[PATCH v5 0/4] of-platdata: Avoid building libfdt

[PATCH v5 0/4] of-platdata: Avoid building libfdt

[Simon Glass]

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(-)

-- 
2.26.2.303.gf8c07b1a785-goog

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Simon Glass]

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);
 
-- 
2.26.2.303.gf8c07b1a785-goog

[PATCH v5 2/4] rockchip: pinctrl: Disable full pinctrl for SPL

[Simon Glass]

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
-- 
2.26.2.303.gf8c07b1a785-goog

[PATCH v5 3/4] spl: Allow SPL/TPL to use of-platdata without libfdt

[Simon Glass]

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
-- 
2.26.2.303.gf8c07b1a785-goog

[PATCH v5 4/4] dm: core: Don't include ofnode functions with of-platdata

[Simon Glass]

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);
-- 
2.26.2.303.gf8c07b1a785-goog

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Peng Fan]

> 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>

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200427/91d1cc69/attachment.sig>

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Lokesh Vutla]

+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!
> 

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Faiz Abbas]

+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

[PATCH v5 2/4] rockchip: pinctrl: Disable full pinctrl for SPL

[Kever Yang]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Bartosz Golaszewski]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200501/eb400b7a/attachment.sig>

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Bartosz Golaszewski]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Simon Glass]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Faiz Abbas]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Bartosz Golaszewski]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Faiz Abbas]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Tom Rini]

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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200514/d6caa171/attachment.sig>

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Faiz Abbas]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200514/d07dc831/attachment.sig>

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Simon Glass]

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

[PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Simon Glass]

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