Dear Jagan,
> -----Original Message----- > From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] > Sent: Wednesday, February 28, 2018 5:40 PM > To: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; Jagan Teki > <ja...@amarulasolutions.com>; Cyrille Pitchen > <cyrille.pitc...@wedev4u.fr> > Cc: u-boot@lists.denx.de; Suresh Gupta <suresh.gu...@nxp.com>; Yogesh > Narayan Gaur <yogeshnarayan.g...@nxp.com>; Poonam Aggrwal > <poonam.aggr...@nxp.com>; Ashish Kumar <ashish.ku...@nxp.com>; > Han Xu <han...@nxp.com>; Frieder Schrempf > <frieder.schre...@exceet.de>; Boris Brezillon <boris.brezillon@free- > electrons.com> > Subject: Re: [U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support > > Prabhakar, Jagan, > > On Wed, 28 Feb 2018 09:42:11 +0000 > Prabhakar Kushwaha <prabhakar.kushw...@nxp.com> wrote: > > > [Resending on correct patch of the patch-set] > > > > 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 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 > > Okay, I've been working a bit with this controller, and can say it's > not quite true. This controller supports any kind of device that > expects memory-like operations (or whatever you want to call them), > that is, everything that is formed of one opcode, X address cycles, Y > dummy cycles and Z data in/out cycles (X, Y and Z can be zero). > Actually, I even think it could support regular SPI transfers, all we'd > have to do is use READ/WRITE instructions to do the transfers. > > > > > > 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. > I've discussed it privately with Cyrille before I sent the spi-mem > extension proposal, and he seemed to agree with the approach. I don't > know what his opinion is now that the RFC has been posted, but if he > hasn't changed his mind, that means Linux implementation is going in > the opposite direction. So it's probably worth reconsidering this move. > Cyrille, could you clarify your opinion? I'm also waiting your feedback > on the RFC to send a v2 addressing the comments I had from other people. > > > > > > ======================================= > > > 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? > That would be great if the code base could converge. Please help us with your strategy towards qspi framework. We are waiting for your direction before creating/sending patches of qspi driver & framework in upstream. --pk _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot