From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 14 May 2020 11:45:36 -0400 Subject: [PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata In-Reply-To: <175f17aa-4827-4f5f-a01d-7b0f90dfa977@ti.com> References: <914e4c85-fd47-2cfa-25b1-06488fc5876e@ti.com> <20200501183248.GC12564@bill-the-cat> <2f9b6c44-6f65-1ebe-2f85-47877539adba@ti.com> <20200514145956.GB4794@bill-the-cat> <175f17aa-4827-4f5f-a01d-7b0f90dfa977@ti.com> Message-ID: <20200514154536.GC4794@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: > >>>>> > >>>>> pt., 1 maj 2020 o 20:32 Tom Rini napisa?(a): > >>>>>> > >>>>>> On Thu, Apr 30, 2020 at 01:43:30PM +0200, Bartosz Golaszewski wrote: > >>>>>>> wt., 28 kwi 2020 o 09:01 Faiz Abbas 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: