From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E932EC77B73 for ; Tue, 30 May 2023 13:59:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232772AbjE3N7T (ORCPT ); Tue, 30 May 2023 09:59:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232747AbjE3N7L (ORCPT ); Tue, 30 May 2023 09:59:11 -0400 Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::225]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C1A9A12B for ; Tue, 30 May 2023 06:59:02 -0700 (PDT) X-GND-Sasl: miquel.raynal@bootlin.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1685455140; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iPKl0w/v3sbTqMK8trZ1QoQzZIkuiRuU+iuDTR4PM7w=; b=i+lgq76jw4UBnAvmGTjz1XNJYzfeipH8VUCxaBpcXsPCRpL+2ebVNd7FAOQgDXWKlPn+zh DLNnHiORlxkXCoaxSPHDHOnTnEVsyAGF3JETcU3Mf2K/sH8nDlO+EeEPG9W0Sl8IWCL6ac +UWW0Qb2XVl0U+Zjq8P8r4Iv0Q4lMOfaOCrJxT9DztW3/dklpIXTVq0IM2XXQsQ3cDJenF MTeyYBAEx/EifOTodiKZGxTrxlLCVzPFkZOBR/2BMsLA/YgwMleYKu0uK/TU/mtI7MTgYW vw/geCnyfMwFBQDKbi0sG4mPLa0Ryk1kyntZqCY7nN8mD0Dvkj9oQvhYVwRDng== X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com X-GND-Sasl: miquel.raynal@bootlin.com Received: by mail.gandi.net (Postfix) with ESMTPSA id 509141C0005; Tue, 30 May 2023 13:58:59 +0000 (UTC) Date: Tue, 30 May 2023 15:58:58 +0200 From: Miquel Raynal To: Arseniy Krasnov Cc: Liang Yang , Richard Weinberger , Vignesh Raghavendra , Neil Armstrong , Kevin Hilman , JeromeBrunet , Martin Blumenstingl , Yixun Lan , Jianxin Pan , , , , , , Subject: Re: [PATCH v4 1/5] mtd: rawnand: meson: fix command sequence for read/write Message-ID: <20230530155858.6bfbed89@xps-13> In-Reply-To: <9d3ada22-0176-2113-bff2-27f8a4ad5c23@sberdevices.ru> References: <20230515094440.3552094-1-AVKrasnov@sberdevices.ru> <20230515094440.3552094-2-AVKrasnov@sberdevices.ru> <20230522170526.6486755a@xps-13> <9013b0e2-c923-43f8-0bd6-979bf0c23ebc@sberdevices.ru> <20230526192205.4a69ca79@xps-13> <6077c959-f566-d399-d2be-8460eb063415@sberdevices.ru> <20230530150556.498c1fae@xps-13> <9d3ada22-0176-2113-bff2-27f8a4ad5c23@sberdevices.ru> Organization: Bootlin X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arseniy, avkrasnov@sberdevices.ru wrote on Tue, 30 May 2023 16:35:59 +0300: > On 30.05.2023 16:05, Miquel Raynal wrote: > > Hi Arseniy, > >=20 > > avkrasnov@sberdevices.ru wrote on Tue, 30 May 2023 14:19:08 +0300: > > =20 > >> On 26.05.2023 20:22, Miquel Raynal wrote: =20 > >>> Hi Arseniy, > >>> > >>> avkrasnov@sberdevices.ru wrote on Wed, 24 May 2023 12:05:47 +0300: > >>> =20 > >>>> On 23.05.2023 12:12, Arseniy Krasnov wrote: =20 > >>>>> Hello Miquel, Liang > >>>>> > >>>>> On 22.05.2023 18:05, Miquel Raynal wrote: =20 > >>>>>> Hi Arseniy, > >>>>>> > >>>>>> AVKrasnov@sberdevices.ru wrote on Mon, 15 May 2023 12:44:35 +0300: > >>>>>> =20 > >>>>>>> This fixes read/write functionality by: > >>>>>>> 1) Changing NFC_CMD_RB_INT bit value. =20 > >>>>>> > >>>>>> I guess this is a separate fix > >>>>>> =20 > >>>>> > >>>>> Ok, I'll move it to separate patch > >>>>> =20 > >>>>>>> 2) Adding extra NAND_CMD_STATUS command on each r/w request. = =20 > >>>>>> > >>>>>> Is this really needed? Looks like you're delaying the next op only= . Is > >>>>>> using a delay enough? If yes, then it's probably the wrong approac= h. =20 > >>>> > >>>> Hi Miquel, small update, I found some details from @Liang's message = in v1 talks from the last month: > >>>> > >>>> * > >>>> After sending NAND_CMD_READ0, address, NAND_CMD_READSTART and read s= tatus(NAND_CMD_STATUS =3D 0x70) commands, it should send > >>>> NAND_CMD_READ0 command for exiting the read status mode from the dat= asheet from NAND device. =20 > >>> > >>> That is true. > >>> =20 > >>>> but previous meson_nfc_queue_rb() > >>>> only checks the Ready/Busy pin and it doesn't send read status(NAND_= CMD_STATUS =3D 0x70) command. > >>>> i think there is something wrong with the Ready/Busy pin(please chec= k the hardware whether this > >>>> Ready/Busy pin is connected with SOC) or the source code. i have the= board without Ready/Busy pin and prefer to use the > >>>> nfc command called RB_IO6. it sends NAND_CMD_STATUS command and chec= ks bit6 of the status register of NAND device from the > >>>> data bus and generate IRQ if ready. > >>>> * > >>>> > >>>> I guess, that sequence of commands from this patch is described in d= atasheet (unfortunately I don't have it and relied on the old driver). > >>>> Yesterday I tried to remove sending of NAND_CMD_STATUS from this pat= ch, but it broke current driver - i had ECC errors, so it looks like > >>>> "shot in the dark" situation, to understand this logic. =20 > >>> > >>> When an operation on the NAND array happens (eg. read, prog, erase), > >>> you need to wait "some time" before accessing the internal sram or ev= en > >>> the chip which is "busy" until it gets "ready" again. You can probe t= he > >>> ready/busy pin (that's the hardware way, fast and reliable) or you can > >>> poll a status with NAND_CMD_STATUS. The chips are designed so they can > >>> actually process that command while they are doing time consuming tas= ks > >>> to update the host. But IIRC every byte read will return the status > >>> until you send READ0 again, which means "I'm done with the status > >>> read" somehow. > >>> > >>> Please see nand_soft_waitrdy() in order to understand how this is > >>> supposed to work. You can even use that helper (which is exported) > >>> instead of open-coding it in your driver. See atmel or sunxi > >>> implementations for instance. > >>> > >>> As using the native RB pin is better, you would need to identify > >>> whether you have one or not at probe time and then either poll the > >>> relevant bit of your controller if there is one, or fallback to the > >>> soft read (which should fallback on exec_op in the end). =20 > >> > >> Thanks for this information! I'll use 'nand_soft_waitrdy()' at least, = because i guess that > >> there is no RB pin on my device. =20 > >=20 > > Currently there is only support for the physical pin IIRC. This means > > you cannot just drop it. You need to support both. =20 >=20 > Yes, i'm not going to drop RB pin support, but as I don't have device to = test it(i guess), i'll add > 'nand_sort_waitrdy()' anyway. Clear. Then go for it :) Thanks, Miqu=C3=A8l