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

[jonsmirl at gmail.com]

On Thu, Aug 1, 2013 at 9:34 AM, jonsmirl at gmail.com <jonsmirl at gmail.com> wrote:
> On Thu, Aug 1, 2013 at 6:18 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> On Wed, 2013-07-31 at 17:26 -0400, jonsmirl at gmail.com 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.

5) this scheme supports future improvements in the DT schema. Lets say
initially we had punted power management to board specific code.
Then in a later kernel version implemented it using device trees. The
quirk system lets you delete the board specific code and replace it
with a DT quirk. That DT quirk will see your deployed DTs at boot time
and add in the new, fancy power management DT attributes.  The new
generic DT based power power management code will see these attributes
added by the quirk and do the right thing. This gives us a way to
slowly remove move board specific code if we choose to.



>
>
>>
>> --
>> dwmw2
>>
>
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com



-- 
Jon Smirl
jonsmirl at gmail.com