On 31/05/2022 12:30, Viresh Kumar wrote: > On 19-05-22, 10:03, Krzysztof Kozlowski wrote: >> Yes, true. The clock frequencies are still changed with each gear, but >> in general the UFS indeed operates on gear concept. > > Hi Krzysztof, > > I have redesigned the OPP core a bit (two patchsets until now) to make > it easier to add multiple clock support going forward. I need some > inputs from you before moving forward with it now. Will this work for > your use case: > > - Add support for multiple clocks, where none of them is primary. > > - Which means you won't be able to use dev_pm_opp_set_rate() but will > need something like dev_pm_opp_set_level(), will add it. > > - That is, your OPP table will need to implement levels (I think of > them as UFS gears) and then call dev_pm_opp_set_level() instead. > > - This new API will work just like dev_pm_opp_set_rate(), except that > it will find the target OPP based on level instead of freq and > support configuration of multiple clock frequencies. > > - Of course both these APIs will share most of the code. Hi Viresh, In general this looks reasonable and matches how the UFS gears should be modeled. It does not match how UFS drivers implemented the clock scaling, but that's the internal problem of UFS drivers. They scale the clocks only max or min, even though there are multiple gears in between. The new approach looks therefore appropriate. Best regards, Krzysztof
