On 19/05/2022 01:57, Stephen Boyd wrote: > Quoting Viresh Kumar (2022-05-10 22:06:43) >> On 10-05-22, 15:09, Krzysztof Kozlowski wrote: >>> On 10/05/2022 06:40, Viresh Kumar wrote: >>>> 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. > > I think for UFS they don't want a rate API at all. They want to set a > "clock gear" and that translates into whatever that means for OPP; be it > a clk frequency (or two), an interconnect bandwidth (or multiple?), and some > performance state (or many) for any power domains. I think the gear > design is built into the UFS spec. If it isn't then I'm misremembering > things. Yes, true. The clock frequencies are still changed with each gear, but in general the UFS indeed operates on gear concept. Best regards, Krzysztof
