lkml.org 
[lkml]   [2022]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v2 4/6] PM: opp: allow control of multiple clocks
On 10-05-22, 15:09, Krzysztof Kozlowski wrote:
> On 10/05/2022 06:40, Viresh Kumar wrote:
> > They shouldn't reach the OPP core then. What will the OPP core do if a
> > clock has a value for one OPP and not the other ?
>
> That would be the same mistake as providing one voltage as 0 or with
> something outside of a spec (but still within regulators min/max).
> Mistakes in DTS create undesirable behavior and this part is no different.

Right, I agree and so it shouldn't be allowed in principle.

> However I understand your point - since the driver provides the list of
> clocks to OPP, it should not provide ones which are irrelevant.

Right.

> > IMHO, this is broken by design. I can easily see that someone wants to
> > have few variants of all other frequencies for the same frequency of
> > the so called "main" clock, i.e. multiple OPPs with same "main" freq
> > value. I don't think we can mark the clocks "main" or otherwise as
> > easily for every platform.
> >
> > Stephen, any inputs on this ?
>
> In such case, matching opps by frequency would be a quite different API.
> The drivers can use now:
> https://github.com/krzk/linux/commit/ebc31798494fcc66389ae409dce6d9489c16156a#diff-b6370444c32afa2e55d9b6150f355ba6f4d20c5ed5da5399ea8295d323de8267R1200
>
> If you assume that this frequency can be used for multiple OPPs, then
> the API should be different. Something like:
> int dev_pm_opp_set_rate(struct device *dev, unsigned long *target_freqs,
> size_t num_freqs);

At this point I am not looking for a new API, but just continuing the discussion
to understand what different hardwares want or look like.

> Finding right opp for given frequencies would be also quite much more
> complicated task. Not a simple ceil/floor search by one frequency.

Right.

> I don't need that use-case and my implementation does not prevent anyone
> from implementing it in the future. IOW, why developing now complex
> solution which no one currently needs? If anyone needs such scaling by
> multiple-frequencies, the PM OPP can be reworked/extended/improved again.

It isn't about being complex or simple for me, but the design needs to be
robust. Either we can have a guaranteed "main" frequency or not and that would
decide how we need to proceed here.

--
viresh

\
 
 \ /
  Last update: 2022-05-11 07:07    [W:0.265 / U:0.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site