RFC SF: Migrate to Linux SPI NOR framework

Quoted 47 lines · Vignesh R

Quoted 30 lines

Hi Jagan,

Quoted 15 lines · Jagan Teki

Quoted 13 lines · Vignesh R

U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that.
This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top.
So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier.

Quoted 2 lines

We(someone) has proposed this sync before, but we(at-least I) rely on implementing via DM not direct sync to Linux.

As I said in my cover letter, U-Boot sf layer is unable to support newer flashes mainly due to lack of 4 byte addressing and proper support for MMIO capable SPI controllers.
My idea of fixing this is to borrow _features_ from Linux SPI NOR "as is". All that's needed is stateless 4 byte addressing, SFDP parsing(optionally), Quad/Octal support and spi-mem like abstraction for MMIO capable Controllers. I see no point in re-coding them from ground up.

Quoted 10 lines

Could you be more specific on what you would like to see here in DM way? I have no issues in adapting this code to any framework here in U-Boot. Linux has driver model and SPI NOR subsystem is a framework and therefore any code ported from Linux will inherently have those abstractions. The only difference I see wrt your code in branch below vs this series is SPI-NOR uclass. This can be easily achieved by moving nor->ops out of struct spi_nor into uclass abstraction. Upstream Linux is anyways merging m25p80 and spi-nor so I did not see a need for SPI NOR uclass. I am okay to change that if you insist on having it.

Merging or syncing spi-nor features stuff from Linux is good, I'm not stopping that. but this can be do by satisfying u-boot driver-model with proper architectural model. I know you take care but I'm not sure ie what can be manageable for long term.

Quoted 9 lines

Let's discuss the proper architectural model, so-that we can move further to incorporate the changes accordingly. (thanks at last we have a thread to discuss)

Linux m25p80 is moved to spi-nor right? so does controllers on spi-nor should be reside in same area like drivers/mtd/spi-nor or it should be part of spi-mem. The last mail with Boris, noted all spi-nor can't be fit into spi-mem(sorry I lost the thread)

Yes, ATM all drivers fit into spi/spi-mem APIs and don't see any need for new spi-nor uclass

Quoted 3 lines

Example: we have zynq qspi it support BAR(with >16MB flashes), dual qspi ect so does it comes under spi-mem or spi-nor?

In current mainline U-Boot, I see _no_ users of flags:
SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH
(I don't see flash->dual_flash set to any of the above enums). But if we do need to support such flashes in future, current address translation logic can be added to spi-nor.c (based on a DT flag), along with a way to pass this info via spi-mem ops.
I would suggest to look at spi-mem ops (and in Linux mainline as well), if there are any shortcomings we can discuss here.

Quoted 5 lines

So, if no driver should be part of spi-nor and all can be handle spi-mem even-though they have controller specific features, yes we can skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child uclass of MTD.

In fact, after this series is merged, UCLASS_SPI_FLASH can be dropped and we can move to spi-nor(and sf_dataflash.c) directly under UCLASS_MTD. But, mostly likely would need to provide a lightweight MTD for SPL (similar to spi-nor-tiny.c) before that can be done.