Re: [PATCH 3/4] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap3630 or ti,am3517

2019-09-09 Thread Adam Ford
On Sat, Sep 7, 2019 at 12:47 PM H. Nikolaus Schaller wrote: > > For the ti-cpufreq driver we need a clear separation between omap34 and > omap36 families > since they have different silicon revisions and efuses. > > So far ti,omap3630/ti,omap36xx is just an additional flag to ti,omap3 while >

[PATCH 3/4] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap3630 or ti,am3517

2019-09-07 Thread H. Nikolaus Schaller
For the ti-cpufreq driver we need a clear separation between omap34 and omap36 families since they have different silicon revisions and efuses. So far ti,omap3630/ti,omap36xx is just an additional flag to ti,omap3 while omap34 has no required entry. Therefore we can not match omap34 boards

Re: [PATCH 3/4] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap3630 or ti,am3517

2019-09-07 Thread Tony Lindgren
* H. Nikolaus Schaller [190907 06:57]: > For the ti-cpufreq driver we need a clear separation between omap34 and > omap36 families > since they have different silicon revisions and efuses. > > So far ti,omap3630/ti,omap36xx is just an additional flag to ti,omap3 while > omap34 has no >

[PATCH 3/4] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap3630 or ti,am3517

2019-09-07 Thread H. Nikolaus Schaller
For the ti-cpufreq driver we need a clear separation between omap34 and omap36 families since they have different silicon revisions and efuses. So far ti,omap3630/ti,omap36xx is just an additional flag to ti,omap3 while omap34 has no required entry. Therefore we can not match omap34 boards