LWN: Comments on "ELCE: Grant Likely on device trees"

ELCE: Grant Likely on device trees

dlang — Tue, 23 Nov 2010 22:45:44 +0000

I'm confused, the arguments against device trees seem to be that they have C code to document every eval board so they don't need device trees.

the arguments _for_ device trees seems to be that real-world devices largely contain the same types of devices as you find on eval boards, but hooked up in different ways, so the device tree tells the system how they are hooked up without having to have every system be it's own defineition in C.

ELCE: Grant Likely on device trees

jgg — Tue, 23 Nov 2010 22:35:51 +0000

I recently converted some old PPC code from the 'C' way to the device tree way and for the most part things were about the same.

However, what really made a big difference was how much device tree cleans up the mess of GPIO, MDIO, I2C and other ancillary stuff.

For instance our SOCs have a ethernet MAC driver that needs to speak to the PHY using MDIO over a certain bus. The bus, address and PHY chip changes depending on the platform, and several ethernet MACs often have to share the same MDIO. With device tree we specify all these relationships in the DT and things work great. The proper phy driver is loaded and attached to the MDIO, the proper MAC attaches to that, etc.

Something similar happens with I2C as well, I2C auto probing doesn't work for real embedded systems, DTS cleans that up wonderfully. The C version it replaced was horrid.

Frankly, I'm surprised at the reluctance from the ARM community. Just expressing the existing C code to setup each unique platform as a device tree and hard-wiring the tree into the kernel would clean things up a lot, without really changing how anything functions.

The arguments I've seen for DT seem to think all the world is an eval board. I've never implemented an embedded CPU that matched an eval board exactly - we *always* change things. Generally we've had to #ifdef through the BSP for the eval board to get things working, it is an ugly mess that won't be upstreamed.

ELCE: Grant Likely on device trees

giraffedata — Fri, 12 Nov 2010 23:48:36 +0000

The most important of these is the compatible property that uniquely defines devices

It does nothing of the kind. compatible classifies the device according to how you use it -- it essentially tells you what device driver to use for it. Lots of devices have the same compatible property and it normally takes additional properties to completely and uniquely define any one of these.

ELCE: Grant Likely on device trees

etienne — Thu, 11 Nov 2010 12:16:28 +0000

Well, I do not see the problem of having:
serial_irq = 3;
network_irq = 4;
in the linker microcontroller-dependant-file,
and you can include explicit data in this file too:
http://sourceware.org/binutils/docs-2.20/ld/Output-Sectio...
You could even include binary blob if that is your aim.

ELCE: Grant Likely on device trees

kronos — Thu, 11 Nov 2010 11:39:50 +0000

You can add information about addresses and interrupts (and also device specific data) to the tree. There are example on http://devicetree.org

ELCE: Grant Likely on device trees

etienne — Thu, 11 Nov 2010 11:10:51 +0000

I still would like to know what is better using a device tree than using a standard relocatable (common to all ARM) kernel and running a last linker command for each ARM configuration.
Anyway, if the bus cannot be queried for what it contains and at which address - that means that those address are constant and at some point the kernel has to know them.
So the same kernel with few relocations would be distributed to all ARMs targets, and each target would have to do a partial and final "ld" with a linker command file containning something like:

smc91c111_base = 0x1532000;
rtc_ds1338_v1 = 0;
rtc_ds1338_v2 = 0x15325000;
memcpy = memcopy_cortex_a9;

Each driver should check that the base address of its device is not null before trying to initialise itself.
If a higher level description is needed, a tool can be used to generate that linker command file.
Maybe there is something I am missing?

ELCE: Grant Likely on device trees

glikely — Thu, 11 Nov 2010 05:40:31 +0000

Thanks for the coverage Jake.

A few words of clarification: First off, while I was peripherally involved with the initial migration of all powerpc support to use a device tree, the credit for most of the heavy lifting goes to others like Paul Mackerras, Ben Herrenschmidt, Becky Bruce, David Gibson and others. I'm building on their work, and many thanks go to tbem.

Second, while I know that Canonical and Linaro are both committed to device tree support, I cannot comment on Google's plans. As it stands, Brian Swetland from Android has eloquently expressed his skepticism about the device tree approach and has no intention of using it (which is fine; the current code allows dt and non-dt platforms to coexist. Board ports are not forced to use a dt).