[PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings

[Rob Herring]

On Wed, May 13, 2015 at 7:32 PM, Michael Turquette
<mike.turquette at linaro.org> wrote:
> Quoting Mark Brown (2015-05-13 04:03:57)
>> On Wed, May 13, 2015 at 02:25:28PM +0530, Viresh Kumar wrote:
>> > On 12-05-15, 14:42, Michael Turquette wrote:
>> > > Quoting Viresh Kumar (2015-04-30 05:07:59)
>> >
>> > > Why should this new binding exist?
>>
>> > The answer to this particular query is perhaps simple, i.e. we have
>> > unsolved problems that we wanted to solve in a generic way.
>>
>> > But probably the bigger question is "Should we really put the OPPs
>> > (new or old bindings) in DT".
>>
>> And also is trying to do this in a completely generic manner the right
>> way of going about things - do we really understand the problem area
>> well enough to create a completely generic solution for all cases,
>> bearing in mind that once things go into a DT binding they become an ABI?
>
> No, we don't understand the problem space well enough to form an ABI.
> And even if we did understand it perfectly today, the constraints and
> expressions will change tomorrow.
>
> Putting this stuff in C without any philosophical constraints on whether
> or not we can change it later is the way to go.

Having a binding does not preclude you from doing your own thing in C.
You can choose to ignore it (or parts of it). It also doesn't mean you
have to use a generic driver with a generic binding.

While yes, we could do the same thing in C, the reality is that we
often don't force common data into common structures. This leads to
obfuscating what are the real h/w differences because everyone does
things their own way. Conveniently, struct dev_pm_opp is a perfect
example here. We already know that just freq and volt alone are not
enough, yet that is all the kernel structure has.

The way you avoid the ABI issue is you create a new one which is what
we've done here. I'm not saying we want 10 different OPP bindings. If
we are back here in a year with v3, then yes you are probably right.
But I believe v2 is a framework that can last. Most of the review
issues have resulted in simply dropping properties (until needed)
without otherwise changing the binding. I think that demonstrates this
bindiing is flexible and extendable.

Rob