| Message ID | 20130730131009.GA28162@radagast (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jul 30, 2013 at 04:10:09PM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: > > @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) > > # define soc_is_omap543x() is_omap543x() > > #endif > > > > +# if defined(CONFIG_SOC_DRA7XX) > > +# undef soc_is_dra7xx > > +# undef soc_is_dra75x > > +# define soc_is_dra7xx() is_dra7xx() > > +# define soc_is_dra75x() is_dra75x() > > since this platform is DT-only, couldn't we just believe DT-data to be > correct of_machine_is_compatible() ? 2/3 of this patch would be removed. s/correct of_/correct and use of_
* Felipe Balbi <balbi@ti.com> [130730 06:25]: > On Tue, Jul 30, 2013 at 04:10:09PM +0300, Felipe Balbi wrote: > > Hi, > > > > On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: > > > @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) > > > # define soc_is_omap543x() is_omap543x() > > > #endif > > > > > > +# if defined(CONFIG_SOC_DRA7XX) > > > +# undef soc_is_dra7xx > > > +# undef soc_is_dra75x > > > +# define soc_is_dra7xx() is_dra7xx() > > > +# define soc_is_dra75x() is_dra75x() > > > > since this platform is DT-only, couldn't we just believe DT-data to be > > correct of_machine_is_compatible() ? 2/3 of this patch would be removed. > > s/correct of_/correct and use of_ Makes sense to me. AFAIK we no longer need to initialize much anything super early. Regards, Tony
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: > Hi, > > On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: >> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) >> # define soc_is_omap543x() is_omap543x() >> #endif >> >> +# if defined(CONFIG_SOC_DRA7XX) >> +# undef soc_is_dra7xx >> +# undef soc_is_dra75x >> +# define soc_is_dra7xx() is_dra7xx() >> +# define soc_is_dra75x() is_dra75x() > since this platform is DT-only, couldn't we just believe DT-data to be > correct of_machine_is_compatible() ? 2/3 of this patch would be removed. > > I patched this for OMAP5 (compile-tested only, no boards available) and > came out with the patch below (still needs to be split): > > diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts > index 08b7267..b3136e5 100644 > --- a/arch/arm/boot/dts/omap5-uevm.dts > +++ b/arch/arm/boot/dts/omap5-uevm.dts > @@ -13,7 +13,7 @@ > > / { > model = "TI OMAP5 uEVM board"; > - compatible = "ti,omap5-uevm", "ti,omap5"; > + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; > ok, nice and simpler way. But would this make different revisions, to appear the same ? Regards, Sricharan > memory { > device_type = "memory"; > diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi > index 07be2cd..a7bc906 100644 > --- a/arch/arm/boot/dts/omap5.dtsi > +++ b/arch/arm/boot/dts/omap5.dtsi > @@ -17,7 +17,7 @@ > #address-cells = <1>; > #size-cells = <1>; > > - compatible = "ti,omap5"; > + compatible = "ti,omap5432-es2.0", "ti,omap5430-es2.0", "ti,omap5"; > interrupt-parent = <&gic>; > > aliases { > diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c > index 2dc62a2..ee94309 100644 > --- a/arch/arm/mach-omap2/id.c > +++ b/arch/arm/mach-omap2/id.c > @@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void) > pr_info("%s %s\n", soc_name, soc_rev); > } > > -void __init omap5xxx_check_revision(void) > -{ > - u32 idcode; > - u16 hawkeye; > - u8 rev; > - > - idcode = read_tap_reg(OMAP_TAP_IDCODE); > - hawkeye = (idcode >> 12) & 0xffff; > - rev = (idcode >> 28) & 0xff; > - switch (hawkeye) { > - case 0xb942: > - switch (rev) { > - case 0: > - omap_revision = OMAP5430_REV_ES1_0; > - break; > - case 1: > - default: > - omap_revision = OMAP5430_REV_ES2_0; > - } > - break; > - > - case 0xb998: > - switch (rev) { > - case 0: > - omap_revision = OMAP5432_REV_ES1_0; > - break; > - case 1: > - default: > - omap_revision = OMAP5432_REV_ES2_0; > - } > - break; > - > - default: > - /* Unknown default to latest silicon rev as default*/ > - omap_revision = OMAP5430_REV_ES2_0; > - } > - > - sprintf(soc_name, "OMAP%04x", omap_rev() >> 16); > - sprintf(soc_rev, "ES%d.0", (omap_rev() >> 12) & 0xf); > - > - pr_info("%s %s\n", soc_name, soc_rev); > -} > - > /* > * Set up things for map_io and processor detection later on. Gets called > * pretty much first thing from board init. For multi-omap, this gets > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c > index 4a3f06f..aa28940 100644 > --- a/arch/arm/mach-omap2/io.c > +++ b/arch/arm/mach-omap2/io.c > @@ -633,8 +633,7 @@ void __init omap4430_init_late(void) > #ifdef CONFIG_SOC_OMAP5 > void __init omap5_init_early(void) > { > - omap2_set_globals_tap(OMAP54XX_CLASS, > - OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE)); > + omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE)); > omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), > OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE)); > omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE)); > @@ -644,7 +643,6 @@ void __init omap5_init_early(void) > omap_prm_base_init(); > omap_cm_base_init(); > omap44xx_prm_init(); > - omap5xxx_check_revision(); > omap54xx_voltagedomains_init(); > omap54xx_powerdomains_init(); > omap54xx_clockdomains_init(); > diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h > index 8c616e4..b8339ad 100644 > --- a/arch/arm/mach-omap2/soc.h > +++ b/arch/arm/mach-omap2/soc.h > @@ -35,6 +35,7 @@ > #ifndef __ASSEMBLY__ > > #include <linux/bitops.h> > +#include <linux/of.h> > > /* > * Test if multicore OMAP support is needed > @@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24) > IS_OMAP_CLASS(34xx, 0x34) > IS_OMAP_CLASS(44xx, 0x44) > IS_AM_CLASS(35xx, 0x35) > -IS_OMAP_CLASS(54xx, 0x54) > IS_AM_CLASS(33xx, 0x33) > IS_AM_CLASS(43xx, 0x43) > > @@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363) > IS_OMAP_SUBCLASS(443x, 0x443) > IS_OMAP_SUBCLASS(446x, 0x446) > IS_OMAP_SUBCLASS(447x, 0x447) > -IS_OMAP_SUBCLASS(543x, 0x543) > > IS_TI_SUBCLASS(816x, 0x816) > IS_TI_SUBCLASS(814x, 0x814) > @@ -373,10 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430) > # endif > > # if defined(CONFIG_SOC_OMAP5) > -# undef soc_is_omap54xx > -# undef soc_is_omap543x > -# define soc_is_omap54xx() is_omap54xx() > -# define soc_is_omap543x() is_omap543x() > +# undef soc_is_omap54xx > +# undef soc_is_omap543x > +# define soc_is_omap54xx() (of_machine_is_compatible("ti,omap5")) > +# define soc_is_omap543x() (soc_is_omap54xx()) > #endif > > /* Various silicon revisions for omap2 */ > @@ -437,16 +436,9 @@ IS_OMAP_TYPE(3430, 0x3430) > #define OMAP447X_CLASS 0x44700044 > #define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 << 8)) > > -#define OMAP54XX_CLASS 0x54000054 > -#define OMAP5430_REV_ES1_0 (OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8)) > -#define OMAP5430_REV_ES2_0 (OMAP54XX_CLASS | (0x30 << 16) | (0x20 << 8)) > -#define OMAP5432_REV_ES1_0 (OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8)) > -#define OMAP5432_REV_ES2_0 (OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8)) > - > void omap2xxx_check_revision(void); > void omap3xxx_check_revision(void); > void omap4xxx_check_revision(void); > -void omap5xxx_check_revision(void); > void omap3xxx_check_features(void); > void ti81xx_check_features(void); > void am33xx_check_features(void); >
Hi, On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote: > On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: > > Hi, > > > > On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: > >> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) > >> # define soc_is_omap543x() is_omap543x() > >> #endif > >> > >> +# if defined(CONFIG_SOC_DRA7XX) > >> +# undef soc_is_dra7xx > >> +# undef soc_is_dra75x > >> +# define soc_is_dra7xx() is_dra7xx() > >> +# define soc_is_dra75x() is_dra75x() > > since this platform is DT-only, couldn't we just believe DT-data to be > > correct of_machine_is_compatible() ? 2/3 of this patch would be removed. > > > > I patched this for OMAP5 (compile-tested only, no boards available) and > > came out with the patch below (still needs to be split): > > > > diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts > > index 08b7267..b3136e5 100644 > > --- a/arch/arm/boot/dts/omap5-uevm.dts > > +++ b/arch/arm/boot/dts/omap5-uevm.dts > > @@ -13,7 +13,7 @@ > > > > / { > > model = "TI OMAP5 uEVM board"; > > - compatible = "ti,omap5-uevm", "ti,omap5"; > > + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; > > > ok, nice and simpler way. > But would this make different revisions, to appear the same ? well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, it should be treated as such, then you can pass a different string to that new board's compatible attribute.
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote: > Hi, > > On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote: >> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: >>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) >>>> # define soc_is_omap543x() is_omap543x() >>>> #endif >>>> >>>> +# if defined(CONFIG_SOC_DRA7XX) >>>> +# undef soc_is_dra7xx >>>> +# undef soc_is_dra75x >>>> +# define soc_is_dra7xx() is_dra7xx() >>>> +# define soc_is_dra75x() is_dra75x() >>> since this platform is DT-only, couldn't we just believe DT-data to be >>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed. >>> >>> I patched this for OMAP5 (compile-tested only, no boards available) and >>> came out with the patch below (still needs to be split): >>> >>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts >>> index 08b7267..b3136e5 100644 >>> --- a/arch/arm/boot/dts/omap5-uevm.dts >>> +++ b/arch/arm/boot/dts/omap5-uevm.dts >>> @@ -13,7 +13,7 @@ >>> >>> / { >>> model = "TI OMAP5 uEVM board"; >>> - compatible = "ti,omap5-uevm", "ti,omap5"; >>> + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; >>> >> ok, nice and simpler way. >> But would this make different revisions, to appear the same ? > well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, > it should be treated as such, then you can pass a different string to > that new board's compatible attribute. > Yes for OMAP5. I was thinking in general about this approach. For example, for OMAP4 we have same board and different revisions can be socketed there. For OMAP5, this is good. Regards, Sricharan
Hi, On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote: > On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote: > > Hi, > > > > On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote: > >> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: > >>> Hi, > >>> > >>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: > >>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) > >>>> # define soc_is_omap543x() is_omap543x() > >>>> #endif > >>>> > >>>> +# if defined(CONFIG_SOC_DRA7XX) > >>>> +# undef soc_is_dra7xx > >>>> +# undef soc_is_dra75x > >>>> +# define soc_is_dra7xx() is_dra7xx() > >>>> +# define soc_is_dra75x() is_dra75x() > >>> since this platform is DT-only, couldn't we just believe DT-data to be > >>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed. > >>> > >>> I patched this for OMAP5 (compile-tested only, no boards available) and > >>> came out with the patch below (still needs to be split): > >>> > >>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts > >>> index 08b7267..b3136e5 100644 > >>> --- a/arch/arm/boot/dts/omap5-uevm.dts > >>> +++ b/arch/arm/boot/dts/omap5-uevm.dts > >>> @@ -13,7 +13,7 @@ > >>> > >>> / { > >>> model = "TI OMAP5 uEVM board"; > >>> - compatible = "ti,omap5-uevm", "ti,omap5"; > >>> + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; > >>> > >> ok, nice and simpler way. > >> But would this make different revisions, to appear the same ? > > well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, > > it should be treated as such, then you can pass a different string to > > that new board's compatible attribute. > > > Yes for OMAP5. I was thinking in general about this approach. > For example, for OMAP4 we have same board and > different revisions can be socketed there. > > For OMAP5, this is good. do we really production socketed boards? Well, at least Blaze has such thing. But do we have too many differences that need to be trated at arch/arm or should/could those be handled by reading IP's revision register (e.g. usb host erratas)
Hi, On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote: > Hi, > > On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote: >> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote: >>>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: >>>>> Hi, >>>>> >>>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: >>>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) >>>>>> # define soc_is_omap543x() is_omap543x() >>>>>> #endif >>>>>> >>>>>> +# if defined(CONFIG_SOC_DRA7XX) >>>>>> +# undef soc_is_dra7xx >>>>>> +# undef soc_is_dra75x >>>>>> +# define soc_is_dra7xx() is_dra7xx() >>>>>> +# define soc_is_dra75x() is_dra75x() >>>>> since this platform is DT-only, couldn't we just believe DT-data to be >>>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed. >>>>> >>>>> I patched this for OMAP5 (compile-tested only, no boards available) and >>>>> came out with the patch below (still needs to be split): >>>>> >>>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts >>>>> index 08b7267..b3136e5 100644 >>>>> --- a/arch/arm/boot/dts/omap5-uevm.dts >>>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts >>>>> @@ -13,7 +13,7 @@ >>>>> >>>>> / { >>>>> model = "TI OMAP5 uEVM board"; >>>>> - compatible = "ti,omap5-uevm", "ti,omap5"; >>>>> + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; >>>>> >>>> ok, nice and simpler way. >>>> But would this make different revisions, to appear the same ? >>> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, >>> it should be treated as such, then you can pass a different string to >>> that new board's compatible attribute. >>> s >> Yes for OMAP5. I was thinking in general about this approach. >> For example, for OMAP4 we have same board and >> different revisions can be socketed there. >> >> For OMAP5, this is good. > do we really production socketed boards? Well, at least Blaze has such > thing. But do we have too many differences that need to be trated at > arch/arm or should/could those be handled by reading IP's revision > register (e.g. usb host erratas) > OMAP4 SDP is socketed as well. Ya, revision checks used only in few places and as you said we handle them using IP revisions, but that we have to look and clean up those places, if we really intend to do this for other socs. Regards, Sricharan
On 07/30/2013 01:37 PM, Sricharan R wrote: > Hi, > On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote: >> Hi, >> >> On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote: >>> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote: >>>> Hi, >>>> >>>> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote: >>>>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: >>>>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) >>>>>>> # define soc_is_omap543x() is_omap543x() >>>>>>> #endif >>>>>>> >>>>>>> +# if defined(CONFIG_SOC_DRA7XX) >>>>>>> +# undef soc_is_dra7xx >>>>>>> +# undef soc_is_dra75x >>>>>>> +# define soc_is_dra7xx() is_dra7xx() >>>>>>> +# define soc_is_dra75x() is_dra75x() >>>>>> since this platform is DT-only, couldn't we just believe DT-data to be >>>>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed. >>>>>> >>>>>> I patched this for OMAP5 (compile-tested only, no boards available) and >>>>>> came out with the patch below (still needs to be split): >>>>>> >>>>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts >>>>>> index 08b7267..b3136e5 100644 >>>>>> --- a/arch/arm/boot/dts/omap5-uevm.dts >>>>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts >>>>>> @@ -13,7 +13,7 @@ >>>>>> >>>>>> / { >>>>>> model = "TI OMAP5 uEVM board"; >>>>>> - compatible = "ti,omap5-uevm", "ti,omap5"; >>>>>> + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; >>>>>> >>>>> ok, nice and simpler way. >>>>> But would this make different revisions, to appear the same ? >>>> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, >>>> it should be treated as such, then you can pass a different string to >>>> that new board's compatible attribute. >>>> s >>> Yes for OMAP5. I was thinking in general about this approach. >>> For example, for OMAP4 we have same board and >>> different revisions can be socketed there. >>> >>> For OMAP5, this is good. >> do we really production socketed boards? Well, at least Blaze has such >> thing. But do we have too many differences that need to be trated at >> arch/arm or should/could those be handled by reading IP's revision >> register (e.g. usb host erratas) >> > OMAP4 SDP is socketed as well. a) OMAP4SDP is not production device b) OMAP4SDP uses SOM (System On Module) c) Socketted SOMs were used only during initial days of SoC d) almost all latest OMAP4 SDP switched to using soldered in SOM e) we claim compatibility of OMAP4 SDP with Blaze. So, I dont think this is a rational argument for keeping soc checks with dts. > Ya, revision checks used only in few places and as you said > we handle them using IP revisions, but that we have to look and clean > up those places, if we really intend to do this for other socs. I agree this is the right approach :).
On Wednesday 31 July 2013 12:13 AM, Nishanth Menon wrote: > On 07/30/2013 01:37 PM, Sricharan R wrote: >> Hi, >> On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote: >>> Hi, >>> >>> On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote: >>>> On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote: >>>>> Hi, >>>>> >>>>> On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote: >>>>>> On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: >>>>>>>> @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) >>>>>>>> # define soc_is_omap543x() is_omap543x() >>>>>>>> #endif >>>>>>>> >>>>>>>> +# if defined(CONFIG_SOC_DRA7XX) >>>>>>>> +# undef soc_is_dra7xx >>>>>>>> +# undef soc_is_dra75x >>>>>>>> +# define soc_is_dra7xx() is_dra7xx() >>>>>>>> +# define soc_is_dra75x() is_dra75x() >>>>>>> since this platform is DT-only, couldn't we just believe DT-data to be >>>>>>> correct of_machine_is_compatible() ? 2/3 of this patch would be removed. >>>>>>> >>>>>>> I patched this for OMAP5 (compile-tested only, no boards available) and >>>>>>> came out with the patch below (still needs to be split): >>>>>>> >>>>>>> diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts >>>>>>> index 08b7267..b3136e5 100644 >>>>>>> --- a/arch/arm/boot/dts/omap5-uevm.dts >>>>>>> +++ b/arch/arm/boot/dts/omap5-uevm.dts >>>>>>> @@ -13,7 +13,7 @@ >>>>>>> >>>>>>> / { >>>>>>> model = "TI OMAP5 uEVM board"; >>>>>>> - compatible = "ti,omap5-uevm", "ti,omap5"; >>>>>>> + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; >>>>>>> >>>>>> ok, nice and simpler way. >>>>>> But would this make different revisions, to appear the same ? >>>>> well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up, >>>>> it should be treated as such, then you can pass a different string to >>>>> that new board's compatible attribute. >>>>> s >>>> Yes for OMAP5. I was thinking in general about this approach. >>>> For example, for OMAP4 we have same board and >>>> different revisions can be socketed there. >>>> >>>> For OMAP5, this is good. >>> do we really production socketed boards? Well, at least Blaze has such >>> thing. But do we have too many differences that need to be trated at >>> arch/arm or should/could those be handled by reading IP's revision >>> register (e.g. usb host erratas) >>> >> OMAP4 SDP is socketed as well. > a) OMAP4SDP is not production device > b) OMAP4SDP uses SOM (System On Module) > c) Socketted SOMs were used only during initial days of SoC > d) almost all latest OMAP4 SDP switched to using soldered in SOM > e) we claim compatibility of OMAP4 SDP with Blaze. > > So, I dont think this is a rational argument for keeping soc checks with dts. What about OMAP4 pandas? I for instance, have an old 4430 panda and I have no idea if its a es2.1 or a es2.3 or something else. If we start relying on dt to pass the right revision check then (we need to create different dts files for these to begin with) I need to know exactly what silicon rev I am running on. I know its good to completely get rid of all silicon rev checks and depend on IP revisions but we have had various IPs which do not have proper rev checks. We have I guess most often used these to identify PRCM differences. Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board at this point for dra7xx, things would be fine even if we do a dt based parsing to identify the device, and I am fine with it if thats what we feel is the right way forward. For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks from the kernel and depending on DT parsing needs to be a separate series anyway and I dont plan to address those as part of this series. > >> Ya, revision checks used only in few places and as you said >> we handle them using IP revisions, but that we have to look and clean >> up those places, if we really intend to do this for other socs. > > I agree this is the right approach :). > >
* Rajendra Nayak <rnayak@ti.com> [130730 23:09]: > > Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board > at this point for dra7xx, things would be fine even if we do a dt based parsing to identify > the device, and I am fine with it if thats what we feel is the right way forward. > For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks > from the kernel and depending on DT parsing needs to be a separate series anyway and I dont > plan to address those as part of this series. Well I'd say there's no need to drop the hardware revision checks at this point at least for existing hardware. That's a very minimal piece of code and there are way bigger issues to tackle. For new SoCs, we could do it based on the compatible flag. If it helps booting newer hardware with older kernels, then that's a good reason to do it. Regards, Tony
On Wednesday 31 July 2013 12:12 PM, Tony Lindgren wrote: > * Rajendra Nayak <rnayak@ti.com> [130730 23:09]: >> >> Tony, what do you suggest we do for this series? Since we have just an es1.0 and one board >> at this point for dra7xx, things would be fine even if we do a dt based parsing to identify >> the device, and I am fine with it if thats what we feel is the right way forward. >> For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of these rev checks >> from the kernel and depending on DT parsing needs to be a separate series anyway and I dont >> plan to address those as part of this series. > > Well I'd say there's no need to drop the hardware revision checks > at this point at least for existing hardware. That's a very minimal > piece of code and there are way bigger issues to tackle. right, makes sense. > > For new SoCs, we could do it based on the compatible flag. If it > helps booting newer hardware with older kernels, then that's a good > reason to do it. Sure, we can have dra7xx use the compatible flag and not add all the rev checks. That said, I would be glad if the latest kernels at least boot on newer hardware let alone older kernels :) But I guess we have bigger issues to tackle before even that happens. Thanks for the quick response. regards, Rajendra > > Regards, > > Tony >
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts index 08b7267..b3136e5 100644 --- a/arch/arm/boot/dts/omap5-uevm.dts +++ b/arch/arm/boot/dts/omap5-uevm.dts @@ -13,7 +13,7 @@ / { model = "TI OMAP5 uEVM board"; - compatible = "ti,omap5-uevm", "ti,omap5"; + compatible = "ti,omap5-uevm", "ti,omap5432-es2.0", "ti,omap5"; memory { device_type = "memory"; diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 07be2cd..a7bc906 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -17,7 +17,7 @@ #address-cells = <1>; #size-cells = <1>; - compatible = "ti,omap5"; + compatible = "ti,omap5432-es2.0", "ti,omap5430-es2.0", "ti,omap5"; interrupt-parent = <&gic>; aliases { diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c index 2dc62a2..ee94309 100644 --- a/arch/arm/mach-omap2/id.c +++ b/arch/arm/mach-omap2/id.c @@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void) pr_info("%s %s\n", soc_name, soc_rev); } -void __init omap5xxx_check_revision(void) -{ - u32 idcode; - u16 hawkeye; - u8 rev; - - idcode = read_tap_reg(OMAP_TAP_IDCODE); - hawkeye = (idcode >> 12) & 0xffff; - rev = (idcode >> 28) & 0xff; - switch (hawkeye) { - case 0xb942: - switch (rev) { - case 0: - omap_revision = OMAP5430_REV_ES1_0; - break; - case 1: - default: - omap_revision = OMAP5430_REV_ES2_0; - } - break; - - case 0xb998: - switch (rev) { - case 0: - omap_revision = OMAP5432_REV_ES1_0; - break; - case 1: - default: - omap_revision = OMAP5432_REV_ES2_0; - } - break; - - default: - /* Unknown default to latest silicon rev as default*/ - omap_revision = OMAP5430_REV_ES2_0; - } - - sprintf(soc_name, "OMAP%04x", omap_rev() >> 16); - sprintf(soc_rev, "ES%d.0", (omap_rev() >> 12) & 0xf); - - pr_info("%s %s\n", soc_name, soc_rev); -} - /* * Set up things for map_io and processor detection later on. Gets called * pretty much first thing from board init. For multi-omap, this gets diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c index 4a3f06f..aa28940 100644 --- a/arch/arm/mach-omap2/io.c +++ b/arch/arm/mach-omap2/io.c @@ -633,8 +633,7 @@ void __init omap4430_init_late(void) #ifdef CONFIG_SOC_OMAP5 void __init omap5_init_early(void) { - omap2_set_globals_tap(OMAP54XX_CLASS, - OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE)); + omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE)); omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE), OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE)); omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE)); @@ -644,7 +643,6 @@ void __init omap5_init_early(void) omap_prm_base_init(); omap_cm_base_init(); omap44xx_prm_init(); - omap5xxx_check_revision(); omap54xx_voltagedomains_init(); omap54xx_powerdomains_init(); omap54xx_clockdomains_init(); diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h index 8c616e4..b8339ad 100644 --- a/arch/arm/mach-omap2/soc.h +++ b/arch/arm/mach-omap2/soc.h @@ -35,6 +35,7 @@ #ifndef __ASSEMBLY__ #include <linux/bitops.h> +#include <linux/of.h> /* * Test if multicore OMAP support is needed @@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24) IS_OMAP_CLASS(34xx, 0x34) IS_OMAP_CLASS(44xx, 0x44) IS_AM_CLASS(35xx, 0x35) -IS_OMAP_CLASS(54xx, 0x54) IS_AM_CLASS(33xx, 0x33) IS_AM_CLASS(43xx, 0x43) @@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363) IS_OMAP_SUBCLASS(443x, 0x443) IS_OMAP_SUBCLASS(446x, 0x446) IS_OMAP_SUBCLASS(447x, 0x447) -IS_OMAP_SUBCLASS(543x, 0x543) IS_TI_SUBCLASS(816x, 0x816) IS_TI_SUBCLASS(814x, 0x814) @@ -373,10 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430) # endif # if defined(CONFIG_SOC_OMAP5) -# undef soc_is_omap54xx -# undef soc_is_omap543x -# define soc_is_omap54xx() is_omap54xx() -# define soc_is_omap543x() is_omap543x() +# undef soc_is_omap54xx +# undef soc_is_omap543x +# define soc_is_omap54xx() (of_machine_is_compatible("ti,omap5")) +# define soc_is_omap543x() (soc_is_omap54xx()) #endif /* Various silicon revisions for omap2 */ @@ -437,16 +436,9 @@ IS_OMAP_TYPE(3430, 0x3430) #define OMAP447X_CLASS 0x44700044 #define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 << 8)) -#define OMAP54XX_CLASS 0x54000054 -#define OMAP5430_REV_ES1_0 (OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8)) -#define OMAP5430_REV_ES2_0 (OMAP54XX_CLASS | (0x30 << 16) | (0x20 << 8)) -#define OMAP5432_REV_ES1_0 (OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8)) -#define OMAP5432_REV_ES2_0 (OMAP54XX_CLASS | (0x32 << 16) | (0x20 << 8)) - void omap2xxx_check_revision(void); void omap3xxx_check_revision(void); void omap4xxx_check_revision(void); -void omap5xxx_check_revision(void); void omap3xxx_check_features(void); void ti81xx_check_features(void); void am33xx_check_features(void);