[alsa-devel] Thoughts on ASOC v2 driver architecture
timur at freescale.com
Tue Jun 17 16:55:05 CEST 2008
Jon Smirl wrote:
> The architecture still doesn't appear right to me. fsl-dma.c is
> another driver that is self-creating its own device.
Well, giving it its own device makes it easier to create sysfs entries.
> We can certainly
> add code to arch/powerpc/platforms/86xx/mpc8610_hpcd.c to create a
> "fsl-elo" device, but it's another fake device.
I don't understand your penchant for putting code in the wrong drivers. First
it's fabric code in the SSI driver. And now you want DMA code in the platform
> Plus there's already a
> driver for the real "fsl,eloplus-dma" hardware in the system.
The DMA nodes that the DMA driver is supposed to use are marked with a different
compatible property (I haven't figured out exactly what). This prevents the
standard DMA driver from touching them.
> to create fake devices is a sign that the design is not correct.
That sounds like an overgeneralization to me.
> support should probably be a library that is linked into the ssi
> driver and not be a standalone device driver.
Each SSI needs two specific DMA channels. I suppose we could augment ASoC to
figure out which channels map to which SSI, but that's a lot of extra work. I
don't know if it's possible to support all architectures with a model like that.
> If you do it in
> the fabric driver, then the fabric driver can never be optional.
I don't have any problem with that at all.
Linux kernel developer at Freescale
More information about the Alsa-devel