Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> writes: > On Thu, Dec 8, 2016 at 12:44 PM, Måns Rullgård <mans@xxxxxxxxx> wrote: >> Vinod Koul <vinod.koul@xxxxxxxxx> writes: >>> On Wed, Dec 07, 2016 at 04:45:58PM +0000, Måns Rullgård wrote: >>>> Vinod Koul <vinod.koul@xxxxxxxxx> writes: >>>> > On Tue, Dec 06, 2016 at 01:14:20PM +0000, Måns Rullgård wrote: >>>> >> That's not going to work very well. Device drivers typically request >>>> >> dma channels in their probe functions or when the device is opened. >>>> >> This means that reserving one of the few channels there will inevitably >>>> >> make some other device fail to operate. >>>> > >>>> > No that doesnt make sense at all, you should get a channel only when you >>>> > want to use it and not in probe! >>>> >>>> Tell that to just about every single driver ever written. >>> >>> Not really, few do yes which is wrong but not _all_ do that. >> >> Every driver I ever looked at does. Name one you consider "correct." > > 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. 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. 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. -- Måns Rullgård -- 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
