On Tue, Nov 14, 2017 at 01:53:12PM -0800, Tony Lindgren wrote: > * 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. As previously discussed, slave DMA should be triggered by RDY pin and it has nothing to do with code already in place. That also means someone should remove misleding comment line from e2c5eb78a3cc "ARM: dts: Fix wrong GPMC size mappings for omaps" ;-) I'll do it later in v5 of "ARM: dts: Nokia: Use R/B pin". > Something to look later on for sure if anybody is interested. While there, we should also benchmark DMA memcpy as OMAP3 version was using 384 bytes as limit to trigger DMA while OMAP2 was using 1024. For smaller chunks, memcpy was used. I decided to leave 384 in place, but I do not have OMAP2 hardware to do any verification. ladis -- 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
