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 <[email protected]> >>> 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? >> >> 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. 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. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
