mbox series

[0/8] Flush RSC votes properly on more RPMh platforms

Message ID 20230531-topic-rsc-v1-0-b4a985f57b8b@linaro.org
Headers
Series Flush RSC votes properly on more RPMh platforms |

Message

Konrad Dybcio May 31, 2023, 1:22 p.m. UTC 
  As pointed out in [1], the Linux implementation of RSC basically requires
(even if not explicitly) that we point it to a power domain which
represents the power state of the CPUs. In an effort to fulfill that
requirement, make it required in bindings and hook it up on all platforms
where I was able to do. This means all RPMh platforms, except

- SC7180
- SC7280
- SA8775

As there wasn't an idle-states setup (which may be on purpose for CrOS
devices, certainly not for Windows SC7[12]80s) that I could validate.
(Doug, Bartosz, could you guys look into your respective platforms of
interest here?)

This series also adds support for idle states on SM6350, as I was able
to add and test that.

[1] https://lore.kernel.org/linux-arm-msm/20230512150425.3171122-1-quic_bjorande@quicinc.com/

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (8):
      dt-bindings: soc: qcom,rpmh-rsc: Require power-domains
      arm64: dts: qcom: sm6350: Add PSCI idle states
      arm64: dts: qcom: qdu1000: Flush RSC sleep & wake votes
      arm64: dts: qcom: sc8180x: Flush RSC sleep & wake votes
      arm64: dts: qcom: sdm670: Flush RSC sleep & wake votes
      arm64: dts: qcom: sdm845: Flush RSC sleep & wake votes
      arm64: dts: qcom: sm6350: Flush RSC sleep & wake votes
      arm64: dts: qcom: sm8550: Flush RSC sleep & wake votes

 .../bindings/soc/qcom/qcom,rpmh-rsc.yaml           |   2 +
 arch/arm64/boot/dts/qcom/qdu1000.dtsi              |   1 +
 arch/arm64/boot/dts/qcom/sc8180x.dtsi              |   1 +
 arch/arm64/boot/dts/qcom/sdm670.dtsi               |   1 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi               |   1 +
 arch/arm64/boot/dts/qcom/sm6350.dtsi               | 142 +++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8550.dtsi               |   1 +
 7 files changed, 149 insertions(+)
---
base-commit: d4cee89031c80066ec461bb77b5e13a4f37d5fd2
change-id: 20230531-topic-rsc-35e838da9afb

Best regards,

Comments

Konrad Dybcio May 31, 2023, 2:25 p.m. UTC | #1 
On 31.05.2023 15:22, Konrad Dybcio wrote:
> As pointed out in [1], the Linux implementation of RSC basically requires
> (even if not explicitly) that we point it to a power domain which
> represents the power state of the CPUs. In an effort to fulfill that
> requirement, make it required in bindings and hook it up on all platforms
> where I was able to do. This means all RPMh platforms, except
> 
> - SC7180
> - SC7280
> - SA8775
> 
> As there wasn't an idle-states setup (which may be on purpose for CrOS
> devices, certainly not for Windows SC7[12]80s) that I could validate.
> (Doug, Bartosz, could you guys look into your respective platforms of
> interest here?)
> 
> This series also adds support for idle states on SM6350, as I was able
> to add and test that.
I noticed that 7280 is WIP:

> 
> [1] https://lore.kernel.org/linux-arm-msm/20230512150425.3171122-1-quic_bjorande@quicinc.com/
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> Konrad Dybcio (8):
>       dt-bindings: soc: qcom,rpmh-rsc: Require power-domains
>       arm64: dts: qcom: sm6350: Add PSCI idle states
>       arm64: dts: qcom: qdu1000: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sc8180x: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sdm670: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sdm845: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sm6350: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sm8550: Flush RSC sleep & wake votes
> 
>  .../bindings/soc/qcom/qcom,rpmh-rsc.yaml           |   2 +
>  arch/arm64/boot/dts/qcom/qdu1000.dtsi              |   1 +
>  arch/arm64/boot/dts/qcom/sc8180x.dtsi              |   1 +
>  arch/arm64/boot/dts/qcom/sdm670.dtsi               |   1 +
>  arch/arm64/boot/dts/qcom/sdm845.dtsi               |   1 +
>  arch/arm64/boot/dts/qcom/sm6350.dtsi               | 142 +++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8550.dtsi               |   1 +
>  7 files changed, 149 insertions(+)
> ---
> base-commit: d4cee89031c80066ec461bb77b5e13a4f37d5fd2
> change-id: 20230531-topic-rsc-35e838da9afb
> 
> Best regards,
Konrad Dybcio May 31, 2023, 2:25 p.m. UTC | #2 
On 31.05.2023 15:22, Konrad Dybcio wrote:
> As pointed out in [1], the Linux implementation of RSC basically requires
> (even if not explicitly) that we point it to a power domain which
> represents the power state of the CPUs. In an effort to fulfill that
> requirement, make it required in bindings and hook it up on all platforms
> where I was able to do. This means all RPMh platforms, except
> 
> - SC7180
> - SC7280
> - SA8775
> 
> As there wasn't an idle-states setup (which may be on purpose for CrOS
> devices, certainly not for Windows SC7[12]80s) that I could validate.
> (Doug, Bartosz, could you guys look into your respective platforms of
> interest here?)
> 
> This series also adds support for idle states on SM6350, as I was able
> to add and test that.
I noticed that 7280 is WIP:

https://lore.kernel.org/lkml/20230424110933.3908-4-quic_mkshah@quicinc.com/

Konrad
> 
> [1] https://lore.kernel.org/linux-arm-msm/20230512150425.3171122-1-quic_bjorande@quicinc.com/
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> Konrad Dybcio (8):
>       dt-bindings: soc: qcom,rpmh-rsc: Require power-domains
>       arm64: dts: qcom: sm6350: Add PSCI idle states
>       arm64: dts: qcom: qdu1000: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sc8180x: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sdm670: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sdm845: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sm6350: Flush RSC sleep & wake votes
>       arm64: dts: qcom: sm8550: Flush RSC sleep & wake votes
> 
>  .../bindings/soc/qcom/qcom,rpmh-rsc.yaml           |   2 +
>  arch/arm64/boot/dts/qcom/qdu1000.dtsi              |   1 +
>  arch/arm64/boot/dts/qcom/sc8180x.dtsi              |   1 +
>  arch/arm64/boot/dts/qcom/sdm670.dtsi               |   1 +
>  arch/arm64/boot/dts/qcom/sdm845.dtsi               |   1 +
>  arch/arm64/boot/dts/qcom/sm6350.dtsi               | 142 +++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8550.dtsi               |   1 +
>  7 files changed, 149 insertions(+)
> ---
> base-commit: d4cee89031c80066ec461bb77b5e13a4f37d5fd2
> change-id: 20230531-topic-rsc-35e838da9afb
> 
> Best regards,
Doug Anderson May 31, 2023, 9:45 p.m. UTC | #3 
Hi,

On Wed, May 31, 2023 at 7:26 AM Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>
> On 31.05.2023 15:22, Konrad Dybcio wrote:
> > As pointed out in [1], the Linux implementation of RSC basically requires
> > (even if not explicitly) that we point it to a power domain which
> > represents the power state of the CPUs. In an effort to fulfill that
> > requirement, make it required in bindings and hook it up on all platforms
> > where I was able to do. This means all RPMh platforms, except
> >
> > - SC7180
> > - SC7280
> > - SA8775
> >
> > As there wasn't an idle-states setup (which may be on purpose for CrOS
> > devices, certainly not for Windows SC7[12]80s) that I could validate.
> > (Doug, Bartosz, could you guys look into your respective platforms of
> > interest here?)
> >
> > This series also adds support for idle states on SM6350, as I was able
> > to add and test that.
> I noticed that 7280 is WIP:
>
> https://lore.kernel.org/lkml/20230424110933.3908-4-quic_mkshah@quicinc.com/

Right. For sc7180 Chromebooks we don't use OSI (OS Initiated) mode but
instead use PC (Platform Coordinated) mode. As I understand it, that
means we take a different path through all this stuff.

That being said, in the sc7280 thread you pointed at, Bjorn and Ulf
said that we could use the new device tree snippets for sc7280 even
before the ATF update. If I'm reading the thread correctly and the
same applies to sc7180:

1. New DT plus firmware that doesn't support OSI - OK
2. New DT plus firmware that supports OSI - OK after code changes
3. Old DT plus firmware that doesn't support OSI - OK
4. Old DT plus firmware that supports OSI - Not OK

For sc7180 Chromebooks we'll never have firmware that supports OSI.
That means that, assuming I'm understanding correctly, we actually
could move the DT to represent things the new way. Presumably this
would be important for sc7180 devices that originally shipped with
Windows (I think support for one of these is underway).

-Doug
Konrad Dybcio June 1, 2023, 8:15 a.m. UTC | #4 
On 31.05.2023 23:45, Doug Anderson wrote:
> Hi,
> 
> On Wed, May 31, 2023 at 7:26 AM Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>
>> On 31.05.2023 15:22, Konrad Dybcio wrote:
>>> As pointed out in [1], the Linux implementation of RSC basically requires
>>> (even if not explicitly) that we point it to a power domain which
>>> represents the power state of the CPUs. In an effort to fulfill that
>>> requirement, make it required in bindings and hook it up on all platforms
>>> where I was able to do. This means all RPMh platforms, except
>>>
>>> - SC7180
>>> - SC7280
>>> - SA8775
>>>
>>> As there wasn't an idle-states setup (which may be on purpose for CrOS
>>> devices, certainly not for Windows SC7[12]80s) that I could validate.
>>> (Doug, Bartosz, could you guys look into your respective platforms of
>>> interest here?)
>>>
>>> This series also adds support for idle states on SM6350, as I was able
>>> to add and test that.
>> I noticed that 7280 is WIP:
>>
>> https://lore.kernel.org/lkml/20230424110933.3908-4-quic_mkshah@quicinc.com/
> 
> Right. For sc7180 Chromebooks we don't use OSI (OS Initiated) mode but
> instead use PC (Platform Coordinated) mode. As I understand it, that
> means we take a different path through all this stuff.
> 
> That being said, in the sc7280 thread you pointed at, Bjorn and Ulf
> said that we could use the new device tree snippets for sc7280 even
> before the ATF update. If I'm reading the thread correctly and the
> same applies to sc7180:
> 
> 1. New DT plus firmware that doesn't support OSI - OK
> 2. New DT plus firmware that supports OSI - OK after code changes
> 3. Old DT plus firmware that doesn't support OSI - OK
> 4. Old DT plus firmware that supports OSI - Not OK
> 
> For sc7180 Chromebooks we'll never have firmware that supports OSI.
> That means that, assuming I'm understanding correctly, we actually
> could move the DT to represent things the new way. Presumably this
> would be important for sc7180 devices that originally shipped with
> Windows (I think support for one of these is underway).
It's even merged now!

Yeah, AFAICT all you said makes sense

I don't however know how you tell RSC driver that your platform is
going to sleep when using PC mode..

KOnrad
> 
> -Doug
Bjorn Andersson June 13, 2023, 10:30 p.m. UTC | #5 
On Wed, 31 May 2023 15:22:34 +0200, Konrad Dybcio wrote:
> As pointed out in [1], the Linux implementation of RSC basically requires
> (even if not explicitly) that we point it to a power domain which
> represents the power state of the CPUs. In an effort to fulfill that
> requirement, make it required in bindings and hook it up on all platforms
> where I was able to do. This means all RPMh platforms, except
> 
> - SC7180
> - SC7280
> - SA8775
> 
> [...]

Applied, thanks!

[2/8] arm64: dts: qcom: sm6350: Add PSCI idle states
      commit: ade89bc08c8e7f52ee8a70d0c6ea55c2defdf1d3
[3/8] arm64: dts: qcom: qdu1000: Flush RSC sleep & wake votes
      commit: ab033e7846f91953244d0626b28ce66412b813b3
[4/8] arm64: dts: qcom: sc8180x: Flush RSC sleep & wake votes
      commit: 442d55d099ed72d96aee996e56f802b5cf885f39
[5/8] arm64: dts: qcom: sdm670: Flush RSC sleep & wake votes
      commit: 7b04cbd81b0e60c5151a310e7b730dc4a951a211
[6/8] arm64: dts: qcom: sdm845: Flush RSC sleep & wake votes
      commit: 91e83140b5dd5598fbcfada3ee1f8b2b410c3731
[7/8] arm64: dts: qcom: sm6350: Flush RSC sleep & wake votes
      commit: 255c53df8ec3ea9f00765eb3dac02ccb705704dd
[8/8] arm64: dts: qcom: sm8550: Flush RSC sleep & wake votes
      commit: 4b2c7ac8e469ab7f92e50c34ad4012a77e79d078

Best regards,