[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Jagan Teki]

Miquel and Brois, thanks for working on this.

On Thu, Jun 7, 2018 at 2:11 PM, Miquel Raynal <miquel.raynal at bootlin.com> wrote:
> Hi Jagan,
>
> On Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki
> <jagannadh.teki at 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 at 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.
>>
>> 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

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.

>
>>
>> 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/
>
>>
>> 3) 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.
>
>>
>> 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.
>
>>
>> 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.
>
>>
>> 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).

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.