
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@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 = <®_vcc3v3>;
vmmc-supply = <®_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?
- 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.
- Push forward on some simple sunxi-ng MMC clock driver?
That one would work for me
- 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