* David Brownell <david-b@xxxxxxxxxxx> [090406 03:48]: > On Monday 06 April 2009, Paul Walmsley wrote: > > > Puzzle: get a dma_copypage() to work faster than copy_page(). > > > Or a dma_clear_page() faster than clear_page(). Not easy... > > > > Doing it via the DMA engine may save power, since MPU can sleep. > > But the CPU overhead of calling the DMA engine can exceed > that of the memcpy()/memset() ... ;) > > Another concern is cache impact. In some cases, having the > dirty data in dcache is a big win. With DMA, the cache will > have been purged. > > It'd be nice to see DMA versions of this stuff winning; > all I'm saying is that such wins are hard to achieve. If the DMA transfer can loop over the small FIFO by and transfer larger chunks of data, the setup overhead is small. Currently at least tusb and ASoC loop the DMA over the FIFO. This way you can let the hardware trigger huge reads or writes from the small FIFO. To loop over the FIFO, set dst_fi or src_fi to a _negative_ number. Maybe onenand could use this too? If you can tell onenand to read or write multiple FIFOs, and there is a hardware DMA request line, the DMA request line can tell onenand to reload the FIFO. 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
