| Message ID | 20230531-topic-rsc-v1-0-b4a985f57b8b@linaro.org |
|---|---|
| Headers | show |
| Series | Flush RSC votes properly on more RPMh platforms | expand |
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
On 31/05/2023 15:22, Konrad Dybcio wrote: > The Linux RPMh implementation refrains from sending some RPMh votes until > the system is about to enter suspend (which is indicated by all CPU cores > entering a low-power state). Lack of the power-domains property will make > it such that these votes are never sent. > > Require the power-domains property as discussed in [1]. > > [1] https://lore.kernel.org/linux-arm-msm/20230512150425.3171122-1-quic_bjorande@quicinc.com/ > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
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
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,
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,