Hi Tony,
Am 03.09.2019 um 15:40 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190902 10:56]:
Matching the ti-cpufreq driver needs to specify explicitly if a board uses an omap34xx or omap36xx chip.
Signed-off-by: H. Nikolaus Schaller hns@goldelico.com
arch/arm/boot/dts/omap3-beagle.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts index e3df3c166902..d47213c7a4d0 100644 --- a/arch/arm/boot/dts/omap3-beagle.dts +++ b/arch/arm/boot/dts/omap3-beagle.dts @@ -8,7 +8,7 @@
/ { model = "TI OMAP3 BeagleBoard";
- compatible = "ti,omap3-beagle", "ti,omap3";
compatible = "ti,omap3-beagle", "ti,omap34xx", "ti,omap3";
cpus { cpu@0 {
For a clean-up patch, we should just use the following compatibles in general for omap3:
ti,omap3 omap3 ti,omap34 omap34xx and omap35xx ti,omap36 omap36xx and dm37xx ti,am35 am35xx
So we should just leave out the "xx" part. But we still need parse also the legacy binding with "xx" in drivers.
Yes, getting rid of the xx in the device trees would be nice.
But I have looked through the kernel tree and that makes more problems than it solves...
There is code that explicitly checks for "ti,omap36xx" in drivers/clk/ti/dpll.c
Maybe that should be replaced by a check for a "ti,dpll5" property which is only defined in omap36xx.dtsi to make the code depend on a feature rather than SoC family string. Although such a change may break other things or we have to keep even more legacy code around.
And there is a binding document omap.txt that does not describe it the way you propose. IMHO that should be changed first.
Next is that omap.txt explicitly says that ti,omap3 defauls to OMAP3430. And OMAP3430 should be specified as compatible = "ti,omap3430", "ti,omap3" while OMAP3630 should have compatible = "ti,omap36xx", "ti,omap3". AM3517 is compatible = "ti,am3517", "ti,omap3" which seems to ignore the AM3505 (maybe there was never a board using it).
So this clean up is much more than what we need for moving from opp-v1 to opp-v2 and it should therefore be addressed separately.
Therefore I'd prefer if we can keep all these problems isolated into a separate set of patches. And because of this I have prepared an RFC-V2 which only adds the "ti,omap3430" to those boards which do not yet have it (in accordance to existing omap.txt).
AM3517 does not seem to have any opp table and therefore I also exclude it at the moment.
BR and thanks, Nikolaus