From patchwork Wed Jan 13 07:47:28 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Robert Jarzmik X-Patchwork-Id: 8022921 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 41C019F716 for ; Wed, 13 Jan 2016 07:49:48 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5D18720430 for ; Wed, 13 Jan 2016 07:49:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0FB8220421 for ; Wed, 13 Jan 2016 07:49:45 +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 1aJG9v-0007D2-BA; Wed, 13 Jan 2016 07:47:59 +0000 Received: from smtp02.smtpout.orange.fr ([80.12.242.124] helo=smtp.smtpout.orange.fr) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aJG9s-0007Ba-1G for linux-arm-kernel@lists.infradead.org; Wed, 13 Jan 2016 07:47:57 +0000 Received: from belgarion ([92.149.187.47]) by mwinf5d37 with ME id 5KnU1s00m11nWjg03KnVQm; Wed, 13 Jan 2016 08:47:32 +0100 X-ME-Helo: belgarion X-ME-Auth: amFyem1pay5yb2JlcnRAb3JhbmdlLmZy X-ME-Date: Wed, 13 Jan 2016 08:47:32 +0100 X-ME-IP: 92.149.187.47 From: Robert Jarzmik To: Michael Wang Subject: Re: mtd: pxa3xx_nand: issue with command time out References: <5695CEF0.1080100@alliedtelesis.co.nz> X-URL: http://belgarath.falguerolles.org/ Date: Wed, 13 Jan 2016 08:47:28 +0100 In-Reply-To: <5695CEF0.1080100@alliedtelesis.co.nz> (Michael Wang's message of "Wed, 13 Jan 2016 04:13:37 +0000") Message-ID: <87a8o9ex9r.fsf@belgarion.home> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160112_234756_550546_72F941B6 X-CRM114-Status: GOOD ( 19.18 ) X-Spam-Score: -1.9 (-) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "computersforpeace@gmail.com" , "linux-mtd@lists.infradead.org" , "ezequiel@vanguardiasur.com.ar" , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Michael Wang writes: > Hi Robert, > > I am currently working with Marvell 98DX4251 switchchip with control and > management subsystem SOC based on ARMADA XP, and after upgrading kernel from ...zip... > 3.16.7 to 4.3, the nand controller command have a high chance of timing out. > -#define CHIP_DELAY_TIMEOUT msecs_to_jiffies(200) > +#define CHIP_DELAY_TIMEOUT msecs_to_jiffies(300) > #define NAND_STOP_DELAY msecs_to_jiffies(40) > #define PAGE_CHUNK_SIZE (2048) > > So I guess my question is whether the CHIP_DELAY_TIMEOUT should be increased > for 98DX4251, or is this likely to be caused by some other issue? Hi Michael, > Any suggestion, help or hint will be very much appreciated. Actually I have one. Before we change the timeout, I'd like to see the sequence of register accesses. As I owe a patch to Brian on this topic, I'd like to have you as a tester. In return, I'll analyse the output of debug traces it generates for you. The patch is at the bottom of this mail, and a "git am" on the mail should apply it to your kernel. It leaves up to you to add the "#define VERBOSE_DEBUG 1" in pxa3xx-nand.c, recompile, and take the traces. Once I have the traces, I will be able to compare with my traces on pxa3xx platforms and spot if there is a difference. Then we'll be able to see if increasing the timeout is the only option. Cheers. diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c index e453ae9a17fa..0845d09e14c1 100644 --- a/drivers/mtd/nand/pxa3xx_nand.c +++ b/drivers/mtd/nand/pxa3xx_nand.c @@ -136,11 +136,23 @@ #define READ_ID_BYTES 7 /* macros for registers read/write */ -#define nand_writel(info, off, val) \ - writel_relaxed((val), (info)->mmio_base + (off)) - -#define nand_readl(info, off) \ - readl_relaxed((info)->mmio_base + (off)) +#define nand_writel(info, off, val) \ + do { \ + dev_vdbg(&info->pdev->dev, \ + "%s():%d nand_writel(0x%x, 0x%04x)\n", \ + __func__, __LINE__, (val), (off)); \ + writel_relaxed((val), (info)->mmio_base + (off)); \ + } while (0) + +#define nand_readl(info, off) \ + ({ \ + unsigned int _v; \ + _v = readl_relaxed((info)->mmio_base + (off)); \ + dev_vdbg(&info->pdev->dev, \ + "%s():%d nand_readl(0x%04x): 0x%x\n", \ + __func__, __LINE__, (off), _v); \ + _v; \ + }) /* error code and state */ enum {