Hi,
On 28/03/18 10:52, Jagan Teki wrote:
> On Wed, Mar 28, 2018 at 4:23 AM, André Przywara <andre.przyw...@arm.com>
> wrote:
>> On 27/03/18 18:58, Jagan Teki wrote:
>>> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przyw...@arm.com>
>>> wrote:
>>>> On 23/03/18 18:14, Jagan Teki wrote:
>>>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przyw...@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".
>
> 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
Yes, but how do you want to make this happen in the one remaining week
of the merge window? For some reason I was totally unaware of this
deadline, and we should have started working on this months ago. But my
DeLorean is in the garage, so we can only look forward from here.
Which means we start with just DM_MMC, but not DM_SPL_MMC, and hope that
this threat of "Boards not converted by this time may be removed in a
subsequent release." does not really apply to sunxi as strictly as put
in this file.
The rest comes over time, giving us opportunity to find solutions for
the space constraint problems.
>> 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
??? I said we should *not* #define DM_SPL_MMC, because of (not only)
this reason. If we follow Heinrich's patch, it just selects DM_MMC, so
no changes for the SPL.
> 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
Sure, no surprise.
>> 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.
Yes, that's what I meant: fixed platdata for SPL, U-Boot proper gets the
full DT glory.
> 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.
That is what I was trying to say ;-)
Cheers,
Andre.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
