On Friday 03 April 2009, Russ Dill wrote: > On Fri, Apr 3, 2009 at 7:52 PM, David Hagood <david.hagood@xxxxxxxxx> wrote: > > Well, that's not what I would have expected - I would have thought > > reads on POP would have been faster than that, and cheaper - the SD > > being the same speed but less CPU is surprising. > > The POP flash may not have a DMA ability. ISTR it does, but it's not used. There are other speedups possible; the NAND driver in the OMAP tree is pretty simplistic. It doesn't use the "Prefetch and Write-Posting Engine" (we don't know if that really helps though); or the more aggressive ECC support (4-bit and 8-bit modes both work). Of course using DMA in the MTD stack can be a bit problematic in general. It assumes that DMA is not used ... to the extent of not guaranteeing to provide DMA-mappable I/O buffers. That said, it's hard to achieve speedups through DMA for such small blocks of memory ... an issue which is not unique to NAND. > Also, the POP flash contents > are compressed and ECC corrected, so its a lot of extra work for the > CPU. ECC is done in hardware for the native NAND stack on OMAP; but you're right about compression. Another point is that "managed NAND" (like MMC and eMMC, and various SSD flavors) is there to offload some complicated and error-prone tasks like wear-leveling. -- 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
