All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata
Date: Thu, 14 May 2020 10:01:54 -0600	[thread overview]
Message-ID: <CAPnjgZ1=5PsJzaN6+SXM2c-gk+1CxGg-KYE0Xh4oftze_FbxGQ@mail.gmail.com> (raw)
In-Reply-To: <aa64d34f-d061-0b0d-6557-9a9001825f12@ti.com>

Hi Faiz,

+Walter Lozano

On Thu, 14 May 2020 at 02:43, Faiz Abbas <faiz_abbas@ti.com> wrote:
>
> Simon,
>
> On 05/05/20 12:20 pm, Faiz Abbas wrote:
> > Hi,
> >
> > On 04/05/20 6:44 pm, Simon Glass wrote:
> >> Hi Bart,
> >>
> >> On Mon, 4 May 2020 at 01:10, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >>>
> >>> pt., 1 maj 2020 o 20:32 Tom Rini <trini@konsulko.com> napisa?(a):
> >>>>
> >>>> On Thu, Apr 30, 2020 at 01:43:30PM +0200, Bartosz Golaszewski wrote:
> >>>>> wt., 28 kwi 2020 o 09:01 Faiz Abbas <faiz_abbas@ti.com> napisa?(a):
> >>>>>>
> >>>>>> +Bartosz
> >>>>>>
> >>>>>> On 28/04/20 9:47 am, Lokesh Vutla wrote:
> >>>>>>> +Faiz,
> >>>>>>>
> >>>>>>> On 28/04/20 12:29 AM, Tom Rini wrote:
> >>>>>>>> On Mon, Apr 27, 2020 at 05:33:41AM +0000, Peng Fan wrote:
> >>>>>>>>>> Subject: [PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata
> >>>>>>>>>>
> >>>>>>>>>> At present this driver is enabled in SPL on omapl138_lcdk, which uses
> >>>>>>>>>> of-platdata. The driver needs to be ported to use of-platdata properly.
> >>>>>>>>>> For now, avoid a build error by returning an error.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>>
> >>>>>>> Does this break the boot on omap l138?
> >>>>>>>
> >>>>>>
> >>>>>> I don't have a board at hand to test this out. Bartosz can you help test this with
> >>>>>> omapl138?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Faiz
> >>>>>
> >>>>> Hi Faiz,
> >>>>>
> >>>>> I can confirm - this *does* break the mmc boot on da850-lcdk.
> >>>>
> >>>> So who is going to fix the driver to unblock Simon's series?
> >>>>
> >>>
> >>> Is this something that will take a lot of work? What exactly needs
> >>> doing? I'm not sure what "use of-platdata properly" means.
> >>
> >> This board is defining CONFIG_SPL_OF_PLATDATA which means that device
> >> tree is not available in SPL. Instead you need to use a C structure
> >> created by dtoc. It basically involves creating that struct and
> >> getting the data from that instead of calling the DT functions. I
> >> expect it will take 2-4 hours to figure out, code and test.
> >>
> >> See of-plat.rst for full documentation. There are quite a few examples for mmc:
> >>
> >> grep PLATDATA drivers/mmc/*.c
> >> drivers/mmc/ftsdc010_mci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/ftsdc010_mci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/ftsdc010_mci.c:#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/ftsdc010_mci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/mxsmmc.c: debug("OF_PLATDATA: regs: 0x%p bw: %d clkid: %d
> >> non_removable: %d\n",
> >> drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/omap_hsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/omap_hsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/omap_hsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> >> !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/rockchip_dw_mmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/rockchip_dw_mmc.c:#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/rockchip_dw_mmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/rockchip_sdhci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/rockchip_sdhci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> >> drivers/mmc/rockchip_sdhci.c:#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> >>
>
> In all the examples above, platdata reg filed is directly being used for
> to assign a register base address but looking at davinci platdata that is generated,
> spl/dts/dt-platdata.c:
>
> static const struct dtd_simple_bus dtv_soc_at_1c00000 = {
>         .model                  = "da850",
>         .ranges                 = {0x0, 0x1c00000, 0x400000},
> };
> U_BOOT_DEVICE(soc_at_1c00000) = {
>         .name           = "simple_bus",
>         .platdata       = &dtv_soc_at_1c00000,
>         .platdata_size  = sizeof(dtv_soc_at_1c00000),
> };
>
> static const struct dtd_ti_da830_uart dtv_serial_at_10d000 = {
>         .power_domains          = {0xa, 0xd},
>         .reg                    = {0x10d000, 0x100},
>         .reg_io_width           = 0x4,
>         .reg_shift              = 0x2,
> };
> U_BOOT_DEVICE(serial_at_10d000) = {
>         .name           = "ti_da830_uart",
>         .platdata       = &dtv_serial_at_10d000,
>         .platdata_size  = sizeof(dtv_serial_at_10d000),
> };
>
> static const struct dtd_ti_da830_mmc dtv_mmc_at_40000 = {
>         .bus_width              = 0x4,
>         .cap_mmc_highspeed      = true,
>         .cap_sd_highspeed       = true,
>         .cd_gpios               = {0x16, 0x40, 0x1},
>         .dma_names              = {"rx", "tx"},
>         .dmas                   = {0x14, 0x10, 0x0, 0x14, 0x11, 0x0},
>         .max_frequency          = 0x2faf080,
>         .reg                    = {0x40000, 0x1000},
> };
> U_BOOT_DEVICE(mmc_at_40000) = {
>         .name           = "ti_da830_mmc",
>         .platdata       = &dtv_mmc_at_40000,
>         .platdata_size  = sizeof(dtv_mmc_at_40000),
> };
>
> I need the base address of the MMC device (dtd_ti_da830_mmc dtv_mmc_at_40000)
> reg = 0x40000 to be translated with the simple_bus ranges above. How do I do
> this without a device tree as there is no parent-child relationship defined
> between the structures? Or at least that is my understanding.
>
> Looks like I will have to drop OF_PLATDATA and use hardcoded U_BOOT_DEVICE()
> declarations for this.

Four options I can think of:

1. Add support for translating to dtoc
2. Add support for parents to dtoc
3. Find the soc device (the one with the ranges) and write a function
to return the base address given the dtplat for that device.
4. Hard-code the address behind if CONFIG_IS_ENABLED(OF_PLATDATA)) for
your board

Regards,
Simon

  parent reply	other threads:[~2020-05-14 16:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27  1:24 [PATCH v5 0/4] of-platdata: Avoid building libfdt Simon Glass
2020-04-27  1:24 ` [PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata Simon Glass
2020-04-27  5:33   ` Peng Fan
2020-04-27 18:59     ` Tom Rini
2020-04-28  4:17       ` Lokesh Vutla
2020-04-28  7:00         ` Faiz Abbas
2020-04-30 11:43           ` Bartosz Golaszewski
2020-05-01 18:32             ` Tom Rini
2020-05-04  7:10               ` Bartosz Golaszewski
2020-05-04 13:14                 ` Simon Glass
2020-05-05  6:50                   ` Faiz Abbas
2020-05-05 16:17                     ` Bartosz Golaszewski
2020-05-14  8:19                     ` Faiz Abbas
2020-05-14 14:59                       ` Tom Rini
2020-05-14 15:25                         ` Faiz Abbas
2020-05-14 15:45                           ` Tom Rini
2020-05-14 17:23                           ` Simon Glass
2020-05-14 16:01                       ` Simon Glass [this message]
2020-04-27  1:24 ` [PATCH v5 2/4] rockchip: pinctrl: Disable full pinctrl for SPL Simon Glass
2020-04-28 14:21   ` Kever Yang
2020-04-27  1:24 ` [PATCH v5 3/4] spl: Allow SPL/TPL to use of-platdata without libfdt Simon Glass
2020-04-27  1:24 ` [PATCH v5 4/4] dm: core: Don't include ofnode functions with of-platdata Simon Glass

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='CAPnjgZ1=5PsJzaN6+SXM2c-gk+1CxGg-KYE0Xh4oftze_FbxGQ@mail.gmail.com' \
    --to=sjg@chromium.org \
    --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.