From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miquel Raynal Date: Mon, 10 Dec 2018 19:04:30 +0100 Subject: [U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework In-Reply-To: <262e69e0-c537-b997-2f2f-07a66d6dd244@ti.com> References: <20181204122659.14720-1-vigneshr@ti.com> <262e69e0-c537-b997-2f2f-07a66d6dd244@ti.com> Message-ID: <20181210190430.3527b5b1@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 Vignesh, Vignesh R wrote on Mon, 10 Dec 2018 23:08:38 +0530: > On 10-Dec-18 6:32 PM, Jagan Teki wrote: > > On Thu, Dec 6, 2018 at 11:55 PM Vignesh R wrote: =20 > >> > >> Hi Jagan, > >> > >> On 06-Dec-18 10:44 PM, Jagan Teki wrote: =20 > >>> On Tue, Dec 4, 2018 at 5:56 PM Vignesh R wrote: =20 > >>>> > >>>> U-Boot SPI NOR support (sf layer) is quite outdated as it does not > >>>> support 4 byte addressing opcodes, SFDP table parsing and different = types of > >>>> quad mode enable sequences. Many newer flashes no longer support BANK > >>>> registers used by sf layer to a access >16MB space. > >>>> Also, many SPI controllers have special MMIO interfaces which provide > >>>> accelerated read/write access but require knowledge of flash paramet= ers > >>>> to make use of it. Recent spi-mem layer provides a way to support su= ch > >>>> flashes but sf layer isn't using that. > >>>> This patch series syncs SPI NOR framework from Linux v4.19. It also = adds > >>>> spi-mem support on top. > >>>> So, we gain 4byte addressing support and SFDP support. This makes > >>>> migrating to U-Boot MTD framework easier. =20 > >>> > >>> We(someone) has proposed this sync before, but we(at-least I) rely on > >>> implementing via DM not direct sync to Linux. =20 > >> > >> As I said in my cover letter, U-Boot sf layer is unable to support new= er > >> flashes mainly due to lack of 4 byte addressing and proper support for > >> MMIO capable SPI controllers. > >> My idea of fixing this is to borrow _features_ from Linux SPI NOR "as > >> is". All that's needed is stateless 4 byte addressing, SFDP > >> parsing(optionally), Quad/Octal support and spi-mem like abstraction f= or > >> MMIO capable Controllers. I see no point in re-coding them from ground= up. > >> > >> Could you be more specific on what you would like to see here in DM wa= y? > >> I have no issues in adapting this code to any framework here in U-Boot. > >> Linux has driver model and SPI NOR subsystem is a framework and > >> therefore any code ported from Linux will inherently have those > >> abstractions. The only difference I see wrt your code in branch below = vs > >> this series is SPI-NOR uclass. This can be easily achieved by moving > >> nor->ops out of struct spi_nor into uclass abstraction. > >> Upstream Linux is anyways merging m25p80 and spi-nor so I did not see a > >> need for SPI NOR uclass. I am okay to change that if you insist on > >> having it. =20 > >=20 > > Merging or syncing spi-nor features stuff from Linux is good, I'm not > > stopping that. but this can be do by satisfying u-boot driver-model > > with proper architectural model. I know you take care but I'm not sure > > ie what can be manageable for long term. > >=20 > > Let's discuss the proper architectural model, so-that we can move > > further to incorporate the changes accordingly. (thanks at last we > > have a thread to discuss) > >=20 > > Linux m25p80 is moved to spi-nor right? so does controllers on spi-nor > > should be reside in same area like drivers/mtd/spi-nor or it should be > > part of spi-mem. The last mail with Boris, noted all spi-nor can't be > > fit into spi-mem(sorry I lost the thread) > > =20 >=20 > Yes, ATM all drivers fit into spi/spi-mem APIs and don't see any need > for new spi-nor uclass >=20 >=20 > > Example: we have zynq qspi it support BAR(with >16MB flashes), dual > > qspi ect so does it comes under spi-mem or spi-nor? > > =20 >=20 > In current mainline U-Boot, I see _no_ users of flags: > SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH > (I don't see flash->dual_flash set to any of the above enums). > But if we do need to support such flashes in future, current address > translation logic can be added to spi-nor.c (based on a DT flag), along > with a way to pass this info via spi-mem ops. > I would suggest to look at spi-mem ops (and in Linux mainline as well), > if there are any shortcomings we can discuss here. >=20 > > So, if no driver should be part of spi-nor and all can be handle > > spi-mem even-though they have controller specific features, yes we can > > skip SPI_NOR_UCLASS otherwise we need spi-nor uclass that can be child > > uclass of MTD. > > =20 >=20 > In fact, after this series is merged, UCLASS_SPI_FLASH can be dropped > and we can move to spi-nor(and sf_dataflash.c) directly under > UCLASS_MTD. But, mostly likely would need to provide a lightweight MTD > for SPL (similar to spi-nor-tiny.c) before that can be done. That would be great! Thanks, Miqu=C3=A8l