Re: [PATCH 1/6] scsi: ufs: ufs-qcom: Setup host power mode during init

Can Guo
2023-10-31T14:06:03Z

Hi Mani,

On 9/19/2023 6:36 PM, Manivannan Sadhasivam wrote:
> On Sun, Sep 10, 2023 at 10:59:22PM -0700, Can Guo wrote:
>> Setup host power mode and its limitations during UFS host driver init to
>> avoid repetitive work during every power mode change.
>>
>> Co-developed-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
>> Signed-off-by: Can Guo <quic_cang@quicinc.com>
>> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
>> ---
>> drivers/ufs/host/ufs-qcom.c | 27 ++++++++++++++++++---------
>> drivers/ufs/host/ufs-qcom.h | 1 +
>> 2 files changed, 19 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
>> index c3215d3..710f079 100644
>> --- a/drivers/ufs/host/ufs-qcom.c
>> +++ b/drivers/ufs/host/ufs-qcom.c
>> @@ -443,7 +443,11 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba)
>> static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>> {
>> struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>> + struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
>> struct phy *phy = host->generic_phy;
>> + enum phy_mode mode = host_pwr_cap->hs_rate == PA_HS_MODE_B ?
>> + PHY_MODE_UFS_HS_B :
>> + PHY_MODE_UFS_HS_A;
> I do not see anyone passing PA_HS_MODE_A in this patch, so this change is not
> required now. If you are doing this as a preparatory work, please do it in a
> separate patch.
Sure.
>
>> int ret;
>>
>> /* Reset UFS Host Controller and PHY */
>> @@ -460,7 +464,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>> return ret;
>> }
>>
>> - phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, host->phy_gear);
>> + phy_set_mode_ext(phy, mode, host->phy_gear);
> Same as above.
Sure.
>
>>
>> /* power on phy - start serdes and phy's power and clocks */
>> ret = phy_power_on(phy);
>> @@ -884,7 +888,6 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>> struct ufs_pa_layer_attr *dev_req_params)
>> {
>> struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>> - struct ufs_dev_params ufs_qcom_cap;
>> int ret = 0;
>>
>> if (!dev_req_params) {
>> @@ -894,13 +897,7 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>>
>> switch (status) {
>> case PRE_CHANGE:
>> - ufshcd_init_pwr_dev_param(&ufs_qcom_cap);
>> - ufs_qcom_cap.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
>> -
>> - /* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
>> - ufs_qcom_cap.hs_tx_gear = ufs_qcom_cap.hs_rx_gear = ufs_qcom_get_hs_gear(hba);
>> -
>> - ret = ufshcd_get_pwr_dev_param(&ufs_qcom_cap,
>> + ret = ufshcd_get_pwr_dev_param(&host->host_pwr_cap,
>> dev_max_params,
>> dev_req_params);
>> if (ret) {
>> @@ -1037,6 +1034,17 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
>> hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>> }
>>
>> +static void ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)
> It's good that you are moving the setting to init() as they are static, but I'm
> worried about the different naming conventions used all over the place.
>
> The intention here is to set host parameters and then get the agreed one between
> host and the device. But different names are being used. The structure itself is
> named as "ufs_dev_params" even though it targets host and the vendor drivers are
> naming it as "ufs_<vendor>_cap" or "host_cap". And now you've given a new name,
> "host_pwr_cap", which makes things even worse.
>
> So we should rename the struct itself as "ufs_host_params" and all the vendor
> drivers should stick to "host_params".

I like the name 'ufs_host_params', will unify the declaration of it in
all vendor drivers in next version.

Thanks,

Can Guo.