Messages in this thread | | | Date | Tue, 5 Jul 2022 12:29:40 +0530 | From | Viresh Kumar <> | Subject | Re: [PATCH 5/8] OPP: Allow multiple clocks for a device |
| |
On 30-06-22, 14:39, Krzysztof Kozlowski wrote: > On 30/06/2022 14:32, Krzysztof Kozlowski wrote: > > On 10/06/2022 10:20, Viresh Kumar wrote: > >> + ret = _read_rate(new_opp, opp_table, np); > >> + if (ret) > >> + return ret; > >> + else if (opp_table->clk_count == 1) > > > > Shouldn't this be >=1? I got several clocks and this one fails. > > Actually this might be correct, but you need to update the bindings. Now > you require opp-level for case with multiple clocks.
I have thought about this again and adding such "fake" property in DT doesn't look right, specially in binding document. It maybe fine to have a "level" property in your case of UFS, where we want something to represent gears. But others may not want it.
So, in the new version I am sending now, we still consider opp-hz property as the property that uniquely identifies an OPP. Just that we compare all the rates now, and not just the first one. I have updated _opp_compare_keys() for this as well.
The drivers, for multiple clock case, are expected to call dev_pm_opp_set_opp() to set the specific OPP. Though how they find the target OPP is left for the users to handle. For some, we may have another unique OPP property, like level, which can be used to find the OPP. While in case of others, we may want to implement freq-based OPP finder APIs for multiple clock rates. I have decided not to implement them in advance, and add them only someone wants to use them.
-- viresh
| |