Re: [PATCH 2/3] arm64: dts: qcom: sm6350: Add OPP table support to UFSHC

[Konrad Dybcio]

On 3/17/25 1:12 PM, Luca Weiss wrote:
> Hi Konrad,
> 
> On Fri Mar 14, 2025 at 11:08 PM CET, Konrad Dybcio wrote:
>> On 3/14/25 10:17 AM, Luca Weiss wrote:
>>> UFS host controller, when scaling gears, should choose appropriate
>>> performance state of RPMh power domain controller along with clock
>>> frequency. So let's add the OPP table support to specify both clock
>>> frequency and RPMh performance states replacing the old "freq-table-hz"
>>> property.
>>>
>>> Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
>>> ---
>>
>> [...]
>>
>>> +
>>> +			ufs_opp_table: opp-table {
>>> +				compatible = "operating-points-v2";
>>> +
>>> +				opp-50000000 {
>>> +					opp-hz = /bits/ 64 <50000000>,
>>> +						 /bits/ 64 <0>,
>>> +						 /bits/ 64 <0>,
>>> +						 /bits/ 64 <37500000>,
>>
>> This rate on this clk requires opp_svs (not low_svs)
> 
> Not sure where you're seeing this?
> 
> This is from my msm-4.19 tree:
> 
> gcc_ufs_phy_axi_clk_src:
>     .rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 50000000,
> gcc_ufs_phy_unipro_core_clk_src:
>     .rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 37500000,
> gcc_ufs_phy_ice_core_clk_src:
>     .rate_max = (unsigned long[VDD_NUM]) { [VDD_LOWER] = 75000000,
> 
> [VDD_LOWER] = RPMH_REGULATOR_LEVEL_LOW_SVS,
> 
> My intepretation for this is we need low_svs?

Hm, I took another look and it seems you're right, I must have misread

Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>

Konrad