On Thu, Aug 1, 2013 at 9:34 AM, jonsmirl at gmail.com [off-list ref] wrote:

On Thu, Aug 1, 2013 at 6:18 AM, David Woodhouse [off-list ref] wrote:

quoted

On Wed, 2013-07-31 at 17:26 -0400, jonsmirl at gmail.com wrote:

quoted

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.

quoted

--
dwmw2

--
Jon Smirl
jonsmirl at gmail.com

-- 
Jon Smirl
jonsmirl at gmail.com