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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux