[PATCH V5 09/11] scsi: ufs: qcom : Refactor phy_power_on/off calls

[Nitin Rawat]

On 5/22/2025 2:25 PM, Manivannan Sadhasivam wrote:
> On Thu, May 22, 2025 at 03:10:48AM +0530, Nitin Rawat wrote:
>>
>>
>> On 5/21/2025 7:27 PM, Manivannan Sadhasivam wrote:
>>> On Thu, May 15, 2025 at 09:57:20PM +0530, Nitin Rawat wrote:
>>>> Commit 3f6d1767b1a0 ("phy: ufs-qcom: Refactor all init steps into
>>>> phy_poweron") removes the phy_power_on/off from ufs_qcom_setup_clocks
>>>
>>> s/removes/moved
>>
>> Sure, will address in next patchset.
>>
>>>
>>>> to suspend/resume func.
>>>>
>>>> To have a better power saving, remove the phy_power_on/off calls from
>>>> resume/suspend path and put them back to ufs_qcom_setup_clocks, so that
>>>> PHY regulators & clks can be turned on/off along with UFS's clocks.
>>>>
>>>> Since phy phy_power_on is separated out from phy calibrate, make
>>>> separate calls to phy_power_on and phy_calibrate calls from ufs qcom
>>>> driver.
>>>>
>>>
>>> This patch is not calling phy_calibrate().
>>
>> updated commit text to remove phy_Calibrate from commit text
>>
>>>
>>>> Co-developed-by: Can Guo <quic_cang at quicinc.com>
>>>> Signed-off-by: Can Guo <quic_cang at quicinc.com>
>>>> Signed-off-by: Nitin Rawat <quic_nitirawa at quicinc.com>
>>>> ---
>>>>    drivers/ufs/host/ufs-qcom.c | 61 ++++++++++++++++++-------------------
>>>>    1 file changed, 29 insertions(+), 32 deletions(-)
>>>>
>>>
>>> [...]
>>>
>>>>    static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
>>>>    				 enum ufs_notify_change_status status)
>>>>    {
>>>>    	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>>>> +	struct phy *phy = host->generic_phy;
>>>> +	int err;
>>>>    	/*
>>>>    	 * In case ufs_qcom_init() is not yet done, simply ignore.
>>>> @@ -1157,10 +1141,22 @@ static int ufs_qcom_setup_clocks(struct ufs_hba *hba, bool on,
>>>>    				/* disable device ref_clk */
>>>>    				ufs_qcom_dev_ref_clk_ctrl(host, false);
>>>>    			}
>>>> +
>>>> +			err = phy_power_off(phy);
>>>> +			if (err) {
>>>> +				dev_err(hba->dev, "phy power off failed, ret=%d\n", err);
>>>> +				return err;
>>>> +			}
>>>>    		}
>>>>    		break;
>>>>    	case POST_CHANGE:
>>>>    		if (on) {
>>>> +			err = phy_power_on(phy);
>>>> +			if (err) {
>>>> +				dev_err(hba->dev, "phy power on failed, ret = %d\n", err);
>>>> +				return err;
>>>> +			}
>>>> +
>>>>    			/* enable the device ref clock for HS mode*/
>>>>    			if (ufshcd_is_hs_mode(&hba->pwr_info))
>>>>    				ufs_qcom_dev_ref_clk_ctrl(host, true);
>>>> @@ -1343,9 +1339,10 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>>>>    static void ufs_qcom_exit(struct ufs_hba *hba)
>>>>    {
>>>>    	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>>>> +	struct phy *phy = host->generic_phy;
>>>>    	ufs_qcom_disable_lane_clks(host);
>>>> -	phy_power_off(host->generic_phy);
>>>> +	phy_power_off(phy);
>>>
>>> This change is not at all needed.
>>
>> In the current code, PHY resources (clocks and rails) remain active even
>> when the link is in a hibernate state and all controller clocks are off.
>> This results in a significant power penalty and can prevent CX power
>> collapse.
>>
>> These rails and clocks are only turned off when a system suspend is
>> triggered, and even then, only at SPM level 5 where the link is turned off.
>> This approach is not power-efficient.
>>
>> As part of this series, the code that enables/disables the PHY's regulators
>> and clocks is now confined to the phy_power_on and phy_power_off calls, with
>> the rest moved to the calibration phase.
>>
>> Therefore, we are invoking the phy_power_off and phy_power_on calls from
>> ufs_qcom_setup_clocks, ensuring that the PHY's regulators and clocks can be
>> turned on/off along with the UFS clocks, thereby achieving power savings.
>>
>> Therefore, this patch is the cornerstone of this series.
>>
> 
> I did not question the patch, but just the change that you did in the
> ufs_qcom_exit() function. You added a local variable for 'host->generic_phy',
> which is not related to this patch.

Sorry about that, Mani. I misunderstood your comments. Sure, will 
address them.


> 
> - Mani
>