Hi Maxime,
thanks for the answer.
On 27/03/18 15:30, Maxime Ripard wrote:
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.
OK. So meanwhile I have something almost(TM) working: - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually (I did it the U-Boot way, not pulling in any super-fancy Linux code). Porting this over to H3/H5 and other SoCs should be trivial: copy/paste for now. We can look at how to unify this later. - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is also not too bad, but I seem to miss a bit in here, as it times out. Will debug this tonight. - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking the single bit in :-(
That looks tight to still get into this merge window, though, at least if we follow the usual process.
Keep you posted.
Cheers, Andre.