From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jagan Teki Date: Mon, 16 Jul 2018 17:12:41 +0530 Subject: [U-Boot] [PATCH 00/25] sunxi: Enable DM_MMC for U-Boot proper In-Reply-To: <2db0192e-b50d-836f-17d5-87502725bce7@arm.com> References: <20180716081956.32434-1-jagan@amarulasolutions.com> <20180716095203.m5nkr4tt24ve4km4@flea.home> <2db0192e-b50d-836f-17d5-87502725bce7@arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Jul 16, 2018 at 4:38 PM, Andre Przywara 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 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/