ARM: mach-shmobile: DT_MACHINE and mach-type updates
[PATCH 01/03] mach-shmobile: Use DT_MACHINE for KZM9G
[PATCH 02/03] mach-shmobile: Use DT_MACHINE for armadillo 800 eva
[PATCH 03/03] ARM: Undelete KZM9D mach-type
These patches contain a few last minute updates for mach-shmobile.
There are two patches that convert recently added boards to make use
of DT_MACHINE_START(). Also, slightly unrelated to the new boards,
but the KZM9D mach-type is undeleted as well. This to allow build
of the EMEV2-based KZM9D board.
Signed-off-by: Magnus Damm <[email protected]>
---
Applies to linux-next 20120514
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 22 ++++++++++++++++++++++
arch/arm/boot/dts/sh73a0-kzm9g.dts | 22 ++++++++++++++++++++++
arch/arm/mach-shmobile/Kconfig | 2 ++
arch/arm/mach-shmobile/board-armadillo800eva.c | 8 +++++++-
arch/arm/mach-shmobile/board-kzm9g.c | 8 +++++++-
arch/arm/tools/mach-types | 1 +
6 files changed, 61 insertions(+), 2 deletions(-)
From: Magnus Damm <[email protected]>
Use DT_MACHINE_START() on the sh73a0 based KZM9G board.
Also include a tiny DTS file to describe the board and
update the Kconfig dependencies to select CONFIG_USE_OF.
Signed-off-by: Magnus Damm <[email protected]>
---
arch/arm/boot/dts/sh73a0-kzm9g.dts | 22 ++++++++++++++++++++++
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm/mach-shmobile/board-kzm9g.c | 8 +++++++-
3 files changed, 30 insertions(+), 1 deletion(-)
--- /dev/null
+++ work/arch/arm/boot/dts/sh73a0-kzm9g.dts 2012-05-14 18:37:52.000000000 +0900
@@ -0,0 +1,22 @@
+/*
+ * Device Tree Source for the KZM-A9-GT board
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "KZM-A9-GT";
+ compatible = "renesas,kzm9g";
+
+ memory {
+ device_type = "memory";
+ reg = <0x41000000 0x1e800000>;
+ };
+};
--- 0001/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig 2012-05-14 18:54:57.000000000 +0900
@@ -109,6 +109,7 @@ config MACH_KZM9G
bool "KZM-A9-GT board"
depends on ARCH_SH73A0
select ARCH_REQUIRE_GPIOLIB
+ select USE_OF
comment "SH-Mobile System Configuration"
--- 0001/arch/arm/mach-shmobile/board-kzm9g.c
+++ work/arch/arm/mach-shmobile/board-kzm9g.c 2012-05-14 18:33:43.000000000 +0900
@@ -443,7 +443,12 @@ static void __init kzm_init(void)
platform_add_devices(kzm_devices, ARRAY_SIZE(kzm_devices));
}
-MACHINE_START(KZM9G, "kzm9g")
+static const char *kzm9g_boards_compat_dt[] __initdata = {
+ "renesas,kzm9g",
+ NULL,
+};
+
+DT_MACHINE_START(KZM9G_DT, "kzm9g")
.map_io = sh73a0_map_io,
.init_early = sh73a0_add_early_devices,
.nr_irqs = NR_IRQS_LEGACY,
@@ -451,4 +456,5 @@ MACHINE_START(KZM9G, "kzm9g")
.handle_irq = gic_handle_irq,
.init_machine = kzm_init,
.timer = &shmobile_timer,
+ .dt_compat = kzm9g_boards_compat_dt,
MACHINE_END
From: Magnus Damm <[email protected]>
Use DT_MACHINE_START() on the r8a7740 based armadillo 800 eva board.
Also include a tiny DTS file to describe the board and update the
Kconfig dependencies to select CONFIG_USE_OF.
Signed-off-by: Magnus Damm <[email protected]>
---
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 22 ++++++++++++++++++++++
arch/arm/mach-shmobile/Kconfig | 1 +
arch/arm/mach-shmobile/board-armadillo800eva.c | 8 +++++++-
3 files changed, 30 insertions(+), 1 deletion(-)
--- /dev/null
+++ work/arch/arm/boot/dts/r8a7740-armadillo800eva.dts 2012-05-14 19:31:57.000000000 +0900
@@ -0,0 +1,22 @@
+/*
+ * Device Tree Source for the armadillo 800 eva board
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "armadillo 800 eva";
+ compatible = "renesas,armadillo800eva";
+
+ memory {
+ device_type = "memory";
+ reg = <0x40000000 0x20000000>;
+ };
+};
--- 0002/arch/arm/mach-shmobile/Kconfig
+++ work/arch/arm/mach-shmobile/Kconfig 2012-05-14 19:32:21.000000000 +0900
@@ -99,6 +99,7 @@ config MACH_ARMADILLO800EVA
bool "Armadillo-800 EVA board"
depends on ARCH_R8A7740
select ARCH_REQUIRE_GPIOLIB
+ select USE_OF
config MACH_MARZEN
bool "MARZEN board"
--- 0001/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ work/arch/arm/mach-shmobile/board-armadillo800eva.c 2012-05-14 19:35:27.000000000 +0900
@@ -768,11 +768,17 @@ static void __init eva_add_early_devices
shmobile_timer.init = eva_earlytimer_init;
}
-MACHINE_START(ARMADILLO800EVA, "armadillo800eva")
+static const char *eva_boards_compat_dt[] __initdata = {
+ "renesas,armadillo800eva",
+ NULL,
+};
+
+DT_MACHINE_START(ARMADILLO800EVA_DT, "armadillo800eva")
.map_io = r8a7740_map_io,
.init_early = eva_add_early_devices,
.init_irq = r8a7740_init_irq,
.handle_irq = shmobile_handle_irq_intc,
.init_machine = eva_init,
.timer = &shmobile_timer,
+ .dt_compat = eva_boards_compat_dt,
MACHINE_END
From: Magnus Damm <[email protected]>
Undelete the KZM9D mach-type to allow build of board
for EMEV2 SoC support.
Signed-off-by: Magnus Damm <[email protected]>
---
arch/arm/tools/mach-types | 1 +
1 file changed, 1 insertion(+)
--- 0001/arch/arm/tools/mach-types
+++ work/arch/arm/tools/mach-types 2012-05-14 19:38:03.000000000 +0900
@@ -530,6 +530,7 @@ nokia_rm680 MACH_NOKIA_RM680 NOKIA_RM68
msm8960_sim MACH_MSM8960_SIM MSM8960_SIM 3230
msm8960_rumi3 MACH_MSM8960_RUMI3 MSM8960_RUMI3 3231
gsia18s MACH_GSIA18S GSIA18S 3234
+kzm9d MACH_KZM9D KZM9D 3246
mx53_loco MACH_MX53_LOCO MX53_LOCO 3273
tx53 MACH_TX53 TX53 3279
encore MACH_ENCORE ENCORE 3284
On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
> From: Magnus Damm <[email protected]>
>
> Undelete the KZM9D mach-type to allow build of board
> for EMEV2 SoC support.
If you've converted to use DT for KZM9D, do you still need this?
On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <[email protected]>
>>
>> Undelete the KZM9D mach-type to allow build of board
>> for EMEV2 SoC support.
>
> If you've converted to use DT for KZM9D, do you still need this?
Good question. I guess it depends on how we want to make use of DT on
that piece of hardware. I do intend to convert the KZM9D board (not to
be mistaken for KZM9G!) to DT (and drop the generic EMEV2 SoC DT
unless someone really wants it at this timing), but I'm still not sure
if the SMP code in V2 is the way we want to do it. I suspect that
there is no way to support SMP without static entity mappings, so
perhaps I should rework that part and redo a V3? Or perhaps I should
interpret the EMEV2 silence as a good thing. =)
Unfortunately the KZM9D board only takes uImages, but good news is
that it actually feeds us the correct mach-type. This seems to be a
pretty common thing around here these days. I'm trying to get people
to actually store the DTB in the boot loader and pass it along, but
that seems rather far away at this point.
So with our current boot loader situation in mind I've been thinking
about adjusting the code in arch/arm/boot/compressed/head-shmobile.S
to check for the mach-type id and pass on a compiled-in DTB depending
on board type. This to allow us to build an uImage as usual and also
support multiple boards with a single kernel.
As you understand, the above plan will still make use of the mach-type
even now when we make more heavy use of DT. It seems like a rather
straightforward way to remain backwards compatible and still do DT,
but I'm not sure if such a solution would be acceptable by you, Arnd
and Olof. My plan right now is to try to cook up some code for the
above and see what feedback I get.
So yes, I'd like to make use of that mach-type entry unless there are
any objections.
Thanks for your help!
/ magnus
On Monday 14 May 2012, Magnus Damm wrote:
> On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
> <[email protected]> wrote:
> > On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
> >> From: Magnus Damm <[email protected]>
> >>
> >> Undelete the KZM9D mach-type to allow build of board
> >> for EMEV2 SoC support.
> >
> > If you've converted to use DT for KZM9D, do you still need this?
>
> Good question. I guess it depends on how we want to make use of DT on
> that piece of hardware. I do intend to convert the KZM9D board (not to
> be mistaken for KZM9G!) to DT (and drop the generic EMEV2 SoC DT
> unless someone really wants it at this timing), but I'm still not sure
> if the SMP code in V2 is the way we want to do it. I suspect that
> there is no way to support SMP without static entity mappings, so
> perhaps I should rework that part and redo a V3? Or perhaps I should
> interpret the EMEV2 silence as a good thing. =)
I don't understand why you want to have a KZM9D board file at all,
since it from looking at it, I can find nothing that is truely
board specific and doesn't already have bindings. This is different
from the other boards that you just converted to DT_MACHINE_START
but still left using individual board files because some bindings
are missing.
The only board specific device you add for KZM9D is smsc911x, and
that has bindings, all the other devices can just be hardcoded
for the soc because they are always the same, until we have bindings
for all of them. Am I missing something?
> Unfortunately the KZM9D board only takes uImages, but good news is
> that it actually feeds us the correct mach-type. This seems to be a
> pretty common thing around here these days. I'm trying to get people
> to actually store the DTB in the boot loader and pass it along, but
> that seems rather far away at this point.
The preferred way would be to store the dtb on the same medium that
contains the kernel, so you can update them together if necessary,
even though we try to keep dtb files compatible across kernel versions.
I would not want to rely on a hardcoded dtb file in the boot loader.
Arnd
On Tue, May 15, 2012 at 6:07 AM, Arnd Bergmann <[email protected]> wrote:
> On Monday 14 May 2012, Magnus Damm wrote:
>> On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
>> <[email protected]> wrote:
>> > On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
>> >> From: Magnus Damm <[email protected]>
>> >>
>> >> Undelete the KZM9D mach-type to allow build of board
>> >> for EMEV2 SoC support.
>> >
>> > If you've converted to use DT for KZM9D, do you still need this?
>>
>> Good question. I guess it depends on how we want to make use of DT on
>> that piece of hardware. I do intend to convert the KZM9D board (not to
>> be mistaken for KZM9G!) to DT (and drop the generic EMEV2 SoC DT
>> unless someone really wants it at this timing), but I'm still not sure
>> if the SMP code in V2 is the way we want to do it. I suspect that
>> there is no way to support SMP without static entity mappings, so
>> perhaps I should rework that part and redo a V3? Or perhaps I should
>> interpret the EMEV2 silence as a good thing. =)
>
> I don't understand why you want to have a KZM9D board file at all,
> since it from looking at it, I can find nothing that is truely
> board specific and doesn't already have bindings. This is different
> from the other boards that you just converted to DT_MACHINE_START
> but still left using individual board files because some bindings
> are missing.
>
> The only board specific device you add for KZM9D is smsc911x, and
> that has bindings, all the other devices can just be hardcoded
> for the soc because they are always the same, until we have bindings
> for all of them. Am I missing something?
Right, I understand your observation. Let me try to explain the reason
behind the board code - please excuse me not doing that in the first
place already.
So yes, in the EMEV2 case the serial port and timers have DT bindings.
Same for the already existing bindings for the SMSC chip. And I'm
working on a EMEV2 GPIO V2 and DT for that GPIO driver. So those are
moving along nicely.
Hardware that doesn't have any DT bindings at this point are: pinmux,
clocks and SMP.
Perhaps my view of DT support is somewhat odd, but I'm rather hesitant
to commit to DT for a SoC when I don't use DT for _all_ the hardware
blocks. As you can see in the EMEV2 SoC DT V2 patch I have
intentionally left out the clock setup dependency and there board code
is in the sad state that it assumes that the boot loader has done all
the work already. There is no SMP bindings in place either. So with
the clock portion missing the kernel is not really that useful as-is,
but I prefer that over locking ourselves into something we don't know
fully yet. On a SoC level that is.
The reason why I don't want to tie in the clock and the pinmux in a
static fashion on a SoC and release DT support is that I don't know to
migrate from that state to all-DT and still remain backwards
compatible. I'd be very happy to hear suggestions how to do that. If
this is possible without causing too much pain for the user then I
will of course go that way.
I am very comfortable doing things on a board level, like in the KZM9G
/ Armadillo EVA 800 cases. Perhaps I can adjust the EMEV2 KZM9D board
to follow that style? As for EMEV2 SoC DT, I prefer either keeping the
EMEV2 SoC DT V2 as-is with no clock, pinmux and SMP, or ditching the
EMEV2 SoC DT portion all together and go KZM9D DT board only.
What is your preference?
>> Unfortunately the KZM9D board only takes uImages, but good news is
>> that it actually feeds us the correct mach-type. This seems to be a
>> pretty common thing around here these days. I'm trying to get people
>> to actually store the DTB in the boot loader and pass it along, but
>> that seems rather far away at this point.
>
> The preferred way would be to store the dtb on the same medium that
> contains the kernel, so you can update them together if necessary,
> even though we try to keep dtb files compatible across kernel versions.
> I would not want to rely on a hardcoded dtb file in the boot loader.
Right, I agree. Relying on a fixed DTB in an unreliable boot loader is
the last thing I want to do.
So if your boot loader can't pass DTB to the kernel, and you want to
have a single kernel supporting multiple boards, then do you see
anything wrong with based on mach-type do a run time decision (in
arch/arm/boot/compressed/) to override the ATAG from the boot loader
with a compiled-in per-board DTB?
The alternative is to have a raw zImage and a set of DTB files and
force the user to manually append the DTB to the zImage depending on
board type. Seems a bit too manual process for my liking, so as you
probably are tired of hearing now - I prefer extending the boot code
to switch on something we already have - the mach-type - and then
based on that feed one of the compiled-in DTBs to the kernel.
I'll try to cook something up unless there are any objections.
Thanks for your help!
Cheers,
/ magnus
On Monday 14 May 2012, Magnus Damm wrote:
> On Tue, May 15, 2012 at 6:07 AM, Arnd Bergmann <[email protected]> wrote:
> > On Monday 14 May 2012, Magnus Damm wrote:
> >> On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
> >> <[email protected]> wrote:
> >> > On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
> >> >> From: Magnus Damm <[email protected]>
> >> >>
> >> >> Undelete the KZM9D mach-type to allow build of board
> >> >> for EMEV2 SoC support.
> >> >
> >> > If you've converted to use DT for KZM9D, do you still need this?
> >>
> >> Good question. I guess it depends on how we want to make use of DT on
> >> that piece of hardware. I do intend to convert the KZM9D board (not to
> >> be mistaken for KZM9G!) to DT (and drop the generic EMEV2 SoC DT
> >> unless someone really wants it at this timing), but I'm still not sure
> >> if the SMP code in V2 is the way we want to do it. I suspect that
> >> there is no way to support SMP without static entity mappings, so
> >> perhaps I should rework that part and redo a V3? Or perhaps I should
> >> interpret the EMEV2 silence as a good thing. =)
> >
> > I don't understand why you want to have a KZM9D board file at all,
> > since it from looking at it, I can find nothing that is truely
> > board specific and doesn't already have bindings. This is different
> > from the other boards that you just converted to DT_MACHINE_START
> > but still left using individual board files because some bindings
> > are missing.
> >
> > The only board specific device you add for KZM9D is smsc911x, and
> > that has bindings, all the other devices can just be hardcoded
> > for the soc because they are always the same, until we have bindings
> > for all of them. Am I missing something?
>
> Right, I understand your observation. Let me try to explain the reason
> behind the board code - please excuse me not doing that in the first
> place already.
>
> So yes, in the EMEV2 case the serial port and timers have DT bindings.
> Same for the already existing bindings for the SMSC chip. And I'm
> working on a EMEV2 GPIO V2 and DT for that GPIO driver. So those are
> moving along nicely.
>
> Hardware that doesn't have any DT bindings at this point are: pinmux,
> clocks and SMP.
>
> Perhaps my view of DT support is somewhat odd, but I'm rather hesitant
> to commit to DT for a SoC when I don't use DT for _all_ the hardware
> blocks. As you can see in the EMEV2 SoC DT V2 patch I have
> intentionally left out the clock setup dependency and there board code
> is in the sad state that it assumes that the boot loader has done all
> the work already. There is no SMP bindings in place either. So with
> the clock portion missing the kernel is not really that useful as-is,
> but I prefer that over locking ourselves into something we don't know
> fully yet. On a SoC level that is.
>
> The reason why I don't want to tie in the clock and the pinmux in a
> static fashion on a SoC and release DT support is that I don't know to
> migrate from that state to all-DT and still remain backwards
> compatible. I'd be very happy to hear suggestions how to do that. If
> this is possible without causing too much pain for the user then I
> will of course go that way.
This is different from what most other maintainers are doing: Generally
the migration to DT is done in small changes over multiple releases,
adding stuff to the dts file when it gets removed from the static
initialization. This is necessary in particular because there are no
bindings for DMA controllers yet, and until recently we had no
general bindings for pinctrl and clock at all, so nobody could
put those into the device tree.
We still see the DT bindings as work in progress at this moment,
at least on most platforms, so we don't yet expect them to be final.
Once we get to that point, the plan is that the DT maintainers
make a separate package with dts files outside of the kernel and
try much harder to keep that stable across kernel versions.
> I am very comfortable doing things on a board level, like in the KZM9G
> / Armadillo EVA 800 cases. Perhaps I can adjust the EMEV2 KZM9D board
> to follow that style? As for EMEV2 SoC DT, I prefer either keeping the
> EMEV2 SoC DT V2 as-is with no clock, pinmux and SMP, or ditching the
> EMEV2 SoC DT portion all together and go KZM9D DT board only.
>
> What is your preference?
I'll leave that up to you. Please make KZM9D use DT_MACHINE_START,
and do what fits your needs best for the generic EMEV2 machine
description. One possible alternative that I can see here is to
move the KZM9D support into the main EMEV2 file but keep the
specific "compatible" property for that, to ensure that we don't
get other boards to rely on generic EMEV2 implementation specifics
that you don't want to expose in DT yet.
> >> Unfortunately the KZM9D board only takes uImages, but good news is
> >> that it actually feeds us the correct mach-type. This seems to be a
> >> pretty common thing around here these days. I'm trying to get people
> >> to actually store the DTB in the boot loader and pass it along, but
> >> that seems rather far away at this point.
> >
> > The preferred way would be to store the dtb on the same medium that
> > contains the kernel, so you can update them together if necessary,
> > even though we try to keep dtb files compatible across kernel versions.
> > I would not want to rely on a hardcoded dtb file in the boot loader.
>
> Right, I agree. Relying on a fixed DTB in an unreliable boot loader is
> the last thing I want to do.
>
> So if your boot loader can't pass DTB to the kernel, and you want to
> have a single kernel supporting multiple boards, then do you see
> anything wrong with based on mach-type do a run time decision (in
> arch/arm/boot/compressed/) to override the ATAG from the boot loader
> with a compiled-in per-board DTB?
I know that we have discussed this in the past, but I don't remember
the outcome of the discussion, maybe someone else can help out here
(Grant?)
It's definitely technically possible to do it, but it could either be
that nobody has bothered to do the implementation, or that we had good
reasons against it and decided not to allow this.
> The alternative is to have a raw zImage and a set of DTB files and
> force the user to manually append the DTB to the zImage depending on
> board type. Seems a bit too manual process for my liking, so as you
> probably are tired of hearing now - I prefer extending the boot code
> to switch on something we already have - the mach-type - and then
> based on that feed one of the compiled-in DTBs to the kernel.
>
> I'll try to cook something up unless there are any objections.
Please hold on until we find someone who remembers what we discussed.
Arnd
On Tue, May 15, 2012 at 5:32 PM, Arnd Bergmann <[email protected]> wrote:
> On Monday 14 May 2012, Magnus Damm wrote:
>> On Tue, May 15, 2012 at 6:07 AM, Arnd Bergmann <[email protected]> wrote:
>> > On Monday 14 May 2012, Magnus Damm wrote:
>> >> On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
>> >> <[email protected]> wrote:
>> >> > On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
>> >> >> From: Magnus Damm <[email protected]>
>> >> >>
>> >> >> Undelete the KZM9D mach-type to allow build of board
>> >> >> for EMEV2 SoC support.
>> >> >
>> >> > If you've converted to use DT for KZM9D, do you still need this?
>> >>
>> >> Good question. I guess it depends on how we want to make use of DT on
>> >> that piece of hardware. I do intend to convert the KZM9D board (not to
>> >> be mistaken for KZM9G!) to DT (and drop the generic EMEV2 SoC DT
>> >> unless someone really wants it at this timing), but I'm still not sure
>> >> if the SMP code in V2 is the way we want to do it. I suspect that
>> >> there is no way to support SMP without static entity mappings, so
>> >> perhaps I should rework that part and redo a V3? Or perhaps I should
>> >> interpret the EMEV2 silence as a good thing. =)
>> >
>> > I don't understand why you want to have a KZM9D board file at all,
>> > since it from looking at it, I can find nothing that is truely
>> > board specific and doesn't already have bindings. This is different
>> > from the other boards that you just converted to DT_MACHINE_START
>> > but still left using individual board files because some bindings
>> > are missing.
>> >
>> > The only board specific device you add for KZM9D is smsc911x, and
>> > that has bindings, all the other devices can just be hardcoded
>> > for the soc because they are always the same, until we have bindings
>> > for all of them. Am I missing something?
>>
>> Right, I understand your observation. Let me try to explain the reason
>> behind the board code - please excuse me not doing that in the first
>> place already.
>>
>> So yes, in the EMEV2 case the serial port and timers have DT bindings.
>> Same for the already existing bindings for the SMSC chip. And I'm
>> working on a EMEV2 GPIO V2 and DT for that GPIO driver. So those are
>> moving along nicely.
>>
>> Hardware that doesn't have any DT bindings at this point are: pinmux,
>> clocks and SMP.
>>
>> Perhaps my view of DT support is somewhat odd, but I'm rather hesitant
>> to commit to DT for a SoC when I don't use DT for _all_ the hardware
>> blocks. As you can see in the EMEV2 SoC DT V2 patch I have
>> intentionally left out the clock setup dependency and there board code
>> is in the sad state that it assumes that the boot loader has done all
>> the work already. There is no SMP bindings in place either. So with
>> the clock portion missing the kernel is not really that useful as-is,
>> but I prefer that over locking ourselves into something we don't know
>> fully yet. On a SoC level that is.
>>
>> The reason why I don't want to tie in the clock and the pinmux in a
>> static fashion on a SoC and release DT support is that I don't know to
>> migrate from that state to all-DT and still remain backwards
>> compatible. I'd be very happy to hear suggestions how to do that. If
>> this is possible without causing too much pain for the user then I
>> will of course go that way.
>
> This is different from what most other maintainers are doing: Generally
> the migration to DT is done in small changes over multiple releases,
> adding stuff to the dts file when it gets removed from the static
> initialization. This is necessary in particular because there are no
> bindings for DMA controllers yet, and until recently we had no
> general bindings ?for pinctrl and clock at all, so nobody could
> put those into the device tree.
I understand. I guess in the EMEV2 case we can simply just add the
drivers with DT support upstream. We have the luxury of no DMA code
upstream for EMEV2 so I hope we can get it right directly. Perhaps I'm
aiming too high. =)
> We still see the DT bindings as work in progress at this moment,
> at least on most platforms, so we don't yet expect them to be final.
> Once we get to that point, the plan is that the DT maintainers
> make a separate package with dts files outside of the kernel and
> try much harder to keep that stable across kernel versions.
I see. I am a bit concerned with customers using DT in platform with
long support cycles like for automotive purpose for instance. As you
can tell by me being cautious when introducing DT support I'd really
like to avoid getting DT support code for the kernel written out of
tree and shipped to customers. Perhaps there is not so much I can do
about that regardless, but if possible I'd like to make it possible
for the "out of tree people" to still do their own thing, but with
platform devices instead of DT because we don't have the same binary
compatibility issue there.
>> I am very comfortable doing things on a board level, like in the KZM9G
>> / Armadillo EVA 800 cases. Perhaps I can adjust the EMEV2 KZM9D board
>> to follow that style? As for EMEV2 SoC DT, I prefer either keeping the
>> EMEV2 SoC DT V2 as-is with no clock, pinmux and SMP, or ditching the
>> EMEV2 SoC DT portion all together and go KZM9D DT board only.
>>
>> What is your preference?
>
> I'll leave that up to you. Please make KZM9D use DT_MACHINE_START,
> and do what fits your needs best for the generic EMEV2 machine
> description. One possible alternative that I can see here is to
> move the KZM9D support into the main EMEV2 file but keep the
> specific "compatible" property for that, to ensure that we don't
> get other boards to rely on generic EMEV2 implementation specifics
> that you don't want to expose in DT yet.
Ok. I will convert the code to use DT_MACHINE_START. Thanks!
So do you have any preference how to deal with SMP and the iotable?
Are you ok with the ioremap vs iotable code as-is in V2? I assume so!
>> >> Unfortunately the KZM9D board only takes uImages, but good news is
>> >> that it actually feeds us the correct mach-type. This seems to be a
>> >> pretty common thing around here these days. I'm trying to get people
>> >> to actually store the DTB in the boot loader and pass it along, but
>> >> that seems rather far away at this point.
>> >
>> > The preferred way would be to store the dtb on the same medium that
>> > contains the kernel, so you can update them together if necessary,
>> > even though we try to keep dtb files compatible across kernel versions.
>> > I would not want to rely on a hardcoded dtb file in the boot loader.
>>
>> Right, I agree. Relying on a fixed DTB in an unreliable boot loader is
>> the last thing I want to do.
>>
>> So if your boot loader can't pass DTB to the kernel, and you want to
>> have a single kernel supporting multiple boards, then do you see
>> anything wrong with based on mach-type do a run time decision (in
>> arch/arm/boot/compressed/) to override the ATAG from the boot loader
>> with a compiled-in per-board DTB?
>
> I know that we have discussed this in the past, but I don't remember
> the outcome of the discussion, maybe someone else can help out here
> (Grant?)
Thanks, any pointers would be greatly appreciated.
> It's definitely technically possible to do it, but it could either be
> that nobody has bothered to do the implementation, or that we had good
> reasons against it and decided not to allow this.
Yeah, it seems like a rather small piece of code that would help our
situation quite a bit. So I imagine that others may be in a similar
position which makes mei wonder why it hasn't been done already.
>> The alternative is to have a raw zImage and a set of DTB files and
>> force the user to manually append the DTB to the zImage depending on
>> board type. Seems a bit too manual process for my liking, so as you
>> probably are tired of hearing now - I prefer extending the boot code
>> to switch on something we already have - the mach-type - and then
>> based on that feed one of the compiled-in DTBs to the kernel.
>>
>> I'll try to cook something up unless there are any objections.
>
> Please hold on until we find someone who remembers what we discussed.
Sure, will do.
Thanks,
/ magnus
On Tue, 15 May 2012 08:32:09 +0000, Arnd Bergmann <[email protected]> wrote:
> On Monday 14 May 2012, Magnus Damm wrote:
> > Right, I agree. Relying on a fixed DTB in an unreliable boot loader is
> > the last thing I want to do.
> >
> > So if your boot loader can't pass DTB to the kernel, and you want to
> > have a single kernel supporting multiple boards, then do you see
> > anything wrong with based on mach-type do a run time decision (in
> > arch/arm/boot/compressed/) to override the ATAG from the boot loader
> > with a compiled-in per-board DTB?
>
> I know that we have discussed this in the past, but I don't remember
> the outcome of the discussion, maybe someone else can help out here
> (Grant?)
>
> It's definitely technically possible to do it, but it could either be
> that nobody has bothered to do the implementation, or that we had good
> reasons against it and decided not to allow this.
Tony and I talked about this quite a bit during the last Connect. The
plan is to extend the existing bootwrapper ATAGs to DT code to allow
appending multiple .dtbs to the zImage and selecting the correct one
based on the machine number. It shouldn't be very complicated, but I
haven't had time to implement it.
g.
On Tuesday 15 May 2012, Grant Likely wrote:
> On Tue, 15 May 2012 08:32:09 +0000, Arnd Bergmann <[email protected]> wrote:
> > On Monday 14 May 2012, Magnus Damm wrote:
> > > Right, I agree. Relying on a fixed DTB in an unreliable boot loader is
> > > the last thing I want to do.
> > >
> > > So if your boot loader can't pass DTB to the kernel, and you want to
> > > have a single kernel supporting multiple boards, then do you see
> > > anything wrong with based on mach-type do a run time decision (in
> > > arch/arm/boot/compressed/) to override the ATAG from the boot loader
> > > with a compiled-in per-board DTB?
> >
> > I know that we have discussed this in the past, but I don't remember
> > the outcome of the discussion, maybe someone else can help out here
> > (Grant?)
> >
> > It's definitely technically possible to do it, but it could either be
> > that nobody has bothered to do the implementation, or that we had good
> > reasons against it and decided not to allow this.
>
> Tony and I talked about this quite a bit during the last Connect. The
> plan is to extend the existing bootwrapper ATAGs to DT code to allow
> appending multiple .dtbs to the zImage and selecting the correct one
> based on the machine number. It shouldn't be very complicated, but I
> haven't had time to implement it.
Ok, good. so you are both on the same page then, Grant and Magnus.
I suppose you just need to coordinate then who is doing the work,
and it seems that Magnus is eager to prototype this.
Arnd
On Tuesday 15 May 2012, Magnus Damm wrote:
> On Tue, May 15, 2012 at 5:32 PM, Arnd Bergmann <[email protected]> wrote:
> > On Monday 14 May 2012, Magnus Damm wrote:
> >> On Tue, May 15, 2012 at 6:07 AM, Arnd Bergmann <[email protected]> wrote:
> >> > On Monday 14 May 2012, Magnus Damm wrote:
> > This is different from what most other maintainers are doing: Generally
> > the migration to DT is done in small changes over multiple releases,
> > adding stuff to the dts file when it gets removed from the static
> > initialization. This is necessary in particular because there are no
> > bindings for DMA controllers yet, and until recently we had no
> > general bindings for pinctrl and clock at all, so nobody could
> > put those into the device tree.
>
> I understand. I guess in the EMEV2 case we can simply just add the
> drivers with DT support upstream. We have the luxury of no DMA code
> upstream for EMEV2 so I hope we can get it right directly. Perhaps I'm
> aiming too high. =)
It can work, the spear platforms have recently been converted from
no DT support at all to completely being DT based, and the cortex-a9
based spear13xx platform that was added now was DT-only from the
start.
> > We still see the DT bindings as work in progress at this moment,
> > at least on most platforms, so we don't yet expect them to be final.
> > Once we get to that point, the plan is that the DT maintainers
> > make a separate package with dts files outside of the kernel and
> > try much harder to keep that stable across kernel versions.
>
> I see. I am a bit concerned with customers using DT in platform with
> long support cycles like for automotive purpose for instance. As you
> can tell by me being cautious when introducing DT support I'd really
> like to avoid getting DT support code for the kernel written out of
> tree and shipped to customers. Perhaps there is not so much I can do
> about that regardless, but if possible I'd like to make it possible
> for the "out of tree people" to still do their own thing, but with
> platform devices instead of DT because we don't have the same binary
> compatibility issue there.
ok, I see.
> > I'll leave that up to you. Please make KZM9D use DT_MACHINE_START,
> > and do what fits your needs best for the generic EMEV2 machine
> > description. One possible alternative that I can see here is to
> > move the KZM9D support into the main EMEV2 file but keep the
> > specific "compatible" property for that, to ensure that we don't
> > get other boards to rely on generic EMEV2 implementation specifics
> > that you don't want to expose in DT yet.
>
> Ok. I will convert the code to use DT_MACHINE_START. Thanks!
>
> So do you have any preference how to deal with SMP and the iotable?
> Are you ok with the ioremap vs iotable code as-is in V2? I assume so!
Yes, that looks all good.
> > It's definitely technically possible to do it, but it could either be
> > that nobody has bothered to do the implementation, or that we had good
> > reasons against it and decided not to allow this.
>
> Yeah, it seems like a rather small piece of code that would help our
> situation quite a bit. So I imagine that others may be in a similar
> position which makes mei wonder why it hasn't been done already.
It also came up in the discussion about making multiplatform kernels
DT-only, where someone asked about the same thing. So now that Grant
has clarified that it's actually what we plan to do anyway, I guess
you could start working on it if you're interested.
Arnd