[U-Boot] [RFC PATCH 0/4 v1] Use fdt to init mvrtc driver for dreamplug

Jason
2011-09-15T19:46:42Z

On Thu, Sep 15, 2011 at 12:16:11PM -0700, Simon Glass wrote:
> On Thu, Sep 15, 2011 at 6:54 AM, Jason Cooper <u-boot@lakedaemon.net> wrote:
> > To make this work, I applied v2 of Simon Glass' patch series (what this
> > email is in reply to) against v2011.09-rc1. ?I then cherry picked my
> > dreamplug board support patch. ?Last, I applied the following series.
> >
> > It works, although with CONFIG_OF_EMBED. ?I haven't tried _SEPARATE yet.
>
> Please do, as that is what we really want people to use.

Ok.

> > Some thoughts:
...
> > 3.) Since mach names (dreamplug) and SoC names (kirkwood) are unique,
> > ? ?should we put all .dts and .dtsi files in one dir? ?eg /dts ? ?This
> > ? ?would facilitate migration to Grant Likely's device-tree.git
> > ? ?whereever and whenever it lands. ?This is also similar to how Linux
> > ? ?currently does it (arch/arm/boot/dts/)
>
> It does have advantages, although (hopefully) the number of files will
> grow quite large. But bear in mind that people will create their own
> .dtsi files, so we will need a strong naming convention there also
> (always use the board prefix perhaps).

Wouldn't they be creating their own board .dts files, that /include/s
the SoC .dtsi?

> If we want to be similar to Linux they should go in arch/<arch>/dts,
> but then we are putting board description files outside the board/
> structure, which doesn't seem right. The arch/arm/ subdir is supposed
> to be for arch-specific code which is generic across boards. Remember
> that the dts will include board things, not just SOC things.
>
> Clearly we don't want .dts files in boards/ and even boards/dts seems
> odd since all the other files are in board/<vendor>. Hmm I quite like
> having them in board/<vendor>/dts.

Funny, that's exactly what I did at first (board/Marvell/dts/) when
creating this patchset. It failed to build, so I conformed just to get
it working. So, board/<vendor>/dts/ feels natural. Must be right,
then. ;-)

I'm currently working on my second driver (mvgbe ethernet) and having a
good time trying to find the interrupt controller for kirkwood. I'll
try _SEPARATE after I get something testable for it.

thx,

Jason.