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 A271ED10DCE for ; Mon, 2 Dec 2024 08:41:50 +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 E678B190B; Mon, 2 Dec 2024 09:41:37 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz E678B190B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1733128907; bh=qwXFiHd5CN6f/s7X+eMBlkD3TFas1Jz69gDTSeCkw0M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=e093oGOmHB3BRRJSXYiXdWjji0rtr6RCGWJR5wNg1q/qCvb1/ZeFLV/hIoN5nwbOH GWay4XYz+XzmRx1byvELd83gXAFmRq+SeoyrNpgbSYK7Qx/bUCZcvz3ApY8KQkx5/B LOil7D4y5MiyVMh5xNHt0Vl3sJPdRC39Ej3cvU2I= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 8FC60F805B6; Mon, 2 Dec 2024 09:41:15 +0100 (CET) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id D3F99F805C1; Mon, 2 Dec 2024 09:41:15 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id CE385F80496; Mon, 25 Nov 2024 16:40:24 +0100 (CET) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C1389F80134 for ; Mon, 25 Nov 2024 16:40:22 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C1389F80134 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=UOlx82X4 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5853F5C5B42; Mon, 25 Nov 2024 15:39:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF9CC4CECE; Mon, 25 Nov 2024 15:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732549219; bh=IsIi8uedJB2d9ynke7rCIfulXuPxooj9TCcL71ClcMc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UOlx82X4RX72arozgLh4e2tPa5MBNgO9Qi33L80gyMCT5HjS3dpmJp3XcrgrLgn3z sLdYwVrnPcuZZK6sYdsz07Uby1Ub0Yq1ymSivQwLuoP+hnYgxZ8ZvLHm2puHpEKFzo Zd4eIt9Z9J4zPlr8vaS8GS+lEpuk3+AxWZSuZJYvVvWw69g8pNKdcnSlqXP0EoarjU DFNpMRE4VMztfKHAdv8F+FMlCsVbwyZF6PpHE2WqVgpqLNqQNCi2NDx69cpoSp4+vl y1l9ocGmPLRxnohePvYVpIx7zPpWzDskSICF3wCmjm0G7d6xyhzlczV4vCrkEMyVYv XCoI3aMIq981w== From: Pratyush Yadav To: Amit Kumar Mahapatra Cc: , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH 0/2] Add support for stacked and parallel memories In-Reply-To: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> (Amit Kumar Mahapatra's message of "Sat, 26 Oct 2024 13:23:45 +0530") References: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> Date: Mon, 25 Nov 2024 15:40:15 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MailFrom: pratyush@kernel.org X-Mailman-Rule-Hits: nonmember-moderation 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 Message-ID-Hash: WGE3NVSAPI5VZFQLFAMQGN2QD5M463PH X-Message-ID-Hash: WGE3NVSAPI5VZFQLFAMQGN2QD5M463PH X-Mailman-Approved-At: Mon, 02 Dec 2024 08:41:11 +0000 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: On Sat, Oct 26 2024, Amit Kumar Mahapatra wrote: Hi Amit, I've been meaning to look into this proposal for some time now, but one thing or another kept coming up and I never got around to it. Well, I'll try to get some of my thoughts out with this reply. I still haven't looked very deeply into the past discussions, so apologies if I bring up something that was already discussed. > Hello Everyone, > > Following an email discussion with Miquel regarding the binding changes > and overall architecture for implementing support for stacked and parallel > memories, I=E2=80=99m sharing this RFC to initiate a discussion on the pr= oposed > updates to current bindings and to finalize the implementation > architecture. > > Before diving into the main topic, here is some background on stacked and > parallel memories. > > The AMD QSPI controller supports two advanced connection modes(Stacked and > Parallel) which allow the controller to treat two different flashes as one > storage. > > Stacked: > Flashes share the same SPI bus, but different CS line, controller driver > asserts the CS of the flash to which it needs to communicate. Stacked mode > is a software abstraction rather than a controller feature or capability. > At any given time, the controller communicates with one of the two > connected flash devices, as determined by the requested address and data > length. If an operation starts on one flash and ends on the other, the > core needs to split it into two separate operations and adjust the data > length accordingly. > > Parallel(Multi-CS): > Both the flashes have their separate SPI bus, CS of both the flashes will > be asserted/de-asserted at the same time. In this mode data will be split > across both the flashes by enabling the STRIPE setting in the controller. > Parallel mode is a controller feature where if the STRIPE bit is set then > the controller internally handles the data split during data write to the > flashes and while reading data from the flash the controller internally > merges data from both the flashes before writing to the controller FIFO. > If STRIPE is not enabled, then same data will be sent to both the devices. > In parallel mode both the flashes should be identical. > > For more information on the modes please feel free to go through the > controller flash interface below [1]. > > Mirochip QSPI controller[2] also supports "Dual Parallel 8-bit IO mode", > but they call it "Twin Quad Mode". > > Initially in [3] [4] [5] Miquel had tried to extend MTD-CONCAT driver to > support Stacked mode, but the bindings were not accepted. So, the > MTD-CONCAT approach was dropped and the DT bindings that got accepted > [6] [7] [8] that describes the two flash devices as being one. SPI core > changes to support the above bindings were added [9]. While adding the > support in SPI-NOR Tudor provided additional feedback, leading to a > discussion on updating the current stacked and parallel DT bindings. > > Proposed Solution: > The solution has two parts: > > 1. Update MTD-CONCAT > Update MTD-CONCAT to create virtual concatinated mtd devices as defined > in the device tree. >>From a very quick look, it seems mtdconcat should already do most of what you want with "stacked mode". The tricky bits might be devicetree design, but from the software perspective, I think mtdconcat makes perfect sense. You leave all the complexity to the SPI NOR layer since it already handles them, and just use the higher-level MTD layer to virtually concatenate devices. Adding a new layer between MTD and SPI NOR makes little sense because mtdconcat is already that layer. Another benefit of this would be you can just as easily concatenate any kinds of flashes you want; they don't have to be the same. I think this is a much simpler problem to solve compared to parallel mode. Once you figure out the devicetree stuff, and I think the mtdconcat changes should be simple and not too controversial. So I think you should split the parallel and stacked support into two independent series. This way you make progress without having to wait for discussions around parallel mode support to settle. > > 2. Add a New Layer > Add a new layer between the SPI-NOR and MTD layers to support stacked > and parallel configurations. This new layer will be part of spi-nor, > located in mtd/spi-nor/, can be included/excluded via Kconfig, will be > maintained by AMD and will: > > - During probing, store information from all connected flashes in > stacked or parallel mode and present them as a single device to the > MTD layer. As I mentioned above, I do not think you should do stacked flashes this way. > - Register callbacks and manage MTD device registration within the new > layer instead of spi-nor/core.c. > - Make minimal changes in spi-nor/core.c, as stacked and parallel > handling will be managed by the new layer on top of SPI-NOR. > - Handle odd byte count requests from the MTD layer during flash > operations in parallel mode. You'd also probably have to add support in SPI MEM to signal the controller to use parallel mode. You don't want to use parallel mode all the time since you'd need to do "normal" operations as well such as reading/writing status registers, reading flash ID, SFDP, etc. That is yet another "cost" parallel mode support has -- it adds another thing to SPI MEM (I'm not saying the cost isn't necessarily worth it -- just pointing it out). >>From the SPI NOR side, this layer would have to make sure both flashes get configured with the exact same settings. That would need SPI NOR to export how it configured a flash, ideally in a stable, well-defined format. It would also have to ask SPI NOR to construct the SPI MEM ops for it, and then edit them to set the "parallel mode" bit. Perhaps the dirmap op templates can come in handy here. It's hard to say much more without seeing the code. It would be interesting to see how you can manage to get this layer work without too much intrusion in the core. [...] --=20 Regards, Pratyush Yadav 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 233F4D58D5E for ; Mon, 25 Nov 2024 15:41:52 +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:Message-ID:Date: References:In-Reply-To:Subject:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=8ORT1phHJlmBlfdknfO2iUEHyltF+zLDEZbasqUxrG4=; b=PlvHxEF+q0MH0IRLyXYqGRHxVx i+kI3F865tJaz2iO2vV/k9nhBqzxGqnvc2VBTjHruJSOucC05h7jSXt+vFWIGeTeklA2KaGT8lkrA SJbT+Y4wXLAfh8lgBNtBpyw87AozpWh9y6rAFPc5kza2WEDxw/RXHol9eOa3cH4sdqSlaY0+zUHLW vcylQIp6g+eyrDX3wKmdcwLUUGIc9QczYt1dUpjppz+4Bx5rHkZ/BlUb1504vwnZOMU2gidS6kcve WsWDE5OuCbD1BfvrGunOBScVuLhbSzb+fS4z9YKNTOSBbnhImBzGHDphaCD16OkDX0Lu6a74V3Xja A8RAsLkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tFbDW-00000008XJ3-0dDb; Mon, 25 Nov 2024 15:41:38 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tFbCG-00000008X5p-32rR; Mon, 25 Nov 2024 15:40:21 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5853F5C5B42; Mon, 25 Nov 2024 15:39:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF9CC4CECE; Mon, 25 Nov 2024 15:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732549219; bh=IsIi8uedJB2d9ynke7rCIfulXuPxooj9TCcL71ClcMc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UOlx82X4RX72arozgLh4e2tPa5MBNgO9Qi33L80gyMCT5HjS3dpmJp3XcrgrLgn3z sLdYwVrnPcuZZK6sYdsz07Uby1Ub0Yq1ymSivQwLuoP+hnYgxZ8ZvLHm2puHpEKFzo Zd4eIt9Z9J4zPlr8vaS8GS+lEpuk3+AxWZSuZJYvVvWw69g8pNKdcnSlqXP0EoarjU DFNpMRE4VMztfKHAdv8F+FMlCsVbwyZF6PpHE2WqVgpqLNqQNCi2NDx69cpoSp4+vl y1l9ocGmPLRxnohePvYVpIx7zPpWzDskSICF3wCmjm0G7d6xyhzlczV4vCrkEMyVYv XCoI3aMIq981w== From: Pratyush Yadav To: Amit Kumar Mahapatra Subject: Re: [RFC PATCH 0/2] Add support for stacked and parallel memories In-Reply-To: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> (Amit Kumar Mahapatra's message of "Sat, 26 Oct 2024 13:23:45 +0530") References: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> Date: Mon, 25 Nov 2024 15:40:15 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241125_074020_866034_88CCDD56 X-CRM114-Status: GOOD ( 42.19 ) 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, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, miquel.raynal@bootlin.com, beanhuo@micron.com, git@amd.com, robh@kernel.org, richard@nod.at, amitrkcian2002@gmail.com, tudor.ambarus@linaro.org, conor+dt@kernel.org, broonie@kernel.org, venkatesh.abbarapu@amd.com, michal.simek@amd.com, linux-arm-kernel@lists.infradead.org, patches@opensource.cirrus.com, claudiu.beznea@tuxon.dev, linux-spi@vger.kernel.org, michael@walle.cc, krzk+dt@kernel.org, pratyush@kernel.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, Oct 26 2024, Amit Kumar Mahapatra wrote: Hi Amit, I've been meaning to look into this proposal for some time now, but one thing or another kept coming up and I never got around to it. Well, I'll try to get some of my thoughts out with this reply. I still haven't looked very deeply into the past discussions, so apologies if I bring up something that was already discussed. > Hello Everyone, > > Following an email discussion with Miquel regarding the binding changes > and overall architecture for implementing support for stacked and parallel > memories, I=E2=80=99m sharing this RFC to initiate a discussion on the pr= oposed > updates to current bindings and to finalize the implementation > architecture. > > Before diving into the main topic, here is some background on stacked and > parallel memories. > > The AMD QSPI controller supports two advanced connection modes(Stacked and > Parallel) which allow the controller to treat two different flashes as one > storage. > > Stacked: > Flashes share the same SPI bus, but different CS line, controller driver > asserts the CS of the flash to which it needs to communicate. Stacked mode > is a software abstraction rather than a controller feature or capability. > At any given time, the controller communicates with one of the two > connected flash devices, as determined by the requested address and data > length. If an operation starts on one flash and ends on the other, the > core needs to split it into two separate operations and adjust the data > length accordingly. > > Parallel(Multi-CS): > Both the flashes have their separate SPI bus, CS of both the flashes will > be asserted/de-asserted at the same time. In this mode data will be split > across both the flashes by enabling the STRIPE setting in the controller. > Parallel mode is a controller feature where if the STRIPE bit is set then > the controller internally handles the data split during data write to the > flashes and while reading data from the flash the controller internally > merges data from both the flashes before writing to the controller FIFO. > If STRIPE is not enabled, then same data will be sent to both the devices. > In parallel mode both the flashes should be identical. > > For more information on the modes please feel free to go through the > controller flash interface below [1]. > > Mirochip QSPI controller[2] also supports "Dual Parallel 8-bit IO mode", > but they call it "Twin Quad Mode". > > Initially in [3] [4] [5] Miquel had tried to extend MTD-CONCAT driver to > support Stacked mode, but the bindings were not accepted. So, the > MTD-CONCAT approach was dropped and the DT bindings that got accepted > [6] [7] [8] that describes the two flash devices as being one. SPI core > changes to support the above bindings were added [9]. While adding the > support in SPI-NOR Tudor provided additional feedback, leading to a > discussion on updating the current stacked and parallel DT bindings. > > Proposed Solution: > The solution has two parts: > > 1. Update MTD-CONCAT > Update MTD-CONCAT to create virtual concatinated mtd devices as defined > in the device tree. >From a very quick look, it seems mtdconcat should already do most of what you want with "stacked mode". The tricky bits might be devicetree design, but from the software perspective, I think mtdconcat makes perfect sense. You leave all the complexity to the SPI NOR layer since it already handles them, and just use the higher-level MTD layer to virtually concatenate devices. Adding a new layer between MTD and SPI NOR makes little sense because mtdconcat is already that layer. Another benefit of this would be you can just as easily concatenate any kinds of flashes you want; they don't have to be the same. I think this is a much simpler problem to solve compared to parallel mode. Once you figure out the devicetree stuff, and I think the mtdconcat changes should be simple and not too controversial. So I think you should split the parallel and stacked support into two independent series. This way you make progress without having to wait for discussions around parallel mode support to settle. > > 2. Add a New Layer > Add a new layer between the SPI-NOR and MTD layers to support stacked > and parallel configurations. This new layer will be part of spi-nor, > located in mtd/spi-nor/, can be included/excluded via Kconfig, will be > maintained by AMD and will: > > - During probing, store information from all connected flashes in > stacked or parallel mode and present them as a single device to the > MTD layer. As I mentioned above, I do not think you should do stacked flashes this way. > - Register callbacks and manage MTD device registration within the new > layer instead of spi-nor/core.c. > - Make minimal changes in spi-nor/core.c, as stacked and parallel > handling will be managed by the new layer on top of SPI-NOR. > - Handle odd byte count requests from the MTD layer during flash > operations in parallel mode. You'd also probably have to add support in SPI MEM to signal the controller to use parallel mode. You don't want to use parallel mode all the time since you'd need to do "normal" operations as well such as reading/writing status registers, reading flash ID, SFDP, etc. That is yet another "cost" parallel mode support has -- it adds another thing to SPI MEM (I'm not saying the cost isn't necessarily worth it -- just pointing it out). >From the SPI NOR side, this layer would have to make sure both flashes get configured with the exact same settings. That would need SPI NOR to export how it configured a flash, ideally in a stable, well-defined format. It would also have to ask SPI NOR to construct the SPI MEM ops for it, and then edit them to set the "parallel mode" bit. Perhaps the dirmap op templates can come in handy here. It's hard to say much more without seeing the code. It would be interesting to see how you can manage to get this layer work without too much intrusion in the core. [...] --=20 Regards, Pratyush Yadav 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 3FE13D58D5E for ; Mon, 25 Nov 2024 15:41:47 +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: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=/GChOIrfWyDs9im1qVgMOvphX9K0jAQG2A5LVsvgF7w=; b=M+7+HFlMA5mi2w NM90jNUZ9ehEQm7c4ndsg4fPBUrzmjIwiYx7NMAwnRbh0qpvkUuuGJTG59/twqBFTlc5wMnPlQf0v X/3s+6rUyg/KW4TxlYByqhwQOyZI4dGKryCwSVA6gp6xkmYM2P0L5K4WxrI3mSBaH3CZB6ZUkyCVP xJylA29+3SkzjkTNZVN4/iiIqVwWdiqsCR/jsOaYt/FjvqIdhnU6mWINu8Qa7PwpkI2BBNxFSnQxT SaK78+Dxuzzfe+o8qdNZwCaIA9icEZPWMjA4WD2J+Ef+zlr9cqA5DSkWdMBKbr2gyv4wgH8OXAUJy tGaP2sLTB4t8r89ZlQmA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tFbDW-00000008XJC-2tkA; Mon, 25 Nov 2024 15:41:38 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tFbCG-00000008X5p-32rR; Mon, 25 Nov 2024 15:40:21 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 5853F5C5B42; Mon, 25 Nov 2024 15:39:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF9CC4CECE; Mon, 25 Nov 2024 15:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732549219; bh=IsIi8uedJB2d9ynke7rCIfulXuPxooj9TCcL71ClcMc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UOlx82X4RX72arozgLh4e2tPa5MBNgO9Qi33L80gyMCT5HjS3dpmJp3XcrgrLgn3z sLdYwVrnPcuZZK6sYdsz07Uby1Ub0Yq1ymSivQwLuoP+hnYgxZ8ZvLHm2puHpEKFzo Zd4eIt9Z9J4zPlr8vaS8GS+lEpuk3+AxWZSuZJYvVvWw69g8pNKdcnSlqXP0EoarjU DFNpMRE4VMztfKHAdv8F+FMlCsVbwyZF6PpHE2WqVgpqLNqQNCi2NDx69cpoSp4+vl y1l9ocGmPLRxnohePvYVpIx7zPpWzDskSICF3wCmjm0G7d6xyhzlczV4vCrkEMyVYv XCoI3aMIq981w== From: Pratyush Yadav To: Amit Kumar Mahapatra Cc: , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH 0/2] Add support for stacked and parallel memories In-Reply-To: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> (Amit Kumar Mahapatra's message of "Sat, 26 Oct 2024 13:23:45 +0530") References: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> Date: Mon, 25 Nov 2024 15:40:15 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241125_074020_866034_88CCDD56 X-CRM114-Status: GOOD ( 42.19 ) 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 T24gU2F0LCBPY3QgMjYgMjAyNCwgQW1pdCBLdW1hciBNYWhhcGF0cmEgd3JvdGU6CgpIaSBBbWl0 LAoKSSd2ZSBiZWVuIG1lYW5pbmcgdG8gbG9vayBpbnRvIHRoaXMgcHJvcG9zYWwgZm9yIHNvbWUg dGltZSBub3csIGJ1dCBvbmUKdGhpbmcgb3IgYW5vdGhlciBrZXB0IGNvbWluZyB1cCBhbmQgSSBu ZXZlciBnb3QgYXJvdW5kIHRvIGl0LiBXZWxsLCBJJ2xsCnRyeSB0byBnZXQgc29tZSBvZiBteSB0 aG91Z2h0cyBvdXQgd2l0aCB0aGlzIHJlcGx5LiBJIHN0aWxsIGhhdmVuJ3QKbG9va2VkIHZlcnkg ZGVlcGx5IGludG8gdGhlIHBhc3QgZGlzY3Vzc2lvbnMsIHNvIGFwb2xvZ2llcyBpZiBJIGJyaW5n IHVwCnNvbWV0aGluZyB0aGF0IHdhcyBhbHJlYWR5IGRpc2N1c3NlZC4KCj4gSGVsbG8gRXZlcnlv bmUsCj4KPiBGb2xsb3dpbmcgYW4gZW1haWwgZGlzY3Vzc2lvbiB3aXRoIE1pcXVlbCByZWdhcmRp bmcgdGhlIGJpbmRpbmcgY2hhbmdlcwo+IGFuZCBvdmVyYWxsIGFyY2hpdGVjdHVyZSBmb3IgaW1w bGVtZW50aW5nIHN1cHBvcnQgZm9yIHN0YWNrZWQgYW5kIHBhcmFsbGVsCj4gbWVtb3JpZXMsIEni gJltIHNoYXJpbmcgdGhpcyBSRkMgdG8gaW5pdGlhdGUgYSBkaXNjdXNzaW9uIG9uIHRoZSBwcm9w b3NlZAo+IHVwZGF0ZXMgdG8gY3VycmVudCBiaW5kaW5ncyBhbmQgdG8gZmluYWxpemUgdGhlIGlt cGxlbWVudGF0aW9uCj4gYXJjaGl0ZWN0dXJlLgo+Cj4gQmVmb3JlIGRpdmluZyBpbnRvIHRoZSBt YWluIHRvcGljLCBoZXJlIGlzIHNvbWUgYmFja2dyb3VuZCBvbiBzdGFja2VkIGFuZAo+IHBhcmFs bGVsIG1lbW9yaWVzLgo+Cj4gVGhlIEFNRCBRU1BJIGNvbnRyb2xsZXIgc3VwcG9ydHMgdHdvIGFk dmFuY2VkIGNvbm5lY3Rpb24gbW9kZXMoU3RhY2tlZCBhbmQKPiBQYXJhbGxlbCkgd2hpY2ggYWxs b3cgdGhlIGNvbnRyb2xsZXIgdG8gdHJlYXQgdHdvIGRpZmZlcmVudCBmbGFzaGVzIGFzIG9uZQo+ IHN0b3JhZ2UuCj4KPiBTdGFja2VkOgo+IEZsYXNoZXMgc2hhcmUgdGhlIHNhbWUgU1BJIGJ1cywg YnV0IGRpZmZlcmVudCBDUyBsaW5lLCBjb250cm9sbGVyIGRyaXZlcgo+IGFzc2VydHMgdGhlIENT IG9mIHRoZSBmbGFzaCB0byB3aGljaCBpdCBuZWVkcyB0byBjb21tdW5pY2F0ZS4gU3RhY2tlZCBt b2RlCj4gaXMgYSBzb2Z0d2FyZSBhYnN0cmFjdGlvbiByYXRoZXIgdGhhbiBhIGNvbnRyb2xsZXIg ZmVhdHVyZSBvciBjYXBhYmlsaXR5Lgo+IEF0IGFueSBnaXZlbiB0aW1lLCB0aGUgY29udHJvbGxl ciBjb21tdW5pY2F0ZXMgd2l0aCBvbmUgb2YgdGhlIHR3bwo+IGNvbm5lY3RlZCBmbGFzaCBkZXZp Y2VzLCBhcyBkZXRlcm1pbmVkIGJ5IHRoZSByZXF1ZXN0ZWQgYWRkcmVzcyBhbmQgZGF0YQo+IGxl bmd0aC4gSWYgYW4gb3BlcmF0aW9uIHN0YXJ0cyBvbiBvbmUgZmxhc2ggYW5kIGVuZHMgb24gdGhl IG90aGVyLCB0aGUKPiBjb3JlIG5lZWRzIHRvIHNwbGl0IGl0IGludG8gdHdvIHNlcGFyYXRlIG9w ZXJhdGlvbnMgYW5kIGFkanVzdCB0aGUgZGF0YQo+IGxlbmd0aCBhY2NvcmRpbmdseS4KPgo+IFBh cmFsbGVsKE11bHRpLUNTKToKPiBCb3RoIHRoZSBmbGFzaGVzIGhhdmUgdGhlaXIgc2VwYXJhdGUg U1BJIGJ1cywgQ1Mgb2YgYm90aCB0aGUgZmxhc2hlcyB3aWxsCj4gYmUgYXNzZXJ0ZWQvZGUtYXNz ZXJ0ZWQgYXQgdGhlIHNhbWUgdGltZS4gSW4gdGhpcyBtb2RlIGRhdGEgd2lsbCBiZSBzcGxpdAo+ IGFjcm9zcyBib3RoIHRoZSBmbGFzaGVzIGJ5IGVuYWJsaW5nIHRoZSBTVFJJUEUgc2V0dGluZyBp biB0aGUgY29udHJvbGxlci4KPiBQYXJhbGxlbCBtb2RlIGlzIGEgY29udHJvbGxlciBmZWF0dXJl IHdoZXJlIGlmIHRoZSBTVFJJUEUgYml0IGlzIHNldCB0aGVuCj4gdGhlIGNvbnRyb2xsZXIgaW50 ZXJuYWxseSBoYW5kbGVzIHRoZSBkYXRhIHNwbGl0IGR1cmluZyBkYXRhIHdyaXRlIHRvIHRoZQo+ IGZsYXNoZXMgYW5kIHdoaWxlIHJlYWRpbmcgZGF0YSBmcm9tIHRoZSBmbGFzaCB0aGUgY29udHJv bGxlciBpbnRlcm5hbGx5Cj4gbWVyZ2VzIGRhdGEgZnJvbSBib3RoIHRoZSBmbGFzaGVzIGJlZm9y ZSB3cml0aW5nIHRvIHRoZSBjb250cm9sbGVyIEZJRk8uCj4gSWYgU1RSSVBFIGlzIG5vdCBlbmFi bGVkLCB0aGVuIHNhbWUgZGF0YSB3aWxsIGJlIHNlbnQgdG8gYm90aCB0aGUgZGV2aWNlcy4KPiBJ biBwYXJhbGxlbCBtb2RlIGJvdGggdGhlIGZsYXNoZXMgc2hvdWxkIGJlIGlkZW50aWNhbC4KPgo+ IEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBtb2RlcyBwbGVhc2UgZmVlbCBmcmVlIHRvIGdv IHRocm91Z2ggdGhlCj4gY29udHJvbGxlciBmbGFzaCBpbnRlcmZhY2UgYmVsb3cgWzFdLgo+Cj4g TWlyb2NoaXAgUVNQSSBjb250cm9sbGVyWzJdIGFsc28gc3VwcG9ydHMgIkR1YWwgUGFyYWxsZWwg OC1iaXQgSU8gbW9kZSIsCj4gYnV0IHRoZXkgY2FsbCBpdCAiVHdpbiBRdWFkIE1vZGUiLgo+Cj4g SW5pdGlhbGx5IGluIFszXSBbNF0gWzVdIE1pcXVlbCBoYWQgdHJpZWQgdG8gZXh0ZW5kIE1URC1D T05DQVQgZHJpdmVyIHRvCj4gc3VwcG9ydCBTdGFja2VkIG1vZGUsIGJ1dCB0aGUgYmluZGluZ3Mg d2VyZSBub3QgYWNjZXB0ZWQuIFNvLCB0aGUKPiBNVEQtQ09OQ0FUIGFwcHJvYWNoIHdhcyBkcm9w cGVkIGFuZCB0aGUgRFQgYmluZGluZ3MgdGhhdCBnb3QgYWNjZXB0ZWQKPiBbNl0gWzddIFs4XSB0 aGF0IGRlc2NyaWJlcyB0aGUgdHdvIGZsYXNoIGRldmljZXMgYXMgYmVpbmcgb25lLiBTUEkgY29y ZQo+IGNoYW5nZXMgdG8gc3VwcG9ydCB0aGUgYWJvdmUgYmluZGluZ3Mgd2VyZSBhZGRlZCBbOV0u IFdoaWxlIGFkZGluZyB0aGUKPiBzdXBwb3J0IGluIFNQSS1OT1IgIFR1ZG9yIHByb3ZpZGVkIGFk ZGl0aW9uYWwgZmVlZGJhY2ssIGxlYWRpbmcgdG8gYQo+IGRpc2N1c3Npb24gb24gdXBkYXRpbmcg dGhlIGN1cnJlbnQgc3RhY2tlZCBhbmQgcGFyYWxsZWwgRFQgYmluZGluZ3MuCj4KPiBQcm9wb3Nl ZCBTb2x1dGlvbjoKPiBUaGUgc29sdXRpb24gaGFzIHR3byBwYXJ0czoKPgo+IDEuIFVwZGF0ZSBN VEQtQ09OQ0FUCj4gICAgVXBkYXRlIE1URC1DT05DQVQgdG8gY3JlYXRlIHZpcnR1YWwgY29uY2F0 aW5hdGVkIG10ZCBkZXZpY2VzIGFzIGRlZmluZWQKPiAgICBpbiB0aGUgZGV2aWNlIHRyZWUuCgpG cm9tIGEgdmVyeSBxdWljayBsb29rLCBpdCBzZWVtcyBtdGRjb25jYXQgc2hvdWxkIGFscmVhZHkg ZG8gbW9zdCBvZgp3aGF0IHlvdSB3YW50IHdpdGggInN0YWNrZWQgbW9kZSIuIFRoZSB0cmlja3kg Yml0cyBtaWdodCBiZSBkZXZpY2V0cmVlCmRlc2lnbiwgYnV0IGZyb20gdGhlIHNvZnR3YXJlIHBl cnNwZWN0aXZlLCBJIHRoaW5rIG10ZGNvbmNhdCBtYWtlcwpwZXJmZWN0IHNlbnNlLiBZb3UgbGVh dmUgYWxsIHRoZSBjb21wbGV4aXR5IHRvIHRoZSBTUEkgTk9SIGxheWVyIHNpbmNlCml0IGFscmVh ZHkgaGFuZGxlcyB0aGVtLCBhbmQganVzdCB1c2UgdGhlIGhpZ2hlci1sZXZlbCBNVEQgbGF5ZXIg dG8KdmlydHVhbGx5IGNvbmNhdGVuYXRlIGRldmljZXMuIEFkZGluZyBhIG5ldyBsYXllciBiZXR3 ZWVuIE1URCBhbmQgU1BJCk5PUiBtYWtlcyBsaXR0bGUgc2Vuc2UgYmVjYXVzZSBtdGRjb25jYXQg aXMgYWxyZWFkeSB0aGF0IGxheWVyLiBBbm90aGVyCmJlbmVmaXQgb2YgdGhpcyB3b3VsZCBiZSB5 b3UgY2FuIGp1c3QgYXMgZWFzaWx5IGNvbmNhdGVuYXRlIGFueSBraW5kcyBvZgpmbGFzaGVzIHlv dSB3YW50OyB0aGV5IGRvbid0IGhhdmUgdG8gYmUgdGhlIHNhbWUuCgpJIHRoaW5rIHRoaXMgaXMg YSBtdWNoIHNpbXBsZXIgcHJvYmxlbSB0byBzb2x2ZSBjb21wYXJlZCB0byBwYXJhbGxlbAptb2Rl LiBPbmNlIHlvdSBmaWd1cmUgb3V0IHRoZSBkZXZpY2V0cmVlIHN0dWZmLCBhbmQgSSB0aGluayB0 aGUKbXRkY29uY2F0IGNoYW5nZXMgc2hvdWxkIGJlIHNpbXBsZSBhbmQgbm90IHRvbyBjb250cm92 ZXJzaWFsLiBTbyBJIHRoaW5rCnlvdSBzaG91bGQgc3BsaXQgdGhlIHBhcmFsbGVsIGFuZCBzdGFj a2VkIHN1cHBvcnQgaW50byB0d28gaW5kZXBlbmRlbnQKc2VyaWVzLiBUaGlzIHdheSB5b3UgbWFr ZSBwcm9ncmVzcyB3aXRob3V0IGhhdmluZyB0byB3YWl0IGZvcgpkaXNjdXNzaW9ucyBhcm91bmQg cGFyYWxsZWwgbW9kZSBzdXBwb3J0IHRvIHNldHRsZS4KCj4KPiAyLiBBZGQgYSBOZXcgTGF5ZXIK PiAgICBBZGQgYSBuZXcgbGF5ZXIgYmV0d2VlbiB0aGUgU1BJLU5PUiBhbmQgTVREIGxheWVycyB0 byBzdXBwb3J0IHN0YWNrZWQKPiAgICBhbmQgcGFyYWxsZWwgY29uZmlndXJhdGlvbnMuIFRoaXMg bmV3IGxheWVyIHdpbGwgYmUgcGFydCBvZiBzcGktbm9yLAo+ICAgIGxvY2F0ZWQgaW4gbXRkL3Nw aS1ub3IvLCBjYW4gYmUgaW5jbHVkZWQvZXhjbHVkZWQgdmlhIEtjb25maWcsIHdpbGwgYmUKPiAg ICBtYWludGFpbmVkIGJ5IEFNRCBhbmQgd2lsbDoKPgo+ICAgIC0gRHVyaW5nIHByb2JpbmcsIHN0 b3JlIGluZm9ybWF0aW9uIGZyb20gYWxsIGNvbm5lY3RlZCBmbGFzaGVzIGluCj4gICAgICBzdGFj a2VkIG9yIHBhcmFsbGVsIG1vZGUgYW5kIHByZXNlbnQgdGhlbSBhcyBhIHNpbmdsZSBkZXZpY2Ug dG8gdGhlCj4gCSBNVEQgbGF5ZXIuCgpBcyBJIG1lbnRpb25lZCBhYm92ZSwgSSBkbyBub3QgdGhp bmsgeW91IHNob3VsZCBkbyBzdGFja2VkIGZsYXNoZXMgdGhpcwp3YXkuCgo+ICAgIC0gUmVnaXN0 ZXIgY2FsbGJhY2tzIGFuZCBtYW5hZ2UgTVREIGRldmljZSByZWdpc3RyYXRpb24gd2l0aGluIHRo ZSBuZXcKPiAgICAgIGxheWVyIGluc3RlYWQgb2Ygc3BpLW5vci9jb3JlLmMuCj4gICAgLSBNYWtl IG1pbmltYWwgY2hhbmdlcyBpbiBzcGktbm9yL2NvcmUuYywgYXMgc3RhY2tlZCBhbmQgcGFyYWxs ZWwKPiAgICAgIGhhbmRsaW5nIHdpbGwgYmUgbWFuYWdlZCBieSB0aGUgbmV3IGxheWVyIG9uIHRv cCBvZiBTUEktTk9SLgo+ICAgIC0gSGFuZGxlIG9kZCBieXRlIGNvdW50IHJlcXVlc3RzIGZyb20g dGhlIE1URCBsYXllciBkdXJpbmcgZmxhc2gKPiAgICAgIG9wZXJhdGlvbnMgaW4gcGFyYWxsZWwg bW9kZS4KCllvdSdkIGFsc28gcHJvYmFibHkgaGF2ZSB0byBhZGQgc3VwcG9ydCBpbiBTUEkgTUVN IHRvIHNpZ25hbCB0aGUKY29udHJvbGxlciB0byB1c2UgcGFyYWxsZWwgbW9kZS4gWW91IGRvbid0 IHdhbnQgdG8gdXNlIHBhcmFsbGVsIG1vZGUgYWxsCnRoZSB0aW1lIHNpbmNlIHlvdSdkIG5lZWQg dG8gZG8gIm5vcm1hbCIgb3BlcmF0aW9ucyBhcyB3ZWxsIHN1Y2ggYXMKcmVhZGluZy93cml0aW5n IHN0YXR1cyByZWdpc3RlcnMsIHJlYWRpbmcgZmxhc2ggSUQsIFNGRFAsIGV0Yy4gVGhhdCBpcwp5 ZXQgYW5vdGhlciAiY29zdCIgcGFyYWxsZWwgbW9kZSBzdXBwb3J0IGhhcyAtLSBpdCBhZGRzIGFu b3RoZXIgdGhpbmcgdG8KU1BJIE1FTSAoSSdtIG5vdCBzYXlpbmcgdGhlIGNvc3QgaXNuJ3QgbmVj ZXNzYXJpbHkgd29ydGggaXQgLS0ganVzdApwb2ludGluZyBpdCBvdXQpLgoKRnJvbSB0aGUgU1BJ IE5PUiBzaWRlLCB0aGlzIGxheWVyIHdvdWxkIGhhdmUgdG8gbWFrZSBzdXJlIGJvdGggZmxhc2hl cwpnZXQgY29uZmlndXJlZCB3aXRoIHRoZSBleGFjdCBzYW1lIHNldHRpbmdzLiBUaGF0IHdvdWxk IG5lZWQgU1BJIE5PUiB0bwpleHBvcnQgaG93IGl0IGNvbmZpZ3VyZWQgYSBmbGFzaCwgaWRlYWxs eSBpbiBhIHN0YWJsZSwgd2VsbC1kZWZpbmVkCmZvcm1hdC4gSXQgd291bGQgYWxzbyBoYXZlIHRv IGFzayBTUEkgTk9SIHRvIGNvbnN0cnVjdCB0aGUgU1BJIE1FTSBvcHMKZm9yIGl0LCBhbmQgdGhl biBlZGl0IHRoZW0gdG8gc2V0IHRoZSAicGFyYWxsZWwgbW9kZSIgYml0LiBQZXJoYXBzIHRoZQpk aXJtYXAgb3AgdGVtcGxhdGVzIGNhbiBjb21lIGluIGhhbmR5IGhlcmUuCgpJdCdzIGhhcmQgdG8g c2F5IG11Y2ggbW9yZSB3aXRob3V0IHNlZWluZyB0aGUgY29kZS4gSXQgd291bGQgYmUKaW50ZXJl c3RpbmcgdG8gc2VlIGhvdyB5b3UgY2FuIG1hbmFnZSB0byBnZXQgdGhpcyBsYXllciB3b3JrIHdp dGhvdXQgdG9vCm11Y2ggaW50cnVzaW9uIGluIHRoZSBjb3JlLgoKWy4uLl0KCi0tIApSZWdhcmRz LApQcmF0eXVzaCBZYWRhdgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcgbGlzdApodHRwOi8v bGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10ZC8K From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 121621AF0B5; Mon, 25 Nov 2024 15:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732549222; cv=none; b=sv+Npylt9PNZjRdQENYoaGDCCsc0hQUhMUVPxSj0Q8W18DMGZfWIsRQnyelryOQdKP6aRxUJZ6jcReV+Mk63Q7e2wgj1D9V2c3HSGHG2G6TQfGPT3Q2d6EsHdsbCj2SqHgO08w4qIqxvOIM4YXVtYjTS0jnZceN84CLOj9ympQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732549222; c=relaxed/simple; bh=IsIi8uedJB2d9ynke7rCIfulXuPxooj9TCcL71ClcMc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=sOLDU8HcxNJPoUXl4AVRzoe3llw+d51ovsGeorqvSDcmEjChW7+V2tk80LBdwQKznrk/WZT7HKAYEM1JsbuckRh+nj7W15TCWWqeChzzEGkES+R8fjhY5fUFWT1dHgp9l21fZlGeFJ6vYD9zTxrbAtQDmbU94X0y1rTcFREiiF4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UOlx82X4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UOlx82X4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF9CC4CECE; Mon, 25 Nov 2024 15:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732549219; bh=IsIi8uedJB2d9ynke7rCIfulXuPxooj9TCcL71ClcMc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UOlx82X4RX72arozgLh4e2tPa5MBNgO9Qi33L80gyMCT5HjS3dpmJp3XcrgrLgn3z sLdYwVrnPcuZZK6sYdsz07Uby1Ub0Yq1ymSivQwLuoP+hnYgxZ8ZvLHm2puHpEKFzo Zd4eIt9Z9J4zPlr8vaS8GS+lEpuk3+AxWZSuZJYvVvWw69g8pNKdcnSlqXP0EoarjU DFNpMRE4VMztfKHAdv8F+FMlCsVbwyZF6PpHE2WqVgpqLNqQNCi2NDx69cpoSp4+vl y1l9ocGmPLRxnohePvYVpIx7zPpWzDskSICF3wCmjm0G7d6xyhzlczV4vCrkEMyVYv XCoI3aMIq981w== From: Pratyush Yadav To: Amit Kumar Mahapatra Cc: , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH 0/2] Add support for stacked and parallel memories In-Reply-To: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> (Amit Kumar Mahapatra's message of "Sat, 26 Oct 2024 13:23:45 +0530") References: <20241026075347.580858-1-amit.kumar-mahapatra@amd.com> Date: Mon, 25 Nov 2024 15:40:15 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) 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-Transfer-Encoding: quoted-printable On Sat, Oct 26 2024, Amit Kumar Mahapatra wrote: Hi Amit, I've been meaning to look into this proposal for some time now, but one thing or another kept coming up and I never got around to it. Well, I'll try to get some of my thoughts out with this reply. I still haven't looked very deeply into the past discussions, so apologies if I bring up something that was already discussed. > Hello Everyone, > > Following an email discussion with Miquel regarding the binding changes > and overall architecture for implementing support for stacked and parallel > memories, I=E2=80=99m sharing this RFC to initiate a discussion on the pr= oposed > updates to current bindings and to finalize the implementation > architecture. > > Before diving into the main topic, here is some background on stacked and > parallel memories. > > The AMD QSPI controller supports two advanced connection modes(Stacked and > Parallel) which allow the controller to treat two different flashes as one > storage. > > Stacked: > Flashes share the same SPI bus, but different CS line, controller driver > asserts the CS of the flash to which it needs to communicate. Stacked mode > is a software abstraction rather than a controller feature or capability. > At any given time, the controller communicates with one of the two > connected flash devices, as determined by the requested address and data > length. If an operation starts on one flash and ends on the other, the > core needs to split it into two separate operations and adjust the data > length accordingly. > > Parallel(Multi-CS): > Both the flashes have their separate SPI bus, CS of both the flashes will > be asserted/de-asserted at the same time. In this mode data will be split > across both the flashes by enabling the STRIPE setting in the controller. > Parallel mode is a controller feature where if the STRIPE bit is set then > the controller internally handles the data split during data write to the > flashes and while reading data from the flash the controller internally > merges data from both the flashes before writing to the controller FIFO. > If STRIPE is not enabled, then same data will be sent to both the devices. > In parallel mode both the flashes should be identical. > > For more information on the modes please feel free to go through the > controller flash interface below [1]. > > Mirochip QSPI controller[2] also supports "Dual Parallel 8-bit IO mode", > but they call it "Twin Quad Mode". > > Initially in [3] [4] [5] Miquel had tried to extend MTD-CONCAT driver to > support Stacked mode, but the bindings were not accepted. So, the > MTD-CONCAT approach was dropped and the DT bindings that got accepted > [6] [7] [8] that describes the two flash devices as being one. SPI core > changes to support the above bindings were added [9]. While adding the > support in SPI-NOR Tudor provided additional feedback, leading to a > discussion on updating the current stacked and parallel DT bindings. > > Proposed Solution: > The solution has two parts: > > 1. Update MTD-CONCAT > Update MTD-CONCAT to create virtual concatinated mtd devices as defined > in the device tree. >From a very quick look, it seems mtdconcat should already do most of what you want with "stacked mode". The tricky bits might be devicetree design, but from the software perspective, I think mtdconcat makes perfect sense. You leave all the complexity to the SPI NOR layer since it already handles them, and just use the higher-level MTD layer to virtually concatenate devices. Adding a new layer between MTD and SPI NOR makes little sense because mtdconcat is already that layer. Another benefit of this would be you can just as easily concatenate any kinds of flashes you want; they don't have to be the same. I think this is a much simpler problem to solve compared to parallel mode. Once you figure out the devicetree stuff, and I think the mtdconcat changes should be simple and not too controversial. So I think you should split the parallel and stacked support into two independent series. This way you make progress without having to wait for discussions around parallel mode support to settle. > > 2. Add a New Layer > Add a new layer between the SPI-NOR and MTD layers to support stacked > and parallel configurations. This new layer will be part of spi-nor, > located in mtd/spi-nor/, can be included/excluded via Kconfig, will be > maintained by AMD and will: > > - During probing, store information from all connected flashes in > stacked or parallel mode and present them as a single device to the > MTD layer. As I mentioned above, I do not think you should do stacked flashes this way. > - Register callbacks and manage MTD device registration within the new > layer instead of spi-nor/core.c. > - Make minimal changes in spi-nor/core.c, as stacked and parallel > handling will be managed by the new layer on top of SPI-NOR. > - Handle odd byte count requests from the MTD layer during flash > operations in parallel mode. You'd also probably have to add support in SPI MEM to signal the controller to use parallel mode. You don't want to use parallel mode all the time since you'd need to do "normal" operations as well such as reading/writing status registers, reading flash ID, SFDP, etc. That is yet another "cost" parallel mode support has -- it adds another thing to SPI MEM (I'm not saying the cost isn't necessarily worth it -- just pointing it out). >From the SPI NOR side, this layer would have to make sure both flashes get configured with the exact same settings. That would need SPI NOR to export how it configured a flash, ideally in a stable, well-defined format. It would also have to ask SPI NOR to construct the SPI MEM ops for it, and then edit them to set the "parallel mode" bit. Perhaps the dirmap op templates can come in handy here. It's hard to say much more without seeing the code. It would be interesting to see how you can manage to get this layer work without too much intrusion in the core. [...] --=20 Regards, Pratyush Yadav