Message ID | 20221205082419.29170-1-bayi.cheng@mediatek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp2131665wrr; Mon, 5 Dec 2022 00:37:05 -0800 (PST) X-Google-Smtp-Source: AA0mqf4jslj0EEVFCX8Db1+USb6c5Gyi+BhPYxqNpv67VlBsmEU/lKEnSrQ6n2H/xxKHie88y95g X-Received: by 2002:a17:906:2854:b0:7ae:3684:84b0 with SMTP id s20-20020a170906285400b007ae368484b0mr60085767ejc.622.1670229424839; Mon, 05 Dec 2022 00:37:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670229424; cv=none; d=google.com; s=arc-20160816; b=ku3Vdc/d7ENbCQn6JdbZG26LHxJLM05dH0ScbUOXqzIYNQk0lNF8ZuT+8Na0xY4Q1F 9cLWZXtnTIfugFGdnyUbgJUiZSpE0y1Q7IR2ecvuaT5nVNUfeNKCllytSzCZJHAiQ8Wy yTZRZZMIc2yPKGC9n9LC4vh2REAOuqDLx1Cm9539VXTR51tEBGCXYjLKTVS9yNVESeqG wu79oJ0HxmpZTePnxZiG3CQBrr5nXwBC1B7uyk5Uhbl/P/lra7Sy4gbDMLGT2SdyTky/ mcUzPFtNFnrHI1m6NgTesfPxBqm9QJJOixnwe1FPtLXigeBCpmSyp5oDb10Ycc5Di7qY MSWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=GlJ2Pnimn4eRqc2TDacYNHE0ujFtrinL9YvZeTlViIw=; b=Y9uAM2V2p69qWw/tOB2Ui+iu3wS7j5FeCYJtAxBLaQZu9rCRWnIFjmATpRVbwXBqHc f5L15dZrtxIuLi8OH0dyhffIpfIeawAg4mnm6lESX41f610s+KLh1Cosi8bNl6MPHyoK sEOLoX7I5zInQwpf+R4nU1eBCBc7IAaYy/B8WH4qX0yOyLZSevFd/5/xOWwg1EH0ecV4 dFDZSJPQGMQWRdbeQQjfjSEKhUNn791DkHeOPDL+H5Soj2Borgxv9SqPbHq62TusqzOh 0vglpox/TwR1PvmwzDBvCSKMQiwHJpd2pMy4aBfNxnN7I8mX+7OlRXJl29yuNDYflPtg 4FTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=BDlmM6I1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q5-20020a056402248500b0045cfb63a033si11383208eda.551.2022.12.05.00.36.41; Mon, 05 Dec 2022 00:37:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=BDlmM6I1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231743AbiLEIYo (ORCPT <rfc822;jaysivo@gmail.com> + 99 others); Mon, 5 Dec 2022 03:24:44 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48204 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231784AbiLEIYe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 5 Dec 2022 03:24:34 -0500 Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD2F0BF57; Mon, 5 Dec 2022 00:24:27 -0800 (PST) X-UUID: 90bceca878974e0b8639e97f93e0ebf7-20221205 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:CC:To:From; bh=GlJ2Pnimn4eRqc2TDacYNHE0ujFtrinL9YvZeTlViIw=; b=BDlmM6I1mOIfFxSsSzs8dOVF1XDyW56S3YOWCdWhzHOWGPCurZbCT8qWeDvvNJLXZBflGbuHMxi2uSSyKJ218JT9tXMlb6kAijT/2wG6glZHQt9OxJ3Vdm3fo2SBt+ZEo3AHqWT6PKZMuXbih4csbWfS6AzaPun5Qb6BcRTJRWE=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.14,REQID:88e325dd-963d-4116-92a1-eb5f3175ecf6,IP:0,U RL:0,TC:0,Content:-25,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTIO N:release,TS:-25 X-CID-META: VersionHash:dcaaed0,CLOUDID:847cb130-2938-482e-aafd-98d66723b8a9,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0 X-UUID: 90bceca878974e0b8639e97f93e0ebf7-20221205 Received: from mtkmbs10n2.mediatek.inc [(172.21.101.183)] by mailgw02.mediatek.com (envelope-from <bayi.cheng@mediatek.com>) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 535825791; Mon, 05 Dec 2022 16:24:23 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs11n2.mediatek.inc (172.21.101.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 5 Dec 2022 16:24:21 +0800 Received: from localhost.localdomain (10.17.3.154) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Mon, 5 Dec 2022 16:24:21 +0800 From: Bayi Cheng <bayi.cheng@mediatek.com> To: Mark Brown <broonie@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, Ikjoon Jang <ikjn@chromium.org> CC: <linux-spi@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <linux-kernel@vger.kernel.org>, Chuanhong Guo <gch981213@gmail.com>, <Project_Global_Chrome_Upstream_Group@mediatek.com>, bayi cheng <bayi.cheng@mediatek.com> Subject: [PATCH v1] spi: spi-mtk-nor: Add recovery mechanism for dma read timeout Date: Mon, 5 Dec 2022 16:24:19 +0800 Message-ID: <20221205082419.29170-1-bayi.cheng@mediatek.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-MTK: N X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, T_SPF_TEMPERROR,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751362489285894956?= X-GMAIL-MSGID: =?utf-8?q?1751362489285894956?= |
Series |
[v1] spi: spi-mtk-nor: Add recovery mechanism for dma read timeout
|
|
Commit Message
Bayi Cheng
Dec. 5, 2022, 8:24 a.m. UTC
From: bayi cheng <bayi.cheng@mediatek.com> The state machine of MTK spi nor controller may be disturbed by some glitch signals from the relevant BUS during dma read, Although the possibility of causing the dma read to fail is next to nothing, However, if error-handling is not implemented, which makes the feature somewhat risky. Add an error-handling mechanism here, reset the state machine and re-read the data when an error occurs. Signed-off-by: bayi cheng <bayi.cheng@mediatek.com> --- Change in v1: -Reset the state machine when dma read fails and read again. --- --- drivers/spi/spi-mtk-nor.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
Comments
Il 05/12/22 09:24, Bayi Cheng ha scritto: > From: bayi cheng <bayi.cheng@mediatek.com> > > The state machine of MTK spi nor controller may be disturbed by some > glitch signals from the relevant BUS during dma read, Although the > possibility of causing the dma read to fail is next to nothing, > However, if error-handling is not implemented, which makes the feature > somewhat risky. > > Add an error-handling mechanism here, reset the state machine and > re-read the data when an error occurs. > > Signed-off-by: bayi cheng <bayi.cheng@mediatek.com> > --- > Change in v1: > -Reset the state machine when dma read fails and read again. > --- > --- > drivers/spi/spi-mtk-nor.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c > index d167699a1a96..c77d79da9a4c 100644 > --- a/drivers/spi/spi-mtk-nor.c > +++ b/drivers/spi/spi-mtk-nor.c > @@ -80,6 +80,9 @@ > #define MTK_NOR_REG_DMA_FADR 0x71c > #define MTK_NOR_REG_DMA_DADR 0x720 > #define MTK_NOR_REG_DMA_END_DADR 0x724 > +#define MTK_NOR_REG_CG_DIS 0x728 > +#define MTK_NOR_SFC_SW_RST BIT(2) > + > #define MTK_NOR_REG_DMA_DADR_HB 0x738 > #define MTK_NOR_REG_DMA_END_DADR_HB 0x73c > > @@ -616,7 +619,18 @@ static int mtk_nor_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) > mtk_nor_set_addr(sp, op); > return mtk_nor_read_pio(sp, op); > } else { > - return mtk_nor_read_dma(sp, op); > + ret = mtk_nor_read_dma(sp, op); > + if (ret) { > + dev_err(sp->dev, "try to read again\n"); > + mtk_nor_rmw(sp, MTK_NOR_REG_CG_DIS, 0, MTK_NOR_SFC_SW_RST); > + mb(); /* flush previous writes */ > + mtk_nor_rmw(sp, MTK_NOR_REG_CG_DIS, MTK_NOR_SFC_SW_RST, 0); > + mb(); /* flush previous writes */ > + writel(MTK_NOR_ENABLE_SF_CMD, sp->base + MTK_NOR_REG_WP); From what I understand, you're introducing a way to perform a flush+reset on the controller. At this point, I'd put that in a separate function like `mtk_nor_reset()`, as to both increase readability and to possibly reuse it somewhere else in the future, if needed. So this would become... } else { ret = mtk_nor_read_dma(sp, op); if (unlikely(ret)) { /* Handle rare bus glitch */ mtk_nor_reset(sp); mtk_nor_setup_bus(sp, op); return mtk_nor_read_dma(sp, op); } return ret; } ...or something alike :-) Regards, Angelo
On Mon, 2022-12-05 at 15:01 +0100, AngeloGioacchino Del Regno wrote: > Il 05/12/22 09:24, Bayi Cheng ha scritto: > > From: bayi cheng <bayi.cheng@mediatek.com> > > > > The state machine of MTK spi nor controller may be disturbed by > > some > > glitch signals from the relevant BUS during dma read, Although the > > possibility of causing the dma read to fail is next to nothing, > > However, if error-handling is not implemented, which makes the > > feature > > somewhat risky. > > > > Add an error-handling mechanism here, reset the state machine and > > re-read the data when an error occurs. > > > > Signed-off-by: bayi cheng <bayi.cheng@mediatek.com> > > --- > > Change in v1: > > -Reset the state machine when dma read fails and read again. > > --- > > --- > > drivers/spi/spi-mtk-nor.c | 16 +++++++++++++++- > > 1 file changed, 15 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c > > index d167699a1a96..c77d79da9a4c 100644 > > --- a/drivers/spi/spi-mtk-nor.c > > +++ b/drivers/spi/spi-mtk-nor.c > > @@ -80,6 +80,9 @@ > > #define MTK_NOR_REG_DMA_FADR 0x71c > > #define MTK_NOR_REG_DMA_DADR 0x720 > > #define MTK_NOR_REG_DMA_END_DADR 0x724 > > +#define MTK_NOR_REG_CG_DIS 0x728 > > +#define MTK_NOR_SFC_SW_RST BIT(2) > > + > > #define MTK_NOR_REG_DMA_DADR_HB 0x738 > > #define MTK_NOR_REG_DMA_END_DADR_HB 0x73c > > > > @@ -616,7 +619,18 @@ static int mtk_nor_exec_op(struct spi_mem > > *mem, const struct spi_mem_op *op) > > mtk_nor_set_addr(sp, op); > > return mtk_nor_read_pio(sp, op); > > } else { > > - return mtk_nor_read_dma(sp, op); > > + ret = mtk_nor_read_dma(sp, op); > > + if (ret) { > > + dev_err(sp->dev, "try to read > > again\n"); > > + mtk_nor_rmw(sp, MTK_NOR_REG_CG_DIS, 0, > > MTK_NOR_SFC_SW_RST); > > + mb(); /* flush previous writes */ > > + mtk_nor_rmw(sp, MTK_NOR_REG_CG_DIS, > > MTK_NOR_SFC_SW_RST, 0); > > + mb(); /* flush previous writes */ > > + writel(MTK_NOR_ENABLE_SF_CMD, sp->base > > + MTK_NOR_REG_WP); > > From what I understand, you're introducing a way to perform a > flush+reset on > the controller. > > At this point, I'd put that in a separate function like > `mtk_nor_reset()`, as > to both increase readability and to possibly reuse it somewhere else > in the > future, if needed. > > So this would become... > > } else { > ret = mtk_nor_read_dma(sp, op); > if (unlikely(ret)) { > /* Handle rare bus glitch */ > mtk_nor_reset(sp); > mtk_nor_setup_bus(sp, op); > return mtk_nor_read_dma(sp, op); > } > return ret; > } > > ...or something alike :-) > > Regards, > Angelo > Hi Angelo, Thanks for your comments! I will fix it in the next patch. Regards, Bayi
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c index d167699a1a96..c77d79da9a4c 100644 --- a/drivers/spi/spi-mtk-nor.c +++ b/drivers/spi/spi-mtk-nor.c @@ -80,6 +80,9 @@ #define MTK_NOR_REG_DMA_FADR 0x71c #define MTK_NOR_REG_DMA_DADR 0x720 #define MTK_NOR_REG_DMA_END_DADR 0x724 +#define MTK_NOR_REG_CG_DIS 0x728 +#define MTK_NOR_SFC_SW_RST BIT(2) + #define MTK_NOR_REG_DMA_DADR_HB 0x738 #define MTK_NOR_REG_DMA_END_DADR_HB 0x73c @@ -616,7 +619,18 @@ static int mtk_nor_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) mtk_nor_set_addr(sp, op); return mtk_nor_read_pio(sp, op); } else { - return mtk_nor_read_dma(sp, op); + ret = mtk_nor_read_dma(sp, op); + if (ret) { + dev_err(sp->dev, "try to read again\n"); + mtk_nor_rmw(sp, MTK_NOR_REG_CG_DIS, 0, MTK_NOR_SFC_SW_RST); + mb(); /* flush previous writes */ + mtk_nor_rmw(sp, MTK_NOR_REG_CG_DIS, MTK_NOR_SFC_SW_RST, 0); + mb(); /* flush previous writes */ + writel(MTK_NOR_ENABLE_SF_CMD, sp->base + MTK_NOR_REG_WP); + mtk_nor_setup_bus(sp, op); + ret = mtk_nor_read_dma(sp, op); + } + return ret; } }