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

[Chen-Yu Tsai]

Hi,

On Tue, Mar 27, 2018 at 10:43 PM, Andre Przywara <andre.przywara at arm.com> wrote:
> 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.

You could post an initial version during the merge window, and refine it
in the following two weeks? AFAIK the rules allow for it to be merged for
the coming release, instead of the next.

Curiously, U-boot repositories don't have -next branches. Is that a
maintainer preference? Having one would help developers in a way as
to not have to hunt down prerequisites and try to figure out whether
they have passed review and will be merged or not, and also avoid
conflicts with other to-be-queued patches. I know this takes extra
effort from the maintainer to possibly rebase or manage conflicts
after a new merge window has opened, as I personally manage sunxi-next
for the Linux kernel to serve as sort of an integration branch for
others. I'm asking is it possible to have -next, even just for sunxi.

>
> Keep you posted.

I'm interested. IMHO we don't need full blown drivers like in Linux.
We should be able to get away with selectively supporting only the
resources needed for the peripherals supported / actively used in U-boot.
This goes for clocks, resets, pinctrl, regulators, etc..

Regards
ChenYu