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). So I would suggest we push the clock DM driver forward first [1], implementing the new CCU binding, then possibly convert over the pre-H3 boards. And meanwhile we try to appease the maintainers to not remove any boards which don't support DM_MMC, because the purpose of U-Boot should be to get boards booting and not to have some fancy driver model just for the sake of it.
Cheers, Andre.