On 19-05-22, 17:59, Stephen Boyd wrote: > This is a general problem with OPP. It is single clk frequency centric, > which works well for CPU/GPU devices that work with cpufreq/devfreq. > When it comes to other devices though we have to fit OPP into what those > devices want, which is something like gears for UFS, or "4k@60" (a > resolution) for display hardware. > > Would adding string labels and/or using an index based API work better > for these devices? I think we'd want to extend OPP for display devices > to have whatever set of use-cases the device driver wants to handle with > string labels. That naturally follows how some SoC manufacturers setup > their OPP tables anyway. They may want to bump only the bus bandwidth > for different display resolutions while maxing out the clk frequency. > Then we could let drivers either construct a string at probe time to get > a handle to those OPP entries or index directly. The frequency APIs > would stick around for OPP tables that have frequencies and for drivers > that want to do cpufreq/devfreq stuff. > > UFS may want to use an index based API that matches the gears per the > spec. I think it could do that with dev_pm_opp_find_level_exact(), > right? I think we can use "level" for all these use cases to find the OPP, if it aligns well with the requirements of all these frameworks. FWIW, we already have three ways to find the OPP currently, via frequency, level and bandwidth. > Then the primary problem is the subject of this patch, > controlling multiple clks per OPP table. Could that be done by linking > one OPP table (for the gears) to an OPP table for each clk? Maybe > through 'required-opps'? Even in that case we will have an OPP table which will have multiple clocks. So it may not matter much which OPP table contains all the clocks. -- viresh
