Re: [RFC] [PATCH] Device Tree on ARM platform
From: Grant Likely
Date: Thu May 28 2009 - 18:33:16 EST
On Thu, May 28, 2009 at 4:37 AM, Mark Brown
> On Wed, May 27, 2009 at 05:15:25PM -0700, David Miller wrote:
>> From: Robert Schwebel <r.schwebel@xxxxxxxxxxxxxx>
>> > 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.
I should clarify my position. I want to make sure the simple things
are described in the device tree and have a generic block of code in
the kernel that can wire them up (the whole simple-of thing is a hacky
and half-assed example of this). However, when it comes to complex
configurations that cannot be easily described, I'm all for using
platform specific code.
In fact, I may have been premature in pursuing the generic description
and generic fabric driver approach for the MPC5200 audio driver. It
may have been better to get a few similar MPC5200 boards under our
belt before trying to identifying the common cases.
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/