Date:	Thu, 28 May 2009 16:32:40 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	David Miller <davem@...emloft.net>, r.schwebel@...gutronix.de,
	scottwood@...escale.com, devicetree-discuss@...abs.org,
	linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, yuan-bo.ye@...orola.com,
	timur@...escale.com, rmk@....linux.org.uk
Subject: Re: [RFC] [PATCH] Device Tree on ARM platform

On Thu, May 28, 2009 at 4:37 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Wed, May 27, 2009 at 05:15:25PM -0700, David Miller wrote:
>> From: Robert Schwebel <r.schwebel@...gutronix.de>
>
>> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists