| Message ID | 20220427203132.47271-1-samuel@sholland.org |
|---|---|
| Headers | show |
| Series | sunxi: Devicetree sync from Linux v5.18-rc1 | expand |
On Wed, 27 Apr 2022 15:31:19 -0500 Samuel Holland <samuel@sholland.org> wrote: Hi Samuel, Tom, > This series brings all of our devicetrees up to date with Linux. > > Older SoCs (before A83T) have not been synchronized in over 3 years. > And I don't have any of this hardware to test. But there are not major > changes to those devicetrees either. > > The big motivation for including older SoCs in this update is converting > the USB PHY driver to get its VBUS detection GPIO/regulator from the > devicetree instead of from a pin name in Kconfig. Many older boards had > those properties added or fixed since the last devicetree sync. This PHY > driver change is necessary to complete the DM_GPIO migration. > > A couple of breaking changes were made to several SoCs' devicetrees in > Linux relating to the "r_intc" interrupt controller. New kernels support > old devicetrees, but not the other way around. So to be most compatible > and avoid regressions, those changes are skipped here. Many thanks for considering this! I just skimmed over the A64 and H6 patches, and this is indeed the only difference. But while I love this pragmatic approach, and would be happy to take this, this goes against our own rules, and more importantly against Tom's one's: to take only direct DT file copies from the kernel tree. Tom, can you give your opinion here? As Samuel mentioned above, the current mainline DTs wouldn't boot on older kernels (the changes affect critical devices), so this spoils stable distro and installer kernels, when using $fdtcontroladdr, for instance when booting via UEFI. As a side effect of always defining SYS_SOC to "sunxi", we cannot easily use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. For context, those changed properties were in the mainline kernel tree at some point, but have been amended since. So it's not some random change. Cheers, Andre > Samuel Holland (12): > dt-bindings: sunxi: Update clock/reset binding headers > ARM: dts: sunxi: Remove unused devicetree headers > ARM: dts: sun4i: Sync from Linux v5.18-rc1 > ARM: dts: sun7i: Sync from Linux v5.18-rc1 > ARM: dts: sunxi: A13/A31/A23/A33: Sync from Linux v5.18-rc1 > ARM: dts: sun9i: Sync from Linux v5.18-rc1 > ARM: dts: sun8i: A83T: Sync from Linux v5.18-rc1 > ARM: dts: sunxi: H2+/H3/H5: Sync from Linux v5.18-rc1 > ARM: dts: sun8i: V3/V3s/S3: Sync from Linux v5.18-rc1 > ARM: dts: sun8i: R40/T3: Sync from Linux v5.18-rc1 > ARM: dts: sun50i: A64: Sync from Linux v5.18-rc1 > ARM: dts: sun50i: H6: Sync from Linux v5.18-rc1 > > arch/arm/dts/Makefile | 25 +- > arch/arm/dts/axp209.dtsi | 6 +- > arch/arm/dts/axp22x.dtsi | 11 +- > arch/arm/dts/axp803.dtsi | 10 +- > arch/arm/dts/axp81x.dtsi | 15 +- > arch/arm/dts/sun4i-a10-a1000.dts | 31 +- > arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 2 +- > arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts | 20 +- > arch/arm/dts/sun4i-a10-cubieboard.dts | 16 +- > arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 21 +- > arch/arm/dts/sun4i-a10-hackberry.dts | 2 +- > arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 20 +- > arch/arm/dts/sun4i-a10-inet1.dts | 21 +- > arch/arm/dts/sun4i-a10-inet97fv2.dts | 22 +- > arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 74 ++-- > .../dts/sun4i-a10-itead-iteaduino-plus.dts | 2 +- > arch/arm/dts/sun4i-a10-jesurun-q5.dts | 4 +- > arch/arm/dts/sun4i-a10-marsboard.dts | 22 +- > arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 33 +- > arch/arm/dts/sun4i-a10-pcduino.dts | 20 +- > arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 21 +- > arch/arm/dts/sun4i-a10-topwise-a721.dts | 242 +++++++++++++ > arch/arm/dts/sun4i-a10.dtsi | 135 ++++++- > arch/arm/dts/sun50i-a64-cpu-opp.dtsi | 2 +- > arch/arm/dts/sun50i-a64-orangepi-win.dts | 2 +- > arch/arm/dts/sun50i-a64-pinebook.dts | 1 + > arch/arm/dts/sun50i-a64-pinephone.dtsi | 27 ++ > arch/arm/dts/sun50i-a64-pinetab.dts | 29 +- > arch/arm/dts/sun50i-a64-teres-i.dts | 4 +- > arch/arm/dts/sun50i-a64.dtsi | 93 +++-- > arch/arm/dts/sun50i-h5-cpu-opp.dtsi | 2 +- > arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 9 +- > arch/arm/dts/sun50i-h5.dtsi | 6 +- > arch/arm/dts/sun50i-h6-beelink-gs1.dts | 38 +- > arch/arm/dts/sun50i-h6-cpu-opp.dtsi | 2 +- > arch/arm/dts/sun50i-h6-orangepi-3.dts | 14 +- > arch/arm/dts/sun50i-h6-orangepi.dtsi | 22 +- > arch/arm/dts/sun50i-h6-pine-h64-model-b.dts | 51 +++ > arch/arm/dts/sun50i-h6-tanix-tx6-mini.dts | 15 + > arch/arm/dts/sun50i-h6-tanix-tx6.dts | 115 +----- > arch/arm/dts/sun50i-h6-tanix.dtsi | 189 ++++++++++ > arch/arm/dts/sun50i-h6.dtsi | 26 +- > arch/arm/dts/sun5i-a10s-auxtek-t003.dts | 16 +- > arch/arm/dts/sun5i-a10s-auxtek-t004.dts | 35 +- > arch/arm/dts/sun5i-a10s-mk802.dts | 31 +- > arch/arm/dts/sun5i-a10s-olinuxino-micro.dts | 68 +--- > arch/arm/dts/sun5i-a10s-r7-tv-dongle.dts | 22 +- > arch/arm/dts/sun5i-a10s-wobo-i5.dts | 34 +- > arch/arm/dts/sun5i-a10s.dtsi | 30 +- > arch/arm/dts/sun5i-a13-ampe-a76.dts | 2 +- > .../dts/sun5i-a13-empire-electronix-d709.dts | 41 +-- > arch/arm/dts/sun5i-a13-hsg-h702.dts | 37 +- > arch/arm/dts/sun5i-a13-inet-86vs.dts | 2 +- > ...common.dtsi => sun5i-a13-licheepi-one.dts} | 146 +++++--- > arch/arm/dts/sun5i-a13-olinuxino-micro.dts | 50 +-- > arch/arm/dts/sun5i-a13-olinuxino.dts | 56 +-- > .../dts/sun5i-a13-pocketbook-touch-lux-3.dts | 258 ++++++++++++++ > arch/arm/dts/sun5i-a13-q8-tablet.dts | 18 +- > arch/arm/dts/sun5i-a13-utoo-p66.dts | 26 +- > arch/arm/dts/sun5i-a13.dtsi | 23 +- > arch/arm/dts/sun5i-gr8-chip-pro.dts | 38 +- > arch/arm/dts/sun5i-gr8-evb.dts | 333 ++++++++++++++++++ > arch/arm/dts/sun5i-gr8.dtsi | 12 +- > arch/arm/dts/sun5i-r8-chip.dts | 52 +-- > .../dts/sun5i-reference-design-tablet.dtsi | 57 +-- > arch/arm/dts/sun5i.dtsi | 209 +++++++---- > arch/arm/dts/sun6i-a31-app4-evb1.dts | 10 +- > arch/arm/dts/sun6i-a31-colombus.dts | 57 +-- > arch/arm/dts/sun6i-a31-hummingbird.dts | 75 +--- > arch/arm/dts/sun6i-a31-i7.dts | 47 +-- > arch/arm/dts/sun6i-a31-m9.dts | 46 +-- > arch/arm/dts/sun6i-a31-mele-a1000g-quad.dts | 46 +-- > arch/arm/dts/sun6i-a31-mixtile-loftq.dts | 6 +- > arch/arm/dts/sun6i-a31.dtsi | 218 +++++++----- > arch/arm/dts/sun6i-a31s-colorfly-e708-q1.dts | 2 +- > arch/arm/dts/sun6i-a31s-cs908.dts | 17 +- > arch/arm/dts/sun6i-a31s-inet-q972.dts | 8 +- > arch/arm/dts/sun6i-a31s-primo81.dts | 32 +- > arch/arm/dts/sun6i-a31s-sina31s-core.dtsi | 4 +- > arch/arm/dts/sun6i-a31s-sina31s.dts | 39 +- > arch/arm/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 144 +++++--- > .../sun6i-a31s-yones-toptech-bs1078-v2.dts | 22 +- > .../dts/sun6i-reference-design-tablet.dtsi | 22 +- > arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 16 +- > arch/arm/dts/sun7i-a20-bananapi.dts | 41 +-- > arch/arm/dts/sun7i-a20-bananapro.dts | 16 +- > arch/arm/dts/sun7i-a20-cubieboard2.dts | 28 +- > arch/arm/dts/sun7i-a20-cubietruck.dts | 20 +- > arch/arm/dts/sun7i-a20-haoyu-marsboard.dts | 182 ++++++++++ > arch/arm/dts/sun7i-a20-hummingbird.dts | 21 +- > arch/arm/dts/sun7i-a20-i12-tvbox.dts | 16 +- > arch/arm/dts/sun7i-a20-icnova-swac.dts | 15 +- > arch/arm/dts/sun7i-a20-itead-ibox.dts | 8 +- > arch/arm/dts/sun7i-a20-lamobo-r1.dts | 16 +- > .../dts/sun7i-a20-linutronix-testbox-v2.dts | 47 +++ > arch/arm/dts/sun7i-a20-m3.dts | 14 +- > arch/arm/dts/sun7i-a20-olimex-som-evb.dts | 14 +- > arch/arm/dts/sun7i-a20-olimex-som204-evb.dts | 30 +- > .../arm/dts/sun7i-a20-olinuxino-lime-emmc.dts | 32 ++ > arch/arm/dts/sun7i-a20-olinuxino-lime.dts | 32 +- > arch/arm/dts/sun7i-a20-olinuxino-lime2.dts | 46 +-- > arch/arm/dts/sun7i-a20-olinuxino-micro.dts | 32 +- > arch/arm/dts/sun7i-a20-orangepi-mini.dts | 28 +- > arch/arm/dts/sun7i-a20-orangepi.dts | 26 +- > arch/arm/dts/sun7i-a20-pcduino3-nano.dts | 32 +- > arch/arm/dts/sun7i-a20-pcduino3.dts | 28 +- > arch/arm/dts/sun7i-a20-wexler-tab7200.dts | 13 +- > arch/arm/dts/sun7i-a20-wits-pro-a20-dkt.dts | 24 +- > arch/arm/dts/sun7i-a20.dtsi | 254 +++++++++++-- > arch/arm/dts/sun8i-a23-a33.dtsi | 308 ++++++++++++---- > arch/arm/dts/sun8i-a23-evb.dts | 20 +- > arch/arm/dts/sun8i-a23-gt90h-v4.dts | 2 +- > ...ommon.dtsi => sun8i-a23-ippo-q8h-v1.2.dts} | 54 ++- > arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts | 73 ++++ > .../dts/sun8i-a23-polaroid-mid2407pxe03.dts | 15 +- > .../dts/sun8i-a23-polaroid-mid2809pxe04.dts | 15 +- > arch/arm/dts/sun8i-a23-q8-tablet.dts | 10 + > arch/arm/dts/sun8i-a23.dtsi | 26 +- > ...c-edition.dts => sun8i-a33-et-q8-v1.6.dts} | 32 +- > arch/arm/dts/sun8i-a33-ga10h-v1.1.dts | 4 +- > arch/arm/dts/sun8i-a33-inet-d978-rev2.dts | 14 +- > arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts | 57 +++ > arch/arm/dts/sun8i-a33-olinuxino.dts | 12 +- > arch/arm/dts/sun8i-a33-q8-tablet.dts | 7 + > arch/arm/dts/sun8i-a33-sinlinx-sina33.dts | 34 +- > arch/arm/dts/sun8i-a33.dtsi | 270 +++++--------- > .../dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 12 + > arch/arm/dts/sun8i-a83t-bananapi-m3.dts | 55 ++- > arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 77 +++- > arch/arm/dts/sun8i-a83t-tbs-a711.dts | 101 +++++- > arch/arm/dts/sun8i-a83t.dtsi | 311 ++++++++++++++-- > .../dts/sun8i-h2-plus-bananapi-m2-zero.dts | 28 +- > arch/arm/dts/sun8i-h3-beelink-x2.dts | 27 +- > arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 28 ++ > arch/arm/dts/sun8i-h3-nanopi-r1.dts | 169 +++++++++ > arch/arm/dts/sun8i-h3-nanopi.dtsi | 1 + > arch/arm/dts/sun8i-h3-orangepi-2.dts | 3 +- > arch/arm/dts/sun8i-h3-orangepi-pc.dts | 3 +- > arch/arm/dts/sun8i-h3.dtsi | 10 +- > arch/arm/dts/sun8i-q8-common.dtsi | 31 +- > arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 55 ++- > .../dts/sun8i-r16-nintendo-nes-classic.dts | 54 +++ > .../sun8i-r16-nintendo-super-nes-classic.dts | 11 + > arch/arm/dts/sun8i-r16-parrot.dts | 62 +--- > arch/arm/dts/sun8i-r40-feta40i.dtsi | 106 ++++++ > arch/arm/dts/sun8i-r40-oka40i-c.dts | 203 +++++++++++ > arch/arm/dts/sun8i-r40.dtsi | 118 ++++++- > .../dts/sun8i-reference-design-tablet.dtsi | 33 +- > arch/arm/dts/sun8i-s3-elimo-impetus.dtsi | 44 +++ > arch/arm/dts/sun8i-s3-elimo-initium.dts | 29 ++ > arch/arm/dts/sun8i-s3-pinecube.dts | 13 +- > arch/arm/dts/sun8i-t3-cqa3t-bv3.dts | 226 ++++++++++++ > arch/arm/dts/sun8i-v3-sl631-imx179.dts | 12 + > arch/arm/dts/sun8i-v3-sl631.dtsi | 138 ++++++++ > arch/arm/dts/sun8i-v3.dtsi | 36 ++ > arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts | 17 +- > arch/arm/dts/sun8i-v3s.dtsi | 93 ++++- > arch/arm/dts/sun9i-a80-cubieboard4.dts | 67 +++- > arch/arm/dts/sun9i-a80-optimus.dts | 50 ++- > arch/arm/dts/sun9i-a80.dtsi | 195 ++++++---- > arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 18 +- > arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 4 +- > arch/arm/dts/sunxi-common-regulators.dtsi | 39 -- > arch/arm/dts/sunxi-h3-h5.dtsi | 42 ++- > arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 13 + > arch/arm/dts/sunxi-libretech-all-h3-it.dtsi | 2 +- > .../dts/sunxi-reference-design-tablet.dtsi | 11 +- > arch/arm/mach-sunxi/Kconfig | 2 +- > .../Nintendo_NES_Classic_Edition_defconfig | 2 +- > include/dt-bindings/clock/sun50i-a64-ccu.h | 2 +- > include/dt-bindings/clock/sun5i-ccu.h | 13 +- > include/dt-bindings/clock/sun6i-a31-ccu.h | 2 + > include/dt-bindings/clock/sun8i-a23-a33-ccu.h | 2 + > include/dt-bindings/clock/sun8i-h3-ccu.h | 2 +- > include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 + > include/dt-bindings/reset/sun5i-ccu.h | 11 +- > include/dt-bindings/reset/sun8i-v3s-ccu.h | 3 + > 177 files changed, 5704 insertions(+), 2683 deletions(-) > create mode 100644 arch/arm/dts/sun4i-a10-topwise-a721.dts > create mode 100644 arch/arm/dts/sun50i-h6-pine-h64-model-b.dts > create mode 100644 arch/arm/dts/sun50i-h6-tanix-tx6-mini.dts > create mode 100644 arch/arm/dts/sun50i-h6-tanix.dtsi > rename arch/arm/dts/{sun5i-q8-common.dtsi => sun5i-a13-licheepi-one.dts} (62%) > create mode 100644 arch/arm/dts/sun5i-a13-pocketbook-touch-lux-3.dts > create mode 100644 arch/arm/dts/sun5i-gr8-evb.dts > create mode 100644 arch/arm/dts/sun7i-a20-haoyu-marsboard.dts > create mode 100644 arch/arm/dts/sun7i-a20-linutronix-testbox-v2.dts > create mode 100644 arch/arm/dts/sun7i-a20-olinuxino-lime-emmc.dts > rename arch/arm/dts/{sunxi-q8-common.dtsi => sun8i-a23-ippo-q8h-v1.2.dts} (75%) > create mode 100644 arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts > rename arch/arm/dts/{sun8i-r16-nintendo-nes-classic-edition.dts => sun8i-a33-et-q8-v1.6.dts} (81%) > create mode 100644 arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts > create mode 100644 arch/arm/dts/sun8i-h3-nanopi-r1.dts > create mode 100644 arch/arm/dts/sun8i-r16-nintendo-nes-classic.dts > create mode 100644 arch/arm/dts/sun8i-r16-nintendo-super-nes-classic.dts > create mode 100644 arch/arm/dts/sun8i-r40-feta40i.dtsi > create mode 100644 arch/arm/dts/sun8i-r40-oka40i-c.dts > create mode 100644 arch/arm/dts/sun8i-s3-elimo-impetus.dtsi > create mode 100644 arch/arm/dts/sun8i-s3-elimo-initium.dts > create mode 100644 arch/arm/dts/sun8i-t3-cqa3t-bv3.dts > create mode 100644 arch/arm/dts/sun8i-v3-sl631-imx179.dts > create mode 100644 arch/arm/dts/sun8i-v3-sl631.dtsi >
On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > On Wed, 27 Apr 2022 15:31:19 -0500 > Samuel Holland <samuel@sholland.org> wrote: > > Hi Samuel, Tom, > > > This series brings all of our devicetrees up to date with Linux. > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > And I don't have any of this hardware to test. But there are not major > > changes to those devicetrees either. > > > > The big motivation for including older SoCs in this update is converting > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > devicetree instead of from a pin name in Kconfig. Many older boards had > > those properties added or fixed since the last devicetree sync. This PHY > > driver change is necessary to complete the DM_GPIO migration. > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > Linux relating to the "r_intc" interrupt controller. New kernels support > > old devicetrees, but not the other way around. So to be most compatible > > and avoid regressions, those changes are skipped here. > > Many thanks for considering this! I just skimmed over the A64 and H6 > patches, and this is indeed the only difference. > > But while I love this pragmatic approach, and would be happy to take this, > this goes against our own rules, and more importantly against Tom's one's: > to take only direct DT file copies from the kernel tree. > > Tom, can you give your opinion here? As Samuel mentioned above, the > current mainline DTs wouldn't boot on older kernels (the changes affect > critical devices), so this spoils stable distro and installer kernels, > when using $fdtcontroladdr, for instance when booting via UEFI. > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > For context, those changed properties were in the mainline kernel tree at > some point, but have been amended since. So it's not some random change. So, this is I guess a bit annoying. But, we aren't at the point where the common use case is the downstream OS using the DTB we've loaded and are using, are we? I mean, we can't be, as ours are so far out of date, so this will only be an option when we use a recent DT ourself. So we should be able to sync in the changes and update our code, as they can't be using $fdtcontroladdr in this case, right? Or am I missing the use case that's in the wild atm? Thanks!
On Fri, 29 Apr 2022 10:57:10 -0400 Tom Rini <trini@konsulko.com> wrote: Hi, > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > On Wed, 27 Apr 2022 15:31:19 -0500 > > Samuel Holland <samuel@sholland.org> wrote: > > > > Hi Samuel, Tom, > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > And I don't have any of this hardware to test. But there are not major > > > changes to those devicetrees either. > > > > > > The big motivation for including older SoCs in this update is converting > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > those properties added or fixed since the last devicetree sync. This PHY > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > old devicetrees, but not the other way around. So to be most compatible > > > and avoid regressions, those changes are skipped here. > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > patches, and this is indeed the only difference. > > > > But while I love this pragmatic approach, and would be happy to take this, > > this goes against our own rules, and more importantly against Tom's one's: > > to take only direct DT file copies from the kernel tree. > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > current mainline DTs wouldn't boot on older kernels (the changes affect > > critical devices), so this spoils stable distro and installer kernels, > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > For context, those changed properties were in the mainline kernel tree at > > some point, but have been amended since. So it's not some random change. > > So, this is I guess a bit annoying. But, we aren't at the point where > the common use case is the downstream OS using the DTB we've loaded and > are using, are we? I mean, we can't be, as ours are so far out of date, > so this will only be an option when we use a recent DT ourself. So we > should be able to sync in the changes and update our code, as they can't > be using $fdtcontroladdr in this case, right? Or am I missing the use > case that's in the wild atm? Thanks! While it sounds like the DTs are wildly out of date, this mostly affects secondary functionality. The mainline updates for the 64-bit SoCs are: - H6: adding the VP9 video h/w codec and an additional wakeup timer - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary digital audio interfaces, plus the wakeup timer Also there are cosmetic changes, like changing node names to make them binding compliant. So those DT updates are really only important for mobile devices like the Pinephone, which probably don't use UEFI booting. At the moment I boot distro grubs and installers just fine, and without losing any real functionality (minus suspend/resume, maybe). The out-of-the-box default boot works now, and would break when pulling in the pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), can only deal with the older DTs (#interrupt-cells for r_intc must be 2). Cheers, Andre
On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > On Fri, 29 Apr 2022 10:57:10 -0400 > Tom Rini <trini@konsulko.com> wrote: > > Hi, > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > Hi Samuel, Tom, > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > And I don't have any of this hardware to test. But there are not major > > > > changes to those devicetrees either. > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > old devicetrees, but not the other way around. So to be most compatible > > > > and avoid regressions, those changes are skipped here. > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > patches, and this is indeed the only difference. > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > this goes against our own rules, and more importantly against Tom's one's: > > > to take only direct DT file copies from the kernel tree. > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > critical devices), so this spoils stable distro and installer kernels, > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > For context, those changed properties were in the mainline kernel tree at > > > some point, but have been amended since. So it's not some random change. > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > the common use case is the downstream OS using the DTB we've loaded and > > are using, are we? I mean, we can't be, as ours are so far out of date, > > so this will only be an option when we use a recent DT ourself. So we > > should be able to sync in the changes and update our code, as they can't > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > case that's in the wild atm? Thanks! > > While it sounds like the DTs are wildly out of date, this mostly affects > secondary functionality. The mainline updates for the 64-bit SoCs are: > - H6: adding the VP9 video h/w codec and an additional wakeup timer > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > digital audio interfaces, plus the wakeup timer > Also there are cosmetic changes, like changing node names to make them > binding compliant. > So those DT updates are really only important for mobile devices like the > Pinephone, which probably don't use UEFI booting. > > At the moment I boot distro grubs and installers just fine, and without > losing any real functionality (minus suspend/resume, maybe). The > out-of-the-box default boot works now, and would break when pulling in the > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). I guess the first point is, yes, we should sync in what we can sync in, to bring things closer to proper alignment. I further guess that given that we have to support both "new Linux" and "not Linux", we have to keep the old style DT information instead as that's how compatibility is supposed to be handled? I'm adding in Rob here since this still reads a bit confusing as to what's supposed to happen, but maybe we also just need to check in with some other-OS folks to see what their plan is?
On Fri, 29 Apr 2022 11:31:00 -0400 Tom Rini <trini@konsulko.com> wrote: Hi, > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > On Fri, 29 Apr 2022 10:57:10 -0400 > > Tom Rini <trini@konsulko.com> wrote: > > > > Hi, > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > > > Hi Samuel, Tom, > > > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > > And I don't have any of this hardware to test. But there are not major > > > > > changes to those devicetrees either. > > > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > > old devicetrees, but not the other way around. So to be most compatible > > > > > and avoid regressions, those changes are skipped here. > > > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > > patches, and this is indeed the only difference. > > > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > > this goes against our own rules, and more importantly against Tom's one's: > > > > to take only direct DT file copies from the kernel tree. > > > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > > critical devices), so this spoils stable distro and installer kernels, > > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > > > For context, those changed properties were in the mainline kernel tree at > > > > some point, but have been amended since. So it's not some random change. > > > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > > the common use case is the downstream OS using the DTB we've loaded and > > > are using, are we? I mean, we can't be, as ours are so far out of date, > > > so this will only be an option when we use a recent DT ourself. So we > > > should be able to sync in the changes and update our code, as they can't > > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > > case that's in the wild atm? Thanks! > > > > While it sounds like the DTs are wildly out of date, this mostly affects > > secondary functionality. The mainline updates for the 64-bit SoCs are: > > - H6: adding the VP9 video h/w codec and an additional wakeup timer > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > digital audio interfaces, plus the wakeup timer > > Also there are cosmetic changes, like changing node names to make them > > binding compliant. > > So those DT updates are really only important for mobile devices like the > > Pinephone, which probably don't use UEFI booting. > > > > At the moment I boot distro grubs and installers just fine, and without > > losing any real functionality (minus suspend/resume, maybe). The > > out-of-the-box default boot works now, and would break when pulling in the > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > I guess the first point is, yes, we should sync in what we can sync in, > to bring things closer to proper alignment. I further guess that given > that we have to support both "new Linux" and "not Linux", we have to > keep the old style DT information instead as that's how compatibility is > supposed to be handled? I'm adding in Rob here since this still reads a > bit confusing as to what's supposed to happen, but maybe we also just > need to check in with some other-OS folks to see what their plan is? AFAIK, the official Linux DT compatibility requirements are to always keep backwards compatibility (boot newer kernels with older DTs), but leave the decision to support the other way around (older kernels with newer DTs) to the respective platform maintainers. At least in the past sunxi opted to allow non-forward compatible changes (this r_intc one being an example of), with the rationale that without proper documentation and with doing "retroactive" development, incompatible changes are unavoidable, or would require more work than those volunteers are willing to do. Those incompatible changes (there were some more, though minor in the past) are the reason I (grudgingly) held back with DT updates for U-Boot, so I would very much appreciate if that situation could be cleared up. As mentioned, I would be happy to take the changed DTs, and would volunteer to keep those diffs somehow maintained in U-Boot. Cheers, Andre
> Date: Fri, 29 Apr 2022 11:31:00 -0400 > From: Tom Rini <trini@konsulko.com> > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > On Fri, 29 Apr 2022 10:57:10 -0400 > > Tom Rini <trini@konsulko.com> wrote: > > > > Hi, > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > > > Hi Samuel, Tom, > > > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > > And I don't have any of this hardware to test. But there are not major > > > > > changes to those devicetrees either. > > > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > > old devicetrees, but not the other way around. So to be most compatible > > > > > and avoid regressions, those changes are skipped here. > > > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > > patches, and this is indeed the only difference. > > > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > > this goes against our own rules, and more importantly against Tom's one's: > > > > to take only direct DT file copies from the kernel tree. > > > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > > critical devices), so this spoils stable distro and installer kernels, > > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > > > For context, those changed properties were in the mainline kernel tree at > > > > some point, but have been amended since. So it's not some random change. > > > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > > the common use case is the downstream OS using the DTB we've loaded and > > > are using, are we? I mean, we can't be, as ours are so far out of date, > > > so this will only be an option when we use a recent DT ourself. So we > > > should be able to sync in the changes and update our code, as they can't > > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > > case that's in the wild atm? Thanks! > > > > While it sounds like the DTs are wildly out of date, this mostly affects > > secondary functionality. The mainline updates for the 64-bit SoCs are: > > - H6: adding the VP9 video h/w codec and an additional wakeup timer > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > digital audio interfaces, plus the wakeup timer > > Also there are cosmetic changes, like changing node names to make them > > binding compliant. > > So those DT updates are really only important for mobile devices like the > > Pinephone, which probably don't use UEFI booting. > > > > At the moment I boot distro grubs and installers just fine, and without > > losing any real functionality (minus suspend/resume, maybe). The > > out-of-the-box default boot works now, and would break when pulling in the > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > I guess the first point is, yes, we should sync in what we can sync in, > to bring things closer to proper alignment. I further guess that given > that we have to support both "new Linux" and "not Linux", we have to > keep the old style DT information instead as that's how compatibility is > supposed to be handled? I'm adding in Rob here since this still reads a > bit confusing as to what's supposed to happen, but maybe we also just > need to check in with some other-OS folks to see what their plan is? My goal with OpenBSD has always been to make the OS boot with the DT built into U-Boot, but to allow users to use a more up-to-date Linux DT by putting the apropriate .dtb file on the ESP. However it is easy to miss changes that break backwards compatibility of the bindings in the noise of other changes. So in many cases we only notice this when the changes make it into U-Boot and we update the OpenBSD U-Boot port. I'll drag out one of my A64 boards and see what needs to be done to support the routing of these interrupts through r_intc.
On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: > > Date: Fri, 29 Apr 2022 11:31:00 -0400 > > From: Tom Rini <trini@konsulko.com> > > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > > On Fri, 29 Apr 2022 10:57:10 -0400 > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > Hi, > > > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > > > > > Hi Samuel, Tom, > > > > > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > > > And I don't have any of this hardware to test. But there are not major > > > > > > changes to those devicetrees either. > > > > > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > > > old devicetrees, but not the other way around. So to be most compatible > > > > > > and avoid regressions, those changes are skipped here. > > > > > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > > > patches, and this is indeed the only difference. > > > > > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > > > this goes against our own rules, and more importantly against Tom's one's: > > > > > to take only direct DT file copies from the kernel tree. > > > > > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > > > critical devices), so this spoils stable distro and installer kernels, > > > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > > > > > For context, those changed properties were in the mainline kernel tree at > > > > > some point, but have been amended since. So it's not some random change. > > > > > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > > > the common use case is the downstream OS using the DTB we've loaded and > > > > are using, are we? I mean, we can't be, as ours are so far out of date, > > > > so this will only be an option when we use a recent DT ourself. So we > > > > should be able to sync in the changes and update our code, as they can't > > > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > > > case that's in the wild atm? Thanks! > > > > > > While it sounds like the DTs are wildly out of date, this mostly affects > > > secondary functionality. The mainline updates for the 64-bit SoCs are: > > > - H6: adding the VP9 video h/w codec and an additional wakeup timer > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > > digital audio interfaces, plus the wakeup timer > > > Also there are cosmetic changes, like changing node names to make them > > > binding compliant. > > > So those DT updates are really only important for mobile devices like the > > > Pinephone, which probably don't use UEFI booting. > > > > > > At the moment I boot distro grubs and installers just fine, and without > > > losing any real functionality (minus suspend/resume, maybe). The > > > out-of-the-box default boot works now, and would break when pulling in the > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > > > I guess the first point is, yes, we should sync in what we can sync in, > > to bring things closer to proper alignment. I further guess that given > > that we have to support both "new Linux" and "not Linux", we have to > > keep the old style DT information instead as that's how compatibility is > > supposed to be handled? I'm adding in Rob here since this still reads a > > bit confusing as to what's supposed to happen, but maybe we also just > > need to check in with some other-OS folks to see what their plan is? > > My goal with OpenBSD has always been to make the OS boot with the DT > built into U-Boot, but to allow users to use a more up-to-date Linux > DT by putting the apropriate .dtb file on the ESP. However it is easy > to miss changes that break backwards compatibility of the bindings in > the noise of other changes. So in many cases we only notice this when > the changes make it into U-Boot and we update the OpenBSD U-Boot port. > > I'll drag out one of my A64 boards and see what needs to be done to > support the routing of these interrupts through r_intc. So, does that mean the plan is to keep the r_intc changes out of U-Boot for now, but we can sync the rest, and come up with a plan to fully update in time?
> Date: Fri, 29 Apr 2022 14:14:19 -0400 > From: Tom Rini <trini@konsulko.com> > > On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: > > > Date: Fri, 29 Apr 2022 11:31:00 -0400 > > > From: Tom Rini <trini@konsulko.com> > > > > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > > > On Fri, 29 Apr 2022 10:57:10 -0400 > > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > > > Hi, > > > > > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > > > > > > > Hi Samuel, Tom, > > > > > > > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > > > > And I don't have any of this hardware to test. But there are not major > > > > > > > changes to those devicetrees either. > > > > > > > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > > > > old devicetrees, but not the other way around. So to be most compatible > > > > > > > and avoid regressions, those changes are skipped here. > > > > > > > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > > > > patches, and this is indeed the only difference. > > > > > > > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > > > > this goes against our own rules, and more importantly against Tom's one's: > > > > > > to take only direct DT file copies from the kernel tree. > > > > > > > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > > > > critical devices), so this spoils stable distro and installer kernels, > > > > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > > > > > > > For context, those changed properties were in the mainline kernel tree at > > > > > > some point, but have been amended since. So it's not some random change. > > > > > > > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > > > > the common use case is the downstream OS using the DTB we've loaded and > > > > > are using, are we? I mean, we can't be, as ours are so far out of date, > > > > > so this will only be an option when we use a recent DT ourself. So we > > > > > should be able to sync in the changes and update our code, as they can't > > > > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > > > > case that's in the wild atm? Thanks! > > > > > > > > While it sounds like the DTs are wildly out of date, this mostly affects > > > > secondary functionality. The mainline updates for the 64-bit SoCs are: > > > > - H6: adding the VP9 video h/w codec and an additional wakeup timer > > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > > > digital audio interfaces, plus the wakeup timer > > > > Also there are cosmetic changes, like changing node names to make them > > > > binding compliant. > > > > So those DT updates are really only important for mobile devices like the > > > > Pinephone, which probably don't use UEFI booting. > > > > > > > > At the moment I boot distro grubs and installers just fine, and without > > > > losing any real functionality (minus suspend/resume, maybe). The > > > > out-of-the-box default boot works now, and would break when pulling in the > > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > > > > > I guess the first point is, yes, we should sync in what we can sync in, > > > to bring things closer to proper alignment. I further guess that given > > > that we have to support both "new Linux" and "not Linux", we have to > > > keep the old style DT information instead as that's how compatibility is > > > supposed to be handled? I'm adding in Rob here since this still reads a > > > bit confusing as to what's supposed to happen, but maybe we also just > > > need to check in with some other-OS folks to see what their plan is? > > > > My goal with OpenBSD has always been to make the OS boot with the DT > > built into U-Boot, but to allow users to use a more up-to-date Linux > > DT by putting the apropriate .dtb file on the ESP. However it is easy > > to miss changes that break backwards compatibility of the bindings in > > the noise of other changes. So in many cases we only notice this when > > the changes make it into U-Boot and we update the OpenBSD U-Boot port. > > > > I'll drag out one of my A64 boards and see what needs to be done to > > support the routing of these interrupts through r_intc. > > So, does that mean the plan is to keep the r_intc changes out of U-Boot > for now, but we can sync the rest, and come up with a plan to fully > update in time? That would work for me.
On Fri, 29 Apr 2022 14:14:19 -0400 Tom Rini <trini@konsulko.com> wrote: Hi, > On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: > > > Date: Fri, 29 Apr 2022 11:31:00 -0400 > > > From: Tom Rini <trini@konsulko.com> > > > > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > > > On Fri, 29 Apr 2022 10:57:10 -0400 > > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > > > Hi, > > > > > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > > > > > > > Hi Samuel, Tom, > > > > > > > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > > > > And I don't have any of this hardware to test. But there are not major > > > > > > > changes to those devicetrees either. > > > > > > > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > > > > old devicetrees, but not the other way around. So to be most compatible > > > > > > > and avoid regressions, those changes are skipped here. > > > > > > > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > > > > patches, and this is indeed the only difference. > > > > > > > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > > > > this goes against our own rules, and more importantly against Tom's one's: > > > > > > to take only direct DT file copies from the kernel tree. > > > > > > > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > > > > critical devices), so this spoils stable distro and installer kernels, > > > > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > > > > > > > For context, those changed properties were in the mainline kernel tree at > > > > > > some point, but have been amended since. So it's not some random change. > > > > > > > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > > > > the common use case is the downstream OS using the DTB we've loaded and > > > > > are using, are we? I mean, we can't be, as ours are so far out of date, > > > > > so this will only be an option when we use a recent DT ourself. So we > > > > > should be able to sync in the changes and update our code, as they can't > > > > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > > > > case that's in the wild atm? Thanks! > > > > > > > > While it sounds like the DTs are wildly out of date, this mostly affects > > > > secondary functionality. The mainline updates for the 64-bit SoCs are: > > > > - H6: adding the VP9 video h/w codec and an additional wakeup timer > > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > > > digital audio interfaces, plus the wakeup timer > > > > Also there are cosmetic changes, like changing node names to make them > > > > binding compliant. > > > > So those DT updates are really only important for mobile devices like the > > > > Pinephone, which probably don't use UEFI booting. > > > > > > > > At the moment I boot distro grubs and installers just fine, and without > > > > losing any real functionality (minus suspend/resume, maybe). The > > > > out-of-the-box default boot works now, and would break when pulling in the > > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > > > > > I guess the first point is, yes, we should sync in what we can sync in, > > > to bring things closer to proper alignment. I further guess that given > > > that we have to support both "new Linux" and "not Linux", we have to > > > keep the old style DT information instead as that's how compatibility is > > > supposed to be handled? I'm adding in Rob here since this still reads a > > > bit confusing as to what's supposed to happen, but maybe we also just > > > need to check in with some other-OS folks to see what their plan is? > > > > My goal with OpenBSD has always been to make the OS boot with the DT > > built into U-Boot, but to allow users to use a more up-to-date Linux > > DT by putting the apropriate .dtb file on the ESP. However it is easy > > to miss changes that break backwards compatibility of the bindings in > > the noise of other changes. So in many cases we only notice this when > > the changes make it into U-Boot and we update the OpenBSD U-Boot port. > > > > I'll drag out one of my A64 boards and see what needs to be done to > > support the routing of these interrupts through r_intc. In FreeBSD the change would be fairly small, I think: just ignoring the first parameter of an r_intc interrupt specifier when it advertises #interrupt-cells = <3>. In OpenBSD I don't find the allwinner,sun6i-a31-r-intc (or any other intc related) compatible string at all, and so far we just lose the NMI from the PMIC. But this would radically change with the new DT: now the two PIOs and the RTC are routed through that IRQ controller, so they would probably fail probing. > So, does that mean the plan is to keep the r_intc changes out of U-Boot > for now, but we can sync the rest, and come up with a plan to fully > update in time? That's one possible solution, yes, and so far the easiest, it provides a good balance between features and compatibility. Theoretically we can never fully sync, unless we decide to no longer support those older OSes (older Linux kernels and (current) *BSD). One thing we could explore is patching the DT at runtime, but U-Boot cannot know if the OS supports the new style or not, so it has to be manually triggered. Cheers, Andre
On 4/29/22 7:08 PM, Andre Przywara wrote: > On Fri, 29 Apr 2022 14:14:19 -0400 > Tom Rini <trini@konsulko.com> wrote: > > Hi, > >> On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: >>>> Date: Fri, 29 Apr 2022 11:31:00 -0400 >>>> From: Tom Rini <trini@konsulko.com> >>>> >>>> On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: >>>>> On Fri, 29 Apr 2022 10:57:10 -0400 >>>>> Tom Rini <trini@konsulko.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>>> On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: >>>>>>> On Wed, 27 Apr 2022 15:31:19 -0500 >>>>>>> Samuel Holland <samuel@sholland.org> wrote: >>>>>>> >>>>>>> Hi Samuel, Tom, >>>>>>> >>>>>>>> This series brings all of our devicetrees up to date with Linux. >>>>>>>> >>>>>>>> Older SoCs (before A83T) have not been synchronized in over 3 years. >>>>>>>> And I don't have any of this hardware to test. But there are not major >>>>>>>> changes to those devicetrees either. >>>>>>>> >>>>>>>> The big motivation for including older SoCs in this update is converting >>>>>>>> the USB PHY driver to get its VBUS detection GPIO/regulator from the >>>>>>>> devicetree instead of from a pin name in Kconfig. Many older boards had >>>>>>>> those properties added or fixed since the last devicetree sync. This PHY >>>>>>>> driver change is necessary to complete the DM_GPIO migration. >>>>>>>> >>>>>>>> A couple of breaking changes were made to several SoCs' devicetrees in >>>>>>>> Linux relating to the "r_intc" interrupt controller. New kernels support >>>>>>>> old devicetrees, but not the other way around. So to be most compatible >>>>>>>> and avoid regressions, those changes are skipped here. >>>>>>> >>>>>>> Many thanks for considering this! I just skimmed over the A64 and H6 >>>>>>> patches, and this is indeed the only difference. >>>>>>> >>>>>>> But while I love this pragmatic approach, and would be happy to take this, >>>>>>> this goes against our own rules, and more importantly against Tom's one's: >>>>>>> to take only direct DT file copies from the kernel tree. >>>>>>> >>>>>>> Tom, can you give your opinion here? As Samuel mentioned above, the >>>>>>> current mainline DTs wouldn't boot on older kernels (the changes affect >>>>>>> critical devices), so this spoils stable distro and installer kernels, >>>>>>> when using $fdtcontroladdr, for instance when booting via UEFI. >>>>>>> >>>>>>> As a side effect of always defining SYS_SOC to "sunxi", we cannot easily >>>>>>> use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. >>>>>>> >>>>>>> For context, those changed properties were in the mainline kernel tree at >>>>>>> some point, but have been amended since. So it's not some random change. >>>>>> >>>>>> So, this is I guess a bit annoying. But, we aren't at the point where >>>>>> the common use case is the downstream OS using the DTB we've loaded and >>>>>> are using, are we? I mean, we can't be, as ours are so far out of date, >>>>>> so this will only be an option when we use a recent DT ourself. So we >>>>>> should be able to sync in the changes and update our code, as they can't >>>>>> be using $fdtcontroladdr in this case, right? Or am I missing the use >>>>>> case that's in the wild atm? Thanks! >>>>> >>>>> While it sounds like the DTs are wildly out of date, this mostly affects >>>>> secondary functionality. The mainline updates for the 64-bit SoCs are: >>>>> - H6: adding the VP9 video h/w codec and an additional wakeup timer >>>>> - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary >>>>> digital audio interfaces, plus the wakeup timer >>>>> Also there are cosmetic changes, like changing node names to make them >>>>> binding compliant. The SoCs where the DTs are wildly out of date (v4.18-rc3) are: A10 A10s/A13 A31 A20 A80 A23/A33 A83T The SoCs with the r_intc binding change are: A31 A23/A33 A83T A64 H3/H5 H6 For the SoCs which are in both lists, yes, it is unlikely that anyone is using $fdtcontroladdr for Linux. So we could probably fully update those DTs. That leaves just A64, H3/H5, and H6 which would temporarily need to exclude the r_intc-related changes. >>>>> So those DT updates are really only important for mobile devices like the >>>>> Pinephone, which probably don't use UEFI booting. We would really like to use UEFI booting on the PinePhone, and the out-of-date devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up the CPU idle states that are added at runtime by TF-A. >>>>> At the moment I boot distro grubs and installers just fine, and without >>>>> losing any real functionality (minus suspend/resume, maybe). The >>>>> out-of-the-box default boot works now, and would break when pulling in the >>>>> pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), >>>>> can only deal with the older DTs (#interrupt-cells for r_intc must be 2). FreeBSD already supports the new binding for forwarding interrupts (everything except NMI). Any version with this change should boot fine: https://cgit.freebsd.org/src/commit/?id=993e8236c30a >>>> I guess the first point is, yes, we should sync in what we can sync in, >>>> to bring things closer to proper alignment. I further guess that given >>>> that we have to support both "new Linux" and "not Linux", we have to >>>> keep the old style DT information instead as that's how compatibility is >>>> supposed to be handled? I'm adding in Rob here since this still reads a >>>> bit confusing as to what's supposed to happen, but maybe we also just >>>> need to check in with some other-OS folks to see what their plan is? >>> >>> My goal with OpenBSD has always been to make the OS boot with the DT >>> built into U-Boot, but to allow users to use a more up-to-date Linux >>> DT by putting the apropriate .dtb file on the ESP. However it is easy >>> to miss changes that break backwards compatibility of the bindings in >>> the noise of other changes. So in many cases we only notice this when >>> the changes make it into U-Boot and we update the OpenBSD U-Boot port. >>> >>> I'll drag out one of my A64 boards and see what needs to be done to >>> support the routing of these interrupts through r_intc. > > In FreeBSD the change would be fairly small, I think: just ignoring the > first parameter of an r_intc interrupt specifier when it advertises > #interrupt-cells = <3>. See above, FreeBSD already supports this. > In OpenBSD I don't find the allwinner,sun6i-a31-r-intc (or any other > intc related) compatible string at all, and so far we just lose the NMI > from the PMIC. But this would radically change with the new DT: now the > two PIOs and the RTC are routed through that IRQ controller, so they > would probably fail probing. > >> So, does that mean the plan is to keep the r_intc changes out of U-Boot >> for now, but we can sync the rest, and come up with a plan to fully >> update in time? > > That's one possible solution, yes, and so far the easiest, it provides > a good balance between features and compatibility. This was my understanding of the plan as well. > Theoretically we can never fully sync, unless we decide to no longer > support those older OSes (older Linux kernels and (current) *BSD). Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD release? After the distro/BSD installers update their kernels? > One thing we could explore is patching the DT at runtime, but U-Boot > cannot know if the OS supports the new style or not, so it has to be > manually triggered. Right, automatically handling this is not really feasible. Users that need the r_intc changes for suspend/resume will have to load a DTB or overlay from disk. (We could possibly build in such an overlay, and load it based on some environment variable, but this seems like little benefit when most users load a DTB from disk anyway.) Regards, Samuel
On Fri, 29 Apr 2022 21:38:58 -0500 Samuel Holland <samuel@sholland.org> wrote: Hi Samuel, > On 4/29/22 7:08 PM, Andre Przywara wrote: > > On Fri, 29 Apr 2022 14:14:19 -0400 > > Tom Rini <trini@konsulko.com> wrote: > > > > Hi, > > > >> On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: > >>>> Date: Fri, 29 Apr 2022 11:31:00 -0400 > >>>> From: Tom Rini <trini@konsulko.com> > >>>> > >>>> On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > >>>>> On Fri, 29 Apr 2022 10:57:10 -0400 > >>>>> Tom Rini <trini@konsulko.com> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>> On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > >>>>>>> On Wed, 27 Apr 2022 15:31:19 -0500 > >>>>>>> Samuel Holland <samuel@sholland.org> wrote: > >>>>>>> > >>>>>>> Hi Samuel, Tom, > >>>>>>> > >>>>>>>> This series brings all of our devicetrees up to date with Linux. > >>>>>>>> > >>>>>>>> Older SoCs (before A83T) have not been synchronized in over 3 years. > >>>>>>>> And I don't have any of this hardware to test. But there are not major > >>>>>>>> changes to those devicetrees either. > >>>>>>>> > >>>>>>>> The big motivation for including older SoCs in this update is converting > >>>>>>>> the USB PHY driver to get its VBUS detection GPIO/regulator from the > >>>>>>>> devicetree instead of from a pin name in Kconfig. Many older boards had > >>>>>>>> those properties added or fixed since the last devicetree sync. This PHY > >>>>>>>> driver change is necessary to complete the DM_GPIO migration. > >>>>>>>> > >>>>>>>> A couple of breaking changes were made to several SoCs' devicetrees in > >>>>>>>> Linux relating to the "r_intc" interrupt controller. New kernels support > >>>>>>>> old devicetrees, but not the other way around. So to be most compatible > >>>>>>>> and avoid regressions, those changes are skipped here. > >>>>>>> > >>>>>>> Many thanks for considering this! I just skimmed over the A64 and H6 > >>>>>>> patches, and this is indeed the only difference. > >>>>>>> > >>>>>>> But while I love this pragmatic approach, and would be happy to take this, > >>>>>>> this goes against our own rules, and more importantly against Tom's one's: > >>>>>>> to take only direct DT file copies from the kernel tree. > >>>>>>> > >>>>>>> Tom, can you give your opinion here? As Samuel mentioned above, the > >>>>>>> current mainline DTs wouldn't boot on older kernels (the changes affect > >>>>>>> critical devices), so this spoils stable distro and installer kernels, > >>>>>>> when using $fdtcontroladdr, for instance when booting via UEFI. > >>>>>>> > >>>>>>> As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > >>>>>>> use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > >>>>>>> > >>>>>>> For context, those changed properties were in the mainline kernel tree at > >>>>>>> some point, but have been amended since. So it's not some random change. > >>>>>> > >>>>>> So, this is I guess a bit annoying. But, we aren't at the point where > >>>>>> the common use case is the downstream OS using the DTB we've loaded and > >>>>>> are using, are we? I mean, we can't be, as ours are so far out of date, > >>>>>> so this will only be an option when we use a recent DT ourself. So we > >>>>>> should be able to sync in the changes and update our code, as they can't > >>>>>> be using $fdtcontroladdr in this case, right? Or am I missing the use > >>>>>> case that's in the wild atm? Thanks! > >>>>> > >>>>> While it sounds like the DTs are wildly out of date, this mostly affects > >>>>> secondary functionality. The mainline updates for the 64-bit SoCs are: > >>>>> - H6: adding the VP9 video h/w codec and an additional wakeup timer > >>>>> - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > >>>>> digital audio interfaces, plus the wakeup timer > >>>>> Also there are cosmetic changes, like changing node names to make them > >>>>> binding compliant. > > The SoCs where the DTs are wildly out of date (v4.18-rc3) are: > A10 A10s/A13 A31 A20 A80 A23/A33 A83T > > The SoCs with the r_intc binding change are: > A31 A23/A33 A83T A64 H3/H5 H6 > > For the SoCs which are in both lists, yes, it is unlikely that anyone is using > $fdtcontroladdr for Linux. So we could probably fully update those DTs. That > leaves just A64, H3/H5, and H6 which would temporarily need to exclude the > r_intc-related changes. Yes, I don't really care about those older SoCs, devices using them are probably not really distro / UEFI material anyway. > >>>>> So those DT updates are really only important for mobile devices like the > >>>>> Pinephone, which probably don't use UEFI booting. > > We would really like to use UEFI booting on the PinePhone, and the out-of-date > devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up > the CPU idle states that are added at runtime by TF-A. Yes, I was wondering about that. I could imagine that suspend/resume is a killer feature for the PinePhone. It probably sounds useful to fully update just the Pinephone .dts, giving up compatibility for older kernels. IIUC the PinePhone doesn't run normal "desktop" distros, but relies more on custom OSes, tailored to a Phone use case in general? What kernels are those OSes using? The only caveat would be that this adds to the mess and increases the diff to mainline, but maybe this could be solved by a sun50i-a64-pinephone-u-boot.dtsi? > >>>>> At the moment I boot distro grubs and installers just fine, and without > >>>>> losing any real functionality (minus suspend/resume, maybe). The > >>>>> out-of-the-box default boot works now, and would break when pulling in the > >>>>> pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > >>>>> can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > FreeBSD already supports the new binding for forwarding interrupts (everything > except NMI). Any version with this change should boot fine: > > https://cgit.freebsd.org/src/commit/?id=993e8236c30a Ah, sorry, my bad, I was looking at a stale repo (they stopped updating the original master branch and switched to main, for technical reasons). > >>>> I guess the first point is, yes, we should sync in what we can sync in, > >>>> to bring things closer to proper alignment. I further guess that given > >>>> that we have to support both "new Linux" and "not Linux", we have to > >>>> keep the old style DT information instead as that's how compatibility is > >>>> supposed to be handled? I'm adding in Rob here since this still reads a > >>>> bit confusing as to what's supposed to happen, but maybe we also just > >>>> need to check in with some other-OS folks to see what their plan is? > >>> > >>> My goal with OpenBSD has always been to make the OS boot with the DT > >>> built into U-Boot, but to allow users to use a more up-to-date Linux > >>> DT by putting the apropriate .dtb file on the ESP. However it is easy > >>> to miss changes that break backwards compatibility of the bindings in > >>> the noise of other changes. So in many cases we only notice this when > >>> the changes make it into U-Boot and we update the OpenBSD U-Boot port. > >>> > >>> I'll drag out one of my A64 boards and see what needs to be done to > >>> support the routing of these interrupts through r_intc. > > > > In FreeBSD the change would be fairly small, I think: just ignoring the > > first parameter of an r_intc interrupt specifier when it advertises > > #interrupt-cells = <3>. > > See above, FreeBSD already supports this. > > > In OpenBSD I don't find the allwinner,sun6i-a31-r-intc (or any other > > intc related) compatible string at all, and so far we just lose the NMI > > from the PMIC. But this would radically change with the new DT: now the > > two PIOs and the RTC are routed through that IRQ controller, so they > > would probably fail probing. > > > >> So, does that mean the plan is to keep the r_intc changes out of U-Boot > >> for now, but we can sync the rest, and come up with a plan to fully > >> update in time? > > > > That's one possible solution, yes, and so far the easiest, it provides > > a good balance between features and compatibility. > > This was my understanding of the plan as well. > > > Theoretically we can never fully sync, unless we decide to no longer > > support those older OSes (older Linux kernels and (current) *BSD). > > Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD > release? After the distro/BSD installers update their kernels? More the latter, I'd say when major distros stop shipping those old kernels in relevant releases. Especially Debian is one to keep an eye on I guess, since they are on 5.10 *currently*, and their installer properly stays there for a while. Ubuntu 20.04 shipped with 5.4, and I'd like to support that say at least one more year still. Don't really keep track of the kernels in other distros, but I think these two are among the more conservative ones. Samuel, since I have you here: With your new hat Linux hat on, can you say whether incompatible DT changes won't happen in the future anymore? From experience I'd say there are ways to avoid them, though possibly at some cost (less clean DT, or deviating from some DT rules). > > One thing we could explore is patching the DT at runtime, but U-Boot > > cannot know if the OS supports the new style or not, so it has to be > > manually triggered. > > Right, automatically handling this is not really feasible. Users that need the > r_intc changes for suspend/resume will have to load a DTB or overlay from disk. > (We could possibly build in such an overlay, and load it based on some > environment variable, but this seems like little benefit when most users load a > DTB from disk anyway.) But loading from disk would lose any manipulation that previous firmware did, for instance TF-A. Plus I think reserved memory is not properly propagated, at least last time I checked. Also the DT would really need to be loaded by U-Boot, loading it via grub would lose even more manipulations like the DRAM size and MAC address. So I believe an overlay is the way to go. I have a patch sitting here that applies all .dtbo files found in a directory on some block device (e.g. "fdt apply_all mmc 0:1 overlays/"), would that help? Cheers, Andre
> Date: Sun, 1 May 2022 01:59:21 +0100 > From: Andre Przywara <andre.przywara@arm.com> Hi Andre, > On Fri, 29 Apr 2022 21:38:58 -0500 > Samuel Holland <samuel@sholland.org> wrote: > > Hi Samuel, > > > On 4/29/22 7:08 PM, Andre Przywara wrote: > > > On Fri, 29 Apr 2022 14:14:19 -0400 > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > Hi, > > > > > >> On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: > > >>>> Date: Fri, 29 Apr 2022 11:31:00 -0400 > > >>>> From: Tom Rini <trini@konsulko.com> > > >>>> > > >>>> On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > >>>>> On Fri, 29 Apr 2022 10:57:10 -0400 > > >>>>> Tom Rini <trini@konsulko.com> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>>> On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > >>>>>>> On Wed, 27 Apr 2022 15:31:19 -0500 > > >>>>>>> Samuel Holland <samuel@sholland.org> wrote: > > >>>>>>> > > >>>>>>> Hi Samuel, Tom, > > >>>>>>> > > >>>>>>>> This series brings all of our devicetrees up to date with Linux. > > >>>>>>>> > > >>>>>>>> Older SoCs (before A83T) have not been synchronized in over 3 years. > > >>>>>>>> And I don't have any of this hardware to test. But there are not major > > >>>>>>>> changes to those devicetrees either. > > >>>>>>>> > > >>>>>>>> The big motivation for including older SoCs in this update is converting > > >>>>>>>> the USB PHY driver to get its VBUS detection GPIO/regulator from the > > >>>>>>>> devicetree instead of from a pin name in Kconfig. Many older boards had > > >>>>>>>> those properties added or fixed since the last devicetree sync. This PHY > > >>>>>>>> driver change is necessary to complete the DM_GPIO migration. > > >>>>>>>> > > >>>>>>>> A couple of breaking changes were made to several SoCs' devicetrees in > > >>>>>>>> Linux relating to the "r_intc" interrupt controller. New kernels support > > >>>>>>>> old devicetrees, but not the other way around. So to be most compatible > > >>>>>>>> and avoid regressions, those changes are skipped here. > > >>>>>>> > > >>>>>>> Many thanks for considering this! I just skimmed over the A64 and H6 > > >>>>>>> patches, and this is indeed the only difference. > > >>>>>>> > > >>>>>>> But while I love this pragmatic approach, and would be happy to take this, > > >>>>>>> this goes against our own rules, and more importantly against Tom's one's: > > >>>>>>> to take only direct DT file copies from the kernel tree. > > >>>>>>> > > >>>>>>> Tom, can you give your opinion here? As Samuel mentioned above, the > > >>>>>>> current mainline DTs wouldn't boot on older kernels (the changes affect > > >>>>>>> critical devices), so this spoils stable distro and installer kernels, > > >>>>>>> when using $fdtcontroladdr, for instance when booting via UEFI. > > >>>>>>> > > >>>>>>> As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > >>>>>>> use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > >>>>>>> > > >>>>>>> For context, those changed properties were in the mainline kernel tree at > > >>>>>>> some point, but have been amended since. So it's not some random change. > > >>>>>> > > >>>>>> So, this is I guess a bit annoying. But, we aren't at the point where > > >>>>>> the common use case is the downstream OS using the DTB we've loaded and > > >>>>>> are using, are we? I mean, we can't be, as ours are so far out of date, > > >>>>>> so this will only be an option when we use a recent DT ourself. So we > > >>>>>> should be able to sync in the changes and update our code, as they can't > > >>>>>> be using $fdtcontroladdr in this case, right? Or am I missing the use > > >>>>>> case that's in the wild atm? Thanks! > > >>>>> > > >>>>> While it sounds like the DTs are wildly out of date, this mostly affects > > >>>>> secondary functionality. The mainline updates for the 64-bit SoCs are: > > >>>>> - H6: adding the VP9 video h/w codec and an additional wakeup timer > > >>>>> - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > >>>>> digital audio interfaces, plus the wakeup timer > > >>>>> Also there are cosmetic changes, like changing node names to make them > > >>>>> binding compliant. > > > > The SoCs where the DTs are wildly out of date (v4.18-rc3) are: > > A10 A10s/A13 A31 A20 A80 A23/A33 A83T > > > > The SoCs with the r_intc binding change are: > > A31 A23/A33 A83T A64 H3/H5 H6 > > > > For the SoCs which are in both lists, yes, it is unlikely that anyone is using > > $fdtcontroladdr for Linux. So we could probably fully update those DTs. That > > leaves just A64, H3/H5, and H6 which would temporarily need to exclude the > > r_intc-related changes. > > Yes, I don't really care about those older SoCs, devices using them are > probably not really distro / UEFI material anyway. OpenBSD boots via UEFI on all of these SoCs (A31, A23/A33 and A83T are not really supported though). That said, I just checked and OpenBSD still boots on my NanoPi A64 with a device tree from mainline Linux. Basically, we don't have a driver for the r_intc interrupt controller yet and none of the drivers that are affected by change actually use interrupts. So everything that's important still works ;). So basically, don't let OpenBSD hold you back. > > >>>>> So those DT updates are really only important for mobile devices like the > > >>>>> Pinephone, which probably don't use UEFI booting. > > > > We would really like to use UEFI booting on the PinePhone, and the out-of-date > > devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up > > the CPU idle states that are added at runtime by TF-A. > > Yes, I was wondering about that. I could imagine that suspend/resume is > a killer feature for the PinePhone. It probably sounds useful to fully > update just the Pinephone .dts, giving up compatibility for older > kernels. IIUC the PinePhone doesn't run normal "desktop" distros, but > relies more on custom OSes, tailored to a Phone use case in general? > What kernels are those OSes using? > The only caveat would be that this adds to the mess and increases the > diff to mainline, but maybe this could be solved by a > sun50i-a64-pinephone-u-boot.dtsi? > > > >>>>> At the moment I boot distro grubs and installers just fine, and without > > >>>>> losing any real functionality (minus suspend/resume, maybe). The > > >>>>> out-of-the-box default boot works now, and would break when pulling in the > > >>>>> pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > >>>>> can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > > > FreeBSD already supports the new binding for forwarding interrupts (everything > > except NMI). Any version with this change should boot fine: > > > > https://cgit.freebsd.org/src/commit/?id=993e8236c30a > > Ah, sorry, my bad, I was looking at a stale repo (they stopped updating > the original master branch and switched to main, for technical reasons). > > > >>>> I guess the first point is, yes, we should sync in what we can sync in, > > >>>> to bring things closer to proper alignment. I further guess that given > > >>>> that we have to support both "new Linux" and "not Linux", we have to > > >>>> keep the old style DT information instead as that's how compatibility is > > >>>> supposed to be handled? I'm adding in Rob here since this still reads a > > >>>> bit confusing as to what's supposed to happen, but maybe we also just > > >>>> need to check in with some other-OS folks to see what their plan is? > > >>> > > >>> My goal with OpenBSD has always been to make the OS boot with the DT > > >>> built into U-Boot, but to allow users to use a more up-to-date Linux > > >>> DT by putting the apropriate .dtb file on the ESP. However it is easy > > >>> to miss changes that break backwards compatibility of the bindings in > > >>> the noise of other changes. So in many cases we only notice this when > > >>> the changes make it into U-Boot and we update the OpenBSD U-Boot port. > > >>> > > >>> I'll drag out one of my A64 boards and see what needs to be done to > > >>> support the routing of these interrupts through r_intc. > > > > > > In FreeBSD the change would be fairly small, I think: just ignoring the > > > first parameter of an r_intc interrupt specifier when it advertises > > > #interrupt-cells = <3>. > > > > See above, FreeBSD already supports this. > > > > > In OpenBSD I don't find the allwinner,sun6i-a31-r-intc (or any other > > > intc related) compatible string at all, and so far we just lose the NMI > > > from the PMIC. But this would radically change with the new DT: now the > > > two PIOs and the RTC are routed through that IRQ controller, so they > > > would probably fail probing. > > > > > >> So, does that mean the plan is to keep the r_intc changes out of U-Boot > > >> for now, but we can sync the rest, and come up with a plan to fully > > >> update in time? > > > > > > That's one possible solution, yes, and so far the easiest, it provides > > > a good balance between features and compatibility. > > > > This was my understanding of the plan as well. > > > > > Theoretically we can never fully sync, unless we decide to no longer > > > support those older OSes (older Linux kernels and (current) *BSD). > > > > Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD > > release? After the distro/BSD installers update their kernels? > > More the latter, I'd say when major distros stop shipping those > old kernels in relevant releases. Especially Debian is one to keep an > eye on I guess, since they are on 5.10 *currently*, and their installer > properly stays there for a while. Ubuntu 20.04 shipped with 5.4, and I'd > like to support that say at least one more year still. Don't really > keep track of the kernels in other distros, but I think these two are > among the more conservative ones. So as stated above, OpenBSD is unaffected by the r_intc changes. If it would be affected, our release cycle is 6 months, so backwards compatibility would be needed for a little bit longer than 6 months probably. > Samuel, since I have you here: With your new hat Linux hat on, can you > say whether incompatible DT changes won't happen in the future anymore? > From experience I'd say there are ways to avoid them, though possibly at > some cost (less clean DT, or deviating from some DT rules). > > > > One thing we could explore is patching the DT at runtime, but U-Boot > > > cannot know if the OS supports the new style or not, so it has to be > > > manually triggered. > > > > Right, automatically handling this is not really feasible. Users that need the > > r_intc changes for suspend/resume will have to load a DTB or overlay from disk. > > (We could possibly build in such an overlay, and load it based on some > > environment variable, but this seems like little benefit when most users load a > > DTB from disk anyway.) > > But loading from disk would lose any manipulation that previous > firmware did, for instance TF-A. Plus I think reserved memory is not > properly propagated, at least last time I checked. Also the DT would > really need to be loaded by U-Boot, loading it via grub would lose even > more manipulations like the DRAM size and MAC address. > > So I believe an overlay is the way to go. I have a patch sitting here > that applies all .dtbo files found in a directory on some block device > (e.g. "fdt apply_all mmc 0:1 overlays/"), would that help? > > Cheers, > Andre >
On Sat, Apr 30, 2022 at 01:08:43AM +0100, Andre Przywara wrote: > On Fri, 29 Apr 2022 14:14:19 -0400 > Tom Rini <trini@konsulko.com> wrote: > > Hi, > > > On Fri, Apr 29, 2022 at 06:05:03PM +0200, Mark Kettenis wrote: > > > > Date: Fri, 29 Apr 2022 11:31:00 -0400 > > > > From: Tom Rini <trini@konsulko.com> > > > > > > > > On Fri, Apr 29, 2022 at 04:25:51PM +0100, Andre Przywara wrote: > > > > > On Fri, 29 Apr 2022 10:57:10 -0400 > > > > > Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > Hi, > > > > > > > > > > > On Fri, Apr 29, 2022 at 03:51:59PM +0100, Andre Przywara wrote: > > > > > > > On Wed, 27 Apr 2022 15:31:19 -0500 > > > > > > > Samuel Holland <samuel@sholland.org> wrote: > > > > > > > > > > > > > > Hi Samuel, Tom, > > > > > > > > > > > > > > > This series brings all of our devicetrees up to date with Linux. > > > > > > > > > > > > > > > > Older SoCs (before A83T) have not been synchronized in over 3 years. > > > > > > > > And I don't have any of this hardware to test. But there are not major > > > > > > > > changes to those devicetrees either. > > > > > > > > > > > > > > > > The big motivation for including older SoCs in this update is converting > > > > > > > > the USB PHY driver to get its VBUS detection GPIO/regulator from the > > > > > > > > devicetree instead of from a pin name in Kconfig. Many older boards had > > > > > > > > those properties added or fixed since the last devicetree sync. This PHY > > > > > > > > driver change is necessary to complete the DM_GPIO migration. > > > > > > > > > > > > > > > > A couple of breaking changes were made to several SoCs' devicetrees in > > > > > > > > Linux relating to the "r_intc" interrupt controller. New kernels support > > > > > > > > old devicetrees, but not the other way around. So to be most compatible > > > > > > > > and avoid regressions, those changes are skipped here. > > > > > > > > > > > > > > Many thanks for considering this! I just skimmed over the A64 and H6 > > > > > > > patches, and this is indeed the only difference. > > > > > > > > > > > > > > But while I love this pragmatic approach, and would be happy to take this, > > > > > > > this goes against our own rules, and more importantly against Tom's one's: > > > > > > > to take only direct DT file copies from the kernel tree. > > > > > > > > > > > > > > Tom, can you give your opinion here? As Samuel mentioned above, the > > > > > > > current mainline DTs wouldn't boot on older kernels (the changes affect > > > > > > > critical devices), so this spoils stable distro and installer kernels, > > > > > > > when using $fdtcontroladdr, for instance when booting via UEFI. > > > > > > > > > > > > > > As a side effect of always defining SYS_SOC to "sunxi", we cannot easily > > > > > > > use per-SoC DT overrides using sun50i-a64-u-boot.dtsi, for instance. > > > > > > > > > > > > > > For context, those changed properties were in the mainline kernel tree at > > > > > > > some point, but have been amended since. So it's not some random change. > > > > > > > > > > > > So, this is I guess a bit annoying. But, we aren't at the point where > > > > > > the common use case is the downstream OS using the DTB we've loaded and > > > > > > are using, are we? I mean, we can't be, as ours are so far out of date, > > > > > > so this will only be an option when we use a recent DT ourself. So we > > > > > > should be able to sync in the changes and update our code, as they can't > > > > > > be using $fdtcontroladdr in this case, right? Or am I missing the use > > > > > > case that's in the wild atm? Thanks! > > > > > > > > > > While it sounds like the DTs are wildly out of date, this mostly affects > > > > > secondary functionality. The mainline updates for the 64-bit SoCs are: > > > > > - H6: adding the VP9 video h/w codec and an additional wakeup timer > > > > > - A64: adding GPU DVFS, adding DRAM DVFS, add support for secondary > > > > > digital audio interfaces, plus the wakeup timer > > > > > Also there are cosmetic changes, like changing node names to make them > > > > > binding compliant. > > > > > So those DT updates are really only important for mobile devices like the > > > > > Pinephone, which probably don't use UEFI booting. > > > > > > > > > > At the moment I boot distro grubs and installers just fine, and without > > > > > losing any real functionality (minus suspend/resume, maybe). The > > > > > out-of-the-box default boot works now, and would break when pulling in the > > > > > pure mainline DTs. Plus FreeBSD (which relies more heavily on UEFI, IIUC), > > > > > can only deal with the older DTs (#interrupt-cells for r_intc must be 2). > > > > > > > > I guess the first point is, yes, we should sync in what we can sync in, > > > > to bring things closer to proper alignment. I further guess that given > > > > that we have to support both "new Linux" and "not Linux", we have to > > > > keep the old style DT information instead as that's how compatibility is > > > > supposed to be handled? I'm adding in Rob here since this still reads a > > > > bit confusing as to what's supposed to happen, but maybe we also just > > > > need to check in with some other-OS folks to see what their plan is? > > > > > > My goal with OpenBSD has always been to make the OS boot with the DT > > > built into U-Boot, but to allow users to use a more up-to-date Linux > > > DT by putting the apropriate .dtb file on the ESP. However it is easy > > > to miss changes that break backwards compatibility of the bindings in > > > the noise of other changes. So in many cases we only notice this when > > > the changes make it into U-Boot and we update the OpenBSD U-Boot port. > > > > > > I'll drag out one of my A64 boards and see what needs to be done to > > > support the routing of these interrupts through r_intc. > > In FreeBSD the change would be fairly small, I think: just ignoring the > first parameter of an r_intc interrupt specifier when it advertises > #interrupt-cells = <3>. > In OpenBSD I don't find the allwinner,sun6i-a31-r-intc (or any other > intc related) compatible string at all, and so far we just lose the NMI > from the PMIC. But this would radically change with the new DT: now the > two PIOs and the RTC are routed through that IRQ controller, so they > would probably fail probing. > > > So, does that mean the plan is to keep the r_intc changes out of U-Boot > > for now, but we can sync the rest, and come up with a plan to fully > > update in time? > > That's one possible solution, yes, and so far the easiest, it provides > a good balance between features and compatibility. > Theoretically we can never fully sync, unless we decide to no longer > support those older OSes (older Linux kernels and (current) *BSD). I believe saying older OSes need to load and pass their device tee, rather than be able to rely on the run-time one, is reasonable. We need to document this somewhere, and then specifically call this out in release emails. But, it seems like a reasonable compromise for supporting older OSes.
On 4/30/22 7:59 PM, Andre Przywara wrote: >>>>>>> So those DT updates are really only important for mobile devices like the >>>>>>> Pinephone, which probably don't use UEFI booting. >> >> We would really like to use UEFI booting on the PinePhone, and the out-of-date >> devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up >> the CPU idle states that are added at runtime by TF-A. > > Yes, I was wondering about that. I could imagine that suspend/resume is > a killer feature for the PinePhone. It probably sounds useful to fully > update just the Pinephone .dts, giving up compatibility for older > kernels. IIUC the PinePhone doesn't run normal "desktop" distros, but > relies more on custom OSes, tailored to a Phone use case in general? There is a mix of desktop distros, mobile spins of desktop distros (the largest/most popular category), and mobile-specific OSes[1]. [1]: https://wiki.pine64.org/wiki/PinePhone_Software_Releases > What kernels are those OSes using? Most are using Ondrej's fork[2]. Some (at least Mobian) maintain their own patch set. [2]: https://github.com/megous/linux/tags > The only caveat would be that this adds to the mess and increases the > diff to mainline, but maybe this could be solved by a > sun50i-a64-pinephone-u-boot.dtsi? Devicetree changes are still needed for camera and USB Type C support, so the r_intc changes could go in with those. I don't think we need to do anything special from the U-Boot side at this point. >>>> So, does that mean the plan is to keep the r_intc changes out of U-Boot >>>> for now, but we can sync the rest, and come up with a plan to fully >>>> update in time? >>> >>> That's one possible solution, yes, and so far the easiest, it provides >>> a good balance between features and compatibility. >> >> This was my understanding of the plan as well. >> >>> Theoretically we can never fully sync, unless we decide to no longer >>> support those older OSes (older Linux kernels and (current) *BSD). >> >> Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD >> release? After the distro/BSD installers update their kernels? > > More the latter, I'd say when major distros stop shipping those > old kernels in relevant releases. Especially Debian is one to keep an > eye on I guess, since they are on 5.10 *currently*, and their installer > properly stays there for a while. Ubuntu 20.04 shipped with 5.4, and I'd > like to support that say at least one more year still. Don't really > keep track of the kernels in other distros, but I think these two are > among the more conservative ones. OK, that makes sense. > Samuel, since I have you here: With your new hat Linux hat on, can you > say whether incompatible DT changes won't happen in the future anymore? No, I really cannot. As for major breaking changes, there is some push from the Linux clock maintainers toward finishing the conversion from legacy to sunxi-ng clock drivers. This affects A31, A23/A33, and A80. (In fact, this unfinished conversion is causing me quite some trouble trying to expand the DM clock drivers in U-Boot.) And then there are always little easy-to-miss things (like adding references to new ASoC widgets) that prevent drivers from loading on old kernels. > From experience I'd say there are ways to avoid them, though possibly at > some cost (less clean DT, or deviating from some DT rules). and, as I'm sure you're painfully aware of, delays in adding support for new hardware, until we can get the binding perfect, because we know we will be stuck with it. >>> One thing we could explore is patching the DT at runtime, but U-Boot >>> cannot know if the OS supports the new style or not, so it has to be >>> manually triggered. >> >> Right, automatically handling this is not really feasible. Users that need the >> r_intc changes for suspend/resume will have to load a DTB or overlay from disk. >> (We could possibly build in such an overlay, and load it based on some >> environment variable, but this seems like little benefit when most users load a >> DTB from disk anyway.) > > But loading from disk would lose any manipulation that previous > firmware did, for instance TF-A. Plus I think reserved memory is not > properly propagated, at least last time I checked. Also the DT would > really need to be loaded by U-Boot, loading it via grub would lose even > more manipulations like the DRAM size and MAC address. > > So I believe an overlay is the way to go. I have a patch sitting here > that applies all .dtbo files found in a directory on some block device > (e.g. "fdt apply_all mmc 0:1 overlays/"), would that help? Possibly? I will defer to others on how devicetree overlays could/should be integrated into the distro boot process. Regards, Samuel
On Mon, 2 May 2022 20:57:35 -0500 Samuel Holland <samuel@sholland.org> wrote: Hi Samuel, > On 4/30/22 7:59 PM, Andre Przywara wrote: > >>>>>>> So those DT updates are really only important for mobile devices like the > >>>>>>> Pinephone, which probably don't use UEFI booting. > >> > >> We would really like to use UEFI booting on the PinePhone, and the out-of-date > >> devicetree is one thing blocking that. We need to use $fdtcontroladdr to pick up > >> the CPU idle states that are added at runtime by TF-A. > > > > Yes, I was wondering about that. I could imagine that suspend/resume is > > a killer feature for the PinePhone. It probably sounds useful to fully > > update just the Pinephone .dts, giving up compatibility for older > > kernels. IIUC the PinePhone doesn't run normal "desktop" distros, but > > relies more on custom OSes, tailored to a Phone use case in general? > > There is a mix of desktop distros, mobile spins of desktop distros (the > largest/most popular category), and mobile-specific OSes[1]. > > [1]: https://wiki.pine64.org/wiki/PinePhone_Software_Releases > > > What kernels are those OSes using? > > Most are using Ondrej's fork[2]. Some (at least Mobian) maintain their own patch > set. So that means it's all quite Pinephone specific then, and none of them are using actual mainline kernels? So people don't run a stock Debian mini.iso on it, for instance? When I was asking for "kernels", I was hoping for mainline kernel *version numbers*, not forks, but I get the idea ;-) > [2]: https://github.com/megous/linux/tags > > > The only caveat would be that this adds to the mess and increases the > > diff to mainline, but maybe this could be solved by a > > sun50i-a64-pinephone-u-boot.dtsi? > > Devicetree changes are still needed for camera and USB Type C support, so the > r_intc changes could go in with those. I don't think we need to do anything > special from the U-Boot side at this point. I was thinking about putting the r_intc changes just in the pinephone-u-boot.dtsi, so that the Pinephone gets them, but every other (development) board does not. Sounds somewhat dodgy, but would pragmatically solve the problem of stability for devboards *and* the Pinephone being usable. Do Pinephone users actually use U-Boot? Also I am not so much concerned about non-essential devices like a camera or USB-C alternative functions, I guess those could even be fixed up using DT overlays while running Linux already, from some script. The problem with the r_intc changes is that last time I checked they break already when booting an initrd, because of the pinctrl driver not probing. > >>>> So, does that mean the plan is to keep the r_intc changes out of U-Boot > >>>> for now, but we can sync the rest, and come up with a plan to fully > >>>> update in time? > >>> > >>> That's one possible solution, yes, and so far the easiest, it provides > >>> a good balance between features and compatibility. > >> > >> This was my understanding of the plan as well. > >> > >>> Theoretically we can never fully sync, unless we decide to no longer > >>> support those older OSes (older Linux kernels and (current) *BSD). > >> > >> Do we have any guidance for when this could be? After the n+1 LTS kernel/BSD > >> release? After the distro/BSD installers update their kernels? > > > > More the latter, I'd say when major distros stop shipping those > > old kernels in relevant releases. Especially Debian is one to keep an > > eye on I guess, since they are on 5.10 *currently*, and their installer > > properly stays there for a while. Ubuntu 20.04 shipped with 5.4, and I'd > > like to support that say at least one more year still. Don't really > > keep track of the kernels in other distros, but I think these two are > > among the more conservative ones. > > OK, that makes sense. > > > Samuel, since I have you here: With your new hat Linux hat on, can you > > say whether incompatible DT changes won't happen in the future anymore? > > No, I really cannot. > > As for major breaking changes, there is some push from the Linux clock > maintainers toward finishing the conversion from legacy to sunxi-ng clock > drivers. This affects A31, A23/A33, and A80. (In fact, this unfinished > conversion is causing me quite some trouble trying to expand the DM clock > drivers in U-Boot.) I am personally less concerned about those older devices, especially those SoCs you mentioned, which were mostly somewhat "embedded" anyway. Plus their DTs in the U-Boot tree are outdated already. In my understanding the A10/A20/H3 devices see quite some more wide-spread usage, some running off-the-shelf distros (I certainly do). And I care more about the v8 devices, especially since arm64 has a more grown-up boot story. > And then there are always little easy-to-miss things (like adding references to > new ASoC widgets) that prevent drivers from loading on old kernels. As mentioned, if that affects secondary features like audio, video, camera, that is less concerning to me. Not being able to boot at all is a different story, though. > > From experience I'd say there are ways to avoid them, though possibly at > > some cost (less clean DT, or deviating from some DT rules). > > and, as I'm sure you're painfully aware of, delays in adding support for new > hardware, until we can get the binding perfect, because we know we will be stuck > with it. Yes, I understand ;-) I totally see that, and was already wondering about some kind of "grace period" for new SoCs, so that we declare their DTs unstable initially, to unblock development and gather experience with it in the field. Just to make this clear: I understand that it's not easy to maintain DT compatibility, but I think it's essential to make this a "serious" platform. I was just wondering if this compatibility goal is something that's considered worth fighting for; in the past that was outright dismissed. Cheers, Andre > >>> One thing we could explore is patching the DT at runtime, but U-Boot > >>> cannot know if the OS supports the new style or not, so it has to be > >>> manually triggered. > >> > >> Right, automatically handling this is not really feasible. Users that need the > >> r_intc changes for suspend/resume will have to load a DTB or overlay from disk. > >> (We could possibly build in such an overlay, and load it based on some > >> environment variable, but this seems like little benefit when most users load a > >> DTB from disk anyway.) > > > > But loading from disk would lose any manipulation that previous > > firmware did, for instance TF-A. Plus I think reserved memory is not > > properly propagated, at least last time I checked. Also the DT would > > really need to be loaded by U-Boot, loading it via grub would lose even > > more manipulations like the DRAM size and MAC address. > > > > So I believe an overlay is the way to go. I have a patch sitting here > > that applies all .dtbo files found in a directory on some block device > > (e.g. "fdt apply_all mmc 0:1 overlays/"), would that help? > > Possibly? I will defer to others on how devicetree overlays could/should be > integrated into the distro boot process. > > Regards, > Samuel
On Wed, 27 Apr 2022 15:31:22 -0500 Samuel Holland <samuel@sholland.org> wrote: > Copy the devicetree source for the A10 SoC and all existing boards > verbatim from the Linux v5.18-rc1 tag. > > This commit also adds the following new board devicetree: > - sun4i-a10-topwise-a721.dts > > While this update should not impact any existing U-Boot functionality, > the changes to the USB PHY detection GPIO properties are needed to > convert that driver to use the DM GPIO framework. Interestingly Patchwork missed this patch, and saving it from my client messed up the ISO8859/1 -> UTF8 conversion at the very top of sun4i-a10-inet97fv2.dts. But I managed to fix that up manually. Other than that there is indeed no diff compared to the kernel. > Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Cheers, Andre > --- > > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/axp209.dtsi | 6 +- > arch/arm/dts/sun4i-a10-a1000.dts | 31 ++- > arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 2 +- > arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts | 20 +- > arch/arm/dts/sun4i-a10-cubieboard.dts | 16 +- > arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 21 +- > arch/arm/dts/sun4i-a10-hackberry.dts | 2 +- > arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 20 +- > arch/arm/dts/sun4i-a10-inet1.dts | 21 +- > arch/arm/dts/sun4i-a10-inet97fv2.dts | 22 +- > arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 74 ++---- > .../dts/sun4i-a10-itead-iteaduino-plus.dts | 2 +- > arch/arm/dts/sun4i-a10-jesurun-q5.dts | 4 +- > arch/arm/dts/sun4i-a10-marsboard.dts | 22 +- > arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 33 +-- > arch/arm/dts/sun4i-a10-pcduino.dts | 20 +- > arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 21 +- > arch/arm/dts/sun4i-a10-topwise-a721.dts | 242 ++++++++++++++++++ > arch/arm/dts/sun4i-a10.dtsi | 135 +++++++++- > 20 files changed, 462 insertions(+), 255 deletions(-) > create mode 100644 arch/arm/dts/sun4i-a10-topwise-a721.dts > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index ab2d0da192..48ede8888e 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -539,7 +539,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \ > sun4i-a10-olinuxino-lime.dtb \ > sun4i-a10-pcduino.dtb \ > sun4i-a10-pcduino2.dtb \ > - sun4i-a10-pov-protab2-ips9.dtb > + sun4i-a10-pov-protab2-ips9.dtb \ > + sun4i-a10-topwise-a721.dtb > dtb-$(CONFIG_MACH_SUN5I) += \ > sun5i-a10s-auxtek-t003.dtb \ > sun5i-a10s-auxtek-t004.dtb \ > diff --git a/arch/arm/dts/axp209.dtsi b/arch/arm/dts/axp209.dtsi > index 0d9ff12bdf..ca240cd6f6 100644 > --- a/arch/arm/dts/axp209.dtsi > +++ b/arch/arm/dts/axp209.dtsi > @@ -53,7 +53,7 @@ > interrupt-controller; > #interrupt-cells = <1>; > > - ac_power_supply: ac-power-supply { > + ac_power_supply: ac-power { > compatible = "x-powers,axp202-ac-power-supply"; > status = "disabled"; > }; > @@ -69,7 +69,7 @@ > #gpio-cells = <2>; > }; > > - battery_power_supply: battery-power-supply { > + battery_power_supply: battery-power { > compatible = "x-powers,axp209-battery-power-supply"; > status = "disabled"; > }; > @@ -112,7 +112,7 @@ > }; > }; > > - usb_power_supply: usb-power-supply { > + usb_power_supply: usb-power { > compatible = "x-powers,axp202-usb-power-supply"; > status = "disabled"; > }; > diff --git a/arch/arm/dts/sun4i-a10-a1000.dts b/arch/arm/dts/sun4i-a10-a1000.dts > index 6c254ec4c8..20f9ed2448 100644 > --- a/arch/arm/dts/sun4i-a10-a1000.dts > +++ b/arch/arm/dts/sun4i-a10-a1000.dts > @@ -60,15 +60,26 @@ > stdout-path = "serial0:115200n8"; > }; > > + hdmi-connector { > + compatible = "hdmi-connector"; > + type = "a"; > + > + port { > + hdmi_con_in: endpoint { > + remote-endpoint = <&hdmi_out_con>; > + }; > + }; > + }; > + > leds { > compatible = "gpio-leds"; > > - red { > + led-0 { > label = "a1000:red:usr"; > gpios = <&pio 7 10 GPIO_ACTIVE_HIGH>; > }; > > - blue { > + led-1 { > label = "a1000:blue:pwr"; > gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; > default-state = "on"; > @@ -125,7 +136,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > @@ -133,6 +144,20 @@ > status = "okay"; > }; > > +&de { > + status = "okay"; > +}; > + > +&hdmi { > + status = "okay"; > +}; > + > +&hdmi_out { > + hdmi_out_con: endpoint { > + remote-endpoint = <&hdmi_con_in>; > + }; > +}; > + > &i2c0 { > status = "okay"; > > diff --git a/arch/arm/dts/sun4i-a10-ba10-tvbox.dts b/arch/arm/dts/sun4i-a10-ba10-tvbox.dts > index 38a2c41349..816d534ac0 100644 > --- a/arch/arm/dts/sun4i-a10-ba10-tvbox.dts > +++ b/arch/arm/dts/sun4i-a10-ba10-tvbox.dts > @@ -68,7 +68,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > diff --git a/arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts b/arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts > index cf7b392dff..7426298888 100644 > --- a/arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts > +++ b/arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts > @@ -131,20 +131,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > ®_usb0_vbus { > status = "okay"; > }; > @@ -165,10 +151,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-cubieboard.dts b/arch/arm/dts/sun4i-a10-cubieboard.dts > index 197a1f2b75..0645d60642 100644 > --- a/arch/arm/dts/sun4i-a10-cubieboard.dts > +++ b/arch/arm/dts/sun4i-a10-cubieboard.dts > @@ -75,12 +75,12 @@ > pinctrl-names = "default"; > pinctrl-0 = <&led_pins_cubieboard>; > > - blue { > + led-0 { > label = "cubieboard:blue:usr"; > gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; /* LED1 */ > }; > > - green { > + led-1 { > label = "cubieboard:green:usr"; > gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* LED2 */ > linux,default-trigger = "heartbeat"; > @@ -114,7 +114,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > @@ -184,12 +184,6 @@ > function = "gpio_out"; > drive-strength = <20>; > }; > - > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > }; > > ®_ahci_5v { > @@ -254,9 +248,7 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > usb1_vbus-supply = <®_usb1_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts b/arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts > index 896e27a087..63e77c05bf 100644 > --- a/arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts > +++ b/arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts > @@ -62,6 +62,7 @@ > brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>; > default-brightness-level = <8>; > enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */ > + power-supply = <®_vcc3v3>; > }; > > chosen { > @@ -158,20 +159,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > &pwm { > pinctrl-names = "default"; > pinctrl-0 = <&pwm0_pin>; > @@ -223,10 +210,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-hackberry.dts b/arch/arm/dts/sun4i-a10-hackberry.dts > index cc988ccd5c..47dea09225 100644 > --- a/arch/arm/dts/sun4i-a10-hackberry.dts > +++ b/arch/arm/dts/sun4i-a10-hackberry.dts > @@ -80,7 +80,7 @@ > }; > > &emac { > - phy = <&phy0>; > + phy-handle = <&phy0>; > status = "okay"; > }; > > diff --git a/arch/arm/dts/sun4i-a10-hyundai-a7hd.dts b/arch/arm/dts/sun4i-a10-hyundai-a7hd.dts > index f63767cddd..bf2044bac4 100644 > --- a/arch/arm/dts/sun4i-a10-hyundai-a7hd.dts > +++ b/arch/arm/dts/sun4i-a10-hyundai-a7hd.dts > @@ -86,20 +86,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > ®_usb0_vbus { > status = "okay"; > }; > @@ -121,10 +107,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-inet1.dts b/arch/arm/dts/sun4i-a10-inet1.dts > index 26d0c1d6a0..60e432a0ef 100644 > --- a/arch/arm/dts/sun4i-a10-inet1.dts > +++ b/arch/arm/dts/sun4i-a10-inet1.dts > @@ -62,6 +62,7 @@ > brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>; > default-brightness-level = <8>; > enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */ > + power-supply = <®_vcc3v3>; > }; > > chosen { > @@ -164,20 +165,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > &pwm { > pinctrl-names = "default"; > pinctrl-0 = <&pwm0_pin>; > @@ -233,10 +220,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb1_vbus-supply = <®_usb1_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > diff --git a/arch/arm/dts/sun4i-a10-inet97fv2.dts b/arch/arm/dts/sun4i-a10-inet97fv2.dts > index 5d096528e7..76016f2ca2 100644 > --- a/arch/arm/dts/sun4i-a10-inet97fv2.dts > +++ b/arch/arm/dts/sun4i-a10-inet97fv2.dts > @@ -1,7 +1,7 @@ > /* > * Copyright 2014 Open Source Support GmbH > * > - * David Lanzend�rfer <david.lanzendoerfer@o2s.ch> > + * David Lanzendörfer <david.lanzendoerfer@o2s.ch> > * > * 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 > @@ -150,20 +150,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > ®_dcdc2 { > regulator-always-on; > regulator-min-microvolt = <1000000>; > @@ -209,10 +195,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-inet9f-rev03.dts b/arch/arm/dts/sun4i-a10-inet9f-rev03.dts > index 221acd10f6..0a562b2cc5 100644 > --- a/arch/arm/dts/sun4i-a10-inet9f-rev03.dts > +++ b/arch/arm/dts/sun4i-a10-inet9f-rev03.dts > @@ -61,10 +61,6 @@ > > gpio-keys { > compatible = "gpio-keys-polled"; > - pinctrl-names = "default"; > - pinctrl-0 = <&key_pins_inet9f>; > - #address-cells = <1>; > - #size-cells = <0>; > poll-interval = <20>; > > left-joystick-left { > @@ -72,7 +68,7 @@ > linux,code = <ABS_X>; > linux,input-type = <EV_ABS>; > linux,input-value = <0xffffffff>; /* -1 */ > - gpios = <&pio 0 6 GPIO_ACTIVE_LOW>; /* PA6 */ > + gpios = <&pio 0 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA6 */ > }; > > left-joystick-right { > @@ -80,7 +76,7 @@ > linux,code = <ABS_X>; > linux,input-type = <EV_ABS>; > linux,input-value = <1>; > - gpios = <&pio 0 5 GPIO_ACTIVE_LOW>; /* PA5 */ > + gpios = <&pio 0 5 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA5 */ > }; > > left-joystick-up { > @@ -88,7 +84,7 @@ > linux,code = <ABS_Y>; > linux,input-type = <EV_ABS>; > linux,input-value = <0xffffffff>; /* -1 */ > - gpios = <&pio 0 8 GPIO_ACTIVE_LOW>; /* PA8 */ > + gpios = <&pio 0 8 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA8 */ > }; > > left-joystick-down { > @@ -96,7 +92,7 @@ > linux,code = <ABS_Y>; > linux,input-type = <EV_ABS>; > linux,input-value = <1>; > - gpios = <&pio 0 9 GPIO_ACTIVE_LOW>; /* PA9 */ > + gpios = <&pio 0 9 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA9 */ > }; > > right-joystick-left { > @@ -104,7 +100,7 @@ > linux,code = <ABS_Z>; > linux,input-type = <EV_ABS>; > linux,input-value = <0xffffffff>; /* -1 */ > - gpios = <&pio 0 1 GPIO_ACTIVE_LOW>; /* PA1 */ > + gpios = <&pio 0 1 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA1 */ > }; > > right-joystick-right { > @@ -112,7 +108,7 @@ > linux,code = <ABS_Z>; > linux,input-type = <EV_ABS>; > linux,input-value = <1>; > - gpios = <&pio 0 0 GPIO_ACTIVE_LOW>; /* PA0 */ > + gpios = <&pio 0 0 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA0 */ > }; > > right-joystick-up { > @@ -120,7 +116,7 @@ > linux,code = <ABS_RZ>; > linux,input-type = <EV_ABS>; > linux,input-value = <0xffffffff>; /* -1 */ > - gpios = <&pio 0 3 GPIO_ACTIVE_LOW>; /* PA3 */ > + gpios = <&pio 0 3 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA3 */ > }; > > right-joystick-down { > @@ -128,7 +124,7 @@ > linux,code = <ABS_RZ>; > linux,input-type = <EV_ABS>; > linux,input-value = <1>; > - gpios = <&pio 0 4 GPIO_ACTIVE_LOW>; /* PA4 */ > + gpios = <&pio 0 4 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA4 */ > }; > > dpad-left { > @@ -136,7 +132,7 @@ > linux,code = <ABS_HAT0X>; > linux,input-type = <EV_ABS>; > linux,input-value = <0xffffffff>; /* -1 */ > - gpios = <&pio 7 23 GPIO_ACTIVE_LOW>; /* PH23 */ > + gpios = <&pio 7 23 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PH23 */ > }; > > dpad-right { > @@ -144,7 +140,7 @@ > linux,code = <ABS_HAT0X>; > linux,input-type = <EV_ABS>; > linux,input-value = <1>; > - gpios = <&pio 7 24 GPIO_ACTIVE_LOW>; /* PH24 */ > + gpios = <&pio 7 24 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PH24 */ > }; > > dpad-up { > @@ -152,7 +148,7 @@ > linux,code = <ABS_HAT0Y>; > linux,input-type = <EV_ABS>; > linux,input-value = <0xffffffff>; /* -1 */ > - gpios = <&pio 7 25 GPIO_ACTIVE_LOW>; /* PH25 */ > + gpios = <&pio 7 25 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PH25 */ > }; > > dpad-down { > @@ -160,55 +156,55 @@ > linux,code = <ABS_HAT0Y>; > linux,input-type = <EV_ABS>; > linux,input-value = <1>; > - gpios = <&pio 7 26 GPIO_ACTIVE_LOW>; /* PH26 */ > + gpios = <&pio 7 26 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PH26 */ > }; > > x { > label = "Button X"; > linux,code = <BTN_X>; > - gpios = <&pio 0 16 GPIO_ACTIVE_LOW>; /* PA16 */ > + gpios = <&pio 0 16 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA16 */ > }; > > y { > label = "Button Y"; > linux,code = <BTN_Y>; > - gpios = <&pio 0 14 GPIO_ACTIVE_LOW>; /* PA14 */ > + gpios = <&pio 0 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA14 */ > }; > > a { > label = "Button A"; > linux,code = <BTN_A>; > - gpios = <&pio 0 17 GPIO_ACTIVE_LOW>; /* PA17 */ > + gpios = <&pio 0 17 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA17 */ > }; > > b { > label = "Button B"; > linux,code = <BTN_B>; > - gpios = <&pio 0 15 GPIO_ACTIVE_LOW>; /* PA15 */ > + gpios = <&pio 0 15 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA15 */ > }; > > select { > label = "Select Button"; > linux,code = <BTN_SELECT>; > - gpios = <&pio 0 11 GPIO_ACTIVE_LOW>; /* PA11 */ > + gpios = <&pio 0 11 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA11 */ > }; > > start { > label = "Start Button"; > linux,code = <BTN_START>; > - gpios = <&pio 0 12 GPIO_ACTIVE_LOW>; /* PA12 */ > + gpios = <&pio 0 12 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA12 */ > }; > > top-left { > label = "Top Left Button"; > linux,code = <BTN_TL>; > - gpios = <&pio 7 22 GPIO_ACTIVE_LOW>; /* PH22 */ > + gpios = <&pio 7 22 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PH22 */ > }; > > top-right { > label = "Top Right Button"; > linux,code = <BTN_TR>; > - gpios = <&pio 0 13 GPIO_ACTIVE_LOW>; /* PA13 */ > + gpios = <&pio 0 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* PA13 */ > }; > }; > }; > @@ -308,30 +304,6 @@ > status = "okay"; > }; > > -&pio { > - key_pins_inet9f: key-pins { > - pins = "PA0", "PA1", "PA3", "PA4", > - "PA5", "PA6", "PA8", "PA9", > - "PA11", "PA12", "PA13", > - "PA14", "PA15", "PA16", "PA17", > - "PH22", "PH23", "PH24", "PH25", "PH26"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > ®_dcdc2 { > regulator-always-on; > regulator-min-microvolt = <1000000>; > @@ -377,10 +349,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-itead-iteaduino-plus.dts b/arch/arm/dts/sun4i-a10-itead-iteaduino-plus.dts > index 80ecd78247..d4e319d16a 100644 > --- a/arch/arm/dts/sun4i-a10-itead-iteaduino-plus.dts > +++ b/arch/arm/dts/sun4i-a10-itead-iteaduino-plus.dts > @@ -58,7 +58,7 @@ > &emac { > pinctrl-names = "default"; > pinctrl-0 = <&emac_pins>; > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > diff --git a/arch/arm/dts/sun4i-a10-jesurun-q5.dts b/arch/arm/dts/sun4i-a10-jesurun-q5.dts > index 247fa27ef7..1aeb0bd551 100644 > --- a/arch/arm/dts/sun4i-a10-jesurun-q5.dts > +++ b/arch/arm/dts/sun4i-a10-jesurun-q5.dts > @@ -63,7 +63,7 @@ > leds { > compatible = "gpio-leds"; > > - green { > + led { > label = "q5:green:usr"; > gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */ > }; > @@ -94,7 +94,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > diff --git a/arch/arm/dts/sun4i-a10-marsboard.dts b/arch/arm/dts/sun4i-a10-marsboard.dts > index 0dbf695765..81fdb217d3 100644 > --- a/arch/arm/dts/sun4i-a10-marsboard.dts > +++ b/arch/arm/dts/sun4i-a10-marsboard.dts > @@ -62,22 +62,22 @@ > leds { > compatible = "gpio-leds"; > > - red1 { > + led-0 { > label = "marsboard:red1:usr"; > gpios = <&pio 1 5 GPIO_ACTIVE_HIGH>; > }; > > - red2 { > + led-1 { > label = "marsboard:red2:usr"; > gpios = <&pio 1 6 GPIO_ACTIVE_HIGH>; > }; > > - red3 { > + led-2 { > label = "marsboard:red3:usr"; > gpios = <&pio 1 7 GPIO_ACTIVE_HIGH>; > }; > > - red4 { > + led-3 { > label = "marsboard:red4:usr"; > gpios = <&pio 1 8 GPIO_ACTIVE_HIGH>; > }; > @@ -105,7 +105,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > @@ -148,14 +148,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > -}; > - > ®_usb1_vbus { > status = "okay"; > }; > @@ -183,9 +175,7 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > usb1_vbus-supply = <®_usb1_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-olinuxino-lime.dts b/arch/arm/dts/sun4i-a10-olinuxino-lime.dts > index b74a614965..83d283cf66 100644 > --- a/arch/arm/dts/sun4i-a10-olinuxino-lime.dts > +++ b/arch/arm/dts/sun4i-a10-olinuxino-lime.dts > @@ -74,7 +74,7 @@ > pinctrl-names = "default"; > pinctrl-0 = <&led_pins_olinuxinolime>; > > - green { > + led { > label = "a10-olinuxino-lime:green:usr"; > gpios = <&pio 7 2 GPIO_ACTIVE_HIGH>; > default-state = "on"; > @@ -91,12 +91,11 @@ > /* > * The A10-Lime is known to be unstable when running at 1008 MHz > */ > - operating-points = < > - /* kHz uV */ > - 912000 1350000 > - 864000 1300000 > - 624000 1250000 > - >; > + operating-points = > + /* kHz uV */ > + <912000 1350000>, > + <864000 1300000>, > + <624000 1250000>; > }; > > &de { > @@ -112,7 +111,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > @@ -186,18 +185,6 @@ > function = "gpio_out"; > drive-strength = <20>; > }; > - > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > }; > > ®_ahci_5v { > @@ -229,10 +216,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb1_vbus-supply = <®_usb1_vbus>; > usb2_vbus-supply = <®_usb2_vbus>; > diff --git a/arch/arm/dts/sun4i-a10-pcduino.dts b/arch/arm/dts/sun4i-a10-pcduino.dts > index b97a0f2f20..1ac82376ba 100644 > --- a/arch/arm/dts/sun4i-a10-pcduino.dts > +++ b/arch/arm/dts/sun4i-a10-pcduino.dts > @@ -63,12 +63,12 @@ > leds { > compatible = "gpio-leds"; > > - tx { > + led-0 { > label = "pcduino:green:tx"; > gpios = <&pio 7 15 GPIO_ACTIVE_LOW>; > }; > > - rx { > + led-1 { > label = "pcduino:green:rx"; > gpios = <&pio 7 16 GPIO_ACTIVE_LOW>; > }; > @@ -76,8 +76,6 @@ > > gpio-keys { > compatible = "gpio-keys"; > - #address-cells = <1>; > - #size-cells = <0>; > > back { > label = "Key Back"; > @@ -112,7 +110,7 @@ > }; > > &emac { > - phy = <&phy1>; > + phy-handle = <&phy1>; > status = "okay"; > }; > > @@ -156,14 +154,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > -}; > - > #include "axp209.dtsi" > > ®_dcdc2 { > @@ -203,9 +193,7 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > usb1_vbus-supply = <®_vcc5v0>; /* USB1 VBUS is always on */ > usb2_vbus-supply = <®_vcc5v0>; /* USB2 VBUS is always on */ > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts b/arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts > index 84b25be1ac..c325969476 100644 > --- a/arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts > +++ b/arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts > @@ -62,6 +62,7 @@ > brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>; > default-brightness-level = <8>; > enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */ > + power-supply = <®_vcc3v3>; > }; > > chosen { > @@ -146,20 +147,6 @@ > status = "okay"; > }; > > -&pio { > - usb0_id_detect_pin: usb0-id-detect-pin { > - pins = "PH4"; > - function = "gpio_in"; > - bias-pull-up; > - }; > - > - usb0_vbus_detect_pin: usb0-vbus-detect-pin { > - pins = "PH5"; > - function = "gpio_in"; > - bias-pull-down; > - }; > -}; > - > &pwm { > pinctrl-names = "default"; > pinctrl-0 = <&pwm0_pin>; > @@ -211,10 +198,8 @@ > }; > > &usbphy { > - pinctrl-names = "default"; > - pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>; > - usb0_id_det-gpio = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > - usb0_vbus_det-gpio = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_id_det-gpios = <&pio 7 4 (GPIO_ACTIVE_HIGH | GPIO_PULL_UP)>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; /* PH5 */ > usb0_vbus-supply = <®_usb0_vbus>; > usb1_vbus-supply = <®_usb1_vbus>; > status = "okay"; > diff --git a/arch/arm/dts/sun4i-a10-topwise-a721.dts b/arch/arm/dts/sun4i-a10-topwise-a721.dts > new file mode 100644 > index 0000000000..3628f12d25 > --- /dev/null > +++ b/arch/arm/dts/sun4i-a10-topwise-a721.dts > @@ -0,0 +1,242 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright 2020 Pascal Roeleven <dev@pascalroeleven.nl> > + */ > + > +/dts-v1/; > +#include "sun4i-a10.dtsi" > +#include "sunxi-common-regulators.dtsi" > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/input/input.h> > +#include <dt-bindings/interrupt-controller/irq.h> > +#include <dt-bindings/pwm/pwm.h> > + > +/ { > + model = "Topwise A721"; > + compatible = "topwise,a721", "allwinner,sun4i-a10"; > + > + aliases { > + serial0 = &uart0; > + }; > + > + backlight: backlight { > + compatible = "pwm-backlight"; > + pwms = <&pwm 0 100000 PWM_POLARITY_INVERTED>; > + power-supply = <®_vbat>; > + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */ > + brightness-levels = <0 30 40 50 60 70 80 90 100>; > + default-brightness-level = <8>; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + panel { > + compatible = "starry,kr070pe2t"; > + backlight = <&backlight>; > + power-supply = <®_lcd_power>; > + > + port { > + panel_input: endpoint { > + remote-endpoint = <&tcon0_out_panel>; > + }; > + }; > + }; > + > + reg_lcd_power: reg-lcd-power { > + compatible = "regulator-fixed"; > + regulator-name = "reg-lcd-power"; > + gpio = <&pio 7 8 GPIO_ACTIVE_HIGH>; /* PH8 */ > + enable-active-high; > + }; > + > + reg_vbat: reg-vbat { > + compatible = "regulator-fixed"; > + regulator-name = "vbat"; > + regulator-min-microvolt = <3700000>; > + regulator-max-microvolt = <3700000>; > + }; > + > +}; > + > +&codec { > + status = "okay"; > +}; > + > +&cpu0 { > + cpu-supply = <®_dcdc2>; > +}; > + > +&de { > + status = "okay"; > +}; > + > +&ehci0 { > + status = "okay"; > +}; > + > +&ehci1 { > + status = "okay"; > +}; > + > +&i2c0 { > + status = "okay"; > + > + axp209: pmic@34 { > + reg = <0x34>; > + interrupts = <0>; > + }; > +}; > + > +#include "axp209.dtsi" > + > +&ac_power_supply { > + status = "okay"; > +}; > + > +&battery_power_supply { > + status = "okay"; > +}; > + > +&i2c1 { > + status = "okay"; > + > + accelerometer@4c { > + compatible = "fsl,mma7660"; > + reg = <0x4c>; > + }; > +}; > + > +&i2c2 { > + status = "okay"; > + > + touchscreen@38 { > + compatible = "edt,edt-ft5406"; > + reg = <0x38>; > + interrupt-parent = <&pio>; > + interrupts = <7 21 IRQ_TYPE_EDGE_FALLING>; > + touchscreen-size-x = <800>; > + touchscreen-size-y = <480>; > + vcc-supply = <®_vcc3v3>; > + }; > +}; > + > +&lradc { > + vref-supply = <®_ldo2>; > + status = "okay"; > + > + button-571 { > + label = "Volume Up"; > + linux,code = <KEY_VOLUMEUP>; > + channel = <0>; > + voltage = <571428>; > + }; > + > + button-761 { > + label = "Volume Down"; > + linux,code = <KEY_VOLUMEDOWN>; > + channel = <0>; > + voltage = <761904>; > + }; > +}; > + > +&mmc0 { > + vmmc-supply = <®_vcc3v3>; > + bus-width = <4>; > + cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH01 */ > + status = "okay"; > +}; > + > +&ohci0 { > + status = "okay"; > +}; > + > +&ohci1 { > + status = "okay"; > +}; > + > +&otg_sram { > + status = "okay"; > +}; > + > +&pio { > + vcc-pb-supply = <®_vcc3v3>; > + vcc-pf-supply = <®_vcc3v3>; > + vcc-ph-supply = <®_vcc3v3>; > +}; > + > +&pwm { > + pinctrl-names = "default"; > + pinctrl-0 = <&pwm0_pin>; > + status = "okay"; > +}; > + > +®_dcdc2 { > + regulator-always-on; > + regulator-min-microvolt = <1000000>; > + regulator-max-microvolt = <1400000>; > + regulator-name = "vdd-cpu"; > +}; > + > +®_dcdc3 { > + regulator-always-on; > + regulator-min-microvolt = <1250000>; > + regulator-max-microvolt = <1250000>; > + regulator-name = "vdd-int-dll"; > +}; > + > +®_ldo1 { > + regulator-name = "vdd-rtc"; > +}; > + > +®_ldo2 { > + regulator-always-on; > + regulator-min-microvolt = <3000000>; > + regulator-max-microvolt = <3000000>; > + regulator-name = "avcc"; > +}; > + > +®_usb0_vbus { > + status = "okay"; > +}; > + > +®_usb1_vbus { > + status = "okay"; > +}; > + > +®_usb2_vbus { > + status = "okay"; > +}; > + > +&tcon0_out { > + tcon0_out_panel: endpoint@0 { > + reg = <0>; > + remote-endpoint = <&panel_input>; > + }; > +}; > + > +&uart0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&uart0_pb_pins>; > + status = "okay"; > +}; > + > +&usb_otg { > + dr_mode = "otg"; > + status = "okay"; > +}; > + > +&usb_power_supply { > + status = "okay"; > +}; > + > +&usbphy { > + usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */ > + usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */ > + usb0_vbus-supply = <®_usb0_vbus>; > + usb1_vbus-supply = <®_usb1_vbus>; > + usb2_vbus-supply = <®_usb2_vbus>; > + status = "okay"; > +}; > diff --git a/arch/arm/dts/sun4i-a10.dtsi b/arch/arm/dts/sun4i-a10.dtsi > index 3a1c6b45c9..51a6464aab 100644 > --- a/arch/arm/dts/sun4i-a10.dtsi > +++ b/arch/arm/dts/sun4i-a10.dtsi > @@ -115,13 +115,12 @@ > reg = <0x0>; > clocks = <&ccu CLK_CPU>; > clock-latency = <244144>; /* 8 32k periods */ > - operating-points = < > + operating-points = > /* kHz uV */ > - 1008000 1400000 > - 912000 1350000 > - 864000 1300000 > - 624000 1250000 > - >; > + <1008000 1400000>, > + <912000 1350000>, > + <864000 1300000>, > + <624000 1250000>; > #cooling-cells = <2>; > }; > }; > @@ -143,7 +142,7 @@ > trips { > cpu_alert0: cpu-alert0 { > /* milliCelsius */ > - temperature = <850000>; > + temperature = <85000>; > hysteresis = <2000>; > type = "passive"; > }; > @@ -184,14 +183,34 @@ > status = "disabled"; > }; > > + pmu { > + compatible = "arm,cortex-a8-pmu"; > + interrupts = <3>; > + }; > + > + reserved-memory { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + /* Address must be kept in the lower 256 MiBs of DRAM for VE. */ > + default-pool { > + compatible = "shared-dma-pool"; > + size = <0x6000000>; > + alloc-ranges = <0x40000000 0x10000000>; > + reusable; > + linux,cma-default; > + }; > + }; > + > soc { > compatible = "simple-bus"; > #address-cells = <1>; > #size-cells = <1>; > ranges; > > - sram-controller@1c00000 { > - compatible = "allwinner,sun4i-a10-sram-controller"; > + system-control@1c00000 { > + compatible = "allwinner,sun4i-a10-system-control"; > reg = <0x01c00000 0x30>; > #address-cells = <1>; > #size-cells = <1>; > @@ -224,6 +243,19 @@ > status = "disabled"; > }; > }; > + > + sram_c: sram@1d00000 { > + compatible = "mmio-sram"; > + reg = <0x01d00000 0xd0000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0x01d00000 0xd0000>; > + > + ve_sram: sram-section@0 { > + compatible = "allwinner,sun4i-a10-sram-c1"; > + reg = <0x000000 0x80000>; > + }; > + }; > }; > > dma: dma-controller@1c02000 { > @@ -234,7 +266,7 @@ > #dma-cells = <2>; > }; > > - nfc: nand@1c03000 { > + nfc: nand-controller@1c03000 { > compatible = "allwinner,sun4i-a10-nand"; > reg = <0x01c03000 0x1000>; > interrupts = <37>; > @@ -309,6 +341,7 @@ > "tcon-ch0", > "tcon-ch1"; > clock-output-names = "tcon0-pixel-clock"; > + #clock-cells = <0>; > dmas = <&dma SUN4I_DMA_DEDICATED 14>; > > ports { > @@ -358,6 +391,7 @@ > "tcon-ch0", > "tcon-ch1"; > clock-output-names = "tcon1-pixel-clock"; > + #clock-cells = <0>; > dmas = <&dma SUN4I_DMA_DEDICATED 15>; > > ports { > @@ -394,6 +428,17 @@ > }; > }; > > + video-codec@1c0e000 { > + compatible = "allwinner,sun4i-a10-video-engine"; > + reg = <0x01c0e000 0x1000>; > + clocks = <&ccu CLK_AHB_VE>, <&ccu CLK_VE>, > + <&ccu CLK_DRAM_VE>; > + clock-names = "ahb", "mod", "ram"; > + resets = <&ccu RST_VE>; > + interrupts = <53>; > + allwinner,sram = <&ve_sram 1>; > + }; > + > mmc0: mmc@1c0f000 { > compatible = "allwinner,sun4i-a10-mmc"; > reg = <0x01c0f000 0x1000>; > @@ -450,13 +495,14 @@ > phy-names = "usb"; > extcon = <&usbphy 0>; > allwinner,sram = <&otg_sram 1>; > + dr_mode = "otg"; > status = "disabled"; > }; > > usbphy: phy@1c13400 { > #phy-cells = <1>; > compatible = "allwinner,sun4i-a10-usb-phy"; > - reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>; > + reg = <0x01c13400 0x10>, <0x01c14800 0x4>, <0x01c1c800 0x4>; > reg-names = "phy_ctrl", "pmu1", "pmu2"; > clocks = <&ccu CLK_USB_PHY>; > clock-names = "usb_phy"; > @@ -530,8 +576,6 @@ > }; > > hdmi_out: port@1 { > - #address-cells = <1>; > - #size-cells = <0>; > reg = <1>; > }; > }; > @@ -579,6 +623,16 @@ > status = "disabled"; > }; > > + csi1: csi@1c1d000 { > + compatible = "allwinner,sun4i-a10-csi1"; > + reg = <0x01c1d000 0x1000>; > + interrupts = <43>; > + clocks = <&ccu CLK_AHB_CSI1>, <&ccu CLK_DRAM_CSI1>; > + clock-names = "bus", "ram"; > + resets = <&ccu RST_CSI1>; > + status = "disabled"; > + }; > + > spi3: spi@1c1f000 { > compatible = "allwinner,sun4i-a10-spi"; > reg = <0x01c1f000 0x1000>; > @@ -625,6 +679,31 @@ > function = "can"; > }; > > + /omit-if-no-ref/ > + csi1_8bits_pg_pins: csi1-8bits-pg-pins { > + pins = "PG0", "PG2", "PG3", "PG4", "PG5", > + "PG6", "PG7", "PG8", "PG9", "PG10", > + "PG11"; > + function = "csi1"; > + }; > + > + /omit-if-no-ref/ > + csi1_24bits_ph_pins: csi1-24bits-ph-pins { > + pins = "PH0", "PH1", "PH2", "PH3", "PH4", > + "PH5", "PH6", "PH7", "PH8", "PH9", > + "PH10", "PH11", "PH12", "PH13", "PH14", > + "PH15", "PH16", "PH17", "PH18", "PH19", > + "PH20", "PH21", "PH22", "PH23", "PH24", > + "PH25", "PH26", "PH27"; > + function = "csi1"; > + }; > + > + /omit-if-no-ref/ > + csi1_clk_pg_pin: csi1-clk-pg-pin { > + pins = "PG1"; > + function = "csi1"; > + }; > + > emac_pins: emac0-pins { > pins = "PA0", "PA1", "PA2", > "PA3", "PA4", "PA5", "PA6", > @@ -762,13 +841,20 @@ > timer@1c20c00 { > compatible = "allwinner,sun4i-a10-timer"; > reg = <0x01c20c00 0x90>; > - interrupts = <22>; > + interrupts = <22>, > + <23>, > + <24>, > + <25>, > + <67>, > + <68>; > clocks = <&osc24M>; > }; > > wdt: watchdog@1c20c90 { > compatible = "allwinner,sun4i-a10-wdt"; > reg = <0x01c20c90 0x10>; > + interrupts = <24>; > + clocks = <&osc24M>; > }; > > rtc: rtc@1c20d00 { > @@ -1001,6 +1087,27 @@ > status = "disabled"; > }; > > + mali: gpu@1c40000 { > + compatible = "allwinner,sun4i-a10-mali", "arm,mali-400"; > + reg = <0x01c40000 0x10000>; > + interrupts = <69>, > + <70>, > + <71>, > + <72>, > + <73>; > + interrupt-names = "gp", > + "gpmmu", > + "pp0", > + "ppmmu0", > + "pmu"; > + clocks = <&ccu CLK_AHB_GPU>, <&ccu CLK_GPU>; > + clock-names = "bus", "core"; > + resets = <&ccu RST_GPU>; > + > + assigned-clocks = <&ccu CLK_GPU>; > + assigned-clock-rates = <384000000>; > + }; > + > fe0: display-frontend@1e00000 { > compatible = "allwinner,sun4i-a10-display-frontend"; > reg = <0x01e00000 0x20000>;
On Wed, 27 Apr 2022 15:31:19 -0500 Samuel Holland <samuel@sholland.org> wrote: > This series brings all of our devicetrees up to date with Linux. > > Older SoCs (before A83T) have not been synchronized in over 3 years. > And I don't have any of this hardware to test. But there are not major > changes to those devicetrees either. > > The big motivation for including older SoCs in this update is converting > the USB PHY driver to get its VBUS detection GPIO/regulator from the > devicetree instead of from a pin name in Kconfig. Many older boards had > those properties added or fixed since the last devicetree sync. This PHY > driver change is necessary to complete the DM_GPIO migration. > > A couple of breaking changes were made to several SoCs' devicetrees in > Linux relating to the "r_intc" interrupt controller. New kernels support > old devicetrees, but not the other way around. So to be most compatible > and avoid regressions, those changes are skipped here. Applied the whole series to sunxi/master, including the Mele M5 fix. Thanks! Andre > > > Samuel Holland (12): > dt-bindings: sunxi: Update clock/reset binding headers > ARM: dts: sunxi: Remove unused devicetree headers > ARM: dts: sun4i: Sync from Linux v5.18-rc1 > ARM: dts: sun7i: Sync from Linux v5.18-rc1 > ARM: dts: sunxi: A13/A31/A23/A33: Sync from Linux v5.18-rc1 > ARM: dts: sun9i: Sync from Linux v5.18-rc1 > ARM: dts: sun8i: A83T: Sync from Linux v5.18-rc1 > ARM: dts: sunxi: H2+/H3/H5: Sync from Linux v5.18-rc1 > ARM: dts: sun8i: V3/V3s/S3: Sync from Linux v5.18-rc1 > ARM: dts: sun8i: R40/T3: Sync from Linux v5.18-rc1 > ARM: dts: sun50i: A64: Sync from Linux v5.18-rc1 > ARM: dts: sun50i: H6: Sync from Linux v5.18-rc1 > > arch/arm/dts/Makefile | 25 +- > arch/arm/dts/axp209.dtsi | 6 +- > arch/arm/dts/axp22x.dtsi | 11 +- > arch/arm/dts/axp803.dtsi | 10 +- > arch/arm/dts/axp81x.dtsi | 15 +- > arch/arm/dts/sun4i-a10-a1000.dts | 31 +- > arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 2 +- > arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts | 20 +- > arch/arm/dts/sun4i-a10-cubieboard.dts | 16 +- > arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 21 +- > arch/arm/dts/sun4i-a10-hackberry.dts | 2 +- > arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 20 +- > arch/arm/dts/sun4i-a10-inet1.dts | 21 +- > arch/arm/dts/sun4i-a10-inet97fv2.dts | 22 +- > arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 74 ++-- > .../dts/sun4i-a10-itead-iteaduino-plus.dts | 2 +- > arch/arm/dts/sun4i-a10-jesurun-q5.dts | 4 +- > arch/arm/dts/sun4i-a10-marsboard.dts | 22 +- > arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 33 +- > arch/arm/dts/sun4i-a10-pcduino.dts | 20 +- > arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 21 +- > arch/arm/dts/sun4i-a10-topwise-a721.dts | 242 +++++++++++++ > arch/arm/dts/sun4i-a10.dtsi | 135 ++++++- > arch/arm/dts/sun50i-a64-cpu-opp.dtsi | 2 +- > arch/arm/dts/sun50i-a64-orangepi-win.dts | 2 +- > arch/arm/dts/sun50i-a64-pinebook.dts | 1 + > arch/arm/dts/sun50i-a64-pinephone.dtsi | 27 ++ > arch/arm/dts/sun50i-a64-pinetab.dts | 29 +- > arch/arm/dts/sun50i-a64-teres-i.dts | 4 +- > arch/arm/dts/sun50i-a64.dtsi | 93 +++-- > arch/arm/dts/sun50i-h5-cpu-opp.dtsi | 2 +- > arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 9 +- > arch/arm/dts/sun50i-h5.dtsi | 6 +- > arch/arm/dts/sun50i-h6-beelink-gs1.dts | 38 +- > arch/arm/dts/sun50i-h6-cpu-opp.dtsi | 2 +- > arch/arm/dts/sun50i-h6-orangepi-3.dts | 14 +- > arch/arm/dts/sun50i-h6-orangepi.dtsi | 22 +- > arch/arm/dts/sun50i-h6-pine-h64-model-b.dts | 51 +++ > arch/arm/dts/sun50i-h6-tanix-tx6-mini.dts | 15 + > arch/arm/dts/sun50i-h6-tanix-tx6.dts | 115 +----- > arch/arm/dts/sun50i-h6-tanix.dtsi | 189 ++++++++++ > arch/arm/dts/sun50i-h6.dtsi | 26 +- > arch/arm/dts/sun5i-a10s-auxtek-t003.dts | 16 +- > arch/arm/dts/sun5i-a10s-auxtek-t004.dts | 35 +- > arch/arm/dts/sun5i-a10s-mk802.dts | 31 +- > arch/arm/dts/sun5i-a10s-olinuxino-micro.dts | 68 +--- > arch/arm/dts/sun5i-a10s-r7-tv-dongle.dts | 22 +- > arch/arm/dts/sun5i-a10s-wobo-i5.dts | 34 +- > arch/arm/dts/sun5i-a10s.dtsi | 30 +- > arch/arm/dts/sun5i-a13-ampe-a76.dts | 2 +- > .../dts/sun5i-a13-empire-electronix-d709.dts | 41 +-- > arch/arm/dts/sun5i-a13-hsg-h702.dts | 37 +- > arch/arm/dts/sun5i-a13-inet-86vs.dts | 2 +- > ...common.dtsi => sun5i-a13-licheepi-one.dts} | 146 +++++--- > arch/arm/dts/sun5i-a13-olinuxino-micro.dts | 50 +-- > arch/arm/dts/sun5i-a13-olinuxino.dts | 56 +-- > .../dts/sun5i-a13-pocketbook-touch-lux-3.dts | 258 ++++++++++++++ > arch/arm/dts/sun5i-a13-q8-tablet.dts | 18 +- > arch/arm/dts/sun5i-a13-utoo-p66.dts | 26 +- > arch/arm/dts/sun5i-a13.dtsi | 23 +- > arch/arm/dts/sun5i-gr8-chip-pro.dts | 38 +- > arch/arm/dts/sun5i-gr8-evb.dts | 333 ++++++++++++++++++ > arch/arm/dts/sun5i-gr8.dtsi | 12 +- > arch/arm/dts/sun5i-r8-chip.dts | 52 +-- > .../dts/sun5i-reference-design-tablet.dtsi | 57 +-- > arch/arm/dts/sun5i.dtsi | 209 +++++++---- > arch/arm/dts/sun6i-a31-app4-evb1.dts | 10 +- > arch/arm/dts/sun6i-a31-colombus.dts | 57 +-- > arch/arm/dts/sun6i-a31-hummingbird.dts | 75 +--- > arch/arm/dts/sun6i-a31-i7.dts | 47 +-- > arch/arm/dts/sun6i-a31-m9.dts | 46 +-- > arch/arm/dts/sun6i-a31-mele-a1000g-quad.dts | 46 +-- > arch/arm/dts/sun6i-a31-mixtile-loftq.dts | 6 +- > arch/arm/dts/sun6i-a31.dtsi | 218 +++++++----- > arch/arm/dts/sun6i-a31s-colorfly-e708-q1.dts | 2 +- > arch/arm/dts/sun6i-a31s-cs908.dts | 17 +- > arch/arm/dts/sun6i-a31s-inet-q972.dts | 8 +- > arch/arm/dts/sun6i-a31s-primo81.dts | 32 +- > arch/arm/dts/sun6i-a31s-sina31s-core.dtsi | 4 +- > arch/arm/dts/sun6i-a31s-sina31s.dts | 39 +- > arch/arm/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 144 +++++--- > .../sun6i-a31s-yones-toptech-bs1078-v2.dts | 22 +- > .../dts/sun6i-reference-design-tablet.dtsi | 22 +- > arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 16 +- > arch/arm/dts/sun7i-a20-bananapi.dts | 41 +-- > arch/arm/dts/sun7i-a20-bananapro.dts | 16 +- > arch/arm/dts/sun7i-a20-cubieboard2.dts | 28 +- > arch/arm/dts/sun7i-a20-cubietruck.dts | 20 +- > arch/arm/dts/sun7i-a20-haoyu-marsboard.dts | 182 ++++++++++ > arch/arm/dts/sun7i-a20-hummingbird.dts | 21 +- > arch/arm/dts/sun7i-a20-i12-tvbox.dts | 16 +- > arch/arm/dts/sun7i-a20-icnova-swac.dts | 15 +- > arch/arm/dts/sun7i-a20-itead-ibox.dts | 8 +- > arch/arm/dts/sun7i-a20-lamobo-r1.dts | 16 +- > .../dts/sun7i-a20-linutronix-testbox-v2.dts | 47 +++ > arch/arm/dts/sun7i-a20-m3.dts | 14 +- > arch/arm/dts/sun7i-a20-olimex-som-evb.dts | 14 +- > arch/arm/dts/sun7i-a20-olimex-som204-evb.dts | 30 +- > .../arm/dts/sun7i-a20-olinuxino-lime-emmc.dts | 32 ++ > arch/arm/dts/sun7i-a20-olinuxino-lime.dts | 32 +- > arch/arm/dts/sun7i-a20-olinuxino-lime2.dts | 46 +-- > arch/arm/dts/sun7i-a20-olinuxino-micro.dts | 32 +- > arch/arm/dts/sun7i-a20-orangepi-mini.dts | 28 +- > arch/arm/dts/sun7i-a20-orangepi.dts | 26 +- > arch/arm/dts/sun7i-a20-pcduino3-nano.dts | 32 +- > arch/arm/dts/sun7i-a20-pcduino3.dts | 28 +- > arch/arm/dts/sun7i-a20-wexler-tab7200.dts | 13 +- > arch/arm/dts/sun7i-a20-wits-pro-a20-dkt.dts | 24 +- > arch/arm/dts/sun7i-a20.dtsi | 254 +++++++++++-- > arch/arm/dts/sun8i-a23-a33.dtsi | 308 ++++++++++++---- > arch/arm/dts/sun8i-a23-evb.dts | 20 +- > arch/arm/dts/sun8i-a23-gt90h-v4.dts | 2 +- > ...ommon.dtsi => sun8i-a23-ippo-q8h-v1.2.dts} | 54 ++- > arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts | 73 ++++ > .../dts/sun8i-a23-polaroid-mid2407pxe03.dts | 15 +- > .../dts/sun8i-a23-polaroid-mid2809pxe04.dts | 15 +- > arch/arm/dts/sun8i-a23-q8-tablet.dts | 10 + > arch/arm/dts/sun8i-a23.dtsi | 26 +- > ...c-edition.dts => sun8i-a33-et-q8-v1.6.dts} | 32 +- > arch/arm/dts/sun8i-a33-ga10h-v1.1.dts | 4 +- > arch/arm/dts/sun8i-a33-inet-d978-rev2.dts | 14 +- > arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts | 57 +++ > arch/arm/dts/sun8i-a33-olinuxino.dts | 12 +- > arch/arm/dts/sun8i-a33-q8-tablet.dts | 7 + > arch/arm/dts/sun8i-a33-sinlinx-sina33.dts | 34 +- > arch/arm/dts/sun8i-a33.dtsi | 270 +++++--------- > .../dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 12 + > arch/arm/dts/sun8i-a83t-bananapi-m3.dts | 55 ++- > arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 77 +++- > arch/arm/dts/sun8i-a83t-tbs-a711.dts | 101 +++++- > arch/arm/dts/sun8i-a83t.dtsi | 311 ++++++++++++++-- > .../dts/sun8i-h2-plus-bananapi-m2-zero.dts | 28 +- > arch/arm/dts/sun8i-h3-beelink-x2.dts | 27 +- > arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 28 ++ > arch/arm/dts/sun8i-h3-nanopi-r1.dts | 169 +++++++++ > arch/arm/dts/sun8i-h3-nanopi.dtsi | 1 + > arch/arm/dts/sun8i-h3-orangepi-2.dts | 3 +- > arch/arm/dts/sun8i-h3-orangepi-pc.dts | 3 +- > arch/arm/dts/sun8i-h3.dtsi | 10 +- > arch/arm/dts/sun8i-q8-common.dtsi | 31 +- > arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 55 ++- > .../dts/sun8i-r16-nintendo-nes-classic.dts | 54 +++ > .../sun8i-r16-nintendo-super-nes-classic.dts | 11 + > arch/arm/dts/sun8i-r16-parrot.dts | 62 +--- > arch/arm/dts/sun8i-r40-feta40i.dtsi | 106 ++++++ > arch/arm/dts/sun8i-r40-oka40i-c.dts | 203 +++++++++++ > arch/arm/dts/sun8i-r40.dtsi | 118 ++++++- > .../dts/sun8i-reference-design-tablet.dtsi | 33 +- > arch/arm/dts/sun8i-s3-elimo-impetus.dtsi | 44 +++ > arch/arm/dts/sun8i-s3-elimo-initium.dts | 29 ++ > arch/arm/dts/sun8i-s3-pinecube.dts | 13 +- > arch/arm/dts/sun8i-t3-cqa3t-bv3.dts | 226 ++++++++++++ > arch/arm/dts/sun8i-v3-sl631-imx179.dts | 12 + > arch/arm/dts/sun8i-v3-sl631.dtsi | 138 ++++++++ > arch/arm/dts/sun8i-v3.dtsi | 36 ++ > arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts | 17 +- > arch/arm/dts/sun8i-v3s.dtsi | 93 ++++- > arch/arm/dts/sun9i-a80-cubieboard4.dts | 67 +++- > arch/arm/dts/sun9i-a80-optimus.dts | 50 ++- > arch/arm/dts/sun9i-a80.dtsi | 195 ++++++---- > arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 18 +- > arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 4 +- > arch/arm/dts/sunxi-common-regulators.dtsi | 39 -- > arch/arm/dts/sunxi-h3-h5.dtsi | 42 ++- > arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 13 + > arch/arm/dts/sunxi-libretech-all-h3-it.dtsi | 2 +- > .../dts/sunxi-reference-design-tablet.dtsi | 11 +- > arch/arm/mach-sunxi/Kconfig | 2 +- > .../Nintendo_NES_Classic_Edition_defconfig | 2 +- > include/dt-bindings/clock/sun50i-a64-ccu.h | 2 +- > include/dt-bindings/clock/sun5i-ccu.h | 13 +- > include/dt-bindings/clock/sun6i-a31-ccu.h | 2 + > include/dt-bindings/clock/sun8i-a23-a33-ccu.h | 2 + > include/dt-bindings/clock/sun8i-h3-ccu.h | 2 +- > include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 + > include/dt-bindings/reset/sun5i-ccu.h | 11 +- > include/dt-bindings/reset/sun8i-v3s-ccu.h | 3 + > 177 files changed, 5704 insertions(+), 2683 deletions(-) > create mode 100644 arch/arm/dts/sun4i-a10-topwise-a721.dts > create mode 100644 arch/arm/dts/sun50i-h6-pine-h64-model-b.dts > create mode 100644 arch/arm/dts/sun50i-h6-tanix-tx6-mini.dts > create mode 100644 arch/arm/dts/sun50i-h6-tanix.dtsi > rename arch/arm/dts/{sun5i-q8-common.dtsi => sun5i-a13-licheepi-one.dts} (62%) > create mode 100644 arch/arm/dts/sun5i-a13-pocketbook-touch-lux-3.dts > create mode 100644 arch/arm/dts/sun5i-gr8-evb.dts > create mode 100644 arch/arm/dts/sun7i-a20-haoyu-marsboard.dts > create mode 100644 arch/arm/dts/sun7i-a20-linutronix-testbox-v2.dts > create mode 100644 arch/arm/dts/sun7i-a20-olinuxino-lime-emmc.dts > rename arch/arm/dts/{sunxi-q8-common.dtsi => sun8i-a23-ippo-q8h-v1.2.dts} (75%) > create mode 100644 arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts > rename arch/arm/dts/{sun8i-r16-nintendo-nes-classic-edition.dts => sun8i-a33-et-q8-v1.6.dts} (81%) > create mode 100644 arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts > create mode 100644 arch/arm/dts/sun8i-h3-nanopi-r1.dts > create mode 100644 arch/arm/dts/sun8i-r16-nintendo-nes-classic.dts > create mode 100644 arch/arm/dts/sun8i-r16-nintendo-super-nes-classic.dts > create mode 100644 arch/arm/dts/sun8i-r40-feta40i.dtsi > create mode 100644 arch/arm/dts/sun8i-r40-oka40i-c.dts > create mode 100644 arch/arm/dts/sun8i-s3-elimo-impetus.dtsi > create mode 100644 arch/arm/dts/sun8i-s3-elimo-initium.dts > create mode 100644 arch/arm/dts/sun8i-t3-cqa3t-bv3.dts > create mode 100644 arch/arm/dts/sun8i-v3-sl631-imx179.dts > create mode 100644 arch/arm/dts/sun8i-v3-sl631.dtsi >
This series brings all of our devicetrees up to date with Linux. Older SoCs (before A83T) have not been synchronized in over 3 years. And I don't have any of this hardware to test. But there are not major changes to those devicetrees either. The big motivation for including older SoCs in this update is converting the USB PHY driver to get its VBUS detection GPIO/regulator from the devicetree instead of from a pin name in Kconfig. Many older boards had those properties added or fixed since the last devicetree sync. This PHY driver change is necessary to complete the DM_GPIO migration. A couple of breaking changes were made to several SoCs' devicetrees in Linux relating to the "r_intc" interrupt controller. New kernels support old devicetrees, but not the other way around. So to be most compatible and avoid regressions, those changes are skipped here. Samuel Holland (12): dt-bindings: sunxi: Update clock/reset binding headers ARM: dts: sunxi: Remove unused devicetree headers ARM: dts: sun4i: Sync from Linux v5.18-rc1 ARM: dts: sun7i: Sync from Linux v5.18-rc1 ARM: dts: sunxi: A13/A31/A23/A33: Sync from Linux v5.18-rc1 ARM: dts: sun9i: Sync from Linux v5.18-rc1 ARM: dts: sun8i: A83T: Sync from Linux v5.18-rc1 ARM: dts: sunxi: H2+/H3/H5: Sync from Linux v5.18-rc1 ARM: dts: sun8i: V3/V3s/S3: Sync from Linux v5.18-rc1 ARM: dts: sun8i: R40/T3: Sync from Linux v5.18-rc1 ARM: dts: sun50i: A64: Sync from Linux v5.18-rc1 ARM: dts: sun50i: H6: Sync from Linux v5.18-rc1 arch/arm/dts/Makefile | 25 +- arch/arm/dts/axp209.dtsi | 6 +- arch/arm/dts/axp22x.dtsi | 11 +- arch/arm/dts/axp803.dtsi | 10 +- arch/arm/dts/axp81x.dtsi | 15 +- arch/arm/dts/sun4i-a10-a1000.dts | 31 +- arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 2 +- arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts | 20 +- arch/arm/dts/sun4i-a10-cubieboard.dts | 16 +- arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 21 +- arch/arm/dts/sun4i-a10-hackberry.dts | 2 +- arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 20 +- arch/arm/dts/sun4i-a10-inet1.dts | 21 +- arch/arm/dts/sun4i-a10-inet97fv2.dts | 22 +- arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 74 ++-- .../dts/sun4i-a10-itead-iteaduino-plus.dts | 2 +- arch/arm/dts/sun4i-a10-jesurun-q5.dts | 4 +- arch/arm/dts/sun4i-a10-marsboard.dts | 22 +- arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 33 +- arch/arm/dts/sun4i-a10-pcduino.dts | 20 +- arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 21 +- arch/arm/dts/sun4i-a10-topwise-a721.dts | 242 +++++++++++++ arch/arm/dts/sun4i-a10.dtsi | 135 ++++++- arch/arm/dts/sun50i-a64-cpu-opp.dtsi | 2 +- arch/arm/dts/sun50i-a64-orangepi-win.dts | 2 +- arch/arm/dts/sun50i-a64-pinebook.dts | 1 + arch/arm/dts/sun50i-a64-pinephone.dtsi | 27 ++ arch/arm/dts/sun50i-a64-pinetab.dts | 29 +- arch/arm/dts/sun50i-a64-teres-i.dts | 4 +- arch/arm/dts/sun50i-a64.dtsi | 93 +++-- arch/arm/dts/sun50i-h5-cpu-opp.dtsi | 2 +- arch/arm/dts/sun50i-h5-nanopi-r1s-h5.dts | 9 +- arch/arm/dts/sun50i-h5.dtsi | 6 +- arch/arm/dts/sun50i-h6-beelink-gs1.dts | 38 +- arch/arm/dts/sun50i-h6-cpu-opp.dtsi | 2 +- arch/arm/dts/sun50i-h6-orangepi-3.dts | 14 +- arch/arm/dts/sun50i-h6-orangepi.dtsi | 22 +- arch/arm/dts/sun50i-h6-pine-h64-model-b.dts | 51 +++ arch/arm/dts/sun50i-h6-tanix-tx6-mini.dts | 15 + arch/arm/dts/sun50i-h6-tanix-tx6.dts | 115 +----- arch/arm/dts/sun50i-h6-tanix.dtsi | 189 ++++++++++ arch/arm/dts/sun50i-h6.dtsi | 26 +- arch/arm/dts/sun5i-a10s-auxtek-t003.dts | 16 +- arch/arm/dts/sun5i-a10s-auxtek-t004.dts | 35 +- arch/arm/dts/sun5i-a10s-mk802.dts | 31 +- arch/arm/dts/sun5i-a10s-olinuxino-micro.dts | 68 +--- arch/arm/dts/sun5i-a10s-r7-tv-dongle.dts | 22 +- arch/arm/dts/sun5i-a10s-wobo-i5.dts | 34 +- arch/arm/dts/sun5i-a10s.dtsi | 30 +- arch/arm/dts/sun5i-a13-ampe-a76.dts | 2 +- .../dts/sun5i-a13-empire-electronix-d709.dts | 41 +-- arch/arm/dts/sun5i-a13-hsg-h702.dts | 37 +- arch/arm/dts/sun5i-a13-inet-86vs.dts | 2 +- ...common.dtsi => sun5i-a13-licheepi-one.dts} | 146 +++++--- arch/arm/dts/sun5i-a13-olinuxino-micro.dts | 50 +-- arch/arm/dts/sun5i-a13-olinuxino.dts | 56 +-- .../dts/sun5i-a13-pocketbook-touch-lux-3.dts | 258 ++++++++++++++ arch/arm/dts/sun5i-a13-q8-tablet.dts | 18 +- arch/arm/dts/sun5i-a13-utoo-p66.dts | 26 +- arch/arm/dts/sun5i-a13.dtsi | 23 +- arch/arm/dts/sun5i-gr8-chip-pro.dts | 38 +- arch/arm/dts/sun5i-gr8-evb.dts | 333 ++++++++++++++++++ arch/arm/dts/sun5i-gr8.dtsi | 12 +- arch/arm/dts/sun5i-r8-chip.dts | 52 +-- .../dts/sun5i-reference-design-tablet.dtsi | 57 +-- arch/arm/dts/sun5i.dtsi | 209 +++++++---- arch/arm/dts/sun6i-a31-app4-evb1.dts | 10 +- arch/arm/dts/sun6i-a31-colombus.dts | 57 +-- arch/arm/dts/sun6i-a31-hummingbird.dts | 75 +--- arch/arm/dts/sun6i-a31-i7.dts | 47 +-- arch/arm/dts/sun6i-a31-m9.dts | 46 +-- arch/arm/dts/sun6i-a31-mele-a1000g-quad.dts | 46 +-- arch/arm/dts/sun6i-a31-mixtile-loftq.dts | 6 +- arch/arm/dts/sun6i-a31.dtsi | 218 +++++++----- arch/arm/dts/sun6i-a31s-colorfly-e708-q1.dts | 2 +- arch/arm/dts/sun6i-a31s-cs908.dts | 17 +- arch/arm/dts/sun6i-a31s-inet-q972.dts | 8 +- arch/arm/dts/sun6i-a31s-primo81.dts | 32 +- arch/arm/dts/sun6i-a31s-sina31s-core.dtsi | 4 +- arch/arm/dts/sun6i-a31s-sina31s.dts | 39 +- arch/arm/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 144 +++++--- .../sun6i-a31s-yones-toptech-bs1078-v2.dts | 22 +- .../dts/sun6i-reference-design-tablet.dtsi | 22 +- arch/arm/dts/sun7i-a20-bananapi-m1-plus.dts | 16 +- arch/arm/dts/sun7i-a20-bananapi.dts | 41 +-- arch/arm/dts/sun7i-a20-bananapro.dts | 16 +- arch/arm/dts/sun7i-a20-cubieboard2.dts | 28 +- arch/arm/dts/sun7i-a20-cubietruck.dts | 20 +- arch/arm/dts/sun7i-a20-haoyu-marsboard.dts | 182 ++++++++++ arch/arm/dts/sun7i-a20-hummingbird.dts | 21 +- arch/arm/dts/sun7i-a20-i12-tvbox.dts | 16 +- arch/arm/dts/sun7i-a20-icnova-swac.dts | 15 +- arch/arm/dts/sun7i-a20-itead-ibox.dts | 8 +- arch/arm/dts/sun7i-a20-lamobo-r1.dts | 16 +- .../dts/sun7i-a20-linutronix-testbox-v2.dts | 47 +++ arch/arm/dts/sun7i-a20-m3.dts | 14 +- arch/arm/dts/sun7i-a20-olimex-som-evb.dts | 14 +- arch/arm/dts/sun7i-a20-olimex-som204-evb.dts | 30 +- .../arm/dts/sun7i-a20-olinuxino-lime-emmc.dts | 32 ++ arch/arm/dts/sun7i-a20-olinuxino-lime.dts | 32 +- arch/arm/dts/sun7i-a20-olinuxino-lime2.dts | 46 +-- arch/arm/dts/sun7i-a20-olinuxino-micro.dts | 32 +- arch/arm/dts/sun7i-a20-orangepi-mini.dts | 28 +- arch/arm/dts/sun7i-a20-orangepi.dts | 26 +- arch/arm/dts/sun7i-a20-pcduino3-nano.dts | 32 +- arch/arm/dts/sun7i-a20-pcduino3.dts | 28 +- arch/arm/dts/sun7i-a20-wexler-tab7200.dts | 13 +- arch/arm/dts/sun7i-a20-wits-pro-a20-dkt.dts | 24 +- arch/arm/dts/sun7i-a20.dtsi | 254 +++++++++++-- arch/arm/dts/sun8i-a23-a33.dtsi | 308 ++++++++++++---- arch/arm/dts/sun8i-a23-evb.dts | 20 +- arch/arm/dts/sun8i-a23-gt90h-v4.dts | 2 +- ...ommon.dtsi => sun8i-a23-ippo-q8h-v1.2.dts} | 54 ++- arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts | 73 ++++ .../dts/sun8i-a23-polaroid-mid2407pxe03.dts | 15 +- .../dts/sun8i-a23-polaroid-mid2809pxe04.dts | 15 +- arch/arm/dts/sun8i-a23-q8-tablet.dts | 10 + arch/arm/dts/sun8i-a23.dtsi | 26 +- ...c-edition.dts => sun8i-a33-et-q8-v1.6.dts} | 32 +- arch/arm/dts/sun8i-a33-ga10h-v1.1.dts | 4 +- arch/arm/dts/sun8i-a33-inet-d978-rev2.dts | 14 +- arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts | 57 +++ arch/arm/dts/sun8i-a33-olinuxino.dts | 12 +- arch/arm/dts/sun8i-a33-q8-tablet.dts | 7 + arch/arm/dts/sun8i-a33-sinlinx-sina33.dts | 34 +- arch/arm/dts/sun8i-a33.dtsi | 270 +++++--------- .../dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 12 + arch/arm/dts/sun8i-a83t-bananapi-m3.dts | 55 ++- arch/arm/dts/sun8i-a83t-cubietruck-plus.dts | 77 +++- arch/arm/dts/sun8i-a83t-tbs-a711.dts | 101 +++++- arch/arm/dts/sun8i-a83t.dtsi | 311 ++++++++++++++-- .../dts/sun8i-h2-plus-bananapi-m2-zero.dts | 28 +- arch/arm/dts/sun8i-h3-beelink-x2.dts | 27 +- arch/arm/dts/sun8i-h3-nanopi-neo-air.dts | 28 ++ arch/arm/dts/sun8i-h3-nanopi-r1.dts | 169 +++++++++ arch/arm/dts/sun8i-h3-nanopi.dtsi | 1 + arch/arm/dts/sun8i-h3-orangepi-2.dts | 3 +- arch/arm/dts/sun8i-h3-orangepi-pc.dts | 3 +- arch/arm/dts/sun8i-h3.dtsi | 10 +- arch/arm/dts/sun8i-q8-common.dtsi | 31 +- arch/arm/dts/sun8i-r16-bananapi-m2m.dts | 55 ++- .../dts/sun8i-r16-nintendo-nes-classic.dts | 54 +++ .../sun8i-r16-nintendo-super-nes-classic.dts | 11 + arch/arm/dts/sun8i-r16-parrot.dts | 62 +--- arch/arm/dts/sun8i-r40-feta40i.dtsi | 106 ++++++ arch/arm/dts/sun8i-r40-oka40i-c.dts | 203 +++++++++++ arch/arm/dts/sun8i-r40.dtsi | 118 ++++++- .../dts/sun8i-reference-design-tablet.dtsi | 33 +- arch/arm/dts/sun8i-s3-elimo-impetus.dtsi | 44 +++ arch/arm/dts/sun8i-s3-elimo-initium.dts | 29 ++ arch/arm/dts/sun8i-s3-pinecube.dts | 13 +- arch/arm/dts/sun8i-t3-cqa3t-bv3.dts | 226 ++++++++++++ arch/arm/dts/sun8i-v3-sl631-imx179.dts | 12 + arch/arm/dts/sun8i-v3-sl631.dtsi | 138 ++++++++ arch/arm/dts/sun8i-v3.dtsi | 36 ++ arch/arm/dts/sun8i-v3s-licheepi-zero-dock.dts | 17 +- arch/arm/dts/sun8i-v3s.dtsi | 93 ++++- arch/arm/dts/sun9i-a80-cubieboard4.dts | 67 +++- arch/arm/dts/sun9i-a80-optimus.dts | 50 ++- arch/arm/dts/sun9i-a80.dtsi | 195 ++++++---- arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi | 18 +- arch/arm/dts/sunxi-bananapi-m2-plus.dtsi | 4 +- arch/arm/dts/sunxi-common-regulators.dtsi | 39 -- arch/arm/dts/sunxi-h3-h5.dtsi | 42 ++- arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi | 13 + arch/arm/dts/sunxi-libretech-all-h3-it.dtsi | 2 +- .../dts/sunxi-reference-design-tablet.dtsi | 11 +- arch/arm/mach-sunxi/Kconfig | 2 +- .../Nintendo_NES_Classic_Edition_defconfig | 2 +- include/dt-bindings/clock/sun50i-a64-ccu.h | 2 +- include/dt-bindings/clock/sun5i-ccu.h | 13 +- include/dt-bindings/clock/sun6i-a31-ccu.h | 2 + include/dt-bindings/clock/sun8i-a23-a33-ccu.h | 2 + include/dt-bindings/clock/sun8i-h3-ccu.h | 2 +- include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 + include/dt-bindings/reset/sun5i-ccu.h | 11 +- include/dt-bindings/reset/sun8i-v3s-ccu.h | 3 + 177 files changed, 5704 insertions(+), 2683 deletions(-) create mode 100644 arch/arm/dts/sun4i-a10-topwise-a721.dts create mode 100644 arch/arm/dts/sun50i-h6-pine-h64-model-b.dts create mode 100644 arch/arm/dts/sun50i-h6-tanix-tx6-mini.dts create mode 100644 arch/arm/dts/sun50i-h6-tanix.dtsi rename arch/arm/dts/{sun5i-q8-common.dtsi => sun5i-a13-licheepi-one.dts} (62%) create mode 100644 arch/arm/dts/sun5i-a13-pocketbook-touch-lux-3.dts create mode 100644 arch/arm/dts/sun5i-gr8-evb.dts create mode 100644 arch/arm/dts/sun7i-a20-haoyu-marsboard.dts create mode 100644 arch/arm/dts/sun7i-a20-linutronix-testbox-v2.dts create mode 100644 arch/arm/dts/sun7i-a20-olinuxino-lime-emmc.dts rename arch/arm/dts/{sunxi-q8-common.dtsi => sun8i-a23-ippo-q8h-v1.2.dts} (75%) create mode 100644 arch/arm/dts/sun8i-a23-ippo-q8h-v5.dts rename arch/arm/dts/{sun8i-r16-nintendo-nes-classic-edition.dts => sun8i-a33-et-q8-v1.6.dts} (81%) create mode 100644 arch/arm/dts/sun8i-a33-ippo-q8h-v1.2.dts create mode 100644 arch/arm/dts/sun8i-h3-nanopi-r1.dts create mode 100644 arch/arm/dts/sun8i-r16-nintendo-nes-classic.dts create mode 100644 arch/arm/dts/sun8i-r16-nintendo-super-nes-classic.dts create mode 100644 arch/arm/dts/sun8i-r40-feta40i.dtsi create mode 100644 arch/arm/dts/sun8i-r40-oka40i-c.dts create mode 100644 arch/arm/dts/sun8i-s3-elimo-impetus.dtsi create mode 100644 arch/arm/dts/sun8i-s3-elimo-initium.dts create mode 100644 arch/arm/dts/sun8i-t3-cqa3t-bv3.dts create mode 100644 arch/arm/dts/sun8i-v3-sl631-imx179.dts create mode 100644 arch/arm/dts/sun8i-v3-sl631.dtsi