* [PATCH 1/7] arm/dts: Add initial device-tree support for OMAP3 SoC
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-01 17:25 ` [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes Benoit Cousson
` (5 subsequent siblings)
6 siblings, 0 replies; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Add initial OMAP3 soc file with empty ocp bus.
Based on initial patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55830.html
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 44 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3.dtsi
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
new file mode 100644
index 0000000..1b27925
--- /dev/null
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -0,0 +1,44 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "ti,omap3430", "ti,omap3";
+
+ /*
+ * 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";
+ };
+
+ /*
+ * XXX: Use a flat representation of the OMAP3 interconnect.
+ * The real OMAP interconnect network is quite complex.
+ * Since that will not bring real advantage to represent that in DT for
+ * the moment, just use a fake OCP bus entry to represent the whole bus
+ * hierarchy.
+ */
+ ocp {
+ compatible = "ti,l3-smx", "arteris,smx", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ hwmods = "l3_main";
+
+ intc: interrupt-controller at 1 {
+ compatible = "ti,omap3-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
2011-09-01 17:25 ` [PATCH 1/7] arm/dts: Add initial device-tree support for OMAP3 SoC Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-01 18:17 ` Arnd Bergmann
2011-09-01 17:25 ` [PATCH 3/7] arm/dts: OMAP3: Add i2c controllers nodes Benoit Cousson
` (4 subsequent siblings)
6 siblings, 1 reply; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
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(-)
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 at 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
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes
2011-09-01 17:25 ` [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes Benoit Cousson
@ 2011-09-01 18:17 ` Arnd Bergmann
2011-09-05 15:05 ` Cousson, Benoit
0 siblings, 1 reply; 30+ messages in thread
From: Arnd Bergmann @ 2011-09-01 18:17 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes
2011-09-01 18:17 ` Arnd Bergmann
@ 2011-09-05 15:05 ` Cousson, Benoit
2011-09-05 17:23 ` Arnd Bergmann
0 siblings, 1 reply; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-05 15:05 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 0 {
compatible = "arm,cortex-a8";
};
};
[...]
soc {
compatible = "ti,omap-infra";
mpu {
compatible = "ti,omap3-mpu";
hwmods = "mpu";
cpu at 0 {
phandle = <&cpu0>;
[...]
};
};
};
Does that look better?
Thanks,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes
2011-09-05 15:05 ` Cousson, Benoit
@ 2011-09-05 17:23 ` Arnd Bergmann
2011-09-05 17:46 ` Mitch Bradley
0 siblings, 1 reply; 30+ messages in thread
From: Arnd Bergmann @ 2011-09-05 17:23 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
> compatible = "arm,cortex-a8";
> };
> };
>
> [...]
>
> soc {
> compatible = "ti,omap-infra";
> mpu {
> compatible = "ti,omap3-mpu";
> hwmods = "mpu";
> cpu at 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
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes
2011-09-05 17:23 ` Arnd Bergmann
@ 2011-09-05 17:46 ` Mitch Bradley
2011-09-06 7:15 ` Cousson, Benoit
0 siblings, 1 reply; 30+ messages in thread
From: Mitch Bradley @ 2011-09-05 17:46 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
>> compatible = "arm,cortex-a8";
>> };
>> };
>>
>> [...]
>>
>> soc {
>> compatible = "ti,omap-infra";
>> mpu {
>> compatible = "ti,omap3-mpu";
>> hwmods = "mpu";
>> cpu at 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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes
2011-09-05 17:46 ` Mitch Bradley
@ 2011-09-06 7:15 ` Cousson, Benoit
0 siblings, 0 replies; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-06 7:15 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0 {
compatible = "arm,cortex-a8";
subsystem = <&mpu>
mpu: arm_mpu {
compatible = "ti,omap3-mpu";
hwmods = "mpu";
};
};
And for an OMAP4 SMP system:
cpus {
cpu at 0 {
compatible = "arm,cortex-a9";
subsystem = <&mpu>
mpu: arm_mpu {
compatible = "ti,omap4-mpu";
hwmods = "mpu";
};
cpu at 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 at 0 {
>>> compatible = "arm,cortex-a8";
>>> };
>>> };
>>>
>>> [...]
>>>
>>> soc {
>>> compatible = "ti,omap-infra";
>>> mpu {
>>> compatible = "ti,omap3-mpu";
>>> hwmods = "mpu";
>>> cpu at 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 at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 3/7] arm/dts: OMAP3: Add i2c controllers nodes
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
2011-09-01 17:25 ` [PATCH 1/7] arm/dts: Add initial device-tree support for OMAP3 SoC Benoit Cousson
2011-09-01 17:25 ` [PATCH 2/7] arm/dts: OMAP3: Add mpu and iva nodes Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-01 17:25 ` [PATCH 4/7] arm/dts: omap3-beagle: Include the generic omap3.dtsi Benoit Cousson
` (3 subsequent siblings)
6 siblings, 0 replies; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 5a95a69..aab2129 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,12 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ aliases {
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ };
+
/*
* 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
@@ -64,5 +70,26 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ i2c1: i2c at 1 {
+ compatible = "ti,omap3-i2c", "ti,omap-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hwmods = "i2c1";
+ };
+
+ i2c2: i2c at 2 {
+ compatible = "ti,omap3-i2c", "ti,omap-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hwmods = "i2c2";
+ };
+
+ i2c3: i2c at 3 {
+ compatible = "ti,omap3-i2c", "ti,omap-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hwmods = "i2c3";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 4/7] arm/dts: omap3-beagle: Include the generic omap3.dtsi
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
` (2 preceding siblings ...)
2011-09-01 17:25 ` [PATCH 3/7] arm/dts: OMAP3: Add i2c controllers nodes Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-01 17:25 ` [PATCH 5/7] arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices Benoit Cousson
` (2 subsequent siblings)
6 siblings, 0 replies; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Update OMAP3 beagleboard DTS file to use the omap3.dtsi
SoC file.
Add a default bootargs line to allow a boot from RAMDISK
Add memory node information.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3-beagle.dts | 26 ++++++++++++++++++++++++--
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index 4439466..da13ec7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -1,7 +1,29 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
/dts-v1/;
-/include/ "skeleton.dtsi"
+
+/include/ "omap3.dtsi"
/ {
model = "TI OMAP3 BeagleBoard";
- compatible = "ti,omap3-beagle";
+ compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3";
+
+ /*
+ * Since the initial device tree board file does not create any
+ * devices (MMC, network...), the only way to boot is to provide a
+ * ramdisk.
+ */
+ chosen {
+ bootargs = "root=/dev/ram0 rw console=ttyO2,115200n8 initrd=0x81600000,20M ramdisk_size=20480 no_console_suspend debug earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>; /* 512 MB */
+ };
};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 5/7] arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
` (3 preceding siblings ...)
2011-09-01 17:25 ` [PATCH 4/7] arm/dts: omap3-beagle: Include the generic omap3.dtsi Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-01 17:25 ` [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support Benoit Cousson
2011-09-01 17:25 ` [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board Benoit Cousson
6 siblings, 0 replies; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Add required clock frequencies for the i2c client devices existing
on beagle board.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/boot/dts/omap3-beagle.dts | 42 ++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index da13ec7..5d0a558 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -27,3 +27,45 @@
reg = <0x80000000 0x20000000>; /* 512 MB */
};
};
+
+&i2c1 {
+ clock-frequency = <2600000>;
+
+ /*
+ * Integrated Power Management Chip
+ */
+ twl at 48 {
+ compatible = "ti,twl4030";
+ reg = <0x48>;
+ interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&intc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ranges = <0 0x48>;
+
+ twl_rtc {
+ compatible = "ti,twl_rtc";
+ interrupts = <11>;
+ reg = <0>;
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+
+ /*
+ * Display monitor features are burnt in the EEPROM
+ * as EDID data.
+ */
+ eeprom at 50 {
+ compatible = "ti,eeprom";
+ reg = <0x50>;
+ };
+};
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
` (4 preceding siblings ...)
2011-09-01 17:25 ` [PATCH 5/7] arm/dts: omap3-beagle: Add twl4030 and EEPROM i2c devices Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-02 8:09 ` Tony Lindgren
2011-09-05 12:09 ` G, Manjunath Kondaiah
2011-09-01 17:25 ` [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board Benoit Cousson
6 siblings, 2 replies; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Create an OMAP3 generic board to start the DT migration.
This file is doing the minimal initialization needed to boot
properly on a RAMDISK filesystem.
As soon as the OMAP3 specifics will be removed, that board will
be converted to an even more generic board-dt.c that will support
every OMAP2+ platforms.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: G, Manjunath Kondaiah <manjugk@ti.com>
---
arch/arm/mach-omap2/Kconfig | 10 +++++
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-omap3-dt.c | 74 ++++++++++++++++++++++++++++++++++
3 files changed, 85 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5d501d2..82f0df2 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
default y
select OMAP_PACKAGE_CBP
+config MACH_OMAP3_DT
+ bool "Generic OMAP3 board (FDT support)"
+ depends on ARCH_OMAP3
+ select OMAP_PACKAGE_CBB
+ select USE_OF
+ help
+ Support for generic TI OMAP3 boards using Flattened Device Tree.
+ Say Y here to enable OMAP3 device tree support
+ More information at Documentation/devicetree
+
config MACH_TI8168EVM
bool "TI8168 Evaluation Module"
depends on SOC_OMAPTI816X
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 6ab9116..5144c17 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO) += board-overo.o
obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o
+obj-$(CONFIG_MACH_OMAP3_DT) += board-omap3-dt.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
sdram-nokia.o
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
new file mode 100644
index 0000000..6eb56c6
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP3 Device tree boards support
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/irqdomain.h>
+#include <linux/of_platform.h>
+#include <linux/i2c/twl.h>
+
+#include <asm/mach/arch.h>
+#include <plat/common.h>
+
+#include "mux.h"
+#include "common-board-devices.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+
+static void __init omap3_init_early(void)
+{
+ omap2_init_common_infrastructure();
+ omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
+ mt46h32m32lf6_sdrc_params);
+}
+
+#ifdef CONFIG_OMAP_MUX
+static struct omap_board_mux board_mux[] __initdata = {
+ { .reg_offset = OMAP_MUX_TERMINATOR },
+};
+#endif
+
+static struct of_device_id omap_dt_match_table[] __initdata = {
+ { .compatible = "simple-bus", },
+ { .compatible = "ti,omap-infra", },
+ {}
+};
+
+static struct of_device_id omap_dt_intc_match[] __initdata = {
+ { .compatible = "ti,omap3-intc", },
+ {}
+};
+
+static void __init omap3_init(void)
+{
+ struct device_node *node;
+
+ node = of_find_matching_node(NULL, omap_dt_intc_match);
+ if (node)
+ irq_domain_add_simple(node, 0);
+
+ omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
+ omap_serial_init();
+
+ of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+}
+
+static const char *omap3_dt_match[] __initdata = {
+ "ti,omap3",
+ NULL
+};
+
+DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
+ .reserve = omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3_init_early,
+ .init_irq = omap3_init_irq,
+ .init_machine = omap3_init,
+ .timer = &omap3_timer,
+ .dt_compat = omap3_dt_match,
+MACHINE_END
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-01 17:25 ` [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support Benoit Cousson
@ 2011-09-02 8:09 ` Tony Lindgren
2011-09-02 8:46 ` Cousson, Benoit
2011-09-05 12:09 ` G, Manjunath Kondaiah
1 sibling, 1 reply; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 8:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
* Benoit Cousson <b-cousson@ti.com> [110901 19:52]:
> Create an OMAP3 generic board to start the DT migration.
I don't think this needs to be SoC specific, we can add multiple
DT_MACHINE_START entries into a single file. So it should be
just board-omap-dt.c.
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
> +static void __init omap3_init_early(void)
> +{
> + omap2_init_common_infrastructure();
> + omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> + mt46h32m32lf6_sdrc_params);
> +}
This has changed, see the cleanup branch. Also, let's just leave
out the sdram timings for now as we can work with bootloader
timings until those come from DT too.
> +static void __init omap3_init(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_matching_node(NULL, omap_dt_intc_match);
> + if (node)
> + irq_domain_add_simple(node, 0);
> +
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + omap_serial_init();
> +
> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> + "ti,omap3",
> + NULL
> +};
Most likely we just need SoC specific init functions in this file
now until the mux data comes from DT also.
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> + .reserve = omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = omap3_init_early,
> + .init_irq = omap3_init_irq,
> + .init_machine = omap3_init,
> + .timer = &omap3_timer,
> + .dt_compat = omap3_dt_match,
> +MACHINE_END
Here omap3_init_early is now generic in the cleanup branch.
Regards,
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 8:09 ` Tony Lindgren
@ 2011-09-02 8:46 ` Cousson, Benoit
2011-09-02 9:08 ` Russell King - ARM Linux
2011-09-02 10:43 ` Tony Lindgren
0 siblings, 2 replies; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 8:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tony,
On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> Hi,
>
> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
>> Create an OMAP3 generic board to start the DT migration.
>
> I don't think this needs to be SoC specific, we can add multiple
> DT_MACHINE_START entries into a single file. So it should be
> just board-omap-dt.c.
I do agree, it should not, I made that comment into the
board-omap4-dt.c, but for the moment we still have dedicated OMAP
specifics stuff at board level, like the map_io.
I have an other series that make the map_io DT aware to get rid of that,
but it still not finalized.
My goal was have a single DT_MACHINE_START for every OMAPs.
But, meanwhile, if you prefer one file with many board descriptors,
that's fine.
>> +#include "mux.h"
>> +#include "common-board-devices.h"
>> +#include "sdram-micron-mt46h32m32lf-6.h"
>> +
>> +
>> +static void __init omap3_init_early(void)
>> +{
>> + omap2_init_common_infrastructure();
>> + omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
>> + mt46h32m32lf6_sdrc_params);
>> +}
>
> This has changed, see the cleanup branch. Also, let's just leave
> out the sdram timings for now as we can work with bootloader
> timings until those come from DT too.
Yep, I know, but since that series is based on my previous series that
is based on mainline rc-3, I missed these.
Now, that kernel.org is back, I'll pull you branches :-).
Which one do you recommend in that case, master or cleanup?
>> +static void __init omap3_init(void)
>> +{
>> + struct device_node *node;
>> +
>> + node = of_find_matching_node(NULL, omap_dt_intc_match);
>> + if (node)
>> + irq_domain_add_simple(node, 0);
>> +
>> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> + omap_serial_init();
>> +
>> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> +}
>> +
>> +static const char *omap3_dt_match[] __initdata = {
>> + "ti,omap3",
>> + NULL
>> +};
>
> Most likely we just need SoC specific init functions in this file
> now until the mux data comes from DT also.
OK, I can get rid of mux stuff then.
>> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
>> + .reserve = omap_reserve,
>> + .map_io = omap3_map_io,
>> + .init_early = omap3_init_early,
>> + .init_irq = omap3_init_irq,
>> + .init_machine = omap3_init,
>> + .timer =&omap3_timer,
>> + .dt_compat = omap3_dt_match,
>> +MACHINE_END
>
> Here omap3_init_early is now generic in the cleanup branch.
Cool, I'll update the whole series, including the OMAP4 ones.
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 8:46 ` Cousson, Benoit
@ 2011-09-02 9:08 ` Russell King - ARM Linux
2011-09-02 9:13 ` Cousson, Benoit
2011-09-02 10:43 ` Tony Lindgren
1 sibling, 1 reply; 30+ messages in thread
From: Russell King - ARM Linux @ 2011-09-02 9:08 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
> Now, that kernel.org is back, I'll pull you branches :-).
Umm. Are you sure? What are you checking - that some kernel.org
servers are reachable or that master.kernel.org is reachable (it
isn't.)
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 9:08 ` Russell King - ARM Linux
@ 2011-09-02 9:13 ` Cousson, Benoit
2011-09-02 9:21 ` Russell King - ARM Linux
0 siblings, 1 reply; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 9:13 UTC (permalink / raw)
To: linux-arm-kernel
On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>> Now, that kernel.org is back, I'll pull you branches :-).
>
> Umm. Are you sure? What are you checking - that some kernel.org
> servers are reachable or that master.kernel.org is reachable (it
> isn't.)
I was not about to fetch
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
yesterday, but it works today.
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 9:13 ` Cousson, Benoit
@ 2011-09-02 9:21 ` Russell King - ARM Linux
2011-09-02 9:34 ` Cousson, Benoit
0 siblings, 1 reply; 30+ messages in thread
From: Russell King - ARM Linux @ 2011-09-02 9:21 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>> Now, that kernel.org is back, I'll pull you branches :-).
>>
>> Umm. Are you sure? What are you checking - that some kernel.org
>> servers are reachable or that master.kernel.org is reachable (it
>> isn't.)
>
> I was not about to fetch
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> yesterday, but it works today.
git.kernel.org != master.kernel.org.
git.kernel.org is an alias for a set of servers which are selected
depending on your geographical location, whereas master.kernel.org
a single machine to which we upload our trees and which has been down
since Wednesday. I don't believe master.kernel.org is part of the
public serving infrastructure (it certainly never used to be.)
So, I suspect your non-reachability of git.kernel.org yesterday was
due to some other problem.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 9:21 ` Russell King - ARM Linux
@ 2011-09-02 9:34 ` Cousson, Benoit
0 siblings, 0 replies; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On 9/2/2011 11:21 AM, Russell King - ARM Linux wrote:
> On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
>> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>>> Now, that kernel.org is back, I'll pull you branches :-).
>>>
>>> Umm. Are you sure? What are you checking - that some kernel.org
>>> servers are reachable or that master.kernel.org is reachable (it
>>> isn't.)
>>
>> I was not about to fetch
>> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
>> yesterday, but it works today.
>
> git.kernel.org != master.kernel.org.
>
> git.kernel.org is an alias for a set of servers which are selected
> depending on your geographical location, whereas master.kernel.org
> a single machine to which we upload our trees and which has been down
> since Wednesday. I don't believe master.kernel.org is part of the
> public serving infrastructure (it certainly never used to be.)
Interesting, thanks for the explanations.
> So, I suspect your non-reachability of git.kernel.org yesterday was
> due to some other problem.
OK, maybe. The good point is that now it works :-)
The bad point is that Kevin cannot push his updated branches, so I still
do not have the latest :-(
Thanks,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 8:46 ` Cousson, Benoit
2011-09-02 9:08 ` Russell King - ARM Linux
@ 2011-09-02 10:43 ` Tony Lindgren
2011-09-02 11:43 ` Cousson, Benoit
1 sibling, 1 reply; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 10:43 UTC (permalink / raw)
To: linux-arm-kernel
* Cousson, Benoit <b-cousson@ti.com> [110902 11:13]:
> Hi Tony,
>
> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> >Hi,
> >
> >* Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
> >>Create an OMAP3 generic board to start the DT migration.
> >
> >I don't think this needs to be SoC specific, we can add multiple
> >DT_MACHINE_START entries into a single file. So it should be
> >just board-omap-dt.c.
>
> I do agree, it should not, I made that comment into the
> board-omap4-dt.c, but for the moment we still have dedicated OMAP
> specifics stuff at board level, like the map_io.
Well map_io can also be set in DT_MACHINE_START. For most part
it already is generic like omap3_map_io and omap4_map_io.
So that should not stop anything.
> I have an other series that make the map_io DT aware to get rid of
> that, but it still not finalized.
Hmm maybe take a look again? We've already sorted out quite a bit
of the init stuff over past few merge windows. If there's still
something blocking that, let's clear it out ASAP.
> My goal was have a single DT_MACHINE_START for every OMAPs.
> But, meanwhile, if you prefer one file with many board descriptors,
> that's fine.
Yes that's better. We should only need a separate DT_MACHINE_START
for major SoC variants.
Regards,
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 10:43 ` Tony Lindgren
@ 2011-09-02 11:43 ` Cousson, Benoit
2011-09-02 11:57 ` Tony Lindgren
0 siblings, 1 reply; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 11:43 UTC (permalink / raw)
To: linux-arm-kernel
On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com> [110902 11:13]:
>> Hi Tony,
>>
>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
>>>> Create an OMAP3 generic board to start the DT migration.
>>>
>>> I don't think this needs to be SoC specific, we can add multiple
>>> DT_MACHINE_START entries into a single file. So it should be
>>> just board-omap-dt.c.
>>
>> I do agree, it should not, I made that comment into the
>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>> specifics stuff at board level, like the map_io.
>
> Well map_io can also be set in DT_MACHINE_START. For most part
> it already is generic like omap3_map_io and omap4_map_io.
> So that should not stop anything.
OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.
It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack.
I will let the device-tree experts answering that question :-)
For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.
>> I have an other series that make the map_io DT aware to get rid of
>> that, but it still not finalized.
>
> Hmm maybe take a look again? We've already sorted out quite a bit
> of the init stuff over past few merge windows. If there's still
> something blocking that, let's clear it out ASAP.
Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
The clear advantage of your method is that not further effort will be require for this part. At least for the moment.
>> My goal was have a single DT_MACHINE_START for every OMAPs.
>> But, meanwhile, if you prefer one file with many board descriptors,
>> that's fine.
>
> Yes that's better. We should only need a separate DT_MACHINE_START
> for major SoC variants.
OK, I'll try that.
Thanks,
Benoit
---
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 11:43 ` Cousson, Benoit
@ 2011-09-02 11:57 ` Tony Lindgren
2011-09-02 12:20 ` Cousson, Benoit
0 siblings, 1 reply; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 11:57 UTC (permalink / raw)
To: linux-arm-kernel
* Cousson, Benoit <b-cousson@ti.com> [110902 14:10]:
> On 9/2/2011 12:43 PM, Tony Lindgren wrote:
> > * Cousson, Benoit<b-cousson@ti.com> [110902 11:13]:
> >> Hi Tony,
> >>
> >> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
> >>> Hi,
> >>>
> >>> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
> >>>> Create an OMAP3 generic board to start the DT migration.
> >>>
> >>> I don't think this needs to be SoC specific, we can add multiple
> >>> DT_MACHINE_START entries into a single file. So it should be
> >>> just board-omap-dt.c.
> >>
> >> I do agree, it should not, I made that comment into the
> >> board-omap4-dt.c, but for the moment we still have dedicated OMAP
> >> specifics stuff at board level, like the map_io.
> >
> > Well map_io can also be set in DT_MACHINE_START. For most part
> > it already is generic like omap3_map_io and omap4_map_io.
> > So that should not stop anything.
>
> OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
> Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
>
> Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.
Sure that can be changed. But why not get the whole data that's
now in various structs from DT too? It's just something like:
.class = OMAP243X_CLASS,
.tap = OMAP2_L4_IO_ADDRESS(0x4900a000),
.sdrc = OMAP243X_SDRC_BASE,
.sms = OMAP243X_SMS_BASE,
.ctrl = OMAP243X_CTRL_BASE,
.prm = OMAP2430_PRM_BASE,
.cm = OMAP2430_CM_BASE,
And all these could be just defined in DT right?
> It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack.
> I will let the device-tree experts answering that question :-)
> For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.
Sure I agree.
> >> I have an other series that make the map_io DT aware to get rid of
> >> that, but it still not finalized.
> >
> > Hmm maybe take a look again? We've already sorted out quite a bit
> > of the init stuff over past few merge windows. If there's still
> > something blocking that, let's clear it out ASAP.
>
> Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
> The clear advantage of your method is that not further effort will be require for this part. At least for the moment.
Well I guess the globals could come from device tree still :)
In general, I'd like to get rid of the cpu_is_omapxxxx stuff
and SoC detection early as that always requires DEBUG_LL to
see any decent debug info when things go wrong.
If we get the SoC major type from DT, then we only need to
do SoC specific ES revision and GP/HS omap detection. And that's
very simple code compared to the current cpu_is_omapxxxx stuff.
Then we can boot with the DT information pretty far to map_io
and initialize low-level serial console, and then set up things
further while having a decent console ;)
Regards,
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 11:57 ` Tony Lindgren
@ 2011-09-02 12:20 ` Cousson, Benoit
2011-09-02 12:32 ` Tony Lindgren
0 siblings, 1 reply; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 12:20 UTC (permalink / raw)
To: linux-arm-kernel
On 9/2/2011 1:57 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com> [110902 14:10]:
>> On 9/2/2011 12:43 PM, Tony Lindgren wrote:
>>> * Cousson, Benoit<b-cousson@ti.com> [110902 11:13]:
>>>> Hi Tony,
>>>>
>>>> On 9/2/2011 10:09 AM, Tony Lindgren wrote:
>>>>> Hi,
>>>>>
>>>>> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
>>>>>> Create an OMAP3 generic board to start the DT migration.
>>>>>
>>>>> I don't think this needs to be SoC specific, we can add multiple
>>>>> DT_MACHINE_START entries into a single file. So it should be
>>>>> just board-omap-dt.c.
>>>>
>>>> I do agree, it should not, I made that comment into the
>>>> board-omap4-dt.c, but for the moment we still have dedicated OMAP
>>>> specifics stuff at board level, like the map_io.
>>>
>>> Well map_io can also be set in DT_MACHINE_START. For most part
>>> it already is generic like omap3_map_io and omap4_map_io.
>>> So that should not stop anything.
>>
>> OK, I think I was trying to be a little bit more extreme, meaning only one omap_map_io for every OMAPs.
>> Then, inside omap_map_io we can use the DT compatible information to retrieve the proper OMAPs revision and thus use the proper init table.
>>
>> Whereas in your case you are still relying on the various DT_MACHINE entries to detect which OMAP revision is used.
>
> Sure that can be changed. But why not get the whole data that's
> now in various structs from DT too? It's just something like:
>
> .class = OMAP243X_CLASS,
> .tap = OMAP2_L4_IO_ADDRESS(0x4900a000),
BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?
> .sdrc = OMAP243X_SDRC_BASE,
> .sms = OMAP243X_SMS_BASE,
> .ctrl = OMAP243X_CTRL_BASE,
> .prm = OMAP2430_PRM_BASE,
> .cm = OMAP2430_CM_BASE,
>
> And all these could be just defined in DT right?
Hehe, it is just a phase-one-proof-of-concept... the phase two was
supposed to move that to DT. But for the moment, I was trying to have a
more conservative approach using the existing data like for hwmod.
The other point is that we still have to deal with the FDT at that
point, the DT is not yest available that why I didn't extract too many
informations from the FDT.
Moreover, in theory, these informations will not be mixed like today,
but will be in their own relevant DT nodes, somewhere inside the tree.
Bottomline... it was a little bit more tricky.
>> It looks to me that relying on several DT_MACHINE_START to identify a SoC version is a little bit more a hack.
>> I will let the device-tree experts answering that question :-)
>> For my point of view, using DT compatible in the various place where the OMAP revision is important, might allow a finer granularity.
>
> Sure I agree.
>
>>>> I have an other series that make the map_io DT aware to get rid of
>>>> that, but it still not finalized.
>>>
>>> Hmm maybe take a look again? We've already sorted out quite a bit
>>> of the init stuff over past few merge windows. If there's still
>>> something blocking that, let's clear it out ASAP.
>>
>> Now that I understand your approach, it is fine. Please find below an example of what I was trying to achieve, and why that point was an issue.
>> The clear advantage of your method is that not further effort will be require for this part. At least for the moment.
>
> Well I guess the globals could come from device tree still :)
Fully agree. It just needs some more time :-)
> In general, I'd like to get rid of the cpu_is_omapxxxx stuff
> and SoC detection early as that always requires DEBUG_LL to
> see any decent debug info when things go wrong.
>
> If we get the SoC major type from DT, then we only need to
> do SoC specific ES revision and GP/HS omap detection. And that's
> very simple code compared to the current cpu_is_omapxxxx stuff.
In fact only the tap should be required at map_io time to get the
DEVICE_ID, I guess that the others entries could be retrieve later?
.sdrc = OMAP243X_SDRC_BASE,
.sms = OMAP243X_SMS_BASE,
.ctrl = OMAP243X_CTRL_BASE,
.prm = OMAP2430_PRM_BASE,
.cm = OMAP2430_CM_BASE,
If this is the case, we can then add a DEVICE_ID address entry in DT
root to be retrieved easily with the FDT.
> Then we can boot with the DT information pretty far to map_io
> and initialize low-level serial console, and then set up things
> further while having a decent console ;)
Yeah! The holy grail.
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-02 12:20 ` Cousson, Benoit
@ 2011-09-02 12:32 ` Tony Lindgren
0 siblings, 0 replies; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
* Cousson, Benoit <b-cousson@ti.com> [110902 14:47]:
> > .tap = OMAP2_L4_IO_ADDRESS(0x4900a000),
>
> BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?
That needs to be mapped early for SoC detection to work
for cpu_is_omapxxxx stuff :(
> In fact only the tap should be required at map_io time to get the
> DEVICE_ID, I guess that the others entries could be retrieve later?
Yes well whatever needs to be mapped early for the SoC
revision detection. It could be that we can map timers
and serial port only early, then set up the mappings for
the rest later on. That is if we can avoid SoC and revision
detection early.
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support
2011-09-01 17:25 ` [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support Benoit Cousson
2011-09-02 8:09 ` Tony Lindgren
@ 2011-09-05 12:09 ` G, Manjunath Kondaiah
1 sibling, 0 replies; 30+ messages in thread
From: G, Manjunath Kondaiah @ 2011-09-05 12:09 UTC (permalink / raw)
To: linux-arm-kernel
Minor comments:
On Thu, Sep 01, 2011 at 07:25:11PM +0200, Benoit Cousson wrote:
> Create an OMAP3 generic board to start the DT migration.
>
> This file is doing the minimal initialization needed to boot
> properly on a RAMDISK filesystem.
>
> As soon as the OMAP3 specifics will be removed, that board will
> be converted to an even more generic board-dt.c that will support
> every OMAP2+ platforms.
>
> Based on original patch from Manju:
> http://www.spinics.net/lists/linux-omap/msg55832.html
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: G, Manjunath Kondaiah <manjugk@ti.com>
> ---
> arch/arm/mach-omap2/Kconfig | 10 +++++
> arch/arm/mach-omap2/Makefile | 1 +
> arch/arm/mach-omap2/board-omap3-dt.c | 74 ++++++++++++++++++++++++++++++++++
> 3 files changed, 85 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 5d501d2..82f0df2 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -305,6 +305,16 @@ config MACH_OMAP_3630SDP
> default y
> select OMAP_PACKAGE_CBP
>
> +config MACH_OMAP3_DT
> + bool "Generic OMAP3 board (FDT support)"
> + depends on ARCH_OMAP3
> + select OMAP_PACKAGE_CBB
> + select USE_OF
> + help
> + Support for generic TI OMAP3 boards using Flattened Device Tree.
> + Say Y here to enable OMAP3 device tree support
> + More information at Documentation/devicetree
> +
> config MACH_TI8168EVM
> bool "TI8168 Evaluation Module"
> depends on SOC_OMAPTI816X
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 6ab9116..5144c17 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -197,6 +197,7 @@ obj-$(CONFIG_MACH_OVERO) += board-overo.o
> obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o
> obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o
> obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o
> +obj-$(CONFIG_MACH_OMAP3_DT) += board-omap3-dt.o
> obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
> obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
> sdram-nokia.o
> diff --git a/arch/arm/mach-omap2/board-omap3-dt.c b/arch/arm/mach-omap2/board-omap3-dt.c
> new file mode 100644
> index 0000000..6eb56c6
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap3-dt.c
> @@ -0,0 +1,74 @@
> +/*
> + * OMAP3 Device tree boards support
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/irqdomain.h>
> +#include <linux/of_platform.h>
> +#include <linux/i2c/twl.h>
this header is redundant
> +
> +#include <asm/mach/arch.h>
> +#include <plat/common.h>
> +
> +#include "mux.h"
> +#include "common-board-devices.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +
> +
extra blank line
-M
> +static void __init omap3_init_early(void)
> +{
> + omap2_init_common_infrastructure();
> + omap2_init_common_devices(mt46h32m32lf6_sdrc_params,
> + mt46h32m32lf6_sdrc_params);
> +}
> +
> +#ifdef CONFIG_OMAP_MUX
> +static struct omap_board_mux board_mux[] __initdata = {
> + { .reg_offset = OMAP_MUX_TERMINATOR },
> +};
> +#endif
> +
> +static struct of_device_id omap_dt_match_table[] __initdata = {
> + { .compatible = "simple-bus", },
> + { .compatible = "ti,omap-infra", },
> + {}
> +};
> +
> +static struct of_device_id omap_dt_intc_match[] __initdata = {
> + { .compatible = "ti,omap3-intc", },
> + {}
> +};
> +
> +static void __init omap3_init(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_matching_node(NULL, omap_dt_intc_match);
> + if (node)
> + irq_domain_add_simple(node, 0);
> +
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + omap_serial_init();
> +
> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> + "ti,omap3",
> + NULL
> +};
> +
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> + .reserve = omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = omap3_init_early,
> + .init_irq = omap3_init_irq,
> + .init_machine = omap3_init,
> + .timer = &omap3_timer,
> + .dt_compat = omap3_dt_match,
> +MACHINE_END
> --
> 1.7.0.4
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
2011-09-01 17:25 [PATCH 0/7] OMAP3: Add basic DT support + i2c + twl Benoit Cousson
` (5 preceding siblings ...)
2011-09-01 17:25 ` [PATCH 6/7] OMAP3: board-dt: Add generic board file for DT support Benoit Cousson
@ 2011-09-01 17:25 ` Benoit Cousson
2011-09-02 8:12 ` Tony Lindgren
6 siblings, 1 reply; 30+ messages in thread
From: Benoit Cousson @ 2011-09-01 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In order to avoid conflict with the new board-omap3-dt.c file,
remove the .dt_compat entry from the beagle regular board
file.
Any DT work for OMAP3 will have to be done on the generic DT
board file to avoid breaking the legacy board support until
DT migration is done.
Based on orginal patch fropm Manju:
http://www.spinics.net/lists/linux-omap/msg55832.html
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index a7923ca..2c358a2 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -19,7 +19,6 @@
#include <linux/err.h>
#include <linux/clk.h>
#include <linux/io.h>
-#include <linux/of_platform.h>
#include <linux/leds.h>
#include <linux/gpio.h>
#include <linux/input.h>
@@ -388,9 +387,7 @@ static int __init omap3_beagle_i2c_init(void)
/* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz */
omap_register_i2c_bus(3, 100, beagle_i2c_eeprom, ARRAY_SIZE(beagle_i2c_eeprom));
-#ifdef CONFIG_OF
omap_register_i2c_bus(2, 100, NULL, 0);
-#endif /* CONFIG_OF */
return 0;
}
@@ -528,10 +525,6 @@ static void __init beagle_opp_init(void)
static void __init omap3_beagle_init(void)
{
-#ifdef CONFIG_OF
- of_platform_prepare(NULL, NULL);
-#endif /* CONFIG_OF */
-
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
@@ -563,11 +556,6 @@ static void __init omap3_beagle_init(void)
beagle_opp_init();
}
-static const char *omap3_beagle_dt_match[] __initdata = {
- "ti,omap3-beagle",
- NULL
-};
-
MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
/* Maintainer: Syed Mohammed Khasim - http://beagleboard.org */
.boot_params = 0x80000100,
@@ -577,5 +565,4 @@ MACHINE_START(OMAP3_BEAGLE, "OMAP3 Beagle Board")
.init_irq = omap3_beagle_init_irq,
.init_machine = omap3_beagle_init,
.timer = &omap3_secure_timer,
- .dt_compat = omap3_beagle_dt_match,
MACHINE_END
--
1.7.0.4
^ permalink raw reply related [flat|nested] 30+ messages in thread* [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
2011-09-01 17:25 ` [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board Benoit Cousson
@ 2011-09-02 8:12 ` Tony Lindgren
2011-09-02 8:59 ` Cousson, Benoit
0 siblings, 1 reply; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 8:12 UTC (permalink / raw)
To: linux-arm-kernel
* Benoit Cousson <b-cousson@ti.com> [110901 19:52]:
> In order to avoid conflict with the new board-omap3-dt.c file,
> remove the .dt_compat entry from the beagle regular board
> file.
>
> Any DT work for OMAP3 will have to be done on the generic DT
> board file to avoid breaking the legacy board support until
> DT migration is done.
In general we should not keep duplicate old non-DT data around
now that we have the DT append support. Instead we should just
require the .dts file appended to zImage for all mach-omap2
machines. Otherwise we'll end up with double bloat :)
So it's OK to have the DT entries in board files so drivers
that get converted will work with them.
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
2011-09-02 8:12 ` Tony Lindgren
@ 2011-09-02 8:59 ` Cousson, Benoit
2011-09-02 10:48 ` Tony Lindgren
0 siblings, 1 reply; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 8:59 UTC (permalink / raw)
To: linux-arm-kernel
On 9/2/2011 10:12 AM, Tony Lindgren wrote:
> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
>> In order to avoid conflict with the new board-omap3-dt.c file,
>> remove the .dt_compat entry from the beagle regular board
>> file.
>>
>> Any DT work for OMAP3 will have to be done on the generic DT
>> board file to avoid breaking the legacy board support until
>> DT migration is done.
>
> In general we should not keep duplicate old non-DT data around
> now that we have the DT append support. Instead we should just
> require the .dts file appended to zImage for all mach-omap2
> machines. Otherwise we'll end up with double bloat :)
Mmm, I'm not sure to get your point. We are not duplicating, since a
pure DT generic board will not have anything except a
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
And the regular board files will keep initializing devices statically.
The drivers will then for the moment support both pdata and DT method to
get board parameters.
> So it's OK to have the DT entries in board files so drivers
> that get converted will work with them.
Well, it will be a little bit more tricky, because having DT in current
board files will be a mess with a bunch of #ifdef CONFIG_OF, and adding
DT compatible inside each boards will prevent the pure generic DT one to
work. In that case we will duplicate the DT migration in every legacy
boards files...
That's why the current strategy is to keep the current board files
non-DT aware and add the DT support only to the generic DT board file.
Regards,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
2011-09-02 8:59 ` Cousson, Benoit
@ 2011-09-02 10:48 ` Tony Lindgren
2011-09-02 12:35 ` Cousson, Benoit
0 siblings, 1 reply; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 10:48 UTC (permalink / raw)
To: linux-arm-kernel
* Cousson, Benoit <b-cousson@ti.com> [110902 11:26]:
> On 9/2/2011 10:12 AM, Tony Lindgren wrote:
> >* Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
> >>In order to avoid conflict with the new board-omap3-dt.c file,
> >>remove the .dt_compat entry from the beagle regular board
> >>file.
> >>
> >>Any DT work for OMAP3 will have to be done on the generic DT
> >>board file to avoid breaking the legacy board support until
> >>DT migration is done.
> >
> >In general we should not keep duplicate old non-DT data around
> >now that we have the DT append support. Instead we should just
> >require the .dts file appended to zImage for all mach-omap2
> >machines. Otherwise we'll end up with double bloat :)
>
> Mmm, I'm not sure to get your point. We are not duplicating, since a
> pure DT generic board will not have anything except a
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> And the regular board files will keep initializing devices statically.
> The drivers will then for the moment support both pdata and DT
> method to get board parameters.
Well when converting a driver to DT, we should just drop pdata
support. No need to keep it around as it will just make it harder
for us to clean up afterwards.
> >So it's OK to have the DT entries in board files so drivers
> >that get converted will work with them.
>
> Well, it will be a little bit more tricky, because having DT in
> current board files will be a mess with a bunch of #ifdef CONFIG_OF,
> and adding DT compatible inside each boards will prevent the pure
> generic DT one to work. In that case we will duplicate the DT
> migration in every legacy boards files...
We should just select CONFIG_OF deal with it that way.
> That's why the current strategy is to keep the current board files
> non-DT aware and add the DT support only to the generic DT board
> file.
Well I don't like that, it will be a big mess. We'll end up with
twice the amount of platform_data and init code. It's OK to
require CONFIG_OF as it's known to work with the append support
for older boards.
It's easier just to require DT append for all the boards. In most
cases it's just a trivial include of the common dts file for now.
When we convert something to DT, there's no point going back.
Regards,
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
2011-09-02 10:48 ` Tony Lindgren
@ 2011-09-02 12:35 ` Cousson, Benoit
2011-09-02 13:08 ` Tony Lindgren
0 siblings, 1 reply; 30+ messages in thread
From: Cousson, Benoit @ 2011-09-02 12:35 UTC (permalink / raw)
To: linux-arm-kernel
On 9/2/2011 12:48 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com> [110902 11:26]:
>> On 9/2/2011 10:12 AM, Tony Lindgren wrote:
>>> * Benoit Cousson<b-cousson@ti.com> [110901 19:52]:
>>>> In order to avoid conflict with the new board-omap3-dt.c file,
>>>> remove the .dt_compat entry from the beagle regular board
>>>> file.
>>>>
>>>> Any DT work for OMAP3 will have to be done on the generic DT
>>>> board file to avoid breaking the legacy board support until
>>>> DT migration is done.
>>>
>>> In general we should not keep duplicate old non-DT data around
>>> now that we have the DT append support. Instead we should just
>>> require the .dts file appended to zImage for all mach-omap2
>>> machines. Otherwise we'll end up with double bloat :)
>>
>> Mmm, I'm not sure to get your point. We are not duplicating, since a
>> pure DT generic board will not have anything except a
>> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>> And the regular board files will keep initializing devices statically.
>> The drivers will then for the moment support both pdata and DT
>> method to get board parameters.
>
> Well when converting a driver to DT, we should just drop pdata
> support. No need to keep it around as it will just make it harder
> for us to clean up afterwards.
I'm not sure it is that simple. We have 20+ OMAP3+ boards supported so
far. Dropping pdata when a driver is adapted means that all these boards
should be properly adapted to DT and tested... (board-XXX.dts +
board-XXX.c).
That's a huge effort for my point of view. Whereas keeping the legacy
pdata method will allow progressing on the boart-dt only without
breaking any legacy boards. It will allow the board manufacturers to
potentially do the DTS file for their own system using then the generic
board-dt.c file.
That being said, keeping the legacy pdata code in some driver along with
the DT is a big pain as well:-(
In some cases, DT can even provide some good way to encode HW
information that we do not have today with hwmod/omap_device. So in that
case we do not even have any alternative method yet.
>>> So it's OK to have the DT entries in board files so drivers
>>> that get converted will work with them.
>>
>> Well, it will be a little bit more tricky, because having DT in
>> current board files will be a mess with a bunch of #ifdef CONFIG_OF,
>> and adding DT compatible inside each boards will prevent the pure
>> generic DT one to work. In that case we will duplicate the DT
>> migration in every legacy boards files...
>
> We should just select CONFIG_OF deal with it that way.
>
>> That's why the current strategy is to keep the current board files
>> non-DT aware and add the DT support only to the generic DT board
>> file.
>
> Well I don't like that, it will be a big mess. We'll end up with
> twice the amount of platform_data and init code. It's OK to
> require CONFIG_OF as it's known to work with the append support
> for older boards.
>
> It's easier just to require DT append for all the boards. In most
> cases it's just a trivial include of the common dts file for now.
That part is easy indeed, this is hacking every board-XXX.c and testing
them that will be tricky. This is as well the board specifics settings
that are tricky not the generic OMAP stuff. We do have to set GPIOs, pin
mux, regulator bindings, audio codec stuff...
> When we convert something to DT, there's no point going back.
Agree on that, in theory, I'm just wondering how practical it will be to
progress on every board at the same time.
I guess we do need some advice from the DT gurus on that as well.
It looks to me that both approaches are painful and will require some
efforts.
It is too bad that nobody did a
devicetree-migration-o-matic-for-lazy-developer.py script to handle that...
Regards,
Benoit
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH 7/7] OMAP3: beagleboard: Remove DT support from regular board
2011-09-02 12:35 ` Cousson, Benoit
@ 2011-09-02 13:08 ` Tony Lindgren
0 siblings, 0 replies; 30+ messages in thread
From: Tony Lindgren @ 2011-09-02 13:08 UTC (permalink / raw)
To: linux-arm-kernel
* Cousson, Benoit <b-cousson@ti.com> [110902 15:02]:
> On 9/2/2011 12:48 PM, Tony Lindgren wrote:
>
> I'm not sure it is that simple. We have 20+ OMAP3+ boards supported
> so far. Dropping pdata when a driver is adapted means that all these
> boards should be properly adapted to DT and tested... (board-XXX.dts
> + board-XXX.c).
> That's a huge effort for my point of view. Whereas keeping the
> legacy pdata method will allow progressing on the boart-dt only
> without breaking any legacy boards. It will allow the board
> manufacturers to potentially do the DTS file for their own system
> using then the generic board-dt.c file.
Yeah but we've seen how badly "we'll clean it up later" approach
works :(
Unfortunately that path means nobody comes back to clean-up
anything after the party is over and all that work falls on the
maintainers.
So the one driver at a time conversion approach is better.
> That being said, keeping the legacy pdata code in some driver along
> with the DT is a big pain as well:-(
Yup and duplicate data will lead to nasty bugs and support issues.
> >It's easier just to require DT append for all the boards. In most
> >cases it's just a trivial include of the common dts file for now.
>
> That part is easy indeed, this is hacking every board-XXX.c and
> testing them that will be tricky. This is as well the board
> specifics settings that are tricky not the generic OMAP stuff. We do
> have to set GPIOs, pin mux, regulator bindings, audio codec stuff...
Right but for most part it's just removing the data. The board
specific things are usually number of MMC data lines, number of
USB transceiver data lines, GPIO to enable etc. Pretty trivial
stuff that the board maintainers can test.
> >When we convert something to DT, there's no point going back.
>
> Agree on that, in theory, I'm just wondering how practical it will
> be to progress on every board at the same time.
That should not be too bad for most part. For example, the board-*.c
files all just call omap_register_i2c_bus with the controllers.
So not much there to convert, just add the controllers to board
.dts files and remove from board-*.c files.
> I guess we do need some advice from the DT gurus on that as well.
>
> It looks to me that both approaches are painful and will require
> some efforts.
Yes, but if we don't drop the pdata then we'll be in half-converted
state eternally.
> It is too bad that nobody did a
> devicetree-migration-o-matic-for-lazy-developer.py script to handle
> that...
The conversion for some drivers can be scripted for sure :)
Regards,
Tony
^ permalink raw reply [flat|nested] 30+ messages in thread