Re: [RFC] [PATCH] Device Tree on ARM platform

Russell King - ARM Linux
2009-05-31T10:53:56Z

On Fri, May 29, 2009 at 10:51:14AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-05-28 at 17:04 +0200, Sascha Hauer wrote:
> >
> > We normally hide these subtle details behind a baseboard= kernel
> > parameter. I agree with you that it's far better to have a
> > standardized
> > way to specify this. For my taste the oftree is too bloated for this
> > purpose.
>
> Define "bloated" ?
>
> We got a lot of push back on powerpc initially with this exact same
> argument "too bloated" but that was never backed up with facts and
> numbers, and I would mostly say that nobody makes it anymore now
> that it's there and people use it.

It really depends how you look at it.

If you look at the amount of supporting code required for one platform
on ARM, it's typically fairly small - mostly just declaration of data
structures (platform devices, platform device data), and possibly a few
small functions to handle the quirkyness of the platform. That's of the
order of a few K of data and code combined - that's on average about 4K.
Add in the SoC platform device declaration code, and maybe add another
10K.

So, about 14K of code and data.

The OF support code in drivers/of is about 3K. The code posted at the
start of this thread I suspect will be about 4K or so, which gives us a
running total of maybe 7K.

What's now missing is conversion of drivers and the like to be DT
compatible, or creation of the platform devices to translate DT into
platform devices and their associated platform device data. Plus
some way to handle the platforms quirks, which as discussed would be
hard to represent in DT.

So I suspect it's actually marginal whether DT turns out to be larger
than our current approach. So I agree with BenH - I don't think there's
an argument to be made about 'bloat' here.

What /does/ concern me is what I percieve as the need to separate the
platform quirks from the description of the platform - so rather than
having a single file describing the entire platform (eg,
arch/arm/mach-pxa/lubbock.c) we would need:

- a file to create the DT information
- a separate .c file in the kernel containing code to handle the
platforms quirks, or a bunch of new DT drivers to do the same
- ensure both DT and quirks are properly in-sync.

But... we need to see how Grant gets on with his PXA trial before we
can properly assess this.