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
