Re: [PATCH v1 3/5] scsi: ufs: customize flush threshold for WriteBooster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/8/2020 10:15 AM, Stanley Chu wrote:
Allow flush threshold for WriteBooster to be customizable by
vendors. To achieve this, make the value as a variable in struct
ufs_hba first.

Signed-off-by: Stanley Chu <stanley.chu@xxxxxxxxxxxx>
---
  drivers/scsi/ufs/ufshcd.c | 6 ++++--
  drivers/scsi/ufs/ufshcd.h | 1 +
  2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index cdacbe6378a1..9a0ce6550c2f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5301,8 +5301,8 @@ static bool ufshcd_wb_presrv_usrspc_keep_vcc_on(struct ufs_hba *hba,
  			 cur_buf);
  		return false;
  	}
-	/* Let it continue to flush when >60% full */
-	if (avail_buf < UFS_WB_40_PERCENT_BUF_REMAIN)
+	/* Let it continue to flush when available buffer exceeds threshold */
+	if (avail_buf < hba->vps->wb_flush_threshold)
  		return true;
return false;
@@ -6839,6 +6839,7 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8 *desc_buf)
  		if (!d_lu_wb_buf_alloc)
  			goto wb_disabled;
  	}
+
Is this newline needed?

  	return;
wb_disabled:
@@ -7462,6 +7463,7 @@ static const struct attribute_group *ufshcd_driver_groups[] = {
static struct ufs_hba_variant_params ufs_hba_vps = {
  	.hba_enable_delay_us		= 1000,
+	.wb_flush_threshold		= UFS_WB_40_PERCENT_BUF_REMAIN,
  	.devfreq_profile.polling_ms	= 100,
  	.devfreq_profile.target		= ufshcd_devfreq_target,
  	.devfreq_profile.get_dev_status	= ufshcd_devfreq_get_dev_status,
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index f7bdf52ba8b0..e3dfb48e669e 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -570,6 +570,7 @@ struct ufs_hba_variant_params {
  	struct devfreq_dev_profile devfreq_profile;
  	struct devfreq_simple_ondemand_data ondemand_data;
  	u16 hba_enable_delay_us;
+	u32 wb_flush_threshold;
  };
/**


Patch[3] & [4] may be combined into a single patch perhaps?
Patch[4] just redoes what [3] did in a different way, so might as well just do what patch[4] does right away.


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux