All of lore.kernel.org
 help / color / mirror / Atom feed
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: Sat, 7 Nov 2015 18:05:37 +0530	[thread overview]
Message-ID: <CAD6G_RSVwR_Vbcw3JcHtOdT854X8jdRn52bv5WNvia+yEq_a+A@mail.gmail.com> (raw)
In-Reply-To: <563977AB.4040709@wytron.com.tw>

Hi Thomas/Simon,

On 4 November 2015 at 08:42, Thomas Chou <thomas@wytron.com.tw> wrote:
>
>
> On 2015?11?03? 22:55, Jagan Teki 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;
>> };
>
>
> Not exactly. I included udevice in mtd_info as it was device for Linux.
>
> @@ -272,6 +273,8 @@ struct mtd_info {
>         struct module *owner;
>  #ifndef __UBOOT__
>         struct device dev;
> +#else
> +       struct udevice *dev;
>  #endif
>         int usecount;
>  };
>
> I think the mtd ops is more complete and widely used. There might be no need
> to reinvent the dm_mtd ops. The mtd uclass priv is set to mtd_info and we
> can get it with mtd_get_info(dev). Then call mtd ops, like mtd_read()
> mtd_write and mtd_erase(), directly.
>
>>  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/
>
> It seems we are working toward the same direction. :)

Sorry, I couldn't understand this looks we're in different direction.

Let me explain what I thought about mtd_info usage. udevice should be
part of underlying flash structure's like cfi, nand and spi_flash and
mtd_info should be used for it's core api's like _erase. _read and
_write and underlying driver will use their global structure that
include's mtd and udevice as a function pointer like this.

struct spi_flash {
   struct mtd_info *info;
   struct udevice *device;
}

struct spi_flash_priv {
        struct spi_flash        flash;
        struct mtd_info         mtd;
};

static int spi_flash_std_probe(struct udevice *dev)
{
        struct spi_flash_priv *priv = dev_get_uclass_priv(dev);
        struct spi_slave *spi = dev_get_parent_priv(dev);
        struct spi_flash *flash;
        int ret;

        flash = &priv->flash;
        flash->mtd = &priv->mtd;

        flash->spi = spi;
        flash->priv = priv;

        priv->mtd.priv = flash;
        flash->dev = dev;
}

U_BOOT_DRIVER(spi_flash_std) = {
        .name           = "spi_flash_std",
        .id             = UCLASS_SPI_FLASH,
        .of_match       = spi_flash_std_ids,
        .probe          = spi_flash_std_probe,
        .priv_auto_alloc_size = sizeof(struct spi_flash_priv),
};

This is the way I have implemented mtd on spi-flash[1] [2]
[1] https://patchwork.ozlabs.org/patch/529397/
[2] https://patchwork.ozlabs.org/patch/529399/

Please explain how this related your approach of adding udevice to mtd.

>
> Simon suggested that we can have an unified flash class (for all cfi, spi
> and nand flash) after the discussion between Bin Meng and I. So I dropped
> the earlier cfi-flash uclass, and found the mtd might be a better uclass. We
> see the same point, "MTD has proven core for flash operations".
>
> The work on cfi-flash is not complete yet. It needs to reshape to use mtd
> ops like your earlier patches. But I have to work on others.
>
> The spi-flash uclass should be merged into mtd uclass and use mtd ops. Maybe
> you will be interested and will help. Thanks in advance.
>
> The nand flash is more ready. But need to convert to driver model.

thanks!
-- 
Jagan | openedev.

  reply	other threads:[~2015-11-07 12:35 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-08  7:34 [U-Boot] [PATCH] dm: implement a cfi flash uclass Thomas Chou
2015-10-09  9:36 ` Simon Glass
2015-10-09 13:31   ` Thomas Chou
2015-10-11  5:16     ` Thomas Chou
2015-10-11  5:41       ` Bin Meng
2015-10-11  7:25         ` Thomas Chou
2015-10-11  7:30 ` [U-Boot] [PATCH v2] " Thomas Chou
2015-10-11  7:54   ` Bin Meng
2015-10-11  8:54     ` Thomas Chou
2015-10-11  9:10       ` Bin Meng
2015-10-11 12:24         ` Thomas Chou
2015-10-11 12:43           ` Bin Meng
2015-10-11 13:29             ` Thomas Chou
2015-10-11 21:47               ` Simon Glass
2015-10-12  0:07                 ` Thomas Chou
2015-10-12  3:07                 ` Bin Meng
2015-10-11  9:35     ` Thomas Chou
2015-10-30 13:33 ` [U-Boot] [PATCH v3 1/3] dm: implement a MTD uclass Thomas Chou
2015-10-30 13:33   ` [U-Boot] [PATCH v3 2/3] cfi_flash: convert to driver model Thomas Chou
2015-11-02  8:20     ` Stefan Roese
2015-11-03  0:23       ` Thomas Chou
2015-11-03  5:56         ` Stefan Roese
2015-11-03  6:25           ` Thomas Chou
2015-11-03  7:22             ` Stefan Roese
2015-10-30 13:33   ` [U-Boot] [PATCH v3 3/3] nios2: use cfi flash " Thomas Chou
2015-11-03 13:09 ` [U-Boot] [PATCH v4 1/3] dm: implement a MTD uclass Thomas Chou
2015-11-03 13:09   ` [U-Boot] [PATCH v4 2/3] cfi_flash: convert to driver model Thomas Chou
2015-11-03 13:54     ` Stefan Roese
2015-11-06  1:09       ` Thomas Chou
2015-11-06  6:04         ` Stefan Roese
2015-11-06  6:33           ` Thomas Chou
2015-11-06  3:15     ` Simon Glass
2015-11-06  4:34       ` Thomas Chou
2015-11-06 23:58         ` Simon Glass
2015-11-03 13:09   ` [U-Boot] [PATCH v4 3/3] nios2: use cfi flash " Thomas Chou
2015-11-03 14:41   ` [U-Boot] [PATCH v4 1/3] dm: implement a MTD uclass Jagan Teki
2015-11-03 14:49     ` Thomas Chou
2015-11-03 14:55       ` Jagan Teki
2015-11-03 14:58         ` Jagan Teki
2015-11-04  3:12         ` Thomas Chou
2015-11-07 12:35           ` Jagan Teki [this message]
2015-11-07 13:43             ` Thomas Chou
2015-11-06 12:06   ` Simon Glass
2015-11-06 13:25     ` Thomas Chou
2015-11-06 23:58       ` Simon Glass
2015-11-07  7:57 ` [U-Boot] [PATCH v5 " Thomas Chou
2015-11-07  7:57   ` [U-Boot] [PATCH v5 2/3] cfi_flash: convert to driver model Thomas Chou
2015-11-09 20:24     ` Simon Glass
2015-12-06  8:23     ` Jagan Teki
2015-12-06 11:37       ` Thomas Chou
2015-12-06 13:10         ` Jagan Teki
2015-12-06 13:35           ` Thomas Chou
2015-12-06 15:03             ` Jagan Teki
2015-12-07  9:11               ` Thomas Chou
2015-11-07  7:57   ` [U-Boot] [PATCH v5 3/3] nios2: use cfi flash " Thomas Chou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAD6G_RSVwR_Vbcw3JcHtOdT854X8jdRn52bv5WNvia+yEq_a+A@mail.gmail.com \
    --to=jteki@openedev.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.