Re: [RFC] [PATCH] Device Tree on ARM platform

[Grant Likely]

On Thu, May 28, 2009 at 4:37 AM, Mark Brown
<broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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.

g.

-- 
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/