[U-Boot] [PATCH 00/25] sunxi: Enable DM_MMC for U-Boot proper

[Jagan Teki <jagan@amarulasolutions.com>]

On Mon, Jul 16, 2018 at 4:38 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 16/07/18 10:52, Maxime Ripard wrote:
>> On Mon, Jul 16, 2018 at 04:35:09PM +0800, Chen-Yu Tsai wrote:
>>> On Mon, Jul 16, 2018 at 4:19 PM, Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>> Enabling DM_MMC is not straight forward for Allwinner SoC's to
>>>> make proper compatibility in mmc driver vs DT nodes.
>>>>
>>>> Existing dm code for ahb gate clock will be suitable to handle
>>>> sun4i,5i,6i and 7i U-Boot specific mmc dt nodes, which are different
>>>> from Linux in terms of clocks phandle notation.
>>>>
>>>> U-Boot DT clocks phandle follow direct ahb and clock address on
>>>> node definition with specific bit position, but Linux clocks phandle
>>>> follow macros to define AHB and MMC clocks so-that the ccu driver
>>>> will set the bits accordingly.
>>>
>>> And that has been deprecated upstream.
>>>
>>>> Clocks phandle notations in U-Boot for higher Allwinner SoC start
>>>> from sun8i, sun50i are following Linux notation so-that both Linux
>>>> and U-Boot can have common node definition.
>>>
>>> So basically you're saying the additional code for clock/reset
>>> handling through the device tree only works for half of the SoCs,
>>> based on a deprecated device tree binding. Which means we're
>>> going to throw it out some time in the future. Is it worth the
>>> churn of driver and device tree changes?
>>>
>>> IMHO the new clock handling code is no better than the old. The only
>>> thing that has changed is how the clock register address is derived.
>>> Not even the index numbers, which BTW are actual bit offsets, for
>>> the AHB gates from the device tree are used. Neither is the device
>>> tree used for the AHB resets.
>>
>> I'd say that it's even worse. We want an actual, common, clock
>> driver. Not a quick hack that doesn't solve any of the issues we're
>> facing.
>
> So is the purpose of this whole series to just comply with the
> deprecation of non-DM_MMC configurations?
> As mentioned before I am wondering how useful this is, and if we could
> ever get rid of those hardcoded hacks for the SPL anyway (so the driver
> would technically be DM_MMC compliant, but still had non-DM_MMC code in).

The migration idea about DM_MMC would be for U-Boot proper[2] (not for
SPL as of now). Even if we put the migration aside, we have a problem
with SPL size for DM_MMC for arm64 SoCs. indeed we need to wait for
this to fix for having full DM_MMC code.

[2] https://patchwork.ozlabs.org/patch/933761/