[U-Boot] [RFC PATCH 00/20] SPI-NAND support

[Jagan Teki]

+ Simon
+ Tom

On Mon, Jun 25, 2018 at 7:57 PM, Jagan Teki <jagan at amarulasolutions.com> wrote:
> + Simon
> + Tom
> (suggesting MTD driver model abstraction layer)
>
> On Mon, Jun 25, 2018 at 2:39 PM, Boris Brezillon
> <boris.brezillon at bootlin.com> wrote:
>> +Richard to comment on the MTD abstraction stuff and how uboot port
>> of UBI might be impacted by some changes requested here.
>>
>> Hi Jagan,
>>
>> On Mon, 25 Jun 2018 13:59:37 +0530
>> Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>
>>>
>>> I've looked the code on the respective patches, look like most of the
>>> code copy from Linux by adding __UBOOT__. I have no issue with Linux
>>> copy but we need to structure the code according to U-Boot in the form
>>> of driver-model (this series lack with that).
>>>
>>> Here are my suggestions, based the MTD work so-far
>>>
>>> First we need to design MTD driver-model which can capable to drive
>>> one driver from each interface. (not converting all interface drivers
>>> at once, that is taking more time and other issues)
>>>
>>> Like Linux MTD, U-Boot should have MTD dm for underlying flash devices
>>> like nand, parallel nor, spinor etc. So to drive this theory with
>>> driver model(with an example of block layer) mtd is common device
>>> interaction for most of  memory technology  flashes like nand,
>>> parallel nor, spinor etc, these are treated as interface types wrt
>>> u-boot driver model.
>>>
>>> Once the respective interface driver bind happen, the uclass driver
>>> will pass an 'interface type' to mtd layer to create device for it,
>>> for example once spinor ULASS_SPI_NOR driver bind happen, the uclass
>>> driver of spinor will pass MTD_IF_TYPE_SPI_NOR
>>> interface type to create mtd device for spinor devices.
>>>
>>> So If we add this design to SPI-NAND changes, we need to implement
>>> - MTD dm core that can driver all interfaces
>>
>> That's already what the MTD framework provides, and Miquel even added
>> some stuff to integrate the MTD layer even further in the DM. It's
>> probably not perfect yet, but the changes are, IMHO, going in the right
>> direction.
>>
>> Now, if you're talking about the new MTD API that creates helper
>> functions prefixed with dm_, sorry, but I don't see the point. We
>> already have plenty of MTD users in u-boot, they all manipulate MTD
>> objects and go through the standard MTD API to do that. What you
>> suggest would make things messier for several reasons:
>>
>> 1/ we won't be able to easily port Linux code to u-boot. Look at the
>>    JFFS2 UBI support. They all use mtd_info objects. What's the point of
>>    changing that except making things harder to port.
>>
>> 2/ Not all MTD providers will be converted to the device model at once,
>>    so how do you plan to deal with that?
>>
>> 3/ What's the benefit of exposing yet another way to manipulate MTD
>>    devices?
>>
>>> - one driver for raw nand
>>
>> Unfortunately, that's not how it works right now, and clearly, we
>> don't have time to work on this raw NAND rework right now.
>>
>>> - one driver for spinand
>>
>> I think that's already the case.
>>
>>> - spi-mem
>>
>> It's also what Miquel is doing in this series.
>>
>>> - convert fsl-qspi to spi-mem
>>
>> We're not targeting the fsl-qspi controller here but a simple SPI
>> controller that is already upstreamed. But yes, the fsl-qspi driver
>> will have to be patched to support the spi-mem interface at some point.
>
> Can you point me that simple spi-mem controller driver?
>
>>
>>> - implement command to handle
>>
>> This I don't get. What do you mean by "implement command to handle"?
>> Are we talking about cmd/mtd.c? I think the work Miquel has done is
>> already a good start, what's missing in there?
>>
>>>
>>> For spi-nor interface design, we have an example code here[2]
>>>
>>> I've paused this [2] series because of dm conversion of spi-drivers
>>> otherwise I need add legacy code like mmc-legacy.c, so if we really
>>> move to spi-mem design and okay with above design. I will try to move
>>> the current spi flash to add MTD driver-model so-that we can add
>>> spi-mem, spi-nand on top of it or we can work together to convert them
>>> all.
>>
>> Why can't we do things iteratively. I mean, if the long term goal is to
>> convert everything to the driver model, then this patchset is going in
>> the right direction:
>>  - addition of DM helpers to the MTD_UCLASS
>>  - addition of the spi-mem interface properly integrated in the DM
>>    model of the SPI framework
>>  - addition of a SPI NAND driver, again properly integrated in the DM
>>  - integration of DM-ready MTD drivers and old MTD drivers in a single
>>    view exposed by the cmd/mtd.c command set
>>
>> I'd really like to limit the scope of this development to these topics,
>> which doesn't prevent you from converting other part of u-boot to the
>> spi-mem approach (SPI NOR is one example).
>>
>> I hope you understand our concerns and the fact that what you're asking
>> us to do as a dependency of getting SPI NAND support + cmd/mtd.c merged
>> is way more than we can actually provide.
>
> To answer all these questions, I think we need to decide whether we go
> for MTD dm abstraction or existing MTD layer.
>
> When I say MTD dm abstraction, all mtd operation prototypes are in the
> form of udevice unlike existing MTD has mtd_info. when I initially
> supporting spi-nor (during Linux early spi-nor) I've reused existing
> MTD and written something like what Miquel did using mtd_info ops [3].
> but then developers on ML, proposed the new drivers should be form of
> driver-model abstraction, so I've added mtd driver model ops [4].
>
> I understand the new MTD dm abstraction in U-Boot is not possible for
> direct syncing from Linux, but we really want the u-boot way of
> handling drivers and trying to copy code from Linux by removing
> __UBOOT__ or any Linux specific macros. Since this is pretty much big
> task, ie the reason I'm asking for single driver from each MTD device
> so-that once the clear stack is ready other drivers can convert
> one-by-one.
>
> [3] http://git.denx.de/?p=u-boot-spi.git;a=commitdiff;h=d297949cd3f44278f109dff42fb88a879722121c
> [4] https://patchwork.ozlabs.org/patch/853337/



-- 
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.