From patchwork Mon Oct 23 08:21:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: xiaolei li X-Patchwork-Id: 10022169 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 81CBE603D7 for ; Mon, 23 Oct 2017 08:22:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6D245284F9 for ; Mon, 23 Oct 2017 08:22:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 61D3F2869A; Mon, 23 Oct 2017 08:22:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id AC33B28674 for ; Mon, 23 Oct 2017 08:22:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=B1l8bZHJs8xadB8hCaEGwCgNMeKhhxipaSh6a8myocU=; b=VK6PSTsbVz5vZy GpUkcgKlUT9r1uRBqMiD4PGhNDaEK3CVPlaq6xV0zsFOrXmPwQQnwJWkZPyDH/Lmp+nDE9NTm7cJn M8DkZ5iT1mpxHnsnxaBgUBl7l/ZiobKFuaySxELGXm/3tfZ13h388if8tuTTH8YltBO0MZooWDDZM xcvaHyl3MXC8VjMuPjIRx6W3xZ7Qzo70jRvAnBF3e0o5ScUw9t0Yz8Lt8S7JiZnqiIkt/CkvUvDH2 RRBNo8CoOZhZGiSAKQ7k18Ww4PxrW0xptwlu9gznhAgktxbcrVZ9StYoKBfjOobSLrSjGxcOGfKyq 9NT9K6mGxxF9PLZFeZMA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1e6Y07-0005Qx-Bi; Mon, 23 Oct 2017 08:22:23 +0000 Received: from [210.61.82.184] (helo=mailgw02.mediatek.com) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1e6Xzv-0005Il-Ux; Mon, 23 Oct 2017 08:22:14 +0000 X-UUID: 48cd610199394373aa752c2b90fb8a0b-20171023 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 1978016859; Mon, 23 Oct 2017 16:21:42 +0800 Received: from mtkcas09.mediatek.inc (172.21.101.178) by mtkmbs03n2.mediatek.inc (172.21.101.182) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 23 Oct 2017 16:21:41 +0800 Received: from mtkslt306.mediatek.inc (10.21.14.136) by mtkcas09.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1210.3 via Frontend Transport; Mon, 23 Oct 2017 16:21:41 +0800 From: Xiaolei Li To: , Subject: [PATCH v1 2/2] mtd: nand: mtk: fix infinite ECC decode IRQ issue Date: Mon, 23 Oct 2017 16:21:37 +0800 Message-ID: <1508746897-62291-3-git-send-email-xiaolei.li@mediatek.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1508746897-62291-1-git-send-email-xiaolei.li@mediatek.com> References: <1508746897-62291-1-git-send-email-xiaolei.li@mediatek.com> MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20171023_012212_152050_7D5B78D9 X-CRM114-Status: GOOD ( 16.40 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: srv_heupstream@mediatek.com, linux-mtd@lists.infradead.org, linux-mediatek@lists.infradead.org, xiaolei.li@mediatek.com, dwmw2@infradead.org, rogercc.lin@mediatek.com Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+patchwork-linux-mediatek=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP For MT2701 NAND Controller, there may generate infinite ECC decode IRQ during long time burn test on some platforms. Once this issue occurred, the ECC decode IRQ status cannot be cleared in the IRQ handler function, and threads cannot be scheduled. ECC HW generates decode IRQ each sector, so there will have more than one decode IRQ if read one page of large page NAND. Currently, ECC IRQ handle flow is that we will check whether it is decode IRQ at first by reading the register ECC_DECIRQ_STA. This is a read-clear type register. If this IRQ is decode IRQ, then the ECC IRQ signal will be cleared at the same time. Secondly, we will check whether all sectors are decoded by reading the register ECC_DECDONE. This is because the current IRQ may be not dealed in time, and the next sectors have been decoded before reading the register ECC_DECIRQ_STA. Then, the next sectors's decode IRQs will not be generated. Thirdly, if all sectors are decoded by comparing with ecc->sectors, then we will complete ecc->done, set ecc->sectors as 0, and disable ECC IRQ by programming the register ECC_IRQ_REG(op) as 0. Otherwise, wait for the next ECC IRQ. But, there is a timing issue between step one and two. When we read the reigster ECC_DECIRQ_STA, all sectors are decoded except the last sector, and the ECC IRQ signal is cleared. But the last sector is decoded before reading ECC_DECDONE, so the ECC IRQ signal is enabled again by ECC HW, and it means we will receive one extra ECC IRQ later. In step three, we will find that all sectors were decoded, then disable ECC IRQ and return. When deal with the extra ECC IRQ, the ECC IRQ status cannot be cleared anymore. That is because the register ECC_DECIRQ_STA can only be cleared when the register ECC_IRQ_REG(op) is enabled. But actually we have disabled ECC IRQ in the previous ECC IRQ handle. So, there will keep receiving ECC decode IRQ. Now, we read the register ECC_DECIRQ_STA once again before completing the ecc done event. This ensures that there will be no extra ECC decode IRQ. MT2712 ECC HW is designed to generate only one decode IRQ each page, so there is no this problem on MT2712 platforms. Signed-off-by: Xiaolei Li --- drivers/mtd/nand/mtk_ecc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/mtd/nand/mtk_ecc.c b/drivers/mtd/nand/mtk_ecc.c index 82aa6f2..0e04323 100644 --- a/drivers/mtd/nand/mtk_ecc.c +++ b/drivers/mtd/nand/mtk_ecc.c @@ -115,6 +115,11 @@ static irqreturn_t mtk_ecc_irq(int irq, void *id) op = ECC_DECODE; dec = readw(ecc->regs + ECC_DECDONE); if (dec & ecc->sectors) { + /** + * Clear decode IRQ status once again to ensure that + * there will be no extra IRQ. + */ + dec = readw(ecc->regs + ECC_DECIRQ_STA); ecc->sectors = 0; complete(&ecc->done); } else {