Re: Thoughts on ASOC v2 driver architecture

[Timur Tabi <timur@freescale.com>]

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
driver.

> 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.

> Needing
> to create fake devices is a sign that the design is not correct. 

That sounds like an overgeneralization to me.

> dma
> 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.

-- 
Timur Tabi
Linux kernel developer at Freescale