[U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux

Tom Rini trini at konsulko.com
Thu Dec 13 03:01:22 UTC 2018


On Thu, Dec 13, 2018 at 04:51:56AM +0530, Jagan Teki wrote:
> On Thu, Dec 13, 2018 at 4:26 AM Tom Rini <trini at konsulko.com> wrote:
> >
> > On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote:
> > > On Wed, Dec 12, 2018 at 11:10 PM Vignesh R <vigneshr at ti.com> wrote:
> > > >
> > > > Current 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 parameters
> > > > to make use of it. Recent spi-mem layer provides a way to support such
> > > > flashes but sf layer isn't using that.
> > > > So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top.
> > > > in order to gain 4 byte addressing support, SFDP support and a way to
> > > > support SPI controllers with MMIO flash interface.
> > > >
> > > > Signed-off-by: Vignesh R <vigneshr at ti.com>
> > > > ---
> > > >  drivers/mtd/spi/spi-nor-core.c | 2647 ++++++++++++++++++++++++++++++++
> > > >  include/linux/mtd/cfi.h        |   32 +
> > > >  include/linux/mtd/spi-nor.h    |  421 +++++
> > >
> > > Please refer many mails about this comment. I don't look for carbon
> > > copy of the code from Linux, you can use the implementation and even
> > > macro names etc but the end code would be the code that require
> > > U-Boot.
> > >
> > > - no __UBOOT ifdef
> >
> > What?  This is the exact opposite of what we're doing in several other
> > areas, with a large amount of success precisely because it allows us to
> > leverage developer base to catch and fix problems.  Dropping in the code
> > and minor and obvious deviations make for easier re-sync.
> 
> Several areas, but not spi-flash or spi. ie what I'm maintaining from
> long. I'm always looking for persistent code to be IN. May be it can't
> be syn-cable but we can work it more maintainable in u-boot way like
> other opensource project.  Well this is my experience with the U-Boot
> project development so-far, I never ever hold any features but if
> u-boot need the same features, better to add then like new code.

I think that for flash related SPI we should follow the lead of the rest
of MTD/NAND and adapt the kernel code.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181212/827053e0/attachment.sig>


More information about the U-Boot mailing list