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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
