Hi Tony,
> Am 03.09.2019 um 15:40 schrieb Tony Lindgren <tony@xxxxxxxxxxx>:
>
> * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [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@xxxxxxxxxxxxx>
>> ---
>> 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
