[alsa-devel] Thoughts on ASOC v2 driver architecture

[Mark Brown]

On Mon, Jun 16, 2008 at 11:53:27AM -0400, Jon Smirl wrote:

> static struct platform_device codec = {
> 	.name		= "wm9713-codec",
> 	.id		= -1,
> };

> static struct platform_device platform = {
> 	.name		= "Mainstone-WM9713",
> 	.id		= -1,
> };

> The drivers are creating their own platform devices. Constructing them
> in the driver builds in the assumption that if the driver is loaded,
> then the devices are present.  But that's not right in my case, I have
> four fabric drivers built in and I only want one of them active.

The above is a bodge on two fronts:

 - Currently ASoC doesn't autoprobe AC97 devices (in part because the
   general kernel infrastructure doesn't handle AC97 devices too well,
   in part because V1 didn't).  The platform device is a workaround for
   this.  Hopefully once V2 is out someone will look into this - it'll
   need some hoops jumping through to allow the system to handle clock
   configuration issues at startup.

 - The hardware that's being controlled here is not a standard part of
   the Mainstone hardware, it's a plugin module for them and there's no
   programmatic way to identify exactly what's on one of these boards.
   The devices are registered at module load since the only way to tell
   what's plugged in is via visual inspection of the hardware.

The ideal thing for ARM platforms like this would be that the machine
init code would register appropriate platform devices, allowing the
platform device autoload support to do its thing.