[U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux
André Przywara
andre.przywara at arm.com
Tue Mar 27 22:53:35 UTC 2018
On 27/03/18 18:58, Jagan Teki wrote:
> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przywara at arm.com> 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 = <®_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.
>
> May it's good option to look at v3 changes, since DM_MMC Migration
> expires in coming release, dt changes which are related to MMC we can
> wait for proper supported feature get IN(like pinctrl, clock, reset),
> that means we should anyway need to move DM_MMC but with working dt
> changes.
>
> The big question for me here is about SPL, I'm sure we can get the
> size issues. May be we try platdata but in any case we need to enable
> DM ie increase the size (atleast for A64, H5)
So my understanding is that those DM_<SUBSYS> defines are just for
U-Boot proper, and the SPL needs extra symbols to be also "DMed".
See the definition of CONFIG_IS_ENABLED().
So by just #defining CONFIG_DM_MMC the SPL still looks the same (using
the non-DM code), and indeed I don't run into size issues with the SPL.
Given the uniformity of at least the MMC device in sunxi, I think in the
medium term we get away with some simple platdata, without pulling the
DT into SPL. The clocks might be a bit more hairy here, though. But
that's nothing for *now* to solve.
Just getting cheeky and wonder if we actually need to touch the clocks
since the boot ROM has actually done all this work already (since we
always load from the same media as the boot ROOM).
Cheers,
Andre.
More information about the U-Boot
mailing list