Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have peopleinterested in device tree janitoring / cleanup?]

[jonsmirl@xxxxxxxxx]

On Thu, Aug 1, 2013 at 6:18 AM, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
> On Wed, 2013-07-31 at 17:26 -0400, jonsmirl@xxxxxxxxx wrote:
>> Alternatively you may be of the belief that it is impossible to get
>> rid of the board specific code. But x86 doesn't have any of it, why
>> should ARM?
>
> The reason x86 doesn't have it is because it carries three decades worth
> of legacy baggage so that it can still look like a 1980s IBM PC when
> necessary.
>
> There *have* been some x86 platforms which abandon that legacy crap, and
> for those we *do* have board-specific code. (Is James still maintaining
> Voyager support? It feels very strange to talk about Voyager with it
> *not* being the 'legacy crap' in question...)
>
> We've even seen *recent* attempts to abandon the legacy crap in the
> embedded x86 space, which backtracked and added it all back again — in
> part because x86 lacked any sane way to describe the hardware if it
> wasn't pretending to be a PC. ACPI doesn't cut it, and DT "wasn't
> invented here"...
>
> Unless you want the ARM world to settle on a strategy of "all the world
> is an Assabet", I'd be careful what you wish for...

So there should be shades for gray in this area. Try to eliminate all
of the board specific code you can, and then only if that fails add
board specific support to the kernel.

But you take device trees pretty far. I believe Grant has even used
one to describe an FPGA that he can dynamically load code into and
change its function.  Not sure how he did it, I wasn't paying too
close of attention when he was talking about it.

I do believe a great deal of this simple plumbing can be eliminated.
Like how to hook up GPIO, I2C, SPI, etc. We're pretty far down that
road.

A path like this seems like it would be beneficial...
1) Implement DT schemas. Use those to enforce as much regularity as
possible into the device tree descriptions for common classes of
things (controllers especially - DMA, I2C, I2S, SPI, Uarts, etc)..
Form a group to review any changes to the common schema.
2) Cleaning up the controller classes is going to cause some DT churn.
Hide backward compatibility in a quirks layer.
3) Continue the process of removing all possible board specific code
that can be reasonably covered in device trees.
4) There will be some board specific code left at the end of this
process. But anyone who looks at should agree that the functions
handled by the code are something that is unreasonable to address in
the DT system.


>
> --
> dwmw2
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/