On Wed, Feb 28, 2018 at 3:12 PM, Prabhakar Kushwaha <[email protected]> wrote: > [Resending on correct patch of the patch-set] > > Dear Jagan, > > >> -----Original Message----- >> From: U-Boot [mailto:[email protected]] On Behalf Of Jagan >> Teki >> Sent: Thursday, December 28, 2017 11:42 AM >> To: [email protected] >> Cc: Tom Rini <[email protected]> >> Subject: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support >> >> 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. The idea is taken from Linux spi-nor framework. >> >> ======================================= >> 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
These look going in reverse direction, since drivers/mtd/spi-nor/fsl_qspi was meant for SPI-NOR flash(from initial version SPI-NOR framework patches) and now it going in driver/spi.. look like it need more discussion with respective people who involved on these. > > > 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. As of now, I would like to write it in driver/mtd/spi-nor assuming all LUT or fsl related changes donesn't harm core areas so-that moving back to drivers/spi might be easy if Linux does. > > 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 Pls use this https://github.com/openedev/u-boot-spi/commits/master _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
