Messages in this thread |  | | | From | "Voss, Nikolaus" <> | | Date | Mon, 30 Jan 2012 08:57:17 +0100 | | Subject | RE: [PATCH] mtd: atmel_nand: fix access to 16 bit NAND devices |
| |
Artem Bityutskiy wrote on 2012-01-27: > On Wed, 2012-01-18 at 10:16 +0100, Nikolaus Voss wrote: >> commit fb5427508abbd635e877fabdf55795488119c2d6 optimizes PIO >> NAND accesses by using IO memcpy instead of IO read/write >> repeated functions. >> >> This breaks access to 16 bit NAND devices as memcpy_fromio()/toio() >> _always_ use byte accesses (see arch/arm/kernel/io.c), so with >> 16 bit NAND, one byte gets lost per NAND access cycle and NAND >> address count is wrong. >> >> Using memcpy() instead of the IO memcpy functions fixes this, but >> depends on correct word alignment of the buffer and length has to >> be a multiple of four, otherwise it might issue byte accesses and >> possibly break 16 bit NAND access (cf arch/arm/lib/copy_template.S). >> >> Memcpy variants seem to be the wrong approach here, since the >> NAND controller doesn't make the NAND appear as truely randomly >> accessible memory (as opposed to the DRAM controller which does >> exactly that). >> >> So, my proposal is to use 32 bit IO read/write (and let SMC >> map it to 8 bit or 16 bit NAND accesses) and account for >> length % 4 > 0 with two additional IO read/writes. >> >> Signed-off-by: Nikolaus Voss <n.voss@weinmann.de> > > Why not to revert fb5427508abbd635e877fabdf55795488119c2d6 instead, it > is in my opinion a bit more readable?
No objections. I've tried to save the idea of fb5427508abbd635e877fabdf55795488119c2d6 but that length % 4 > 0 stuff uglifies it a little bit... Niko
|  |