From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jagan Teki <jagannadh.teki@gmail.com>
Date: Wed, 28 Mar 2018 15:22:20 +0530
Subject: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts
 files from Linux
In-Reply-To: <a4251262-c61c-560d-8bb9-28422de7a9d0@arm.com>
References: <20180314015715.15615-1-andre.przywara@arm.com>
 <20180314015715.15615-14-andre.przywara@arm.com>
 <CAD6G_RRukdWS_NCe9+7hzcWOgZXz9Vc6CCchfaV4aD2DwK-LCQ@mail.gmail.com>
 <c0e0d875-4f54-93ed-ca04-98658d0a483e@arm.com>
 <CAD6G_RSEYQzPGqd=4rwd-YrFFb=f8SsXV-Djw5ihzP2_yLex1g@mail.gmail.com>
 <a4251262-c61c-560d-8bb9-28422de7a9d0@arm.com>
Message-ID: <CAD6G_RTVsDW1oFybL15JX=hScrMBgnO0JEXfqjXh2h=3FOHi6g@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: u-boot@lists.denx.de

On Wed, Mar 28, 2018 at 4:23 AM, André Przywara <andre.przywara@arm.com> wrote:
> On 27/03/18 18:58, Jagan Teki wrote:
>> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przywara@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@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.
>>
>> 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".

I don't think so, Idea about migrating to BLK, DM_MMC should remove
#ifdef code with DM vs non-DM such that the driver should have DM
version with DT along with PLATDATA

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

Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to
build SPL even with SPL_DM=y

SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA

aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
`.text' is not within region `.sram'
aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in
region `.sram'
aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
`.text' is not within region `.sram'
aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section
`.text' is not within region `.sram'
aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes

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

platdata available only for SPL, not for U-Boot proper.

I agree that clock might be more hairy for now. and we can go with DT
for U-Boot proper and just grab the minimum properties which are
required for probe and rest we can use the driver as before, so-that
regulator, clock, gpio, reset, pinctrl we use step by step.