
Dear Jagan,
-----Original Message----- From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] Sent: Wednesday, February 28, 2018 5:40 PM To: Prabhakar Kushwaha prabhakar.kushwaha@nxp.com; Jagan Teki jagan@amarulasolutions.com; Cyrille Pitchen cyrille.pitchen@wedev4u.fr Cc: u-boot@lists.denx.de; Suresh Gupta suresh.gupta@nxp.com; Yogesh Narayan Gaur yogeshnarayan.gaur@nxp.com; Poonam Aggrwal poonam.aggrwal@nxp.com; Ashish Kumar ashish.kumar@nxp.com; Han Xu han.xu@nxp.com; Frieder Schrempf frieder.schrempf@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.kushwaha@nxp.com wrote:
[Resending on correct patch of the patch-set]
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 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/43cc45764b975bfbb191de3f6a37e073d...
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