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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
