All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] scsi: ufshpb: Properly handle max-single-cmd
@ 2021-10-31 12:36 Avri Altman
       [not found] ` <CGME20211031123708epcas2p16645db36a077acf3bd6c0138e50fedc8@epcms2p7>
  0 siblings, 1 reply; 2+ messages in thread
From: Avri Altman @ 2021-10-31 12:36 UTC (permalink / raw)
  To: James E . J . Bottomley, Martin K . Petersen
  Cc: linux-scsi, linux-kernel, Bart Van Assche, Adrian Hunter,
	Bean Huo, Daejun Park, Avri Altman

The spec recommends that for transfer length larger than the
max-single-cmd attribute (bMAX_ DATA_SIZE_FOR_HPB_SINGLE_CMD) it is
possible to couple pre-reqs with the HPB-READ command.  Being a
recommendation, using pre-reqs can be perceived merely as a mean of
optimization.  A common practice was to send pre-reqs for chunks within
some interval, and leave the READ10 untouched if larger.

Anyway, now that the pre-reqs flows have been opt-out, all the commands
are single commands.  So properly handle this attribute and do not send
HPB-READ for transfer lengths larger than max-single-cmd.

Fixes: 09d9e4d04187 (scsi: ufs: ufshpb: Remove HPB2.0 flows)

Signed-off-by: Avri Altman <avri.altman@wdc.com>
---
 drivers/scsi/ufs/ufshpb.c | 29 +++++++++++++++--------------
 drivers/scsi/ufs/ufshpb.h |  1 -
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 026a133149dc..40e62d9e2c89 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -394,8 +394,6 @@ int ufshpb_prep(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
 	if (!ufshpb_is_supported_chunk(hpb, transfer_len))
 		return 0;
 
-	WARN_ON_ONCE(transfer_len > HPB_MULTI_CHUNK_HIGH);
-
 	if (hpb->is_hcm) {
 		/*
 		 * in host control mode, reads are the main source for
@@ -1572,7 +1570,7 @@ static void ufshpb_lu_parameter_init(struct ufs_hba *hba,
 	if (ufshpb_is_legacy(hba))
 		hpb->pre_req_max_tr_len = HPB_LEGACY_CHUNK_HIGH;
 	else
-		hpb->pre_req_max_tr_len = HPB_MULTI_CHUNK_HIGH;
+		hpb->pre_req_max_tr_len = hpb_dev_info->max_hpb_single_cmd;
 
 	hpb->lu_pinned_start = hpb_lu_info->pinned_start;
 	hpb->lu_pinned_end = hpb_lu_info->num_pinned ?
@@ -2582,7 +2580,7 @@ void ufshpb_get_dev_info(struct ufs_hba *hba, u8 *desc_buf)
 {
 	struct ufshpb_dev_info *hpb_dev_info = &hba->ufshpb_dev;
 	int version, ret;
-	u32 max_hpb_single_cmd = HPB_MULTI_CHUNK_LOW;
+	int max_single_cmd;
 
 	hpb_dev_info->control_mode = desc_buf[DEVICE_DESC_PARAM_HPB_CONTROL];
 
@@ -2598,21 +2596,24 @@ void ufshpb_get_dev_info(struct ufs_hba *hba, u8 *desc_buf)
 	if (version == HPB_SUPPORT_LEGACY_VERSION)
 		hpb_dev_info->is_legacy = true;
 
-	pm_runtime_get_sync(hba->dev);
-	ret = ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_READ_ATTR,
-		QUERY_ATTR_IDN_MAX_HPB_SINGLE_CMD, 0, 0, &max_hpb_single_cmd);
-	pm_runtime_put_sync(hba->dev);
-
-	if (ret)
-		dev_err(hba->dev, "%s: idn: read max size of single hpb cmd query request failed",
-			__func__);
-	hpb_dev_info->max_hpb_single_cmd = max_hpb_single_cmd;
-
 	/*
 	 * Get the number of user logical unit to check whether all
 	 * scsi_device finish initialization
 	 */
 	hpb_dev_info->num_lu = desc_buf[DEVICE_DESC_PARAM_NUM_LU];
+
+	if (hpb_dev_info->is_legacy)
+		return;
+
+	pm_runtime_get_sync(hba->dev);
+	ret = ufshcd_query_attr_retry(hba, UPIU_QUERY_OPCODE_READ_ATTR,
+		QUERY_ATTR_IDN_MAX_HPB_SINGLE_CMD, 0, 0, &max_single_cmd);
+	pm_runtime_put_sync(hba->dev);
+
+	if (ret)
+		hpb_dev_info->max_hpb_single_cmd = HPB_LEGACY_CHUNK_HIGH;
+	else
+		hpb_dev_info->max_hpb_single_cmd = min(max_single_cmd + 1, HPB_MULTI_CHUNK_HIGH);
 }
 
 void ufshpb_init(struct ufs_hba *hba)
diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
index f15d8fdbce2e..b475dbd78988 100644
--- a/drivers/scsi/ufs/ufshpb.h
+++ b/drivers/scsi/ufs/ufshpb.h
@@ -31,7 +31,6 @@
 
 /* hpb support chunk size */
 #define HPB_LEGACY_CHUNK_HIGH			1
-#define HPB_MULTI_CHUNK_LOW			7
 #define HPB_MULTI_CHUNK_HIGH			255
 
 /* hpb vender defined opcode */
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* RE: [PATCH] scsi: ufshpb: Properly handle max-single-cmd
       [not found] ` <CGME20211031123708epcas2p16645db36a077acf3bd6c0138e50fedc8@epcms2p7>
@ 2021-11-01  7:22   ` Daejun Park
  0 siblings, 0 replies; 2+ messages in thread
From: Daejun Park @ 2021-11-01  7:22 UTC (permalink / raw)
  To: Avri Altman, James E . J . Bottomley, Martin K . Petersen
  Cc: linux-scsi, linux-kernel, Bart Van Assche, Adrian Hunter,
	Bean Huo, Daejun Park

Hi Avri,

> The spec recommends that for transfer length larger than the
> max-single-cmd attribute (bMAX_ DATA_SIZE_FOR_HPB_SINGLE_CMD) it is
> possible to couple pre-reqs with the HPB-READ command.  Being a
> recommendation, using pre-reqs can be perceived merely as a mean of
> optimization.  A common practice was to send pre-reqs for chunks within
> some interval, and leave the READ10 untouched if larger.
>  
> Anyway, now that the pre-reqs flows have been opt-out, all the commands
> are single commands.  So properly handle this attribute and do not send
> HPB-READ for transfer lengths larger than max-single-cmd.
>  
> Fixes: 09d9e4d04187 (scsi: ufs: ufshpb: Remove HPB2.0 flows)
>  
> Signed-off-by: Avri Altman <avri.altman@wdc.com>
> ---
>  drivers/scsi/ufs/ufshpb.c | 29 +++++++++++++++--------------
>  drivers/scsi/ufs/ufshpb.h |  1 -
>  2 files changed, 15 insertions(+), 15 deletions(-)

Reviewed-by: Daejun Park <daejun7.park@samsung.com>

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-11-01  7:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-31 12:36 [PATCH] scsi: ufshpb: Properly handle max-single-cmd Avri Altman
     [not found] ` <CGME20211031123708epcas2p16645db36a077acf3bd6c0138e50fedc8@epcms2p7>
2021-11-01  7:22   ` Daejun Park

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.