Dear Jagan, > -----Original Message----- > From: U-Boot [mailto:u-boot-boun...@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 <tr...@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/43cc45764b975bfbb191de3f6a37e073da1a2706 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot