Re: [RESEND] [PATCH v11 2/6] added UFS 2.0 capabilities

[Joao Pinto]

On 3/29/2016 12:33 PM, Winkler, Tomas wrote:
> Hi Thomas,
> 
> On 3/29/2016 11:41 AM, Winkler, Tomas wrote:
>>
>> Adding UFS 2.0 support to the UFS core driver.
>>
>> Signed-off-by: Joao Pinto <jpinto@xxxxxxxxxxxx>
>> Acked-by: Arnd Bergmann <arnd@xxxxxxxx>
>> Acked-by: Rob Herring <robh@xxxxxxxxxx>
>> ---
>> Changes v8->v11:
>> - Nothing changed (just to keep up with patch set version).
>> Changes v7->v8:
>> - Added "jedec, ufs-2.0" to the ufschd-platform compatibility strings Changes v0->v7:
>> - Nothing changed (just to keep up with patch set version).
>>
>>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt      |  4 +--
>>  drivers/scsi/ufs/ufshcd.c                          | 29 +++++++++++++++++++---
>>  drivers/scsi/ufs/ufshci.h                          |  1 +
>>  3 files changed, 28 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
>> b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> index 03c0e98..8d9a9d2 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> @@ -4,8 +4,8 @@ UFSHC nodes are defined to describe on-chip UFS host controllers.
>>  Each UFS controller instance should have its own node.
>>  
>>  Required properties:
>> -- compatible		: must contain "jedec,ufs-1.1", may also list one or more
>> -					  of the following:
>> +- compatible		: must contain "jedec,ufs-1.1" or "jedec,ufs-2.0", may
>> +			  also list one or more of the following:
>>  					  "qcom,msm8994-ufshc"
>>  					  "qcom,msm8996-ufshc"
>>  					  "qcom,ufshc"
>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c 
>> index 85cd256..2b5f2bf 100644
>>
>> I think this should go in separate patch
> 
> In my opinion it only makes sense to add 2.0 to the device-tree binding if the driver actually supports it, that was why I added to the same patch, but of course it can be separated if more people agree with the approach.
> 
> Yes, we have ufshcd-pci device that needs that so I think this should go separately 

I will separate this, no problem.

>>
>> --- a/drivers/scsi/ufs/ufshcd.c
>> +++ b/drivers/scsi/ufs/ufshcd.c
>> @@ -1223,6 +1223,7 @@ static int ufshcd_compose_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
>>  			ret = -EINVAL;
>>  		}
>>  		break;
>> +	case UTP_CMD_TYPE_UFS_STORAGE:
>>  	case UTP_CMD_TYPE_DEV_MANAGE:
>>  		ufshcd_prepare_req_desc_hdr(lrbp, &upiu_flags, DMA_NONE);
>>  		if (hba->dev_cmd.type == DEV_CMD_TYPE_QUERY) @@ -1287,6 +1288,7 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
>>  	struct ufshcd_lrb *lrbp;
>>  	struct ufs_hba *hba;
>>  	unsigned long flags;
>> +	u32 upiu_flags;
>>  	int tag;
>>  	int err = 0;
>>  
>> @@ -1343,10 +1345,23 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, struct scsi_cmnd *cmd)
>>  	lrbp->task_tag = tag;
>>  	lrbp->lun = ufshcd_scsi_to_upiu_lun(cmd->device->lun);
>>  	lrbp->intr_cmd = !ufshcd_is_intr_aggr_allowed(hba) ? true : false;
>> -	lrbp->command_type = UTP_CMD_TYPE_SCSI;
>> +
>> +	if (hba->ufs_version == UFSHCI_VERSION_20)
>> +		lrbp->command_type = UTP_CMD_TYPE_UFS_STORAGE;
>> +	else
>> +		lrbp->command_type = UTP_CMD_TYPE_SCSI;
>> This translation can be pushed to prepare_req_desc_hdr and you end up 
>> with  ~oneliner fix
> 
> I think your suggestion is good! We have to check the 2.0 version in 2 places and with your approach we would only check it in prepare_req_desc_hdr() once.
> I will do that update!
> 
> Okay I think you can alter ufshcd_lrb structure and push the information there,
> Add ufs version there as hba is not available in req_desc_hdr, I think both command_type and ufs_version can be u8 so the structure won't grow. 

Going to check it out.

> 
> 
>>
>>  
>>  	/* form UPIU before issuing the command */
>> -	ufshcd_compose_upiu(hba, lrbp);
>> +	if (hba->ufs_version == UFSHCI_VERSION_20) {
>> +		if (likely(lrbp->cmd)) {
>> How this can be possible NULL, the code above will crash or I'm missing something ? 
>> +			ufshcd_prepare_req_desc_hdr(lrbp, &upiu_flags,
>> +					lrbp->cmd->sc_data_direction);
>> +			ufshcd_prepare_utp_scsi_cmd_upiu(lrbp, upiu_flags);
>> What is different her from the code in ufshcd_compose_upiu ?
>> +		} else
>> +			err = -EINVAL;
>> +	} else
>> +		ufshcd_compose_upiu(hba, lrbp);
> 
> If you check ufshcd_compose_upiu() you will see that it contains 2 scopes:
> cmd_upiu and query_req_upiu. Before 2.0 this single function approach that had both scopes worked well, but now with 2.0 we must use the same command_type
> (UTP_CMD_TYPE_UFS_STORAGE) which causes incompatibility. This was why I put the same code from cmd_upiu in the outside.
> 
> Of course we can break ufshcd_compose_upiu() in 2: ufshcd_compose_cmd_upiu() and ufshcd_compose_query_upiu(). What do you think?
> If you use ufs_version only in req_desc_hdr then you don't need this
> 
> If (ufs_version == 2.0)
>    cmd_type = UFS_STORAGE 
> else 
>     cmd_type = lrb->command_type 
> 
> ... 
> I think with this change 

Ok, I will test that.

> 
>> +
>>  	err = ufshcd_map_sg(lrbp);
>>  	if (err) {
>>  		lrbp->cmd = NULL;
>> @@ -1371,7 +1386,12 @@ static int ufshcd_compose_dev_cmd(struct ufs_hba *hba,
>>  	lrbp->sense_buffer = NULL;

[snip]

>>  				complete(hba->dev_cmd.complete);
>>  		}
>> diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h 
>> index 0ae0967..8dba0e7 100644
>> --- a/drivers/scsi/ufs/ufshci.h
>> +++ b/drivers/scsi/ufs/ufshci.h
>> @@ -273,6 +273,7 @@ enum {
>>  	UTP_CMD_TYPE_SCSI		= 0x0,
>>  	UTP_CMD_TYPE_UFS		= 0x1,
>>  	UTP_CMD_TYPE_DEV_MANAGE		= 0x2,
>> +	UTP_CMD_TYPE_UFS_STORAGE	= 0x11,
> Why 0x11? 

I'll have to check with our R&D team.

> 
> Thanks
> Tomas 
> 

Thanks
Joao