Dear Jagan,

-----Original Message----- From: U-Boot [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Jagan Teki Sent: Thursday, December 28, 2017 11:42 AM To: u-boot@lists.denx.de Cc: Tom Rini trini@konsulko.com Subject: [U-Boot] [PATCH v10 00/27] dm: Generic MTD Subsystem, with SPI- NOR interface

Compared to previous series’s [1], [2], [3] and [4] this patch set redefined most of the implementation suitable to fit into existing driver-model.

MTD is generic subsystem for underlying flash devices like nand, parallel nor, spinor, dataflash 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, dataflash 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.

SPI-NOR:

Some of the SPI device drivers at drivers/spi not a real spi controllers, Unlike normal/generic SPI controllers they operates only with SPI-NOR flash devices. these were technically termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c

The problem with these were resides at drivers/spi is entire SPI layer becomes SPI-NOR flash oriented which is absolutely a wrong indication where SPI layer getting effected more with flash operations - So this SPI-NOR core will resolve this issue by separating all SPI-NOR flash operations from spi layer and creats a generic layer called SPI-NOR core which can be used to interact SPI-NOR to SPI driver interface layer and the SPI-NOR controller driver.

======================================= cmd/spinor.c ======================================= mtd-uclass.c ======================================= spi-nor-uclass.c ======================================= spi-nor.c ======================================= m25p80.c zynq_qspinor.c ======================================= spi-uclass.c ======================================= zynq_qspi.c ======================================= #####SPI NOR chip###### =======================================

As per this patch-set, fsl_qspi is looks to be getting proposed in driver/mtd/spi-nor/ folder.

fsl_qspi is supporting both flash and fpga. We are not sure about its location.

There is an on-going effort for similar type of requirement in Linux by Boris Brezillon . It is dealing with controllers supporting NORs, NANDs, SRAMs etc. http://patchwork.ozlabs.org/project/linux-mtd/list/?series=27088

Borris has also ported fsl_qspi in driver/spi to use this new framework. It is still not completely tested. https://github.com/bbrezillon/linux/commit/43cc45764b975bfbb191de3f6a37e073d...

Will you also follow similar approach as being done in http://patchwork.ozlabs.org/project/linux-mtd/list/?series=27088 for longer term?

For Now, We are planning to update fsl_qspi driver to support dynamic LUT. Similar patch is in progress in Linux http://patchwork.ozlabs.org/project/linux-mtd/list/?series=26084 Now we are confused, should be port fsl_qspi in driver/mtd/spi-nor and then update driver Or We update driver/spi/fsl_qspi for dynamic LUTs. We may need to modify existing framework to get all required info for dynamic LUT.

Also we want some change in framework like support of - 4 byte address and SFDP : http://patchwork.ozlabs.org/project/uboot/list/?series=19621&state=* - SMPT : in discussion in Linux http://patchwork.ozlabs.org/patch/869718/ Which code base should we use? u-boot-spi.git branch mtd-spinor-working or u-boot.git master branch

--pk