LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Avri Altman <Avri.Altman@wdc.com>
To: Asutosh Das <asutoshd@codeaurora.org>,
	"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: Tue, 25 Feb 2020 12:50:36 +0000	[thread overview]
Message-ID: <MN2PR04MB699133FA7E3B2B7A4F1450FAFCED0@MN2PR04MB6991.namprd04.prod.outlook.com> (raw)
In-Reply-To: <0eb182e6731bc4ce0c1d6a97f102155d7186520f.1582330473.git.asutoshd@codeaurora.org>

> +/*
> + * 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?

> +                 (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...

> +                   (avail_buf < UFS_WB_40_PERCENT_BUF_REMAIN)) {
> +                       hba->dev_info.keep_vcc_on = true;
> +                       return true;
> +               }
> +       }
> +       return false;
> +}

Thanks,
Avri

  parent reply	other threads:[~2020-02-25 12:50 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 [this message]
2020-02-26 17:57     ` Asutosh Das (asd)
2020-03-16 23:52     ` Asutosh Das (asd)
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=MN2PR04MB699133FA7E3B2B7A4F1450FAFCED0@MN2PR04MB6991.namprd04.prod.outlook.com \
    --to=avri.altman@wdc.com \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --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: 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).