Hi Vinod, again > > > I'm not saying you need to, I just wanted to raise the issue. From what I > > > understood Vinod was also having doubts on using the DMA engine API for this > > > device, given that it doesn't really match what the DMA engine API has been > > > designed for. If everybody else is fine with your patches, and if the sound DT > > > nodes are not considered overly complex with the DMA engine bindings, then I > > > have no objection. > > Laurent is right in his observations, When I last reviewed the series > > (though have looked at this one yet), the advise was to use dmaengine APIs > > with sound dmanengine library for 1st DMAC. The second DMAC is specfic to > > this device so should be handled internally or as part of the sound driver > > (or whatever client) > > So, is this mean we can't use DMAEngine style if it was non-generic DMAC ? > For Example, we have USB-DMAC (it is used from USB only) This is out-of-topic from sound DMAC, but in USB-DMAC case, our SoC have USB IP and its DMAC. Old USB used generic DMAC before, but, New USB have USB specific DMAC today. And we already have usb driver. what should we do in this case ? Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
