[alsa-devel] Thoughts on ASOC v2 driver architecture
Mark Brown
broonie at opensource.wolfsonmicro.com
Mon Jun 16 18:58:53 CEST 2008
On Mon, Jun 16, 2008 at 12:11:31PM -0400, Jon Smirl wrote:
> A more familiar example of this problem is unified graphics drivers.
> NVidia probably has 100 variations on their GPUs. They used to have
Yes, nothing you're doing should be this difficult - it's a very
standard problem. AFAICT the main issue you're running into here is
that the way the PowerPC device trees are done it's difficult for you to
idomatically do things based on the board type you're running on.
I'm wondering if it might be worth adding some sort of infrastructure
which would allow drivers to load based on the machine type - not by
defining a device type, just by saying "load me on board X"? This would
be very similar to how DMI information is used on x86 systems to handle
similar situations.
> To do this I'll put all of the device drivers on an initrd. Then as
> the kernel processes the device tree the right drivers will get
> loaded. After the boot process is finished the initrd and unused
> drivers disappear. Moving the fabric device creation in the my
> equivalent of arch/powerpc/platforms/86xx/mpc8610_hpcd.c will let me
> do this.
That's pretty much how most platforms using platform devices would
handle this.
> BTW, if you read in /Documentation about platform drivers they say not
> to make the devices in the module init function because it causes
> problems like the one I'm having.
Right, and this is not expected to happen in production ASoC v2 drivers
- for ARM boards the idomatic thing would be for the setup to happen in
board specific initialisation code under arch/arm.
More information about the Alsa-devel
mailing list