From: Keoseong Park <keosung.park@samsung.com>
To: Bean Huo <huobean@gmail.com>,
ALIM AKHTAR <alim.akhtar@samsung.com>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
"beanhuo@micron.com" <beanhuo@micron.com>,
"bvanassche@acm.org" <bvanassche@acm.org>,
"tomas.winkler@intel.com" <tomas.winkler@intel.com>,
Daejun Park <daejun7.park@samsung.com>,
Keoseong Park <keosung.park@samsung.com>,
"peter.wang@mediatek.com" <peter.wang@mediatek.com>,
"powen.kao@mediatek.com" <powen.kao@mediatek.com>,
cpgsproxy3 <cpgsproxy3@samsung.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3 5/6] scsi: ufshpb: Add handing of device reset HPB regions Infos in HPB device mode
Date: Mon, 25 Apr 2022 12:54:04 +0900 [thread overview]
Message-ID: <1796371666.21650859682732.JavaMail.epsvc@epcpadp4> (raw)
In-Reply-To: <20220424220713.1253049-6-huobean@gmail.com>
>From: Bean Huo <beanhuo@micron.com>
>
>In UFS HPB Spec JESD220-3A,
>
>"5.8. Active and inactive information upon power cycle
>...
>When the device is powered off by the host, the device may restore L2P map data
>upon power up or build from the host’s HPB READ command. In case device powered
>up and lost HPB information, device can signal to the host through HPB Sense data,
>by setting HPB Operation as ‘2’ which will inform the host that device reset HPB
>information."
>
>Therefore, for HPB device control mode, if the UFS device is reset via the RST_N
>pin, the active region information in the device will be reset. If the host side
>receives this notification from the device side, it is recommended to inactivate
>all active regions in the host's HPB cache.
>
>Signed-off-by: Bean Huo <beanhuo@micron.com>
>---
> drivers/scsi/ufs/ufshpb.c | 82 +++++++++++++++++++++++++++------------
> 1 file changed, 58 insertions(+), 24 deletions(-)
>
>diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
>index e7f311bb4401..7868412054bf 100644
>--- a/drivers/scsi/ufs/ufshpb.c
>+++ b/drivers/scsi/ufs/ufshpb.c
>@@ -1137,6 +1137,39 @@ static int ufshpb_add_region(struct ufshpb_lu *hpb, struct ufshpb_region *rgn)
> spin_unlock_irqrestore(&hpb->rgn_state_lock, flags);
> return ret;
> }
>+/**
>+ *ufshpb_submit_region_inactive() - submit a region to be inactivated later
>+ *@hpb: per-LU HPB instance
>+ *@region_index: the index associated with the region that will be inactivated later
>+ */
>+static void ufshpb_submit_region_inactive(struct ufshpb_lu *hpb, int region_index)
>+{
>+ int subregion_index;
>+ struct ufshpb_region *rgn;
>+ struct ufshpb_subregion *srgn;
>+
>+ /*
>+ * Remove this region from active region list and add it to inactive list
>+ */
>+ spin_lock(&hpb->rsp_list_lock);
>+ ufshpb_update_inactive_info(hpb, region_index);
>+ spin_unlock(&hpb->rsp_list_lock);
>+
>+ rgn = hpb->rgn_tbl + region_index;
>+
>+ /*
>+ * Set subregion state to be HPB_SRGN_INVALID, there will no HPB read on this subregion
>+ */
>+ spin_lock(&hpb->rgn_state_lock);
>+ if (rgn->rgn_state != HPB_RGN_INACTIVE) {
>+ for (subregion_index = 0; subregion_index < rgn->srgn_cnt; subregion_index++) {
>+ srgn = rgn->srgn_tbl + subregion_index;
>+ if (srgn->srgn_state == HPB_SRGN_VALID)
>+ srgn->srgn_state = HPB_SRGN_INVALID;
>+ }
>+ }
>+ spin_unlock(&hpb->rgn_state_lock);
>+}
>
> static void ufshpb_rsp_req_region_update(struct ufshpb_lu *hpb,
> struct utp_hpb_rsp *rsp_field)
>@@ -1196,25 +1229,8 @@ static void ufshpb_rsp_req_region_update(struct ufshpb_lu *hpb,
>
> for (i = 0; i < rsp_field->inactive_rgn_cnt; i++) {
> rgn_i = be16_to_cpu(rsp_field->hpb_inactive_field[i]);
>- dev_dbg(&hpb->sdev_ufs_lu->sdev_dev,
>- "inactivate(%d) region %d\n", i, rgn_i);
>-
>- spin_lock(&hpb->rsp_list_lock);
>- ufshpb_update_inactive_info(hpb, rgn_i);
>- spin_unlock(&hpb->rsp_list_lock);
>-
>- rgn = hpb->rgn_tbl + rgn_i;
>-
>- spin_lock(&hpb->rgn_state_lock);
>- if (rgn->rgn_state != HPB_RGN_INACTIVE) {
>- for (srgn_i = 0; srgn_i < rgn->srgn_cnt; srgn_i++) {
>- srgn = rgn->srgn_tbl + srgn_i;
>- if (srgn->srgn_state == HPB_SRGN_VALID)
>- srgn->srgn_state = HPB_SRGN_INVALID;
>- }
>- }
>- spin_unlock(&hpb->rgn_state_lock);
>-
>+ dev_dbg(&hpb->sdev_ufs_lu->sdev_dev, "inactivate(%d) region %d\n", i, rgn_i);
>+ ufshpb_submit_region_inactive(hpb, rgn_i);
> }
>
> out:
>@@ -1249,14 +1265,32 @@ static void ufshpb_dev_reset_handler(struct ufs_hba *hba)
>
> __shost_for_each_device(sdev, hba->host) {
> hpb = ufshpb_get_hpb_data(sdev);
>- if (hpb && hpb->is_hcm)
>+ if (!hpb)
>+ continue;
>+
>+ if (hpb->is_hcm) {
> /*
>- * For the HPB host mode, in case device powered up and lost HPB
>- * information, we will set the region flag to be RGN_FLAG_UPDATE,
>- * it will let host reload its L2P entries(re-activate the region
>- * in the UFS device).
>+ * For the HPB host control mode, in case device powered up and lost HPB
>+ * information, we will set the region flag to be RGN_FLAG_UPDATE, it will
>+ * let host reload its L2P entries(reactivate region in the UFS device).
> */
> ufshpb_set_regions_update(hpb);
>+ } else {
>+ /*
>+ * For the HPB device control mode, if host side receives 02h:HPB Operation
>+ * in UPIU response, which means device recommends the host side should
>+ * inactivate all active regions. Here we add all active regions to inactive
>+ * list, they will be inactivated later in ufshpb_map_work_handler().
>+ */
>+ struct victim_select_info *lru_info = &hpb->lru_info;
>+ struct ufshpb_region *rgn;
>+
>+ list_for_each_entry(rgn, &lru_info->lh_lru_rgn, list_lru_rgn)
>+ ufshpb_submit_region_inactive(hpb, rgn->rgn_idx);
>+
>+ if (ufshpb_get_state(hpb) == HPB_PRESENT)
>+ queue_work(ufshpb_wq, &hpb->map_work);
>+ }
> }
> }
>
>--
>2.34.1
>
>
Looks good to me.
Reviewed-by: Keoseong Park <keosung.park@samsung.com>
Best Regards,
Keoseong Park
prev parent reply other threads:[~2022-04-25 4:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-24 22:07 [PATCH v3 0/6] Several changes for UFSHPB Bean Huo
2022-04-24 22:07 ` [PATCH v3 1/6] scsi: ufshpb: Merge ufshpb_reset() and ufshpb_reset_host() Bean Huo
2022-04-24 22:07 ` [PATCH v3 2/6] scsi: ufshpb: Remove 0 assignment for enum value Bean Huo
2022-04-24 22:07 ` [PATCH v3 3/6] scsi: ufshpb: Cleanup the handler when device reset HPB information Bean Huo
2022-04-24 22:07 ` [PATCH v3 4/6] scsi: ufshpb: Change sysfs node hpb_stats/rb_* prefix to start with rcmd_* Bean Huo
2022-04-25 6:19 ` Avri Altman
2022-04-26 21:44 ` Bean Huo
2022-04-24 22:07 ` [PATCH v3 5/6] scsi: ufshpb: Add handing of device reset HPB regions Infos in HPB device mode Bean Huo
2022-04-25 6:43 ` Avri Altman
2022-04-26 21:54 ` Bean Huo
2022-04-24 22:07 ` [PATCH v3 6/6] scsi: ufshpb: Cleanup ufshpb_suspend/resume Bean Huo
[not found] ` <CGME20220424220726epcas2p2a4824a1c187680fe519bfba447e23b32@epcms2p1>
2022-04-25 2:00 ` [PATCH v3 1/6] scsi: ufshpb: Merge ufshpb_reset() and ufshpb_reset_host() Keoseong Park
[not found] ` <CGME20220424220758epcas2p398348a86cb11bced52451da2de09629d@epcms2p1>
2022-04-25 2:25 ` [PATCH v3 6/6] scsi: ufshpb: Cleanup ufshpb_suspend/resume Keoseong Park
[not found] ` <CGME20220424220758epcas2p1c518cbee68ebefaf1565909f60711561@epcms2p1>
2022-04-25 3:23 ` [PATCH v3 3/6] scsi: ufshpb: Cleanup the handler when device reset HPB information Keoseong Park
[not found] ` <CGME20220424220757epcas2p37d7fcf3c58b1c29291f6e6765e6690ed@epcms2p3>
2022-04-25 3:43 ` [PATCH v3 4/6] scsi: ufshpb: Change sysfs node hpb_stats/rb_* prefix to start with rcmd_* Keoseong Park
2022-04-26 21:56 ` Bean Huo
[not found] ` <CGME20220424220755epcas2p231c49e8ae1326d63429b0fdd31600733@epcms2p4>
2022-04-25 3:54 ` Keoseong Park [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=1796371666.21650859682732.JavaMail.epsvc@epcpadp4 \
--to=keosung.park@samsung.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=cpgsproxy3@samsung.com \
--cc=daejun7.park@samsung.com \
--cc=huobean@gmail.com \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=peter.wang@mediatek.com \
--cc=powen.kao@mediatek.com \
--cc=stanley.chu@mediatek.com \
--cc=tomas.winkler@intel.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).