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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C7040C5AE59 for ; Mon, 26 May 2025 12:27:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc: To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SGcFMzxRqwZHeyCIUfXG3hV8hcSrtdD19rnC1FAfz94=; b=DkBA2i58KydNhXafLMmiOpa88Z SmYncAcPhPzzLI+FMuSa0CupmZAl8rSu/+y61+Ii2Ps6qklpSPv8wB67iisYePJxcWKbAKE59cm8X pxEqjA08YyIEU+xdUoCHbmPZymdhVJbDvsNc9KUJHUcBCQxaxzRw2UDEj1Bn99NvrSFBN6tOwcCbB khYknvWPOOTPuQRCF6e35hDjNC5wxY8s3EjJFo203GCeWEU2Q1MCG4CWZTswYpMsa7++I+4BUjOK7 rdZU0KYGIz51INszpHRHUfP39jktr4CEbapI8MfitWjIeQ0OKZKUXkHrbAgH+TKH3dVzcUXN7f9w1 TAL4mJCA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uJWvd-00000008n1D-3ZjK; Mon, 26 May 2025 12:27:41 +0000 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uJWtU-00000008msD-42SO; Mon, 26 May 2025 12:25:30 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id E6A7A43999; Mon, 26 May 2025 12:25:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1748262325; 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=SGcFMzxRqwZHeyCIUfXG3hV8hcSrtdD19rnC1FAfz94=; b=OGi0+/oi9B3QDJ1KGV+hqFr4jwgJ66ptIKnfiXUyHOp8YjRVIngeyqOZjOtY3z+rI0y7ug 5z7jfbQ1Ld1G9sISQaoa1It6KFL0gQfrAaFLu1EzG5V4NBnzavkxG/WjWgXRTSeGgTQLWR HsjLu8qP2BEIjmtxcIOKePLrqejwQU/kvU/pcTIq2dogwQiWAOugpH7wUE+UzzE7FgJyMY RjxNiaXyAwVw8ETuf/74U/ccYcEXIDjq4aheJt98HrSZgfIZqN3vq82/mH7TzMxcir7YsQ j/ng/O0laZGNuT038HrZk6FIs5UFuOQJ+ivag8upCNg10izXEde8A9sca3ajpg== From: Miquel Raynal To: Chuanhong Guo Cc: Sky Huang , Matthias Brugger , AngeloGioacchino Del Regno , Richard Weinberger , Vignesh Raghavendra , Daniel Golle , Chia-Lin Kao , Cheng Ming Lin , Christophe JAILLET , Pratyush Yadav , linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Steven Liu Subject: Re: [PATCH nand/next] mtd: nand: spi: Use write_cache first and then update_cache in write operation In-Reply-To: (Chuanhong Guo's message of "Tue, 29 Apr 2025 19:58:05 +0800") References: <20241119093949.3014-1-SkyLake.Huang@mediatek.com> <871pymtab3.fsf@bootlin.com> <87bjsfv0x1.fsf@bootlin.com> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Mon, 26 May 2025 14:25:21 +0200 Message-ID: <87sekry2xa.fsf@bootlin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddujeehudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffgffkfggtgfgsehtqhertddtreejnecuhfhrohhmpefoihhquhgvlhcutfgrhihnrghluceomhhiqhhuvghlrdhrrgihnhgrlhessghoohhtlhhinhdrtghomheqnecuggftrfgrthhtvghrnhepffeghfejtdefieeguddukedujeektdeihfelleeuieeuveehkedvleduheeivdefnecukfhppeeltddrkeelrdduieefrdduvdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledtrdekledrudeifedruddvjedphhgvlhhopehlohgtrghlhhhoshhtpdhmrghilhhfrhhomhepmhhiqhhuvghlrdhrrgihnhgrlhessghoohhtlhhinhdrtghomhdpnhgspghrtghpthhtohepudeipdhrtghpthhtohepghgthhelkeduvddufeesghhmrghilhdrtghomhdprhgtphhtthhopefukhihnfgrkhgvrdfjuhgrnhhgsehmvgguihgrthgvkhdrtghomhdprhgtphhtthhopehmrghtthhhihgrshdrsghgghesghhmrghilhdrtghomhdprhgtphhtthhopegrnhhgvghlohhgihhorggttghhihhnohdruggvlhhrvghgnhhosegtohhllhgrsghorhgrrdgtohhmp dhrtghpthhtoheprhhitghhrghrugesnhhougdrrghtpdhrtghpthhtohepvhhighhnvghshhhrsehtihdrtghomhdprhgtphhtthhopegurghnihgvlhesmhgrkhhrohhtohhpihgrrdhorhhgpdhrtghpthhtoheprggtvghlrghnrdhkrghosegtrghnohhnihgtrghlrdgtohhm X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250526_052529_341026_BCD960A9 X-CRM114-Status: GOOD ( 21.40 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hello Chuanhong, >> >>> Before applying this patch, write operation uses only 34H(update_cac= he): >> >>> [78.937720] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1s= t byte: 0xa5 >> >>> [78.945297] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data = 1st byte: 0xa5 >> >>> [78.954251] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1s= t byte: 0xa5 >> >>> [78.962966] OP code: 0x10, addr val: 0x300 >> >>> [78.968816] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1s= t byte: 0xff >> >>> [78.977233] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data = 1st byte: 0xff >> >>> [78.985124] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1s= t byte: 0xff >> >>> [78.992527] OP code: 0x10, addr val: 0x301 >> >>> [78.996981] OP code: 0x34, addr val: 0x0, data nbytes: 1020, data 1s= t byte: 0xff >> >>> [79.004416] OP code: 0x34, addr val: 0x3fc, data nbytes: 1020, data = 1st byte: 0xff >> >>> [79.012031] OP code: 0x34, addr val: 0x7f8, data nbytes: 72, data 1s= t byte: 0xff >> >>> [79.019435] OP code: 0x10, addr val: 0x302 >> >> I am sorry but above you said that we should not perform: >> >> 0x32, 0x32, 0x32... >> >> because the second time it would clear the cache again. And here >> >> you tell us that actually the core already handles that by performing >> >> instead: >> >> 0x34, 0x34, 0x34... >> >> So what is the problem? >> >> Or maybe I misunderstood the issue, but I think Chuanhong raised an >> >> issue that is already solved? Isn't it? >> >> >> > >> > The issue is that the FORESEE NANDs require the first cache writing >> > instruction to be WRITE_CACHE instead of UPDATE_CACHE. i.e. it needs a >> > command sequence of: >> > 0x32, 0x34, 0x34, 0x34... >> >> So Foresee NANDs do not support update_cache, why are they advertised in >> the first place? Could you we have a less impacting solution for the >> other NANDs? >> >> > This patch does exactly that, making the first instruction issued 0x32. >> > It should be applied to fix the issue above. >> >> My understanding is that this is very specific to FORESEE NANDs and you >> are changing this for all NANDs. I have fears that it will break >> everywhere else. > > I just checked a few datasheets of SPI-NANDs from > Toshiba/Winbond/Etron/ESMT/GigaDevice/Macronix. > All of them specify the programming sequence to be: > write_enable->write_cache->update_cache if needed-> > program_execute->poll status. > Some of them mentions that the only difference between write_cache > and update_cache is whether the page cache is cleared before > writing (Winbond), while others don't specifically say that. > > The original sequence doesn't seem to be following any manufacturers' > instructions. We just haven't run into any problems until this FORESEE > one. That is what I am saying. It currently works, and we may encounter silent failures all around because of this change, even if it might be theoretically correct. Anyhow, we have these templates (both write and update) so let's try to re-use them. However I dislike the current implementation which changes the global wdesc template and puts it back. Can you please propose something cleaner? Thanks, Miqu=C3=A8l