Re: [PATCH 10/12] arm64: dts: qcom: sm8550: Switch UFS from opp-table-hz to opp-v2

[Konrad Dybcio]

On 12/18/23 17:35, Nitin Rawat wrote:
> On 12/18/2023 9:32 PM, Konrad Dybcio wrote:
> > Now that the non-legacy form of OPP is supported within the UFS driver,
> > go ahead and switch to it, adding support for more intermediate freq/power
> > states.
> >
> > In doing so, add the CX RPMhPD under GCC to make sure at least some of
> > the power state requirements are *actually* propagated up the stack.
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
> > ---
> >   arch/arm64/boot/dts/qcom/sm8550.dtsi | 50 +++++++++++++++++++++++++++++-------
> >   1 file changed, 41 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > index d707d15cea5b..d6edd54f3ad3 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> > @@ -1930,6 +1930,7 @@ ufs_mem_hc: ufs@1d84000 {
> >               iommus = <&apps_smmu 0x60 0x0>;
> >               dma-coherent;
> > +            operating-points-v2 = <&ufs_opp_table>;
> >               interconnects = <&aggre1_noc MASTER_UFS_MEM 0 &mc_virt SLAVE_EBI1 0>,
> >                       <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_UFS_MEM_CFG 0>;
> > @@ -1950,18 +1951,49 @@ ufs_mem_hc: ufs@1d84000 {
> >                    <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> >                    <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>,
> >                    <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>;
> > -            freq-table-hz =
> > -                <75000000 300000000>,
> > -                <0 0>,
> > -                <0 0>,
> > -                <75000000 300000000>,
> > -                <100000000 403000000>,
> > -                <0 0>,
> > -                <0 0>,
> > -                <0 0>;
> >               qcom,ice = <&ice>;
> >               status = "disabled";
> > +
> > +            ufs_opp_table: opp-table {
> > +                compatible = "operating-points-v2";
> > +
> > +                opp-75000000 {
> > +                    opp-hz = /bits/ 64 <75000000>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <75000000>,
> > +                         /bits/ 64 <100000000>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>;
> > +                    required-opps = <&rpmhpd_opp_low_svs>;
> > +                };
> > +
> > +                opp-150000000 {
> > +                    opp-hz = /bits/ 64 <150000000>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <150000000>,
> > +                         /bits/ 64 <100000000> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>;
> > +                    required-opps = <&rpmhpd_opp_svs>;
> > +                };
> > +
> > +                opp-300000000 {
> > +                    opp-hz = /bits/ 64 <300000000>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <0>,
> > +                         /bits/ 64 <300000000>,
> > +                         /bits/ 64 <100000000>,
> Hi Konrad,
>
> This entry is for ICE clock ? Shouldn't the entry be 403000000 ?
> Same for svs as well ?
Hi Nitin,

this entry is for the TCSR_UFS_PAD_CLKREF_EN/"ref_clk" clock,
which doesn't support ratesetting, so it should probably be 0
(or its actual value if we know it - I assumed it was 100 MHz
as it was there before).

The ICE clock is handled separately by the crypto@1d88000 node.

Thinking about it again, the original submission probably included
the ICE clock within the UFS node and when TCSRCC was created,
somebody might have omitted the wrong rate value.

Konrad