[PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
t-kristo at ti.com
Sat Oct 12 06:25:47 EDT 2013
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
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.
> 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
More information about the linux-arm-kernel