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

[Andre Przywara]

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 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.

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.