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 2F965C52D7B for ; Wed, 14 Aug 2024 10:55:22 +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 A1F0B227E; Wed, 14 Aug 2024 12:55:10 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A1F0B227E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1723632920; bh=uNzw9J4WE8npfPuqFzki9uq65FktmGhF48iIhaLpTf4=; 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=oXJoeZkA364Mkb9n8RBM7aoAmxg8ZDW7KDzLLYC2cP9LbzD1ox6sv4MsJYhGuW+Yv vWIaieoiqDYOA4f4P6bley05mDREnrY+xcUerhsCn7EnpqeglHr5drTKpooGXimRrv ysFcBSn2lgSVk9mAay+nTOMha+HKvEqO8Popkb5g= Received: by alsa1.perex.cz (Postfix, from userid 50401) id CAA19F806CC; Wed, 14 Aug 2024 12:53:30 +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 17469F806BE; Wed, 14 Aug 2024 12:53:30 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 338A4F80423; Wed, 14 Aug 2024 10:46:55 +0200 (CEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::221]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C049DF800B0 for ; Wed, 14 Aug 2024 10:46:28 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C049DF800B0 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=FdsiK+vF Received: by mail.gandi.net (Postfix) with ESMTPSA id 7A91E240002; Wed, 14 Aug 2024 08:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723625187; 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=ucah7eJHaaeq3ephNaG8kgL8jqU515QWycrDeI4W32U=; b=FdsiK+vFzIxzAqPbfc+zcpWwxzSkeu0QWaWCCAjEbz0ECS+4Gop5b9iMy9KvidVfzrT8YS R3glCu3H/fqGqqli0J7bcQs1w03PBRnmCapSt56E9eryaNugOsi1PeVvaPMZvrGAhfIkSu /t4pALdm08hT/0XNHlcrmjKN0EZBCdXNgFQPpp1Z0aEC9SrkAFKSLnmVn9py1QCfRHIjnT 2sHSq8VKWfcCkSJJEP/ynJ4bZVshyjwgQhXFQlj4veogBmCtfuNurSeoBV7fWvqLvn4VxT XCZP930UGMK7PVedVe/wN8EbyAnhDkfoixyA+y09If7Os0pmm1Gwux56yiPboQ== Date: Wed, 14 Aug 2024 10:46:23 +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: <20240814104623.72eef495@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> <20240812103812.72763f69@xps-13> 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: 7KHPRYAF4FVBK7UMTEV4QJKKRAGUDTJQ X-Message-ID-Hash: 7KHPRYAF4FVBK7UMTEV4QJKKRAGUDTJQ 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 Amit, amit.kumar-mahapatra@amd.com wrote on Wed, 14 Aug 2024 07:13:35 +0000: > Hello Miquel, >=20 > > > Based on the inputs/suggestions from Tudor, i am planning to add a new > > > layer between the SPI-NOR and MTD layers to support stacked and > > > parallel configurations. This new layer will be part of the spi-nor > > > and located in mtd/spi-nor/ =20 > >=20 > > For now I don't think you need a totally generic implementation. As lon= g as > > there is only one controller supporting these modes, I'd say this is no= t super > > relevant. =20 >=20 > IMHO, there should be a general solution since this isn't limited to just= =20 > one controller. Any controller can support stacked mode with multiple=20 > native-cs or multiple gpio-cs, or with a combination of a native-cs and a= =20 > gpio-cs. That's not what was initially discussed. The Xilinx use case was: a controller is managing two devices "at the same time" transparently from the host. So the two flashes appear like a single one and thus, are described like a single one. You don't need anything in the bindings nor in the core to manage two flashes connected to the same controller otherwise. The only use case the Xilinx model was bringing, was to consider the storage bigger from a host perspective and thus be able to store files across the device boundary natively. > For parallel configurations, there are other controllers from=20 > Microchip and some flash devices that operate similarly to AMD's parallel= =20 > mode. Yes, Tudor reminded me about these. > > > This layer would perform the following tasks: > > > - During probing, store information from all the connected flashes, > > > whether in stacked or parallel mode, and present it as a single de= vice > > > to the MTD layer. > > > - Register callbacks through this new layer instead of spi-nor/core.= c and > > > handle MTD device registration. > > > - In stacked mode, select the appropriate spi-nor flash based on the > > > 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 > > > operations in parallel mode. > > > > > > For implementing this the current DT binding need to be updated as > > > follows. =20 > >=20 > > So you want to go back to step 1 and redefine bindings? Is that worth? = =20 >=20 > The current bindings are effective if we only support identical=20 > flash devices or flashes of the same make but with different sizes=20 > connected in stacked mode. However, if we want to extend stacked support= =20 > to include flashes of different makes in stacked mode, The only actual feature the stacked mode brings is the ability to consider two devices like one. This is abstracted by hardware, this is a controller capability. The only way this can work is if the two storage devices are of the same kind and accept the same commands/init cycles. If you consider two different devices, then there is no hardware abstraction anymore, the controller is no longer "smart" enough and you are back to the standard situation with two devices connected using their own independent CS, known by the host. In this case the "stacked-mode" bindings no longer apply. You need to describe the two chips independently in the DT, and your stacked feature in the controller can no longer be used. You need other bindings to support this case because it is a different situation. For this case, there was a mtd-concat approach (which was never merged). But this is really something different than the stacked mode in your controller because there is no specific hardware feature involved, it's just pure software. > the current=20 > bindings may not be adequate. That's why I suggested updating the binding= s=20 > to accommodate all possible scenario. >=20 > > =20 > > > stacked-memories DT changes: > > > - Flash size information can be retrieved directly from the flash, s= o it > > > has been removed from the DT binding. > > > - Each stacked flash will have its own flash node. This approach all= ows > > > flashes of different makes and sizes to be stacked together, as ea= ch > > > flash will be probed individually. =20 > >=20 > > And how will you define partitions crossing device boundaries? I believ= e this > > constraint has been totally forgotten in this proposal. =20 >=20 > According to the new binding proposal, one of the two flash nodes will=20 > have a partition that crosses the device boundary. =46rom a bindings perspective, it feels very awkward and I doubt it will be accepted. From a code perspective, you're gonna need to butcher the core... > > The whole idea of stacking two devices this way was to simplify the use= r's life > > with a single device exposed and the controller handling itself the CS = changes. > > That is precisely what the current binding do. =20 >=20 > That's true, but as I mentioned earlier, if we're not inclined to support= =20 > stacked mode for flashes of different makes, then the current bindings=20 > are sufficient. 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 9FE0BC531DD for ; Wed, 14 Aug 2024 10:00: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: 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=8mgLPB5jaOl9sB15pRgRS3MKe+hl4i1cScmuTQXXmRI=; b=SZIks/MElgE0mL Dm6LEhnn9kGpijSkWYrN21g+9Y9HTRmu/1Cb1ee731alksGHJbWnQlwGMDCuE4lgPrVaDWXwKcbiG XI/Viafw5z/NLKVbszOarw1Y2+E8SL0V+jHj4ywhisBxDUT+FQK39Xr3ONkzTwHatw1imtoEno2ZM SlSDmA81XfFh/qafpRX1k5QviGlS+k49kSgmOfpY1se88jUDu2q/10NP7wnzb/NZdeLMLv+oskkqQ Xc+5YLs3oeDexzQhEfuhF0YnSKcPbJb9geZOU2csmfzb73j66IY+KnrsjGgdHyfCsg70In7cLsInK 67T7+XcWVKQstSVHK5HA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seAo6-00000006U30-31qh; Wed, 14 Aug 2024 10:00:42 +0000 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1se9eJ-00000006Gc2-1kcz; Wed, 14 Aug 2024 08:46:33 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 7A91E240002; Wed, 14 Aug 2024 08:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723625187; 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=ucah7eJHaaeq3ephNaG8kgL8jqU515QWycrDeI4W32U=; b=FdsiK+vFzIxzAqPbfc+zcpWwxzSkeu0QWaWCCAjEbz0ECS+4Gop5b9iMy9KvidVfzrT8YS R3glCu3H/fqGqqli0J7bcQs1w03PBRnmCapSt56E9eryaNugOsi1PeVvaPMZvrGAhfIkSu /t4pALdm08hT/0XNHlcrmjKN0EZBCdXNgFQPpp1Z0aEC9SrkAFKSLnmVn9py1QCfRHIjnT 2sHSq8VKWfcCkSJJEP/ynJ4bZVshyjwgQhXFQlj4veogBmCtfuNurSeoBV7fWvqLvn4VxT XCZP930UGMK7PVedVe/wN8EbyAnhDkfoixyA+y09If7Os0pmm1Gwux56yiPboQ== Date: Wed, 14 Aug 2024 10:46:23 +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: <20240814104623.72eef495@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> <20240812103812.72763f69@xps-13> 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-20240814_014631_770799_09E0098D X-CRM114-Status: GOOD ( 36.30 ) 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 SGkgQW1pdCwKCmFtaXQua3VtYXItbWFoYXBhdHJhQGFtZC5jb20gd3JvdGUgb24gV2VkLCAxNCBB dWcgMjAyNCAwNzoxMzozNSArMDAwMDoKCj4gSGVsbG8gTWlxdWVsLAo+IAo+ID4gPiBCYXNlZCBv biB0aGUgaW5wdXRzL3N1Z2dlc3Rpb25zIGZyb20gVHVkb3IsIGkgYW0gcGxhbm5pbmcgdG8gYWRk IGEgbmV3Cj4gPiA+IGxheWVyIGJldHdlZW4gdGhlIFNQSS1OT1IgYW5kIE1URCBsYXllcnMgdG8g c3VwcG9ydCBzdGFja2VkIGFuZAo+ID4gPiBwYXJhbGxlbCBjb25maWd1cmF0aW9ucy4gVGhpcyBu ZXcgbGF5ZXIgd2lsbCBiZSBwYXJ0IG9mIHRoZSBzcGktbm9yCj4gPiA+IGFuZCBsb2NhdGVkIGlu IG10ZC9zcGktbm9yLyAgCj4gPiAKPiA+IEZvciBub3cgSSBkb24ndCB0aGluayB5b3UgbmVlZCBh IHRvdGFsbHkgZ2VuZXJpYyBpbXBsZW1lbnRhdGlvbi4gQXMgbG9uZyBhcwo+ID4gdGhlcmUgaXMg b25seSBvbmUgY29udHJvbGxlciBzdXBwb3J0aW5nIHRoZXNlIG1vZGVzLCBJJ2Qgc2F5IHRoaXMg aXMgbm90IHN1cGVyCj4gPiByZWxldmFudC4gIAo+IAo+IElNSE8sIHRoZXJlIHNob3VsZCBiZSBh IGdlbmVyYWwgc29sdXRpb24gc2luY2UgdGhpcyBpc24ndCBsaW1pdGVkIHRvIGp1c3QgCj4gb25l IGNvbnRyb2xsZXIuIEFueSBjb250cm9sbGVyIGNhbiBzdXBwb3J0IHN0YWNrZWQgbW9kZSB3aXRo IG11bHRpcGxlIAo+IG5hdGl2ZS1jcyBvciBtdWx0aXBsZSBncGlvLWNzLCBvciB3aXRoIGEgY29t YmluYXRpb24gb2YgYSBuYXRpdmUtY3MgYW5kIGEgCj4gZ3Bpby1jcy4KClRoYXQncyBub3Qgd2hh dCB3YXMgaW5pdGlhbGx5IGRpc2N1c3NlZC4gVGhlIFhpbGlueCB1c2UgY2FzZSB3YXM6CmEgY29u dHJvbGxlciBpcyBtYW5hZ2luZyB0d28gZGV2aWNlcyAiYXQgdGhlIHNhbWUgdGltZSIgdHJhbnNw YXJlbnRseQpmcm9tIHRoZSBob3N0LiBTbyB0aGUgdHdvIGZsYXNoZXMgYXBwZWFyIGxpa2UgYSBz aW5nbGUgb25lIGFuZCB0aHVzLAphcmUgZGVzY3JpYmVkIGxpa2UgYSBzaW5nbGUgb25lLgoKWW91 IGRvbid0IG5lZWQgYW55dGhpbmcgaW4gdGhlIGJpbmRpbmdzIG5vciBpbiB0aGUgY29yZSB0byBt YW5hZ2UgdHdvCmZsYXNoZXMgY29ubmVjdGVkIHRvIHRoZSBzYW1lIGNvbnRyb2xsZXIgb3RoZXJ3 aXNlLiBUaGUgb25seSB1c2UgY2FzZQp0aGUgWGlsaW54IG1vZGVsIHdhcyBicmluZ2luZywgd2Fz IHRvIGNvbnNpZGVyIHRoZSBzdG9yYWdlIGJpZ2dlciBmcm9tCmEgaG9zdCBwZXJzcGVjdGl2ZSBh bmQgdGh1cyBiZSBhYmxlIHRvIHN0b3JlIGZpbGVzIGFjcm9zcyB0aGUgZGV2aWNlCmJvdW5kYXJ5 IG5hdGl2ZWx5LgoKPiBGb3IgcGFyYWxsZWwgY29uZmlndXJhdGlvbnMsIHRoZXJlIGFyZSBvdGhl ciBjb250cm9sbGVycyBmcm9tIAo+IE1pY3JvY2hpcCBhbmQgc29tZSBmbGFzaCBkZXZpY2VzIHRo YXQgb3BlcmF0ZSBzaW1pbGFybHkgdG8gQU1EJ3MgcGFyYWxsZWwgCj4gbW9kZS4KClllcywgVHVk b3IgcmVtaW5kZWQgbWUgYWJvdXQgdGhlc2UuCgo+ID4gPiBUaGlzIGxheWVyIHdvdWxkIHBlcmZv cm0gdGhlIGZvbGxvd2luZyB0YXNrczoKPiA+ID4gIC0gRHVyaW5nIHByb2JpbmcsIHN0b3JlIGlu Zm9ybWF0aW9uIGZyb20gYWxsIHRoZSBjb25uZWN0ZWQgZmxhc2hlcywKPiA+ID4gICAgd2hldGhl ciBpbiBzdGFja2VkIG9yIHBhcmFsbGVsIG1vZGUsIGFuZCBwcmVzZW50IGl0IGFzIGEgc2luZ2xl IGRldmljZQo+ID4gPiAgICB0byB0aGUgTVREIGxheWVyLgo+ID4gPiAgLSBSZWdpc3RlciBjYWxs YmFja3MgdGhyb3VnaCB0aGlzIG5ldyBsYXllciBpbnN0ZWFkIG9mIHNwaS1ub3IvY29yZS5jIGFu ZAo+ID4gPiAgICBoYW5kbGUgTVREIGRldmljZSByZWdpc3RyYXRpb24uCj4gPiA+ICAtIEluIHN0 YWNrZWQgbW9kZSwgc2VsZWN0IHRoZSBhcHByb3ByaWF0ZSBzcGktbm9yIGZsYXNoIGJhc2VkIG9u IHRoZQo+ID4gPiAgICBhZGRyZXNzIHByb3ZpZGVkIGJ5IHRoZSBNVEQgbGF5ZXIgZHVyaW5nIGZs YXNoIG9wZXJhdGlvbnMuCj4gPiA+ICAtIE1hbmFnZSBmbGFzaCBjcm9zc292ZXIgb3BlcmF0aW9u cyBpbiBzdGFja2VkIG1vZGUuCj4gPiA+ICAtIEVuc3VyZSBib3RoIGNvbm5lY3RlZCBmbGFzaGVz IGFyZSBpZGVudGljYWwgaW4gcGFyYWxsZWwgbW9kZS4KPiA+ID4gIC0gSGFuZGxlIG9kZCBieXRl IGNvdW50IHJlcXVlc3RzIGZyb20gdGhlIE1URCBsYXllciBkdXJpbmcgZmxhc2gKPiA+ID4gICAg b3BlcmF0aW9ucyBpbiBwYXJhbGxlbCBtb2RlLgo+ID4gPgo+ID4gPiBGb3IgaW1wbGVtZW50aW5n IHRoaXMgdGhlIGN1cnJlbnQgRFQgYmluZGluZyBuZWVkIHRvIGJlIHVwZGF0ZWQgYXMKPiA+ID4g Zm9sbG93cy4gIAo+ID4gCj4gPiBTbyB5b3Ugd2FudCB0byBnbyBiYWNrIHRvIHN0ZXAgMSBhbmQg cmVkZWZpbmUgYmluZGluZ3M/IElzIHRoYXQgd29ydGg/ICAKPiAKPiBUaGUgY3VycmVudCBiaW5k aW5ncyBhcmUgZWZmZWN0aXZlIGlmIHdlIG9ubHkgc3VwcG9ydCBpZGVudGljYWwgCj4gZmxhc2gg ZGV2aWNlcyBvciBmbGFzaGVzIG9mIHRoZSBzYW1lIG1ha2UgYnV0IHdpdGggZGlmZmVyZW50IHNp emVzIAo+IGNvbm5lY3RlZCBpbiBzdGFja2VkIG1vZGUuIEhvd2V2ZXIsIGlmIHdlIHdhbnQgdG8g ZXh0ZW5kIHN0YWNrZWQgc3VwcG9ydCAKPiB0byBpbmNsdWRlIGZsYXNoZXMgb2YgZGlmZmVyZW50 IG1ha2VzIGluIHN0YWNrZWQgbW9kZSwKClRoZSBvbmx5IGFjdHVhbCBmZWF0dXJlIHRoZSBzdGFj a2VkIG1vZGUgYnJpbmdzIGlzIHRoZSBhYmlsaXR5IHRvCmNvbnNpZGVyIHR3byBkZXZpY2VzIGxp a2Ugb25lLiBUaGlzIGlzIGFic3RyYWN0ZWQgYnkgaGFyZHdhcmUsIHRoaXMgaXMKYSBjb250cm9s bGVyIGNhcGFiaWxpdHkuIFRoZSBvbmx5IHdheSB0aGlzIGNhbiB3b3JrIGlzIGlmIHRoZSB0d28K c3RvcmFnZSBkZXZpY2VzIGFyZSBvZiB0aGUgc2FtZSBraW5kIGFuZCBhY2NlcHQgdGhlIHNhbWUg Y29tbWFuZHMvaW5pdApjeWNsZXMuCgpJZiB5b3UgY29uc2lkZXIgdHdvIGRpZmZlcmVudCBkZXZp Y2VzLCB0aGVuIHRoZXJlIGlzIG5vIGhhcmR3YXJlCmFic3RyYWN0aW9uIGFueW1vcmUsIHRoZSBj b250cm9sbGVyIGlzIG5vIGxvbmdlciAic21hcnQiIGVub3VnaCBhbmQgeW91CmFyZSBiYWNrIHRv IHRoZSBzdGFuZGFyZCBzaXR1YXRpb24gd2l0aCB0d28gZGV2aWNlcyBjb25uZWN0ZWQgdXNpbmcK dGhlaXIgb3duIGluZGVwZW5kZW50IENTLCBrbm93biBieSB0aGUgaG9zdC4gSW4gdGhpcyBjYXNl IHRoZQoic3RhY2tlZC1tb2RlIiBiaW5kaW5ncyBubyBsb25nZXIgYXBwbHkuIFlvdSBuZWVkIHRv IGRlc2NyaWJlIHRoZSB0d28KY2hpcHMgaW5kZXBlbmRlbnRseSBpbiB0aGUgRFQsIGFuZCB5b3Vy IHN0YWNrZWQgZmVhdHVyZSBpbiB0aGUKY29udHJvbGxlciBjYW4gbm8gbG9uZ2VyIGJlIHVzZWQu CgpZb3UgbmVlZCBvdGhlciBiaW5kaW5ncyB0byBzdXBwb3J0IHRoaXMgY2FzZSBiZWNhdXNlIGl0 IGlzIGEgZGlmZmVyZW50CnNpdHVhdGlvbi4gRm9yIHRoaXMgY2FzZSwgdGhlcmUgd2FzIGEgbXRk LWNvbmNhdCBhcHByb2FjaCAod2hpY2ggd2FzCm5ldmVyIG1lcmdlZCkuIEJ1dCB0aGlzIGlzIHJl YWxseSBzb21ldGhpbmcgZGlmZmVyZW50IHRoYW4gdGhlIHN0YWNrZWQKbW9kZSBpbiB5b3VyIGNv bnRyb2xsZXIgYmVjYXVzZSB0aGVyZSBpcyBubyBzcGVjaWZpYyBoYXJkd2FyZSBmZWF0dXJlCmlu dm9sdmVkLCBpdCdzIGp1c3QgcHVyZSBzb2Z0d2FyZS4KCj4gdGhlIGN1cnJlbnQgCj4gYmluZGlu Z3MgbWF5IG5vdCBiZSBhZGVxdWF0ZS4gVGhhdCdzIHdoeSBJIHN1Z2dlc3RlZCB1cGRhdGluZyB0 aGUgYmluZGluZ3MgCj4gdG8gYWNjb21tb2RhdGUgYWxsIHBvc3NpYmxlIHNjZW5hcmlvLgo+IAo+ ID4gICAKPiA+ID4gc3RhY2tlZC1tZW1vcmllcyBEVCBjaGFuZ2VzOgo+ID4gPiAgLSBGbGFzaCBz aXplIGluZm9ybWF0aW9uIGNhbiBiZSByZXRyaWV2ZWQgZGlyZWN0bHkgZnJvbSB0aGUgZmxhc2gs IHNvIGl0Cj4gPiA+ICAgIGhhcyBiZWVuIHJlbW92ZWQgZnJvbSB0aGUgRFQgYmluZGluZy4KPiA+ ID4gIC0gRWFjaCBzdGFja2VkIGZsYXNoIHdpbGwgaGF2ZSBpdHMgb3duIGZsYXNoIG5vZGUuIFRo aXMgYXBwcm9hY2ggYWxsb3dzCj4gPiA+ICAgIGZsYXNoZXMgb2YgZGlmZmVyZW50IG1ha2VzIGFu ZCBzaXplcyB0byBiZSBzdGFja2VkIHRvZ2V0aGVyLCBhcyBlYWNoCj4gPiA+ICAgIGZsYXNoIHdp bGwgYmUgcHJvYmVkIGluZGl2aWR1YWxseS4gIAo+ID4gCj4gPiBBbmQgaG93IHdpbGwgeW91IGRl ZmluZSBwYXJ0aXRpb25zIGNyb3NzaW5nIGRldmljZSBib3VuZGFyaWVzPyBJIGJlbGlldmUgdGhp cwo+ID4gY29uc3RyYWludCBoYXMgYmVlbiB0b3RhbGx5IGZvcmdvdHRlbiBpbiB0aGlzIHByb3Bv c2FsLiAgCj4gCj4gQWNjb3JkaW5nIHRvIHRoZSBuZXcgYmluZGluZyBwcm9wb3NhbCwgb25lIG9m IHRoZSB0d28gZmxhc2ggbm9kZXMgd2lsbCAKPiBoYXZlIGEgcGFydGl0aW9uIHRoYXQgY3Jvc3Nl cyB0aGUgZGV2aWNlIGJvdW5kYXJ5LgoKRnJvbSBhIGJpbmRpbmdzIHBlcnNwZWN0aXZlLCBpdCBm ZWVscyB2ZXJ5IGF3a3dhcmQgYW5kIEkgZG91YnQgaXQgd2lsbApiZSBhY2NlcHRlZC4gRnJvbSBh IGNvZGUgcGVyc3BlY3RpdmUsIHlvdSdyZSBnb25uYSBuZWVkIHRvIGJ1dGNoZXIgdGhlCmNvcmUu Li4KCj4gPiBUaGUgd2hvbGUgaWRlYSBvZiBzdGFja2luZyB0d28gZGV2aWNlcyB0aGlzIHdheSB3 YXMgdG8gc2ltcGxpZnkgdGhlIHVzZXIncyBsaWZlCj4gPiB3aXRoIGEgc2luZ2xlIGRldmljZSBl eHBvc2VkIGFuZCB0aGUgY29udHJvbGxlciBoYW5kbGluZyBpdHNlbGYgdGhlIENTIGNoYW5nZXMu Cj4gPiBUaGF0IGlzIHByZWNpc2VseSB3aGF0IHRoZSBjdXJyZW50IGJpbmRpbmcgZG8uICAKPiAK PiBUaGF0J3MgdHJ1ZSwgYnV0IGFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIGlmIHdlJ3JlIG5vdCBp bmNsaW5lZCB0byBzdXBwb3J0IAo+IHN0YWNrZWQgbW9kZSBmb3IgZmxhc2hlcyBvZiBkaWZmZXJl bnQgbWFrZXMsIHRoZW4gdGhlIGN1cnJlbnQgYmluZGluZ3MgCj4gYXJlIHN1ZmZpY2llbnQuCgpU aGFua3MsCk1pcXXDqGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpMaW51eCBNVEQgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QKaHR0cDovL2xp c3RzLmluZnJhZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1tdGQvCg== 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 C5F31C3DA4A for ; Wed, 14 Aug 2024 10:00:51 +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=ucah7eJHaaeq3ephNaG8kgL8jqU515QWycrDeI4W32U=; b=ASIvjFT4MKgj3o ZA3WMgycmpVIjNvXYN0vSbMtH14i+P9pc6vF6WHkIvr6s7c7IcBu1a0+zO9AvmWfIn42DwAm1I5aY ZSdEHnEUZyFRXXrg2S7Uprt7WRgQRwcJ7J0jrodnhr4JsJS0Lx1Gs4HrRNtShNayiMHjndZKIyODk iEfaMWdOz3lDfrwT0+hhTfAqWNCtYfIQqqPQvutMKE6Yvmh88aI4s9ld+JtCn7Ge8rraGLotSqe/A y+QyadpzO8t5H3WYrXXGgql0fSiZdwdPyxr5bPeMKzRBH7sl4zOwlfRL2K8m3WVpHkjeRdar/Bo9E WKaXKa5DSvn+Prg9JMQg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seAo6-00000006U2q-02r9; Wed, 14 Aug 2024 10:00:42 +0000 Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1se9eJ-00000006Gc2-1kcz; Wed, 14 Aug 2024 08:46:33 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 7A91E240002; Wed, 14 Aug 2024 08:46:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723625187; 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=ucah7eJHaaeq3ephNaG8kgL8jqU515QWycrDeI4W32U=; b=FdsiK+vFzIxzAqPbfc+zcpWwxzSkeu0QWaWCCAjEbz0ECS+4Gop5b9iMy9KvidVfzrT8YS R3glCu3H/fqGqqli0J7bcQs1w03PBRnmCapSt56E9eryaNugOsi1PeVvaPMZvrGAhfIkSu /t4pALdm08hT/0XNHlcrmjKN0EZBCdXNgFQPpp1Z0aEC9SrkAFKSLnmVn9py1QCfRHIjnT 2sHSq8VKWfcCkSJJEP/ynJ4bZVshyjwgQhXFQlj4veogBmCtfuNurSeoBV7fWvqLvn4VxT XCZP930UGMK7PVedVe/wN8EbyAnhDkfoixyA+y09If7Os0pmm1Gwux56yiPboQ== Date: Wed, 14 Aug 2024 10:46:23 +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: <20240814104623.72eef495@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> <20240812103812.72763f69@xps-13> 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-20240814_014631_770799_09E0098D X-CRM114-Status: GOOD ( 36.30 ) 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 Amit, amit.kumar-mahapatra@amd.com wrote on Wed, 14 Aug 2024 07:13:35 +0000: > Hello Miquel, >=20 > > > Based on the inputs/suggestions from Tudor, i am planning to add a new > > > layer between the SPI-NOR and MTD layers to support stacked and > > > parallel configurations. This new layer will be part of the spi-nor > > > and located in mtd/spi-nor/ =20 > >=20 > > For now I don't think you need a totally generic implementation. As lon= g as > > there is only one controller supporting these modes, I'd say this is no= t super > > relevant. =20 >=20 > IMHO, there should be a general solution since this isn't limited to just= =20 > one controller. Any controller can support stacked mode with multiple=20 > native-cs or multiple gpio-cs, or with a combination of a native-cs and a= =20 > gpio-cs. That's not what was initially discussed. The Xilinx use case was: a controller is managing two devices "at the same time" transparently from the host. So the two flashes appear like a single one and thus, are described like a single one. You don't need anything in the bindings nor in the core to manage two flashes connected to the same controller otherwise. The only use case the Xilinx model was bringing, was to consider the storage bigger from a host perspective and thus be able to store files across the device boundary natively. > For parallel configurations, there are other controllers from=20 > Microchip and some flash devices that operate similarly to AMD's parallel= =20 > mode. Yes, Tudor reminded me about these. > > > This layer would perform the following tasks: > > > - During probing, store information from all the connected flashes, > > > whether in stacked or parallel mode, and present it as a single de= vice > > > to the MTD layer. > > > - Register callbacks through this new layer instead of spi-nor/core.= c and > > > handle MTD device registration. > > > - In stacked mode, select the appropriate spi-nor flash based on the > > > 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 > > > operations in parallel mode. > > > > > > For implementing this the current DT binding need to be updated as > > > follows. =20 > >=20 > > So you want to go back to step 1 and redefine bindings? Is that worth? = =20 >=20 > The current bindings are effective if we only support identical=20 > flash devices or flashes of the same make but with different sizes=20 > connected in stacked mode. However, if we want to extend stacked support= =20 > to include flashes of different makes in stacked mode, The only actual feature the stacked mode brings is the ability to consider two devices like one. This is abstracted by hardware, this is a controller capability. The only way this can work is if the two storage devices are of the same kind and accept the same commands/init cycles. If you consider two different devices, then there is no hardware abstraction anymore, the controller is no longer "smart" enough and you are back to the standard situation with two devices connected using their own independent CS, known by the host. In this case the "stacked-mode" bindings no longer apply. You need to describe the two chips independently in the DT, and your stacked feature in the controller can no longer be used. You need other bindings to support this case because it is a different situation. For this case, there was a mtd-concat approach (which was never merged). But this is really something different than the stacked mode in your controller because there is no specific hardware feature involved, it's just pure software. > the current=20 > bindings may not be adequate. That's why I suggested updating the binding= s=20 > to accommodate all possible scenario. >=20 > > =20 > > > stacked-memories DT changes: > > > - Flash size information can be retrieved directly from the flash, s= o it > > > has been removed from the DT binding. > > > - Each stacked flash will have its own flash node. This approach all= ows > > > flashes of different makes and sizes to be stacked together, as ea= ch > > > flash will be probed individually. =20 > >=20 > > And how will you define partitions crossing device boundaries? I believ= e this > > constraint has been totally forgotten in this proposal. =20 >=20 > According to the new binding proposal, one of the two flash nodes will=20 > have a partition that crosses the device boundary. =46rom a bindings perspective, it feels very awkward and I doubt it will be accepted. From a code perspective, you're gonna need to butcher the core... > > The whole idea of stacking two devices this way was to simplify the use= r's life > > with a single device exposed and the controller handling itself the CS = changes. > > That is precisely what the current binding do. =20 >=20 > That's true, but as I mentioned earlier, if we're not inclined to support= =20 > stacked mode for flashes of different makes, then the current bindings=20 > are sufficient. Thanks, Miqu=C3=A8l