Hi Jagan, On Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki <jagannadh.t...@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.ray...@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). Regards, Miquèl _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
