Messages in this thread | | | From | Ulf Hansson <> | Date | Tue, 28 Nov 2017 17:38:52 +0100 | Subject | Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values |
| |
On 2 November 2017 at 10:00, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 02-11-17, 00:15, Stephen Boyd wrote: >> Sorry I'm not following. We're going to need to have platform >> specific code that understands platform specific bindings that >> aren't shoved into the generic OPP bindings. > > At least I am not targeting any platform specific binding right now. > The way I see this to work is: > > - We will reuse earlier bindings and allow opp-hz and opp-microvolt to > contain special values (this patch). > - Platform specific DT entries will put corner numbers in opp-hz (or > opp-microvolt) fields. > - Some platform specific driver (in OPP or genpd) will be used to > convert OPP into a performance state (corner) value. Now that can > simply read opp-hz (or opp-microvolt) and return its value.
Since the "operating-points-v2" phandle(s) belongs in the power-domain controller device node, which anyway is being parsed by the genpd SoC specific driver, I assume it makes sense to start the initialization from there. Unless there is something that prevents that, of course.
Then whatever library/helper functions we need for parse and create the OPP tables, can be provided to the OPP framework and the OPP OF library.
> - OPP core will request for a performance state (code is already > merged for that). > > And so there is no platform specific binding here. Do you want to do > this differently ?
This makes sense to me!
Also, the SoC (QCOM) specific genpd driver is free to use the terminology "corner values", when it translates opp-hz|microvolt into such values.
Kind regards Uffe
| |