[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa54a097-7edd-89af-6233-1e71c131668c@gmail.com>
Date: Thu, 24 Dec 2020 15:14:01 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
Mark Brown <broonie@...nel.org>,
Liam Girdwood <lgirdwood@...il.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Peter Geis <pgwipeout@...il.com>,
Nicolas Chauvet <kwizart@...il.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Kevin Hilman <khilman@...nel.org>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Viresh Kumar <vireshk@...nel.org>,
Stephen Boyd <sboyd@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-media@...r.kernel.org, linux-tegra@...r.kernel.org,
linux-clk@...r.kernel.org
Subject: Re: [PATCH v2 19/48] opp: Fix adding OPP entries in a wrong order if
rate is unavailable
24.12.2020 09:28, Viresh Kumar пишет:
> On 23-12-20, 23:36, Dmitry Osipenko wrote:
>> 23.12.2020 07:34, Viresh Kumar пишет:
>>> On 22-12-20, 22:19, Dmitry Osipenko wrote:
>>>> 22.12.2020 12:12, Viresh Kumar пишет:
>>>>> rate will be 0 for both the OPPs here if rate_not_available is true and so this
>>>>> change shouldn't be required.
>>>>
>>>> The rate_not_available is negated in the condition. This change is
>>>> required because both rates are 0 and then we should proceed to the
>>>> levels comparison.
>>>
>>> Won't that happen without this patch ?
>>
>> No
>
> This is how the code looks like currently:
>
> int _opp_compare_key(struct dev_pm_opp *opp1, struct dev_pm_opp *opp2)
> {
> if (opp1->rate != opp2->rate)
> return opp1->rate < opp2->rate ? -1 : 1;
> if (opp1->bandwidth && opp2->bandwidth &&
> opp1->bandwidth[0].peak != opp2->bandwidth[0].peak)
> return opp1->bandwidth[0].peak < opp2->bandwidth[0].peak ? -1 : 1;
> if (opp1->level != opp2->level)
> return opp1->level < opp2->level ? -1 : 1;
> return 0;
> }
>
> Lets consider the case you are focussing on, where rate is 0 for both the OPPs,
> bandwidth isn't there and we want to run the level comparison here.
>
> Since both the rates are 0, (opp1->rate != opp2->rate) will fail and so we will
> move to bandwidth check which will fail too. And so we will get to the level
> comparison.
>
> What am I missing here ? I am sure there is something for sure as you won't have
> missed this..
>
Ah, you're right. It was me who was missing something as I see now,
after taking a closer look and trying to implement yours suggestion, my
bad. I'll improve this patch in the next revision, thanks!
Powered by blists - more mailing lists