* Ladislav Michl <ladis@xxxxxxxxxxxxxx> [171114 22:34]: > 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". Well gpio_65 has sys_ndmareq1 mode.. And if it's RDY pin, it to me sounds like it really could be used for loading more data to the fifo. But then again, I have not looked at the datasheet so you probably know better :) > > 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. Yeah testing on n8x0 really should be done to avoid regressions. 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
