Miquel and Brois, thanks for working on this.
On Thu, Jun 7, 2018 at 2:11 PM, Miquel Raynal miquel.raynal@bootlin.com wrote:
Hi Jagan,
On Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki jagannadh.teki@gmail.com wrote:
- Boris
- Suneel (who helped in DM MTD)
- Siva, Michal (zynq qspi)
On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal miquel.raynal@bootlin.com wrote:
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.
- 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
This is really nice, look like this design handling any kind of controller features by abstracting spi core so-that controller hacks shouldn't touch the common core code. unfortunately I missed Linux ML during submission.
- 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...
- If so is fsl_qspi spi-nor driver moves to drivers/spi area? 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.
- 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.
- 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.
- 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).
I've looked the code on the respective patches, look like most of the code copy from Linux by adding __UBOOT__. I have no issue with Linux copy but we need to structure the code according to U-Boot in the form of driver-model (this series lack with that).
Here are my suggestions, based the MTD work so-far
First we need to design MTD driver-model which can capable to drive one driver from each interface. (not converting all interface drivers at once, that is taking more time and other issues)
Like Linux MTD, U-Boot should have MTD dm for underlying flash devices like nand, parallel nor, spinor etc. So to drive this theory with driver model(with an example of block layer) mtd is common device interaction for most of memory technology flashes like nand, parallel nor, spinor etc, these are treated as interface types wrt u-boot driver model.
Once the respective interface driver bind happen, the uclass driver will pass an 'interface type' to mtd layer to create device for it, for example once spinor ULASS_SPI_NOR driver bind happen, the uclass driver of spinor will pass MTD_IF_TYPE_SPI_NOR interface type to create mtd device for spinor devices.
So If we add this design to SPI-NAND changes, we need to implement - MTD dm core that can driver all interfaces - one driver for raw nand - one driver for spinand - spi-mem - convert fsl-qspi to spi-mem - implement command to handle
For spi-nor interface design, we have an example code here[2]
I've paused this [2] series because of dm conversion of spi-drivers otherwise I need add legacy code like mmc-legacy.c, so if we really move to spi-mem design and okay with above design. I will try to move the current spi flash to add MTD driver-model so-that we can add spi-mem, spi-nand on top of it or we can work together to convert them all.
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=20450
Jagan.