KS2009: Generic device trees

Posted Nov 4, 2009 10:00 UTC (Wed) by HalfMoon (guest, #3211) [Link]

Those trees are a way to communicate standard information. But embedded boards have little of that. They're heavy on the customization, the one-off, the new-in-this-revision stuff.

See, that's the reason these "trees" don't work so well. Hardware is very customizable. New chips come out all the time and they need a lot more information. This one has a dozen pins for random uses that drivers need to understand about, or in some cases board setup code. Three other variants of the chip have *different* uses for those pins, and need very different configuration. NOT STANDARD. Gotta come up with some way to cram it into the device tree. Committee negotiations slow that process down. Multiply that by, say, six instances of that problem on your new board that's got to enter testing next quarter...

And when you get to the point where some "device tree" can solve that ... you're really just growing chip-specific customizations, which still require C code to handle. At that point, there's no benefit to having to come up with some board or chip specific declarations in the "device" tree and then come up with corresponding C code. Easier to just have the C code to cope with, and to do it without needing to involve outside "experts" who have their own ideas about how your hardware should work, and don't have your own product timetables (or success) as priorities. Who may want some fancy Architecting before they add new mechanisms...

The reason some folk like that stuff is that when you can use it, you're starting with a simple problem. That's why there's a time saving: they're both derived from having simple hardware. But a LOT of hardware is nowhere near simple — or regular! — enough to use that approach.