[PATCH v5 0/4] of-platdata: Avoid building libfdt
The original patch of this series was sent in September but unfortunately caused build problems on some boards, since they don't comply with the of-platdata rules.
With of-platdata, the idea is to compile the device tree into C structures to save space and avoid needing to use libfdt. But some boards use of-platdata while also using libfdt in a few areas, thus defeating the purpose of of-platdata.
This series includes the original two patches
http://patchwork.ozlabs.org/patch/1167420/ http://patchwork.ozlabs.org/patch/1167367/
as well as a few other patches to fix the build errors. Overall this reduces code size and provides better error messages when unavailable functions are used.
Board maintainers should still take a look at the result, adjusting the of-platdata support as needed.
Changes in v5: - Drop one rockchip patch as that issue has been fixed
Changes in v4: - Add new patch for rockchip build errors - Add new patch for omap MMC build errors - Add new patch for rockchip chromebook build errors - Pull out patches into a new series - Add new patches to handle build failures
Changes in v3: - Fix eth_dev_get_mac_address() call dev_read...() only when available
Simon Glass (4): omap: mmc: Avoid using libfdt with of-platdata rockchip: pinctrl: Disable full pinctrl for SPL spl: Allow SPL/TPL to use of-platdata without libfdt dm: core: Don't include ofnode functions with of-platdata
configs/chromebit_mickey_defconfig | 1 + configs/chromebook_jerry_defconfig | 1 + configs/chromebook_minnie_defconfig | 1 + configs/chromebook_speedy_defconfig | 1 + drivers/core/Makefile | 4 +++- drivers/mmc/davinci_mmc.c | 6 ++++++ include/dm/read.h | 3 +-- lib/Kconfig | 4 ++-- net/eth-uclass.c | 2 +- 9 files changed, 17 insertions(+), 6 deletions(-)
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 ---
Changes in v5: None Changes in v4: None Changes in v3: None
drivers/mmc/davinci_mmc.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/davinci_mmc.c b/drivers/mmc/davinci_mmc.c index ef5cd4e723..44903354ab 100644 --- a/drivers/mmc/davinci_mmc.c +++ b/drivers/mmc/davinci_mmc.c @@ -498,6 +498,12 @@ static int davinci_mmc_probe(struct udevice *dev) cfg->b_max = DAVINCI_MAX_BLOCKS; cfg->name = "da830-mmc";
+ /* FIXME: Cannot read from device tree with of-platdata */ + if (CONFIG_IS_ENABLED(OF_PLATDATA)) { + printf("Please fix this driver to use of-platdata"); + return -ENOSYS; + } + priv->reg_base = (struct davinci_mmc_regs *)dev_read_addr(dev); priv->input_clk = clk_get(DAVINCI_MMCSD_CLKID);
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
Acked-by: Peng Fan peng.fan@nxp.com
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
Acked-by: Peng Fan peng.fan@nxp.com
Since the board maintainer is on CC and I believe that platform is still actively used in testing, I want to see this fixed rather than turned in to a run-time error. Thanks!
+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?
Thanks and regards, Lokesh
Acked-by: Peng Fan peng.fan@nxp.com
Since the board maintainer is on CC and I believe that platform is still actively used in testing, I want to see this fixed rather than turned in to a run-time error. Thanks!
+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
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.
Bart
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?
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.
Bart
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)
Regards, Simon
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)
I was able to get a setup to work on. Will post a fix for this soon.
Thanks, Faiz
wt., 5 maj 2020 o 08:50 Faiz Abbas faiz_abbas@ti.com napisał(a):
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)
I was able to get a setup to work on. Will post a fix for this soon.
Thanks, Faiz
Thanks Faiz! Let me know if you need some help testing it.
Bart
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.
Thanks, Faiz
On Thu, May 14, 2020 at 01:49:37PM +0530, Faiz Abbas 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.
I'm sure the TRM for those chips is readily available in public even, you should be able to work it out from there, yes?
Hi Tom,
On 14/05/20 8:29 pm, Tom Rini wrote:
On Thu, May 14, 2020 at 01:49:37PM +0530, Faiz Abbas 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 >>>>>>
...
> > 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.
I'm sure the TRM for those chips is readily available in public even, you should be able to work it out from there, yes?
The problem is not getting the offset. We already know it from the device tree. The issue is that of-platdata doesn't support address translation (yet?). Is there a way to do this cleanly using the generated device structures of platdata? Otherwise as I said I will need to disable OF_PLATDATA and declare static C structures in the board file.
Thanks, Faiz
On Thu, May 14, 2020 at 08:55:01PM +0530, Faiz Abbas wrote:
Hi Tom,
On 14/05/20 8:29 pm, Tom Rini wrote:
On Thu, May 14, 2020 at 01:49:37PM +0530, Faiz Abbas 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 >>>>>>>
...
>> >> 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.
I'm sure the TRM for those chips is readily available in public even, you should be able to work it out from there, yes?
The problem is not getting the offset. We already know it from the device tree. The issue is that of-platdata doesn't support address translation (yet?). Is there a way to do this cleanly using the generated device structures of platdata? Otherwise as I said I will need to disable OF_PLATDATA and declare static C structures in the board file.
Ah, sorry I misunderstood the problem. I suspect U_BOOT_DEVICES is probably the best path forward right now.
Hi Faiz,
On Thu, 14 May 2020 at 10:40, Faiz Abbas faiz_abbas@ti.com wrote:
Hi Tom,
On 14/05/20 8:29 pm, Tom Rini wrote:
On Thu, May 14, 2020 at 01:49:37PM +0530, Faiz Abbas 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 >>>>>>>
...
>> >> 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.
I'm sure the TRM for those chips is readily available in public even, you should be able to work it out from there, yes?
The problem is not getting the offset. We already know it from the device tree. The issue is that of-platdata doesn't support address translation (yet?). Is there a way to do this cleanly using the generated device structures of platdata? Otherwise as I said I will need to disable OF_PLATDATA and declare static C structures in the board file.
+Walter Lozano again
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
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
We don't need full pinctrl for SPL on these chrombook devices. Disable it so that of-platdata can be used without calling libfdt routines.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v5: None Changes in v4: None Changes in v3: None
configs/chromebit_mickey_defconfig | 1 + configs/chromebook_jerry_defconfig | 1 + configs/chromebook_minnie_defconfig | 1 + configs/chromebook_speedy_defconfig | 1 + 4 files changed, 4 insertions(+)
diff --git a/configs/chromebit_mickey_defconfig b/configs/chromebit_mickey_defconfig index a0b1c8d87e..7a1a5d6fcb 100644 --- a/configs/chromebit_mickey_defconfig +++ b/configs/chromebit_mickey_defconfig @@ -72,6 +72,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set # CONFIG_SPL_PINMUX is not set CONFIG_SPL_PINCONF=y CONFIG_DM_PMIC=y diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig index 7ba0c9566a..0e7381ca72 100644 --- a/configs/chromebook_jerry_defconfig +++ b/configs/chromebook_jerry_defconfig @@ -75,6 +75,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set # CONFIG_SPL_PINMUX is not set CONFIG_SPL_PINCONF=y CONFIG_DM_PMIC=y diff --git a/configs/chromebook_minnie_defconfig b/configs/chromebook_minnie_defconfig index 46e1c183a2..bacfafb539 100644 --- a/configs/chromebook_minnie_defconfig +++ b/configs/chromebook_minnie_defconfig @@ -74,6 +74,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set # CONFIG_SPL_PINMUX is not set CONFIG_SPL_PINCONF=y CONFIG_DM_PMIC=y diff --git a/configs/chromebook_speedy_defconfig b/configs/chromebook_speedy_defconfig index 34cf727abc..370a40df3e 100644 --- a/configs/chromebook_speedy_defconfig +++ b/configs/chromebook_speedy_defconfig @@ -74,6 +74,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_PMIC_RK8XX=y
On 2020/4/27 上午9:24, Simon Glass wrote:
We don't need full pinctrl for SPL on these chrombook devices. Disable it so that of-platdata can be used without calling libfdt routines.
Signed-off-by: Simon Glass sjg@chromium.org
Reviewed-by: Kever Yang kever.yang@rock-chips.com
Thanks, - Kever
Changes in v5: None Changes in v4: None Changes in v3: None
configs/chromebit_mickey_defconfig | 1 + configs/chromebook_jerry_defconfig | 1 + configs/chromebook_minnie_defconfig | 1 + configs/chromebook_speedy_defconfig | 1 + 4 files changed, 4 insertions(+)
diff --git a/configs/chromebit_mickey_defconfig b/configs/chromebit_mickey_defconfig index a0b1c8d87e..7a1a5d6fcb 100644 --- a/configs/chromebit_mickey_defconfig +++ b/configs/chromebit_mickey_defconfig @@ -72,6 +72,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set # CONFIG_SPL_PINMUX is not set CONFIG_SPL_PINCONF=y CONFIG_DM_PMIC=y diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig index 7ba0c9566a..0e7381ca72 100644 --- a/configs/chromebook_jerry_defconfig +++ b/configs/chromebook_jerry_defconfig @@ -75,6 +75,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set # CONFIG_SPL_PINMUX is not set CONFIG_SPL_PINCONF=y CONFIG_DM_PMIC=y diff --git a/configs/chromebook_minnie_defconfig b/configs/chromebook_minnie_defconfig index 46e1c183a2..bacfafb539 100644 --- a/configs/chromebook_minnie_defconfig +++ b/configs/chromebook_minnie_defconfig @@ -74,6 +74,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set # CONFIG_SPL_PINMUX is not set CONFIG_SPL_PINCONF=y CONFIG_DM_PMIC=y diff --git a/configs/chromebook_speedy_defconfig b/configs/chromebook_speedy_defconfig index 34cf727abc..370a40df3e 100644 --- a/configs/chromebook_speedy_defconfig +++ b/configs/chromebook_speedy_defconfig @@ -74,6 +74,7 @@ CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y +# CONFIG_SPL_PINCTRL_FULL is not set CONFIG_DM_PMIC=y # CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_PMIC_RK8XX=y
At present libfdt is included in SPL/TPL if SPL/TPL_OF_CONTROL is enabled. But if of-platdata is in use this is not required. Update the condition to avoid building this extra code. This ensures that if a libfdt function is used it will produce a link error rather than silently increasing the build size.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v5: - Drop rockchip patches as those boards have been fixed
Changes in v4: - Add new patch for rockchip build errors - Add new patch for omap MMC build errors - Add new patch for rockchip chromebook build errors - Pull out patches into a new series - Add new patches to handle build failures
Changes in v3: None
lib/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig index 144a54da28..854f0990c5 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -501,7 +501,7 @@ config OF_LIBFDT_OVERLAY
config SPL_OF_LIBFDT bool "Enable the FDT library for SPL" - default y if SPL_OF_CONTROL + default y if SPL_OF_CONTROL && !SPL_OF_PLATDATA help This enables the FDT library (libfdt). It provides functions for accessing binary device tree images in memory, such as adding and @@ -522,7 +522,7 @@ config SPL_OF_LIBFDT_ASSUME_MASK
config TPL_OF_LIBFDT bool "Enable the FDT library for TPL" - default y if TPL_OF_CONTROL + default y if TPL_OF_CONTROL && !TPL_OF_PLATDATA help This enables the FDT library (libfdt). It provides functions for accessing binary device tree images in memory, such as adding and
These functions cannot work with of-platdata since libfdt is not available. At present when dev_read_...() functions are used it produces error messages about ofnode which is confusing.
Adjust the Makefile and header to produce an error message for the actual dev_read...() function which is called. This makes it easier to see what code needs to be converted for use with of-platdata.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v5: None Changes in v4: None Changes in v3: - Fix eth_dev_get_mac_address() call dev_read...() only when available
drivers/core/Makefile | 4 +++- include/dm/read.h | 3 +-- net/eth-uclass.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/core/Makefile b/drivers/core/Makefile index c707026a3a..0fd09abc40 100644 --- a/drivers/core/Makefile +++ b/drivers/core/Makefile @@ -14,6 +14,8 @@ obj-$(CONFIG_OF_LIVE) += of_access.o of_addr.o ifndef CONFIG_DM_DEV_READ_INLINE obj-$(CONFIG_OF_CONTROL) += read.o endif -obj-$(CONFIG_OF_CONTROL) += of_extra.o ofnode.o read_extra.o +ifdef CONFIG_$(SPL_TPL_)OF_LIBFDT +obj-$(CONFIG_$(SPL_TPL_)OF_CONTROL) += of_extra.o ofnode.o read_extra.o +endif
ccflags-$(CONFIG_DM_DEBUG) += -DDEBUG diff --git a/include/dm/read.h b/include/dm/read.h index 03c15b8550..79a2a4ec8c 100644 --- a/include/dm/read.h +++ b/include/dm/read.h @@ -43,8 +43,7 @@ static inline bool dev_of_valid(const struct udevice *dev) return ofnode_valid(dev_ofnode(dev)); }
-#ifndef CONFIG_DM_DEV_READ_INLINE - +#if !defined(CONFIG_DM_DEV_READ_INLINE) || CONFIG_IS_ENABLED(OF_PLATDATA) /** * dev_read_u32() - read a 32-bit integer from a device's DT property * diff --git a/net/eth-uclass.c b/net/eth-uclass.c index 8bf2eabe90..abefda0b0c 100644 --- a/net/eth-uclass.c +++ b/net/eth-uclass.c @@ -467,7 +467,7 @@ static int eth_pre_unbind(struct udevice *dev)
static bool eth_dev_get_mac_address(struct udevice *dev, u8 mac[ARP_HLEN]) { -#if IS_ENABLED(CONFIG_OF_CONTROL) +#if CONFIG_IS_ENABLED(OF_CONTROL) const uint8_t *p;
p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
participants (8)
-
Bartosz Golaszewski -
Bartosz Golaszewski -
Faiz Abbas -
Kever Yang -
Lokesh Vutla -
Peng Fan -
Simon Glass -
Tom Rini