RE: [PATCH 4/5] scsi: ufs: rework link start-up process
On Monday, April 29, 2013, Sujit Reddy Thumma wrote:
On 4/29/2013 3:54 PM, Seungwon Jeon wrote:
On Monday, April 29, 2013, Sujit Reddy Thumma wrote:
On 4/26/2013 10:44 AM, Seungwon Jeon wrote:
On Thursday, April 25, 2013 , Sujit Reddy Thumma wrote:
On 4/24/2013 9:36 PM, Seungwon Jeon wrote:
Link start-up requires long time with multiphase handshakes
between UFS host and device. This affects driver's probe time.
This patch let link start-up run asynchronously.
And completion time of uic command is defined to avoid a
permanent wait.
I have similar patch posted few days back scsi: ufs: Generalize UFS
Interconnect Layer (UIC) command support which does a bit more (mutex,
error handling) than what is done here. Can that be used/improved?
I completed to check your patch to compare it now.
Though it's just my thought, the patch I sent is more intuitive on the
whole.
Considering other dme operations which I have introduced, it looks like
matched.
There are lot of code duplications you might want to minimize building a
DME command.
Of course, you may disagree.
But I think the part of mutex is needed. It's a good point.
In case of error handling, I didn't catch nothing special.
Rather, handling link lost case is not proper.
When ufs host meets link lost status, it should start with dme_reset not
retried dme_linkstartup.
In section 7.2.1 (Host Controller Initialization) of JESD223A UFS HCI
v1.1 specification I find this -
6. Sent DME_LINKSTARTUP command to start the link startup procedure
9. Check value of HCS.DP and make sure that there is a device attached
to the Link. If presence of a device is detected, go to step 10;
otherwise, resend the DME_LINKSTARTUP command after IS.ULLS has been set
to 1 (Go to step 6). IS.ULLS equal 1 indicates that the UFS Device is
ready for a link startup.
Going by the spec. just retrying with DME_LINKSTARTUP is correct.
Yes, as you quoted above, HCI standard mentions that.
Also, the following is mentioned.
UIC Link Lost Status (ULLS) corresponds to the UniPro DME_LINKLOST.ind
I just referred unipro specification.
When DME_LINKLOST.ind is generated, this affects the Link is put in the
LinkLost state.
Unipro spec says that DME User must apply a DME_RESET to redo the boot
sequence.
If there is misunderstood meaning and I have something to miss, we can
discuss more.
Please let me know.
Yes, it looks like the two specs. are conflicting each other. I guess we
need to take this to Jedec for clarification. Meanwhile, to be on safe
side can we add a retry mechanism that does ufshcd_hba_enable() before
sending DME_LINKSTARTUP again? This way we can be sure that the
DME_RESET and DME_ENABLE is taken care by the host reset itself.
Yes, If the latter case is applied, 'ufshcd_hba_enable' will be start entry for
retry.
Further, IS.ULLS could be handled through the interrupt instead of polling for
retry mechanism?
In addition, it doesn't say what happens if IS.ULLS never sets to 1.
Probably, the case which never happens.
And it would be good if link start-up procedure is done in separate
process, not in driver probe.
True.
If it's all right with you, I'd like to update lock mechanism for uic
command.
I can add your signed-off. Please let me know your opinion.
I would like to get a third opinion as both the patches needs
modifications.
Some comments below:
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/scsi/ufs/ufshcd.c | 114
+---
drivers/scsi/ufs/ufshcd.h |6 ++-
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efe2256..76ff332 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -38,6 +38,7 @@
#define UFSHCD_ENABLE_INTRS (UTP_TRANSFER_REQ_COMPL |\
UTP_TASK_REQ_COMPL |\
UFSHCD_ERROR_MASK)
+#define UIC_CMD_TIMEOUT100
enum {
UFSHCD_MAX_CHANNEL = 0,
@@ -357,13 +358,15 @@ static inline void ufshcd_hba_capabilities(struct
ufs_hba *hba)
}
/**
- * ufshcd_send_uic_command - Send UIC commands to unipro layers
+ * ufshcd_dispatch_uic_cmd - Dispatch UIC commands to unipro layers
* @hba: per adapter instance
* @uic_command: UIC command
*/
static inline void
-ufshcd_send_uic_command(struct ufs_hba *hba, struct uic_command
*uic_cmnd)
+ufshcd_dispatch_uic_cmd(struct ufs_hba *hba, struct uic_command
*uic_cmnd)
{
+ init_completion(uic_cmnd-done);
+
/* Write Args */
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_1, uic_cmnd-argument1);
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_2, uic_cmnd-argument2);
@@ -375,6 +378,45 @@ ufshcd_send_uic_command(struct ufs_hba *hba,
Re: WRITE SAME failed. Manually zeroing with 3w-xxxx driver
Martin K. Petersen martin.peter...@oracle.com wrote: Florian == Florian Westphal f...@strlen.de writes: Florian After update to 3.8 dmesg is spammed with: kernel: [ Florian 280.272094] 3w-: scsi8: Unknown scsi opcode: 0x41 kernel: [ Florian 280.272107] sd 8:0:0:0: [sda] Unhandled error code kernel: Could you please test the patch below? Works. Only one WRITE_SAME error at boot, max_write_same_blocks in sysfs is 0, which wasn't the case before. The second question is what it is that's issuing these zeroouts at boot? Which filesystem are you using? What's your DM/MD config? ext4, no DM/MD is used. I guess the zeroouts are from postgres, but i'm not sure. 3w-: Create sense buffer for unsupported commands Make the driver return appropriate sense data when an unsupported operation is queued. This will cause the SCSI layer to stop issuing the offending command. Reported-by: Florian Westphal f...@strlen.de CC: adam radford aradf...@gmail.com Signed-off-by: Martin K. Petersen martin.peter...@oracle.com Tested-by: Florian Westphal f...@strlen.de Thanks again. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] scsi: ufs: rework link start-up process
On 4/30/2013 12:03 PM, Seungwon Jeon wrote:
On Monday, April 29, 2013, Sujit Reddy Thumma wrote:
On 4/29/2013 3:54 PM, Seungwon Jeon wrote:
On Monday, April 29, 2013, Sujit Reddy Thumma wrote:
On 4/26/2013 10:44 AM, Seungwon Jeon wrote:
On Thursday, April 25, 2013 , Sujit Reddy Thumma wrote:
On 4/24/2013 9:36 PM, Seungwon Jeon wrote:
Link start-up requires long time with multiphase handshakes
between UFS host and device. This affects driver's probe time.
This patch let link start-up run asynchronously.
And completion time of uic command is defined to avoid a
permanent wait.
I have similar patch posted few days back scsi: ufs: Generalize UFS
Interconnect Layer (UIC) command support which does a bit more (mutex,
error handling) than what is done here. Can that be used/improved?
I completed to check your patch to compare it now.
Though it's just my thought, the patch I sent is more intuitive on the whole.
Considering other dme operations which I have introduced, it looks like matched.
There are lot of code duplications you might want to minimize building a
DME command.
Of course, you may disagree.
But I think the part of mutex is needed. It's a good point.
In case of error handling, I didn't catch nothing special.
Rather, handling link lost case is not proper.
When ufs host meets link lost status, it should start with dme_reset not
retried dme_linkstartup.
In section 7.2.1 (Host Controller Initialization) of JESD223A UFS HCI
v1.1 specification I find this -
6. Sent DME_LINKSTARTUP command to start the link startup procedure
9. Check value of HCS.DP and make sure that there is a device attached
to the Link. If presence of a device is detected, go to step 10;
otherwise, resend the DME_LINKSTARTUP command after IS.ULLS has been set
to 1 (Go to step 6). IS.ULLS equal 1 indicates that the UFS Device is
ready for a link startup.
Going by the spec. just retrying with DME_LINKSTARTUP is correct.
Yes, as you quoted above, HCI standard mentions that.
Also, the following is mentioned.
UIC Link Lost Status (ULLS) corresponds to the UniPro DME_LINKLOST.ind
I just referred unipro specification.
When DME_LINKLOST.ind is generated, this affects the Link is put in the
LinkLost state.
Unipro spec says that DME User must apply a DME_RESET to redo the boot sequence.
If there is misunderstood meaning and I have something to miss, we can discuss
more.
Please let me know.
Yes, it looks like the two specs. are conflicting each other. I guess we
need to take this to Jedec for clarification. Meanwhile, to be on safe
side can we add a retry mechanism that does ufshcd_hba_enable() before
sending DME_LINKSTARTUP again? This way we can be sure that the
DME_RESET and DME_ENABLE is taken care by the host reset itself.
Yes, If the latter case is applied, 'ufshcd_hba_enable' will be start entry for
retry.
Further, IS.ULLS could be handled through the interrupt instead of polling for
retry mechanism?
Agree, but the interrupt handling will be tailored for two things - 1)
bootup case where scsi_scan_host is not yet called. 2) the case where
link lost occurred after a long time after bootup where there is no need
to do scsi_scan_host again.
In addition, it doesn't say what happens if IS.ULLS never sets to 1.
Probably, the case which never happens.
And it would be good if link start-up procedure is done in separate process,
not in driver probe.
True.
If it's all right with you, I'd like to update lock mechanism for uic command.
I can add your signed-off. Please let me know your opinion.
I would like to get a third opinion as both the patches needs modifications.
Some comments below:
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/scsi/ufs/ufshcd.c | 114
+---
drivers/scsi/ufs/ufshcd.h |6 ++-
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efe2256..76ff332 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -38,6 +38,7 @@
#define UFSHCD_ENABLE_INTRS(UTP_TRANSFER_REQ_COMPL |\
UTP_TASK_REQ_COMPL |\
UFSHCD_ERROR_MASK)
+#define UIC_CMD_TIMEOUT100
enum {
UFSHCD_MAX_CHANNEL = 0,
@@ -357,13 +358,15 @@ static inline void ufshcd_hba_capabilities(struct ufs_hba
*hba)
}
/**
- * ufshcd_send_uic_command - Send UIC commands to unipro layers
+ * ufshcd_dispatch_uic_cmd - Dispatch UIC commands to unipro layers
* @hba: per adapter instance
* @uic_command: UIC command
*/
static inline void
-ufshcd_send_uic_command(struct ufs_hba *hba, struct uic_command *uic_cmnd)
+ufshcd_dispatch_uic_cmd(struct ufs_hba *hba, struct uic_command *uic_cmnd)
{
+ init_completion(uic_cmnd-done);
+
/* Write Args */
ufshcd_writel(hba, REG_UIC_COMMAND_ARG_1, uic_cmnd-argument1);
Re: [PATCH 1/5] scsi: ufs: move the ufshcd_hba_stop to ufshcd.c
Looks good. Reviewed-by: Subhash Jadavani subha...@codeaurora.org
On 4/24/2013 9:36 PM, Seungwon Jeon wrote:
Move the ufshcd_hba_stop from header file.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/scsi/ufs/ufshcd.c |9 +
drivers/scsi/ufs/ufshcd.h |9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 60fd40c..41b9639 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -285,6 +285,15 @@ static inline void ufshcd_hba_start(struct ufs_hba *hba)
}
/**
+ * ufshcd_hba_stop - Send controller to reset state
+ * @hba: per adapter instance
+ */
+static inline void ufshcd_hba_stop(struct ufs_hba *hba)
+{
+ writel(CONTROLLER_DISABLE, (hba-mmio_base + REG_CONTROLLER_ENABLE));
+}
+
+/**
* ufshcd_is_hba_active - Get controller state
* @hba: per adapter instance
*
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 6b99a42..1680394 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -190,13 +190,4 @@ int ufshcd_init(struct device *, struct ufs_hba ** ,
void __iomem * ,
unsigned int);
void ufshcd_remove(struct ufs_hba *);
-/**
- * ufshcd_hba_stop - Send controller to reset state
- * @hba: per adapter instance
- */
-static inline void ufshcd_hba_stop(struct ufs_hba *hba)
-{
- writel(CONTROLLER_DISABLE, (hba-mmio_base + REG_CONTROLLER_ENABLE));
-}
-
#endif /* End of Header */
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] scsi: ufs: wrap the i/o access operations
On 4/26/2013 10:36 AM, Seungwon Jeon wrote: Hi, On Thursday, April 25, 2013, Sujit Reddy Thumma wrote: On 4/24/2013 9:36 PM, Seungwon Jeon wrote: Simplify operations with hiding mmio_base. Signed-off-by: Seungwon Jeon tgih@samsung.com --- drivers/scsi/ufs/ufshcd.c | 106 +++-- drivers/scsi/ufs/ufshcd.h |5 ++ 2 files changed, 49 insertions(+), 62 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index 1680394..6728450 100644 --- a/drivers/scsi/ufs/ufshcd.h +++ b/drivers/scsi/ufs/ufshcd.h @@ -190,4 +190,9 @@ int ufshcd_init(struct device *, struct ufs_hba ** , void __iomem * , unsigned int); void ufshcd_remove(struct ufs_hba *); +#define ufshcd_writel(hba, reg, val) \ Let this be consistent with writel() arguments - val as second arg and reg as third? You got a point there. When considering an array of arguments in two functions and value part can be some long expression, I think it seems more coherent. ufshcd_readl(hba, reg); ufshcd_writel(hba, reg, val); How about keeping these? I somehow tend to agree with what Sujit suggested. Its good to be consitent with writel() for better code readability. Thanks, Seungwon Jeon + writel((val), (hba)-mmio_base + (reg)) +#define ufshcd_readl(hba, reg) \ + readl((hba)-mmio_base + (reg)) + #endif /* End of Header */ -- Regards, Sujit -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
LPC2013: File and Storage Systems uconf Approved
Just a heads up, Linux Plumbers has approved the FS Storage micro-conf for this year. Please have a look at the wiki for details: http://www.linuxplumbersconf.org/2013/ I have posted some suggested topics at the site, let's get the planning rolling so we can get people registered in time for the early bird price :) Thanks! Ric -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ISCI: add more PCI IDs
On 04/30/2013 06:12 AM, Evgeni Golov wrote:
These are found in e.g. the R2000GZ/GL machines.
Nack. These PCI device IDs are reserved for third party device drivers.
Most likely that machine has a third party OROM as well.
---
drivers/scsi/isci/init.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
index 2839baa..d1ec2bd 100644
--- a/drivers/scsi/isci/init.c
+++ b/drivers/scsi/isci/init.c
@@ -82,12 +82,16 @@ static DEFINE_PCI_DEVICE_TABLE(isci_id_table) = {
{ PCI_VDEVICE(INTEL, 0x1D67),},
{ PCI_VDEVICE(INTEL, 0x1D69),},
{ PCI_VDEVICE(INTEL, 0x1D6B),},
+ { PCI_VDEVICE(INTEL, 0x1D6D),},
+ { PCI_VDEVICE(INTEL, 0x1D6F),},
{ PCI_VDEVICE(INTEL, 0x1D60),},
{ PCI_VDEVICE(INTEL, 0x1D62),},
{ PCI_VDEVICE(INTEL, 0x1D64),},
{ PCI_VDEVICE(INTEL, 0x1D66),},
{ PCI_VDEVICE(INTEL, 0x1D68),},
{ PCI_VDEVICE(INTEL, 0x1D6A),},
+ { PCI_VDEVICE(INTEL, 0x1D6C),},
+ { PCI_VDEVICE(INTEL, 0x1D6E),},
{}
};
--
Dave Jiang
Application Engineer, Storage Divsion
Intel Corp.
dave.ji...@intel.com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] First round of SCSI updates for the 3.9+ merge window
This is the first round, consisting mostly of drivers and patches submitted 3 weeks ago. Since I've been travelling quite a bit, there will be a second round just before the merge window closes for all the patches three weeks or newer, or which got flagged for my attention after 10 April. The patch set is mostly driver updates (qla4, qla2 [ISF support updates], lpfc, aacraid [dual firmware image support]) and a few bug fixes. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc The short changelog is Adheer Chandravanshi (8): qla4xxx: Use correct value for max flash node entries qla4xxx: Restrict logout from boot target session using session id qla4xxx: Use correct flash ddb offset for ISP40XX qla4xxx: Replace dev type macros with generic portal type macros scsi_transport_iscsi: Declare portal type string macros for generic use qla4xxx: Add flash node mgmt support libiscsi: export function iscsi_switch_str_param scsi_transport_iscsi: Add flash node mgmt support Giridhar Malavali (1): qla2xxx: Enhancements to support ISPFx00. Jack Wang (1): pm8001: updated MAINTAINERS list James Smart (11): lpfc 8.3.38: Update lpfc version for 8.3.38 driver release lpfc 8.3.38: Fixed potential mis-interpretation of READ_TOPOLOGY reserved fields lpfc 8.3.38: Fix default value for lpfc_enable_rrq. lpfc 8.3.38: Fixed circular locking dependency and inconsistent lock state issues lpfc 8.3.38: Fixed PT2PT bring up problem for FC SLI4. lpfc 8.3.38: Fixed OXID reuse issue. lpfc 8.3.38: Fixed async FCF modified event to in-use FCF failure to trigger recovery lpfc 8.3.38: Fixed deadlock condition in FCF round robin handling scsilpfc 8.3.38: Fixed bsg timeout handling issues that would result in crashes lpfc 8.3.38: Fixed degraded performance after cable pulls lpfc 8.3.38: Fixed NMI watch dog panic's when resetting the hba. Jingoo Han (1): isci: add CONFIG_PM_SLEEP to suspend/resume functions Joe Carnuccio (2): qla2xxx: Obtain loopback iteration count from bsg request. qla2xxx: Add clarifying printk to thermal access fail cases. Mahesh Rajashekhara (1): aacraid: Dual firmware image support Manish Dusane (1): qla4xxx: Take E-port out of reset before disabling pause frames Masatake YAMATO (1): libiscsi: avoid unnecessary multiple NULL assignments Mike Christie (2): iscsi_tcp: support PF_MEMALLOC/__GFP_MEMALLOC scsi_dh_alua: fix stpg sense handling Nilesh Javali (1): qla4xxx: Skip retry of initialize_adapter for ISP80XX Saurav Kashyap (1): qla2xxx: Update the driver version to 8.05.00.03-k. Stewart, Sean (1): scsi_dh_alua: Add module parameter to allow failover to non preferred path without STPG Tej Parkash (1): qla4xxx: Fixed request queue count manipulation on response path Vikas Chaudhary (12): qla4xxx: Update driver version to 5.03.00-k8 qla4xxx: Added print statements to display AENs qla4xxx: Update driver version to 5.03.00-k7 qla4xxx: Update driver version to 5.03.00-k6 qla4xxx: Assign correct CHAP table address to FLT qla4xxx: Added missing check for ISP83XX in CHAP related functions qla4xxx: Update driver version to 5.03.00-k5 qla4xxx: Fix debug level to avoid floods of same message qla4xxx: Pass correct LUN address to firmware in case of lun_reset qla4xxx: Fix double reset in case of firmware hung for ISP83XX qla4xxx: Set graceful reset bit for ISP83XX qla4xxx: Boot from SAN fix for ISP83XX Wei Yongjun (2): qla2xxx: Remove duplicated include form qla_isr.c csiostor: remove unused variable in csio_process_fwevtq_entry() And the diffstat MAINTAINERS|2 +- drivers/scsi/aacraid/aacraid.h |6 +- drivers/scsi/aacraid/comminit.c|2 +- drivers/scsi/aacraid/src.c | 26 +- drivers/scsi/csiostor/csio_hw.c|5 - drivers/scsi/device_handler/scsi_dh_alua.c | 17 +- drivers/scsi/isci/init.c |6 +- drivers/scsi/iscsi_tcp.c | 18 +- drivers/scsi/libiscsi.c|4 +- drivers/scsi/lpfc/lpfc_attr.c | 12 +- drivers/scsi/lpfc/lpfc_bsg.c | 1107 + drivers/scsi/lpfc/lpfc_crtn.h |1 + drivers/scsi/lpfc/lpfc_els.c | 21 +- drivers/scsi/lpfc/lpfc_hbadisc.c | 68 +- drivers/scsi/lpfc/lpfc_hw4.h |3 + drivers/scsi/lpfc/lpfc_init.c | 106 +- drivers/scsi/lpfc/lpfc_mbox.c | 24 +- drivers/scsi/lpfc/lpfc_nportdisc.c |1 - drivers/scsi/lpfc/lpfc_scsi.c |8 +- drivers/scsi/lpfc/lpfc_sli.c | 115 +- drivers/scsi/lpfc/lpfc_version.h |2 +-
Re: [PATCH] ISCI: add more PCI IDs
On 04/30/2013 07:33 PM, Dave Jiang wrote: These are found in e.g. the R2000GZ/GL machines. Nack. These PCI device IDs are reserved for third party device drivers. Most likely that machine has a third party OROM as well. OROM = option ROM? Yes, it has the white C600 expansion pack, so we can use all 8 ports of the SAS controller. But we do not want (and actually cannot) use the Intel-provided megasr driver (the machines run Debian Wheezy with the 3.2 kernel). Can we get the controller to use the regular PCI ID instead? Regards Evgeni -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ISCI: add more PCI IDs
On 04/30/2013 11:26 AM, Evgeni Golov wrote: On 04/30/2013 07:33 PM, Dave Jiang wrote: These are found in e.g. the R2000GZ/GL machines. Nack. These PCI device IDs are reserved for third party device drivers. Most likely that machine has a third party OROM as well. OROM = option ROM? Yes, it has the white C600 expansion pack, so we can use all 8 ports of the SAS controller. But we do not want (and actually cannot) use the Intel-provided megasr driver (the machines run Debian Wheezy with the 3.2 kernel). Can we get the controller to use the regular PCI ID instead? Yes. You need an Intel Option ROM instead of the LSI. You need to talk to whomever sold you the system and get the Intel OROM. Also just an FYI, the isci driver didn't get a lot of the issues sorted out until kernel 3.7. The 3.2 driver is quite old and you may run into issues. Obviously you already know you can patch the driver to pick up those device IDs, but I don't know what the LSI OROM does with the OEM parameters and if will provide it to the isci driver properly. Regards Evgeni -- Dave Jiang Application Engineer, Storage Divsion Intel Corp. dave.ji...@intel.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 Resend2 1/2] [SCSI] ufs: Add Platform glue driver for ufshcd
Hi James,
Can this patch be poushed to 3.9+ merge window?
Thnaks,
Maya
This patch adds Platform glue driver for ufshcd.
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Namjae Jeon linkinj...@gmail.com
Reviewed-by: Subhash Jadavani subha...@codeaurora.org
Reviewed-by: Sujit Reddy Thumma sthu...@codeaurora.org
Tested-by: Maya Erez me...@codeaurora.org
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 11 ++
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufshcd-pltfrm.c | 217
++
3 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 0371047..35faf24 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -57,3 +57,14 @@ config SCSI_UFSHCD_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config SCSI_UFSHCD_PLATFORM
+ tristate Platform bus based UFS Controller support
+ depends on SCSI_UFSHCD
+ ---help---
+ This selects the UFS host controller support. Select this if
+ you have an UFS controller on Platform bus.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9eda0df..1e5bd48 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,3 +1,4 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
+obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c
b/drivers/scsi/ufs/ufshcd-pltfrm.c
new file mode 100644
index 000..03319ac
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -0,0 +1,217 @@
+/*
+ * Universal Flash Storage Host controller Platform bus based glue driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd-pltfrm.c
+ * Copyright (C) 2011-2013 Samsung India Software Operations
+ *
+ * Authors:
+ * Santosh Yaraganavi santosh...@samsung.com
+ * Vinayak Holikatti h.vina...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * See the COPYING file in the top-level directory or visit
+ * http://www.gnu.org/licenses/gpl-2.0.html
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This program is provided AS IS and WITH ALL FAULTS and
+ * without warranty of any kind. You are solely responsible for
+ * determining the appropriateness of using and distributing
+ * the program and assume all risks associated with your exercise
+ * of rights with respect to the program, including but not limited
+ * to infringement of third party rights, the risks and costs of
+ * program errors, damage to or loss of data, programs or equipment,
+ * and unavailability or interruption of operations. Under no
+ * circumstances will the contributor of this Program be liable for
+ * any damages of any kind arising from your use or distribution of
+ * this program.
+ */
+
+#include ufshcd.h
+#include linux/platform_device.h
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_pltfrm_suspend - suspend power management function
+ * @dev: pointer to device handle
+ *
+ *
+ * Returns 0
+ */
+static int ufshcd_pltfrm_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct ufs_hba *hba = platform_get_drvdata(pdev);
+
+ /*
+ * TODO:
+ * 1. Call ufshcd_suspend
+ * 2. Do bus specific power management
+ */
+
+ disable_irq(hba-irq);
+
+ return 0;
+}
+
+/**
+ * ufshcd_pltfrm_resume - resume power management function
+ * @dev: pointer to device handle
+ *
+ * Returns 0
+ */
+static int ufshcd_pltfrm_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct ufs_hba *hba = platform_get_drvdata(pdev);
+
+ /*
+ * TODO:
+ * 1. Call ufshcd_resume.
+ * 2. Do bus specific wake up
+ */
+
+ enable_irq(hba-irq);
+
+ return 0;
+}
+#else
+#define ufshcd_pltfrm_suspendNULL
+#define ufshcd_pltfrm_resume NULL
+#endif
+
+/**
+ * ufshcd_pltfrm_probe - probe routine of the driver
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int ufshcd_pltfrm_probe(struct
Re: [PATCH V6 Resend2 2/2] [SCSI] ufs: Correct the expected data transfersize
Hi James, Can this patch be poushed to 3.9+ merge window? Thnaks, Maya This patch corrects the expected data transfer size of the command UPIU. The current implementation of cmd-transfersize is wrong as it probably equal to sector size. With this implementation the transfer size is updated correctly Reported-by: KOBAYASHI Yoshitake yoshitake.kobaya...@toshiba.co.jp Reviewed-by: Arnd Bergmann a...@arndb.de Reviewed-by: Namjae Jeon linkinj...@gmail.com Reviewed-by: Subhash Jadavani subha...@codeaurora.org Tested-by: Maya Erez me...@codeaurora.org Signed-off-by: Santosh Yaraganavi santos...@gmail.com Signed-off-by: Vinayak Holikatti vinholika...@gmail.com --- drivers/scsi/ufs/ufshcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 60fd40c..c32a478 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -478,7 +478,7 @@ static void ufshcd_compose_upiu(struct ufshcd_lrb *lrbp) ucd_cmd_ptr-header.dword_2 = 0; ucd_cmd_ptr-exp_data_transfer_len = - cpu_to_be32(lrbp-cmd-transfersize); + cpu_to_be32(lrbp-cmd-sdb.length); memcpy(ucd_cmd_ptr-cdb, lrbp-cmd-cmnd, -- 1.7.5.4 -- Maya Erez QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
