[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240904064004.7hwfom4nrqzfkvlo@vireshk-i7>
Date: Wed, 4 Sep 2024 12:10:04 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>,
Dikshita Agarwal <quic_dikshita@...cinc.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <quic_kdybcio@...cinc.com>,
Nikunj Kela <nkela@...cinc.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Thierry Reding <thierry.reding@...il.com>,
Mikko Perttunen <mperttunen@...dia.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Stephan Gerhold <stephan@...hold.net>,
Ilia Lin <ilia.lin@...nel.org>,
Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
Vikash Garodia <quic_vgarodia@...cinc.com>,
linux-pm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] OPP/pmdomain: Fix the assignment of the required-devs
On 03-09-24, 13:43, Ulf Hansson wrote:
> On Tue, 3 Sept 2024 at 12:53, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> > On 03-09-24, 11:54, Ulf Hansson wrote:
> > > In the current code, genpd_find_opp_table() tries to find an OPP table
> > > for the genpd that the device is getting attached to. Then genpd
> > > passes that OPP table via devm_pm_opp_set_config(), to let the OPP
> > > core to hook up a required-dev for it. This was a naive approach, as
> > > that OPP table may not be the one that actually corresponds to a
> > > required-opps for the required-dev. Consider the below in DT.
> > >
> > > opp_table_devA: opp-table-devA {
> > > compatible = "operating-points-v2";
> > >
> > > opp-devA-50 {
> > > opp-hz = /bits/ 64 <2500>;
> > > required-opps = <&opp_pd_50>; //corresponds to
> > > pd_perf1's OPP table
> > > };
> > > ....
> > >
> > > devA {
> > > compatible = "foo,bar";
> > > power-domains = <&pd_perf0>, <&pd_perf1>; //both
> > > pd_perf0 and pd_perf1 has OPP tables.
> > > power-domain-names = "perf0", "perf1";
> > > operating-points-v2 = <&opp_table_devA>;
> > > };
> >
> > I think another way forward would be to send an index along with
> > required-dev information (now that you do it one by one). That index
> > would be the index of the genpd in the genpd-list for the device. That
> > would make it work, isn't it ?
>
> I am not sure how that index will be much helpful, but maybe I am not
> fully understanding what you propose.
>
> Please note that the index of the power-domain doesn't need to match
> the index of the required-opps.
Yeah, I missed that, it doesn't happen via DT but by platform code. I
do see problems where situation would be a bit ambiguous. Your example
with a minor change to your code:
opp_table_devA: opp-table-devA {
compatible = "operating-points-v2";
opp-devA-50 {
opp-hz = /bits/ 64 <2500>;
required-opps = <&opp_pd_50, &opp_pd_51>; //corresponds to pd_perf1 and pd_perf0 (in reverse order)
};
....
devA {
compatible = "foo,bar";
power-domains = <&pd_perf0>, <&pd_perf1>; //both
pd_perf0 and pd_perf1 has OPP tables.
power-domain-names = "perf0", "perf1";
operating-points-v2 = <&opp_table_devA>;
};
Here, I don't think there is a way for us to know which genpd does
opp_pd_50 belongs to and to which one opp_pd_51 does.
We solve this by sending clock_names and regulator_names in OPP
config structure. That gives the ordering in which required_opps are
present. The same needs to be done for genpd, and then genpd core
would be able to attach the right genpd with right required opp.
--
viresh
Powered by blists - more mailing lists