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 (unknown [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 EF1B4C3DA4A for ; Mon, 5 Aug 2024 08:15:58 +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 380045EC3; Mon, 5 Aug 2024 10:15:41 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 380045EC3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1722845751; bh=xLwAL30HsUazONbAdeyL6SW7m8LuRtuI1JpFRvYHPkI=; h=Date:Cc:From:To:Subject:References:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=lTl+C9v8W1s3jXL0w2HzaPTTOarXd/8JZM3TJKnQ0zAR68UhDJ1KNQDBgpddWL3KD iJJhDwAdPKAfFFkKS7ZI/ob8KvTm1w/H9jr+x9sVJIIbiayGQgViEzramZWP5jK1gr BmVYnOXkd+UzVTQ/xtBRqifxqR6iUr6oTdnJrHw8= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 6F0CEF80588; Mon, 5 Aug 2024 10:15:19 +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 BEBF8F800BF; Mon, 5 Aug 2024 10:15:18 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 068ABF802DB; Mon, 5 Aug 2024 10:15:06 +0200 (CEST) Received: from mail.3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (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 3FACCF800E3 for ; Mon, 5 Aug 2024 10:14:58 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 3FACCF800E3 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=walle.cc header.i=@walle.cc header.a=rsa-sha256 header.s=mail2022082101 header.b=gGs8eCs0 Received: from localhost (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id B62FE112; Mon, 5 Aug 2024 10:14:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1722845698; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type:in-reply-to:in-reply-to: references:references; bh=5BjVyMLlxUNN9B+c+TnMQJMAi/0kH47F+XpZ7pZB+aY=; b=gGs8eCs06i5Bm0tao3zgmqnXZxRLfAVT9HCBeDdXP8vkxsjJE4j5FvUAbG369KAyjIHMT8 BYZmNMlnsOqH+DonAHT8TCoFTn+Ra08pncLMz1OTv1uLPM7iP8q58ioWfZS7UpuTGeQ3T3 dYTsDbzQzDlyjGGm4sqcAKDvGrsDWKnxE07Cje6GwTMwkYLQSieOKz9CWFpbT/+triyUps rcIAWsgWxg2rUaNBaNq+9zJgga+ZnL/xnA9jBKiHW/EbNNCUl4MiK99L+TOkg1Xaf7KGlq tm6wsSKL4cmLtNuXDq1VL+0txgqm/iXXj0O1yC1hOz5JTu7pYr9KsdAJli+GQg== Content-Type: multipart/signed; boundary=7dd7e4000aaf39ea05868ee56141ae02e60c588dac0a5b0688b30f1b385e; micalg=pgp-sha384; protocol="application/pgp-signature" Date: Mon, 05 Aug 2024 10:14:55 +0200 Message-Id: Cc: "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" , "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" From: "Michael Walle" To: "Frager, Neal" , "Simek, Michal" , "Mahapatra, Amit Kumar" , "Tudor Ambarus" , "broonie@kernel.org" , "pratyush@kernel.org" , "miquel.raynal@bootlin.com" , "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" Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in spi-nor X-Mailer: aerc 0.16.0 References: <20231125092137.2948-1-amit.kumar-mahapatra@amd.com> <576d56ed-d24b-40f9-9ae4-a02c50eea2ab@linaro.org> <9cdb7f8b-e64f-46f6-94cb-194a25a42ccd@linaro.org> <9fb60743-3e89-49fa-a399-3cf2607a7e41@amd.com> In-Reply-To: < Message-ID-Hash: IR3CLZI6CHGEIQ27MUMQFLD3WBF2S2OH X-Message-ID-Hash: IR3CLZI6CHGEIQ27MUMQFLD3WBF2S2OH X-MailFrom: michael@walle.cc 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: --7dd7e4000aaf39ea05868ee56141ae02e60c588dac0a5b0688b30f1b385e Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi, > > You get twice more capacity based on that configuration. I can't answer= the=20 > > second question because not working with field. But both of that config= urations=20 > > are used by customers. Adding Neal if he wants to add something more to= it. > > Just to add a comment as I work directly with our customers. The main re= ason > this support is important is for our older SoCs, zynq and zynqmp. > > Most of our customers are using QSPI flash as the first boot memory to ge= t > from the boot ROM to u-boot. They then typically use other memories, suc= h as > eMMC for the Linux kernel, OS and file system. Agreed and that's probably the most prominent use case for NOR flashes anyway. > The issue we have on the zynq and zynqmp SoCs is that the boot ROM (code = that > cannot be changed) will not boot from an OSPI flash. It will only boot f= rom a > QSPI flash. This is what is forcing many of our customers down the QSPI = path. > Since many of these customers are interested in additional speed and memo= ry > size, they then end up using a parallel or stacked configuration because = they > cannot use an OSPI with zynq or zynqmp. Above you've said, the bootloader is stored on the NOR flash and the bulk storage is eMMC. So why do you need bigger NOR flashes (where even the biggest NOR flash isn't enough)? I also don't understand "the boot ROM will just boot from QSPI". First, you cannot connect an octal flash anyway, because you only have an QSPI controller, right? Secondly, normally the bootrom will (at least) boot the first stage using normal (single line) SPI commands. Is that not the case for zynq and zynqmp? > All of our newer SoCs can boot from OSPI. I agree with you that if someo= ne > could choose OSPI for performance, they would, so I do not expect paralle= l or > stacked configurations with our newer SoCs. Ok, but then the argument with bigger flashes are void, because you are back to be bound to one OSPI flash. > I get why you see this configuration as a niche, but for us, it is a very > large niche because zynq and zynqmp are two of our most successful SoC > families. Fair enough. But please find a way to support it without butchering the whole core. -michael --7dd7e4000aaf39ea05868ee56141ae02e60c588dac0a5b0688b30f1b385e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iKcEABMJAC8WIQTIVZIcOo5wfU/AngkSJzzuPgIf+AUCZrCKABEcbWljaGFlbEB3 YWxsZS5jYwAKCRASJzzuPgIf+FYNAX9NIWR38ce9qJn6zNk09ma1XmS8x6pEwlyq B9zfpWmszaRp5K+VrBhJPhG/hsHdCEYBgJOO6eD7uzRx54DCJJvPk/PtcUpV9fHS uITq20JdXO5/9F2UNXphqdnMQ0F8FW7hjg== =jmIb -----END PGP SIGNATURE----- --7dd7e4000aaf39ea05868ee56141ae02e60c588dac0a5b0688b30f1b385e--