From: Avri Altman <Avri.Altman@wdc.com>
To: Asutosh Das <asutoshd@codeaurora.org>,
"cang@codeaurora.org" <cang@codeaurora.org>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Cc: "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: RE: [<RFC RESEND PATCH v2> 0/3] WriteBooster Feature Support
Date: Thu, 26 Mar 2020 21:53:25 +0000 [thread overview]
Message-ID: <SN6PR04MB46401B509D68CAE9C4828B0FFCCF0@SN6PR04MB4640.namprd04.prod.outlook.com> (raw)
In-Reply-To: <cover.1584752043.git.asutoshd@codeaurora.org>
Hi,
The code looks good to me and I encourage you to submit your patches.
I just want to make some general remarks:
- The way you use the clock scaling to set WB on/off, is IMO, an elegant design choice.
- You should add a platform capability for WB
- As for setting user space configuration options - I think you've got it wrong.
You should read it from bSupportedWriteBoosterBufferUserSpaceReductionTypes
(offset 0x55 in the device descriptor).
This is a configurable parameter that the chipset vendor control and can set during provisioning.
- I agree with your approach toward flush during runtime suspend (keep-vcc-on):
it is the host's interest to assist the device with some extra idle time if needed for WB flush.
This way you will assure consistent write performance.
Thanks,
Avri
>
>
> Still a RFC patch, because I'm still expecting some comments
> on the design.
>
> v1 -> v2:
> - Addressed comments on v1
>
> - Supports shared buffer mode only
>
> - Didn't use exception event as suggested.
> The reason being while testing I saw that the WriteBooster
> available buffer remains at 0x1 for a longer time if flush is
> enabled all the time as compared to an event-based enablement.
> This essentially means that writes go to the WriteBooster buffer
> more. Spec says that the if flush is enabled, the device would
> flush when it sees the command queue empty. So I guess that'd trigger
> flush more than an event based approach.
> Anyway the Vcc would be turned-off during system suspend, so flush
> would stop anyway.
> In this patchset, I never turn-off flush.
> Hence the RFC.
>
> Asutosh Das (3):
> scsi: ufs: add write booster feature support
> ufs-qcom: scsi: configure write booster type
> ufs: sysfs: add sysfs entries for write booster
>
> drivers/scsi/ufs/ufs-qcom.c | 7 ++
> drivers/scsi/ufs/ufs-sysfs.c | 39 ++++++-
> drivers/scsi/ufs/ufs.h | 37 ++++++-
> drivers/scsi/ufs/ufshcd.c | 238
> ++++++++++++++++++++++++++++++++++++++++++-
> drivers/scsi/ufs/ufshcd.h | 9 ++
> 5 files changed, 324 insertions(+), 6 deletions(-)
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project.
prev parent reply other threads:[~2020-03-26 21:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-21 0:59 [<RFC RESEND PATCH v2> 0/3] WriteBooster Feature Support Asutosh Das
2020-03-21 0:59 ` [<RFC RESEND PATCH v2> 1/3] scsi: ufs: add write booster feature support Asutosh Das
2020-03-21 0:59 ` [<RFC RESEND PATCH v2> 2/3] ufs-qcom: scsi: configure write booster type Asutosh Das
2020-03-21 0:59 ` [<RFC RESEND PATCH v2> 3/3] ufs: sysfs: add sysfs entries for write booster Asutosh Das
2020-03-26 21:53 ` Avri Altman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SN6PR04MB46401B509D68CAE9C4828B0FFCCF0@SN6PR04MB4640.namprd04.prod.outlook.com \
--to=avri.altman@wdc.com \
--cc=asutoshd@codeaurora.org \
--cc=cang@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).