On Wed, May 27, 2009 at 05:15:25PM -0700, David Miller wrote: > From: Robert Schwebel <[email protected]>
> > It works badly for corner cases, and embedded land is full > > of it. The effort to get the oftree stuff right is often more than a > > magnitude of order higher than the effort for the actual functionality. > > That should be an alarm sign that something is wrong. > And here you speak about the negatives purely in generalities that > cannot be discussed concretely. > And, sadly, I think this is on purpose. A concrete example that was mentioned elsewhere in the thread is audio subsystems. The audio subsystem for an embedded system will contain multiple chips - a mobile phone could have the CPU, an audio CODEC, bluetooth and GSM for example. These will be interconnected by a combination of analogue and digital links. The digital links consist of six wires (data, sync clock and bit clock for each of transmit and recieve), some of which may be tied together in hardware. Some of these links may be shared either with switches or using TDM. The devices will also have master clocks from various sources and will often have PLLs or FLLs able to generate clocks if the inputs aren't directly usable. Each clock domain within the audio subsystem will need some level of synchronisation of the clocks and there may be multiple clock domains within the system. In principle we could describe the links between the devices, provide some additional use case based constraints then take this information and figure out a suitable runtime configuration automatically; this is probably the only viable OS neutral way of doing things. In practice we're nowhere near having a clock framework which is able to support implementing this. The current approach is to write custom code that knows a suitable way to set things up in a given system (which is a much more tractable problem). The PowerPC people have mostly accepted using this approach but they're really not happy with it and it's been difficult to get the general community understanding that it's hard to cope with this in the device tree. _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
