[U-Boot] [PATCH v4 1/3] dm: implement a MTD uclass

From: Jagan Teki <jteki@openedev.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v4 1/3] dm: implement a MTD uclass
Date: Tue, 3 Nov 2015 20:28:30 +0530	[thread overview]
Message-ID: <CAD6G_RQd7KveoHQLPiMEmQ3QeELd+6Mc2dH6EX-36bG9Z68DCw@mail.gmail.com> (raw)
In-Reply-To: <CAD6G_RSXgXfhPBoeZNtmiLU5QR1zdhPdBjMtVJUZU3=+sVjdcg@mail.gmail.com>

On 3 November 2015 at 20:25, Jagan Teki <jteki@openedev.com> wrote:
> On 3 November 2015 at 20:19, Thomas Chou <thomas@wytron.com.tw> wrote:
>> Hi Jagan,
>>
>> On 2015?11?03? 22:41, Jagan Teki wrote:
>>>
>>> Hi Thomas,
>>>
>>> On 3 November 2015 at 18:39, Thomas Chou <thomas@wytron.com.tw> wrote:
>>>>
>>>> Implement a Memory Technology Device (MTD) uclass. It should
>>>> include most flash drivers in the future. Though no uclass ops
>>>> are defined yet, the MTD ops could be used.
>>>>
>>>> The NAND flash driver is based on MTD. The CFI flash and SPI
>>>> flash support MTD, too. It should make sense to convert them
>>>> to MTD uclass.
>>>
>>>
>>> Why does MTD require driver model? Should drivers like nand, cfi or
>>> etc register mtd core should need to move on dm?
>>
>>
>> The driver model combined with device tree control of u-boot offers dynamic
>> binding of drivers and devices. It is expected that all drivers will be
>> converted to driver model, including nand, cfi and spi flash.
>
> So, mtd_info ops like _erase, _write and _read will also change or
> something like this
>
> struct dm_mtd_info {
>     struct mtd_info *info;
>     struct udevice *dev;
> };

See for example, I have recently added MTD support to spi_flash [1] [2]

[1] https://patchwork.ozlabs.org/patch/529397/
[2] https://patchwork.ozlabs.org/patch/529399/

-- 
Jagan | openedev.