On Mon, Jul 16, 2018 at 4:38 PM, Andre Przywara <andre.przyw...@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 <ja...@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/ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
