[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Boris Brezillon]

Hi Jagan,

On Thu, 7 Jun 2018 10:41:35 +0200
Miquel Raynal <miquel.raynal at bootlin.com> wrote:

> Hi Jagan,
> 
> On Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki
> <jagannadh.teki at gmail.com> wrote:
> 
> > + Boris
> > + Suneel (who helped in DM MTD)
> > + Siva, Michal  (zynq qspi)
> > 
> > On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal <miquel.raynal at bootlin.com> wrote:  
> > > During the last months, Boris Brezillon shared his work to support
> > > serial flashes within Linux. First, he delivered (and merged) a new
> > > layer called spi-mem. He also initiated in Linux MTD subsystem the move
> > > of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> > > same time a NAND core that would be shared with all NAND devices. Then,
> > > he contributed a generic SPI-NAND driver, making use of this NAND core,
> > > as well as some vendor code to drive a few chips.    
> > 
> > 1) Can you pointed us the Linux changes along with discussion thread
> > about spi-mem, and spi-nand.  
> 
> Sure, you can have a look there:
> 
> SPI-mem:
> http://lists.infradead.org/pipermail/linux-mtd/2018-April/080225.html
> 
> SPI-NAND:
> http://lists.infradead.org/pipermail/linux-mtd/2018-May/081005.html
> 
> > 
> > 2) If my understanding was correct, spi-mem is replacement for spi-nor
> > controller drivers from driver/mtd/spi-nor in Linux.  
> 
> It is not 'exactly' a replacement for spi-nor controller drivers but
> that's the idea. I suggest you to have a look at Boris' blog post about
> it:
> https://bootlin.com/blog/spi-mem-bringing-some-consistency-to-the-spi-memory-ecosystem/
> 
> > 
> > 3) If so is fsl_qspi spi-nor driver moves to drivers/spi area? yes
> > then how does flash changes handled by spi-mem.  
> 
> This series does not migrate the SPI-NOR stack to spi-mem. It focuses
> on SPI-NAND for now. And I don't understand the second sentence.
> 
> > 
> > 4) we have zynq qspi controller which has extensive features like dual
> > flash(stacked and parallel) does spi-mem support these flash specific
> > changes?  
> 
> This controller is very specific and such support has not yet been
> added.
> 
> > 
> > 5) Better to send spi-mem and spi-nand changes separately, for better reviewing.  
> 
> It would mean sending 3 or 4 distinct series, I thought better to give
> the whole picture but that's your choice.
> 
> > 
> > 6) We have DM MTD layer in ML, better to send the changes on-top [1]
> > 
> > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=20450  
> 
> This is great to see such effort being made to develop U-Boot
> driver-model but is there a real need for yet another layer on top of
> the MTD stack?
> 
> I'm looking at mtd-uclass.c for instance, I don't get the need for a
> mtd_dread() function, all the operations in the mtd_d*() helpers are
> already handled by mtd/mtdcore.c, no?
> 
> And the mtd_ops structure does not bring a lot. Should not we keep it
> simple and avoid such intermediate layer?
> 
> Also, there is the introduction of a spinor command (what about the
> existing 'sf'?), which is exactly the opposite of what the MTD
> abstraction would told us to do (thus, the 'mtd' generic command).

Any chance you can comment on Miquel's reply?

That's really important to have your feedback on these questions since
your answers might heavily impact the work we'll have to do to get
things merged (especially question #6).

Thanks,

Boris