Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp7604509rwd; Tue, 6 Jun 2023 13:22:09 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6cN5K9V/lHcvPlDx8O5FjlUZVNFklPvYofD0GwOEziuTKqmz+g6W2DQrBFtWKo5AO7VA7K X-Received: by 2002:a05:622a:149:b0:3f6:b499:b2f9 with SMTP id v9-20020a05622a014900b003f6b499b2f9mr892678qtw.63.1686082928765; Tue, 06 Jun 2023 13:22:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686082928; cv=none; d=google.com; s=arc-20160816; b=Ars4omZdGhsq9nD/6negLHRAebbMb+ylyhYkRT4NljXOYrVlV7q12wJcGvO/aV7t3m Xo5mILOF2bx8ndaLZzdyrHX7J8u9ckD0TqolyqUw0PJlleZlQAUptpQzTmYEclZPEIxf P1BQ8ktl1Sj3E03tlLsSnkk16ObQm/eq6WIXlYR7RqxYxwH2XrKqUjn214BrYqd96uqB F3tu/fD/9CyM4zLytoR/8YuVmCgtvCGI/J0TeQRHmKrtfXBVgkWQWVzDd/7o6XZQIPh7 leC/RYTEVrWdaFeZOlGAzS/7FSn16kZ1BSNWkZxGI9ZwNOhYHlGbSyc2PRFc2A/fOUcB CZ5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=HsbilSNXGprd3byyDOvNssmOWdlSZHdBWqrnSufFSSw=; b=Y9BcDqEKjjq0OPFr1Y/M7lMDit6co1xKcmb1LYOyhKmYvuJb6iZpgRnQrYdP2KBbac W8kKmhxdTFHi5iCweTlUqbIt5Z+E4x9u7uNLUbCbJC58bqITnyOosmjE4TCincXEUjxd 1srFv4eZxQaoO2HyBvM25rUddfo7BJya8jYy0WcCFL4PlOpnTDZJwFy6FFALByV/NkFm f9KQHbS8QibJ49cRYDeDIzlzaJeyZxBbEV4sC7W8u4VQbY4ohR56Cy84zQ1N23R5yrmy CFRhJy0YTFRKhkjDJRbaQNHTBofZ7aciAxUdZlMtzuPbfMoESDSoVnClH7i01UOJ5kbg HYgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sberdevices.ru header.s=mail header.b=ZZU7Z6ra; 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=sberdevices.ru Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w15-20020a05622a134f00b003e18051efdbsi1587695qtk.671.2023.06.06.13.21.43; Tue, 06 Jun 2023 13:22:08 -0700 (PDT) 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=@sberdevices.ru header.s=mail header.b=ZZU7Z6ra; 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=sberdevices.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239614AbjFFT7e (ORCPT + 99 others); Tue, 6 Jun 2023 15:59:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239217AbjFFT73 (ORCPT ); Tue, 6 Jun 2023 15:59:29 -0400 Received: from mx.sberdevices.ru (mx.sberdevices.ru [45.89.227.171]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7DFDF10F0 for ; Tue, 6 Jun 2023 12:59:27 -0700 (PDT) Received: from s-lin-edge02.sberdevices.ru (localhost [127.0.0.1]) by mx.sberdevices.ru (Postfix) with ESMTP id BDEFB5FD0C; Tue, 6 Jun 2023 22:59:25 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sberdevices.ru; s=mail; t=1686081565; bh=HsbilSNXGprd3byyDOvNssmOWdlSZHdBWqrnSufFSSw=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; b=ZZU7Z6raDP6idx0UdSOQZRgPB1iO0AILrTTyExr92YK5bHZfxEpVbtSiu4qliHENJ hmGzSGX2dnvidjfQyZhyDZkfIqciZLiliur0qlw+FpyIZrMPGmaY3JFscc0Yue3NZc cO1rVDziwSPv7p50EkhIWA7jl+j9CeE/U3hGfzb9xpRcMiWeKQBb4Jb8xr9i+nr4yx cvcD/P3/c313g/4NMHlEyjT8c1j6ozzvvCJI8Je4gj3pahH+Ca2k1p/qZom5fwS2vp JJxYUUc0bl3pZJY/T2vZiPjGz5HVFqf1qELQlqx3JivNkzkYBVHxY/iRLfiPFRyJ9V c4GC7fklO9sAg== Received: from S-MS-EXCH01.sberdevices.ru (S-MS-EXCH01.sberdevices.ru [172.16.1.4]) by mx.sberdevices.ru (Postfix) with ESMTP; Tue, 6 Jun 2023 22:59:25 +0300 (MSK) Message-ID: <2ed06841-6c9f-46c9-2d2d-2daffb0a9010@sberdevices.ru> Date: Tue, 6 Jun 2023 22:54:32 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH v1] mtd: rawnand: meson: waiting w/o wired ready/busy pin Content-Language: en-US To: Liang Yang , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl CC: , , , , , References: <20230606195128.83432-1-AVKrasnov@sberdevices.ru> From: Arseniy Krasnov In-Reply-To: <20230606195128.83432-1-AVKrasnov@sberdevices.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.1.6] X-ClientProxiedBy: S-MS-EXCH01.sberdevices.ru (172.16.1.4) To S-MS-EXCH01.sberdevices.ru (172.16.1.4) X-KSMG-Rule-ID: 4 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiPhishing: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.30, bases: 2023/06/06 14:43:00 #21444531 X-KSMG-AntiVirus-Status: Clean, skipped X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org On 06.06.2023 22:51, Arseniy Krasnov wrote: > If there is no wired ready/busy pin, classic way to wait for command > completion is to use function 'nand_soft_waitrdy()'. Meson NAND has > special command which allows to wait for NAND_STATUS_READY bit without > reading status in a software loop (as 'nand_soft_waitrdy()' does). To > use it send this command along with NAND_CMD_STATUS, then wait for an > interrupt, and after interrupt send NAND_CMD_READ0. So this feature > allows to use interrupt driven waiting without wired ready/busy pin. > > Suggested-by: Liang Yang > Signed-off-by: Arseniy Krasnov > --- > drivers/mtd/nand/raw/meson_nand.c | 58 ++++++++++++++++++++++++++++++- > 1 file changed, 57 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c > index 074e14225c06..f4c5309a9527 100644 > --- a/drivers/mtd/nand/raw/meson_nand.c > +++ b/drivers/mtd/nand/raw/meson_nand.c > @@ -38,6 +38,7 @@ > #define NFC_CMD_SCRAMBLER_DISABLE 0 > #define NFC_CMD_SHORTMODE_DISABLE 0 > #define NFC_CMD_RB_INT BIT(14) > +#define NFC_CMD_RB_INT_NO_PIN ((0xb << 10) | BIT(18) | BIT(16)) > > #define NFC_CMD_GET_SIZE(x) (((x) >> 22) & GENMASK(4, 0)) > > @@ -94,6 +95,7 @@ > > /* nand flash controller delay 3 ns */ > #define NFC_DEFAULT_DELAY 3000 > +#define NFC_NO_RB_PIN_DELAY 5 > > #define ROW_ADDER(page, index) (((page) >> (8 * (index))) & 0xff) > #define MAX_CYCLE_ADDRS 5 > @@ -179,6 +181,7 @@ struct meson_nfc { > u32 info_bytes; > > unsigned long assigned_cs; > + bool no_rb_pin; > }; > > enum { > @@ -392,7 +395,41 @@ static void meson_nfc_set_data_oob(struct nand_chip *nand, > } > } > > -static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms) > +static int meson_nfc_wait_no_rb_pin(struct meson_nfc *nfc, int timeout_ms) > +{ > + u32 cmd, cfg; > + > + meson_nfc_cmd_idle(nfc, nfc->timing.twb); > + meson_nfc_drain_cmd(nfc); > + meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT); > + > + cfg = readl(nfc->reg_base + NFC_REG_CFG); > + cfg |= NFC_RB_IRQ_EN; > + writel(cfg, nfc->reg_base + NFC_REG_CFG); > + > + reinit_completion(&nfc->completion); > + cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS; > + writel(cmd, nfc->reg_base + NFC_REG_CMD); > + meson_nfc_cmd_idle(nfc, NFC_NO_RB_PIN_DELAY); ^^^ > + > + /* use the max erase time as the maximum clock for waiting R/B */ > + cmd = NFC_CMD_RB | NFC_CMD_RB_INT_NO_PIN | nfc->timing.tbers_max; > + writel(cmd, nfc->reg_base + NFC_REG_CMD); > + meson_nfc_cmd_idle(nfc, NFC_NO_RB_PIN_DELAY); ^^^ Liang, I've implemented "new RB_INT" way instead of 'nand_soft_waitrdy()'. There were two numbers 2 and 5 in 'meson_nfc_cmd_idle()' as time argument (here and above). I've replaced both with define of 5 == NFC_NO_RB_PIN_DELAY. Is it correct? 2 and 5 were from doc? Thanks, Arseniy > + > + if (!wait_for_completion_timeout(&nfc->completion, > + msecs_to_jiffies(timeout_ms))) > + return -ETIMEDOUT; > + > + cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_READ0; > + writel(cmd, nfc->reg_base + NFC_REG_CMD); > + meson_nfc_drain_cmd(nfc); > + meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT); > + > + return 0; > +} > + > +static int meson_nfc_wait_rb_pin(struct meson_nfc *nfc, int timeout_ms) > { > u32 cmd, cfg; > int ret = 0; > @@ -420,6 +457,23 @@ static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms) > return ret; > } > > +static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms) > +{ > + if (nfc->no_rb_pin) { > + /* This mode is used when there is no wired R/B pin. > + * It works like 'nand_soft_waitrdy()', but instead of > + * polling NAND_CMD_STATUS bit in the software loop, > + * it will wait for interrupt - controllers checks IO > + * bus and when it detects NAND_CMD_STATUS on it, it > + * raises interrupt. After interrupt, NAND_CMD_READ0 is > + * sent as terminator of the ready waiting procedure. > + */ > + return meson_nfc_wait_no_rb_pin(nfc, timeout_ms); > + } else { > + return meson_nfc_wait_rb_pin(nfc, timeout_ms); > + } > +} > + > static void meson_nfc_set_user_byte(struct nand_chip *nand, u8 *oob_buf) > { > struct meson_nfc_nand_chip *meson_chip = to_meson_nand(nand); > @@ -1412,6 +1466,8 @@ static int meson_nfc_probe(struct platform_device *pdev) > return ret; > } > > + nfc->no_rb_pin = !of_property_read_bool(dev->of_node, "nand-rb"); > + > writel(0, nfc->reg_base + NFC_REG_CFG); > ret = devm_request_irq(dev, irq, meson_nfc_irq, 0, dev_name(dev), nfc); > if (ret) {