From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Thu, 7 Jun 2018 10:41:35 +0200 Subject: [U-Boot] [RFC PATCH 00/20] SPI-NAND support In-Reply-To: References: <20180606153040.21397-1-miquel.raynal@bootlin.com> Message-ID: <20180607104135.02df4c3c@xps13> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi Jagan, On Thu, 7 Jun 2018 11:21:22 +0530, Jagan Teki wrote: > + Boris > + Suneel (who helped in DM MTD) > + Siva, Michal (zynq qspi) >=20 > On Wed, Jun 6, 2018 at 9:00 PM, Miquel Raynal = 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. =20 >=20 > 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 >=20 > 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-memor= y-ecosystem/ >=20 > 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. >=20 > 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. >=20 > 5) Better to send spi-mem and spi-nand changes separately, for better rev= iewing. It would mean sending 3 or 4 distinct series, I thought better to give the whole picture but that's your choice. >=20 > 6) We have DM MTD layer in ML, better to send the changes on-top [1] >=20 > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=3D20450 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=C3=A8l