OMAP3: Add basic DT support + i2c + twl

        /*

arch/arm/boot/dts/omap3.dtsi +8 -0

+        * 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.
         */

Quoted 22 lines · On Thursday 01 September 2011 19:25:07 Benoit Cousson wrote:

         /*

arch/arm/boot/dts/omap3.dtsi +15 -0

+        * 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";
+                       };
+               };

Quoted 1 line

+

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>;
                        [...]
                };
        };
};

Quoted 3 lines · Benoit

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.

Quoted 15 lines

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";
         };
};

[...]

Quoted 11 lines

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

Quoted 4 lines · Arnd Bergmann

Quoted 3 lines · Benoit

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.

Quoted 37 lines

Quoted 16 lines

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";
          };
};

[...]

Quoted 11 lines

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

Create an OMAP3 generic board to start the DT migration.

arch/arm/mach-omap2/board-omap3-dt.c new file +8 -0

+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);
+

Hi,

Quoted 1 line · Benoit Cousson

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.

Quoted 7 lines

arch/arm/mach-omap2/board-omap3-dt.c new file +7 -0

+#include "mux.h"
+#include "common-board-devices.h"
+#include "sdram-micron-mt46h32m32lf-6.h"
+
+
+static void __init omap3_init_early(void)
+{

arch/arm/mach-omap2/board-omap3-dt.c line 28

Quoted 4 lines

arch/arm/mach-omap2/board-omap3-dt.c new file +4 -0

+	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.

Quoted 13 lines

arch/arm/mach-omap2/board-omap3-dt.c new file +13 -0

+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);
+}

arch/arm/mach-omap2/board-omap3-dt.c line 64

Quoted 5 lines

arch/arm/mach-omap2/board-omap3-dt.c new file +5 -0

+
+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.

arch/arm/mach-omap2/board-omap3-dt.c line 74

Quoted 9 lines

arch/arm/mach-omap2/board-omap3-dt.c new file +9 -0

+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.

Now, that kernel.org is back, I'll pull you branches :-).

Quoted 1 line · Benoit

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.)

Quoted 6 lines · Russell King - ARM Linux

Quoted 1 line · Benoit

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.

Quoted 11 lines · Benoit

Quoted 6 lines · Russell King - ARM Linux

Quoted 1 line · Benoit

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.

Hi Tony,

Quoted 5 lines · Tony Lindgren

Hi,

Quoted 1 line · Benoit Cousson

Create an OMAP3 generic board to start the DT migration.

Quoted 3 lines

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.

Quoted 12 lines · Cousson, Benoit

Hi Tony,

Quoted 8 lines · Tony Lindgren

Hi,

Quoted 1 line · Benoit Cousson

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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 17 lines · Tony Lindgren

Quoted 15 lines · Cousson, Benoit

Hi Tony,

Quoted 8 lines · Tony Lindgren

Hi,

Quoted 1 line · Benoit Cousson

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.

Quoted 3 lines

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.

Quoted 6 lines

Quoted 2 lines

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.

Quoted 25 lines · Cousson, Benoit

Quoted 13 lines · Tony Lindgren

Quoted 12 lines · Cousson, Benoit

Hi Tony,

Quoted 8 lines · Tony Lindgren

Hi,

Quoted 1 line · Benoit Cousson

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.

Quoted 7 lines

Quoted 3 lines

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.

Quoted 1 line

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?

Quoted 3 lines

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.

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

I have an other series that make the map_io DT aware to get rid of that, but it still not finalized.

Quoted 6 lines

Quoted 3 lines

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 ;)

Quoted 1 line

        .tap    = OMAP2_L4_IO_ADDRESS(0x4900a000),

BTW, how can we get rid of that OMAP2_L4_IO_ADDRESS?

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?

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 <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc G, Manjunath Kondaiah <[email protected]>

---
 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

arch/arm/mach-omap2/Kconfig +10 -0

index 5d501d2..82f0df2 100644
@@ -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

arch/arm/mach-omap2/Makefile +1 -0

index 6ab9116..5144c17 100644
@@ -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

arch/arm/mach-omap2/board-omap3-dt.c new file +3 -0

new file mode 100644
index 0000000..6eb56c6
@@ -0,0 +1,74 @@
+/*
+ * OMAP3 Device tree boards support
+ *

arch/arm/mach-omap2/board-omap3-dt.c new file +52 -0

+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

Signature · 1 line

1.7.0.4

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.

Quoted 4 lines · Benoit Cousson

In order to avoid conflict with the new board-omap3-dt.c file, remove the .dt_compat entry from the beagle regular board file.

Quoted 3 lines

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.

Quoted 5 lines · Tony Lindgren

Quoted 4 lines · Benoit Cousson

In order to avoid conflict with the new board-omap3-dt.c file, remove the .dt_compat entry from the beagle regular board file.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 15 lines · Cousson, Benoit

Quoted 5 lines · Tony Lindgren

Quoted 4 lines · Benoit Cousson

In order to avoid conflict with the new board-omap3-dt.c file, remove the .dt_compat entry from the beagle regular board file.

Quoted 8 lines

Quoted 3 lines

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 :)

Quoted 6 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

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.

That being said, keeping the legacy pdata code in some driver along with the DT is a big pain as well:-(

Quoted 2 lines

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...

Quoted 1 line

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...