On Thu, Dec 08, 2016 at 12:20:30PM +0000, Måns Rullgård wrote: > > > > I'm far from claiming that drivers/tty/serial/sh-sci.c is perfect, but > > it does request DMA channels at open time, not at probe time. > > In the part quoted above, I said most drivers request dma channels in > their probe or open functions. For the purposes of this discussion, > that distinction is irrelevant. In either case, the channel is held > indefinitely. And the answer was it is wrong and not _all_ do that!! > If this wasn't the correct way to use the dmaengine, > there would be no need for the virt-dma helpers which are specifically > designed for cases the one currently at hand. That is incorrect. virt-dma helps to have multiple request from various clients. For many controllers which implement a SW mux, they can transfer data for one client and then next transfer can be for some other one. This allows better utilization of dma channels and helps in case where we have fewer dma channels than users. This was _not_ developed to let people grab channels in probe. > The only problem we have is that nobody envisioned hardware where the > dma engine indicates completion slightly too soon. I suspect there's a > fifo or such somewhere, and the interrupt is triggered when the last > byte has been placed in the fifo rather than when it has been removed > which would have been more correct. That is pretty common hardware optimization but usually hardware shows up with flush commands to let in flight transactions be completed. One other example of this implementations has already been pointed in this thread -- ~Vinod -- 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
