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

[Jagan Teki <jagannadh.teki@gmail.com>]

On Tue, Mar 27, 2018 at 8:13 PM, Andre Przywara <andre.przywara@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@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 :-(

I did this missing DM work like pinctrl, reset and clk and unable to
send because of size issues. which was with v2017.03.

I'm thinking DM_MMC should wait till the driver should have support of
these feature with all family SOC's

Jagan.

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.