[U-Boot] [PATCH v10 03/27] mtd: add SPI-NOR core support

Prabhakar Kushwaha
2018-03-06T05:59:01Z

Dear Jagan,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon at 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 at 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 at lists.denx.de] On Behalf Of
> > > Jagan Teki
> > > Sent: Thursday, December 28, 2017 11:42 AM
> > > To: u-boot at 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/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