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 E1B33CA6007 for ; Thu, 8 Oct 2026 14:15:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=C8UB02Fd9Xl2npFhVf1l9ebaG5xmmLjc7sg3i9JfLpo=; b=kPEmS8ByBM8vg6 5NNUcFbbB+OBrq2rZ1E9rAdEyP120k1wZGuZTbiKzNKo6lDErSzqQzjqsqY6WNSPNFHt9zixl66hC 1PAFgKr1zaNwjP0qmype/zzt3NSWeSOWnTWyc+gYn667XBJS92WH0UxHzKKRJr4S+KSnVTS3WUoZX EfFBy5p6nOQFyazNZdTZuDLarrlZRVvuZWEgg4otdxmw2lmYStX3UbXBX3ksj9IqYt8bS/NAP8f6c 1Em5Ihj4GS7PXTHr5uu+AfmfvuUTkbstpPLmk5lbqEc9ssisCBZ+87344AJuaL8VrqxXduEHeY7XJ n9cMufejKAH+KWXP8Gog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEou9-00000004WXh-3ZzZ; Thu, 08 Oct 2026 14:15:29 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xEou8-00000004WXL-2xRa for linux-mtd@lists.infradead.org; Thu, 08 Oct 2026 14:15:28 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 4A04940B4B; Thu, 8 Oct 2026 14:15:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 993711F000FF; Thu, 8 Oct 2026 14:15:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791468928; bh=8XJt5C3RPzkVfzrMpjlMPHBznNL0WRY+1WpPfBNC7lc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=B9oz5yhmYDipgCqmIDCLFg109FItC3XHs1e+34ocTlnjyYNSkpOspCfVcNMcCsl3S FEkeEhjBvCbb8I4ZpmJrD81cKuDpCam9vGCqdiFqUfWKxiEwkCahg3scEBA5OCa8JJ HT+z75kDNbwOYy4wW5BzBl7TDDI9/fGhX1dvOn0nZiTVUp8Il2jE21vvMBICobcmjY qkvWElVw9GaBnJ8gGzaYj6+ktG8k9PWtmcX17KNfL1FZXcRdL4NiYbCmKLnpuhBL2E ijE1utH96dthG6UBp6wK17txC6PmyOB1lpz+36xNPGhk95pR/2E/Dn+dZ3+p7/CkmW ZEziy3qpHrpWw== Date: Thu, 8 Oct 2026 21:55:27 +0800 From: Jisheng Zhang To: Nuno =?utf-8?B?U8Oh?= Cc: Miquel Raynal , Nuno =?utf-8?B?U8Oh?= , Fei Xie , Mark Brown , linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [RFC PATCH 0/4] spi: cadence-xspi: add ACMD PIO support for NAND and NOR Message-ID: References: <20260921093701.1341766-1-fei.xie@horizon.auto> <20260928055005.3987624-1-fei.xie@horizon.auto> <87bj99lef4.fsf@bootlin.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org T24gV2VkLCBPY3QgMDcsIDIwMjYgYXQgMDc6MTI6NTdBTSArMDEwMCwgTnVubyBTw6Egd3JvdGU6 Cj4gT24gV2VkLCAyMDI2LTEwLTA3IGF0IDEyOjQ4ICswODAwLCBKaXNoZW5nIFpoYW5nIHdyb3Rl Ogo+ID4gT24gVHVlLCBPY3QgMDYsIDIwMjYgYXQgMDc6NTA6NDRBTSArMDEwMCwgTnVubyBTw6Eg d3JvdGU6Cj4gPiA+IE9uIFN1biwgMjAyNi0xMC0wNCBhdCAxNjozNyArMDIwMCwgTWlxdWVsIFJh eW5hbCB3cm90ZToKPiA+ID4gPiBIZWxsbywKPiA+ID4gPiAKPiA+ID4gPiBPbiAyOC8wOS8yMDI2 IGF0IDE2OjAyOjI3ICswMSwgTnVubyBTw6EgPG51bm8uc2FAYW5hbG9nLmNvbT4gd3JvdGU6Cj4g PiA+ID4gCj4gPiA+ID4gPiBPbiBNb24sIFNlcCAyOCwgMjAyNiBhdCAwMTo1MDowNVBNICswODAw LCBGZWkgWGllIHdyb3RlOgo+ID4gPiA+ID4gCj4gPiA+ID4gPiBIaSBGZWksCj4gPiA+ID4gPiAK PiA+ID4gPiA+ID4gSGkgTnVubywgTWlxdWVsLAo+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gVGhh bmtzIGZvciBhc2tpbmcgZm9yIGJlbmNobWFya3MuIEkgYmFja3BvcnRlZCB0aGUgMzIvNjQtYml0 IFNUSUcgU0RNQQo+ID4gPiA+ID4gPiB0cmFuc2ZlciBjaGFuZ2VzIGZyb20gdGhlIHBhdGNoIE51 bm8gcG9pbnRlZCB0byBbMV0gdG8gb3VyIHZlbmRvciA2LjEKPiA+ID4gPiA+ID4ga2VybmVsLCBh bmQgY29tcGFyZWQgdGhhdCBTVElHIHBhdGggYWdhaW5zdCB0aGUgQUNNRCBTUEkgTkFORCBwYXRo IGZyb20KPiA+ID4gPiA+ID4gdGhpcyBSRkMuIEkgaGF2ZSBub3QgYXBwbGllZCBOdW5vJ3Mgc2Vw YXJhdGUgQUNNRCByZWFkIGltcGxlbWVudGF0aW9uOwo+ID4gPiA+ID4gPiB0aGUgZmlndXJlcyBi ZWxvdyBhcmUgZm9yIHRoZSBpbXBsZW1lbnRhdGlvbiBpbiB0aGlzIFJGQy4KPiA+ID4gPiA+ID4g Cj4gPiA+ID4gPiA+IFRoZSBkZXZpY2UgaXMgYSBHRDVGNEdNOFJFIFNQSSBOQU5EICgyIEtpQiBw YWdlcywgMTI4IEtpQiBlcmFzZWJsb2NrcykKPiA+ID4gPiA+ID4gb24gYSBIb3Jpem9uIEo2QiBi b2FyZCwgcnVubmluZyBhdCA4MCBNSHogaW4gcXVhZCBTRFIgbW9kZS4gQm90aCBwYXRocwo+ID4g PiA+ID4gPiB1c2VkIHRoZSBzYW1lIGJvYXJkIFBIWSBjb25maWd1cmF0aW9uLiBTVElHIG5lZWRl ZCBvbmUgYWRkaXRpb25hbCBkdW1teQo+ID4gPiA+ID4gPiBjbG9jayBmb3IgdGhlIEVCaCByZWFk LWNhY2hlIGNvbW1hbmQgb24gdGhpcyBib2FyZCB0byByZXR1cm4gY29ycmVjdAo+ID4gPiA+ID4g PiBkYXRhIGF0IDgwIE1Iei4gVGhpcyBpcyBhIGxvY2FsIHRlc3QgYWRqdXN0bWVudCwgbm90IHBh cnQgb2YgdGhlIHBvc3RlZAo+ID4gPiA+ID4gPiBSRkMgb3IgWzFdOyBJIGV4Y2x1ZGVkIHRoZSBp bmNvcnJlY3QgU1RJRyByZWFkcyBmcm9tIHRoZSBjb21wYXJpc29uLgo+ID4gPiA+ID4gPiAKPiA+ ID4gPiA+ID4gSSByYW4gZmxhc2hfc3BlZWQgLWMgNSAtZCAvZGV2L210ZDE4IHRocmVlIHRpbWVz IHdpdGggZWFjaCBtb2RlLiBUaGUKPiA+ID4gPiA+ID4gbnVtYmVycyBiZWxvdyBhcmUgdGhlIGFy aXRobWV0aWMgbWVhbnMsIGluIEtpQi9zOgo+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFNU SUfCoMKgwqDCoMKgIEFDTUQgUElPCj4gPiA+ID4gPiA+IMKgIGVyYXNlYmxvY2sgd3JpdGUgc3Bl ZWTCoMKgwqDCoMKgIDM2ODXCoMKgwqDCoMKgwqDCoMKgwqAgMzU1NQo+ID4gPiA+ID4gPiDCoCBl cmFzZWJsb2NrIHJlYWQgc3BlZWTCoMKgwqDCoMKgIDEyNDY4wqDCoMKgwqDCoMKgwqDCoCAxNDIy Mgo+ID4gPiA+ID4gPiDCoCBwYWdlIHdyaXRlIHNwZWVkwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAz NjcxwqDCoMKgwqDCoMKgwqDCoMKgIDM1MTAKPiA+ID4gPiA+ID4gwqAgcGFnZSByZWFkIHNwZWVk wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAxMTkzMcKgwqDCoMKgwqDCoMKgwqAgMTM3MTYKPiA+ID4g PiA+ID4gwqAgZXJhc2Ugc3BlZWTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNDAwMDDC oMKgwqDCoMKgwqDCoMKgIDM3NjQ3Cj4gPiA+ID4gPiAKPiA+ID4gPiA+IFNvIHRoaXMgZ29lcyBh bG9uZyB3aXRoIG15IGV4cGVjdGF0aW9ucy4gSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIHRoYXQK PiA+ID4gPiA+IFBST0dSQU0gKyBFUkFTRSBpcyBub3Qgd29ydGggdGhlIHRyb3VibGU/IFdlIGV2 ZW4gbG9vc2UgcGVyZm9ybWFuY2UuLi4KPiA+ID4gPiAKPiA+ID4gPiBZZWFoLgo+ID4gPiA+IAo+ ID4gPiA+ID4gPiBGb3IgYSBzZXBhcmF0ZSBzZXF1ZW50aWFsLXJlYWQgdGVzdCwgSSBlcmFzZWQg YW5kIHByb2dyYW1tZWQgdGhlIGZpcnN0Cj4gPiA+ID4gPiA+IDY0IE1pQiB3aXRoIGtub3duIHJh bmRvbSBkYXRhLCB0aGVuIGNoZWNrZWQgdGhhdCBlYWNoIG1vZGUgcmVhZCBiYWNrCj4gPiA+ID4g PiA+IHRoZSBjb21wbGV0ZSBhcmVhIGJ5dGUtZm9yLWJ5dGUuIEJvdGggU0hBLTI1NiBoYXNoZXMg bWF0Y2hlZCB0aGUgc291cmNlOwo+ID4gPiA+ID4gPiB0aGUgcmVwb3J0ZWQgRUNDIGZhaWx1cmUg Y291bnRzIHdlcmUgemVyby4gSSB0aGVuIHJhbjoKPiA+ID4gPiA+IAo+ID4gPiA+ID4gV2hhdCBk byB5b3UgbWVhbiBieSBzZXF1ZW50aWFsIHJlYWQ/IERvZXMgeW91ciBmbGFzaCBzdXBwb3J0cyBj b250aW51b3VzCj4gPiA+ID4gPiByYWRzIChvciBidWZmZXJlZCBtb2RlIEkgdGhpbmspLiBJZiBz bywgSSB3b3VsZCBleHBlY3QgbXVjaCBiZXR0ZXIKPiA+ID4gPiA+IG51bWJlciBmb3IgdGhlIEFD TUQgY2FzZS4gQnV0IHRoYXQgY2FuIGJlIHRoZSBpc3N1ZSBvZiBoYXZpbmcgYm90aCB0aGUKPiA+ ID4gPiA+IGNvbnRyb2xsZXIgYW5kIHRoZSBjaGlwIHRyeWluZyB0byB3YWxrIHBhZ2VzLgo+ID4g PiA+IAo+ID4gPiA+IFNlcXVlbnRpYWwsIGNvbnRpbnVvdXMgYW5kIGJ1ZmZlcmVkIHNob3VsZCBt ZWFuIHRoZSBzYW1lIGluIHRoZSBOQU5ECj4gPiA+ID4gY29udGV4dC4KPiA+ID4gPiAKPiA+ID4g PiA+ID4gwqAgL3Zhci9idXN5Ym94L3RpbWUgLWYgJ3JlYWw9JWUgdXNlcj0lVSBzeXM9JVMgY3B1 PSVQJyBcCj4gPiA+ID4gPiA+IMKgwqDCoCBkZCBpZj0vZGV2L210ZDE4IG9mPS9kZXYvbnVsbCBi cz0xTSBjb3VudD02NAo+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgU1RJR8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIEFDTUQgUElPCj4gPiA+ID4gPiA+IMKgIGVsYXBzZWQgKHRocmVlIHJ1bnMpwqDCoMKg IDUuMzAvNS4yOC81LjI2IHPCoCA0LjY2LzQuNjUvNC42NSBzCj4gPiA+ID4gPiA+IMKgIG1lYW4g dGhyb3VnaHB1dMKgwqDCoMKgwqDCoMKgwqAgMTIuMTIgTWlCL3PCoMKgwqDCoMKgwqAgMTMuNzUg TWlCL3MKPiA+ID4gPiA+ID4gwqAgbWVhbiBzeXN0ZW0gdGltZcKgwqDCoMKgwqDCoMKgIDMuNTUg c8KgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMS4wNiBzCj4gPiA+ID4gPiA+IMKgIHByb2Nlc3MgQ1BV IHVzYWdlwqDCoMKgwqDCoMKgIDY3JcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMjIlCj4g PiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBPbiB0aGlzIE5BTkQsIEFDTUQgaW1wcm92ZXMgdGhlIDY0 IE1pQiByZWFkIHRocm91Z2hwdXQgYnkgYWJvdXQgMTMuNSUKPiA+ID4gPiA+ID4gYW5kIHJlZHVj ZXMgdGhlIHJlYWRpbmcgcHJvY2VzcydzIENQVSB1c2FnZSBieSA0NSBwZXJjZW50YWdlIHBvaW50 cy4KPiA+ID4gPiA+ID4gVGhlIGZsYXNoX3NwZWVkIHJlc3VsdHMgc2hvdyBhIHNpbWlsYXIgZ2Fp biBmb3IgcmVhZHMsIGluY2x1ZGluZwo+ID4gPiA+ID4gPiBzaW5nbGUtcGFnZSByZWFkcy4KPiA+ ID4gPiAKPiA+ID4gPiBGWUksIGlmIHlvdSBwdWxsIGEgcmVjZW50IHZlcnNpb24gb2YgbXRkLXV0 aWxzLCBmbGFzaF9zcGVlZCBjYW4KPiA+ID4gPiBiZW5jaG1hcmsgY29udGludW91cyByZWFkIGlt cHJvdmVtZW50cyB3aXRoIHRoZSAtQyBvcHRpb24uCj4gPiA+ID4gCj4gPiA+ID4gPiA+IEkgZG8g bm90IHNlZSBhIHByb2dyYW0gb3IgZXJhc2UgdGhyb3VnaHB1dCBiZW5lZml0Ogo+ID4gPiA+ID4g PiBBQ01EIGlzIHNsaWdodGx5IHNsb3dlciBmb3IgYm90aCBpbiB0aGlzIHNldHVwLiBUaGVzZSBh cmUgU1BJIE5BTkQKPiA+ID4gPiA+ID4gcmVzdWx0cyBvbmx5OyBJIGhhdmUgbm90IGJlbmNobWFy a2VkIHRoZSBOT1IgcGF0aCBvbiB0aGlzIGJvYXJkLgo+ID4gPiA+ID4gCj4gPiA+ID4gPiBTbyBD UFUgcmVzdWx0cyBhcmUgdGhlIGJpbmcgdGhpbmcgaGVyZS4gSSBndWVzcyB3ZSBuZWVkIHRvIGRl Y2lkZSBpZgo+ID4gPiA+ID4gaXQncyB3b3J0aCB0aGUgYW1vdW50IG9mIGNvbXBsZXhpdHkgaXQg cmVxdWlyZXMgZm9yIHRoZSB3aG9sZSB0aGluZyB0bwo+ID4gPiA+ID4gd29yay4gQXMgSSBtZW50 aW9uZWQsIGlmIHRoZSBjaGlwIGhhcyBjb250aW51b3VzIG1vZGUgYW5kIHdlIHRyeSB0bwo+ID4g PiA+ID4gcmVhZCBhbnl0aGluZyBiaWdnZXIgdGhhbiBwYWdlIHNpemUgd2Ugc2hvdWxkIGxldCB0 aGUgbmFuZCBjaGlwIHRvCj4gPiA+ID4gPiB3YWxrIHRoZSBwYWdlcyBhbmQgdGhhdCBtZWFucyB0 aGUgYmVoYXZpb3Igd2UgaGF2ZSB0b2RheSAoSU1ITyBvZgo+ID4gPiA+ID4gY291cnNlKToKPiA+ ID4gPiA+IAo+ID4gPiA+ID4gMHgxMyAoU1RJRykgKyB3YWl0ICsgcmVhZCBmcm9tIGNhY2hlIChB Q01EKQo+ID4gPiA+ID4gCj4gPiA+ID4gPiBJZiB3ZSdyZSBvbmx5IHJlYWRpbmcgYSBzaW5nbGUg cGFnZSB0aGVuIHRoZSBsb2dpYyBpbiB0aGlzIHNlcmllcyB3b3VsZAo+ID4gPiA+ID4gcGF5b2Zm IChzbGlnaHQgcGVyZm9ybWFuY2UgZ2FpbiArIHNpZ25pZmljYW50IGRyb3AgaW4gY3B1IGxvYWQp LiBPbmUgc2ltcGxlCj4gPiA+ID4gPiB3YXkgZm9yIGRvaW5nIHRoaXMgYXMgYSBzdGFydGluZyBw b2ludCB3b3VsZCBiZToKPiA+ID4gPiA+IAo+ID4gPiA+ID4gKiBOYW5kIGhhcyBjb250IG1vZGUg LT4geHNwaSBjb250cm9sbGVyIGRvZXMgbm90aGluZyBzcGVjaWFsCj4gPiA+ID4gPiAqIE5hbmQg aGFzIG5vIGNvbnQgbW9kZSAtPiBBZ2dyZWdhdGUgdGhlIHhmZXJzIHRvZ2V0aGVyLgo+ID4gPiA+ IAo+ID4gPiA+IEknbSBmaW5lIHdpdGggc3RhdGljIGRlY2lzaW9ucyBsaWtlIHRoYXQsIGJ1dCBt eSB1bmRlcnN0YW5kaW5nIG9mIHRoZQo+ID4gPiA+IGFib3ZlIGlzIHRoYXQgQUNNRCBtb2RlIGlz IHVzZWZ1bCBmb3IgYWxsIHJlYWRzLiBzbyBJIGRvbid0IGdldCB3aHkgeW91Cj4gPiA+ID4gd291 bGQgbm8gdXNlIGl0IGZvciBhbGwuIE1heWJlIGJlY2F1c2UgaXQgd291bGQgYnJlYWsgY29udGlu dW91cyByZWFkcz8KPiA+ID4gPiAoc29ycnkgSSBsb3N0IGEgYml0IG9mIHRoZSBjb250ZXh0IGFs cmVhZHkpLgo+ID4gPiAKPiA+ID4gRXhhY3RseS4gSW4gQUNNRCwgaXMgYWxzbyBjYXBhYmxlIG9m ICJ3YWxraW5nIHBhZ2VzIiBmb3IgcmVhZHMgYmlnZ2VyIHRoYW4gcGFnZQo+ID4gPiBzaXplCj4g PiA+IChoZW5jZSB0aGUgbmVlZCB0byBrbm93IHRoZSBmbGFzaCBnZW9tZXRyeSkgYW5kIElJUkMs IHRoYXQgZG9lcyBub3QgcmVhbGx5IHdvcmsKPiA+ID4gd2VsbAo+ID4gPiB3aGVuIHRoZSBmbGFz aCBpcyBhbHNvIGRvaW5nIGl0Lgo+ID4gPiAKPiA+ID4gPiAKPiA+ID4gPiBGb3Igd3JpdGVzIGFu ZCBlcmFzZXMgaG93ZXZlciwgaXQgc2VlbXMgbGlrZSB3ZSBjb3VsZCBrZWVwIHRoZSBTVElHIHBh dGguCj4gPiA+ID4gCj4gPiA+ID4gPiBEb2luZyBzb21ldGhpbmcgZHluYW1pYyB3b3VsZCBiZSBt dWNoIG1vcmUgY29tcGxleCBJIGd1ZXNzLiBXaXRoIHRoZQo+ID4gPiA+ID4gYWJvdmUgcmVhc29u aW5nLCBoYXZpbmcgc29tZSBtZW1faW5mbygpIGtpbmQgb2Ygc3BpX21lbSBjYWxsYmFjayB0byB0 ZWxsCj4gPiA+ID4gPiB1cyB0aGluZ3MgbGlrZSBnZW9tZXRyeSwgY29udGludW91cyBtb2RlIHN1 cHBvcnQsIGV0YyB3b3VsZCBiZSBlbm91Z2ggdG8KPiA+ID4gPiA+IGhhbmRsZSB0aGUgYWJvdmUg SSB0aGluay4gVGhlIHJlYXNvbmluZyBpcyB0aGF0IHJlYWRpbmcgYSBuYW5kIHBhZ2UgaXMKPiA+ ID4gPiA+IGFsd2F5cyBsaWtlIHNwaW5hbmRfbG9hZF9wYWdlX29wKCkgKG9wY29kZSAweDEzKSAr IHNwaW5hbmRfd2FpdCgpICsKPiA+ID4gPiA+IHNwaW5hbmRfcmVhZF9mcm9tX2NhY2hlX29wKCkg c28gd2UgY291bGQgcHJvYmFibHkgYWdncmVnYXRlIGV2ZXJ5dGhpbmcKPiA+ID4gPiA+IGluIHRo ZSBsYXN0IGNhbGwgb24gdGhlIGNvbnRyb2xsZXIgc2lkZSB3aXRob3V0IGNvbXBsaWNhdGluZyB0 aGUgbmFuZCBjb3JlCj4gPiA+ID4gPiBsb2dpYy4KPiA+ID4gPiAKPiA+ID4gPiBJbiBnZW5lcmFs LCBkcml2ZXJzIG1ha2luZyBhc3N1bXB0aW9ucyBoYXMgYmVlbiBhIGRpc2FzdGVyIGluIHRoZSBy YXcKPiA+ID4gPiBOQU5EIHdvcmxkLiBUaGlzIHdhcyB0aGUgbWFpbiByZWFzb24gZm9yIHRoZSAt PmV4ZWNfb3AoKSBpbnRyb2R1Y3Rpb24KPiA+ID4gPiB0aGVyZTogZ2l2aW5nIHRoZSB3aG9sZSBv cGVyYXRpb24gdG8gdGhlIGNvbnRyb2xsZXIgc28gaXQgY2FuIGRlY2lkZQo+ID4gPiA+IHdoYXQg dG8gZG8gd2l0aG91dCBndWVzc2luZy4gQnV0IHdlIHRoaW5raW5nIGF0IHRoZSBvcGVyYXRpb24g Ym91bmRhcnksCj4gPiA+ID4gbm90IGF0IHRoZSAic2V0IG9mIG9wZXJhdGlvbnMiIGxldmVsLiBT aW5jZSAtPmV4ZWNfb3AoKSBpbiB0aGUgU1BJIE5BTkQKPiA+ID4gPiBzdWJzeXN0ZW0gaGFzIGJl ZW4gd3JpdHRlbiBmb2xsb3dpbmcgdGhlIHNhbWUgcGhpbG9zb3BoeSwgSSBmZWFyIHdlJ3JlCj4g PiA+ID4gZ29pbmcgdG8gdHJ5IG1ha2Ugcm91bmRzIGZpdCBpbnNpZGUgc3F1YXJlcy4gT25lIG9m IHRoZSBwb3NzaWJsZQo+ID4gPiAKPiA+ID4gRmFpciBlbm91Z2ghIEFncmVlZAo+ID4gPiAKPiA+ ID4gPiBhcHByb2FjaCB3b3VsZCBiZSB0byBtaW1pYyB3aGF0IHdlJ3ZlIGRvbmUgZm9yIHRoZSBz b21lIGxpbWl0ZWQKPiA+ID4gPiBjb250cm9sbGVyczogcGFjayBldmVyeXRoaW5nIGluIG9uZSBz aW5nbGUgb3AgKHNlZSB0aGUgX21vbm9saXRoaWMKPiA+ID4gPiBzdWZmaXggaW4gZHJpdmVycy9t dGQvbmFuZC9yYXcvKS4gVGhhdCdzIGp1c3Qgb25lIGlkZWEuCj4gPiA+ID4gCj4gPiA+IAo+ID4g PiBJIGNhbiB0YWtlIGEgbG9vayBtb3N0bHkgZm9yIGN1cmlvc2l0eSBhcyBteSBpbnRlbnRpb24g aXMgbm90IHRvICJzdGVhbCIgdGhpcwo+ID4gPiB3b3JrCj4gPiA+IGZyb20gRmVpLiBJZiBldmVy eW9uZSBhZ3JlZXMgKHNwZWNpYWxseSBGZWkpLCB3aGF0IEkgY2FuIGRvIGlzIHRvIHNlbmQgbXkg c2ltcGxlcgo+ID4gPiBwYXRjaGVzIHRoYXQganVzdCBzdXBwb3J0IEFDTUQgKHdpdGhvdXQgYW55 IHNwZWNpYWwgZGlzdGluY3Rpb24gYmV0d2VlbiBOYW5kIGFuZAo+ID4gPiBOb3IpCj4gPiA+IEZv ciBOYW5kcywgSSBoYXZlIGEgbWl4IG9mIFNUSUcgYW5kIEFDTUQsIHdoZXJlIGJpZyBnYWlucyBj b21lIGZyb20gTmFuZHMgd2l0aAo+ID4gPiBjb250Cj4gPiA+IG1vZGUuCj4gPiA+IAo+ID4gPiBU aGVuIHdlIGNhbiBidWlsZCBvbiB0b3Agb2YgaXQgaW4gb3JkZXIgdG8gaW1wcm92ZSBOYW5kIHN1 cHBvcnQgKG1vc3RseSBvbiBDUFUKPiA+ID4gbG9hZCkuCj4gPiAKPiA+IEknbSBhbHNvIGludGVy ZXN0ZWQgaW4gdGhpcyBkcml2ZXIncyBwZXJmb3JtYW5jZS4gQSBiaXQgb2ZmIHRoZSBzdWJqZWN0 Cj4gPiBidXQgcmVsYXRlZCBxdWVzdGlvbjogVXN1YWxseSwgdGhlIFNvYyBtYXkgY29ubmVjdCB0 aGUgeHNwaSB0byBkbWEKPiA+IGVuZ2luZSwgSSdtIGN1cmlvdXMgd2hhdCB3b3VsZCBiZSB0aGUg YmVuZWZpdCBvZiBhZGRpbmcgZG1hIGVuZ2luZQo+ID4gc3VwcG9ydCBpbnN0ZWFkIG9mIEFDTUQ/ IElzIGRtYSBlbmdpbmUgc3VwcG9ydCBzaW1wbGVyIGFuZAo+ID4gaXMgdGhlIGdhaW4ocGVyZm9y bWFuY2UgKyBjcHUgbG9hZCkgbW9yZT8KPiA+IAo+IAo+IEknbSBub3QgZmFtaWxpYXIgd2l0aCB0 aGF0IGFwcHJvYWNoIHRiaC4gQnV0IEkgd291bGQgYXNzdW1lIHBlcmZvcm1hbmNlIHRvIGJlIHBy ZXR0eQo+IG11Y2ggc2ltaWxhciB0byB3aGF0IEkgaGF2ZSBnaXZlbiB0aGF0IEFDTUQgdXNlcyB0 aGUgSVAgaW50ZXJuYWwgRE1BIGVuZ2luZS4gQnV0IG5vdAo+IHVzaW5nIEFDTUQgbWVhbnMgbm90 IGhhdmluZyB0aGUgY3B1IGdhaW5zIGF0IGxlYXN0IGZvciB0aGUgc21hbGxlciB0cmFuc2ZlcnMg YXMgd2UKPiB3b3VsZCBub3QgYmUgYWJsZSB0byBhZ2dyZWdhdGUgdHJhbnNmZXJzLiBGV0lXLCBn aXZlbiB0aGF0IHlvdSBtaWdodCBub3QgaGF2ZSBsb29rZWQKCkhtbSwgbXkgcGxhdGZvcm1zIGNv bm5lY3QgdHdvIGRtYWVuZ2luZSBjaGFubmVscyB0byB0aGUgeHNwaSBjb250cm9sbGVyLApidXQg SSBoYXZlbid0IGFkZGVkIHRoZSBkbWEtZW5naW5lIHN1cHBvcnQgdG8gdGhlIGRyaXZlciB5ZXQu IElmIHRoZQpBQ01EIGlzIGVub3VnaCwgd2h5IEhXIGNvbm5lY3RzIGRtYS1lbmdpbmUgdGhlbj8g SnVzdCBjdXJpb3VzLCB0aGVyZQptdXN0IGJlIHBlcmZvcm1hbmNlIGdhaW4gSSBndWVzcy4gQnV0 IEknbSBub3Qgc3VyZSBhbmQgSSBkb24ndCBoYXZlCnBlcmZvcm1hbmNlIG51bWJlcnMuCgo+IGF0 IHRoZSB3aG9sZSB0aHJlYWQsIHRoaXMgaXMgd2hhdCBJIGhhdmU6Cj4gCj4gaHR0cHM6Ly9naXRo dWIuY29tL2FuYWxvZ2RldmljZXNpbmMvbGludXgvcHVsbC8zNDc4L2NoYW5nZXMvNDc3ZTYwOTU1 MDg1NDY1NTIwNzFiODI1YTY2NTIyY2Y2OTdjMjdjMgo+IAo+IC0gTnVubyBTw6EKPiAKPiA+IFJl Z2FyZHMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpMaW51eCBNVEQgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1tdGQvCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9222417B50F for ; Thu, 8 Oct 2026 14:15:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791468929; cv=none; b=UzS71XctsW5Obn+qplyVcMaL4gGXNMSWd2qtSnvQpMagASoyGmoaI1Sq6UOnsGNbXXJEk501wI7gSH3lpagCaDL+00W4jo7K09ush8hJNSLcg5Z95EJDQ6GUqbCHqeBbo89gSKqhSWtoC6dnkQzjY4g5OEocd1HahhnY+jlvWBg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791468929; c=relaxed/simple; bh=QVyNV4WOcjg/olM/Wk2BR/0cymsBuF61r00W2QE+p40=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LTT3yaQ2ziZWcz/HGSCIuD0JoCT/9aR8mEPzaj9wX8Pcd84CJNMFm/fvaNZSooDDTxRBn2PyVHyDyMerTCGye4r1J5bxcXuTbiTz/JmJvmYJsJfI2/DS9oaqK4Q8PDN7Ej3xLG0qw0v2SxFPd8CV5Mf/ZoulnjApHUbo6fnuXdU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B9oz5yhm; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B9oz5yhm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 993711F000FF; Thu, 8 Oct 2026 14:15:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1791468928; bh=8XJt5C3RPzkVfzrMpjlMPHBznNL0WRY+1WpPfBNC7lc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=B9oz5yhmYDipgCqmIDCLFg109FItC3XHs1e+34ocTlnjyYNSkpOspCfVcNMcCsl3S FEkeEhjBvCbb8I4ZpmJrD81cKuDpCam9vGCqdiFqUfWKxiEwkCahg3scEBA5OCa8JJ HT+z75kDNbwOYy4wW5BzBl7TDDI9/fGhX1dvOn0nZiTVUp8Il2jE21vvMBICobcmjY qkvWElVw9GaBnJ8gGzaYj6+ktG8k9PWtmcX17KNfL1FZXcRdL4NiYbCmKLnpuhBL2E ijE1utH96dthG6UBp6wK17txC6PmyOB1lpz+36xNPGhk95pR/2E/Dn+dZ3+p7/CkmW ZEziy3qpHrpWw== Date: Thu, 8 Oct 2026 21:55:27 +0800 From: Jisheng Zhang To: Nuno =?utf-8?B?U8Oh?= Cc: Miquel Raynal , Nuno =?utf-8?B?U8Oh?= , Fei Xie , Mark Brown , linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [RFC PATCH 0/4] spi: cadence-xspi: add ACMD PIO support for NAND and NOR Message-ID: References: <20260921093701.1341766-1-fei.xie@horizon.auto> <20260928055005.3987624-1-fei.xie@horizon.auto> <87bj99lef4.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-spi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Oct 07, 2026 at 07:12:57AM +0100, Nuno Sá wrote: > On Wed, 2026-10-07 at 12:48 +0800, Jisheng Zhang wrote: > > On Tue, Oct 06, 2026 at 07:50:44AM +0100, Nuno Sá wrote: > > > On Sun, 2026-10-04 at 16:37 +0200, Miquel Raynal wrote: > > > > Hello, > > > > > > > > On 28/09/2026 at 16:02:27 +01, Nuno Sá wrote: > > > > > > > > > On Mon, Sep 28, 2026 at 01:50:05PM +0800, Fei Xie wrote: > > > > > > > > > > Hi Fei, > > > > > > > > > > > Hi Nuno, Miquel, > > > > > > > > > > > > Thanks for asking for benchmarks. I backported the 32/64-bit STIG SDMA > > > > > > transfer changes from the patch Nuno pointed to [1] to our vendor 6.1 > > > > > > kernel, and compared that STIG path against the ACMD SPI NAND path from > > > > > > this RFC. I have not applied Nuno's separate ACMD read implementation; > > > > > > the figures below are for the implementation in this RFC. > > > > > > > > > > > > The device is a GD5F4GM8RE SPI NAND (2 KiB pages, 128 KiB eraseblocks) > > > > > > on a Horizon J6B board, running at 80 MHz in quad SDR mode. Both paths > > > > > > used the same board PHY configuration. STIG needed one additional dummy > > > > > > clock for the EBh read-cache command on this board to return correct > > > > > > data at 80 MHz. This is a local test adjustment, not part of the posted > > > > > > RFC or [1]; I excluded the incorrect STIG reads from the comparison. > > > > > > > > > > > > I ran flash_speed -c 5 -d /dev/mtd18 three times with each mode. The > > > > > > numbers below are the arithmetic means, in KiB/s: > > > > > > > > > > > >                                STIG      ACMD PIO > > > > > >   eraseblock write speed      3685          3555 > > > > > >   eraseblock read speed      12468         14222 > > > > > >   page write speed            3671          3510 > > > > > >   page read speed            11931         13716 > > > > > >   erase speed                40000         37647 > > > > > > > > > > So this goes along with my expectations. I think we can all agree that > > > > > PROGRAM + ERASE is not worth the trouble? We even loose performance... > > > > > > > > Yeah. > > > > > > > > > > For a separate sequential-read test, I erased and programmed the first > > > > > > 64 MiB with known random data, then checked that each mode read back > > > > > > the complete area byte-for-byte. Both SHA-256 hashes matched the source; > > > > > > the reported ECC failure counts were zero. I then ran: > > > > > > > > > > What do you mean by sequential read? Does your flash supports continuous > > > > > rads (or buffered mode I think). If so, I would expect much better > > > > > number for the ACMD case. But that can be the issue of having both the > > > > > controller and the chip trying to walk pages. > > > > > > > > Sequential, continuous and buffered should mean the same in the NAND > > > > context. > > > > > > > > > >   /var/busybox/time -f 'real=%e user=%U sys=%S cpu=%P' \ > > > > > >     dd if=/dev/mtd18 of=/dev/null bs=1M count=64 > > > > > > > > > > > >                           STIG              ACMD PIO > > > > > >   elapsed (three runs)    5.30/5.28/5.26 s  4.66/4.65/4.65 s > > > > > >   mean throughput         12.12 MiB/s       13.75 MiB/s > > > > > >   mean system time        3.55 s            1.06 s > > > > > >   process CPU usage       67%               22% > > > > > > > > > > > > On this NAND, ACMD improves the 64 MiB read throughput by about 13.5% > > > > > > and reduces the reading process's CPU usage by 45 percentage points. > > > > > > The flash_speed results show a similar gain for reads, including > > > > > > single-page reads. > > > > > > > > FYI, if you pull a recent version of mtd-utils, flash_speed can > > > > benchmark continuous read improvements with the -C option. > > > > > > > > > > I do not see a program or erase throughput benefit: > > > > > > ACMD is slightly slower for both in this setup. These are SPI NAND > > > > > > results only; I have not benchmarked the NOR path on this board. > > > > > > > > > > So CPU results are the bing thing here. I guess we need to decide if > > > > > it's worth the amount of complexity it requires for the whole thing to > > > > > work. As I mentioned, if the chip has continuous mode and we try to > > > > > read anything bigger than page size we should let the nand chip to > > > > > walk the pages and that means the behavior we have today (IMHO of > > > > > course): > > > > > > > > > > 0x13 (STIG) + wait + read from cache (ACMD) > > > > > > > > > > If we're only reading a single page then the logic in this series would > > > > > payoff (slight performance gain + significant drop in cpu load). One simple > > > > > way for doing this as a starting point would be: > > > > > > > > > > * Nand has cont mode -> xspi controller does nothing special > > > > > * Nand has no cont mode -> Aggregate the xfers together. > > > > > > > > I'm fine with static decisions like that, but my understanding of the > > > > above is that ACMD mode is useful for all reads. so I don't get why you > > > > would no use it for all. Maybe because it would break continuous reads? > > > > (sorry I lost a bit of the context already). > > > > > > Exactly. In ACMD, is also capable of "walking pages" for reads bigger than page > > > size > > > (hence the need to know the flash geometry) and IIRC, that does not really work > > > well > > > when the flash is also doing it. > > > > > > > > > > > For writes and erases however, it seems like we could keep the STIG path. > > > > > > > > > Doing something dynamic would be much more complex I guess. With the > > > > > above reasoning, having some mem_info() kind of spi_mem callback to tell > > > > > us things like geometry, continuous mode support, etc would be enough to > > > > > handle the above I think. The reasoning is that reading a nand page is > > > > > always like spinand_load_page_op() (opcode 0x13) + spinand_wait() + > > > > > spinand_read_from_cache_op() so we could probably aggregate everything > > > > > in the last call on the controller side without complicating the nand core > > > > > logic. > > > > > > > > In general, drivers making assumptions has been a disaster in the raw > > > > NAND world. This was the main reason for the ->exec_op() introduction > > > > there: giving the whole operation to the controller so it can decide > > > > what to do without guessing. But we thinking at the operation boundary, > > > > not at the "set of operations" level. Since ->exec_op() in the SPI NAND > > > > subsystem has been written following the same philosophy, I fear we're > > > > going to try make rounds fit inside squares. One of the possible > > > > > > Fair enough! Agreed > > > > > > > approach would be to mimic what we've done for the some limited > > > > controllers: pack everything in one single op (see the _monolithic > > > > suffix in drivers/mtd/nand/raw/). That's just one idea. > > > > > > > > > > I can take a look mostly for curiosity as my intention is not to "steal" this > > > work > > > from Fei. If everyone agrees (specially Fei), what I can do is to send my simpler > > > patches that just support ACMD (without any special distinction between Nand and > > > Nor) > > > For Nands, I have a mix of STIG and ACMD, where big gains come from Nands with > > > cont > > > mode. > > > > > > Then we can build on top of it in order to improve Nand support (mostly on CPU > > > load). > > > > I'm also interested in this driver's performance. A bit off the subject > > but related question: Usually, the Soc may connect the xspi to dma > > engine, I'm curious what would be the benefit of adding dma engine > > support instead of ACMD? Is dma engine support simpler and > > is the gain(performance + cpu load) more? > > > > I'm not familiar with that approach tbh. But I would assume performance to be pretty > much similar to what I have given that ACMD uses the IP internal DMA engine. But not > using ACMD means not having the cpu gains at least for the smaller transfers as we > would not be able to aggregate transfers. FWIW, given that you might not have looked Hmm, my platforms connect two dmaengine channels to the xspi controller, but I haven't added the dma-engine support to the driver yet. If the ACMD is enough, why HW connects dma-engine then? Just curious, there must be performance gain I guess. But I'm not sure and I don't have performance numbers. > at the whole thread, this is what I have: > > https://github.com/analogdevicesinc/linux/pull/3478/changes/477e6095508546552071b825a66522cf697c27c2 > > - Nuno Sá > > > Regards