[U-Boot] [RFC PATCH v2 00/11] SF: Migrate to Linux SPI NOR framework

[Simon Goldschmidt]

Am 06.12.2018 um 19:25 schrieb Vignesh R:
> Hi Jagan,
> 
> On 06-Dec-18 10:44 PM, Jagan Teki wrote:
>> On Tue, Dec 4, 2018 at 5:56 PM Vignesh R <vigneshr at ti.com> wrote:
>>>
>>> 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.
>>> 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.
>>
>> We(someone) has proposed this sync before, but we(at-least I) rely on
>> implementing via DM not direct sync to Linux.
> 
> As I said in my cover letter, U-Boot sf layer is unable to support newer
> 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 for
> MMIO capable Controllers. I see no point in re-coding them from ground up.

And this is exactly why I'm testing this series: it's the only series 
I've seen in the last months that seems to properly handle 4-byte 
addressing (even if it does not fully do that for me, yet, but it's 
still RFC).

I have a bug in my hardware that requires me to put the chip back to 
3-byte mode manually up to now. I've sent a patch for that and this 
patch has been rejected.

So now I'm testing this series to see if it allows me to run U-Boot 
mainline on my board without additional patches required.

Simon

> 
> Could you be more specific on what you would like to see here in DM way?
> 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.
> 
> 
>> ofcourse other
>> subsystems might have doing this but I literally don't propose to do
>> that, since it may fire the u-boot implementation in future.
>>
> 
> Could you explain what might be possible issues in future? I will work
> on it.
> 
>> If you really get things up further, try to check this DM based
>> spi-nor here[1] and lets discuss on u-boot point-of-view. I've paused
>> this because of non-dm code, but I'm thinking we even re-change this
>> to fit MTD driver-model (this is my TODO, once spi dm migration done).
>>
> AFAICS, Non DM code is not going away anytime soon. Meanwhile, IMHO,
> lack of 4 byte addressing support is significantly hampering new
> development (as evident from number of people trying to add 4 byte
> addressing support.)
> 
>> [1] http://git.denx.de/?p=u-boot-spi.git;a=shortlog;h=refs/heads/next-working
>>
> 
> IIRC, last post of this branch was in January 2018. And looking at my
> inbox, its seems that 4 byte addressing was broken in that series.
> If you add 4 byte addressing + SFDP parsing logic + spi-mem support to
> above branch, I am pretty sure you spi-nor.c would look almost the same
> to whats there in this series.
> 
> Regards
> Vignesh
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>