[PATCHv7 00/36] ARM: OMAP: clock data conversion to DT

[Tero Kristo]

On 10/12/2013 01:37 AM, Paul Walmsley wrote:
> On Fri, 11 Oct 2013, Tero Kristo wrote:
>
>> Oh yea, one additional note you probably have missed. Mike asked us to fall
>> back to vendor specific bindings at around v6 or so of this set. Take a look
>> at v8, we have dropped the use of generic bindings, we are not trying to
>> declare those with this set.
>
> No, I didn't miss it.
>
>> This set introduces vendor specific bindings only, and even these are
>> claimed 'unstable', which should be enough to discourage people from
>> burning those to OTP type memory.
>
> Better to just avoid merging unstable bindings in the first place.
>
> Please keep this in mind: any change that anyone makes to the DT data
> needs to be supportable by the kernel into the indefinite future, once it
> makes it into arch/arm/boot/dts or the DT binding documentation.  Also,
> any changes need to work for other OSes, i.e., the changes should not be
> Linux-specific.

As pointed out earlier, the unstable claim just points to the fact that 
we might have some generic clock bindings in distant future at which 
point we _might_ evolve that way. Personally I have no problems carrying 
these binding to the far future, as they are vendor specific, and pretty 
much also device specific (am3-dpll-* omap4-dpll-* etc.)

Later on, we can add also support for clock firmware or whatever if we 
want to optimize stuff.

If we do not merge the bindings now, what is your proposal then? We have 
a couple of new SoC:s in queue and getting them boot mainline currently 
we only have this option to get them to work. Hardware is not going to 
wait for two years so we can have generic clock bindings in place. I 
would rather have this resolved as soon as possible, and it would have 
been much better if you came forward with your claims at version 1 or 2 
of this set, rather than at v8 and saying all should be forfeit.

-Tero

>
> Those have been stated goals for the Linux DT project since day one.
> Some folks haven't been monitoring those goals very closely and that's
> unfortunate.  We could have avoided some pretty big messes.
>
>
> - Paul
>