Re: [PATCH 00/06] ARM: shmobile: Per-board memory size fixups

Re: [PATCH 00/06] ARM: shmobile: Per-board memory size fixups

[Magnus Damm]

On Wed, Jun 5, 2013 at 4:34 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> ARM: shmobile: Per-board memory size fixups
>
> [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper
> [PATCH 02/06] ARM: shmobile: AG5EVM memory config via ATAGS fixup
> [PATCH 03/06] ARM: shmobile: AP4EVB memory config via ATAGS fixup
> [PATCH 04/06] ARM: shmobile: Bonito memory config via ATAGS fixup
> [PATCH 05/06] ARM: shmobile: Kota2 memory config via ATAGS fixup
> [PATCH 06/06] ARM: shmobile: Marzen memory config via ATAGS fixup

Oh, ok, the above turned out to be an old version of the patch names.
Before I cause more confusion, the patch names are supposed to be like this:

[PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper
[PATCH 02/06] ARM: shmobile: AG5EVM memory size fixup
[PATCH 03/06] ARM: shmobile: AP4EVB memory size fixup
[PATCH 04/06] ARM: shmobile: Bonito memory size fixup
[PATCH 05/06] ARM: shmobile: Kota2 memory size fixup
[PATCH 06/06] ARM: shmobile: Marzen memory size fixup

Thanks,

/ magnus

[PATCH 00/06] ARM: shmobile: Per-board memory size fixups

[Magnus Damm]

ARM: shmobile: Per-board memory size fixups

[PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper
[PATCH 02/06] ARM: shmobile: AG5EVM memory config via ATAGS fixup
[PATCH 03/06] ARM: shmobile: AP4EVB memory config via ATAGS fixup
[PATCH 04/06] ARM: shmobile: Bonito memory config via ATAGS fixup
[PATCH 05/06] ARM: shmobile: Kota2 memory config via ATAGS fixup
[PATCH 06/06] ARM: shmobile: Marzen memory config via ATAGS fixup

This series adds memory size and base address fixups to
non-DT mach-shmobile boards. This way the ATAGS code in
arch/arm/kernel/atags_parse.c can be overriden on a per-
board basis without the need of any global MEM_SIZE or
PHYS_OFFSET settings.

This is one of several series of code that reworks code
not to rely on CONFIG_MEMORY_START/SIZE which in turn is
needed for ARCH_MULTIPLATFORM.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 Written against renesas.git renesas-next-20130604v2

 arch/arm/mach-shmobile/Kconfig               |    5 +++++
 arch/arm/mach-shmobile/board-ag5evm.c        |    4 ++++
 arch/arm/mach-shmobile/board-ap4evb.c        |    3 +++
 arch/arm/mach-shmobile/board-bonito.c        |    4 ++++
 arch/arm/mach-shmobile/board-kota2.c         |    4 ++++
 arch/arm/mach-shmobile/board-marzen.c        |    4 ++++
 arch/arm/mach-shmobile/include/mach/common.h |   13 +++++++++++++
 7 files changed, 37 insertions(+)

[PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Introduce SHMOBILE_FIXUP() as a helper function to
allow boards to specify their memory base and size.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/include/mach/common.h |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- 0001/arch/arm/mach-shmobile/include/mach/common.h
+++ work/arch/arm/mach-shmobile/include/mach/common.h	2013-06-04 13:01:40.000000000 +0900
@@ -37,4 +37,17 @@ static inline void __init shmobile_init_
 	shmobile_cpuidle_init();
 }
 
+#define SHMOBILE_FIXUP(boardname, mem_start, mem_size)			\
+static void __init boardname##_fixup(struct tag *tag, char **cmdline,	\
+				struct meminfo *mi)			\
+{									\
+	for (; tag->hdr.size; tag = tag_next(tag)) {			\
+		if (tag->hdr.tag = ATAG_MEM) {				\
+			tag->u.mem.start = (mem_start);			\
+			tag->u.mem.size = (mem_size);			\
+			break;						\
+		}							\
+	}								\
+}
+
 #endif /* __ARCH_MACH_COMMON_H */

[PATCH 02/06] ARM: shmobile: AG5EVM memory size fixup

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Specify the AG5EVM memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-ag5evm.c |    4 ++++
 2 files changed, 5 insertions(+)

--- 0001/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-06-04 13:18:56.000000000 +0900
@@ -92,6 +92,7 @@ endchoice
 config MACH_AG5EVM
 	bool "AG5EVM board"
 	depends on ARCH_SH73A0
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
--- 0001/arch/arm/mach-shmobile/board-ag5evm.c
+++ work/arch/arm/mach-shmobile/board-ag5evm.c	2013-06-04 13:16:52.000000000 +0900
@@ -53,6 +53,7 @@
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/setup.h>
 #include <asm/traps.h>
 
 /* Dummy supplies, where voltage doesn't matter */
@@ -660,7 +661,10 @@ static void __init ag5evm_init(void)
 	platform_add_devices(ag5evm_devices, ARRAY_SIZE(ag5evm_devices));
 }
 
+SHMOBILE_FIXUP(ag5evm, 0x40000000, 0x20000000)
+
 MACHINE_START(AG5EVM, "ag5evm")
+	.fixup		= ag5evm_fixup,
 	.smp		= smp_ops(sh73a0_smp_ops),
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_add_early_devices,

[PATCH 03/06] ARM: shmobile: AP4EVB memory size fixup

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Specify the AP4EVB memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-ap4evb.c |    3 +++
 2 files changed, 4 insertions(+)

--- 0005/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-06-04 15:08:32.000000000 +0900
@@ -71,6 +71,7 @@ comment "SH-Mobile Board Type"
 config MACH_AP4EVB
 	bool "AP4EVB board"
 	depends on ARCH_SH7372
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 	select SH_LCD_MIPI_DSI
--- 0001/arch/arm/mach-shmobile/board-ap4evb.c
+++ work/arch/arm/mach-shmobile/board-ap4evb.c	2013-06-04 15:08:17.000000000 +0900
@@ -1321,7 +1321,10 @@ static void __init ap4evb_init(void)
 	pm_clk_add(&lcdc1_device.dev, "hdmi");
 }
 
+SHMOBILE_FIXUP(ap4evb, 0x40000000, 0x10000000)
+
 MACHINE_START(AP4EVB, "ap4evb")
+	.fixup		= ap4evb_fixup,
 	.map_io		= sh7372_map_io,
 	.init_early	= sh7372_add_early_devices,
 	.init_irq	= sh7372_init_irq,

[PATCH 04/06] ARM: shmobile: Bonito memory size fixup

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Specify the Bonito memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-bonito.c |    4 ++++
 2 files changed, 5 insertions(+)

--- 0006/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-06-04 15:11:54.000000000 +0900
@@ -120,6 +120,7 @@ config MACH_KOTA2
 config MACH_BONITO
 	bool "bonito board"
 	depends on ARCH_R8A7740
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
--- 0001/arch/arm/mach-shmobile/board-bonito.c
+++ work/arch/arm/mach-shmobile/board-bonito.c	2013-06-04 15:19:19.000000000 +0900
@@ -37,6 +37,7 @@
 #include <asm/mach/map.h>
 #include <asm/mach/time.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/setup.h>
 #include <mach/r8a7740.h>
 #include <mach/irqs.h>
 #include <video/sh_mobile_lcdc.h>
@@ -484,7 +485,10 @@ static void __init bonito_add_early_devi
 	r8a7740_add_early_devices();
 }
 
+SHMOBILE_FIXUP(bonito, 0x40000000, 0x20000000)
+
 MACHINE_START(BONITO, "bonito")
+	.fixup		= bonito_fixup,
 	.map_io		= bonito_map_io,
 	.init_early	= bonito_add_early_devices,
 	.init_irq	= r8a7740_init_irq,

[PATCH 05/06] ARM: shmobile: Kota2 memory size fixup

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Specify the Kota2 memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/Kconfig       |    1 +
 arch/arm/mach-shmobile/board-kota2.c |    4 ++++
 2 files changed, 5 insertions(+)

--- 0007/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-06-04 15:24:49.000000000 +0900
@@ -114,6 +114,7 @@ config MACH_MACKEREL
 config MACH_KOTA2
 	bool "KOTA2 board"
 	depends on ARCH_SH73A0
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
--- 0001/arch/arm/mach-shmobile/board-kota2.c
+++ work/arch/arm/mach-shmobile/board-kota2.c	2013-06-04 15:23:00.000000000 +0900
@@ -51,6 +51,7 @@
 #include <asm/mach/arch.h>
 #include <asm/mach/time.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/setup.h>
 #include <asm/traps.h>
 
 /* Dummy supplies, where voltage doesn't matter */
@@ -541,7 +542,10 @@ static void __init kota2_init(void)
 	platform_add_devices(kota2_devices, ARRAY_SIZE(kota2_devices));
 }
 
+SHMOBILE_FIXUP(kota2, 0x41000000, 0x1e000000)
+
 MACHINE_START(KOTA2, "kota2")
+	.fixup		= kota2_fixup,
 	.smp		= smp_ops(sh73a0_smp_ops),
 	.map_io		= sh73a0_map_io,
 	.init_early	= sh73a0_add_early_devices,

[PATCH 06/06] ARM: shmobile: Marzen memory size fixup

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Specify the Marzen memory configuration via
a board specific fixup callback, and also
select ATAGS to make sure the callback is
executed as expected.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/mach-shmobile/Kconfig        |    1 +
 arch/arm/mach-shmobile/board-marzen.c |    4 ++++
 2 files changed, 5 insertions(+)

--- 0008/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig	2013-06-04 15:30:05.000000000 +0900
@@ -143,6 +143,7 @@ config MACH_BOCKW
 config MACH_MARZEN
 	bool "MARZEN board"
 	depends on ARCH_R8A7779
+	select ATAGS
 	select ARCH_REQUIRE_GPIOLIB
 	select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
--- 0001/arch/arm/mach-shmobile/board-marzen.c
+++ work/arch/arm/mach-shmobile/board-marzen.c	2013-06-04 15:34:21.000000000 +0900
@@ -46,6 +46,7 @@
 #include <mach/irqs.h>
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
+#include <asm/setup.h>
 #include <asm/traps.h>
 
 /* Fixed 3.3V regulator to be used by SDHI0 */
@@ -409,7 +410,10 @@ static void __init marzen_init(void)
 	platform_add_devices(marzen_devices, ARRAY_SIZE(marzen_devices));
 }
 
+SHMOBILE_FIXUP(marzen, 0x60000000, 0x10000000)
+
 MACHINE_START(MARZEN, "marzen")
+	.fixup		= marzen_fixup,
 	.smp		= smp_ops(r8a7779_smp_ops),
 	.map_io		= r8a7779_map_io,
 	.init_early	= r8a7779_add_early_devices,

Re: [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Russell King - ARM Linux]

On Wed, Jun 05, 2013 at 04:34:18PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm@opensource.se>
> 
> Introduce SHMOBILE_FIXUP() as a helper function to
> allow boards to specify their memory base and size.

No.  I really don't like this idea (we've had people doing this in the
past and I went around removing all that crap, and adding command line
options into the defconfig files for those boards.)

I also fail to understand why in 2013, some 11 years after ATAG stuff
was created, people _still_ can't get pass correct information into
the kernel.

It's exactly this kind of issue which makes me believe that stuff like
ACPI, UEFI and DT are doomed to fail on ARM because this kind of problem
constantly crops up time and time again.  People have seem to have this
total inability to get the pre-kernel environment right.

Re: [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Magnus Damm]

Hi Russell,

On Thu, Jun 6, 2013 at 4:20 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jun 05, 2013 at 04:34:18PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> Introduce SHMOBILE_FIXUP() as a helper function to
>> allow boards to specify their memory base and size.
>
> No.  I really don't like this idea (we've had people doing this in the
> past and I went around removing all that crap, and adding command line
> options into the defconfig files for those boards.)
>
> I also fail to understand why in 2013, some 11 years after ATAG stuff
> was created, people _still_ can't get pass correct information into
> the kernel.
>
> It's exactly this kind of issue which makes me believe that stuff like
> ACPI, UEFI and DT are doomed to fail on ARM because this kind of problem
> constantly crops up time and time again.  People have seem to have this
> total inability to get the pre-kernel environment right.

Thanks for your comments. As you probably saw in patch 00/06, the goal
with this series is to remove CONFIG_MEMORY_START/SIZE from
mach-shmobile.

I myself am quite happy to keep on using the kernel configuration to
describe the main memory window like today, this is exactly how we
used to do it on SH as well. What is a bit difficult is that we for
mach-shmobile are requested to consolidate the kernel configurations
and move to CONFIG_MULTIPLATFORM.

My main concern is that I'd like to keep per-board memory
configuration somewhere, just removing it seems like a regression in
usefulness to me. Do you have any recommendation for me how to
proceed?

Thanks,

/ magnus

Re: [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Arnd Bergmann]

On Wednesday 05 June 2013, Russell King - ARM Linux wrote:
> On Wed, Jun 05, 2013 at 04:34:18PM +0900, Magnus Damm wrote:
> > From: Magnus Damm <damm@opensource.se>
> > 
> > Introduce SHMOBILE_FIXUP() as a helper function to
> > allow boards to specify their memory base and size.
> 
> No.  I really don't like this idea (we've had people doing this in the
> past and I went around removing all that crap, and adding command line
> options into the defconfig files for those boards.)
> 
> I also fail to understand why in 2013, some 11 years after ATAG stuff
> was created, people still can't get pass correct information into
> the kernel.
> 
> It's exactly this kind of issue which makes me believe that stuff like
> ACPI, UEFI and DT are doomed to fail on ARM because this kind of problem
> constantly crops up time and time again.  People have seem to have this
> total inability to get the pre-kernel environment right.

I think the problem in this case is that the pre-boot environment is
essentially nothing but mask rom jumping into head-shmobile.S, which
is something nobody else does.

My understanding is that you can also put a regular u-boot, kexec or
some other boot loader into the same place and get a running system with
correct ATAGS or DT information.

It's debatable whether booting the kernel directly without an upgradable
boot loader is a good idea, but since Renesas have come to depend on
this and it's been supported by Linux for ages (both on ARM and SH),
I would certainly not ask them to remove support for that.

What I think we can do however is move all that configuration into
one place of the kernel that is fairly separate from everything else.
head-shmobile.S already contains most of the special case, so
how about adding a configuration option that enables both the
head-shmobile.S code and contains the configuration for that in
a submenu?

	Arnd

Re: [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Arnd Bergmann]

On Thursday 06 June 2013, Magnus Damm wrote:
> Thanks for your comments. As you probably saw in patch 00/06, the goal
> with this series is to remove CONFIG_MEMORY_START/SIZE from
> mach-shmobile.
> 
> I myself am quite happy to keep on using the kernel configuration to
> describe the main memory window like today, this is exactly how we
> used to do it on SH as well. What is a bit difficult is that we for
> mach-shmobile are requested to consolidate the kernel configurations
> and move to CONFIG_MULTIPLATFORM.
> 
> My main concern is that I'd like to keep per-board memory
> configuration somewhere, just removing it seems like a regression in
> usefulness to me. Do you have any recommendation for me how to
> proceed?

Actually I think with an appended DTB file, you should be able to
pass the correct memory configuration per board just like everyone
else, even when booting directly from mask ROM. I understand that
you still have a long way to go before you can go DT-only for all
shmobile SoCs, so what we need is a way to bridge the mid-term
where you want to support that boot method on SoCs with incomplete
or missing DT support.

The easiest way is probably to declare that multiplatform booting
on shmobile is only supported for DT-enabled boards and that support
for non-DT booting will be removed at the same time as
non-multiplatform booting on shmobile. This is the same thing we are
doing e.g. on Exynos and the various Marvell embedded (non-PXA/MMP)
chips.  The time line for this not set yet, and I think that will
be one of the hot topics at this year's ARM subarch maintainer summit
that I hope we will have the chance to do during the kernel summit.
FWIW, my take on this is that at some point we will require both DT
and multiplatform for all ARMv6 and ARMv7 platforms anyway (not
for the older ones, in particular StrongARM and XScale), but we have
to come up with a timing that works for everyone.

	Arnd

Re: [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Magnus Damm]

Hi Arnd,

On Fri, Jun 7, 2013 at 2:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 06 June 2013, Magnus Damm wrote:
>> Thanks for your comments. As you probably saw in patch 00/06, the goal
>> with this series is to remove CONFIG_MEMORY_START/SIZE from
>> mach-shmobile.
>>
>> I myself am quite happy to keep on using the kernel configuration to
>> describe the main memory window like today, this is exactly how we
>> used to do it on SH as well. What is a bit difficult is that we for
>> mach-shmobile are requested to consolidate the kernel configurations
>> and move to CONFIG_MULTIPLATFORM.
>>
>> My main concern is that I'd like to keep per-board memory
>> configuration somewhere, just removing it seems like a regression in
>> usefulness to me. Do you have any recommendation for me how to
>> proceed?
>
> Actually I think with an appended DTB file, you should be able to
> pass the correct memory configuration per board just like everyone
> else, even when booting directly from mask ROM. I understand that
> you still have a long way to go before you can go DT-only for all
> shmobile SoCs, so what we need is a way to bridge the mid-term
> where you want to support that boot method on SoCs with incomplete
> or missing DT support.

The only two boards where we today boot from the reset vector and
actually need to provide this information to the kernel are Mackerel
and AP4EVB.

My approach with this series was more to make sure all boards keep on
working regardless what their boot loader pass. This since I too do
not trust the boot loader - especially on older boards. Perhaps the
more acceptable approach is to pretend to start trusting the
information by the boot loader and deal with the fallout if that
happens. Things may break when removing CONFIG_MEMORY_START/SIZE since
the MEM_SIZE and PHYS_OFFSET change in arch/arm/kernel/atags_parse.c

Anyway I can update my romImage series so it uses appended DTB with
both AP4EVB and Mackerel. Then this series can simply be thrown away.

> The easiest way is probably to declare that multiplatform booting
> on shmobile is only supported for DT-enabled boards and that support
> for non-DT booting will be removed at the same time as
> non-multiplatform booting on shmobile. This is the same thing we are
> doing e.g. on Exynos and the various Marvell embedded (non-PXA/MMP)
> chips.  The time line for this not set yet, and I think that will
> be one of the hot topics at this year's ARM subarch maintainer summit
> that I hope we will have the chance to do during the kernel summit.
> FWIW, my take on this is that at some point we will require both DT
> and multiplatform for all ARMv6 and ARMv7 platforms anyway (not
> for the older ones, in particular StrongARM and XScale), but we have
> to come up with a timing that works for everyone.

Yeah, I agree with your idea but I wonder about the timing. Actually,
I was thinking that the prime candidate boards for multiplatform are
our DT -reference boards. Still blocked on common clock framework
though... I will try to sort out the memory bits first.

Thanks,

/ magnus

Re: [PATCH 01/06] ARM: shmobile: Introduce SHMOBILE_FIXUP() helper

[Arnd Bergmann]

On Monday 10 June 2013, Magnus Damm wrote:
> On Fri, Jun 7, 2013 at 2:17 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 06 June 2013, Magnus Damm wrote:
> 
> My approach with this series was more to make sure all boards keep on
> working regardless what their boot loader pass. This since I too do
> not trust the boot loader - especially on older boards. Perhaps the
> more acceptable approach is to pretend to start trusting the
> information by the boot loader and deal with the fallout if that
> happens. Things may break when removing CONFIG_MEMORY_START/SIZE since
> the MEM_SIZE and PHYS_OFFSET change in arch/arm/kernel/atags_parse.c
> 
> Anyway I can update my romImage series so it uses appended DTB with
> both AP4EVB and Mackerel. Then this series can simply be thrown away.

That sounds like a good idea, but it seems that AP4EVB does not
yet use DT_MACHINE_START, so I suspect you will need more work.

> > The easiest way is probably to declare that multiplatform booting
> > on shmobile is only supported for DT-enabled boards and that support
> > for non-DT booting will be removed at the same time as
> > non-multiplatform booting on shmobile. This is the same thing we are
> > doing e.g. on Exynos and the various Marvell embedded (non-PXA/MMP)
> > chips.  The time line for this not set yet, and I think that will
> > be one of the hot topics at this year's ARM subarch maintainer summit
> > that I hope we will have the chance to do during the kernel summit.
> > FWIW, my take on this is that at some point we will require both DT
> > and multiplatform for all ARMv6 and ARMv7 platforms anyway (not
> > for the older ones, in particular StrongARM and XScale), but we have
> > to come up with a timing that works for everyone.
> 
> Yeah, I agree with your idea but I wonder about the timing. Actually,
> I was thinking that the prime candidate boards for multiplatform are
> our DT -reference boards. Still blocked on common clock framework
> though... I will try to sort out the memory bits first.

Ok.

	Arnd