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 alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (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 25B86C52D7C for ; Mon, 12 Aug 2024 08:40:39 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 529DA1667; Mon, 12 Aug 2024 10:40:27 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 529DA1667 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1723452037; bh=C39qRErPUQkJNzW9w7SV07Iow5wNuuOXfmuMigKGNYA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=prXNHIvjDlcNOx9sRmcg0ZDBNy8XgCm387Vzp2cuu6j4MB9luS/YvMFYHQ5TZOZ73 EXX1dxsix02g/NZDnW+39+hqSaanRSKEIiX3f9VgdyV6ZYAgv+GbJ427nvIjqHuj9O Q3E8MyJEYZISSwOdXQAw4PvtgkehJrrG4zyDbvZY= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 8CA8DF805B4; Mon, 12 Aug 2024 10:39:52 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id F197DF805B5; Mon, 12 Aug 2024 10:39:51 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 7CFA3F80423; Mon, 12 Aug 2024 10:38:34 +0200 (CEST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 0F4ECF800B0 for ; Mon, 12 Aug 2024 10:38:17 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 0F4ECF800B0 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=c6AlCNyi Received: by mail.gandi.net (Postfix) with ESMTPSA id 9CA3DC0007; Mon, 12 Aug 2024 08:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723451896; 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=Wpp+yPNEBFJMfjQq3cL+mUf+1IBUOb95UB4rmwmrlsY=; b=c6AlCNyiO8HVav7lY582H4/RuX+O01sHF3FNBasOHB+VazJm8ydFO5xcwvZJ6d0jkuT1+i Sv6Jmq7TiB6stzxv6fHQQa+YoLJwE6CB0pLKjHXsxJutvIaUi3XWsYO0U/WLuaOQKhRMaj oYCvTZD9GQ24ua+nUP3gCpF3C6okHJvfQouuv+Um04e3FbRgfLwABTZb1Gz3Bv7n8iXw03 x9Asn7ip/Md3h2Z5s2eWCP8HOY68mRsa/1Af21B9Pn6tV6LjyvoVyXtr2k+qyIVZjDyrqX hZ95LcD6Gu/o+tPGUr5jmWRM7yJB3Z7WuAv3A3Gh79rQQk5Q9dDD2WZqwYr7Vg== Date: Mon, 12 Aug 2024 10:38:12 +0200 From: Miquel Raynal To: "Mahapatra, Amit Kumar" Cc: Tudor Ambarus , "broonie@kernel.org" , "pratyush@kernel.org" , "richard@nod.at" , "vigneshr@ti.com" , "sbinding@opensource.cirrus.com" , "lee@kernel.org" , "james.schulman@cirrus.com" , "david.rhodes@cirrus.com" , "rf@opensource.cirrus.com" , "perex@perex.cz" , "tiwai@suse.com" , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "michael@walle.cc" , "linux-mtd@lists.infradead.org" , "nicolas.ferre@microchip.com" , "alexandre.belloni@bootlin.com" , "claudiu.beznea@tuxon.dev" , "Simek, Michal" , "linux-arm-kernel@lists.infradead.org" , "alsa-devel@alsa-project.org" , "patches@opensource.cirrus.com" , "linux-sound@vger.kernel.org" , "git (AMD-Xilinx)" , "amitrkcian2002@gmail.com" , Conor Dooley , "beanhuo@micron.com" Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor Message-ID: <20240812103812.72763f69@xps-13> In-Reply-To: References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com> <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org> <9cdb7f8b-e64f-46f6-94cb-194a25a42ccd@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Message-ID-Hash: 4VHNHOJDUYEJHWAM75P4BWBQAQEMF4PO X-Message-ID-Hash: 4VHNHOJDUYEJHWAM75P4BWBQAQEMF4PO X-MailFrom: miquel.raynal@bootlin.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, > Hello Everyone, >=20 > I would like to propose another approach for handling stacked and=20 > parallel connection modes and would appreciate your thoughts on it.=20 > But before that, here is some background on what we are trying to achieve. >=20 > The AMD QSPI controller supports two advanced connection modes(Stacked an= d=20 > Dual Parallel) which allow the controller to treat two different flashes= =20 > as one storage. >=20 > Stacked: > Flashes share the same SPI bus, but different CS line, controller asserts= =20 > the CS of the flash to which it needs to communicate. >=20 > Dual Parallel: > Both the flashes have their separate SPI bus CS of both the flashes will= =20 > be asserted/de-asserted at the same time. In this mode data will be split= =20 > across both the flashes by enabling the STRIPE setting in the controller.= =20 > If STRIPE is not enabled, then same data will be sent to both the devices. >=20 > For more information on the modes please feel free to go through the=20 > controller flash interface below > https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Inte= rface >=20 > Mirochip QSPI controller also supports "Dual Parallel 8-bit IO mode", but= =20 > they call it "Twin Quad Mode". > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductD= ocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf >=20 > DT binding changes were added through the following commits: > https://github.com/torvalds/linux/commit/f89504300e94524d5d5846ff8b728592= ac72cec4 > https://github.com/torvalds/linux/commit/eba5368503b4291db7819512600fa014= ea17c5a8 > https://github.com/torvalds/linux/commit/e2edd1b64f1c79e8abda365149ed62a2= a9a494b4 >=20 > SPI core changes were adds through the following commit: > https://github.com/torvalds/linux/commit/4d8ff6b0991d5e86b17b235fc46ec62e= 9195cb9b >=20 > Based on the inputs/suggestions from Tudor, i am planning to add a new=20 > layer between the SPI-NOR and MTD layers to support stacked and parallel= =20 > configurations. This new layer will be part of the spi-nor and located in= =20 > mtd/spi-nor/ For now I don't think you need a totally generic implementation. As long as there is only one controller supporting these modes, I'd say this is not super relevant. > This layer would perform the following tasks: > - During probing, store information from all the connected flashes,=20 > whether in stacked or parallel mode, and present it as a single device= =20 > to the MTD layer. > - Register callbacks through this new layer instead of spi-nor/core.c an= d=20 > handle MTD device registration. > - In stacked mode, select the appropriate spi-nor flash based on the=20 > address provided by the MTD layer during flash operations. > - Manage flash crossover operations in stacked mode. > - Ensure both connected flashes are identical in parallel mode. > - Handle odd byte count requests from the MTD layer during flash=20 > operations in parallel mode. >=20 > For implementing this the current DT binding need to be updated as=20 > follows. So you want to go back to step 1 and redefine bindings? Is that worth? > stacked-memories DT changes: > - Flash size information can be retrieved directly from the flash, so it= =20 > has been removed from the DT binding. > - Each stacked flash will have its own flash node. This approach allows= =20 > flashes of different makes and sizes to be stacked together, as each=20 > flash will be probed individually. And how will you define partitions crossing device boundaries? I believe this constraint has been totally forgotten in this proposal. The whole idea of stacking two devices this way was to simplify the user's life with a single device exposed and the controller handling itself the CS changes. That is precisely what the current binding do. The final goal being to double your storage transparently. If your goal was to put two chips aside, then none of this was actually needed. If you don't care about that anymore, then all the energy put into discussing the bindings initially was useless and a controller property could also have made the trick. > - The stacked-memories DT bindings will contain the phandles of the flas= h=20 > nodes connected in stacked mode. >=20 > spi@0 { > =20 > flash@0 { > compatible =3D "jedec,spi-nor" > reg =3D <0x00>; > stacked-memories =3D <&flash@0 &flash@1>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-0"; > reg =3D <0x0 0xf00000>; > }; > =20 >=20 > } > =20 > flash@1 { > compatible =3D "jedec,spi-nor" > reg =3D <0x01>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-1"; > reg =3D <0x0 0x800000>; > }; > } > } >=20 > parallel-memories DT changes: > - Flash size information can be retrieved directly from the flash, so it= =20 > has been removed from the DT binding. > - Each flash connected in parallel mode will have its own flash node.=20 > This allows us to verify that both flashes connected in parallel are=20 > identical, as each flash node will be probed separately. Well, you don't have to verify that. It's a basic hardware design constraint for using this mode. Otherwise same comment as above, this description doesn't allow correct partitioning and that was one of the main constraints back when we discussed these needs. > - The parallel-memories DT bindings will contain the phandles of the=20 > flash nodes connected in parallel. >=20 > spi@0 { > =20 > flash@0 { > compatible =3D "jedec,spi-nor" > reg =3D <0x00>; > parallel-memories =3D <&flash@0 &flash@1>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-0"; > reg =3D <0x0 0xf00000>; > }; > =20 >=20 > } > =20 > flash@1 { > compatible =3D "jedec,spi-nor" > reg =3D <0x01>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-1"; > reg =3D <0x0 0x800000>; > }; > } > } Thanks, Miqu=C3=A8l 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 949DDC3DA7F for ; Mon, 12 Aug 2024 08:39:07 +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:MIME-Version:References:In-Reply-To: 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=8qj6vfpuK7HvZMsZ4FN8hifp6vOlmD3uyUO+sxEQH90=; b=Q5ykasgWi/46cD UDXHdB+B+sP+4bJG1c/oOCTSjkKVEnOKp+RXUcnZEtdGO2iG1Z/cvb+yvOmS7dv/u0l/5tJMiOAjX 5RpEt5+4fn2RybJuoAytCf3BxjYJlOMnoSuP2NvF8Z+mYrE7UgZ9hu03OcEcfuHWWGOXNnNeHPjPu vwt2Rj5+uekfIPQBIgfaA7TePirMQtiTscQAEZmuP0RnelWhvITp3Bf034iGLYSlnJmhY6bLFSe7W d81im+flDoU+VRsmX1j3+Zj+Glc6k3XNVvEkWGIACMiw909wUpx6OFzxR9dLYhnGnLFUpFNlxaCAu mQuXW7JFmeLgJepsT+0g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdQZw-0000000HITh-17fw; Mon, 12 Aug 2024 08:39:00 +0000 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdQZI-0000000HINb-31Fp; Mon, 12 Aug 2024 08:38:23 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 9CA3DC0007; Mon, 12 Aug 2024 08:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723451896; 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=Wpp+yPNEBFJMfjQq3cL+mUf+1IBUOb95UB4rmwmrlsY=; b=c6AlCNyiO8HVav7lY582H4/RuX+O01sHF3FNBasOHB+VazJm8ydFO5xcwvZJ6d0jkuT1+i Sv6Jmq7TiB6stzxv6fHQQa+YoLJwE6CB0pLKjHXsxJutvIaUi3XWsYO0U/WLuaOQKhRMaj oYCvTZD9GQ24ua+nUP3gCpF3C6okHJvfQouuv+Um04e3FbRgfLwABTZb1Gz3Bv7n8iXw03 x9Asn7ip/Md3h2Z5s2eWCP8HOY68mRsa/1Af21B9Pn6tV6LjyvoVyXtr2k+qyIVZjDyrqX hZ95LcD6Gu/o+tPGUr5jmWRM7yJB3Z7WuAv3A3Gh79rQQk5Q9dDD2WZqwYr7Vg== Date: Mon, 12 Aug 2024 10:38:12 +0200 From: Miquel Raynal To: "Mahapatra, Amit Kumar" Cc: Tudor Ambarus , "broonie@kernel.org" , "pratyush@kernel.org" , "richard@nod.at" , "vigneshr@ti.com" , "sbinding@opensource.cirrus.com" , "lee@kernel.org" , "james.schulman@cirrus.com" , "david.rhodes@cirrus.com" , "rf@opensource.cirrus.com" , "perex@perex.cz" , "tiwai@suse.com" , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "michael@walle.cc" , "linux-mtd@lists.infradead.org" , "nicolas.ferre@microchip.com" , "alexandre.belloni@bootlin.com" , "claudiu.beznea@tuxon.dev" , "Simek, Michal" , "linux-arm-kernel@lists.infradead.org" , "alsa-devel@alsa-project.org" , "patches@opensource.cirrus.com" , "linux-sound@vger.kernel.org" , "git (AMD-Xilinx)" , "amitrkcian2002@gmail.com" , Conor Dooley , "beanhuo@micron.com" Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor Message-ID: <20240812103812.72763f69@xps-13> In-Reply-To: References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com> <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org> <9cdb7f8b-e64f-46f6-94cb-194a25a42ccd@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240812_013821_569366_63AD43B3 X-CRM114-Status: GOOD ( 34.21 ) 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 SGksCgo+IEhlbGxvIEV2ZXJ5b25lLAo+IAo+IEkgd291bGQgbGlrZSB0byBwcm9wb3NlIGFub3Ro ZXIgYXBwcm9hY2ggZm9yIGhhbmRsaW5nIHN0YWNrZWQgYW5kIAo+IHBhcmFsbGVsIGNvbm5lY3Rp b24gbW9kZXMgYW5kIHdvdWxkIGFwcHJlY2lhdGUgeW91ciB0aG91Z2h0cyBvbiBpdC4gCj4gQnV0 IGJlZm9yZSB0aGF0LCBoZXJlIGlzIHNvbWUgYmFja2dyb3VuZCBvbiB3aGF0IHdlIGFyZSB0cnlp bmcgdG8gYWNoaWV2ZS4KPiAKPiBUaGUgQU1EIFFTUEkgY29udHJvbGxlciBzdXBwb3J0cyB0d28g YWR2YW5jZWQgY29ubmVjdGlvbiBtb2RlcyhTdGFja2VkIGFuZCAKPiBEdWFsIFBhcmFsbGVsKSB3 aGljaCBhbGxvdyB0aGUgY29udHJvbGxlciB0byB0cmVhdCB0d28gZGlmZmVyZW50IGZsYXNoZXMg Cj4gYXMgb25lIHN0b3JhZ2UuCj4gCj4gU3RhY2tlZDoKPiBGbGFzaGVzIHNoYXJlIHRoZSBzYW1l IFNQSSBidXMsIGJ1dCBkaWZmZXJlbnQgQ1MgbGluZSwgY29udHJvbGxlciBhc3NlcnRzIAo+IHRo ZSBDUyBvZiB0aGUgZmxhc2ggdG8gd2hpY2ggaXQgbmVlZHMgdG8gY29tbXVuaWNhdGUuCj4gCj4g RHVhbCBQYXJhbGxlbDoKPiBCb3RoIHRoZSBmbGFzaGVzIGhhdmUgdGhlaXIgc2VwYXJhdGUgU1BJ IGJ1cyBDUyBvZiBib3RoIHRoZSBmbGFzaGVzIHdpbGwgCj4gYmUgYXNzZXJ0ZWQvZGUtYXNzZXJ0 ZWQgYXQgdGhlIHNhbWUgdGltZS4gSW4gdGhpcyBtb2RlIGRhdGEgd2lsbCBiZSBzcGxpdCAKPiBh Y3Jvc3MgYm90aCB0aGUgZmxhc2hlcyBieSBlbmFibGluZyB0aGUgU1RSSVBFIHNldHRpbmcgaW4g dGhlIGNvbnRyb2xsZXIuIAo+IElmIFNUUklQRSBpcyBub3QgZW5hYmxlZCwgdGhlbiBzYW1lIGRh dGEgd2lsbCBiZSBzZW50IHRvIGJvdGggdGhlIGRldmljZXMuCj4gCj4gRm9yIG1vcmUgaW5mb3Jt YXRpb24gb24gdGhlIG1vZGVzIHBsZWFzZSBmZWVsIGZyZWUgdG8gZ28gdGhyb3VnaCB0aGUgCj4g Y29udHJvbGxlciBmbGFzaCBpbnRlcmZhY2UgYmVsb3cKPiBodHRwczovL2RvY3MuYW1kLmNvbS9y L2VuLVVTL2FtMDExLXZlcnNhbC1hY2FwLXRybS9RU1BJLUZsYXNoLURldmljZS1JbnRlcmZhY2UK PiAKPiBNaXJvY2hpcCBRU1BJIGNvbnRyb2xsZXIgYWxzbyBzdXBwb3J0cyAiRHVhbCBQYXJhbGxl bCA4LWJpdCBJTyBtb2RlIiwgYnV0IAo+IHRoZXkgY2FsbCBpdCAiVHdpbiBRdWFkIE1vZGUiLgo+ IGh0dHBzOi8vd3cxLm1pY3JvY2hpcC5jb20vZG93bmxvYWRzL2FlbURvY3VtZW50cy9kb2N1bWVu dHMvTVBVMzIvUHJvZHVjdERvY3VtZW50cy9EYXRhU2hlZXRzL1NBTUE3RzUtU2VyaWVzLURhdGEt U2hlZXQtRFM2MDAwMTc2NS5wZGYKPiAKPiBEVCBiaW5kaW5nIGNoYW5nZXMgd2VyZSBhZGRlZCB0 aHJvdWdoIHRoZSBmb2xsb3dpbmcgY29tbWl0czoKPiBodHRwczovL2dpdGh1Yi5jb20vdG9ydmFs ZHMvbGludXgvY29tbWl0L2Y4OTUwNDMwMGU5NDUyNGQ1ZDU4NDZmZjhiNzI4NTkyYWM3MmNlYzQK PiBodHRwczovL2dpdGh1Yi5jb20vdG9ydmFsZHMvbGludXgvY29tbWl0L2ViYTUzNjg1MDNiNDI5 MWRiNzgxOTUxMjYwMGZhMDE0ZWExN2M1YTgKPiBodHRwczovL2dpdGh1Yi5jb20vdG9ydmFsZHMv bGludXgvY29tbWl0L2UyZWRkMWI2NGYxYzc5ZThhYmRhMzY1MTQ5ZWQ2MmEyYTlhNDk0YjQKPiAK PiBTUEkgY29yZSBjaGFuZ2VzIHdlcmUgYWRkcyB0aHJvdWdoIHRoZSBmb2xsb3dpbmcgY29tbWl0 Ogo+IGh0dHBzOi8vZ2l0aHViLmNvbS90b3J2YWxkcy9saW51eC9jb21taXQvNGQ4ZmY2YjA5OTFk NWU4NmIxN2IyMzVmYzQ2ZWM2MmU5MTk1Y2I5Ygo+IAo+IEJhc2VkIG9uIHRoZSBpbnB1dHMvc3Vn Z2VzdGlvbnMgZnJvbSBUdWRvciwgaSBhbSBwbGFubmluZyB0byBhZGQgYSBuZXcgCj4gbGF5ZXIg YmV0d2VlbiB0aGUgU1BJLU5PUiBhbmQgTVREIGxheWVycyB0byBzdXBwb3J0IHN0YWNrZWQgYW5k IHBhcmFsbGVsIAo+IGNvbmZpZ3VyYXRpb25zLiBUaGlzIG5ldyBsYXllciB3aWxsIGJlIHBhcnQg b2YgdGhlIHNwaS1ub3IgYW5kIGxvY2F0ZWQgaW4gCj4gbXRkL3NwaS1ub3IvCgpGb3Igbm93IEkg ZG9uJ3QgdGhpbmsgeW91IG5lZWQgYSB0b3RhbGx5IGdlbmVyaWMgaW1wbGVtZW50YXRpb24uIEFz CmxvbmcgYXMgdGhlcmUgaXMgb25seSBvbmUgY29udHJvbGxlciBzdXBwb3J0aW5nIHRoZXNlIG1v ZGVzLCBJJ2Qgc2F5CnRoaXMgaXMgbm90IHN1cGVyIHJlbGV2YW50LgoKPiBUaGlzIGxheWVyIHdv dWxkIHBlcmZvcm0gdGhlIGZvbGxvd2luZyB0YXNrczoKPiAgLSBEdXJpbmcgcHJvYmluZywgc3Rv cmUgaW5mb3JtYXRpb24gZnJvbSBhbGwgdGhlIGNvbm5lY3RlZCBmbGFzaGVzLCAKPiAgICB3aGV0 aGVyIGluIHN0YWNrZWQgb3IgcGFyYWxsZWwgbW9kZSwgYW5kIHByZXNlbnQgaXQgYXMgYSBzaW5n bGUgZGV2aWNlIAo+ICAgIHRvIHRoZSBNVEQgbGF5ZXIuCj4gIC0gUmVnaXN0ZXIgY2FsbGJhY2tz IHRocm91Z2ggdGhpcyBuZXcgbGF5ZXIgaW5zdGVhZCBvZiBzcGktbm9yL2NvcmUuYyBhbmQgCj4g ICAgaGFuZGxlIE1URCBkZXZpY2UgcmVnaXN0cmF0aW9uLgo+ICAtIEluIHN0YWNrZWQgbW9kZSwg c2VsZWN0IHRoZSBhcHByb3ByaWF0ZSBzcGktbm9yIGZsYXNoIGJhc2VkIG9uIHRoZSAKPiAgICBh ZGRyZXNzIHByb3ZpZGVkIGJ5IHRoZSBNVEQgbGF5ZXIgZHVyaW5nIGZsYXNoIG9wZXJhdGlvbnMu Cj4gIC0gTWFuYWdlIGZsYXNoIGNyb3Nzb3ZlciBvcGVyYXRpb25zIGluIHN0YWNrZWQgbW9kZS4K PiAgLSBFbnN1cmUgYm90aCBjb25uZWN0ZWQgZmxhc2hlcyBhcmUgaWRlbnRpY2FsIGluIHBhcmFs bGVsIG1vZGUuCj4gIC0gSGFuZGxlIG9kZCBieXRlIGNvdW50IHJlcXVlc3RzIGZyb20gdGhlIE1U RCBsYXllciBkdXJpbmcgZmxhc2ggCj4gICAgb3BlcmF0aW9ucyBpbiBwYXJhbGxlbCBtb2RlLgo+ IAo+IEZvciBpbXBsZW1lbnRpbmcgdGhpcyB0aGUgY3VycmVudCBEVCBiaW5kaW5nIG5lZWQgdG8g YmUgdXBkYXRlZCBhcyAKPiBmb2xsb3dzLgoKU28geW91IHdhbnQgdG8gZ28gYmFjayB0byBzdGVw IDEgYW5kIHJlZGVmaW5lIGJpbmRpbmdzPyBJcyB0aGF0IHdvcnRoPwoKPiBzdGFja2VkLW1lbW9y aWVzIERUIGNoYW5nZXM6Cj4gIC0gRmxhc2ggc2l6ZSBpbmZvcm1hdGlvbiBjYW4gYmUgcmV0cmll dmVkIGRpcmVjdGx5IGZyb20gdGhlIGZsYXNoLCBzbyBpdCAKPiAgICBoYXMgYmVlbiByZW1vdmVk IGZyb20gdGhlIERUIGJpbmRpbmcuCj4gIC0gRWFjaCBzdGFja2VkIGZsYXNoIHdpbGwgaGF2ZSBp dHMgb3duIGZsYXNoIG5vZGUuIFRoaXMgYXBwcm9hY2ggYWxsb3dzIAo+ICAgIGZsYXNoZXMgb2Yg ZGlmZmVyZW50IG1ha2VzIGFuZCBzaXplcyB0byBiZSBzdGFja2VkIHRvZ2V0aGVyLCBhcyBlYWNo IAo+ICAgIGZsYXNoIHdpbGwgYmUgcHJvYmVkIGluZGl2aWR1YWxseS4KCkFuZCBob3cgd2lsbCB5 b3UgZGVmaW5lIHBhcnRpdGlvbnMgY3Jvc3NpbmcgZGV2aWNlIGJvdW5kYXJpZXM/IEkKYmVsaWV2 ZSB0aGlzIGNvbnN0cmFpbnQgaGFzIGJlZW4gdG90YWxseSBmb3Jnb3R0ZW4gaW4gdGhpcyBwcm9w b3NhbC4KVGhlIHdob2xlIGlkZWEgb2Ygc3RhY2tpbmcgdHdvIGRldmljZXMgdGhpcyB3YXkgd2Fz IHRvIHNpbXBsaWZ5IHRoZQp1c2VyJ3MgbGlmZSB3aXRoIGEgc2luZ2xlIGRldmljZSBleHBvc2Vk IGFuZCB0aGUgY29udHJvbGxlciBoYW5kbGluZwppdHNlbGYgdGhlIENTIGNoYW5nZXMuIFRoYXQg aXMgcHJlY2lzZWx5IHdoYXQgdGhlIGN1cnJlbnQgYmluZGluZyBkby4KVGhlIGZpbmFsIGdvYWwg YmVpbmcgdG8gZG91YmxlIHlvdXIgc3RvcmFnZSB0cmFuc3BhcmVudGx5LiBJZiB5b3VyIGdvYWwK d2FzIHRvIHB1dCB0d28gY2hpcHMgYXNpZGUsIHRoZW4gbm9uZSBvZiB0aGlzIHdhcyBhY3R1YWxs eSBuZWVkZWQuIElmCnlvdSBkb24ndCBjYXJlIGFib3V0IHRoYXQgYW55bW9yZSwgdGhlbiBhbGwg dGhlIGVuZXJneSBwdXQgaW50bwpkaXNjdXNzaW5nIHRoZSBiaW5kaW5ncyBpbml0aWFsbHkgd2Fz IHVzZWxlc3MgYW5kIGEgY29udHJvbGxlciBwcm9wZXJ0eQpjb3VsZCBhbHNvIGhhdmUgbWFkZSB0 aGUgdHJpY2suCgo+ICAtIFRoZSBzdGFja2VkLW1lbW9yaWVzIERUIGJpbmRpbmdzIHdpbGwgY29u dGFpbiB0aGUgcGhhbmRsZXMgb2YgdGhlIGZsYXNoIAo+ICAgIG5vZGVzIGNvbm5lY3RlZCBpbiBz dGFja2VkIG1vZGUuCj4gCj4gc3BpQDAgewo+ICAgCj4gICBmbGFzaEAwIHsKPiAgICAgY29tcGF0 aWJsZSA9ICJqZWRlYyxzcGktbm9yIgo+ICAgICByZWcgPSA8MHgwMD47Cj4gICAgIHN0YWNrZWQt bWVtb3JpZXMgPSA8JmZsYXNoQDAgJmZsYXNoQDE+Owo+ICAgICBzcGktbWF4LWZyZXF1ZW5jeSA9 IDw1MDAwMDAwMD47Cj4gICAgIC4uLgo+ICAgICAgICAgICAgICAgcGFydGl0aW9uQDAgeyAKPiAg ICAgICAgIGxhYmVsID0gInFzcGktMCI7Cj4gICAgICAgICByZWcgPSA8MHgwIDB4ZjAwMDAwPjsK PiAgICAgfTsKPiAgICAgICAgICAgICAgICAgICAgICAgICAKPiAKPiAgIH0KPiAgIAo+ICAgZmxh c2hAMSB7Cj4gICAgIGNvbXBhdGlibGUgPSAiamVkZWMsc3BpLW5vciIKPiAgICAgICAgICAgICAg IHJlZyA9IDwweDAxPjsKPiAgICAgc3BpLW1heC1mcmVxdWVuY3kgPSA8NTAwMDAwMDA+Owo+ICAg ICAuLi4KPiAgICAgICAgICAgICAgIHBhcnRpdGlvbkAwIHsgCj4gICAgICAgICBsYWJlbCA9ICJx c3BpLTEiOwo+ICAgICAgICAgcmVnID0gPDB4MCAweDgwMDAwMD47Cj4gICAgIH07Cj4gICB9Cj4g fQo+IAo+IHBhcmFsbGVsLW1lbW9yaWVzIERUIGNoYW5nZXM6Cj4gIC0gRmxhc2ggc2l6ZSBpbmZv cm1hdGlvbiBjYW4gYmUgcmV0cmlldmVkIGRpcmVjdGx5IGZyb20gdGhlIGZsYXNoLCBzbyBpdCAK PiAgICBoYXMgYmVlbiByZW1vdmVkIGZyb20gdGhlIERUIGJpbmRpbmcuCj4gIC0gRWFjaCBmbGFz aCBjb25uZWN0ZWQgaW4gcGFyYWxsZWwgbW9kZSB3aWxsIGhhdmUgaXRzIG93biBmbGFzaCBub2Rl LiAKPiAgICBUaGlzIGFsbG93cyB1cyB0byB2ZXJpZnkgdGhhdCBib3RoIGZsYXNoZXMgY29ubmVj dGVkIGluIHBhcmFsbGVsIGFyZSAKPiAgICBpZGVudGljYWwsIGFzIGVhY2ggZmxhc2ggbm9kZSB3 aWxsIGJlIHByb2JlZCBzZXBhcmF0ZWx5LgoKV2VsbCwgeW91IGRvbid0IGhhdmUgdG8gdmVyaWZ5 IHRoYXQuIEl0J3MgYSBiYXNpYyBoYXJkd2FyZSBkZXNpZ24KY29uc3RyYWludCBmb3IgdXNpbmcg dGhpcyBtb2RlLgoKT3RoZXJ3aXNlIHNhbWUgY29tbWVudCBhcyBhYm92ZSwgdGhpcyBkZXNjcmlw dGlvbiBkb2Vzbid0IGFsbG93CmNvcnJlY3QgcGFydGl0aW9uaW5nIGFuZCB0aGF0IHdhcyBvbmUg b2YgdGhlIG1haW4gY29uc3RyYWludHMgYmFjayB3aGVuCndlIGRpc2N1c3NlZCB0aGVzZSBuZWVk cy4KCj4gIC0gVGhlIHBhcmFsbGVsLW1lbW9yaWVzIERUIGJpbmRpbmdzIHdpbGwgY29udGFpbiB0 aGUgcGhhbmRsZXMgb2YgdGhlIAo+ICAgIGZsYXNoIG5vZGVzIGNvbm5lY3RlZCBpbiBwYXJhbGxl bC4KPiAKPiBzcGlAMCB7Cj4gICAKPiAgIGZsYXNoQDAgewo+ICAgICBjb21wYXRpYmxlID0gImpl ZGVjLHNwaS1ub3IiCj4gICAgIHJlZyA9IDwweDAwPjsKPiAgICAgcGFyYWxsZWwtbWVtb3JpZXMg PSA8JmZsYXNoQDAgJmZsYXNoQDE+Owo+ICAgICBzcGktbWF4LWZyZXF1ZW5jeSA9IDw1MDAwMDAw MD47Cj4gICAgIC4uLgo+ICAgICAgICAgICAgICAgcGFydGl0aW9uQDAgeyAKPiAgICAgICAgIGxh YmVsID0gInFzcGktMCI7Cj4gICAgICAgICByZWcgPSA8MHgwIDB4ZjAwMDAwPjsKPiAgICAgfTsK PiAgICAgICAgICAgICAgICAgICAgICAgICAKPiAKPiAgIH0KPiAgIAo+ICAgZmxhc2hAMSB7Cj4g ICAgIGNvbXBhdGlibGUgPSAiamVkZWMsc3BpLW5vciIKPiAgICAgICAgICAgICAgIHJlZyA9IDww eDAxPjsKPiAgICAgc3BpLW1heC1mcmVxdWVuY3kgPSA8NTAwMDAwMDA+Owo+ICAgICAuLi4KPiAg ICAgICAgICAgICAgIHBhcnRpdGlvbkAwIHsgCj4gICAgICAgICBsYWJlbCA9ICJxc3BpLTEiOwo+ ICAgICAgICAgcmVnID0gPDB4MCAweDgwMDAwMD47Cj4gICAgIH07Cj4gICB9Cj4gfQoKVGhhbmtz LApNaXF1w6hsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5p bmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo= 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 B10B4C52D7C for ; Mon, 12 Aug 2024 08:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To: Message-ID:Subject: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=Wpp+yPNEBFJMfjQq3cL+mUf+1IBUOb95UB4rmwmrlsY=; b=AABm1hxExrhFp0 oo97zJVnmrQrpsebADTdgshhTxepZrEfrMU4etHiP3yPuQY5Q6tu7p9VHF7DFJs/eq37/k47n4FN7 eMO+XuleNJWnrftp/mzB7D05a3+Ac56XOUSP/0nPOutELxy/xGaO/INn/scUQlMwgeMXhRk5mMStO R4+UNzhmMiCNElSw90Qs5dfN5nfEza8lDqT9G0lT/bZ3QETlt3wxvYxT6udYjt5+Rfz/p91kwQqQN fy9ZZVat7qv+ki9UcnceT27phtz0wkjQ3CtCxnC3Q28C8naBQRYmw+LuY2ghCYMT35VxmfOqvfIxi m+17rUDMJBtbmpqFZCzg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdQZv-0000000HITb-2MjX; Mon, 12 Aug 2024 08:38:59 +0000 Received: from relay6-d.mail.gandi.net ([2001:4b98:dc4:8::226]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdQZI-0000000HINb-31Fp; Mon, 12 Aug 2024 08:38:23 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 9CA3DC0007; Mon, 12 Aug 2024 08:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723451896; 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=Wpp+yPNEBFJMfjQq3cL+mUf+1IBUOb95UB4rmwmrlsY=; b=c6AlCNyiO8HVav7lY582H4/RuX+O01sHF3FNBasOHB+VazJm8ydFO5xcwvZJ6d0jkuT1+i Sv6Jmq7TiB6stzxv6fHQQa+YoLJwE6CB0pLKjHXsxJutvIaUi3XWsYO0U/WLuaOQKhRMaj oYCvTZD9GQ24ua+nUP3gCpF3C6okHJvfQouuv+Um04e3FbRgfLwABTZb1Gz3Bv7n8iXw03 x9Asn7ip/Md3h2Z5s2eWCP8HOY68mRsa/1Af21B9Pn6tV6LjyvoVyXtr2k+qyIVZjDyrqX hZ95LcD6Gu/o+tPGUr5jmWRM7yJB3Z7WuAv3A3Gh79rQQk5Q9dDD2WZqwYr7Vg== Date: Mon, 12 Aug 2024 10:38:12 +0200 From: Miquel Raynal To: "Mahapatra, Amit Kumar" Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor Message-ID: <20240812103812.72763f69@xps-13> In-Reply-To: References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com> <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org> <9cdb7f8b-e64f-46f6-94cb-194a25a42ccd@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240812_013821_569366_63AD43B3 X-CRM114-Status: GOOD ( 34.21 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "alexandre.belloni@bootlin.com" , "vigneshr@ti.com" , "alsa-devel@alsa-project.org" , "claudiu.beznea@tuxon.dev" , Conor Dooley , "linux-mtd@lists.infradead.org" , "beanhuo@micron.com" , "git \(AMD-Xilinx\)" , "sbinding@opensource.cirrus.com" , "richard@nod.at" , "lee@kernel.org" , Tudor Ambarus , "amitrkcian2002@gmail.com" , "linux-sound@vger.kernel.org" , "james.schulman@cirrus.com" , "rf@opensource.cirrus.com" , "broonie@kernel.org" , "tiwai@suse.com" , "perex@perex.cz" , "Simek, Michal" , "linux-arm-kernel@lists.infradead.org" , "patches@opensource.cirrus.com" , "linux-kernel@vger.kernel.org" , "linux-spi@vger.kernel.org" , "michael@walle.cc" , "david.rhodes@cirrus.com" , "pratyush@kernel.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, > Hello Everyone, >=20 > I would like to propose another approach for handling stacked and=20 > parallel connection modes and would appreciate your thoughts on it.=20 > But before that, here is some background on what we are trying to achieve. >=20 > The AMD QSPI controller supports two advanced connection modes(Stacked an= d=20 > Dual Parallel) which allow the controller to treat two different flashes= =20 > as one storage. >=20 > Stacked: > Flashes share the same SPI bus, but different CS line, controller asserts= =20 > the CS of the flash to which it needs to communicate. >=20 > Dual Parallel: > Both the flashes have their separate SPI bus CS of both the flashes will= =20 > be asserted/de-asserted at the same time. In this mode data will be split= =20 > across both the flashes by enabling the STRIPE setting in the controller.= =20 > If STRIPE is not enabled, then same data will be sent to both the devices. >=20 > For more information on the modes please feel free to go through the=20 > controller flash interface below > https://docs.amd.com/r/en-US/am011-versal-acap-trm/QSPI-Flash-Device-Inte= rface >=20 > Mirochip QSPI controller also supports "Dual Parallel 8-bit IO mode", but= =20 > they call it "Twin Quad Mode". > https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ProductD= ocuments/DataSheets/SAMA7G5-Series-Data-Sheet-DS60001765.pdf >=20 > DT binding changes were added through the following commits: > https://github.com/torvalds/linux/commit/f89504300e94524d5d5846ff8b728592= ac72cec4 > https://github.com/torvalds/linux/commit/eba5368503b4291db7819512600fa014= ea17c5a8 > https://github.com/torvalds/linux/commit/e2edd1b64f1c79e8abda365149ed62a2= a9a494b4 >=20 > SPI core changes were adds through the following commit: > https://github.com/torvalds/linux/commit/4d8ff6b0991d5e86b17b235fc46ec62e= 9195cb9b >=20 > Based on the inputs/suggestions from Tudor, i am planning to add a new=20 > layer between the SPI-NOR and MTD layers to support stacked and parallel= =20 > configurations. This new layer will be part of the spi-nor and located in= =20 > mtd/spi-nor/ For now I don't think you need a totally generic implementation. As long as there is only one controller supporting these modes, I'd say this is not super relevant. > This layer would perform the following tasks: > - During probing, store information from all the connected flashes,=20 > whether in stacked or parallel mode, and present it as a single device= =20 > to the MTD layer. > - Register callbacks through this new layer instead of spi-nor/core.c an= d=20 > handle MTD device registration. > - In stacked mode, select the appropriate spi-nor flash based on the=20 > address provided by the MTD layer during flash operations. > - Manage flash crossover operations in stacked mode. > - Ensure both connected flashes are identical in parallel mode. > - Handle odd byte count requests from the MTD layer during flash=20 > operations in parallel mode. >=20 > For implementing this the current DT binding need to be updated as=20 > follows. So you want to go back to step 1 and redefine bindings? Is that worth? > stacked-memories DT changes: > - Flash size information can be retrieved directly from the flash, so it= =20 > has been removed from the DT binding. > - Each stacked flash will have its own flash node. This approach allows= =20 > flashes of different makes and sizes to be stacked together, as each=20 > flash will be probed individually. And how will you define partitions crossing device boundaries? I believe this constraint has been totally forgotten in this proposal. The whole idea of stacking two devices this way was to simplify the user's life with a single device exposed and the controller handling itself the CS changes. That is precisely what the current binding do. The final goal being to double your storage transparently. If your goal was to put two chips aside, then none of this was actually needed. If you don't care about that anymore, then all the energy put into discussing the bindings initially was useless and a controller property could also have made the trick. > - The stacked-memories DT bindings will contain the phandles of the flas= h=20 > nodes connected in stacked mode. >=20 > spi@0 { > =20 > flash@0 { > compatible =3D "jedec,spi-nor" > reg =3D <0x00>; > stacked-memories =3D <&flash@0 &flash@1>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-0"; > reg =3D <0x0 0xf00000>; > }; > =20 >=20 > } > =20 > flash@1 { > compatible =3D "jedec,spi-nor" > reg =3D <0x01>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-1"; > reg =3D <0x0 0x800000>; > }; > } > } >=20 > parallel-memories DT changes: > - Flash size information can be retrieved directly from the flash, so it= =20 > has been removed from the DT binding. > - Each flash connected in parallel mode will have its own flash node.=20 > This allows us to verify that both flashes connected in parallel are=20 > identical, as each flash node will be probed separately. Well, you don't have to verify that. It's a basic hardware design constraint for using this mode. Otherwise same comment as above, this description doesn't allow correct partitioning and that was one of the main constraints back when we discussed these needs. > - The parallel-memories DT bindings will contain the phandles of the=20 > flash nodes connected in parallel. >=20 > spi@0 { > =20 > flash@0 { > compatible =3D "jedec,spi-nor" > reg =3D <0x00>; > parallel-memories =3D <&flash@0 &flash@1>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-0"; > reg =3D <0x0 0xf00000>; > }; > =20 >=20 > } > =20 > flash@1 { > compatible =3D "jedec,spi-nor" > reg =3D <0x01>; > spi-max-frequency =3D <50000000>; > ... > partition@0 {=20 > label =3D "qspi-1"; > reg =3D <0x0 0x800000>; > }; > } > } Thanks, Miqu=C3=A8l