[U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux

[Maxime Ripard]

On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote:
> >> May it's good option to look at v3 changes, since DM_MMC Migration
> >> expires in coming release, dt changes which are related to MMC we can
> >> wait for proper supported feature get IN(like pinctrl, clock, reset),
> >> that means we should anyway need to move DM_MMC but with working dt
> >> changes.
> >>
> >> The big question for me here is about SPL, I'm sure we can get the
> >> size issues. May be we try platdata but in any case we need to enable
> >> DM ie increase the size (atleast for A64, H5)
> >
> > So my understanding is that those DM_<SUBSYS> defines are just for
> > U-Boot proper, and the SPL needs extra symbols to be also "DMed".
> 
> I don't think so, Idea about migrating to BLK, DM_MMC should remove
> #ifdef code with DM vs non-DM such that the driver should have DM
> version with DT along with PLATDATA

I'm not even sure what is the point of having the DM in the SPL. We
won't be able to have any of the benefits due to our size constraint.

> > See the definition of CONFIG_IS_ENABLED().
> > So by just #defining CONFIG_DM_MMC the SPL still looks the same (using
> > the non-DM code), and indeed I don't run into size issues with the SPL.
> 
> Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to
> build SPL even with SPL_DM=y
> 
> SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA
> 
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in
> region `.sram'
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
> `.text' is not within region `.sram'
> aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes
> 
> > Given the uniformity of at least the MMC device in sunxi, I think in the
> > medium term  we get away with some simple platdata, without pulling the
> > DT into SPL. The clocks might be a bit more hairy here, though. But
> > that's nothing for *now* to solve.
> 
> platdata available only for SPL, not for U-Boot proper.
> 
> I agree that clock might be more hairy for now. and we can go with DT
> for U-Boot proper and just grab the minimum properties which are
> required for probe and rest we can use the driver as before, so-that
> regulator, clock, gpio, reset, pinctrl we use step by step.

I agree.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180328/8266e62e/attachment.sig>