[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220706063946.pmtkwiyfzxx5ka7h@vireshk-i7>
Date: Wed, 6 Jul 2022 12:09:46 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>, linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Dmitry Osipenko <dmitry.osipenko@...labora.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 09/13] OPP: Assert clk_count == 1 for single clk
helpers
On 05-07-22, 19:21, Krzysztof Kozlowski wrote:
> Where is the safety problem with multiple-clocks case?
All these APIs, which I have added the assert to now, are designed
with a single clk/freq in mind. They simply take a clock frequency
value as input and do something based on it. It only works fine with
single clk case, as more information is required for multiple clock
case, a freq value isn't sufficient here. In order to avoid abuse or
accidental use of the wrong API, these WARNs were required.
> And how users of PM OPP API are supposed to iterate/find OPPs they
> want if the API now throws WARN?
We need to provide new APIs for that, as I mentioned in the cover
letter and the other mail I sent you yesterday.
Specifically, if we want to have OPP finder API based on freq value,
then it needs to either have index + freq as input, or an array of
frequencies (one for each clk) as input.
Though I am not sure what you would need at the moment, as you can
also use opp-level for OPPs as they match UFS gears, that was my
understanding from earlier discussion.
--
viresh
Powered by blists - more mailing lists