LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: "Asutosh Das (asd)" <asutoshd@codeaurora.org> To: Avri Altman <Avri.Altman@wdc.com>, "subhashj@codeaurora.org" <subhashj@codeaurora.org>, "cang@codeaurora.org" <cang@codeaurora.org>, "rnayak@codeaurora.org" <rnayak@codeaurora.org>, "vinholikatti@gmail.com" <vinholikatti@gmail.com>, "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>, "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>, Alim Akhtar <alim.akhtar@samsung.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, Stanley Chu <stanley.chu@mediatek.com>, Bean Huo <beanhuo@micron.com>, Tomas Winkler <tomas.winkler@intel.com>, Colin Ian King <colin.king@canonical.com>, Bart Van Assche <bvanassche@acm.org>, Venkat Gopalakrishnan <venkatg@codeaurora.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, open list <linux-kernel@vger.kernel.org> Subject: Re: [<RFC PATCH v1> 1/2] scsi: ufs: add write booster feature support Date: Mon, 16 Mar 2020 16:52:08 -0700 [thread overview] Message-ID: <8d618210-0f83-47cc-d0c4-cc4343e4d51c@codeaurora.org> (raw) In-Reply-To: <MN2PR04MB699133FA7E3B2B7A4F1450FAFCED0@MN2PR04MB6991.namprd04.prod.outlook.com> On 2/25/2020 4:50 AM, Avri Altman wrote: >> +/* >> + * ufshcd_get_wb_alloc_units - returns >> "dLUNumWriteBoosterBufferAllocUnits" >> + * @hba: per-adapter instance >> + * @lun: UFS device lun id >> + * @d_lun_wbb_au: pointer to buffer to hold the LU's alloc units info >> + * >> + * Returns 0 in case of success and d_lun_wbb_au would be returned >> + * Returns -ENOTSUPP if reading d_lun_wbb_au is not supported. >> + * Returns -EINVAL in case of invalid parameters passed to this function. >> + */ >> +static int ufshcd_get_wb_alloc_units(struct ufs_hba *hba, >> + u8 lun, >> + u8 *d_lun_wbb_au) >> +{ >> + int ret; >> + >> + if (!d_lun_wbb_au) >> + ret = -EINVAL; >> + >> + /* WB can be supported only from LU0..LU7 */ >> + else if (lun >= UFS_UPIU_MAX_GENERAL_LUN) >> + ret = -ENOTSUPP; >> + else >> + ret = ufshcd_read_unit_desc_param(hba, >> + lun, >> + UNIT_DESC_PARAM_WB_BUF_ALLOC_UNITS, >> + d_lun_wbb_au, >> + sizeof(*d_lun_wbb_au)); > You are reading here a single byte, instead of 4 > >> + return ret; >> +} >> + >> /** >> * ufshcd_get_lu_power_on_wp_status - get LU's power on write protect >> * status >> @@ -5194,6 +5267,165 @@ static void >> ufshcd_bkops_exception_event_handler(struct ufs_hba *hba) >> __func__, err); >> } >> >> +static bool ufshcd_wb_sup(struct ufs_hba *hba) >> +{ >> + return ((hba->dev_info.d_ext_ufs_feature_sup & >> + UFS_DEV_WRITE_BOOSTER_SUP) && > Don't you want to have a vendor cap as well, > to allow the platform vendor to control this feature? I presume each platform vendor would provide a provisioning script/method which would configure the WB properties. It can be controlled through that. > >> + (hba->dev_info.b_wb_buffer_type >> + || hba->dev_info.wb_config_lun)); >> +} >> + >> + > > > >> +static bool ufshcd_wb_is_buf_flush_needed(struct ufs_hba *hba) >> +{ >> + int ret; >> + u32 cur_buf, status, avail_buf; >> + >> + if (!ufshcd_wb_sup(hba)) >> + return false; >> + >> + ret = ufshcd_query_attr_retry(hba, >> UPIU_QUERY_OPCODE_READ_ATTR, >> + QUERY_ATTR_IDN_AVAIL_WB_BUFF_SIZE, >> + 0, 0, &avail_buf); >> + if (ret) { >> + dev_warn(hba->dev, "%s dAvailableWriteBoosterBufferSize read >> failed %d\n", >> + __func__, ret); >> + return false; >> + } >> + >> + ret = ufshcd_vops_get_user_cap_mode(hba); >> + if (ret <= 0) { >> + dev_dbg(hba->dev, "Get user-cap reduction mode: failed: %d\n", >> + ret); >> + /* Most commonly used */ >> + ret = UFS_WB_BUFF_PRESERVE_USER_SPACE; >> + } >> + >> + hba->dev_info.keep_vcc_on = false; >> + if (ret == UFS_WB_BUFF_USER_SPACE_RED_EN) { >> + if (avail_buf <= UFS_WB_10_PERCENT_BUF_REMAIN) { >> + hba->dev_info.keep_vcc_on = true; >> + return true; >> + } >> + return false; >> + } else if (ret == UFS_WB_BUFF_PRESERVE_USER_SPACE) { >> + ret = ufshcd_query_attr_retry(hba, >> UPIU_QUERY_OPCODE_READ_ATTR, >> + QUERY_ATTR_IDN_CURR_WB_BUFF_SIZE, >> + 0, 0, &cur_buf); >> + if (ret) { >> + dev_err(hba->dev, "%s dCurWriteBoosterBufferSize read failed >> %d\n", >> + __func__, ret); >> + return false; >> + } >> + >> + if (!cur_buf) { >> + dev_info(hba->dev, "dCurWBBuf: %d WB disabled until free- >> space is available\n", >> + cur_buf); >> + return false; >> + } >> + >> + ret = ufshcd_get_ee_status(hba, &status); >> + if (ret) { >> + dev_err(hba->dev, "%s: failed to get exception status %d\n", >> + __func__, ret); >> + if (avail_buf < UFS_WB_40_PERCENT_BUF_REMAIN) { >> + hba->dev_info.keep_vcc_on = true; >> + return true; >> + } >> + return false; >> + } >> + >> + status &= hba->ee_ctrl_mask; >> + >> + if ((status & MASK_EE_URGENT_BKOPS) || > So you are getting the status, but not the bkops level. > And what about WRITEBOOSTER_EVENT_EN? After all it was invented specifically for WB... Yeah - WB exception event is not supported in this series. I will push another change to support that. With WB enabled, any BKOPS exception level warrants the vcc to be on. This is to minimize performance impact. Please correct this understanding from device perspective. > >> + (avail_buf < UFS_WB_40_PERCENT_BUF_REMAIN)) { >> + hba->dev_info.keep_vcc_on = true; >> + return true; >> + } >> + } >> + return false; >> +} > > Thanks, > Avri > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, Linux Foundation Collaborative Project
next prev parent reply other threads:[~2020-03-16 23:52 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <cover.1582330473.git.asutoshd@codeaurora.org> 2020-02-22 0:47 ` [<RFC PATCH v1> 1/2] scsi: ufs: add write booster feature support Asutosh Das 2020-02-23 9:03 ` Avri Altman 2020-03-16 23:45 ` Asutosh Das (asd) 2020-02-25 10:58 ` Avri Altman 2020-02-25 11:21 ` Avri Altman 2020-02-25 12:50 ` Avri Altman 2020-02-26 17:57 ` Asutosh Das (asd) 2020-03-16 23:52 ` Asutosh Das (asd) [this message] 2020-02-22 0:47 ` [<RFC PATCH v1> 2/2] ufs-qcom: scsi: configure write booster type Asutosh Das
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=8d618210-0f83-47cc-d0c4-cc4343e4d51c@codeaurora.org \ --to=asutoshd@codeaurora.org \ --cc=Avri.Altman@wdc.com \ --cc=alim.akhtar@samsung.com \ --cc=beanhuo@micron.com \ --cc=bjorn.andersson@linaro.org \ --cc=bvanassche@acm.org \ --cc=cang@codeaurora.org \ --cc=colin.king@canonical.com \ --cc=jejb@linux.ibm.com \ --cc=jejb@linux.vnet.ibm.com \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-scsi@vger.kernel.org \ --cc=martin.petersen@oracle.com \ --cc=rnayak@codeaurora.org \ --cc=stanley.chu@mediatek.com \ --cc=subhashj@codeaurora.org \ --cc=tomas.winkler@intel.com \ --cc=venkatg@codeaurora.org \ --cc=vinholikatti@gmail.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: linkBe 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).