From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Date: Tue, 27 Mar 2018 16:30:48 +0200 Subject: [U-Boot] [PATCH v4 13/19] sunxi: DT: A64: update board .dts files from Linux In-Reply-To: References: <20180314015715.15615-1-andre.przywara@arm.com> <20180314015715.15615-14-andre.przywara@arm.com> Message-ID: <20180327143048.a2agt6rzjvavowzl@flea> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi, On Sat, Mar 24, 2018 at 01:07:27AM +0000, Andr=C3=A9 Przywara wrote: > On 23/03/18 18:14, Jagan Teki wrote: > > On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara wrote: > >> Update the .dts files for the various boards with an Allwinner A64 SoC. > >> This is as of v4.15-rc9, exactly Linux commit: >=20 > .... >=20 > >> > >> &mmc2 { > >> pinctrl-names =3D "default"; > >> pinctrl-0 =3D <&mmc2_pins>; > >> - vmmc-supply =3D <®_vcc3v3>; > >> + vmmc-supply =3D <®_dcdc1>; > >=20 > > These AXP regulator stuff need to wait until the relevant driver > > supported through dt >=20 > 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. >=20 > But actually that's not our problem, as we don't define DM_REGULATORS, > so we will never parse those properties. >=20 > Instead: >=20 > > otherwise moving to DM_MMC might fail to get the > > regulator? [1] > > [1] https://patchwork.ozlabs.org/patch/887405/ >=20 > Ah, thanks for the link, I totally missed that. > So as Heinrich rightfully feared in his first patch, this change - for > all sunxi boards - breaks most of them: The DM-MMC part of the sunxi MMC > driver is not ready for any other SoC than the A20: > a) The only compatible string it knows is "allwinner,sun5i-a13-mmc". > b) It assumes the old style clocks, even without checking if the > referenced nodes are compatible. >=20 > So while a) is trivial to fix (U-Boot probably does not need to care > about the differences in the MMC controllers of the different SoCs), b) > is more of a beast. > I started looking into an easy implementation of the new clocks, > basically just enough to get MMC going, for the H3/H5 and A64. This > could be extended for other clocks once we need them. > But I am afraid this is not 2018.05 material anymore. >=20 > So what do we do here? >=20 > 1) Just switch over A20? The A20 DTs in U-Boot use the old-style clocks > still, so that's fine. And we postpone the DM-MMC switch for the rest > until we have some DM new-style clock driver? I'm not sure I'd like to do that to be honest, this sounds like something that will never happen. > 2) Push forward on some simple sunxi-ng MMC clock driver? That one would work for me > 3) Don't use DM_MMC at all? Given the warning that was set for the next release, I'm not sure we have much choice unfortunately. Maxime --=20 Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: