[alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Mark Brown
broonie at opensource.wolfsonmicro.com
Wed Apr 28 23:00:37 EST 2010
On Wed, Apr 28, 2010 at 02:25:29PM +1000, Benjamin Herrenschmidt wrote:
> I'd stay stick to the basics and move incrementally up until it stops
> making sense:
> - First, the basics: nodes for actual physical devices. i2c codecs on
> their i2c busses, DMA controllers, etc...
This is already supported by the ASoC core and has been for about a year
or so, it just needs the device drivers to make use of it. IIRC the
drivers relevant to PowerPC are pretty much doing so already, but I
didn't actually check.
> - From there, see what simple properties are better off being put in
> those respective nodes because they represent common enough variants of
> functionality or simply because they are specific attributes of a given
> device that aren't too concerned by the way things are interconnected.
This one is just a case of writing boiler plate for the existing
platform data devices have to convert that from device tree into the
existing formats. It's not a monumentally edifying task, but I don't
think we really need to worry about it here.
> - Provide at least one identifier (either in a "sound" virtual device,
> or just use the board's own "compatible" property) to have a .c file to
> put everything together.
This has been the big sticking point so far. It has been difficult to
get people to accept this idea at all, the idea that there may be more
to the machine specific setup than can be readily expressed in static
data and might even vary dynamically at runtime is what seems to upset
people. I've been told on a number of occasions that instantiating
machine specific code that's not part of a specific chip is very
difficult and would cause the device tree to be horribly buggy.
What you're suggesting here is exactly what is supposed to happen from
an ASoC point of view.
> The whole thing is a matter of common sense and a bit of taste :-)
The impression that has been created in the past is that there are
inflexible device tree rules which can't be varied.
More information about the Linuxppc-dev
mailing list