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

[Maxime Ripard]

Hi,

On Sat, Mar 24, 2018 at 01:07:27AM +0000, André Przywara wrote:
> On 23/03/18 18:14, Jagan Teki wrote:
> > On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara at arm.com> wrote:
> >> Update the .dts files for the various boards with an Allwinner A64 SoC.
> >> This is as of v4.15-rc9, exactly Linux commit:
> 
> ....
> 
> >>
> >>  &mmc2 {
> >>         pinctrl-names = "default";
> >>         pinctrl-0 = <&mmc2_pins>;
> >> -       vmmc-supply = <&reg_vcc3v3>;
> >> +       vmmc-supply = <&reg_dcdc1>;
> > 
> > These AXP regulator stuff need to wait until the relevant driver
> > supported through dt
> 
> Well, we could take the two patches I had in v3 that revert this change.
> As mentioned before, DCDC1 is an always-on regulator anyways.
> 
> But actually that's not our problem, as we don't define DM_REGULATORS,
> so we will never parse those properties.
> 
> Instead:
> 
> > otherwise moving to DM_MMC might fail to get the
> > regulator? [1]
> > [1] https://patchwork.ozlabs.org/patch/887405/
> 
> Ah, thanks for the link, I totally missed that.
> So as Heinrich rightfully feared in his first patch, this change - for
> all sunxi boards - breaks most of them: The DM-MMC part of the sunxi MMC
> driver is not ready for any other SoC than the A20:
> a) The only compatible string it knows is "allwinner,sun5i-a13-mmc".
> b) It assumes the old style clocks, even without checking if the
> referenced nodes are compatible.
> 
> So while a) is trivial to fix (U-Boot probably does not need to care
> about the differences in the MMC controllers of the different SoCs), b)
> is more of a beast.
> I started looking into an easy implementation of the new clocks,
> basically just enough to get MMC going, for the H3/H5 and A64. This
> could be extended for other clocks once we need them.
> But I am afraid this is not 2018.05 material anymore.
> 
> So what do we do here?
> 
> 1) Just switch over A20? The A20 DTs in U-Boot use the old-style clocks
> still, so that's fine. And we postpone the DM-MMC switch for the rest
> until we have some DM new-style clock driver?

I'm not sure I'd like to do that to be honest, this sounds like
something that will never happen.

> 2) Push forward on some simple sunxi-ng MMC clock driver?

That one would work for me

> 3) Don't use DM_MMC at all?

Given the warning that was set for the next release, I'm not sure we
have much choice unfortunately.

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/20180327/590e72a8/attachment.sig>