Message-ID: <9fb60743-3e89-49fa-a399-3cf2607a7e41@amd.com>
Date: Wed, 31 Jul 2024 15:40:41 +0200
From: Michal Simek <michal.simek@....com>
To: Michael Walle <michael@...le.cc>,
 "Mahapatra, Amit Kumar" <amit.kumar-mahapatra@....com>,
 Tudor Ambarus <tudor.ambarus@...aro.org>,
 "broonie@...nel.org" <broonie@...nel.org>,
 "pratyush@...nel.org" <pratyush@...nel.org>,
 "miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
 "richard@....at" <richard@....at>, "vigneshr@...com" <vigneshr@...com>,
 "sbinding@...nsource.cirrus.com" <sbinding@...nsource.cirrus.com>,
 "lee@...nel.org" <lee@...nel.org>,
 "james.schulman@...rus.com" <james.schulman@...rus.com>,
 "david.rhodes@...rus.com" <david.rhodes@...rus.com>,
 "rf@...nsource.cirrus.com" <rf@...nsource.cirrus.com>,
 "perex@...ex.cz" <perex@...ex.cz>, "tiwai@...e.com" <tiwai@...e.com>
Cc: "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
 "nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
 "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
 "claudiu.beznea@...on.dev" <claudiu.beznea@...on.dev>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
 "patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>,
 "linux-sound@...r.kernel.org" <linux-sound@...r.kernel.org>,
 "git (AMD-Xilinx)" <git@....com>,
 "amitrkcian2002@...il.com" <amitrkcian2002@...il.com>,
 Conor Dooley <conor.dooley@...rochip.com>,
 "beanhuo@...ron.com" <beanhuo@...ron.com>
Subject: Re: [PATCH v11 07/10] mtd: spi-nor: Add stacked memories support in
 spi-nor



On 7/31/24 11:19, Michael Walle wrote:
> Hi Michal,
> 
>>>> 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/
>>>
>>> Will AMD submit to maintain this layer? What happens if the
>>> maintainer will leave AMD? TBH, personally, I don't like to
>>> maintain such a niche feature.
>>> I'd really like to see some use cases and performance reports for
>>> this, like actual boards (and no evaluation boards don't count). Why
>>> wouldn't someone just use an octal flash?
>>
>> AMD/Xilinx is not creating products that's why we don't have data on actual
>> boards but I don't really understand why evaluation boards don't count.
> 
> Because on an eval board the vendor just puts everything possible on
> the board.
> 
>> A lot of
>> customers are taking schematics from us and removing parts which they don't need
>> and add their custom part.
>>
>> But one product for parallel configuration which is publicly saying that it is
>> using it is for example this SOM.
>> https://shop.trenz-electronic.de/en/TE0820-05-2AI21MA-MPSoC-Module-with-AMD-Zynq-UltraScale-ZU2CG-1I-2-GByte-DDR4-SDRAM-4-x-5-cm
>>
>> I am not marketing guy to tell if there is any other which publicly saying we
>> are using this feature but we can only develop/support/maintain support for
>> these configurations on our evaluation boards because that's what we have access
>> to and what we know how it is done.
>>
>> Also performance numbers from us can be only provided against our evaluation boards.
> 
> Which is good enough.
> 
> All I'm saying is that you shouldn't put burden on us (the SPI NOR
> maintainers) for what seems to me at least as a niche. Thus I was
> asking for performance numbers and users. Convince me that I'm
> wrong and that is worth our time.

No. It is not really just feature of our evaluation boards. Customers are using 
it. I was talking to one guy from field and he confirms me that these 
configurations are used by his multiple customers in real products.

> 
> The first round of patches were really invasive regarding the core
> code. So if there is a clean layering approach which can be enabled
> as a module and you are maintaining it I'm fine with that (even if
> the core code needs some changes then like hooks or so, not sure).

That discussion started with Miquel some years ago when he was trying to to 
solve description in DT which is merged for a while in the kernel.
And Amit is trying to figure it out which way to go.
I don't want to predict where that code should be going or how it should look 
like because don't have spi-nor experience. But I hope we finally move forward 
on this topic to see the path how to upstream support for it.

Thanks,
Michal

Powered by blists - more mailing lists