* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171110 21:41]: > On Fri, Nov 10, 2017 at 07:24:23AM -0800, Tony Lindgren wrote: > > FYI, the gpio pin for onenand should not be in gpio mode. It should > > be used as external dma request line to automatically trigger new > > transfers like we do for tusb6010 dma. But of course it's possible > > that onenand has other issues too preventing the dma usage. > > Now, after reading dma and interrupt related code again, I still do > not see how the driver could be using hardware synchronized transfer. > DMA seems to be used as a memcpy and gpio pin a ready/busy. > Care to elaborate a bit more? Well take a look at mux options for the onenand connected pins, and if there is one that has a mux option for ext_dmareq or similar, chances are it can be used to retrigger dma transfers. I could be wrong of course, and it could be it won't even work with onenand. Something to look later on for sure if anybody is interested. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
