From patchwork Fri May 9 18:45:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ezequiel Garcia X-Patchwork-Id: 4144791 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 311FFBFF02 for ; Fri, 9 May 2014 18:49:30 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3D4142034A for ; Fri, 9 May 2014 18:49:29 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 559BF20328 for ; Fri, 9 May 2014 18:49:28 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wipo7-0007qa-OX; Fri, 09 May 2014 18:46:07 +0000 Received: from top.free-electrons.com ([176.31.233.9] helo=mail.free-electrons.com) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wipo2-0007pP-Sw; Fri, 09 May 2014 18:46:05 +0000 Received: by mail.free-electrons.com (Postfix, from userid 106) id 27593804; Fri, 9 May 2014 20:45:42 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from localhost (unknown [190.2.108.30]) by mail.free-electrons.com (Postfix) with ESMTPSA id 316BA7B8; Fri, 9 May 2014 20:45:40 +0200 (CEST) Date: Fri, 9 May 2014 15:45:05 -0300 From: Ezequiel Garcia To: Arnd Bergmann Subject: Re: [PATCH 2/2] mtd: orion-nand: fix build error with ARMv4 Message-ID: <20140509184505.GA30330@arch.cereza> References: <1399560433-1402630-1-git-send-email-arnd@arndb.de> <1399560990-1402858-1-git-send-email-arnd@arndb.de> <1399560990-1402858-4-git-send-email-arnd@arndb.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1399560990-1402858-4-git-send-email-arnd@arndb.de> User-Agent: Mutt/1.5.22 (2013-10-16) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140509_114603_254587_5CC0088E X-CRM114-Status: GOOD ( 20.79 ) X-Spam-Score: 0.3 (/) Cc: Jingoo Han , linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Brian Norris , David Woodhouse , linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On 08 May 04:56 PM, Arnd Bergmann wrote: > 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 > Cc: David Woodhouse > Cc: Brian Norris > Cc: Jingoo Han > Cc: linux-mtd@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: 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. 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); }