[alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC

[Mark Brown]

On Fri, Jan 04, 2008 at 10:47:25AM +1100, David Gibson wrote:
> On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:

> > I'm no expert on this, but I think from the PowerPC point-of-view,
> > the *ideal* situation would be if the ASoC fabric driver were
> > generic, maybe even part of ASoC itself, and everything it needed
> > could be obtained from the device tree.

> Nice idea in principle, and may be the way to go ultimately, but very
> tricky in practice.  The whole reason the fabric driver concept exists
> (from other archs) is that there are an awful lot of variants on how
> to wire the sound components together.  Devising a way of expressing
> those connections in the device tree that's sufficient will be very
> curly.  Then we'd have to build the fabric driver that can parse and
> process them all.

Yes, there's an issue with complexity here.  Some of the individual
components are going to have quite a lot of different things to
configure by themselves even for static use and the choices made may
depend on the usage at run time rather than being a static property of
the hardware.  It's also more than just connections - many machine
drivers will provide control for components like analogue switches or
simple amplifiers controlled through GPIO lines or memory mapped
registers (these are generally specific to the board).

As a result I would expect that you will always have systems using
platform based drivers.  I don't think that this is a bad thing -
something that can completely replace them would be able to do anything
that can be done in C in the kernel.

>                    And then, people will no doubt produce device trees
> with errors in the connection information, so we'll still need
> platform-specific workarounds.

The other concern with this is that it risks turning the interface to
the codec and controller drivers into an ABI which isn't expected at the
minute and might cause problems in the future.  At the minute the
drivers export constants to their users defining the parameters they
can configure and (for things like source selection) the possible
values.  These can currently be changed at will and there's no great
consistency in their values between drivers.

There would also be difficulties in writing the device tree - without
the symbolic names you're going to end up with strings of numeric
constants in the device tree which are not going to be terribly readable
and will be error prone.

> If we want sound working any time soon, we'll want to stick with the
> platform based fabric drivers for the time being.

Like I say, I would expect that you're always going to want to have
platform based drivers.  Even if a given board can be represented in a
device tree some users will find it more straightforward or convenient
to write C code for their platform and have the device tree specify more
basic configuration options that correspond to the things they want to
vary between boards.