| Message ID | 1314897912-18178-3-git-send-email-b-cousson@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote: > > /* > + * XXX: The cpus node is mandatory, but since the CPUs are as well part > + * of the mpu subsystem below, it is not clear where the information > + * should be. Maybe here with a phandle inside the mpu? > + */ > + cpus { > + }; > + > + /* > * The soc node represents the soc top level view. It is uses for IPs > * that are not memory mapped in the MPU view or for the MPU itself. > */ > soc { > compatible = "ti,omap-infra"; > + mpu { > + compatible = "ti,omap3-mpu"; > + hwmods = "mpu"; > + cpu@0 { > + compatible = "arm,cortex-a8"; > + }; > + }; > + I would always put the cpu nodes in the top-level, even if that's a slight misrepresentation of the truth. The point is basically that CPU nodes are special (you cannot have device drivers for them) and that the device tree is basically laid out from the perspective of the CPU, which may be different from the perspective that a hardware designer has. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, On 9/1/2011 8:17 PM, Arnd Bergmann wrote: > On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote: >> >> /* >> + * XXX: The cpus node is mandatory, but since the CPUs are as well part >> + * of the mpu subsystem below, it is not clear where the information >> + * should be. Maybe here with a phandle inside the mpu? >> + */ >> + cpus { >> + }; >> + >> + /* >> * The soc node represents the soc top level view. It is uses for IPs >> * that are not memory mapped in the MPU view or for the MPU itself. >> */ >> soc { >> compatible = "ti,omap-infra"; >> + mpu { >> + compatible = "ti,omap3-mpu"; >> + hwmods = "mpu"; >> + cpu@0 { >> + compatible = "arm,cortex-a8"; >> + }; >> + }; >> + > > I would always put the cpu nodes in the top-level, even if that's > a slight misrepresentation of the truth. The point is basically > that CPU nodes are special (you cannot have device drivers for them) > and that the device tree is basically laid out from the perspective > of the CPU, which may be different from the perspective that a > hardware designer has. Yeah, I saw that in the "cpus" node documentation. My point here is that I do need to represent the MPU subsystem that will contain the cpus. And thus the Cortex is inside the MPU subsystem. I can potentially keep the CPUs inside the cpus node, and just represent the mpu node inside the soc, with potentially some phandle to the real cpu nodes. Something like that: cpus { cpu0: cpu@0 { compatible = "arm,cortex-a8"; }; }; [...] soc { compatible = "ti,omap-infra"; mpu { compatible = "ti,omap3-mpu"; hwmods = "mpu"; cpu@0 { phandle = <&cpu0>; [...] }; }; }; Does that look better? Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday 05 September 2011, Cousson, Benoit wrote: > Yeah, I saw that in the "cpus" node documentation. My point here is that > I do need to represent the MPU subsystem that will contain the cpus. And > thus the Cortex is inside the MPU subsystem. > > I can potentially keep the CPUs inside the cpus node, and just represent > the mpu node inside the soc, with potentially some phandle to the real > cpu nodes. > > Something like that: > > cpus { > cpu0: cpu@0 { > compatible = "arm,cortex-a8"; > }; > }; > > [...] > > soc { > compatible = "ti,omap-infra"; > mpu { > compatible = "ti,omap3-mpu"; > hwmods = "mpu"; > cpu@0 { > phandle = <&cpu0>; > [...] > }; > }; > }; Yes, that looks good. I wouldn't name the attribute "phandle" if I could think of anything better (which I can't at the moment). Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/5/2011 7:23 AM, Arnd Bergmann wrote: > On Monday 05 September 2011, Cousson, Benoit wrote: >> Yeah, I saw that in the "cpus" node documentation. My point here is that >> I do need to represent the MPU subsystem that will contain the cpus. And >> thus the Cortex is inside the MPU subsystem. The device tree hierarchy does not represent "containment", but rather addressing from the standpoint of a program running on a CPU. From that viewpoint, it might be better to have a phandle reference to the mpu in each CPU node. >> >> I can potentially keep the CPUs inside the cpus node, and just represent >> the mpu node inside the soc, with potentially some phandle to the real >> cpu nodes. >> >> Something like that: >> >> cpus { >> cpu0: cpu@0 { >> compatible = "arm,cortex-a8"; >> }; >> }; >> >> [...] >> >> soc { >> compatible = "ti,omap-infra"; >> mpu { >> compatible = "ti,omap3-mpu"; >> hwmods = "mpu"; >> cpu@0 { >> phandle =<&cpu0>; >> [...] >> }; >> }; >> }; > > Yes, that looks good. I wouldn't name the attribute "phandle" if I could > think of anything better (which I can't at the moment). > > Arnd > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/devicetree-discuss > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 9/5/2011 7:46 PM, Mitch Bradley wrote: > On 9/5/2011 7:23 AM, Arnd Bergmann wrote: >> On Monday 05 September 2011, Cousson, Benoit wrote: >>> Yeah, I saw that in the "cpus" node documentation. My point here is that >>> I do need to represent the MPU subsystem that will contain the cpus. And >>> thus the Cortex is inside the MPU subsystem. > > > The device tree hierarchy does not represent "containment", but rather > addressing from the standpoint of a program running on a CPU. > > From that viewpoint, it might be better to have a phandle reference to > the mpu in each CPU node. So in that case, I'd rather use a scheme similar to a shared cache between CPUs: cpus { cpu@0 { compatible = "arm,cortex-a8"; subsystem = <&mpu> mpu: arm_mpu { compatible = "ti,omap3-mpu"; hwmods = "mpu"; }; }; And for an OMAP4 SMP system: cpus { cpu@0 { compatible = "arm,cortex-a9"; subsystem = <&mpu> mpu: arm_mpu { compatible = "ti,omap4-mpu"; hwmods = "mpu"; }; cpu@1 { compatible = "arm,cortex-a9"; subsystem = <&mpu> }; }; Ideally the interrupt-controller/GIC should probably be inside that MPU node, isn't it? Thanks, Benoit > >>> >>> I can potentially keep the CPUs inside the cpus node, and just represent >>> the mpu node inside the soc, with potentially some phandle to the real >>> cpu nodes. >>> >>> Something like that: >>> >>> cpus { >>> cpu0: cpu@0 { >>> compatible = "arm,cortex-a8"; >>> }; >>> }; >>> >>> [...] >>> >>> soc { >>> compatible = "ti,omap-infra"; >>> mpu { >>> compatible = "ti,omap3-mpu"; >>> hwmods = "mpu"; >>> cpu@0 { >>> phandle =<&cpu0>; >>> [...] >>> }; >>> }; >>> }; >> >> Yes, that looks good. I wouldn't name the attribute "phandle" if I could >> think of anything better (which I can't at the moment). >> >> Arnd >> _______________________________________________ >> devicetree-discuss mailing list >> devicetree-discuss@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/devicetree-discuss >> -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi index 1b27925..5a95a69 100644 --- a/arch/arm/boot/dts/omap3.dtsi +++ b/arch/arm/boot/dts/omap3.dtsi @@ -14,11 +14,35 @@ compatible = "ti,omap3430", "ti,omap3"; /* + * XXX: The cpus node is mandatory, but since the CPUs are as well part + * of the mpu subsystem below, it is not clear where the information + * should be. Maybe here with a phandle inside the mpu? + */ + cpus { + }; + + /* * The soc node represents the soc top level view. It is uses for IPs * that are not memory mapped in the MPU view or for the MPU itself. */ soc { compatible = "ti,omap-infra"; + mpu { + compatible = "ti,omap3-mpu"; + hwmods = "mpu"; + cpu@0 { + compatible = "arm,cortex-a8"; + }; + }; + + iva { + compatible = "ti,iva22", "ti,iva"; + hwmods = "iva"; + + dsp { + compatible = "ti,omap3-c64", "ti,c64"; + }; + }; }; /* diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index ba4d187..1fdde69 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -24,6 +24,7 @@ #include "clockdomain.h" #include "pm.h" +#ifndef CONFIG_OF static struct omap_device_pm_latency *pm_lats; static int _init_omap_device(char *name) @@ -53,17 +54,18 @@ static void omap2_init_processor_devices(void) _init_omap_device("iva"); if (cpu_is_omap44xx()) { -#ifndef CONFIG_OF _init_omap_device("mpu"); _init_omap_device("l3_main_1"); _init_omap_device("dsp"); _init_omap_device("iva"); -#endif } else { _init_omap_device("mpu"); _init_omap_device("l3_main"); } } +#else +static void omap2_init_processor_devices(void) {} +#endif /* Types of sleep_switch used in omap_set_pwrdm_state */ #define FORCEWAKEUP_SWITCH 0
Add nodes for devices used by PM code (mpu, iva). In the case of OMAP3, the dsp was included inside the IVA2.2. Add an empty cpus node as well as recommended in the DT spec. Remove mpu and iva devices init if CONFIG_OF is defined. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Kevin Hilman <khilman@ti.com> --- arch/arm/boot/dts/omap3.dtsi | 24 ++++++++++++++++++++++++ arch/arm/mach-omap2/pm.c | 6 ++++-- 2 files changed, 28 insertions(+), 2 deletions(-)