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 D3091CF649D for ; Mon, 30 Sep 2024 09:04:55 +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 D7DED1948; Mon, 30 Sep 2024 11:04:43 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D7DED1948 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1727687093; bh=5vfmCoWhJfN9myIJ8um04DTZKKRCmBeNbBVzguOQXMk=; 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=rYZmVzW6cur0McxyTXkCZZQix9UlCKdT38hiUWYoTFFMUgN76/YzG8LmdYt/C1YiC dsBWST5BZERnxIqJI8GwRo4InnZOnUQ+vaHCMNMbfN9Kh62L3CevmkyWpDVkkL7Ef9 WLCuXq6MgoLIpPwLcW2sV3OroB4hd0JSZv0SQIBQ= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 84446F805AD; Mon, 30 Sep 2024 11:04:22 +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 CC183F805B5; Mon, 30 Sep 2024 11:04:21 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 825B1F80508; Mon, 30 Sep 2024 11:04:18 +0200 (CEST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8BCC5F80007 for ; Mon, 30 Sep 2024 11:04:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 8BCC5F80007 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=oopwFy97 Received: by mail.gandi.net (Postfix) with ESMTPSA id 29C2D40009; Mon, 30 Sep 2024 09:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1727687053; 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=I/Yd74SXWwnJNHzkH+B1zGDPYPSWPzutmB3r6NlN8+k=; b=oopwFy97Xs7m4K3UfEGC1hiSSNHKTDyWZt9dJs73tB3PhVekjYUwWjFTpXxO9rhGuwRcmO 7EY460BtJoyBI+PszIgN0UqnD7FmeuGdO66U/wzlSL49YKAnVFWxzKZQqg5GViNphID+YS GoW6P4MpEYAGoSwerOwunKoJeKsq5S7j+qpOV5xD/FKvGAzX4OMK2gx61LXZ8CWjDIOEXS +7H8X+m6td/vhZ38an6ytEtNTgQNe8GqLcq3hxsAfAS0En8/N59vH5/z446z+0K/TdOA5Y riEwwRZm+c++1OUJ0NH0ycTAbZzXXGCnsAHUqCs6sQ6pgE8FYRgGMxIkB8Voig== Date: Mon, 30 Sep 2024 11:04:08 +0200 From: Miquel Raynal To: "Mahapatra, Amit Kumar" Cc: Tudor Ambarus , "michael@walle.cc" , "broonie@kernel.org" , "pratyush@kernel.org" , "richard@nod.at" , "vigneshr@ti.com" , Rob Herring , "cornor+dt@kernel.org" , "krzk+dt@kernel.org" , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "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: Add stacked and parallel memories support in spi-nor Message-ID: <20240930110408.6ec43e97@xps-13> In-Reply-To: References: 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: 4I6RNOQPLDF565UAAOBRYDNMG4PG6O6I X-Message-ID-Hash: 4I6RNOQPLDF565UAAOBRYDNMG4PG6O6I 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, > For implementing this the current DT binding[1] [2] [3] need to be update= d as follows. >=20 >=20 >=20 > stacked-memories DT changes: >=20 > - Flash size information can be retrieved directly from the flash, so it = has been removed from the DT binding. >=20 > - Each stacked flash will have its own flash node. This approach allows f= lashes of different makes and sizes to be stacked together, as each flash w= ill be probed individually. >=20 > - Each of the flash node will have its own "reg" property that will cont= ain its physical CS. These three first points are just describing the existing bindings for non-concatenated situations. > - The stacked-memories DT bindings will contain the phandles of the flash= nodes connected in stacked mode. >=20 > - The first flash node will contain the mtd partition that would have the= cross over memory staring at a memory location in the first flash and endi= ng at some memory location of the 2nd flash I don't like that much. Describing partitions past the actual device sounds wrong. If you look into [1] there is a suggestion from Rob to handle this case using a property that tells us there is a continuation, so from a software perspective we can easily make the link, but on the hardware description side the information are correct. If this description is accepted, then fine, you can deprecate the=20 "stacked-memories" property. > - The new layer will update the mtd->size and other mtd_info parameters = after both the flashes are probed and will call mtd_device_register with th= e combined information. Okay, this is back to the mtd-concat thing I initially proposed, but I believe it can work. [...] > parallel-memories DT changes: >=20 > - Flash size information can be retrieved directly from the flash, so it = has been removed from the DT binding. It's not really about the size but more about the fact that two memories are in use. If the stacked situation does not require anything specific besides the partitions trick, then you can assume that double reg flashes are just two flashes and this can be your way to discriminate the data organization. But I don't like much this shortcut because it is not future proof, and instead I'd keep the stacked-memory property. If you don't like the size, I don't really care, just use it as a boolean. But I believe we need some naming to tell the OS that the data is spread in a specific way inside the memory devices. > - Each flash connected in parallel mode should be identical and will have= one flash node for both the flash devices. This is already the case. > - The "reg" prop will contain the physical CS number for both the connect= ed flashes. This is already the case. > - The new layer will double the mtd-> size and register it with the mtd l= ayer. This is not a DT change. 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 A975ACF6497 for ; Mon, 30 Sep 2024 09:05:41 +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=oNaYTD6jjsBu+fnW19Ef7UIcAUS3MXiXqG/b/f5nKPM=; b=W5TA0XOwgPVKyi laJsnNqtXJpn/uYCs6xGe84qxZzSmQvcWygMKXiVA8cBR9fWswSGUxHc9ypSmqGfiw3wrDHJQR+Ih 8pc30J/zIlVrDjkEMyEa7RNA0SAAGO2kW+XFrhN9QPKc0SxJitEe070BBlg0b16Nm/mjlYkSKH08u upaFUGqHsWwH7NkK7h+oxsv0fk+TucH/CIPiKmZzjrpeKcSzZUgevqBsiRijcuIHA4HeLeGCRscPZ ILzfGR+QLjS7dD/QBE9I7LVjuP5lDNAioB1dkChgF4JtJlusx+tMz9aRD22m+n29haZ2QXnHXZeml MaGg33NtwjwUk+YLV3+A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1svCLX-0000000GRFP-0N4B; Mon, 30 Sep 2024 09:05:35 +0000 Received: from relay2-d.mail.gandi.net ([2001:4b98:dc4:8::222]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1svCKH-0000000GQyY-0Iyg; Mon, 30 Sep 2024 09:04:18 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 29C2D40009; Mon, 30 Sep 2024 09:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1727687053; 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=I/Yd74SXWwnJNHzkH+B1zGDPYPSWPzutmB3r6NlN8+k=; b=oopwFy97Xs7m4K3UfEGC1hiSSNHKTDyWZt9dJs73tB3PhVekjYUwWjFTpXxO9rhGuwRcmO 7EY460BtJoyBI+PszIgN0UqnD7FmeuGdO66U/wzlSL49YKAnVFWxzKZQqg5GViNphID+YS GoW6P4MpEYAGoSwerOwunKoJeKsq5S7j+qpOV5xD/FKvGAzX4OMK2gx61LXZ8CWjDIOEXS +7H8X+m6td/vhZ38an6ytEtNTgQNe8GqLcq3hxsAfAS0En8/N59vH5/z446z+0K/TdOA5Y riEwwRZm+c++1OUJ0NH0ycTAbZzXXGCnsAHUqCs6sQ6pgE8FYRgGMxIkB8Voig== Date: Mon, 30 Sep 2024 11:04:08 +0200 From: Miquel Raynal To: "Mahapatra, Amit Kumar" Cc: Tudor Ambarus , "michael@walle.cc" , "broonie@kernel.org" , "pratyush@kernel.org" , "richard@nod.at" , "vigneshr@ti.com" , Rob Herring , "cornor+dt@kernel.org" , "krzk+dt@kernel.org" , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "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: Add stacked and parallel memories support in spi-nor Message-ID: <20240930110408.6ec43e97@xps-13> In-Reply-To: References: 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-20240930_020417_731408_198A9AA5 X-CRM114-Status: GOOD ( 20.70 ) 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 SGkgQW1pdCwKCj4gRm9yIGltcGxlbWVudGluZyB0aGlzIHRoZSBjdXJyZW50IERUIGJpbmRpbmdb MV0gWzJdIFszXSBuZWVkIHRvIGJlIHVwZGF0ZWQgYXMgZm9sbG93cy4KPiAKPiAKPiAKPiBzdGFj a2VkLW1lbW9yaWVzIERUIGNoYW5nZXM6Cj4gCj4gLSBGbGFzaCBzaXplIGluZm9ybWF0aW9uIGNh biBiZSByZXRyaWV2ZWQgZGlyZWN0bHkgZnJvbSB0aGUgZmxhc2gsIHNvIGl0IGhhcyBiZWVuIHJl bW92ZWQgZnJvbSB0aGUgRFQgYmluZGluZy4KPiAKPiAtIEVhY2ggc3RhY2tlZCBmbGFzaCB3aWxs IGhhdmUgaXRzIG93biBmbGFzaCBub2RlLiBUaGlzIGFwcHJvYWNoIGFsbG93cyBmbGFzaGVzIG9m IGRpZmZlcmVudCBtYWtlcyBhbmQgc2l6ZXMgdG8gYmUgc3RhY2tlZCB0b2dldGhlciwgYXMgZWFj aCBmbGFzaCB3aWxsIGJlIHByb2JlZCBpbmRpdmlkdWFsbHkuCj4gCj4gLSAgRWFjaCBvZiB0aGUg Zmxhc2ggbm9kZSB3aWxsIGhhdmUgaXRzIG93biAicmVnIiBwcm9wZXJ0eSB0aGF0IHdpbGwgY29u dGFpbiBpdHMgcGh5c2ljYWwgQ1MuCgpUaGVzZSB0aHJlZSBmaXJzdCBwb2ludHMgYXJlIGp1c3Qg ZGVzY3JpYmluZyB0aGUgZXhpc3RpbmcgYmluZGluZ3MgZm9yCm5vbi1jb25jYXRlbmF0ZWQgc2l0 dWF0aW9ucy4KCj4gLSBUaGUgc3RhY2tlZC1tZW1vcmllcyBEVCBiaW5kaW5ncyB3aWxsIGNvbnRh aW4gdGhlIHBoYW5kbGVzIG9mIHRoZSBmbGFzaCBub2RlcyBjb25uZWN0ZWQgaW4gc3RhY2tlZCBt b2RlLgo+IAo+IC0gVGhlIGZpcnN0IGZsYXNoIG5vZGUgd2lsbCBjb250YWluIHRoZSBtdGQgcGFy dGl0aW9uIHRoYXQgd291bGQgaGF2ZSB0aGUgY3Jvc3Mgb3ZlciBtZW1vcnkgc3RhcmluZyBhdCBh IG1lbW9yeSBsb2NhdGlvbiBpbiB0aGUgZmlyc3QgZmxhc2ggYW5kIGVuZGluZyBhdCBzb21lIG1l bW9yeSBsb2NhdGlvbiBvZiB0aGUgMm5kIGZsYXNoCgpJIGRvbid0IGxpa2UgdGhhdCBtdWNoLiBE ZXNjcmliaW5nIHBhcnRpdGlvbnMgcGFzdCB0aGUgYWN0dWFsIGRldmljZQpzb3VuZHMgd3Jvbmcu IElmIHlvdSBsb29rIGludG8gWzFdIHRoZXJlIGlzIGEgc3VnZ2VzdGlvbiBmcm9tIFJvYiB0bwpo YW5kbGUgdGhpcyBjYXNlIHVzaW5nIGEgcHJvcGVydHkgdGhhdCB0ZWxscyB1cyB0aGVyZSBpcyBh CmNvbnRpbnVhdGlvbiwgc28gZnJvbSBhIHNvZnR3YXJlIHBlcnNwZWN0aXZlIHdlIGNhbiBlYXNp bHkgbWFrZSB0aGUKbGluaywgYnV0IG9uIHRoZSBoYXJkd2FyZSBkZXNjcmlwdGlvbiBzaWRlIHRo ZSBpbmZvcm1hdGlvbiBhcmUgY29ycmVjdC4KCklmIHRoaXMgZGVzY3JpcHRpb24gaXMgYWNjZXB0 ZWQsIHRoZW4gZmluZSwgeW91IGNhbiBkZXByZWNhdGUgdGhlIAoic3RhY2tlZC1tZW1vcmllcyIg cHJvcGVydHkuCgo+ICAtIFRoZSBuZXcgbGF5ZXIgd2lsbCB1cGRhdGUgdGhlIG10ZC0+c2l6ZSBh bmQgb3RoZXIgbXRkX2luZm8gcGFyYW1ldGVycyBhZnRlciBib3RoIHRoZSBmbGFzaGVzIGFyZSBw cm9iZWQgYW5kIHdpbGwgY2FsbCBtdGRfZGV2aWNlX3JlZ2lzdGVyIHdpdGggdGhlIGNvbWJpbmVk IGluZm9ybWF0aW9uLgoKT2theSwgdGhpcyBpcyBiYWNrIHRvIHRoZSBtdGQtY29uY2F0IHRoaW5n IEkgaW5pdGlhbGx5IHByb3Bvc2VkLCBidXQgSQpiZWxpZXZlIGl0IGNhbiB3b3JrLgoKWy4uLl0K Cj4gcGFyYWxsZWwtbWVtb3JpZXMgRFQgY2hhbmdlczoKPiAKPiAtIEZsYXNoIHNpemUgaW5mb3Jt YXRpb24gY2FuIGJlIHJldHJpZXZlZCBkaXJlY3RseSBmcm9tIHRoZSBmbGFzaCwgc28gaXQgaGFz IGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBEVCBiaW5kaW5nLgoKSXQncyBub3QgcmVhbGx5IGFib3V0 IHRoZSBzaXplIGJ1dCBtb3JlIGFib3V0IHRoZSBmYWN0IHRoYXQgdHdvCm1lbW9yaWVzIGFyZSBp biB1c2UuIElmIHRoZSBzdGFja2VkIHNpdHVhdGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueXRoaW5n CnNwZWNpZmljIGJlc2lkZXMgdGhlIHBhcnRpdGlvbnMgdHJpY2ssIHRoZW4geW91IGNhbiBhc3N1 bWUgdGhhdCBkb3VibGUKcmVnIGZsYXNoZXMgYXJlIGp1c3QgdHdvIGZsYXNoZXMgYW5kIHRoaXMg Y2FuIGJlIHlvdXIgd2F5IHRvCmRpc2NyaW1pbmF0ZSB0aGUgZGF0YSBvcmdhbml6YXRpb24uIEJ1 dCBJIGRvbid0IGxpa2UgbXVjaCB0aGlzIHNob3J0Y3V0CmJlY2F1c2UgaXQgaXMgbm90IGZ1dHVy ZSBwcm9vZiwgYW5kIGluc3RlYWQgSSdkIGtlZXAgdGhlIHN0YWNrZWQtbWVtb3J5CnByb3BlcnR5 LiBJZiB5b3UgZG9uJ3QgbGlrZSB0aGUgc2l6ZSwgSSBkb24ndCByZWFsbHkgY2FyZSwganVzdCB1 c2UgaXQKYXMgYSBib29sZWFuLiBCdXQgSSBiZWxpZXZlIHdlIG5lZWQgc29tZSBuYW1pbmcgdG8g dGVsbCB0aGUgT1MgdGhhdCB0aGUKZGF0YSBpcyBzcHJlYWQgaW4gYSBzcGVjaWZpYyB3YXkgaW5z aWRlIHRoZSBtZW1vcnkgZGV2aWNlcy4KCj4gLSBFYWNoIGZsYXNoIGNvbm5lY3RlZCBpbiBwYXJh bGxlbCBtb2RlIHNob3VsZCBiZSBpZGVudGljYWwgYW5kIHdpbGwgaGF2ZSBvbmUgZmxhc2ggbm9k ZSBmb3IgYm90aCB0aGUgZmxhc2ggZGV2aWNlcy4KClRoaXMgaXMgYWxyZWFkeSB0aGUgY2FzZS4K Cj4gLSBUaGUgInJlZyIgcHJvcCB3aWxsIGNvbnRhaW4gdGhlIHBoeXNpY2FsIENTIG51bWJlciBm b3IgYm90aCB0aGUgY29ubmVjdGVkIGZsYXNoZXMuCgpUaGlzIGlzIGFscmVhZHkgdGhlIGNhc2Uu Cgo+IC0gVGhlIG5ldyBsYXllciB3aWxsIGRvdWJsZSB0aGUgbXRkLT4gc2l6ZSBhbmQgcmVnaXN0 ZXIgaXQgd2l0aCB0aGUgbXRkIGxheWVyLgoKVGhpcyBpcyBub3QgYSBEVCBjaGFuZ2UuCgoKVGhh bmtzLApNaXF1w6hsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0 cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo= 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 0CC76CF649D for ; Mon, 30 Sep 2024 09:05:46 +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=I/Yd74SXWwnJNHzkH+B1zGDPYPSWPzutmB3r6NlN8+k=; b=FkPtSF2qNtjzm2 8x4Ar0WP3rcHQQehr+GMNjK7AYShmO8MKNM9Dp+2VwpHTblWFIVeDDnfTKcfKUilI5+3b9A/c/XP+ gJ5L+J+4nPNVH9zksEnws/wo4nbBsspimUhEp+f++UMWTBZHPNkEN5K1v/zLmlEEAf1HJrYxN0O3V fFRSE0GWajDO1ibgOldv2TQVkN+8cgfwvCEURUv0uCMPKGn8GMM5k9pG0dnxfJdAZtq3DGmpR6ak7 zP3HWv/A/9hIcdgH70XJnrA0vvjcyG0NNiXAeLlwEFvsRzlSUYtiJzx/Y7KhUvkNmjFAoV3/0SN2N DRVW+cvuc3BWN4cxWOsQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1svCLW-0000000GRF9-22wS; Mon, 30 Sep 2024 09:05:34 +0000 Received: from relay2-d.mail.gandi.net ([2001:4b98:dc4:8::222]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1svCKH-0000000GQyY-0Iyg; Mon, 30 Sep 2024 09:04:18 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 29C2D40009; Mon, 30 Sep 2024 09:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1727687053; 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=I/Yd74SXWwnJNHzkH+B1zGDPYPSWPzutmB3r6NlN8+k=; b=oopwFy97Xs7m4K3UfEGC1hiSSNHKTDyWZt9dJs73tB3PhVekjYUwWjFTpXxO9rhGuwRcmO 7EY460BtJoyBI+PszIgN0UqnD7FmeuGdO66U/wzlSL49YKAnVFWxzKZQqg5GViNphID+YS GoW6P4MpEYAGoSwerOwunKoJeKsq5S7j+qpOV5xD/FKvGAzX4OMK2gx61LXZ8CWjDIOEXS +7H8X+m6td/vhZ38an6ytEtNTgQNe8GqLcq3hxsAfAS0En8/N59vH5/z446z+0K/TdOA5Y riEwwRZm+c++1OUJ0NH0ycTAbZzXXGCnsAHUqCs6sQ6pgE8FYRgGMxIkB8Voig== Date: Mon, 30 Sep 2024 11:04:08 +0200 From: Miquel Raynal To: "Mahapatra, Amit Kumar" Subject: Re: Add stacked and parallel memories support in spi-nor Message-ID: <20240930110408.6ec43e97@xps-13> In-Reply-To: References: 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-20240930_020417_731408_198A9AA5 X-CRM114-Status: GOOD ( 20.70 ) 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" , Conor Dooley , "linux-mtd@lists.infradead.org" , "beanhuo@micron.com" , "git \(AMD-Xilinx\)" , Rob Herring , "richard@nod.at" , Tudor Ambarus , "cornor+dt@kernel.org" , "amitrkcian2002@gmail.com" , "linux-sound@vger.kernel.org" , "broonie@kernel.org" , "Simek, Michal" , "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 Hi Amit, > For implementing this the current DT binding[1] [2] [3] need to be update= d as follows. >=20 >=20 >=20 > stacked-memories DT changes: >=20 > - Flash size information can be retrieved directly from the flash, so it = has been removed from the DT binding. >=20 > - Each stacked flash will have its own flash node. This approach allows f= lashes of different makes and sizes to be stacked together, as each flash w= ill be probed individually. >=20 > - Each of the flash node will have its own "reg" property that will cont= ain its physical CS. These three first points are just describing the existing bindings for non-concatenated situations. > - The stacked-memories DT bindings will contain the phandles of the flash= nodes connected in stacked mode. >=20 > - The first flash node will contain the mtd partition that would have the= cross over memory staring at a memory location in the first flash and endi= ng at some memory location of the 2nd flash I don't like that much. Describing partitions past the actual device sounds wrong. If you look into [1] there is a suggestion from Rob to handle this case using a property that tells us there is a continuation, so from a software perspective we can easily make the link, but on the hardware description side the information are correct. If this description is accepted, then fine, you can deprecate the=20 "stacked-memories" property. > - The new layer will update the mtd->size and other mtd_info parameters = after both the flashes are probed and will call mtd_device_register with th= e combined information. Okay, this is back to the mtd-concat thing I initially proposed, but I believe it can work. [...] > parallel-memories DT changes: >=20 > - Flash size information can be retrieved directly from the flash, so it = has been removed from the DT binding. It's not really about the size but more about the fact that two memories are in use. If the stacked situation does not require anything specific besides the partitions trick, then you can assume that double reg flashes are just two flashes and this can be your way to discriminate the data organization. But I don't like much this shortcut because it is not future proof, and instead I'd keep the stacked-memory property. If you don't like the size, I don't really care, just use it as a boolean. But I believe we need some naming to tell the OS that the data is spread in a specific way inside the memory devices. > - Each flash connected in parallel mode should be identical and will have= one flash node for both the flash devices. This is already the case. > - The "reg" prop will contain the physical CS number for both the connect= ed flashes. This is already the case. > - The new layer will double the mtd-> size and register it with the mtd l= ayer. This is not a DT change. Thanks, Miqu=C3=A8l