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 B89B6C52D7B for ; Wed, 14 Aug 2024 14:47:40 +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=xDfSsuNrPtx6YX5pobWJTyhNVK0h9n02y4gpLyd5QZ0=; b=0Xm7kTO5Abk7eX +92ae4RoKdAwEGokkYIeWCXad34YHSRVGS3+zEjTogZULowjuKBZynL72H80BfAwsrCMfA61lx/fO cnPLETIIBDU4tJgo+2C3OaA9CJKTJrUobSuvZDSnZdQvoe//rNL2b3fMd144PX5fQOR3Q0SxXTCFv yhS7FhpCeecaTSMxkrJUP9Lo4HIEyQs5kj0cvjVoLUXZKwBnofPRXrjxGJZEaVi0j98ftlUtvfXAY d0eKIcwoxhexMxdTWsbn/VJczHYPmrFyLM9tO1lYyf3Q7AZrvgxcoX0AIUYu1C8szvy9i+K6OioDt XONqDZPXzdj1O6MQtCFw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seFHc-00000007M6B-1ZqC; Wed, 14 Aug 2024 14:47:28 +0000 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seFGy-00000007M1f-0PqA; Wed, 14 Aug 2024 14:46:50 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 620DA240005; Wed, 14 Aug 2024 14:46:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1723646805; 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=xDfSsuNrPtx6YX5pobWJTyhNVK0h9n02y4gpLyd5QZ0=; b=a/65HTTM/Z2uuPVwZKhtoPVKYKAssPIOGi1yJ87QWyxc0Yy9B/HO9r53TlM7SKb4aDZ+/Q W6rJ9e2mF+xR+Jl744Ovws0z1I5cdIq31Vv1pwpD9wLK7HEBFJIpuIWK6Vaq7l0IYBIqV7 4b3HVhC09ke19XLLWgBT/5VwLBJ8J7Oset9eu1j5nL89W/N3sK6iHbvqDSK38O0Ezl39Bi OFCgH/+vOzdJFjrKLhZCp7ZfV0xiV4MPwJkRjCHxESDQtvz8wbMP5qBNdtgqN719/o5xpQ eg3SAKUv5Kfqp+R+i9NkVYRsaGc0wZCqzTMUSS2knl3fnKuXGO3BFN+Hl++fEQ== Date: Wed, 14 Aug 2024 16:46:42 +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: <20240814164642.24705f18@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> <20240814104623.72eef495@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_074648_422244_6BE182CA X-CRM114-Status: GOOD ( 20.87 ) 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, > > > > > For implementing this the current DT binding need to be updated as > > > > > follows. =20 > > > > > > > > So you want to go back to step 1 and redefine bindings? Is that wor= th? =20 > > > > > > The current bindings are effective if we only support identical flash > > > devices or flashes of the same make but with different sizes connected > > > in stacked mode. However, if we want to extend stacked support to > > > include flashes of different makes in stacked mode, =20 > >=20 > > The only actual feature the stacked mode brings is the ability to consi= der two > > devices like one. This is abstracted by hardware, this is a controller = capability. =20 >=20 > Stacked mode is a software abstraction rather than a controller feature o= r=20 > capability. At any given time, the controller communicates with one of th= e=20 > two connected flash devices, as determined by the requested address and d= ata=20 > length. If an operation starts on one flash and ends on the other, the co= re=20 > needs to split it into two separate operations and adjust the data length= =20 > accordingly. I'm sorry, that was not my understanding, cf the initial RFC: Subject: [RFC PATCH 0/3] Dual stacked/parallel memories bindings Date: Fri, 12 Nov 2021 16:24:08 +0100 "[...] supporting specific SPI controller modes like Xilinx's where the controller can highly abstract the hardware and provide access to a single bigger device instead [...]" Furthermore, I rapidly checked the Zynq7000 TRM, it suggests that the controller is capable of addressing the right memory itself based on the address, especially in linear mode?=20 https://docs.amd.com/r/en-US/ug585-zynq-7000-SoC-TRM/Dual-SS-4-bit-Stacked= -I/O "The lower SPI flash memory should always be connected if the linear Quad-SPI memory subsystem is used, and the upper flash memory is optional. Total address space is 32 MB with a 25-bit address. In IO mode, the MSB of the address is defined by U_PAGE which is located at bit 28 of register 0xA0 . In Linear address mode, AXI address bit 24 determines the upper or lower memory page. All of the commands will be executed by the device selected by U_PAGE in I/O mode and address bit 24 in linear mode." Anyway, you may decide to go down the "pure software" route, which is probably easier from an implementation perspective, but means you're gonna have to argue -again- in favor of the representation of a purely virtual device that is not hardware. Cheers, Miqu=C3=A8l