On Wed, Oct 22, 2008 at 3:02 PM, David Brownell <david-b@xxxxxxxxxxx> wrote: > On Wednesday 22 October 2008, Juha Kuikka wrote: >> >> - __raw_readsl(nand->IO_ADDR_R, buf, len / 2); >> >> + __raw_readsl(nand->IO_ADDR_R, buf, len / 4); >> >> } >> > >> > Shouldn't that have been __raw_readsw() though? >> >> Hmh, good point. > > Yeah, but the bug was from a patch from me ... sigh. > > >> From the original code it looks like that was the intention but >> readsl() works just as well. > > Really? Both upper and lower 16-bit units have the right data? Yes, all data comes in normally. I'm running JFFS2 on top of this. >> I tested this on OMAP2430 and it works ok. >> >> I don't see any mentions in the TRM about the width of the >> GPMC_NAND_DATA registers but apparently the NAND engine happily >> accepts 32bit accesses on bus. > > Maybe this has to do with the FIFO behavior. It would certainly > make sense to allow reads of any size from the FIFO. If it were > raw reads on the data bus, then I'd expect that both 8 and 16 bit > widths would work. (Assuming NAND chips weren't in parallel...) Right, for the FIFO in prefetch/writeposting block the TRM explicitly states that it does accept 8/16/32 bit accesses but I don't see this driver using the prefetch engine. No parallel chips here, just a regular 16 bit wide LP NAND. > If the FIFO is active, and specified to support arbitrary width > accesses (that don't match the data bus), then by all means use > the __raw_readsl() call to maximize bandwidth use. Sure. But interestingly enough even without explicitly using the FIFO it seems to accept longer bus accesses. Just to be on the safe side, maybe the patch should indeed be revised to use __raw_readsw(..., len/2) ? - Juha -- Madness takes it's toll. Please have exact change. -- 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
