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

[Boris Brezillon <boris.brezillon@bootlin.com>]

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.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com