2020-12-08 21:16:26

by Bean Huo

[permalink] [raw]
Subject: [PATCH v3 0/3] Three changes for UFS WriteBooster

From: Bean Huo <[email protected]>

Changelog:
v2--v3:
1. Change multi-line comments style in patch 1/3 (Can Guo)

v1--v2:
1. Take is_hibern8_wb_flush checkup out from function
ufshcd_wb_need_flush() in patch 2/3
2. Add UFSHCD_CAP_CLK_SCALING checkup in patch 1/3. that means
only for the platform, which doesn't support UFSHCD_CAP_CLK_SCALING,
can control WB through "wb_on".

Bean Huo (3):
scsi: ufs: Add "wb_on" sysfs node to control WB on/off
scsi: ufs: Keep device active mode only
fWriteBoosterBufferFlushDuringHibernate == 1
scsi: ufs: Changes comment in the function ufshcd_wb_probe()

drivers/scsi/ufs/ufs-sysfs.c | 41 ++++++++++++++++++++++++++++++++++++
drivers/scsi/ufs/ufs.h | 2 ++
drivers/scsi/ufs/ufshcd.c | 30 ++++++++++++++++----------
drivers/scsi/ufs/ufshcd.h | 2 ++
4 files changed, 64 insertions(+), 11 deletions(-)

--
2.17.1


2020-12-08 21:16:33

by Bean Huo

[permalink] [raw]
Subject: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1

From: Bean Huo <[email protected]>

According to the JEDEC UFS 3.1 Spec, If fWriteBoosterBufferFlushDuringHibernate
is set to one, the device flushes the WriteBooster Buffer data automatically
whenever the link enters the hibernate (HIBERN8) state. While the flushing
operation is in progress, the device should be kept in Active power mode.
Currently, we set this flag during the UFSHCD probe stage, but we didn't deal
with its programming failure. Even this failure is less likely to occur, but
still it is possible.
This patch is to add checkup of fWriteBoosterBufferFlushDuringHibernate setting,
keep the device as "active power mode" only when this flag be successfully set
to 1.

Fixes: 51dd905bd2f6 ("scsi: ufs: Fix WriteBooster flush during runtime suspend")
Signed-off-by: Bean Huo <[email protected]>
---
drivers/scsi/ufs/ufs.h | 2 ++
drivers/scsi/ufs/ufshcd.c | 20 +++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index d593edb48767..311d5f7a024d 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -530,6 +530,8 @@ struct ufs_dev_info {
bool f_power_on_wp_en;
/* Keeps information if any of the LU is power on write protected */
bool is_lu_power_on_wp;
+ /* Indicates if flush WB buffer during hibern8 successfully enabled */
+ bool is_hibern8_wb_flush;
/* Maximum number of general LU supported by the UFS device */
u8 max_lu_supported;
u8 wb_dedicated_lu;
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f9fefb6c7ddb..f3ba46c48383 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -283,10 +283,16 @@ static inline void ufshcd_wb_config(struct ufs_hba *hba)
dev_err(hba->dev, "%s: Enable WB failed: %d\n", __func__, ret);
else
dev_info(hba->dev, "%s: Write Booster Configured\n", __func__);
+
ret = ufshcd_wb_toggle_flush_during_h8(hba, true);
- if (ret)
+ if (ret) {
dev_err(hba->dev, "%s: En WB flush during H8: failed: %d\n",
__func__, ret);
+ hba->dev_info.is_hibern8_wb_flush = false;
+ } else {
+ hba->dev_info.is_hibern8_wb_flush = true;
+ }
+
ufshcd_wb_toggle_flush(hba, true);
}

@@ -5444,6 +5450,7 @@ static bool ufshcd_wb_need_flush(struct ufs_hba *hba)

if (!ufshcd_is_wb_allowed(hba))
return false;
+
/*
* The ufs device needs the vcc to be ON to flush.
* With user-space reduction enabled, it's enough to enable flush
@@ -8535,6 +8542,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
+ bool hibern8;

hba->pm_op_in_progress = 1;
if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8594,11 +8602,13 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
* Hibern8, keep device power mode as "active power mode"
* and VCC supply.
*/
+ hibern8 = req_link_state == UIC_LINK_HIBERN8_STATE ||
+ (req_link_state == UIC_LINK_ACTIVE_STATE &&
+ ufshcd_is_auto_hibern8_enabled(hba));
+
hba->dev_info.b_rpm_dev_flush_capable =
- hba->auto_bkops_enabled ||
- (((req_link_state == UIC_LINK_HIBERN8_STATE) ||
- ((req_link_state == UIC_LINK_ACTIVE_STATE) &&
- ufshcd_is_auto_hibern8_enabled(hba))) &&
+ hba->auto_bkops_enabled || (hibern8 &&
+ hba->dev_info.is_hibern8_wb_flush &&
ufshcd_wb_need_flush(hba));
}

--
2.17.1

2020-12-08 21:16:50

by Bean Huo

[permalink] [raw]
Subject: [PATCH v3 1/3] scsi: ufs: Add "wb_on" sysfs node to control WB on/off

From: Bean Huo <[email protected]>

Currently UFS WriteBooster driver uses clock scaling up/down to set
WB on/off, for the platform which doesn't support UFSHCD_CAP_CLK_SCALING,
WB will be always on. Provide a sysfs attribute to enable/disable WB
during runtime. Write 1/0 to "wb_on" sysfs node to enable/disable UFS WB.

Reviewed-by: Avri Altman <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Bean Huo <[email protected]>
---
drivers/scsi/ufs/ufs-sysfs.c | 41 ++++++++++++++++++++++++++++++++++++
drivers/scsi/ufs/ufshcd.c | 3 +--
drivers/scsi/ufs/ufshcd.h | 2 ++
3 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 08e72b7eef6a..2b4e9fe935cc 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -189,6 +189,45 @@ static ssize_t auto_hibern8_store(struct device *dev,
return count;
}

+static ssize_t wb_on_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct ufs_hba *hba = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", hba->wb_enabled);
+}
+
+static ssize_t wb_on_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct ufs_hba *hba = dev_get_drvdata(dev);
+ unsigned int wb_enable;
+ ssize_t res;
+
+ if (ufshcd_is_clkscaling_supported(hba)) {
+ /*
+ * If the platform supports UFSHCD_CAP_AUTO_BKOPS_SUSPEND,
+ * turn WB on/off will be done while clock scaling up/down.
+ */
+ dev_warn(dev, "To control WB through wb_on is not allowed!\n");
+ return -EOPNOTSUPP;
+ }
+ if (!ufshcd_is_wb_allowed(hba))
+ return -EOPNOTSUPP;
+
+ if (kstrtouint(buf, 0, &wb_enable))
+ return -EINVAL;
+
+ if (wb_enable != 0 && wb_enable != 1)
+ return -EINVAL;
+
+ pm_runtime_get_sync(hba->dev);
+ res = ufshcd_wb_ctrl(hba, wb_enable);
+ pm_runtime_put_sync(hba->dev);
+
+ return res < 0 ? res : count;
+}
+
static DEVICE_ATTR_RW(rpm_lvl);
static DEVICE_ATTR_RO(rpm_target_dev_state);
static DEVICE_ATTR_RO(rpm_target_link_state);
@@ -196,6 +235,7 @@ static DEVICE_ATTR_RW(spm_lvl);
static DEVICE_ATTR_RO(spm_target_dev_state);
static DEVICE_ATTR_RO(spm_target_link_state);
static DEVICE_ATTR_RW(auto_hibern8);
+static DEVICE_ATTR_RW(wb_on);

static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
&dev_attr_rpm_lvl.attr,
@@ -205,6 +245,7 @@ static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
&dev_attr_spm_target_dev_state.attr,
&dev_attr_spm_target_link_state.attr,
&dev_attr_auto_hibern8.attr,
+ &dev_attr_wb_on.attr,
NULL
};

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 11a4aad09f3a..f9fefb6c7ddb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -245,7 +245,6 @@ static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
static int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag);
static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
-static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
static int ufshcd_wb_toggle_flush_during_h8(struct ufs_hba *hba, bool set);
static inline void ufshcd_wb_toggle_flush(struct ufs_hba *hba, bool enable);
static void ufshcd_hba_vreg_set_lpm(struct ufs_hba *hba);
@@ -5303,7 +5302,7 @@ static void ufshcd_bkops_exception_event_handler(struct ufs_hba *hba)
__func__, err);
}

-static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
+int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
{
int ret;
u8 index;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 7a7e056a33a9..ea19d6c77faf 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -1073,6 +1073,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
u8 *desc_buff, int *buff_len,
enum query_opcode desc_op);

+int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
+
/* Wrapper functions for safely calling variant operations */
static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
{
--
2.17.1

2020-12-08 21:17:16

by Bean Huo

[permalink] [raw]
Subject: [PATCH v3 3/3] scsi: ufs: Changes comment in the function ufshcd_wb_probe()

From: Bean Huo <[email protected]>

USFHCD supports WriteBooster "LU dedicated buffer” mode and
“shared buffer” mode both, so changes the comment in the
function ufshcd_wb_probe().

Signed-off-by: Bean Huo <[email protected]>
Reviewed-by: Can Guo <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
---
drivers/scsi/ufs/ufshcd.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f3ba46c48383..75ea74748bc6 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7167,10 +7167,9 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8 *desc_buf)
goto wb_disabled;

/*
- * WB may be supported but not configured while provisioning.
- * The spec says, in dedicated wb buffer mode,
- * a max of 1 lun would have wb buffer configured.
- * Now only shared buffer mode is supported.
+ * WB may be supported but not configured while provisioning. The spec
+ * says, in dedicated wb buffer mode, a max of 1 lun would have wb
+ * buffer configured.
*/
dev_info->b_wb_buffer_type =
desc_buf[DEVICE_DESC_PARAM_WB_TYPE];
--
2.17.1

2020-12-09 07:45:35

by Avri Altman

[permalink] [raw]
Subject: RE: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1

> From: Bean Huo <[email protected]>
>
> According to the JEDEC UFS 3.1 Spec, If
> fWriteBoosterBufferFlushDuringHibernate
> is set to one, the device flushes the WriteBooster Buffer data automatically
> whenever the link enters the hibernate (HIBERN8) state. While the flushing
> operation is in progress, the device should be kept in Active power mode.
> Currently, we set this flag during the UFSHCD probe stage, but we didn't deal
> with its programming failure. Even this failure is less likely to occur, but
> still it is possible.
How about reading it on every ufshcd_wb_need_flush?

Thanks,
Avri

2020-12-09 22:10:23

by Bean Huo

[permalink] [raw]
Subject: Re: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1

On Wed, 2020-12-09 at 07:40 +0000, Avri Altman wrote:
> > According to the JEDEC UFS 3.1 Spec, If
> > fWriteBoosterBufferFlushDuringHibernate
> > is set to one, the device flushes the WriteBooster Buffer data
> > automatically
> > whenever the link enters the hibernate (HIBERN8) state. While the
> > flushing
> > operation is in progress, the device should be kept in Active power
> > mode.
> > Currently, we set this flag during the UFSHCD probe stage, but we
> > didn't deal
> > with its programming failure. Even this failure is less likely to
> > occur, but
> > still it is possible.
>
> How about reading it on every ufshcd_wb_need_flush?
>
> Thanks,
> Avri


Hi Avri
I was using that way, no different from the current my way. Instead,
reading on every time will add some delay. As long as the UFS device
returns the successful, we assume that this flag has been properly
set. so, just keeping is_hibern8_wb_flush if set, I think it is
enough.

Thanks,
Bean

2020-12-09 22:14:25

by Bean Huo

[permalink] [raw]
Subject: Re: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1

On Wed, 2020-12-09 at 07:40 +0000, Avri Altman wrote:
> > From: Bean Huo <[email protected]>
> >
> > According to the JEDEC UFS 3.1 Spec, If
> > fWriteBoosterBufferFlushDuringHibernate
> > is set to one, the device flushes the WriteBooster Buffer data
> > automatically
> > whenever the link enters the hibernate (HIBERN8) state. While the
> > flushing
> > operation is in progress, the device should be kept in Active power
> > mode.
> > Currently, we set this flag during the UFSHCD probe stage, but we
> > didn't deal
> > with its programming failure. Even this failure is less likely to
> > occur, but
> > still it is possible.

Hi, Can and Stanley
Please review this patch, and leave your comments.
or if you look good, leave your review-tag, in order that Martin can
accept this series patch easily.

Thanks,
Bean


2020-12-10 07:49:24

by Avri Altman

[permalink] [raw]
Subject: RE: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1

> On Wed, 2020-12-09 at 07:40 +0000, Avri Altman wrote:
> > > According to the JEDEC UFS 3.1 Spec, If
> > > fWriteBoosterBufferFlushDuringHibernate
> > > is set to one, the device flushes the WriteBooster Buffer data
> > > automatically
> > > whenever the link enters the hibernate (HIBERN8) state. While the
> > > flushing
> > > operation is in progress, the device should be kept in Active power
> > > mode.
> > > Currently, we set this flag during the UFSHCD probe stage, but we
> > > didn't deal
> > > with its programming failure. Even this failure is less likely to
> > > occur, but
> > > still it is possible.
> >
> > How about reading it on every ufshcd_wb_need_flush?
> >
> > Thanks,
> > Avri
>
>
> Hi Avri
> I was using that way, no different from the current my way. Instead,
> reading on every time will add some delay. As long as the UFS device
> returns the successful, we assume that this flag has been properly
> set. so, just keeping is_hibern8_wb_flush if set, I think it is
> enough.
Right.
But it is a small price, and you no longer need to worry about rare error event.
Also adding an if (fWriteBoosterBufferFlushDuringHibernate == 1) will allow some more flexibility,
e.g. shutting it off from user-space (ufs-utils), unlike today,
that it is categorically on for all platforms / devices.

Anyway, if you decided to add new capability,
Preferable to do it in a different series.

Thanks,
Avri

2020-12-10 20:19:19

by Bean Huo

[permalink] [raw]
Subject: Re: [PATCH v3 2/3] scsi: ufs: Keep device active mode only fWriteBoosterBufferFlushDuringHibernate == 1

On Thu, 2020-12-10 at 07:46 +0000, Avri Altman wrote:
> >
>
> Right.
> But it is a small price, and you no longer need to worry about rare
> error event.
> Also adding an if (fWriteBoosterBufferFlushDuringHibernate == 1) will
> allow some more flexibility,
> e.g. shutting it off from user-space (ufs-utils), unlike today,
> that it is categorically on for all platforms / devices.
>
> Anyway, if you decided to add new capability,
> Preferable to do it in a different series.
>
> Thanks,
> Avri

Hi Avri
Thanks. This reminds me that ufs-bsg is a latent defect. Currently,
userspace can pass any raw UPIU commands to the UFS through ufs-bsg,
ufs-bsg is a pass-through channel. So,
fWriteBoosterBufferFlushDuringHibernate is not the only one in the
ufshcd.c can be changed by ufs-utils. any flags in the UFS can be
changed by user-space tool after UFS finishing its initialization.


This modification after the fact (Linux initialization/probe itself) is
not legal. I remembered we discussed this on the eMMC case, the same
with here that, user can change some parameters in the eMMC through
eMMC Ioctl, the user feels great, but they did a wrong thing.


Ulf Hansson: "I don't think it's worth to compensate and try
to act accordingly to cover cases when userspace has messed up."



thanks,
Bean