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
