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
next 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-25 2:00 ` Keoseong Park
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-25 3:23 ` Keoseong Park
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 3:43 ` Keoseong Park
2022-04-26 21:56 ` 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 3:54 ` Keoseong Park [this message]
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
2022-04-25 2:25 ` Keoseong Park
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.