[PATCH 2/2] mtd: orion-nand: fix build error with ARMv4
From: Ezequiel Garcia <hidden>
Date: 2014-05-09 18:45:41
Also in:
lkml
Subsystem:
memory technology devices (mtd), nand flash subsystem, the rest · Maintainers:
Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, Linus Torvalds
On 08 May 04:56 PM, Arnd Bergmann wrote:
quoted hunk ↗ jump to hunk
orion_nand_read_buf uses an inline assembly with the "ldrd" instruction, which is only available from ARMv5 upwards. This used to be fine, since all users have an ARMv5 or ARMv7 CPU, but now we can also build a multiplatform kernel with ARMv4 support enabled in addition to the "kirkwood" (mvebu) platform. This provides an alternative to call the readsl() function that is supposed to have the same effect and is also optimized for performance. This patch is untested, and it would be worthwhile to check if there is any performance impact, especially in case the readsl version is actually faster. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Brian Norris <computersforpeace@gmail.com> Cc: Jingoo Han <redacted> Cc: linux-mtd at lists.infradead.org --- drivers/mtd/nand/orion_nand.c | 5 +++++ 1 file changed, 5 insertions(+)diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c index dd7fe81..c7b5e8a 100644 --- a/drivers/mtd/nand/orion_nand.c +++ b/drivers/mtd/nand/orion_nand.c@@ -56,6 +56,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) *buf++ = readb(io_base); len--; } +#if __LINUX_ARM_ARCH__ >= 5 buf64 = (uint64_t *)buf; while (i < len/8) { /*@@ -68,6 +69,10 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) asm volatile ("ldrd\t%0, [%1]" : "=&r" (x) : "r" (io_base)); buf64[i++] = x; } +#else + readsl(io_base, buf, len/8);
I gave this a try in order to answer Arnd's performance question. First of all, the patch seems wrong. I guess it's because readsl reads 4-bytes pieces, instead of 8-bytes. This patch below is tested (but not completely, see below) and works:
diff --git a/drivers/mtd/nand/orion_nand.c b/drivers/mtd/nand/orion_nand.c
index dd7fe81..7a78cc5 100644
--- a/drivers/mtd/nand/orion_nand.c
+++ b/drivers/mtd/nand/orion_nand.c@@ -52,6 +52,7 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) uint64_t *buf64; int i = 0; +#if __LINUX_ARM_ARCH__ >= 5 while (len && (unsigned long)buf & 7) { *buf++ = readb(io_base); len--;
@@ -69,6 +70,14 @@ static void orion_nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) buf64[i++] = x; } i *= 8; +#else + while (len && (unsigned long)buf & 3) { + *buf++ = readb(io_base); + len--; + } + readsl(io_base, buf, len/4); + i = (len / 4 * 4) * 4; +#endif while (i < len) buf[i++] = readb(io_base); }
However, all the reads are nicely aligned (in both the buffer and the length) which means the only 'read' performed in the readsl() one. In other words, the patch is still half-untested. Therefore, and given this is meant only to coherce a build, maybe we'd rather just loop over readb and stay on the safe side? And now, answering Arnd's question: # Using ldrd # time nanddump /dev/mtd5 -f /dev/null -q real 0m 5.90s user 0m 0.22s sys 0m 5.67s # Using readsl # time nanddump /dev/mtd5 -f /dev/null -q real 0m 6.39s user 0m 0.17s sys 0m 6.20s So I'd say, let's stick to the ldrd magic. -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com