From: Walter Lozano <walter.lozano@collabora.com>
To: u-boot@lists.denx.de
Subject: [RFC 1/7] mmc: fsl_esdhc_imx: add OF_PLATDATA support
Date: Thu, 9 Apr 2020 16:44:05 -0300 [thread overview]
Message-ID: <da52cf00-5eb7-a80a-bcba-2cbe6712230f@collabora.com> (raw)
In-Reply-To: <CAPnjgZ0-O2uhQ0X8P6wRqQLTwObYsq5cqze5EqFtq3MnXc1s9w@mail.gmail.com>
Hi Simon,
On 9/4/20 16:36, Simon Glass wrote:
> Hi Walter,
>
> On Thu, 9 Apr 2020 at 13:07, Walter Lozano <walter.lozano@collabora.com> wrote:
>> Hi Simon,
>>
>> On 8/4/20 00:14, Simon Glass wrote:
>>> Hi Walter,
>>>
>>> On Tue, 7 Apr 2020 at 14:05, Walter Lozano <walter.lozano@collabora.com> wrote:
>>>> Hi Simon,
>>>>
>>>> Thank you for taking the time to review this series.
>>>>
>>>> On 6/4/20 00:42, Simon Glass wrote:
>>>>> Hi Walter,
>>>>>
>>>>> On Sun, 29 Mar 2020 at 21:32, Walter Lozano<walter.lozano@collabora.com> wrote:
>>>>>> Signed-off-by: Walter Lozano<walter.lozano@collabora.com>
>>>>>> ---
>>>>>> drivers/mmc/fsl_esdhc_imx.c | 46 +++++++++++++++++++++++++++++++++----
>>>>>> 1 file changed, 42 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
>>>>>> index 4900498e9b..761a4b46e9 100644
>>>>>> --- a/drivers/mmc/fsl_esdhc_imx.c
>>>>>> +++ b/drivers/mmc/fsl_esdhc_imx.c
>>>>>> @@ -29,6 +29,8 @@
>>>>>> #include <dm.h>
>>>>>> #include <asm-generic/gpio.h>
>>>>>> #include <dm/pinctrl.h>
>>>>>> +#include <dt-structs.h>
>>>>>> +#include <mapmem.h>
>>>>>>
>>>>>> #if !CONFIG_IS_ENABLED(BLK)
>>>>>> #include "mmc_private.h"
>>>>>> @@ -98,6 +100,11 @@ struct fsl_esdhc {
>>>>>> };
>>>>>>
>>>>>> struct fsl_esdhc_plat {
>>>>>> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
>>>>>> + /* Put this first since driver model will copy the data here */
>>>>>> + struct dtd_fsl_imx6q_usdhc dtplat;
>>>>>> +#endif
>>>>>> +
>>>>>> struct mmc_config cfg;
>>>>>> struct mmc mmc;
>>>>>> };
>>>>>> @@ -1377,14 +1384,18 @@ static int fsl_esdhc_probe(struct udevice *dev)
>>>>>> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
>>>>>> struct fsl_esdhc_plat *plat = dev_get_platdata(dev);
>>>>>> struct fsl_esdhc_priv *priv = dev_get_priv(dev);
>>>>>> +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
>>>>>> const void *fdt = gd->fdt_blob;
>>>>>> int node = dev_of_offset(dev);
>>>>>> + fdt_addr_t addr;
>>>>>> +#else
>>>>>> + struct dtd_fsl_imx6q_usdhc *dtplat = &plat->dtplat;
>>>>>> +#endif
>>>>>> struct esdhc_soc_data *data =
>>>>>> (struct esdhc_soc_data *)dev_get_driver_data(dev);
>>>>>> #if CONFIG_IS_ENABLED(DM_REGULATOR)
>>>>>> struct udevice *vqmmc_dev;
>>>>>> #endif
>>>>>> - fdt_addr_t addr;
>>>>>> unsigned int val;
>>>>>> struct mmc *mmc;
>>>>>> #if !CONFIG_IS_ENABLED(BLK)
>>>>>> @@ -1392,14 +1403,23 @@ static int fsl_esdhc_probe(struct udevice *dev)
>>>>>> #endif
>>>>>> int ret;
>>>>>>
>>>>>> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
>>>>>> + priv->esdhc_regs = map_sysmem(dtplat->reg[0], dtplat->reg[1]);
>>>>>> + val = plat->dtplat.bus_width;
>>>>>> + if (val == 8)
>>>>>> + priv->bus_width = 8;
>>>>>> + else if (val == 4)
>>>>>> + priv->bus_width = 4;
>>>>>> + else
>>>>>> + priv->bus_width = 1;
>>>>>> + priv->non_removable = 1;
>>>>>> +#else
>>>>>> addr = dev_read_addr(dev);
>>>>>> if (addr == FDT_ADDR_T_NONE)
>>>>>> return -EINVAL;
>>>>>> priv->esdhc_regs = (struct fsl_esdhc *)addr;
>>>>>> priv->dev = dev;
>>>>>> priv->mode = -1;
>>>>>> - if (data)
>>>>>> - priv->flags = data->flags;
>>>>>>
>>>>>> val = dev_read_u32_default(dev, "bus-width", -1);
>>>>>> if (val == 8)
>>>>>> @@ -1462,7 +1482,9 @@ static int fsl_esdhc_probe(struct udevice *dev)
>>>>>> priv->vs18_enable = 1;
>>>>>> }
>>>>>> #endif
>>>>>> -
>>>>>> +#endif
>>>>>> + if (data)
>>>>>> + priv->flags = data->flags;
>>>>>> /*
>>>>>> * TODO:
>>>>>> * Because lack of clk driver, if SDHC clk is not enabled,
>>>>>> @@ -1513,9 +1535,11 @@ static int fsl_esdhc_probe(struct udevice *dev)
>>>>>> return ret;
>>>>>> }
>>>>>>
>>>>>> +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
>>>>> Maybe can use if() for this one?
>>>> Thank you for the suggestion
>>>>
>>>>>> ret = mmc_of_parse(dev, &plat->cfg);
>>>>>> if (ret)
>>>>>> return ret;
>>>>>> +#endif
>>>>>>
>>>>>> mmc = &plat->mmc;
>>>>>> mmc->cfg = &plat->cfg;
>>>>>> @@ -1648,4 +1672,18 @@ U_BOOT_DRIVER(fsl_esdhc) = {
>>>>>> .platdata_auto_alloc_size = sizeof(struct fsl_esdhc_plat),
>>>>>> .priv_auto_alloc_size = sizeof(struct fsl_esdhc_priv),
>>>>>> };
>>>>>> +
>>>>>> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
>>>>> Don't you already have a U_BOOT_DRIVER declaration?
>>>>>
>>>>> You may need to change the name of your existing driver though (see
>>>>> of-platdata docs).
>>>>>
>>>>> So if it is because of that, please add a comment.
>>>> I have my doubts regarding this issue. As I see, this driver is used by
>>>> many different DT with different compatible strings, so I'm thinking in
>>>> trying to find a more generic approach. Would it be useful to have a
>>>> more elaborated solution searching for the compatible string when
>>>> matching drivers with device?
>>> Yes I think so.
>>>
>>> Actually searching for a string is not great anyway. I wonder if we
>>> can use the linker-list idea in the previous email somehow?
>>
>> I'm sure I' understand the idea you try to share with me. Sorry, I
>> understand that one limitation of the current implementation of
>> OF_PLATDATA is the fact that the U_BOOT_DRIVER name should match the one
>> used as first entry in DT. As in particular this driver has several
>> compatible
>>
>> { .compatible = "fsl,imx53-esdhc", },
>> { .compatible = "fsl,imx6ul-usdhc", },
>> { .compatible = "fsl,imx6sx-usdhc", },
>> { .compatible = "fsl,imx6sl-usdhc", },
>> { .compatible = "fsl,imx6q-usdhc", },
>> { .compatible = "fsl,imx7d-usdhc", .data =
>> (ulong)&usdhc_imx7d_data,},
>> { .compatible = "fsl,imx7ulp-usdhc", },
>> { .compatible = "fsl,imx8qm-usdhc", .data =
>> (ulong)&usdhc_imx8qm_data,},
>> { .compatible = "fsl,imx8mm-usdhc", .data =
>> (ulong)&usdhc_imx8qm_data,},
>> { .compatible = "fsl,imx8mn-usdhc", .data =
>> (ulong)&usdhc_imx8qm_data,},
>> { .compatible = "fsl,imx8mq-usdhc", .data =
>> (ulong)&usdhc_imx8qm_data,},
>> { .compatible = "fsl,imxrt-usdhc", },
>>
>> and in order to create a general solution, we need to search for the
>> compatible string instead of matching for driver name.
>>
>> Could you please elaborate a bit more your suggestion in order to
>> understand your approach.
>>
>> Thanks in advance.
> I am wondering if we can use the DM_GET_DRIVER() macro somehow in
> dt_platdata.c. At present we emit a string, and that string matches
> the driver name, so we should be able to. That will give a compile
> error if something is wrong, much better than the current behaviour of
> not being able to bind the driver at runtime.
>
> This is just to improve the current impl, not to do what you are asking here.
>
> For what you want, our current approach is to use the first compatible
> string to find the driver name. Since all compatible strings point to
> the same driver, perhaps that is good enough? We should at least
> understand the limitations before going further.
>
> The main one I am aware of is that you need to duplicate the
> U_BOOT_DRIVER()xxx for each compatible string. To fix that we could
> add:
>
> U_BOOT_DRIVER_ALIAS(xxx, new_name)
>
> which creates a linker list symbol that points to the original driver,
> perhaps using ll_entry_get(). That should be easy enough I think. Then
> whichever symbol you use you will get the same driver since all the
> symbols point to it.
>
> Unfortunately the .data field is not available with of_platdata. That
> could be added to the dtd_... struct automatically by dtoc, I suspect.
> However that requires some clever parsing of the C code...
>
> As you can tell I would really like to avoid string comparisons and
> tables of compatible strings in the image itself. It adds overheade.
Thanks for taking the time to elaborate your idea, now is clear. I
totally agree with you, the whole idea behind it to reduce the image
size, so we need to work to avoid any kind of table of strings.
I will investigate you approach and come back to you.
Regards,
Walter
next prev parent reply other threads:[~2020-04-09 19:44 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 3:31 [RFC 0/7] mx6cuboxi: enable OF_PLATDATA with MMC support Walter Lozano
2020-03-30 3:31 ` [RFC 1/7] mmc: fsl_esdhc_imx: add OF_PLATDATA support Walter Lozano
2020-04-06 3:42 ` Simon Glass
2020-04-07 20:05 ` Walter Lozano
2020-04-08 3:14 ` Simon Glass
2020-04-09 19:06 ` Walter Lozano
2020-04-09 19:36 ` Simon Glass
2020-04-09 19:44 ` Walter Lozano [this message]
2020-04-09 19:50 ` Simon Glass
2020-04-09 20:01 ` Walter Lozano
2020-04-17 20:05 ` Walter Lozano
2020-04-21 17:44 ` Simon Glass
2020-03-30 3:31 ` [RFC 2/7] mmc: fsl_esdhc_imx: add ofdata_to_platdata support Walter Lozano
2020-04-06 3:42 ` Simon Glass
2020-04-07 20:05 ` Walter Lozano
2020-03-30 3:31 ` [RFC 3/7] dtoc: update dtb_platdata to support cd-gpio Walter Lozano
2020-04-06 3:42 ` Simon Glass
2020-04-07 20:05 ` Walter Lozano
2020-03-30 3:31 ` [RFC 4/7] dm: uclass: add functions to get device by platdata Walter Lozano
2020-03-30 3:31 ` [RFC 5/7] gpio: mxc_gpio: add OF_PLATDATA support Walter Lozano
2020-04-06 3:42 ` Simon Glass
2020-04-07 20:05 ` Walter Lozano
2020-03-30 3:31 ` [RFC 6/7] mmc: fsl_esdhc_imx: add CD support when OF_PLATDATA is enabled Walter Lozano
2020-03-30 3:31 ` [RFC 7/7] mx6cuboxi: enable OF_PLATDATA Walter Lozano
2020-04-06 3:43 ` Simon Glass
2020-04-07 20:06 ` Walter Lozano
2020-03-30 3:54 ` [RFC 0/7] mx6cuboxi: enable OF_PLATDATA with MMC support Baruch Siach
2020-03-30 14:33 ` Walter Lozano
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=da52cf00-5eb7-a80a-bcba-2cbe6712230f@collabora.com \
--to=walter.lozano@collabora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox