[alsa-devel] Dynamically registering a codec

Mark Brown broonie at opensource.wolfsonmicro.com
Thu May 14 19:40:32 CEST 2009


On Thu, 2009-05-14 at 12:43 -0400, Jon Smirl wrote:
> > My main objection is to your abuse of platform devices here - there is
> > no need for this on non-PowerPC platforms and a platform device affects
> > everyone. So long as you come up with a solution that does not impact
> > other platforms I'm less worried.

> This is the part you don't like?
> +static void __init efika_declare_platform_devices(void)
> +{

That bit's OK - it's the device you've added for the CODEC which is
concerning me.

> on an Efika it can exit. There were multiple discussions about this on
> the ppc list. The conclusion was that the mess of wires on the
> mainboard implementing audio really was a platform device.

I agree, this is the most sensible way to handle machine drivers.

> There is a general kernel design problem in that there is no automated
> way to load something like an audio fabric driver. The Efika fabric
> driver is just example code, my Digispeaker hardware requires a board
> specific fabric driver since it has an external audio clock chip.
> Digispeaker drivers will come later after we decide on the final
> hardware design.

It's only really a problem on platforms using the device tree,
everything else can happily define random Linux-specific platform
devices in the board initialisation code and everything is happy.

> The problem with fabric drivers is that they are optional and ALSA
> drivers can load in any order. That requires a mechanism to say
> registration time is now closed, proceed without waiting for a fabric
> driver. The core could be changed to remove this requirement by
> imposing ordering constraints on driver registration.

Indeed - this is only a problem due to the fact that you're trying to
provide a generic machine driver.



More information about the Alsa-devel mailing list