From: nitirawa@codeaurora.org
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: asutoshd@codeaurora.org, cang@codeaurora.org,
stummala@codeaurora.org, vbadigan@codeaurora.org,
alim.akhtar@samsung.com, avri.altman@wdc.com, jejb@linux.ibm.com,
martin.petersen@oracle.com, stanley.chu@mediatek.com,
beanhuo@micron.com, adrian.hunter@intel.com, bvanassche@acm.org,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2 3/3] scsi: ufs-qcom: configure VCC voltage level in vendor file
Date: Thu, 25 Mar 2021 03:25:19 +0530 [thread overview]
Message-ID: <f27b4fde8092088ec5dc6232cc4b2318@codeaurora.org> (raw)
In-Reply-To: <20210323152834.GH5254@yoga>
On 2021-03-23 20:58, Bjorn Andersson wrote:
> On Sun 21 Mar 16:57 CDT 2021, Nitin Rawat wrote:
>
>> As a part of vops handler, VCC voltage is updated
>> as per the ufs device probed after reading the device
>> descriptor. We follow below steps to configure voltage
>> level.
>>
>> 1. Set the device to SLEEP state.
>> 2. Disable the Vcc Regulator.
>> 3. Set the vcc voltage according to the device type and reenable
>> the regulator.
>> 4. Set the device mode back to ACTIVE.
>>
>
> When we discussed this a while back this was described as a requirement
> from the device specification, you only operate on objects "owned" by
> ufshcd and you invoke ufshcd operations to perform the actions.
>
> So why is this a ufs-qcom patch and not something in ufshcd?
>
> Regards,
> Bjorn
>
>> Signed-off-by: Nitin Rawat <nitirawa@codeaurora.org>
>> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
>> ---
>> drivers/scsi/ufs/ufs-qcom.c | 51
>> +++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>>
>> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
>> index f97d7b0..ca35f5c 100644
>> --- a/drivers/scsi/ufs/ufs-qcom.c
>> +++ b/drivers/scsi/ufs/ufs-qcom.c
>> @@ -21,6 +21,17 @@
>> #define UFS_QCOM_DEFAULT_DBG_PRINT_EN \
>> (UFS_QCOM_DBG_PRINT_REGS_EN | UFS_QCOM_DBG_PRINT_TEST_BUS_EN)
>>
>> +#define ANDROID_BOOT_DEV_MAX 30
>> +static char android_boot_dev[ANDROID_BOOT_DEV_MAX];
>> +
>> +/* Min and Max VCC voltage values for ufs 2.x and
>> + * ufs 3.x devices
>> + */
>> +#define UFS_3X_VREG_VCC_MIN_UV 2540000 /* uV */
>> +#define UFS_3X_VREG_VCC_MAX_UV 2700000 /* uV */
>> +#define UFS_2X_VREG_VCC_MIN_UV 2950000 /* uV */
>> +#define UFS_2X_VREG_VCC_MAX_UV 2960000 /* uV */
>> +
>> enum {
>> TSTBUS_UAWM,
>> TSTBUS_UARM,
>> @@ -1293,6 +1304,45 @@ static void
>> ufs_qcom_print_hw_debug_reg_all(struct ufs_hba *hba,
>> print_fn(hba, reg, 9, "UFS_DBG_RD_REG_TMRLUT ", priv);
>> }
>>
>> + /**
>> + * ufs_qcom_setup_vcc_regulators - Update VCC voltage
>> + * @hba: host controller instance
>> + * Update VCC voltage based on UFS device(ufs 2.x or
>> + * ufs 3.x probed)
>> + */
>> +static int ufs_qcom_setup_vcc_regulators(struct ufs_hba *hba)
>> +{
>> + struct ufs_dev_info *dev_info = &hba->dev_info;
>> + struct ufs_vreg *vreg = hba->vreg_info.vcc;
>> + int ret;
>> +
>> + /* Put the device in sleep before lowering VCC level */
>> + ret = ufshcd_set_dev_pwr_mode(hba, UFS_SLEEP_PWR_MODE);
>> +
>> + /* Switch off VCC before switching it ON at 2.5v or 2.96v */
>> + ret = ufshcd_disable_vreg(hba->dev, vreg);
>> +
>> + /* add ~2ms delay before renabling VCC at lower voltage */
>> + usleep_range(2000, 2100);
>> +
>> + /* set VCC min and max voltage according to ufs device type */
>> + if (dev_info->wspecversion >= 0x300) {
>> + vreg->min_uV = UFS_3X_VREG_VCC_MIN_UV;
>> + vreg->max_uV = UFS_3X_VREG_VCC_MAX_UV;
>> + }
>> +
>> + else {
>> + vreg->min_uV = UFS_2X_VREG_VCC_MIN_UV;
>> + vreg->max_uV = UFS_2X_VREG_VCC_MAX_UV;
>> + }
>> +
>> + ret = ufshcd_enable_vreg(hba->dev, vreg);
>> +
>> + /* Bring the device in active now */
>> + ret = ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE);
>> + return ret;
>> +}
>> +
>> static void ufs_qcom_enable_test_bus(struct ufs_qcom_host *host)
>> {
>> if (host->dbg_print_en & UFS_QCOM_DBG_PRINT_TEST_BUS_EN) {
>> @@ -1490,6 +1540,7 @@ static const struct ufs_hba_variant_ops
>> ufs_hba_qcom_vops = {
>> .device_reset = ufs_qcom_device_reset,
>> .config_scaling_param = ufs_qcom_config_scaling_param,
>> .program_key = ufs_qcom_ice_program_key,
>> + .setup_vcc_regulators = ufs_qcom_setup_vcc_regulators,
>> };
>>
>> /**
>> --
>> 2.7.4
>>
Hi Bjorn,
Thanks for your review.
But As per the earlier discussion regarding handling of vcc voltage
for platform supporting both ufs 2.x and ufs 3.x , it was finally
concluded to
use "vops and let vendors handle it, until specs or someone
has a better suggestion". Please correct me in case i am wrong.
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2399116.html
Regards,
Nitin
next prev parent reply other threads:[~2021-03-24 21:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-21 21:57 [PATCH V2 0/3] scsi: ufs: Add a vops to configure VCC voltage level Nitin Rawat
2021-03-21 21:57 ` [PATCH V2 1/3] scsi: ufs: export api for use in vendor file Nitin Rawat
2021-03-21 21:57 ` [PATCH V2 2/3] scsi: ufs: add a vops to configure VCC voltage level Nitin Rawat
2021-03-31 18:00 ` Asutosh Das (asd)
2021-04-01 15:00 ` nitirawa
2021-04-01 15:03 ` nitirawa
2021-03-21 21:57 ` [PATCH V2 3/3] scsi: ufs-qcom: configure VCC voltage level in vendor file Nitin Rawat
2021-03-23 15:28 ` Bjorn Andersson
2021-03-24 21:55 ` nitirawa [this message]
2021-03-31 18:19 ` Bjorn Andersson
2021-04-01 14:58 ` nitirawa
2021-04-01 15:12 ` Bjorn Andersson
2021-05-26 7:23 ` nitirawa
2021-06-03 20:31 ` nitirawa
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=f27b4fde8092088ec5dc6232cc4b2318@codeaurora.org \
--to=nitirawa@codeaurora.org \
--cc=adrian.hunter@intel.com \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bjorn.andersson@linaro.org \
--cc=bvanassche@acm.org \
--cc=cang@codeaurora.org \
--cc=jejb@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=stanley.chu@mediatek.com \
--cc=stummala@codeaurora.org \
--cc=vbadigan@codeaurora.org \
/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.