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-...
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