[PATCH 03/03] ARM: Undelete KZM9D mach-type

Tue May 15 04:32:09 EDT 2012

On Monday 14 May 2012, Magnus Damm wrote:
> On Tue, May 15, 2012 at 6:07 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Monday 14 May 2012, Magnus Damm wrote:
> >> On Mon, May 14, 2012 at 9:30 PM, Russell King - ARM Linux
> >> <linux at arm.linux.org.uk> wrote:
> >> > On Mon, May 14, 2012 at 07:54:51PM +0900, Magnus Damm wrote:
> >> >> From: Magnus Damm <damm at opensource.se>
> >> >>
> >> >> 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