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.