[PATCH v3 5/7] mtd: onenand: omap2: Unify OMAP2 and OMAP3 DMA implementation

[Tony Lindgren]

* Ladislav Michl <ladis at linux-mips.org> [171114 22:34]:
> On Tue, Nov 14, 2017 at 01:53:12PM -0800, Tony Lindgren wrote:
> > * Ladislav Michl <ladis at linux-mips.org> [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