RFC SPI-NAND support
Get series with b4
b4 am 20180607104135.02df4c3c@xps13Versions newest first
- v1 RFC Latest0 of 20 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 20 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [RFC PATCH 00/20] SPI-NAND support
Hi Jagan,
Quoted 13 lines · Jagan Teki
+ Boris
+ Suneel (who helped in DM MTD)
+ Siva, Michal (zynq qspi)Quoted 7 lines · Miquel Raynal
During the last months, Boris Brezillon shared his work to support serial flashes within Linux. First, he delivered (and merged) a new layer called spi-mem. He also initiated in Linux MTD subsystem the move of all 'raw' NAND related code to a raw/ subdirectory, adding at the same time a NAND core that would be shared with all NAND devices. Then, he contributed a generic SPI-NAND driver, making use of this NAND core, as well as some vendor code to drive a few chips.
Quoted 2 lines
1) Can you pointed us the Linux changes along with discussion thread about spi-mem, and spi-nand.
Sure, you can have a look there:
SPI-mem:
http://lists.infradead.org/pipermail/linux-mtd/2018-April/080225.html
SPI-NAND:
http://lists.infradead.org/pipermail/linux-mtd/2018-May/081005.html
Quoted 3 lines
2) If my understanding was correct, spi-mem is replacement for spi-nor controller drivers from driver/mtd/spi-nor in Linux.
It is not 'exactly' a replacement for spi-nor controller drivers but that's the idea. I suggest you to have a look at Boris' blog post about it:
https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/
Quoted 3 lines
3) If so is
fsl_qspispi-nor driver moves todrivers/spiarea? yes then how does flash changes handled by spi-mem.
This series does not migrate the SPI-NOR stack to spi-mem. It focuses on SPI-NAND for now. And I don't understand the second sentence.
Quoted 4 lines
4) we have zynq qspi controller which has extensive features like dual flash(stacked and parallel) does spi-mem support these flash specific changes?
This controller is very specific and such support has not yet been added.
Quoted 2 lines
5) Better to send spi-mem and spi-nand changes separately, for better reviewing.
It would mean sending 3 or 4 distinct series, I thought better to give the whole picture but that's your choice.
Quoted 4 lines
6) We have DM MTD layer in ML, better to send the changes on-top [1]
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=20450
This is great to see such effort being made to develop U-Boot driver-model but is there a real need for yet another layer on top of the MTD stack?
I'm looking at mtd-uclass.c for instance, I don't get the need for a mtd_dread() function, all the operations in the mtd_d*() helpers are already handled by mtd/mtdcore.c, no?
And the mtd_ops structure does not bring a lot. Should not we keep it simple and avoid such intermediate layer?
Also, there is the introduction of a spinor command (what about the existing 'sf'?), which is exactly the opposite of what the MTD abstraction would told us to do (thus, the 'mtd' generic command).
Regards,
Miquèl