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