On Thu, Dec 8, 2016 at 1:20 PM, Måns Rullgård <mans@xxxxxxxxx> wrote: > 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. Sorry, I mainly read Vinod's "not in probe", and missed your "or when the device is opened". Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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