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

[Vignesh R]

On 07/12/18 3:21 PM, Boris Brezillon wrote:
> On Thu, 6 Dec 2018 23:55:30 +0530
> Vignesh R <vigneshr at ti.com> wrote:
> 
>> 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.
>>
>> 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.
>>
> 
> No, please don't add a SPI_NOR_UCLASS. We already have the MTD_UCLASS
> which is barely used by drivers, so if anything, we should work on
> converting drivers to this UCLASS and maybe automate a few more things
> for MTD drivers (like MTD dev registration/deregistration [1]) instead
> of adding yet another UCLASS.
> 

I agree.

> If you need an example of how integration with the DM (and the MTD
> UCLASS) should be been done, you can look at the SPI NAND driver [2].
> 
> [1]http://code.bulix.org/9lart9-519406
> [2]http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mtd/nand/spi/core.c;h=cb8ffa3fa96a16dd40dda3553bbb171107e71df7;hb=HEAD#l1249
> 

Yeah, that can be done once MTD Kconfig cleanup is done and we have
dropped UCLASS_SPI_FLASH (would also require sf_dataflash.c to be moved
to MTD)

-- 
Regards
Vignesh