[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e98a2901-7ad4-5a1f-5739-64750836d396@linaro.org>
Date: Thu, 1 Jun 2023 10:15:13 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Melody Olvera <quic_molvera@...cinc.com>,
Vinod Koul <vkoul@...nel.org>,
Richard Acayan <mailingradian@...il.com>,
Lina Iyer <ilina@...eaurora.org>,
Neil Armstrong <neil.armstrong@...aro.org>,
Abel Vesa <abel.vesa@...aro.org>,
Sai Prakash Ranjan <quic_saipraka@...cinc.com>,
Marijn Suijten <marijn.suijten@...ainline.org>,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Luca Weiss <luca.weiss@...rphone.com>,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Andy Gross <andy.gross@...aro.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Maulik Shah <quic_mkshah@...cinc.com>,
Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH 0/8] Flush RSC votes properly on more RPMh platforms
On 31.05.2023 23:45, Doug Anderson wrote:
> Hi,
>
> On Wed, May 31, 2023 at 7:26 AM Konrad Dybcio <konrad.dybcio@...aro.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
Powered by blists - more mailing lists