[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <278f3baa-a760-18cf-1a43-2814793af987@linaro.org>
Date: Thu, 15 Jun 2023 19:37:21 +0200
From: Konrad Dybcio <konrad.dybcio@...aro.org>
To: Stephen Boyd <sboyd@...nel.org>, Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Evan Green <evgreen@...omium.org>,
Georgi Djakov <djakov@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Leo Yan <leo.yan@...aro.org>,
Michael Turquette <mturquette@...libre.com>,
Rob Herring <robh+dt@...nel.org>
Cc: Marijn Suijten <marijn.suijten@...ainline.org>,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-clk@...r.kernel.org, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Stephan Gerhold <stephan@...hold.net>
Subject: Re: [PATCH v6 00/22] Restructure RPM SMD ICC
On 15.06.2023 19:35, Stephen Boyd wrote:
> Quoting Konrad Dybcio (2023-06-15 00:52:07)
>> On 15.06.2023 02:49, Stephen Boyd wrote:
>>> Quoting Konrad Dybcio (2023-06-14 11:04:19)
>>>> This series reshuffles things around, moving the management of SMD RPM
>>>> bus clocks to the interconnect framework where they belong. This helps
>>>> us solve a couple of issues:
>>>>
>>>> 1. We can work towards unused clk cleanup of RPMCC without worrying
>>>> about it killing some NoC bus, resulting in the SoC dying.
>>>> Deasserting actually unused RPM clocks (among other things) will
>>>> let us achieve "true SoC-wide power collapse states", also known as
>>>> VDD_LOW and VDD_MIN.
>>>>
>>>> 2. We no longer have to keep tons of quirky bus clock ifs in the icc
>>>> driver. You either have a RPM clock and call "rpm set rate" or you
>>>> have a single non-RPM clock (like AHB_CLK_SRC) or you don't have any.
>>>>
>>>> 3. There's less overhead - instead of going through layers and layers of
>>>> the CCF, ratesetting comes down to calling max() and sending a single
>>>> RPM message. ICC is very very dynamic so that's a big plus.
>>>>
>>>> The clocks still need to be vaguely described in the clk-smd-rpm driver,
>>>> as it gives them an initial kickoff, before actually telling RPM to
>>>> enable DVFS scaling. After RPM receives that command, all clocks that
>>>> have not been assigned a rate are considered unused and are shut down
>>>> in hardware, leading to the same issue as described in point 1.
>>>
>>> Why can't we move the enable of DVFS scaling call to the interconnect
>>> driver as well? We want the clk driver to not reference the interconnect
>>> resources at all.
>> That would result in no rpmcc ratesetting on platforms without a functional
>> interconnect driver. The DVFS call concerns both bus and !bus clocks.
>>
>
> That's the intent. Probe the interconnect driver to get bus clk rate
> setting.
>
> What are the !bus clocks managed by RPM?
Depending on the platform, that includes IPA, GPU, OCMEM, RF.. everything
that's not been separated out in patch 18.
Konrad
Powered by blists - more mailing lists