| Message ID | 20180314015715.15615-14-andre.przywara@arm.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
| Series | sunxi: sync H3, H5, A64 DTs from mainline Linux | expand |
On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: > Update the .dts files for the various boards with an Allwinner A64 SoC. > This is as of v4.15-rc9, exactly Linux commit: > commit bdfe4cebea11476d278b1b98dd0f7cdac8269d62 > Author: Icenowy Zheng <icenowy@aosc.io> > Date: Fri Nov 10 17:26:54 2017 +0800 > arm64: allwinner: a64: add Ethernet PHY regulator for several boards > > It updates the existing DT files, adds the newly added axp803.dtsi and > removes our temporary kludge file to get Ethernet support in U-Boot. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> > --- > arch/arm/dts/axp803.dtsi | 150 ++++++++++++++++++++ > arch/arm/dts/sun50i-a64-bananapi-m64.dts | 161 +++++++++++++++++++-- > arch/arm/dts/sun50i-a64-nanopi-a64.dts | 108 ++++++++++++-- > arch/arm/dts/sun50i-a64-olinuxino.dts | 131 +++++++++++++++-- > arch/arm/dts/sun50i-a64-orangepi-win.dts | 7 +- > arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 20 --- > arch/arm/dts/sun50i-a64-pine64-plus.dts | 17 ++- > arch/arm/dts/sun50i-a64-pine64.dts | 178 +++++++++++++++++++++++- > 8 files changed, 716 insertions(+), 56 deletions(-) > create mode 100644 arch/arm/dts/axp803.dtsi > delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi > > diff --git a/arch/arm/dts/axp803.dtsi b/arch/arm/dts/axp803.dtsi > new file mode 100644 > index 0000000000..ff8af52743 > --- /dev/null > +++ b/arch/arm/dts/axp803.dtsi > @@ -0,0 +1,150 @@ > +/* > + * Copyright 2017 Icenowy Zheng <icenowy@aosc.xyz> > + * > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > + * > + * a) This file is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of the > + * License, or (at your option) any later version. > + * > + * This file is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +/* > + * AXP803 Integrated Power Management Chip > + * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf > + */ > + > +&axp803 { > + interrupt-controller; > + #interrupt-cells = <1>; > + > + regulators { > + /* Default work frequency for buck regulators */ > + x-powers,dcdc-freq = <3000>; > + > + reg_aldo1: aldo1 { > + regulator-name = "aldo1"; > + }; > + > + reg_aldo2: aldo2 { > + regulator-name = "aldo2"; > + }; > + > + reg_aldo3: aldo3 { > + regulator-name = "aldo3"; > + }; > + > + reg_dc1sw: dc1sw { > + regulator-name = "dc1sw"; > + }; > + > + reg_dcdc1: dcdc1 { > + regulator-name = "dcdc1"; > + }; > + > + reg_dcdc2: dcdc2 { > + regulator-name = "dcdc2"; > + }; > + > + reg_dcdc3: dcdc3 { > + regulator-name = "dcdc3"; > + }; > + > + reg_dcdc4: dcdc4 { > + regulator-name = "dcdc4"; > + }; > + > + reg_dcdc5: dcdc5 { > + regulator-name = "dcdc5"; > + }; > + > + reg_dcdc6: dcdc6 { > + regulator-name = "dcdc6"; > + }; > + > + reg_dldo1: dldo1 { > + regulator-name = "dldo1"; > + }; > + > + reg_dldo2: dldo2 { > + regulator-name = "dldo2"; > + }; > + > + reg_dldo3: dldo3 { > + regulator-name = "dldo3"; > + }; > + > + reg_dldo4: dldo4 { > + regulator-name = "dldo4"; > + }; > + > + reg_eldo1: eldo1 { > + regulator-name = "eldo1"; > + }; > + > + reg_eldo2: eldo2 { > + regulator-name = "eldo2"; > + }; > + > + reg_eldo3: eldo3 { > + regulator-name = "eldo3"; > + }; > + > + reg_fldo1: fldo1 { > + regulator-name = "fldo1"; > + }; > + > + reg_fldo2: fldo2 { > + regulator-name = "fldo2"; > + }; > + > + reg_ldo_io0: ldo-io0 { > + regulator-name = "ldo-io0"; > + status = "disabled"; > + }; > + > + reg_ldo_io1: ldo-io1 { > + regulator-name = "ldo-io1"; > + status = "disabled"; > + }; > + > + reg_rtc_ldo: rtc-ldo { > + /* RTC_LDO is a fixed, always-on regulator */ > + regulator-always-on; > + regulator-min-microvolt = <3000000>; > + regulator-max-microvolt = <3000000>; > + regulator-name = "rtc-ldo"; > + }; > + }; > +}; > diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64.dts b/arch/arm/dts/sun50i-a64-bananapi-m64.dts > index 02db114113..4a8d3f83a3 100644 > --- a/arch/arm/dts/sun50i-a64-bananapi-m64.dts > +++ b/arch/arm/dts/sun50i-a64-bananapi-m64.dts > @@ -1,6 +1,5 @@ > /* > * Copyright (c) 2016 ARM Ltd. > - * Copyright (C) 2017 Jagan Teki <jteki@openedev.com> > * > * This file is dual-licensed: you can use it either under the terms > * of the GPL or the X11 license, at your option. Note that this dual > @@ -52,6 +51,7 @@ > compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64"; > > aliases { > + ethernet0 = &emac; > serial0 = &uart0; > serial1 = &uart1; > }; > @@ -60,14 +60,25 @@ > stdout-path = "serial0:115200n8"; > }; > > - reg_vcc3v3: vcc3v3 { > - compatible = "regulator-fixed"; > - regulator-name = "vcc3v3"; > - regulator-min-microvolt = <3300000>; > - regulator-max-microvolt = <3300000>; > + wifi_pwrseq: wifi_pwrseq { > + compatible = "mmc-pwrseq-simple"; > + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */ > }; > }; > > +&ehci1 { > + status = "okay"; > +}; > + > +&emac { > + pinctrl-names = "default"; > + pinctrl-0 = <&rgmii_pins>; > + phy-mode = "rgmii"; > + phy-handle = <&ext_rgmii_phy>; > + phy-supply = <®_dc1sw>; > + status = "okay"; > +}; > + > &i2c1 { > pinctrl-names = "default"; > pinctrl-0 = <&i2c1_pins>; > @@ -78,10 +89,17 @@ > bias-pull-up; > }; > > +&mdio { > + ext_rgmii_phy: ethernet-phy@1 { > + compatible = "ethernet-phy-ieee802.3-c22"; > + reg = <1>; > + }; > +}; > + > &mmc0 { > pinctrl-names = "default"; > pinctrl-0 = <&mmc0_pins>; > - vmmc-supply = <®_vcc3v3>; > + vmmc-supply = <®_dcdc1>; > cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; > cd-inverted; > disable-wp; > @@ -92,22 +110,143 @@ > &mmc1 { > pinctrl-names = "default"; > pinctrl-0 = <&mmc1_pins>; > - vmmc-supply = <®_vcc3v3>; > + vmmc-supply = <®_dldo2>; > + vqmmc-supply = <®_dldo4>; > + mmc-pwrseq = <&wifi_pwrseq>; > bus-width = <4>; > non-removable; > status = "okay"; > + > + brcmf: wifi@1 { > + reg = <1>; > + compatible = "brcm,bcm4329-fmac"; > + interrupt-parent = <&r_pio>; > + interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */ > + interrupt-names = "host-wake"; > + }; > }; > > &mmc2 { > pinctrl-names = "default"; > pinctrl-0 = <&mmc2_pins>; > - vmmc-supply = <®_vcc3v3>; > + vmmc-supply = <®_dcdc1>; These AXP regulator stuff need to wait until the relevant driver supported through dt otherwise moving to DM_MMC might fail to get the regulator? [1] [1] https://patchwork.ozlabs.org/patch/887405/ Jagan.
On 23/03/18 18:14, Jagan Teki wrote: > On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >> Update the .dts files for the various boards with an Allwinner A64 SoC. >> This is as of v4.15-rc9, exactly Linux commit: .... >> >> &mmc2 { >> pinctrl-names = "default"; >> pinctrl-0 = <&mmc2_pins>; >> - vmmc-supply = <®_vcc3v3>; >> + vmmc-supply = <®_dcdc1>; > > These AXP regulator stuff need to wait until the relevant driver > supported through dt 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. But actually that's not our problem, as we don't define DM_REGULATORS, so we will never parse those properties. Instead: > otherwise moving to DM_MMC might fail to get the > regulator? [1] > [1] https://patchwork.ozlabs.org/patch/887405/ 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. 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. So what do we do here? 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? 2) Push forward on some simple sunxi-ng MMC clock driver? 3) Don't use DM_MMC at all? Would love to here other's opinions. Cheers, Andre.
Hi, On Sat, Mar 24, 2018 at 01:07:27AM +0000, André Przywara wrote: > On 23/03/18 18:14, Jagan Teki wrote: > > On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: > >> Update the .dts files for the various boards with an Allwinner A64 SoC. > >> This is as of v4.15-rc9, exactly Linux commit: > > .... > > >> > >> &mmc2 { > >> pinctrl-names = "default"; > >> pinctrl-0 = <&mmc2_pins>; > >> - vmmc-supply = <®_vcc3v3>; > >> + vmmc-supply = <®_dcdc1>; > > > > These AXP regulator stuff need to wait until the relevant driver > > supported through dt > > 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. > > But actually that's not our problem, as we don't define DM_REGULATORS, > so we will never parse those properties. > > Instead: > > > otherwise moving to DM_MMC might fail to get the > > regulator? [1] > > [1] https://patchwork.ozlabs.org/patch/887405/ > > 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. > > 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. > > So what do we do here? > > 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
Hi Maxime, thanks for the answer. On 27/03/18 15:30, Maxime Ripard wrote: > Hi, > > On Sat, Mar 24, 2018 at 01:07:27AM +0000, André Przywara wrote: >> On 23/03/18 18:14, Jagan Teki wrote: >>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>>> This is as of v4.15-rc9, exactly Linux commit: >> >> .... >> >>>> >>>> &mmc2 { >>>> pinctrl-names = "default"; >>>> pinctrl-0 = <&mmc2_pins>; >>>> - vmmc-supply = <®_vcc3v3>; >>>> + vmmc-supply = <®_dcdc1>; >>> >>> These AXP regulator stuff need to wait until the relevant driver >>> supported through dt >> >> 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. >> >> But actually that's not our problem, as we don't define DM_REGULATORS, >> so we will never parse those properties. >> >> Instead: >> >>> otherwise moving to DM_MMC might fail to get the >>> regulator? [1] >>> [1] https://patchwork.ozlabs.org/patch/887405/ >> >> 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. >> >> 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. >> >> So what do we do here? >> >> 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. OK. So meanwhile I have something almost(TM) working: - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually (I did it the U-Boot way, not pulling in any super-fancy Linux code). Porting this over to H3/H5 and other SoCs should be trivial: copy/paste for now. We can look at how to unify this later. - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is also not too bad, but I seem to miss a bit in here, as it times out. Will debug this tonight. - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking the single bit in :-( That looks tight to still get into this merge window, though, at least if we follow the usual process. Keep you posted. Cheers, Andre.
On Tue, Mar 27, 2018 at 8:13 PM, Andre Przywara <andre.przywara@arm.com> wrote: > Hi Maxime, > > thanks for the answer. > > On 27/03/18 15:30, Maxime Ripard wrote: >> Hi, >> >> On Sat, Mar 24, 2018 at 01:07:27AM +0000, André Przywara wrote: >>> On 23/03/18 18:14, Jagan Teki wrote: >>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>>>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>>>> This is as of v4.15-rc9, exactly Linux commit: >>> >>> .... >>> >>>>> >>>>> &mmc2 { >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&mmc2_pins>; >>>>> - vmmc-supply = <®_vcc3v3>; >>>>> + vmmc-supply = <®_dcdc1>; >>>> >>>> These AXP regulator stuff need to wait until the relevant driver >>>> supported through dt >>> >>> 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. >>> >>> But actually that's not our problem, as we don't define DM_REGULATORS, >>> so we will never parse those properties. >>> >>> Instead: >>> >>>> otherwise moving to DM_MMC might fail to get the >>>> regulator? [1] >>>> [1] https://patchwork.ozlabs.org/patch/887405/ >>> >>> 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. >>> >>> 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. >>> >>> So what do we do here? >>> >>> 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. > > OK. So meanwhile I have something almost(TM) working: > - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of > the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, > CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually > (I did it the U-Boot way, not pulling in any super-fancy Linux code). > Porting this over to H3/H5 and other SoCs should be trivial: copy/paste > for now. We can look at how to unify this later. > - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is > also not too bad, but I seem to miss a bit in here, as it times out. > Will debug this tonight. > - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking > the single bit in :-( I did this missing DM work like pinctrl, reset and clk and unable to send because of size issues. which was with v2017.03. I'm thinking DM_MMC should wait till the driver should have support of these feature with all family SOC's Jagan.
On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przywara@arm.com> wrote: > On 23/03/18 18:14, Jagan Teki wrote: >> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>> This is as of v4.15-rc9, exactly Linux commit: > > .... > >>> >>> &mmc2 { >>> pinctrl-names = "default"; >>> pinctrl-0 = <&mmc2_pins>; >>> - vmmc-supply = <®_vcc3v3>; >>> + vmmc-supply = <®_dcdc1>; >> >> These AXP regulator stuff need to wait until the relevant driver >> supported through dt > > 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. May it's good option to look at v3 changes, since DM_MMC Migration expires in coming release, dt changes which are related to MMC we can wait for proper supported feature get IN(like pinctrl, clock, reset), that means we should anyway need to move DM_MMC but with working dt changes. The big question for me here is about SPL, I'm sure we can get the size issues. May be we try platdata but in any case we need to enable DM ie increase the size (atleast for A64, H5) Jagan.
On 27/03/18 18:58, Jagan Teki wrote: > On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przywara@arm.com> wrote: >> On 23/03/18 18:14, Jagan Teki wrote: >>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>>> This is as of v4.15-rc9, exactly Linux commit: >> >> .... >> >>>> >>>> &mmc2 { >>>> pinctrl-names = "default"; >>>> pinctrl-0 = <&mmc2_pins>; >>>> - vmmc-supply = <®_vcc3v3>; >>>> + vmmc-supply = <®_dcdc1>; >>> >>> These AXP regulator stuff need to wait until the relevant driver >>> supported through dt >> >> 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. > > May it's good option to look at v3 changes, since DM_MMC Migration > expires in coming release, dt changes which are related to MMC we can > wait for proper supported feature get IN(like pinctrl, clock, reset), > that means we should anyway need to move DM_MMC but with working dt > changes. > > The big question for me here is about SPL, I'm sure we can get the > size issues. May be we try platdata but in any case we need to enable > DM ie increase the size (atleast for A64, H5) So my understanding is that those DM_<SUBSYS> defines are just for U-Boot proper, and the SPL needs extra symbols to be also "DMed". See the definition of CONFIG_IS_ENABLED(). So by just #defining CONFIG_DM_MMC the SPL still looks the same (using the non-DM code), and indeed I don't run into size issues with the SPL. Given the uniformity of at least the MMC device in sunxi, I think in the medium term we get away with some simple platdata, without pulling the DT into SPL. The clocks might be a bit more hairy here, though. But that's nothing for *now* to solve. Just getting cheeky and wonder if we actually need to touch the clocks since the boot ROM has actually done all this work already (since we always load from the same media as the boot ROOM). Cheers, Andre.
On Wed, Mar 28, 2018 at 4:23 AM, André Przywara <andre.przywara@arm.com> wrote: > On 27/03/18 18:58, Jagan Teki wrote: >> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przywara@arm.com> wrote: >>> On 23/03/18 18:14, Jagan Teki wrote: >>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>>>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>>>> This is as of v4.15-rc9, exactly Linux commit: >>> >>> .... >>> >>>>> >>>>> &mmc2 { >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&mmc2_pins>; >>>>> - vmmc-supply = <®_vcc3v3>; >>>>> + vmmc-supply = <®_dcdc1>; >>>> >>>> These AXP regulator stuff need to wait until the relevant driver >>>> supported through dt >>> >>> 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. >> >> May it's good option to look at v3 changes, since DM_MMC Migration >> expires in coming release, dt changes which are related to MMC we can >> wait for proper supported feature get IN(like pinctrl, clock, reset), >> that means we should anyway need to move DM_MMC but with working dt >> changes. >> >> The big question for me here is about SPL, I'm sure we can get the >> size issues. May be we try platdata but in any case we need to enable >> DM ie increase the size (atleast for A64, H5) > > So my understanding is that those DM_<SUBSYS> defines are just for > U-Boot proper, and the SPL needs extra symbols to be also "DMed". I don't think so, Idea about migrating to BLK, DM_MMC should remove #ifdef code with DM vs non-DM such that the driver should have DM version with DT along with PLATDATA > See the definition of CONFIG_IS_ENABLED(). > So by just #defining CONFIG_DM_MMC the SPL still looks the same (using > the non-DM code), and indeed I don't run into size issues with the SPL. Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to build SPL even with SPL_DM=y SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section `.text' is not within region `.sram' aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram' aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section `.text' is not within region `.sram' aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section `.text' is not within region `.sram' aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes > > Given the uniformity of at least the MMC device in sunxi, I think in the > medium term we get away with some simple platdata, without pulling the > DT into SPL. The clocks might be a bit more hairy here, though. But > that's nothing for *now* to solve. platdata available only for SPL, not for U-Boot proper. I agree that clock might be more hairy for now. and we can go with DT for U-Boot proper and just grab the minimum properties which are required for probe and rest we can use the driver as before, so-that regulator, clock, gpio, reset, pinctrl we use step by step.
On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote: > >> May it's good option to look at v3 changes, since DM_MMC Migration > >> expires in coming release, dt changes which are related to MMC we can > >> wait for proper supported feature get IN(like pinctrl, clock, reset), > >> that means we should anyway need to move DM_MMC but with working dt > >> changes. > >> > >> The big question for me here is about SPL, I'm sure we can get the > >> size issues. May be we try platdata but in any case we need to enable > >> DM ie increase the size (atleast for A64, H5) > > > > So my understanding is that those DM_<SUBSYS> defines are just for > > U-Boot proper, and the SPL needs extra symbols to be also "DMed". > > I don't think so, Idea about migrating to BLK, DM_MMC should remove > #ifdef code with DM vs non-DM such that the driver should have DM > version with DT along with PLATDATA I'm not even sure what is the point of having the DM in the SPL. We won't be able to have any of the benefits due to our size constraint. > > See the definition of CONFIG_IS_ENABLED(). > > So by just #defining CONFIG_DM_MMC the SPL still looks the same (using > > the non-DM code), and indeed I don't run into size issues with the SPL. > > Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to > build SPL even with SPL_DM=y > > SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA > > aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section > `.text' is not within region `.sram' > aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in > region `.sram' > aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section > `.text' is not within region `.sram' > aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section > `.text' is not within region `.sram' > aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes > > > Given the uniformity of at least the MMC device in sunxi, I think in the > > medium term we get away with some simple platdata, without pulling the > > DT into SPL. The clocks might be a bit more hairy here, though. But > > that's nothing for *now* to solve. > > platdata available only for SPL, not for U-Boot proper. > > I agree that clock might be more hairy for now. and we can go with DT > for U-Boot proper and just grab the minimum properties which are > required for probe and rest we can use the driver as before, so-that > regulator, clock, gpio, reset, pinctrl we use step by step. I agree. Maxime
Hi, On 28/03/18 10:52, Jagan Teki wrote: > On Wed, Mar 28, 2018 at 4:23 AM, André Przywara <andre.przywara@arm.com> wrote: >> On 27/03/18 18:58, Jagan Teki wrote: >>> On Sat, Mar 24, 2018 at 6:37 AM, André Przywara <andre.przywara@arm.com> wrote: >>>> On 23/03/18 18:14, Jagan Teki wrote: >>>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>>>>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>>>>> This is as of v4.15-rc9, exactly Linux commit: >>>> >>>> .... >>>> >>>>>> >>>>>> &mmc2 { >>>>>> pinctrl-names = "default"; >>>>>> pinctrl-0 = <&mmc2_pins>; >>>>>> - vmmc-supply = <®_vcc3v3>; >>>>>> + vmmc-supply = <®_dcdc1>; >>>>> >>>>> These AXP regulator stuff need to wait until the relevant driver >>>>> supported through dt >>>> >>>> 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. >>> >>> May it's good option to look at v3 changes, since DM_MMC Migration >>> expires in coming release, dt changes which are related to MMC we can >>> wait for proper supported feature get IN(like pinctrl, clock, reset), >>> that means we should anyway need to move DM_MMC but with working dt >>> changes. >>> >>> The big question for me here is about SPL, I'm sure we can get the >>> size issues. May be we try platdata but in any case we need to enable >>> DM ie increase the size (atleast for A64, H5) >> >> So my understanding is that those DM_<SUBSYS> defines are just for >> U-Boot proper, and the SPL needs extra symbols to be also "DMed". > > I don't think so, Idea about migrating to BLK, DM_MMC should remove > #ifdef code with DM vs non-DM such that the driver should have DM > version with DT along with PLATDATA Yes, but how do you want to make this happen in the one remaining week of the merge window? For some reason I was totally unaware of this deadline, and we should have started working on this months ago. But my DeLorean is in the garage, so we can only look forward from here. Which means we start with just DM_MMC, but not DM_SPL_MMC, and hope that this threat of "Boards not converted by this time may be removed in a subsequent release." does not really apply to sunxi as strictly as put in this file. The rest comes over time, giving us opportunity to find solutions for the space constraint problems. >> See the definition of CONFIG_IS_ENABLED(). >> So by just #defining CONFIG_DM_MMC the SPL still looks the same (using >> the non-DM code), and indeed I don't run into size issues with the SPL. > > Even to use DM_MMC in SPL we should enable SPL_DM so I'm unable to > build SPL even with SPL_DM=y ??? I said we should *not* #define DM_SPL_MMC, because of (not only) this reason. If we follow Heinrich's patch, it just selects DM_MMC, so no changes for the SPL. > SPL build, with SPL_DM_, SPL_DM_MMC, SPL_OF_PLATDATA > > aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section > `.text' is not within region `.sram' > aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in > region `.sram' > aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section > `.text' is not within region `.sram' > aarch64-linux-gnu-ld.bfd: address 0x18d18 of u-boot-spl section > `.text' is not within region `.sram' > aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 11104 bytes Sure, no surprise. >> Given the uniformity of at least the MMC device in sunxi, I think in the >> medium term we get away with some simple platdata, without pulling the >> DT into SPL. The clocks might be a bit more hairy here, though. But >> that's nothing for *now* to solve. > > platdata available only for SPL, not for U-Boot proper. Yes, that's what I meant: fixed platdata for SPL, U-Boot proper gets the full DT glory. > I agree that clock might be more hairy for now. and we can go with DT > for U-Boot proper and just grab the minimum properties which are > required for probe and rest we can use the driver as before, so-that > regulator, clock, gpio, reset, pinctrl we use step by step. That is what I was trying to say ;-) Cheers, Andre.
On Wed, Mar 28, 2018 at 4:45 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote: >> >> May it's good option to look at v3 changes, since DM_MMC Migration >> >> expires in coming release, dt changes which are related to MMC we can >> >> wait for proper supported feature get IN(like pinctrl, clock, reset), >> >> that means we should anyway need to move DM_MMC but with working dt >> >> changes. >> >> >> >> The big question for me here is about SPL, I'm sure we can get the >> >> size issues. May be we try platdata but in any case we need to enable >> >> DM ie increase the size (atleast for A64, H5) >> > >> > So my understanding is that those DM_<SUBSYS> defines are just for >> > U-Boot proper, and the SPL needs extra symbols to be also "DMed". >> >> I don't think so, Idea about migrating to BLK, DM_MMC should remove >> #ifdef code with DM vs non-DM such that the driver should have DM >> version with DT along with PLATDATA > > I'm not even sure what is the point of having the DM in the SPL. We > won't be able to have any of the benefits due to our size constraint. True, but what if MIGRATION.txt intention is to remove old or non-dm code after v2018.05? Jagan.
On Wed, Mar 28, 2018 at 11:29:10PM +0530, Jagan Teki wrote: > On Wed, Mar 28, 2018 at 4:45 PM, Maxime Ripard > <maxime.ripard@bootlin.com> wrote: > > On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote: > >> >> May it's good option to look at v3 changes, since DM_MMC Migration > >> >> expires in coming release, dt changes which are related to MMC we can > >> >> wait for proper supported feature get IN(like pinctrl, clock, reset), > >> >> that means we should anyway need to move DM_MMC but with working dt > >> >> changes. > >> >> > >> >> The big question for me here is about SPL, I'm sure we can get the > >> >> size issues. May be we try platdata but in any case we need to enable > >> >> DM ie increase the size (atleast for A64, H5) > >> > > >> > So my understanding is that those DM_<SUBSYS> defines are just for > >> > U-Boot proper, and the SPL needs extra symbols to be also "DMed". > >> > >> I don't think so, Idea about migrating to BLK, DM_MMC should remove > >> #ifdef code with DM vs non-DM such that the driver should have DM > >> version with DT along with PLATDATA > > > > I'm not even sure what is the point of having the DM in the SPL. We > > won't be able to have any of the benefits due to our size constraint. > > True, but what if MIGRATION.txt intention is to remove old or non-dm > code after v2018.05? Then that intention is unreallistic, and unless the one that wrote it can make it fit in the SPL of all platforms, that's just wishful thinking. Maxime
On Thu, Mar 29, 2018 at 2:37 PM, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > On Wed, Mar 28, 2018 at 11:29:10PM +0530, Jagan Teki wrote: >> On Wed, Mar 28, 2018 at 4:45 PM, Maxime Ripard >> <maxime.ripard@bootlin.com> wrote: >> > On Wed, Mar 28, 2018 at 03:22:20PM +0530, Jagan Teki wrote: >> >> >> May it's good option to look at v3 changes, since DM_MMC Migration >> >> >> expires in coming release, dt changes which are related to MMC we can >> >> >> wait for proper supported feature get IN(like pinctrl, clock, reset), >> >> >> that means we should anyway need to move DM_MMC but with working dt >> >> >> changes. >> >> >> >> >> >> The big question for me here is about SPL, I'm sure we can get the >> >> >> size issues. May be we try platdata but in any case we need to enable >> >> >> DM ie increase the size (atleast for A64, H5) >> >> > >> >> > So my understanding is that those DM_<SUBSYS> defines are just for >> >> > U-Boot proper, and the SPL needs extra symbols to be also "DMed". >> >> >> >> I don't think so, Idea about migrating to BLK, DM_MMC should remove >> >> #ifdef code with DM vs non-DM such that the driver should have DM >> >> version with DT along with PLATDATA >> > >> > I'm not even sure what is the point of having the DM in the SPL. We >> > won't be able to have any of the benefits due to our size constraint. >> >> True, but what if MIGRATION.txt intention is to remove old or non-dm >> code after v2018.05? > > Then that intention is unreallistic, and unless the one that wrote it > can make it fit in the SPL of all platforms, that's just wishful > thinking. I do have follow similar approach to remove #ifdef for SPI(_FLASH) areas, I already written to MMC migration thread hope they come back with proper. Jagan.
Hi, On Tue, Mar 27, 2018 at 10:43 PM, Andre Przywara <andre.przywara@arm.com> wrote: > Hi Maxime, > > thanks for the answer. > > On 27/03/18 15:30, Maxime Ripard wrote: >> Hi, >> >> On Sat, Mar 24, 2018 at 01:07:27AM +0000, André Przywara wrote: >>> On 23/03/18 18:14, Jagan Teki wrote: >>>> On Wed, Mar 14, 2018 at 7:27 AM, Andre Przywara <andre.przywara@arm.com> wrote: >>>>> Update the .dts files for the various boards with an Allwinner A64 SoC. >>>>> This is as of v4.15-rc9, exactly Linux commit: >>> >>> .... >>> >>>>> >>>>> &mmc2 { >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&mmc2_pins>; >>>>> - vmmc-supply = <®_vcc3v3>; >>>>> + vmmc-supply = <®_dcdc1>; >>>> >>>> These AXP regulator stuff need to wait until the relevant driver >>>> supported through dt >>> >>> 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. >>> >>> But actually that's not our problem, as we don't define DM_REGULATORS, >>> so we will never parse those properties. >>> >>> Instead: >>> >>>> otherwise moving to DM_MMC might fail to get the >>>> regulator? [1] >>>> [1] https://patchwork.ozlabs.org/patch/887405/ >>> >>> 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. >>> >>> 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. >>> >>> So what do we do here? >>> >>> 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. > > OK. So meanwhile I have something almost(TM) working: > - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of > the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, > CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually > (I did it the U-Boot way, not pulling in any super-fancy Linux code). > Porting this over to H3/H5 and other SoCs should be trivial: copy/paste > for now. We can look at how to unify this later. > - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is > also not too bad, but I seem to miss a bit in here, as it times out. > Will debug this tonight. > - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking > the single bit in :-( > > That looks tight to still get into this merge window, though, at least > if we follow the usual process. You could post an initial version during the merge window, and refine it in the following two weeks? AFAIK the rules allow for it to be merged for the coming release, instead of the next. Curiously, U-boot repositories don't have -next branches. Is that a maintainer preference? Having one would help developers in a way as to not have to hunt down prerequisites and try to figure out whether they have passed review and will be merged or not, and also avoid conflicts with other to-be-queued patches. I know this takes extra effort from the maintainer to possibly rebase or manage conflicts after a new merge window has opened, as I personally manage sunxi-next for the Linux kernel to serve as sort of an integration branch for others. I'm asking is it possible to have -next, even just for sunxi. > > Keep you posted. I'm interested. IMHO we don't need full blown drivers like in Linux. We should be able to get away with selectively supporting only the resources needed for the peripherals supported / actively used in U-boot. This goes for clocks, resets, pinctrl, regulators, etc.. Regards ChenYu
On 30/03/18 05:25, Chen-Yu Tsai wrote: .... >> OK. So meanwhile I have something almost(TM) working: >> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of >> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, >> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually >> (I did it the U-Boot way, not pulling in any super-fancy Linux code). >> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste >> for now. We can look at how to unify this later. >> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is >> also not too bad, but I seem to miss a bit in here, as it times out. >> Will debug this tonight. >> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking >> the single bit in :-( >> >> That looks tight to still get into this merge window, though, at least >> if we follow the usual process. > > You could post an initial version during the merge window, and refine it > in the following two weeks? AFAIK the rules allow for it to be merged for > the coming release, instead of the next. Is that so? I had the impression that this was tightened in the last few releases, so no features would be allowed beyond the merge window anymore. I will try to send something ASAP, but ... > Curiously, U-boot repositories don't have -next branches. Is that a > maintainer preference? Having one would help developers in a way as > to not have to hunt down prerequisites and try to figure out whether > they have passed review and will be merged or not, and also avoid > conflicts with other to-be-queued patches. I know this takes extra > effort from the maintainer to possibly rebase or manage conflicts > after a new merge window has opened, as I personally manage sunxi-next > for the Linux kernel to serve as sort of an integration branch for > others. I'm asking is it possible to have -next, even just for sunxi. > >> >> Keep you posted. > > I'm interested. IMHO we don't need full blown drivers like in Linux. > We should be able to get away with selectively supporting only the > resources needed for the peripherals supported / actively used in U-boot. > This goes for clocks, resets, pinctrl, regulators, etc.. So I have something(TM) working now. This is a bit like a can of worms: - As mentioned above, we need a UCLASS_CLK driver. This is pretty straightforward, one driver per SoC, then something like: int sunxi_clk_enable(clk) { switch (clk->id) { case CLK_MMC0: addr = priv->base + 0x88; setbits_le32(clk_base, BIT(31)); (plus get_rate/set_rate) As you guessed, we just list the clocks we need, in the moment this is UART and MMC. Adding new clocks is easy, other SoCs can be copy&pasted for now, we might find a clever way of code sharing later. One nasty property is the marriage of RESET and CLK in the sunxi-ng clock binding. So we also need a DM reset driver. I need to wrap my head around how to instantiate those at the same time from only one compatible. - Also I realised two days ago that we need a DM pinctrl driver. As this was on my list anyway, I just bit the bullet. Eventually this isn't as bad as it sounds, as I resorted to the "pinmux" property to give me the mux value, so don't need the huge table Linux uses. But: a similar problem as above, as we need to marry this to the already existing DM_GPIO driver, because they share a DT node. So the current status is: - UCLASS_CLK works and looks fairly reasonable. - UCLASS_PINCTRL works, just requires adding a pinmux property to each pinctrl pin group node (just a few), as I proposed last year for Linux[1]. - no UCLASS_RESET for the sunxi-ng resets yet. Hacked badly atm. - The existing UCLASS_GPIO driver clashes with UCLASS_PINCTRL, so I disabled the former for now. - The existing UCLASS_MMC driver got amended to use all of those. This boots on the Pine64, at least via FEL, with USB, MMC and Ethernet working in U-Boot proper. Just in case someone gets impatient: https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP I will try to get rid of the hacks and post an RFC. But, as Jagan mentioned already: eventually the outcome is quite questionable. For the near future we need the non-DM bits (UART + MMC) for the SPL still, so we can't get rid of this code. So technically we support DM_MMC/DM_BLK, but it's not clear what the actual benefit is. Cheers, Andre. [1] http://archive.armlinux.org.uk/lurker/message/20171113.012520.b50dc300.en.html
On Sun, Apr 1, 2018 at 9:28 AM, André Przywara <andre.przywara@arm.com> wrote: > On 30/03/18 05:25, Chen-Yu Tsai wrote: > > .... >>> OK. So meanwhile I have something almost(TM) working: >>> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of >>> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, >>> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually >>> (I did it the U-Boot way, not pulling in any super-fancy Linux code). >>> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste >>> for now. We can look at how to unify this later. >>> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is >>> also not too bad, but I seem to miss a bit in here, as it times out. >>> Will debug this tonight. >>> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking >>> the single bit in :-( >>> >>> That looks tight to still get into this merge window, though, at least >>> if we follow the usual process. >> >> You could post an initial version during the merge window, and refine it >> in the following two weeks? AFAIK the rules allow for it to be merged for >> the coming release, instead of the next. > > Is that so? I had the impression that this was tightened in the last few > releases, so no features would be allowed beyond the merge window > anymore. I will try to send something ASAP, but ... > >> Curiously, U-boot repositories don't have -next branches. Is that a >> maintainer preference? Having one would help developers in a way as >> to not have to hunt down prerequisites and try to figure out whether >> they have passed review and will be merged or not, and also avoid >> conflicts with other to-be-queued patches. I know this takes extra >> effort from the maintainer to possibly rebase or manage conflicts >> after a new merge window has opened, as I personally manage sunxi-next >> for the Linux kernel to serve as sort of an integration branch for >> others. I'm asking is it possible to have -next, even just for sunxi. >> >>> >>> Keep you posted. >> >> I'm interested. IMHO we don't need full blown drivers like in Linux. >> We should be able to get away with selectively supporting only the >> resources needed for the peripherals supported / actively used in U-boot. >> This goes for clocks, resets, pinctrl, regulators, etc.. > > So I have something(TM) working now. This is a bit like a can of worms: > - As mentioned above, we need a UCLASS_CLK driver. This is pretty > straightforward, one driver per SoC, then something like: > int sunxi_clk_enable(clk) > { > switch (clk->id) { > case CLK_MMC0: > addr = priv->base + 0x88; > setbits_le32(clk_base, BIT(31)); > (plus get_rate/set_rate) > As you guessed, we just list the clocks we need, in the moment this is > UART and MMC. Adding new clocks is easy, other SoCs can be copy&pasted > for now, we might find a clever way of code sharing later. > One nasty property is the marriage of RESET and CLK in the sunxi-ng > clock binding. So we also need a DM reset driver. I need to wrap my head > around how to instantiate those at the same time from only one compatible. We could look at how the DM gpio driver currently does it: The compatible matches the driver directly, and the DM bind function creates many child devices using platform data and binds it to the same driver. The device node is also assigned to the same one. AFAIK you have to figure out how to lookup a different driver by name for the child device, e.g. a reset driver to bind to the child device of the clk device. In addition, Philipp from Theobroma Systems posted a series some time ago for sunxi DM conversion, which included some patches that involved creating multiple uclass devices for the same device node. > > - Also I realised two days ago that we need a DM pinctrl driver. As this > was on my list anyway, I just bit the bullet. Eventually this isn't as > bad as it sounds, as I resorted to the "pinmux" property to give me the > mux value, so don't need the huge table Linux uses. > But: a similar problem as above, as we need to marry this to the already > existing DM_GPIO driver, because they share a DT node. Same as the above I guess? And having the pinctrl driver as the base device might work out better. It looks like we won't have gpio/pinctrl exclusivity like we do in Linux, so people should try to avoid shooting themselves in the foot. We could try denying requests based on whether the pinmux value in the register is not the default GPIO / disconnected value. > > So the current status is: > - UCLASS_CLK works and looks fairly reasonable. > - UCLASS_PINCTRL works, just requires adding a pinmux property to each > pinctrl pin group node (just a few), as I proposed last year for Linux[1]. IIRC this didn't go well? We could have a simplified table to cover the use cases we need (again it's probably just UART + MMC). We don't need to declare every single pin. Since a function tends to have the same pinmux value for each used pin within the same pingroup, we could just have a table that maps [SoC, pingroup, function] to pinmux value. And you could just ignore the gpio_{in,out} pinmux nodes. > - no UCLASS_RESET for the sunxi-ng resets yet. Hacked badly atm. > - The existing UCLASS_GPIO driver clashes with UCLASS_PINCTRL, so I > disabled the former for now. > - The existing UCLASS_MMC driver got amended to use all of those. > > This boots on the Pine64, at least via FEL, with USB, MMC and Ethernet > working in U-Boot proper. > > Just in case someone gets impatient: > https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP > > I will try to get rid of the hacks and post an RFC. > > But, as Jagan mentioned already: eventually the outcome is quite > questionable. For the near future we need the non-DM bits (UART + MMC) > for the SPL still, so we can't get rid of this code. So technically we > support DM_MMC/DM_BLK, but it's not clear what the actual benefit is. My thoughts exactly. We end up with either two drivers, one DM and one not, or we have a whole bunch of #ifdefs in the DM driver to trim it down for SPL. Regards ChenYu > > Cheers, > Andre. > > [1] > http://archive.armlinux.org.uk/lurker/message/20171113.012520.b50dc300.en.html >
On Sun, Apr 1, 2018 at 8:11 AM, Chen-Yu Tsai <wens@csie.org> wrote: > On Sun, Apr 1, 2018 at 9:28 AM, André Przywara <andre.przywara@arm.com> wrote: >> On 30/03/18 05:25, Chen-Yu Tsai wrote: >> >> .... >>>> OK. So meanwhile I have something almost(TM) working: >>>> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of >>>> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, >>>> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually >>>> (I did it the U-Boot way, not pulling in any super-fancy Linux code). >>>> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste >>>> for now. We can look at how to unify this later. >>>> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is >>>> also not too bad, but I seem to miss a bit in here, as it times out. >>>> Will debug this tonight. >>>> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking >>>> the single bit in :-( >>>> >>>> That looks tight to still get into this merge window, though, at least >>>> if we follow the usual process. >>> >>> You could post an initial version during the merge window, and refine it >>> in the following two weeks? AFAIK the rules allow for it to be merged for >>> the coming release, instead of the next. >> >> Is that so? I had the impression that this was tightened in the last few >> releases, so no features would be allowed beyond the merge window >> anymore. I will try to send something ASAP, but ... >> >>> Curiously, U-boot repositories don't have -next branches. Is that a >>> maintainer preference? Having one would help developers in a way as >>> to not have to hunt down prerequisites and try to figure out whether >>> they have passed review and will be merged or not, and also avoid >>> conflicts with other to-be-queued patches. I know this takes extra >>> effort from the maintainer to possibly rebase or manage conflicts >>> after a new merge window has opened, as I personally manage sunxi-next >>> for the Linux kernel to serve as sort of an integration branch for >>> others. I'm asking is it possible to have -next, even just for sunxi. >>> >>>> >>>> Keep you posted. >>> >>> I'm interested. IMHO we don't need full blown drivers like in Linux. >>> We should be able to get away with selectively supporting only the >>> resources needed for the peripherals supported / actively used in U-boot. >>> This goes for clocks, resets, pinctrl, regulators, etc.. >> >> So I have something(TM) working now. This is a bit like a can of worms: >> - As mentioned above, we need a UCLASS_CLK driver. This is pretty >> straightforward, one driver per SoC, then something like: >> int sunxi_clk_enable(clk) >> { >> switch (clk->id) { >> case CLK_MMC0: >> addr = priv->base + 0x88; >> setbits_le32(clk_base, BIT(31)); >> (plus get_rate/set_rate) >> As you guessed, we just list the clocks we need, in the moment this is >> UART and MMC. Adding new clocks is easy, other SoCs can be copy&pasted >> for now, we might find a clever way of code sharing later. >> One nasty property is the marriage of RESET and CLK in the sunxi-ng >> clock binding. So we also need a DM reset driver. I need to wrap my head >> around how to instantiate those at the same time from only one compatible. > > We could look at how the DM gpio driver currently does it: The compatible > matches the driver directly, and the DM bind function creates many child > devices using platform data and binds it to the same driver. The device > node is also assigned to the same one. AFAIK you have to figure out how > to lookup a different driver by name for the child device, e.g. a reset > driver to bind to the child device of the clk device. > > In addition, Philipp from Theobroma Systems posted a series some time ago > for sunxi DM conversion, which included some patches that involved creating > multiple uclass devices for the same device node. > >> >> - Also I realised two days ago that we need a DM pinctrl driver. As this >> was on my list anyway, I just bit the bullet. Eventually this isn't as >> bad as it sounds, as I resorted to the "pinmux" property to give me the >> mux value, so don't need the huge table Linux uses. >> But: a similar problem as above, as we need to marry this to the already >> existing DM_GPIO driver, because they share a DT node. > > Same as the above I guess? And having the pinctrl driver as the base device > might work out better. It looks like we won't have gpio/pinctrl exclusivity > like we do in Linux, so people should try to avoid shooting themselves in > the foot. We could try denying requests based on whether the pinmux value > in the register is not the default GPIO / disconnected value. > >> >> So the current status is: >> - UCLASS_CLK works and looks fairly reasonable. >> - UCLASS_PINCTRL works, just requires adding a pinmux property to each >> pinctrl pin group node (just a few), as I proposed last year for Linux[1]. > > IIRC this didn't go well? We could have a simplified table to cover the > use cases we need (again it's probably just UART + MMC). We don't need > to declare every single pin. Since a function tends to have the same > pinmux value for each used pin within the same pingroup, we could just > have a table that maps [SoC, pingroup, function] to pinmux value. And > you could just ignore the gpio_{in,out} pinmux nodes. > >> - no UCLASS_RESET for the sunxi-ng resets yet. Hacked badly atm. >> - The existing UCLASS_GPIO driver clashes with UCLASS_PINCTRL, so I >> disabled the former for now. >> - The existing UCLASS_MMC driver got amended to use all of those. >> >> This boots on the Pine64, at least via FEL, with USB, MMC and Ethernet >> working in U-Boot proper. >> >> Just in case someone gets impatient: >> https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP >> >> I will try to get rid of the hacks and post an RFC. >> >> But, as Jagan mentioned already: eventually the outcome is quite >> questionable. For the near future we need the non-DM bits (UART + MMC) >> for the SPL still, so we can't get rid of this code. So technically we >> support DM_MMC/DM_BLK, but it's not clear what the actual benefit is. > > My thoughts exactly. We end up with either two drivers, one DM and one not, > or we have a whole bunch of #ifdefs in the DM driver to trim it down for > SPL. what about writing glue mmc spl code? like what we did for spi_flash or drivers/mmc/fsl_esdhc_spl.c
Hi, On 08/05/18 11:34, Jagan Teki wrote: > On Sun, Apr 1, 2018 at 8:11 AM, Chen-Yu Tsai <wens@csie.org> wrote: >> On Sun, Apr 1, 2018 at 9:28 AM, André Przywara <andre.przywara@arm.com> wrote: >>> On 30/03/18 05:25, Chen-Yu Tsai wrote: >>> >>> .... >>>>> OK. So meanwhile I have something almost(TM) working: >>>>> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of >>>>> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, >>>>> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually >>>>> (I did it the U-Boot way, not pulling in any super-fancy Linux code). >>>>> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste >>>>> for now. We can look at how to unify this later. >>>>> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is >>>>> also not too bad, but I seem to miss a bit in here, as it times out. >>>>> Will debug this tonight. >>>>> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking >>>>> the single bit in :-( >>>>> >>>>> That looks tight to still get into this merge window, though, at least >>>>> if we follow the usual process. >>>> >>>> You could post an initial version during the merge window, and refine it >>>> in the following two weeks? AFAIK the rules allow for it to be merged for >>>> the coming release, instead of the next. >>> >>> Is that so? I had the impression that this was tightened in the last few >>> releases, so no features would be allowed beyond the merge window >>> anymore. I will try to send something ASAP, but ... >>> >>>> Curiously, U-boot repositories don't have -next branches. Is that a >>>> maintainer preference? Having one would help developers in a way as >>>> to not have to hunt down prerequisites and try to figure out whether >>>> they have passed review and will be merged or not, and also avoid >>>> conflicts with other to-be-queued patches. I know this takes extra >>>> effort from the maintainer to possibly rebase or manage conflicts >>>> after a new merge window has opened, as I personally manage sunxi-next >>>> for the Linux kernel to serve as sort of an integration branch for >>>> others. I'm asking is it possible to have -next, even just for sunxi. >>>> >>>>> >>>>> Keep you posted. >>>> >>>> I'm interested. IMHO we don't need full blown drivers like in Linux. >>>> We should be able to get away with selectively supporting only the >>>> resources needed for the peripherals supported / actively used in U-boot. >>>> This goes for clocks, resets, pinctrl, regulators, etc.. >>> >>> So I have something(TM) working now. This is a bit like a can of worms: >>> - As mentioned above, we need a UCLASS_CLK driver. This is pretty >>> straightforward, one driver per SoC, then something like: >>> int sunxi_clk_enable(clk) >>> { >>> switch (clk->id) { >>> case CLK_MMC0: >>> addr = priv->base + 0x88; >>> setbits_le32(clk_base, BIT(31)); >>> (plus get_rate/set_rate) >>> As you guessed, we just list the clocks we need, in the moment this is >>> UART and MMC. Adding new clocks is easy, other SoCs can be copy&pasted >>> for now, we might find a clever way of code sharing later. >>> One nasty property is the marriage of RESET and CLK in the sunxi-ng >>> clock binding. So we also need a DM reset driver. I need to wrap my head >>> around how to instantiate those at the same time from only one compatible. >> >> We could look at how the DM gpio driver currently does it: The compatible >> matches the driver directly, and the DM bind function creates many child >> devices using platform data and binds it to the same driver. The device >> node is also assigned to the same one. AFAIK you have to figure out how >> to lookup a different driver by name for the child device, e.g. a reset >> driver to bind to the child device of the clk device. >> >> In addition, Philipp from Theobroma Systems posted a series some time ago >> for sunxi DM conversion, which included some patches that involved creating >> multiple uclass devices for the same device node. >> >>> >>> - Also I realised two days ago that we need a DM pinctrl driver. As this >>> was on my list anyway, I just bit the bullet. Eventually this isn't as >>> bad as it sounds, as I resorted to the "pinmux" property to give me the >>> mux value, so don't need the huge table Linux uses. >>> But: a similar problem as above, as we need to marry this to the already >>> existing DM_GPIO driver, because they share a DT node. >> >> Same as the above I guess? And having the pinctrl driver as the base device >> might work out better. It looks like we won't have gpio/pinctrl exclusivity >> like we do in Linux, so people should try to avoid shooting themselves in >> the foot. We could try denying requests based on whether the pinmux value >> in the register is not the default GPIO / disconnected value. >> >>> >>> So the current status is: >>> - UCLASS_CLK works and looks fairly reasonable. >>> - UCLASS_PINCTRL works, just requires adding a pinmux property to each >>> pinctrl pin group node (just a few), as I proposed last year for Linux[1]. >> >> IIRC this didn't go well? We could have a simplified table to cover the >> use cases we need (again it's probably just UART + MMC). We don't need >> to declare every single pin. Since a function tends to have the same >> pinmux value for each used pin within the same pingroup, we could just >> have a table that maps [SoC, pingroup, function] to pinmux value. And >> you could just ignore the gpio_{in,out} pinmux nodes. >> >>> - no UCLASS_RESET for the sunxi-ng resets yet. Hacked badly atm. >>> - The existing UCLASS_GPIO driver clashes with UCLASS_PINCTRL, so I >>> disabled the former for now. >>> - The existing UCLASS_MMC driver got amended to use all of those. >>> >>> This boots on the Pine64, at least via FEL, with USB, MMC and Ethernet >>> working in U-Boot proper. >>> >>> Just in case someone gets impatient: >>> https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP >>> >>> I will try to get rid of the hacks and post an RFC. >>> >>> But, as Jagan mentioned already: eventually the outcome is quite >>> questionable. For the near future we need the non-DM bits (UART + MMC) >>> for the SPL still, so we can't get rid of this code. So technically we >>> support DM_MMC/DM_BLK, but it's not clear what the actual benefit is. >> >> My thoughts exactly. We end up with either two drivers, one DM and one not, >> or we have a whole bunch of #ifdefs in the DM driver to trim it down for >> SPL. > > what about writing glue mmc spl code? like what we did for spi_flash > or drivers/mmc/fsl_esdhc_spl.c So what is your idea here? To make a small SPL driver which directly calls some internal, but exported function from the DM driver, which does the actual work? So that the DM driver has all the DM boilerplate around that function, and the SPL driver does not? But it sounds hairy when it comes to the details ... We could get away with just read support, I guess? Do you feel like giving this a try and see how it looks like? Cheers, Andre.
+ Vasily On Tue, May 8, 2018 at 6:45 PM, Andre Przywara <andre.przywara@arm.com> wrote: > Hi, > > On 08/05/18 11:34, Jagan Teki wrote: >> On Sun, Apr 1, 2018 at 8:11 AM, Chen-Yu Tsai <wens@csie.org> wrote: >>> On Sun, Apr 1, 2018 at 9:28 AM, André Przywara <andre.przywara@arm.com> wrote: >>>> On 30/03/18 05:25, Chen-Yu Tsai wrote: >>>> >>>> .... >>>>>> OK. So meanwhile I have something almost(TM) working: >>>>>> - drivers/clk/sunxi/clk-a64.c, which is a UCLASS_CLK implementation of >>>>>> the clock IDs from allwinner,sun50i-a64-ccu that we need: CLK_BUS_UARTx, >>>>>> CLK_BUS_MMCx, CLK_MMCx. Their implementation is fairly simple, actually >>>>>> (I did it the U-Boot way, not pulling in any super-fancy Linux code). >>>>>> Porting this over to H3/H5 and other SoCs should be trivial: copy/paste >>>>>> for now. We can look at how to unify this later. >>>>>> - drivers/mmc/sunxi_mmc.c extended to use UCLASS_CLK clocks. This is >>>>>> also not too bad, but I seem to miss a bit in here, as it times out. >>>>>> Will debug this tonight. >>>>>> - Cowardly dodging a proper UCLASS_RESET driver for now, instead hacking >>>>>> the single bit in :-( >>>>>> >>>>>> That looks tight to still get into this merge window, though, at least >>>>>> if we follow the usual process. >>>>> >>>>> You could post an initial version during the merge window, and refine it >>>>> in the following two weeks? AFAIK the rules allow for it to be merged for >>>>> the coming release, instead of the next. >>>> >>>> Is that so? I had the impression that this was tightened in the last few >>>> releases, so no features would be allowed beyond the merge window >>>> anymore. I will try to send something ASAP, but ... >>>> >>>>> Curiously, U-boot repositories don't have -next branches. Is that a >>>>> maintainer preference? Having one would help developers in a way as >>>>> to not have to hunt down prerequisites and try to figure out whether >>>>> they have passed review and will be merged or not, and also avoid >>>>> conflicts with other to-be-queued patches. I know this takes extra >>>>> effort from the maintainer to possibly rebase or manage conflicts >>>>> after a new merge window has opened, as I personally manage sunxi-next >>>>> for the Linux kernel to serve as sort of an integration branch for >>>>> others. I'm asking is it possible to have -next, even just for sunxi. >>>>> >>>>>> >>>>>> Keep you posted. >>>>> >>>>> I'm interested. IMHO we don't need full blown drivers like in Linux. >>>>> We should be able to get away with selectively supporting only the >>>>> resources needed for the peripherals supported / actively used in U-boot. >>>>> This goes for clocks, resets, pinctrl, regulators, etc.. >>>> >>>> So I have something(TM) working now. This is a bit like a can of worms: >>>> - As mentioned above, we need a UCLASS_CLK driver. This is pretty >>>> straightforward, one driver per SoC, then something like: >>>> int sunxi_clk_enable(clk) >>>> { >>>> switch (clk->id) { >>>> case CLK_MMC0: >>>> addr = priv->base + 0x88; >>>> setbits_le32(clk_base, BIT(31)); >>>> (plus get_rate/set_rate) >>>> As you guessed, we just list the clocks we need, in the moment this is >>>> UART and MMC. Adding new clocks is easy, other SoCs can be copy&pasted >>>> for now, we might find a clever way of code sharing later. >>>> One nasty property is the marriage of RESET and CLK in the sunxi-ng >>>> clock binding. So we also need a DM reset driver. I need to wrap my head >>>> around how to instantiate those at the same time from only one compatible. >>> >>> We could look at how the DM gpio driver currently does it: The compatible >>> matches the driver directly, and the DM bind function creates many child >>> devices using platform data and binds it to the same driver. The device >>> node is also assigned to the same one. AFAIK you have to figure out how >>> to lookup a different driver by name for the child device, e.g. a reset >>> driver to bind to the child device of the clk device. >>> >>> In addition, Philipp from Theobroma Systems posted a series some time ago >>> for sunxi DM conversion, which included some patches that involved creating >>> multiple uclass devices for the same device node. >>> >>>> >>>> - Also I realised two days ago that we need a DM pinctrl driver. As this >>>> was on my list anyway, I just bit the bullet. Eventually this isn't as >>>> bad as it sounds, as I resorted to the "pinmux" property to give me the >>>> mux value, so don't need the huge table Linux uses. >>>> But: a similar problem as above, as we need to marry this to the already >>>> existing DM_GPIO driver, because they share a DT node. >>> >>> Same as the above I guess? And having the pinctrl driver as the base device >>> might work out better. It looks like we won't have gpio/pinctrl exclusivity >>> like we do in Linux, so people should try to avoid shooting themselves in >>> the foot. We could try denying requests based on whether the pinmux value >>> in the register is not the default GPIO / disconnected value. >>> >>>> >>>> So the current status is: >>>> - UCLASS_CLK works and looks fairly reasonable. >>>> - UCLASS_PINCTRL works, just requires adding a pinmux property to each >>>> pinctrl pin group node (just a few), as I proposed last year for Linux[1]. >>> >>> IIRC this didn't go well? We could have a simplified table to cover the >>> use cases we need (again it's probably just UART + MMC). We don't need >>> to declare every single pin. Since a function tends to have the same >>> pinmux value for each used pin within the same pingroup, we could just >>> have a table that maps [SoC, pingroup, function] to pinmux value. And >>> you could just ignore the gpio_{in,out} pinmux nodes. >>> >>>> - no UCLASS_RESET for the sunxi-ng resets yet. Hacked badly atm. >>>> - The existing UCLASS_GPIO driver clashes with UCLASS_PINCTRL, so I >>>> disabled the former for now. >>>> - The existing UCLASS_MMC driver got amended to use all of those. >>>> >>>> This boots on the Pine64, at least via FEL, with USB, MMC and Ethernet >>>> working in U-Boot proper. >>>> >>>> Just in case someone gets impatient: >>>> https://github.com/apritzel/u-boot/commits/sunxi-dm-WIP >>>> >>>> I will try to get rid of the hacks and post an RFC. >>>> >>>> But, as Jagan mentioned already: eventually the outcome is quite >>>> questionable. For the near future we need the non-DM bits (UART + MMC) >>>> for the SPL still, so we can't get rid of this code. So technically we >>>> support DM_MMC/DM_BLK, but it's not clear what the actual benefit is. >>> >>> My thoughts exactly. We end up with either two drivers, one DM and one not, >>> or we have a whole bunch of #ifdefs in the DM driver to trim it down for >>> SPL. >> >> what about writing glue mmc spl code? like what we did for spi_flash >> or drivers/mmc/fsl_esdhc_spl.c > > So what is your idea here? To make a small SPL driver which directly > calls some internal, but exported function from the DM driver, which > does the actual work? So that the DM driver has all the DM boilerplate > around that function, and the SPL driver does not? But it sounds hairy > when it comes to the details ... > We could get away with just read support, I guess? > > Do you feel like giving this a try and see how it looks like? May be an another option to try, because trying for another stage like TPL seems doesn't suit for A64.
diff --git a/arch/arm/dts/axp803.dtsi b/arch/arm/dts/axp803.dtsi new file mode 100644 index 0000000000..ff8af52743 --- /dev/null +++ b/arch/arm/dts/axp803.dtsi @@ -0,0 +1,150 @@ +/* + * Copyright 2017 Icenowy Zheng <icenowy@aosc.xyz> + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This file is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This file is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/* + * AXP803 Integrated Power Management Chip + * http://files.pine64.org/doc/datasheet/pine64/AXP803_Datasheet_V1.0.pdf + */ + +&axp803 { + interrupt-controller; + #interrupt-cells = <1>; + + regulators { + /* Default work frequency for buck regulators */ + x-powers,dcdc-freq = <3000>; + + reg_aldo1: aldo1 { + regulator-name = "aldo1"; + }; + + reg_aldo2: aldo2 { + regulator-name = "aldo2"; + }; + + reg_aldo3: aldo3 { + regulator-name = "aldo3"; + }; + + reg_dc1sw: dc1sw { + regulator-name = "dc1sw"; + }; + + reg_dcdc1: dcdc1 { + regulator-name = "dcdc1"; + }; + + reg_dcdc2: dcdc2 { + regulator-name = "dcdc2"; + }; + + reg_dcdc3: dcdc3 { + regulator-name = "dcdc3"; + }; + + reg_dcdc4: dcdc4 { + regulator-name = "dcdc4"; + }; + + reg_dcdc5: dcdc5 { + regulator-name = "dcdc5"; + }; + + reg_dcdc6: dcdc6 { + regulator-name = "dcdc6"; + }; + + reg_dldo1: dldo1 { + regulator-name = "dldo1"; + }; + + reg_dldo2: dldo2 { + regulator-name = "dldo2"; + }; + + reg_dldo3: dldo3 { + regulator-name = "dldo3"; + }; + + reg_dldo4: dldo4 { + regulator-name = "dldo4"; + }; + + reg_eldo1: eldo1 { + regulator-name = "eldo1"; + }; + + reg_eldo2: eldo2 { + regulator-name = "eldo2"; + }; + + reg_eldo3: eldo3 { + regulator-name = "eldo3"; + }; + + reg_fldo1: fldo1 { + regulator-name = "fldo1"; + }; + + reg_fldo2: fldo2 { + regulator-name = "fldo2"; + }; + + reg_ldo_io0: ldo-io0 { + regulator-name = "ldo-io0"; + status = "disabled"; + }; + + reg_ldo_io1: ldo-io1 { + regulator-name = "ldo-io1"; + status = "disabled"; + }; + + reg_rtc_ldo: rtc-ldo { + /* RTC_LDO is a fixed, always-on regulator */ + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "rtc-ldo"; + }; + }; +}; diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64.dts b/arch/arm/dts/sun50i-a64-bananapi-m64.dts index 02db114113..4a8d3f83a3 100644 --- a/arch/arm/dts/sun50i-a64-bananapi-m64.dts +++ b/arch/arm/dts/sun50i-a64-bananapi-m64.dts @@ -1,6 +1,5 @@ /* * Copyright (c) 2016 ARM Ltd. - * Copyright (C) 2017 Jagan Teki <jteki@openedev.com> * * This file is dual-licensed: you can use it either under the terms * of the GPL or the X11 license, at your option. Note that this dual @@ -52,6 +51,7 @@ compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64"; aliases { + ethernet0 = &emac; serial0 = &uart0; serial1 = &uart1; }; @@ -60,14 +60,25 @@ stdout-path = "serial0:115200n8"; }; - reg_vcc3v3: vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "vcc3v3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; + wifi_pwrseq: wifi_pwrseq { + compatible = "mmc-pwrseq-simple"; + reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */ }; }; +&ehci1 { + status = "okay"; +}; + +&emac { + pinctrl-names = "default"; + pinctrl-0 = <&rgmii_pins>; + phy-mode = "rgmii"; + phy-handle = <&ext_rgmii_phy>; + phy-supply = <®_dc1sw>; + status = "okay"; +}; + &i2c1 { pinctrl-names = "default"; pinctrl-0 = <&i2c1_pins>; @@ -78,10 +89,17 @@ bias-pull-up; }; +&mdio { + ext_rgmii_phy: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; +}; + &mmc0 { pinctrl-names = "default"; pinctrl-0 = <&mmc0_pins>; - vmmc-supply = <®_vcc3v3>; + vmmc-supply = <®_dcdc1>; cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; cd-inverted; disable-wp; @@ -92,22 +110,143 @@ &mmc1 { pinctrl-names = "default"; pinctrl-0 = <&mmc1_pins>; - vmmc-supply = <®_vcc3v3>; + vmmc-supply = <®_dldo2>; + vqmmc-supply = <®_dldo4>; + mmc-pwrseq = <&wifi_pwrseq>; bus-width = <4>; non-removable; status = "okay"; + + brcmf: wifi@1 { + reg = <1>; + compatible = "brcm,bcm4329-fmac"; + interrupt-parent = <&r_pio>; + interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */ + interrupt-names = "host-wake"; + }; }; &mmc2 { pinctrl-names = "default"; pinctrl-0 = <&mmc2_pins>; - vmmc-supply = <®_vcc3v3>; + vmmc-supply = <®_dcdc1>; bus-width = <8>; non-removable; cap-mmc-hw-reset; status = "okay"; }; +&ohci1 { + status = "okay"; +}; + +&r_rsb { + status = "okay"; + + axp803: pmic@3a3 { + compatible = "x-powers,axp803"; + reg = <0x3a3>; + interrupt-parent = <&r_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + }; +}; + +#include "axp803.dtsi" + +®_aldo2 { + regulator-always-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-pl"; +}; + +®_aldo3 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc-pll-avcc"; +}; + +®_dc1sw { + regulator-name = "vcc-phy"; +}; + +®_dcdc1 { + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-3v3"; +}; + +®_dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1040000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-cpux"; +}; + +/* DCDC3 is polyphased with DCDC2 */ + +®_dcdc5 { + regulator-always-on; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + regulator-name = "vcc-dram"; +}; + +®_dcdc6 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-sys"; +}; + +®_dldo1 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-hdmi-dsi"; +}; + +®_dldo2 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-wifi"; +}; + +®_dldo4 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-wifi-io"; +}; + +®_eldo1 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "cpvdd"; +}; + +®_fldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-name = "vcc-1v2-hsic"; +}; + +/* + * The A64 chip cannot work without this regulator off, although + * it seems to be only driving the AR100 core. + * Maybe we don't still know well about CPUs domain. + */ +®_fldo2 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-cpus"; +}; + +®_rtc_ldo { + regulator-name = "vcc-rtc"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins_a>; @@ -119,3 +258,7 @@ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; status = "okay"; }; + +&usbphy { + status = "okay"; +}; diff --git a/arch/arm/dts/sun50i-a64-nanopi-a64.dts b/arch/arm/dts/sun50i-a64-nanopi-a64.dts index 778636c73a..2beef9e6cb 100644 --- a/arch/arm/dts/sun50i-a64-nanopi-a64.dts +++ b/arch/arm/dts/sun50i-a64-nanopi-a64.dts @@ -57,13 +57,6 @@ chosen { stdout-path = "serial0:115200n8"; }; - - reg_vcc3v3: vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "vcc3v3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; }; &ehci0 { @@ -88,7 +81,7 @@ &mmc0 { pinctrl-names = "default"; pinctrl-0 = <&mmc0_pins>; - vmmc-supply = <®_vcc3v3>; + vmmc-supply = <®_dcdc1>; cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; cd-inverted; disable-wp; @@ -104,6 +97,105 @@ status = "okay"; }; +&r_rsb { + status = "okay"; + + axp803: pmic@3a3 { + compatible = "x-powers,axp803"; + reg = <0x3a3>; + interrupt-parent = <&r_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + }; +}; + +#include "axp803.dtsi" + +®_aldo2 { + regulator-always-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-pl"; +}; + +®_aldo3 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc-pll-avcc"; +}; + +®_dcdc1 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc-3v"; +}; + +®_dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1040000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-cpux"; +}; + +/* DCDC3 is polyphased with DCDC2 */ + +®_dcdc5 { + regulator-always-on; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + regulator-name = "vcc-dram"; +}; + +®_dcdc6 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-sys"; +}; + +®_dldo1 { + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-hdmi-dsi"; +}; + +®_dldo4 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc-pg-wifi-io"; +}; + +®_eldo1 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "cpvdd"; +}; + +®_fldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-name = "vcc-1v2-hsic"; +}; + +/* + * The A64 chip cannot work without this regulator off, although + * it seems to be only driving the AR100 core. + * Maybe we don't still know well about CPUs domain. + */ +®_fldo2 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-cpus"; +}; + +®_rtc_ldo { + regulator-name = "vcc-rtc"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins_a>; diff --git a/arch/arm/dts/sun50i-a64-olinuxino.dts b/arch/arm/dts/sun50i-a64-olinuxino.dts index 7bd4730c93..338e786155 100644 --- a/arch/arm/dts/sun50i-a64-olinuxino.dts +++ b/arch/arm/dts/sun50i-a64-olinuxino.dts @@ -57,19 +57,12 @@ chosen { stdout-path = "serial0:115200n8"; }; - - reg_vcc3v3: vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "vcc3v3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; }; &mmc0 { pinctrl-names = "default"; pinctrl-0 = <&mmc0_pins>; - vmmc-supply = <®_vcc3v3>; + vmmc-supply = <®_dcdc1>; cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; cd-inverted; disable-wp; @@ -77,6 +70,128 @@ status = "okay"; }; +&r_rsb { + status = "okay"; + + axp803: pmic@3a3 { + compatible = "x-powers,axp803"; + reg = <0x3a3>; + interrupt-parent = <&r_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + }; +}; + +#include "axp803.dtsi" + +®_aldo1 { + regulator-always-on; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-name = "vcc-pe"; +}; + +®_aldo2 { + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-pl"; +}; + +®_aldo3 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc-pll-avcc"; +}; + +®_dcdc1 { + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-3v3"; +}; + +®_dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1040000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-cpux"; +}; + +/* DCDC3 is polyphased with DCDC2 */ + +®_dcdc5 { + regulator-always-on; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + regulator-name = "vcc-ddr3"; +}; + +®_dcdc6 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-sys"; +}; + +®_dldo1 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-hdmi"; +}; + +®_dldo2 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-mipi"; +}; + +®_dldo3 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-name = "vcc-avdd-csi"; +}; + +®_dldo4 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-wifi-io"; +}; + +®_eldo1 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "cpvdd"; +}; + +®_eldo2 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc-dvdd-csi"; +}; + +®_fldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-name = "vcc-1v2-hsic"; +}; + +/* + * The A64 chip cannot work without this regulator off, although + * it seems to be only driving the AR100 core. + * Maybe we don't still know well about CPUs domain. + */ +®_fldo2 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-cpus"; +}; + +®_rtc_ldo { + regulator-name = "vcc-rtc"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins_a>; diff --git a/arch/arm/dts/sun50i-a64-orangepi-win.dts b/arch/arm/dts/sun50i-a64-orangepi-win.dts index cf76c35237..5f8ff4017d 100644 --- a/arch/arm/dts/sun50i-a64-orangepi-win.dts +++ b/arch/arm/dts/sun50i-a64-orangepi-win.dts @@ -67,7 +67,7 @@ }; &ehci1 { - status = "okay"; + status = "okay"; }; &mmc0 { @@ -80,7 +80,7 @@ }; &ohci1 { - status = "okay"; + status = "okay"; }; &uart0 { @@ -90,5 +90,6 @@ }; &usbphy { - status = "okay"; + status = "okay"; }; + diff --git a/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi b/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi deleted file mode 100644 index 1b8aa3d8dc..0000000000 --- a/arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi +++ /dev/null @@ -1,20 +0,0 @@ -/ { - aliases { - ethernet0 = &emac; - }; -}; - -&emac { - pinctrl-names = "default"; - pinctrl-0 = <&rgmii_pins>; - phy-mode = "rgmii"; - phy-handle = <&ext_rgmii_phy>; - status = "okay"; -}; - -&mdio { - ext_rgmii_phy: ethernet-phy@1 { - compatible = "ethernet-phy-ieee802.3-c22"; - reg = <1>; - }; -}; diff --git a/arch/arm/dts/sun50i-a64-pine64-plus.dts b/arch/arm/dts/sun50i-a64-pine64-plus.dts index 790d14daaa..24f1aac366 100644 --- a/arch/arm/dts/sun50i-a64-pine64-plus.dts +++ b/arch/arm/dts/sun50i-a64-pine64-plus.dts @@ -46,5 +46,20 @@ model = "Pine64+"; compatible = "pine64,pine64-plus", "allwinner,sun50i-a64"; - /* TODO: Camera, Ethernet PHY, touchscreen, etc. */ + /* TODO: Camera, touchscreen, etc. */ +}; + +&emac { + pinctrl-names = "default"; + pinctrl-0 = <&rgmii_pins>; + phy-mode = "rgmii"; + phy-handle = <&ext_rgmii_phy>; + status = "okay"; +}; + +&mdio { + ext_rgmii_phy: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; }; diff --git a/arch/arm/dts/sun50i-a64-pine64.dts b/arch/arm/dts/sun50i-a64-pine64.dts index c680ed385d..604cdaedac 100644 --- a/arch/arm/dts/sun50i-a64-pine64.dts +++ b/arch/arm/dts/sun50i-a64-pine64.dts @@ -51,25 +51,37 @@ compatible = "pine64,pine64", "allwinner,sun50i-a64"; aliases { + ethernet0 = &emac; serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; + serial3 = &uart3; + serial4 = &uart4; }; chosen { stdout-path = "serial0:115200n8"; }; +}; - reg_vcc3v3: vcc3v3 { - compatible = "regulator-fixed"; - regulator-name = "vcc3v3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - }; +&ehci0 { + status = "okay"; }; &ehci1 { status = "okay"; }; +&emac { + pinctrl-names = "default"; + pinctrl-0 = <&rmii_pins>; + phy-mode = "rmii"; + phy-handle = <&ext_rmii_phy1>; + phy-supply = <®_dc1sw>; + status = "okay"; + +}; + &i2c1 { pinctrl-names = "default"; pinctrl-0 = <&i2c1_pins>; @@ -80,10 +92,17 @@ bias-pull-up; }; +&mdio { + ext_rmii_phy1: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; +}; + &mmc0 { pinctrl-names = "default"; pinctrl-0 = <&mmc0_pins>; - vmmc-supply = <®_vcc3v3>; + vmmc-supply = <®_dcdc1>; cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; cd-inverted; disable-wp; @@ -91,16 +110,161 @@ status = "okay"; }; +&ohci0 { + status = "okay"; +}; + &ohci1 { status = "okay"; }; +&r_rsb { + status = "okay"; + + axp803: pmic@3a3 { + compatible = "x-powers,axp803"; + reg = <0x3a3>; + interrupt-parent = <&r_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + }; +}; + +#include "axp803.dtsi" + +®_aldo2 { + regulator-always-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-pl"; +}; + +®_aldo3 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc-pll-avcc"; +}; + +®_dc1sw { + regulator-name = "vcc-phy"; +}; + +®_dcdc1 { + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-3v3"; +}; + +®_dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1040000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd-cpux"; +}; + +/* DCDC3 is polyphased with DCDC2 */ + +/* + * The DRAM chips used by Pine64 boards are DDR3L-compatible, so they can + * work at 1.35V with less power consumption. + * As AXP803 DCDC5 cannot reach 1.35V accurately, use 1.36V instead. + */ +®_dcdc5 { + regulator-always-on; + regulator-min-microvolt = <1360000>; + regulator-max-microvolt = <1360000>; + regulator-name = "vcc-dram"; +}; + +®_dcdc6 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-sys"; +}; + +®_dldo1 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-hdmi"; +}; + +®_dldo2 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-mipi"; +}; + +®_dldo4 { + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc-wifi"; +}; + +®_eldo1 { + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "cpvdd"; +}; + +®_fldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-name = "vcc-1v2-hsic"; +}; + +/* + * The A64 chip cannot work without this regulator off, although + * it seems to be only driving the AR100 core. + * Maybe we don't still know well about CPUs domain. + */ +®_fldo2 { + regulator-always-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-name = "vdd-cpus"; +}; + +®_rtc_ldo { + regulator-name = "vcc-rtc"; +}; + +/* On Exp and Euler connectors */ &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_pins_a>; status = "okay"; }; +/* On Wifi/BT connector, with RTS/CTS */ +&uart1 { + pinctrl-names = "default"; + pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>; + status = "disabled"; +}; + +/* On Pi-2 connector */ +&uart2 { + pinctrl-names = "default"; + pinctrl-0 = <&uart2_pins>; + status = "disabled"; +}; + +/* On Euler connector */ +&uart3 { + pinctrl-names = "default"; + pinctrl-0 = <&uart3_pins>; + status = "disabled"; +}; + +/* On Euler connector, RTS/CTS optional */ +&uart4 { + pinctrl-names = "default"; + pinctrl-0 = <&uart4_pins>; + status = "disabled"; +}; + &usb_otg { dr_mode = "host"; status = "okay";
Update the .dts files for the various boards with an Allwinner A64 SoC. This is as of v4.15-rc9, exactly Linux commit: commit bdfe4cebea11476d278b1b98dd0f7cdac8269d62 Author: Icenowy Zheng <icenowy@aosc.io> Date: Fri Nov 10 17:26:54 2017 +0800 arm64: allwinner: a64: add Ethernet PHY regulator for several boards It updates the existing DT files, adds the newly added axp803.dtsi and removes our temporary kludge file to get Ethernet support in U-Boot. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> --- arch/arm/dts/axp803.dtsi | 150 ++++++++++++++++++++ arch/arm/dts/sun50i-a64-bananapi-m64.dts | 161 +++++++++++++++++++-- arch/arm/dts/sun50i-a64-nanopi-a64.dts | 108 ++++++++++++-- arch/arm/dts/sun50i-a64-olinuxino.dts | 131 +++++++++++++++-- arch/arm/dts/sun50i-a64-orangepi-win.dts | 7 +- arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi | 20 --- arch/arm/dts/sun50i-a64-pine64-plus.dts | 17 ++- arch/arm/dts/sun50i-a64-pine64.dts | 178 +++++++++++++++++++++++- 8 files changed, 716 insertions(+), 56 deletions(-) create mode 100644 arch/arm/dts/axp803.dtsi delete mode 100644 arch/arm/dts/sun50i-a64-pine64-plus-u-boot.dtsi