From: Asutosh Das <asutoshd@codeaurora.org>
To: cang@codeaurora.org, martin.petersen@oracle.com,
Avri.Altman@wdc.com, linux-scsi@vger.kernel.org
Cc: Asutosh Das <asutoshd@codeaurora.org>, linux-arm-msm@vger.kernel.org
Subject: [PATCH v1 0/3] WriteBooster Feature Support
Date: Wed, 8 Apr 2020 14:48:38 -0700 [thread overview]
Message-ID: <cover.1586374414.git.asutoshd@codeaurora.org> (raw)
RFC -> v1:
- Added platform capability for WriteBooster
RFC-:
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 | 8 ++
drivers/scsi/ufs/ufs-sysfs.c | 39 ++++++-
drivers/scsi/ufs/ufs.h | 37 ++++++-
drivers/scsi/ufs/ufshcd.c | 241 ++++++++++++++++++++++++++++++++++++++++++-
drivers/scsi/ufs/ufshcd.h | 43 ++++++++
5 files changed, 362 insertions(+), 6 deletions(-)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
WARNING: multiple messages have this Message-ID (diff)
From: Asutosh Das <asutoshd@codeaurora.org>
To: cang@codeaurora.org, martin.petersen@oracle.com,
Avri.Altman@wdc.com, linux-scsi@vger.kernel.org
Cc: Asutosh Das <asutoshd@codeaurora.org>, linux-arm-msm@vger.kernel.org
Subject: [PATCH v1 0/3] WriteBooster Feature Support
Date: Tue, 21 Apr 2020 15:54:15 -0700 [thread overview]
Message-ID: <cover.1586374414.git.asutoshd@codeaurora.org> (raw)
Message-ID: <20200421225415.930Pluh6ACLaRkrQbd8JpKvj5AVbpLBeQMeFgY94OTA@z> (raw)
v1 -> v2:
- Refactor WriteBooster initialization, introduce ufshcd_wb_probe()
- Refactor ufshcd_wb_keep_vcc_on() and introduce a new function
ufshcd_wb_presrv_usrspc_keep_vcc_on()
- Get the WriteBooster configuration by reading
bWriteBoosterBufferPreserveUserSpaceEn
RFC -> v1:
- Added platform capability for WriteBooster
RFC-:
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 | 8 ++
drivers/scsi/ufs/ufs-sysfs.c | 39 ++++++-
drivers/scsi/ufs/ufs.h | 37 ++++++-
drivers/scsi/ufs/ufshcd.c | 241 ++++++++++++++++++++++++++++++++++++++++++-
drivers/scsi/ufs/ufshcd.h | 43 ++++++++
5 files changed, 362 insertions(+), 6 deletions(-)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
WARNING: multiple messages have this Message-ID (diff)
From: Asutosh Das <asutoshd@codeaurora.org>
To: cang@codeaurora.org, martin.petersen@oracle.com,
Avri.Altman@wdc.com, linux-scsi@vger.kernel.org
Cc: Asutosh Das <asutoshd@codeaurora.org>, linux-arm-msm@vger.kernel.org
Subject: [PATCH v3 0/3] WriteBooster Feature Support
Date: Wed, 22 Apr 2020 14:41:41 -0700 [thread overview]
Message-ID: <cover.1586374414.git.asutoshd@codeaurora.org> (raw)
Message-ID: <20200422214141.bU11rc0AzpQW5ql9q-RfaHOQDWs5g-fepZsBTl9kR-c@z> (raw)
v2 -> v3:
- Addressed Comments on refactoring
- Corrected the commit message
v1 -> v2:
- Refactor WriteBooster initialization, introduce ufshcd_wb_probe()
- Refactor ufshcd_wb_keep_vcc_on() and introduce a new function
ufshcd_wb_presrv_usrspc_keep_vcc_on()
- Get the WriteBooster configuration by reading
bWriteBoosterBufferPreserveUserSpaceEn
RFC -> v1:
- Added platform capability for WriteBooster
RFC-:
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 | 8 ++
drivers/scsi/ufs/ufs-sysfs.c | 39 ++++++-
drivers/scsi/ufs/ufs.h | 37 ++++++-
drivers/scsi/ufs/ufshcd.c | 241 ++++++++++++++++++++++++++++++++++++++++++-
drivers/scsi/ufs/ufshcd.h | 43 ++++++++
5 files changed, 362 insertions(+), 6 deletions(-)
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
next reply other threads:[~2020-04-08 21:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 21:48 Asutosh Das [this message]
2020-04-08 21:48 ` [PATCH v1 1/3] scsi: ufs: add write booster feature support Asutosh Das
2020-04-08 21:48 ` [PATCH v1 2/3] ufs-qcom: scsi: configure write booster type Asutosh Das
2020-04-08 21:48 ` [PATCH v1 3/3] ufs: sysfs: add sysfs entries for write booster Asutosh Das
2020-04-12 12:43 ` [PATCH v1 1/3] scsi: ufs: add write booster feature support Avri Altman
2020-04-21 20:01 ` Asutosh Das (asd)
2020-06-20 21:13 ` Rob Clark
2020-06-21 7:40 ` Avri Altman
2020-06-21 7:55 ` Bjorn Andersson
2020-06-21 16:50 ` Rob Clark
2020-06-21 17:50 ` Steev Klimaszewski
2020-06-23 4:34 ` Kyuho Choi
2020-06-23 6:09 ` Avri Altman
2020-06-23 6:51 ` Kyuho Choi
2020-06-24 1:10 ` Steev Klimaszewski
2020-06-24 1:53 ` Stanley Chu
2020-06-24 2:06 ` Kyuho Choi
2020-06-24 2:49 ` Stanley Chu
2020-06-24 16:15 ` Steev Klimaszewski
2020-06-25 3:29 ` Stanley Chu
2020-06-24 1:54 ` Kyuho Choi
2020-04-21 22:54 ` [PATCH v1 0/3] WriteBooster Feature Support Asutosh Das
2020-04-21 22:54 ` [PATCH v2 1/3] scsi: ufs: add write booster feature support Asutosh Das
2020-04-21 22:54 ` [PATCH v2 2/3] ufs: sysfs: add sysfs entries for write booster Asutosh Das
2020-04-22 8:49 ` Avri Altman
2020-04-21 22:54 ` [PATCH v2 3/3] ufs-qcom: scsi: configure write booster type Asutosh Das
2020-04-22 8:51 ` Avri Altman
2020-04-22 10:28 ` [PATCH v2 1/3] scsi: ufs: add write booster feature support Avri Altman
2020-04-22 10:35 ` Avri Altman
2020-04-22 21:41 ` [PATCH v3 0/3] WriteBooster Feature Support Asutosh Das
2020-04-22 21:41 ` [PATCH v3 1/3] scsi: ufs: add write booster feature support Asutosh Das
2020-04-22 21:41 ` [PATCH v3 2/3] ufs: sysfs: add sysfs entries for write booster Asutosh Das
2020-04-22 21:41 ` [PATCH v3 3/3] ufs-qcom: scsi: configure write booster type Asutosh Das
2020-04-23 8:30 ` [PATCH v3 0/3] WriteBooster Feature Support Avri Altman
2020-04-27 22:49 ` [PATCH v1 " Martin K. Petersen
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=cover.1586374414.git.asutoshd@codeaurora.org \
--to=asutoshd@codeaurora.org \
--cc=Avri.Altman@wdc.com \
--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).