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
> 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.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
