[PATCH 00/10] arm64: dts: allwinner: A64 boards DT updates

[PATCH 00/10] arm64: dts: allwinner: A64 boards DT updates

[Andre Przywara]

When starring at some DTs while copying the kernel DTs into the U-Boot
tree, I realised that some boards seem to get more love than others.
Fix up some issues I found by inspection on some boards:
Patch 1 adds L2 cache nodes, to avoid a message on the boot console.
Patch 2 adds a separate DT file for the Pine64-LTS board, which from the
software point of view is very much a SOPine + baseboard.
There were reports from people with the Olinuxino board about various
issues and missing features, so patches 3 till 5 attempt to fix these.
The NanoPi-A64 also hasn't been updated in a while, enable the Ethernet
and the WiFi/Bluetooth chip, and fix some voltage issues in the last 5
patches.

I don't have the Olinuxino or NanoPi-A64, so can't test these boards.
So even though I have carefully checked the changes against the
available schematics, I would treat the patches for those two boards
as a "discussion base" and would love to see some testing and
confirmation from owners of these systems.

Cheers,
Andre.

Andre Przywara (10):
  arm64: dts: allwinner: a64: Add L2 cache nodes
  arm64: dts: allwinner: a64: Add Pine64-LTS device tree file
  arm64: dts: allwinner: a64: Olinuxino: fix DRAM voltage
  arm64: dts: allwinner: a64: Olinuxino: add Ethernet nodes
  arm64: dts: allwinner: a64: Olinuxino: enable USB
  arm64: dts: allwinner: a64: NanoPi-A64: Fix DCDC1 voltage
  arm64: dts: allwinner: a64: NanoPi-A64: Add Ethernet
  arm64: dts: allwinner: a64: NanoPi-A64: Fix PortE voltage
  arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip
  arm64: dts: allwinner: a64: NanoPi-A64: Add blue status LED

 arch/arm64/boot/dts/allwinner/Makefile             |  1 +
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 72 +++++++++++++++++++++-
 .../boot/dts/allwinner/sun50i-a64-olinuxino.dts    | 63 +++++++++++++++++--
 .../boot/dts/allwinner/sun50i-a64-pine64-lts.dts   | 13 ++++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi      |  9 +++
 5 files changed, 151 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts

-- 
2.14.4

[PATCH 01/10] arm64: dts: allwinner: a64: Add L2 cache nodes

[Andre Przywara]

Current kernels complain when booting on an A64 Soc:
....
[    1.904297] cacheinfo: Unable to detect cache hierarchy for CPU 0
....
Not a real biggie on this flat topology, but also easy enough to fix.

Add the L2 cache node and let each CPU point to it.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 840753432ea5..53af7e7ab62c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -88,6 +88,7 @@
 			device_type = "cpu";
 			reg = <0>;
 			enable-method = "psci";
+			next-level-cache = <&L2>;
 		};
 
 		cpu1: cpu at 1 {
@@ -95,6 +96,7 @@
 			device_type = "cpu";
 			reg = <1>;
 			enable-method = "psci";
+			next-level-cache = <&L2>;
 		};
 
 		cpu2: cpu at 2 {
@@ -102,6 +104,7 @@
 			device_type = "cpu";
 			reg = <2>;
 			enable-method = "psci";
+			next-level-cache = <&L2>;
 		};
 
 		cpu3: cpu at 3 {
@@ -109,6 +112,12 @@
 			device_type = "cpu";
 			reg = <3>;
 			enable-method = "psci";
+			next-level-cache = <&L2>;
+		};
+
+                L2: l2-cache {
+			compatible = "cache";
+			cache-level = <2>;
 		};
 	};
 
-- 
2.14.4

[PATCH 02/10] arm64: dts: allwinner: a64: Add Pine64-LTS device tree file

[Andre Przywara]

The Pine64-LTS is a variant of the Pine64 board, from the software
visible side resembling a SoPine module on a baseboard, though the
board has the SoC and DRAM integrated on one PCB.
Due to this it basically shares the DT with the SoPine baseboard, which
we mimic in our DT by inclucing the boardboard .dts into the new file,
just overwriting the model name.
Having a separate .dts for this seems useful, since we don't know yet if
there are subtle differences between the two. Also the SoC on the LTS
board is technically an "R18" instead of the original "A64", although as
far as we know this is just a relabelled version of the original SoC.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/Makefile                  |  1 +
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts | 13 +++++++++++++
 2 files changed, 14 insertions(+)
 create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts

diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
index 9ffa7a038791..b7034327b28b 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-nanopi-a64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-olinuxino.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-orangepi-win.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-lts.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinebook.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
new file mode 100644
index 000000000000..72d6961dc312
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64-lts.dts
@@ -0,0 +1,13 @@
+/*
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ *
+ * Copyright (c) 2018 ARM Ltd.
+ */
+
+#include "sun50i-a64-sopine-baseboard.dts"
+
+/ {
+	model = "Pine64 LTS";
+	compatible = "pine64,pine64-lts", "allwinner,sun50i-r18",
+		     "allwinner,sun50i-a64";
+};
-- 
2.14.4

[PATCH 03/10] arm64: dts: allwinner: a64: Olinuxino: fix DRAM voltage

[Andre Przywara]

The Olinuxino board uses DDR3L chips which are supposed to be driven
with 1.35V. The reset default of the AXP is properly set to 1.36V.

While technically the chips can also run at 1.5 volts, changing the
voltage on the fly while booting Linux is asking for trouble. Also
running at a lower voltage saves power.

So fix the DCDC5 value to match the actual board design.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 3f531393eaee..f945c70f3a80 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -140,12 +140,14 @@
 	regulator-name = "vdd-cpux";
 };
 
-/* DCDC3 is polyphased with DCDC2 */
-
+/*
+ * DCDC3 is polyphased with DCDC2 to supply the DDR3L DRAM chips.
+ * 1.36V is the closest to the nominal 1.35V that the PMIC can drive.
+ */
 &reg_dcdc5 {
 	regulator-always-on;
-	regulator-min-microvolt = <1500000>;
-	regulator-max-microvolt = <1500000>;
+	regulator-min-microvolt = <1360000>;
+	regulator-max-microvolt = <1360000>;
 	regulator-name = "vcc-ddr3";
 };
 
-- 
2.14.4

[PATCH 04/10] arm64: dts: allwinner: a64: Olinuxino: add Ethernet nodes

[Andre Przywara]

Add the DT nodes required to enable the Gigabit Ethernet on the board.
The PHY is powered by the always-on power rail VDD_SYS_3.3V (DCDC1).

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index f945c70f3a80..73ddb665a995 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -64,6 +64,22 @@
 	};
 };
 
+&emac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-handle = <&ext_rgmii_phy>;
+	phy-supply = <&reg_dcdc1>;
+	status = "okay";
+};
+
+&mdio {
+	ext_rgmii_phy: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
-- 
2.14.4

[PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

The Olinuxino has two USB socket:
USB0 is connected to a micro B socket. As it has the ID pin wired, we
describe it as a proper OTG socket, which switches between host and
device automatically.
USB1 is connected to a normal USB A socket. PG9 enables the power line,
so add the required regulator as well.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../boot/dts/allwinner/sun50i-a64-olinuxino.dts    | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 73ddb665a995..0485a10a0114 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -62,6 +62,25 @@
 		compatible = "mmc-pwrseq-simple";
 		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
 	};
+
+	reg_usb0_vbus: usb0-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb0-vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-boot-on;
+		enable-active-high;
+		gpio = <&pio 6 9 GPIO_ACTIVE_HIGH>; /* PG9 */
+		status = "okay";
+	};
+};
+
+&ehci0 {
+	status = "okay";
+};
+
+&ehci1 {
+	status = "okay";
 };
 
 &emac {
@@ -108,6 +127,14 @@
 	};
 };
 
+&ohci0 {
+	status = "okay";
+};
+
+&ohci1 {
+	status = "okay";
+};
+
 &r_rsb {
 	status = "okay";
 
@@ -241,3 +268,13 @@
 	pinctrl-0 = <&uart0_pins_a>;
 	status = "okay";
 };
+
+&usb_otg {
+	status = "okay";
+};
+
+&usbphy {
+	status = "okay";
+	usb0_id_det-gpios = <&pio 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
+	usb0_vbus-supply = <&reg_usb0_vbus>;
+};
-- 
2.14.4

[PATCH 06/10] arm64: dts: allwinner: a64: NanoPi-A64: Fix DCDC1 voltage

[Andre Przywara]

According to the NanoPi-A64 schematics, DCDC1 is connected to a voltage
rail named "VDD_SYS_3.3V". All users seem to expect 3.3V here: the
Ethernet PHY, the uSD card slot, the camera interface and the GPIO pins
on the headers.
Fix up the voltage on the regulator to lift it up to 3.3V.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 98dbff19f5cc..5caba225b4f7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -125,9 +125,9 @@
 
 &reg_dcdc1 {
 	regulator-always-on;
-	regulator-min-microvolt = <3000000>;
-	regulator-max-microvolt = <3000000>;
-	regulator-name = "vcc-3v";
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-3v3";
 };
 
 &reg_dcdc2 {
-- 
2.14.4

[PATCH 07/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Ethernet

[Andre Przywara]

The NanoPi-A64 has the usual Realtek Gbit PHY connected to the EMAC,
so add the respective nodes to the DT. The PHY is powered by the
VDD_SYS_3.3V line, which is always on.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 5caba225b4f7..bd35a093e6cd 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -51,6 +51,7 @@
 	compatible = "friendlyarm,nanopi-a64", "allwinner,sun50i-a64";
 
 	aliases {
+		ethernet0 = &emac;
 		serial0 = &uart0;
 	};
 
@@ -67,6 +68,15 @@
 	status = "okay";
 };
 
+&emac {
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-handle = <&ext_rgmii_phy>;
+	phy-supply = <&reg_dcdc1>;
+	status = "okay";
+};
+
 /* i2c1 connected with gpio headers like pine64, bananapi */
 &i2c1 {
 	pinctrl-names = "default";
@@ -78,6 +88,13 @@
 	bias-pull-up;
 };
 
+&mdio {
+	ext_rgmii_phy: ethernet-phy at 1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <1>;
+	};
+};
+
 &mmc0 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc0_pins>;
-- 
2.14.4

[PATCH 08/10] arm64: dts: allwinner: a64: NanoPi-A64: Fix PortE voltage

[Andre Przywara]

VCC-PE is driven the AXP's ALDO1 regulator, and is connected to the I2C
pins on the RPi2 header. One would expect 3.3 V there, so enable this
regulator and set it to this voltage.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index bd35a093e6cd..0439cff685d6 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -126,6 +126,13 @@
 
 #include "axp803.dtsi"
 
+&reg_aldo1 {
+	regulator-always-on;
+	regulator-min-microvolt = <3300000>;
+	regulator-max-microvolt = <3300000>;
+	regulator-name = "vcc-pe";
+};
+
 &reg_aldo2 {
 	regulator-always-on;
 	regulator-min-microvolt = <1800000>;
-- 
2.14.4

[PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Andre Przywara]

The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
to the usual MMC1 and UART1. The power is provided by the always-on
VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.

Add the respective nodes to the DT to make it usable.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index 0439cff685d6..bb3ba7709dee 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -53,11 +53,18 @@
 	aliases {
 		ethernet0 = &emac;
 		serial0 = &uart0;
+		serial1 = &uart1;
 	};
 
 	chosen {
 		stdout-path = "serial0:115200n8";
 	};
+
+        wifi_pwrseq: wifi_pwrseq {
+                compatible = "mmc-pwrseq-simple";
+                reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
+        };
+
 };
 
 &ehci0 {
@@ -105,6 +112,25 @@
 	status = "okay";
 };
 
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dldo4>;
+	mmc-pwrseq = <&wifi_pwrseq>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+
+	brcmf: wifi at 1 {
+		reg = <1>;
+		compatible = "brcm,bcm4329-fmac";
+		interrupt-parent = <&r_pio>;
+		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
+		interrupt-names = "host-wake";
+	};
+};
+
 &ohci0 {
 	status = "okay";
 };
@@ -229,6 +255,13 @@
 	status = "okay";
 };
 
+/* Connected to the Bluetooth UART, with hardware handshake pins */
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+	status = "okay";
+};
+
 &usbphy {
 	status = "okay";
 };
-- 
2.14.4

[PATCH 10/10] arm64: dts: allwinner: a64: NanoPi-A64: Add blue status LED

[Andre Przywara]

Beside the non-controllable green power LED, the NanoPi-A64 features a
blue "status" LED, connected to PD24.

Add the device tree node to make it usable.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
index bb3ba7709dee..58df76530f03 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
@@ -60,6 +60,15 @@
 		stdout-path = "serial0:115200n8";
 	};
 
+	leds {
+		compatible = "gpio-leds";
+
+		blue {
+			label = "nanopi-a64:blue:status";
+			gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+		};
+	};
+
         wifi_pwrseq: wifi_pwrseq {
                 compatible = "mmc-pwrseq-simple";
                 reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
-- 
2.14.4

[linux-sunxi] [PATCH 03/10] arm64: dts: allwinner: a64: Olinuxino: fix DRAM voltage

[Icenowy Zheng]

? 2018?7?6? GMT+08:00 ??4:52:03, Andre Przywara <andre.przywara@arm.com> ??:
>The Olinuxino board uses DDR3L chips which are supposed to be driven
>with 1.35V. The reset default of the AXP is properly set to 1.36V.
>
>While technically the chips can also run at 1.5 volts, changing the
>voltage on the fly while booting Linux is asking for trouble. Also
>running at a lower voltage saves power.
>
>So fix the DCDC5 value to match the actual board design.
>
>Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>---
> arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>index 3f531393eaee..f945c70f3a80 100644
>--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>@@ -140,12 +140,14 @@
> 	regulator-name = "vdd-cpux";
> };
> 
>-/* DCDC3 is polyphased with DCDC2 */
>-
>+/*
>+ * DCDC3 is polyphased with DCDC2 to supply the DDR3L DRAM chips.
>+ * 1.36V is the closest to the nominal 1.35V that the PMIC can drive.

The comment is a mess. DCDC2+3 is for CPU, and 5 is for DRAM.

Personally I suggest to use two comment blocks, one sit at
where dcdc3 should appear, and the second before dcdc5.

>+ */
> &reg_dcdc5 {
> 	regulator-always-on;
>-	regulator-min-microvolt = <1500000>;
>-	regulator-max-microvolt = <1500000>;
>+	regulator-min-microvolt = <1360000>;
>+	regulator-max-microvolt = <1360000>;
> 	regulator-name = "vcc-ddr3";
> };
> 

[PATCH 08/10] arm64: dts: allwinner: a64: NanoPi-A64: Fix PortE voltage

[Icenowy Zheng]

? 2018?7?6? GMT+08:00 ??4:52:08, Andre Przywara <andre.przywara@arm.com> ??:
>VCC-PE is driven the AXP's ALDO1 regulator, and is connected to the I2C
>pins on the RPi2 header. One would expect 3.3 V there, so enable this
>regulator and set it to this voltage.

However, 3.3V will break the DVP camera (although not yet
supported).

>
>Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>---
> arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>index bd35a093e6cd..0439cff685d6 100644
>--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>@@ -126,6 +126,13 @@
> 
> #include "axp803.dtsi"
> 
>+&reg_aldo1 {
>+	regulator-always-on;
>+	regulator-min-microvolt = <3300000>;
>+	regulator-max-microvolt = <3300000>;
>+	regulator-name = "vcc-pe";
>+};
>+
> &reg_aldo2 {
> 	regulator-always-on;
> 	regulator-min-microvolt = <1800000>;

[PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Icenowy Zheng]

? 2018?7?6? GMT+08:00 ??4:52:09, Andre Przywara <andre.przywara@arm.com> ??:
>The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
>to the usual MMC1 and UART1. The power is provided by the always-on
>VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.
>
>Add the respective nodes to the DT to make it usable.
>
>Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>---
>.../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 33
>++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>index 0439cff685d6..bb3ba7709dee 100644
>--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>@@ -53,11 +53,18 @@
> 	aliases {
> 		ethernet0 = &emac;
> 		serial0 = &uart0;
>+		serial1 = &uart1;
> 	};
> 
> 	chosen {
> 		stdout-path = "serial0:115200n8";
> 	};
>+
>+        wifi_pwrseq: wifi_pwrseq {
>+                compatible = "mmc-pwrseq-simple";
>+                reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>+        };
>+
> };
> 
> &ehci0 {
>@@ -105,6 +112,25 @@
> 	status = "okay";
> };
> 
>+&mmc1 {
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&mmc1_pins>;
>+	vmmc-supply = <&reg_dcdc1>;
>+	vqmmc-supply = <&reg_dldo4>;
>+	mmc-pwrseq = <&wifi_pwrseq>;
>+	bus-width = <4>;
>+	non-removable;
>+	status = "okay";
>+
>+	brcmf: wifi at 1 {
>+		reg = <1>;
>+		compatible = "brcm,bcm4329-fmac";
>+		interrupt-parent = <&r_pio>;
>+		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
>+		interrupt-names = "host-wake";
>+	};
>+};
>+
> &ohci0 {
> 	status = "okay";
> };
>@@ -229,6 +255,13 @@
> 	status = "okay";
> };
> 
>+/* Connected to the Bluetooth UART, with hardware handshake pins */
>+&uart1 {
>+	pinctrl-names = "default";
>+	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>+	status = "okay";

Do you consider to enable serdev driver for it?

>+};
>+
> &usbphy {
> 	status = "okay";
> };

[linux-sunxi] [PATCH 03/10] arm64: dts: allwinner: a64: Olinuxino: fix DRAM voltage

[Andre Przywara]

Hi,

On 06/07/18 09:55, Icenowy Zheng wrote:
> 
> 
> ? 2018?7?6? GMT+08:00 ??4:52:03, Andre Przywara <andre.przywara@arm.com> ??:
>> The Olinuxino board uses DDR3L chips which are supposed to be driven
>> with 1.35V. The reset default of the AXP is properly set to 1.36V.
>>
>> While technically the chips can also run at 1.5 volts, changing the
>> voltage on the fly while booting Linux is asking for trouble. Also
>> running at a lower voltage saves power.
>>
>> So fix the DCDC5 value to match the actual board design.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 10 ++++++----
>> 1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> index 3f531393eaee..f945c70f3a80 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
>> @@ -140,12 +140,14 @@
>> 	regulator-name = "vdd-cpux";
>> };
>>
>> -/* DCDC3 is polyphased with DCDC2 */
>> -
>> +/*
>> + * DCDC3 is polyphased with DCDC2 to supply the DDR3L DRAM chips.
>> + * 1.36V is the closest to the nominal 1.35V that the PMIC can drive.
> 
> The comment is a mess. DCDC2+3 is for CPU, and 5 is for DRAM.

Aargh, true. I was misled by that lonely comment.

> Personally I suggest to use two comment blocks, one sit at
> where dcdc3 should appear, and the second before dcdc5.

Yeah, sounds like the right thing to do.

Thanks for having a look!

Cheers,
Andre.

>> + */
>> &reg_dcdc5 {
>> 	regulator-always-on;
>> -	regulator-min-microvolt = <1500000>;
>> -	regulator-max-microvolt = <1500000>;
>> +	regulator-min-microvolt = <1360000>;
>> +	regulator-max-microvolt = <1360000>;
>> 	regulator-name = "vcc-ddr3";
>> };
>>

[PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Andre Przywara]

Hi,

On 06/07/18 10:04, Icenowy Zheng wrote:
> 
> 
> ? 2018?7?6? GMT+08:00 ??4:52:09, Andre Przywara <andre.przywara@arm.com> ??:
>> The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
>> to the usual MMC1 and UART1. The power is provided by the always-on
>> VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.
>>
>> Add the respective nodes to the DT to make it usable.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 33
>> ++++++++++++++++++++++
>> 1 file changed, 33 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> index 0439cff685d6..bb3ba7709dee 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> @@ -53,11 +53,18 @@
>> 	aliases {
>> 		ethernet0 = &emac;
>> 		serial0 = &uart0;
>> +		serial1 = &uart1;
>> 	};
>>
>> 	chosen {
>> 		stdout-path = "serial0:115200n8";
>> 	};
>> +
>> +        wifi_pwrseq: wifi_pwrseq {
>> +                compatible = "mmc-pwrseq-simple";
>> +                reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> +        };
>> +
>> };
>>
>> &ehci0 {
>> @@ -105,6 +112,25 @@
>> 	status = "okay";
>> };
>>
>> +&mmc1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&mmc1_pins>;
>> +	vmmc-supply = <&reg_dcdc1>;
>> +	vqmmc-supply = <&reg_dldo4>;
>> +	mmc-pwrseq = <&wifi_pwrseq>;
>> +	bus-width = <4>;
>> +	non-removable;
>> +	status = "okay";
>> +
>> +	brcmf: wifi at 1 {
>> +		reg = <1>;
>> +		compatible = "brcm,bcm4329-fmac";
>> +		interrupt-parent = <&r_pio>;
>> +		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
>> +		interrupt-names = "host-wake";
>> +	};
>> +};
>> +
>> &ohci0 {
>> 	status = "okay";
>> };
>> @@ -229,6 +255,13 @@
>> 	status = "okay";
>> };
>>
>> +/* Connected to the Bluetooth UART, with hardware handshake pins */
>> +&uart1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>> +	status = "okay";
> 
> Do you consider to enable serdev driver for it?

Have you tried this before?
I remember I hacked Bluetooth to work on a Pine64, but this was quite
dodgy with some userland tools needed from somewhere, I am pretty sure
this was just using /dev/ttySx (because this was ages ago, before the
introduction of serdev, I believe).

Basically I just wanted to mark those pins as "used", because they are
hardwired to this Bluetooth chip.

Cheers,
Andre.

>> +};
>> +
>> &usbphy {
>> 	status = "okay";
>> };

[PATCH 08/10] arm64: dts: allwinner: a64: NanoPi-A64: Fix PortE voltage

[Andre Przywara]

Hi,

On 06/07/18 10:03, Icenowy Zheng wrote:
> 
> 
> ? 2018?7?6? GMT+08:00 ??4:52:08, Andre Przywara <andre.przywara@arm.com> ??:
>> VCC-PE is driven the AXP's ALDO1 regulator, and is connected to the I2C
>> pins on the RPi2 header. One would expect 3.3 V there, so enable this
>> regulator and set it to this voltage.
> 
> However, 3.3V will break the DVP camera (although not yet
> supported).

Interesting, so what would the supposed voltage be here? The NanoPi-A64
schematic at least mentions 3.3V for the *supply* pins on that connector
and connects VDD_SYS_3.3V to that. Happy to put any other value for the
I/O here, but it would be problematic to see a different voltage on
those two I2C pins on the RPi2 header.

Cheers,
Andre.

>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> index bd35a093e6cd..0439cff685d6 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> @@ -126,6 +126,13 @@
>>
>> #include "axp803.dtsi"
>>
>> +&reg_aldo1 {
>> +	regulator-always-on;
>> +	regulator-min-microvolt = <3300000>;
>> +	regulator-max-microvolt = <3300000>;
>> +	regulator-name = "vcc-pe";
>> +};
>> +
>> &reg_aldo2 {
>> 	regulator-always-on;
>> 	regulator-min-microvolt = <1800000>;

[PATCH 08/10] arm64: dts: allwinner: a64: NanoPi-A64: Fix PortE voltage

[Chen-Yu Tsai]

On Fri, Jul 6, 2018 at 5:39 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 06/07/18 10:03, Icenowy Zheng wrote:
>>
>>
>> ? 2018?7?6? GMT+08:00 ??4:52:08, Andre Przywara <andre.przywara@arm.com> ??:
>>> VCC-PE is driven the AXP's ALDO1 regulator, and is connected to the I2C
>>> pins on the RPi2 header. One would expect 3.3 V there, so enable this
>>> regulator and set it to this voltage.
>>
>> However, 3.3V will break the DVP camera (although not yet
>> supported).
>
> Interesting, so what would the supposed voltage be here? The NanoPi-A64
> schematic at least mentions 3.3V for the *supply* pins on that connector
> and connects VDD_SYS_3.3V to that. Happy to put any other value for the
> I/O here, but it would be problematic to see a different voltage on
> those two I2C pins on the RPi2 header.

AFAIK a whole bunch of cameras use 2.8V as their I/O supply voltage.
This is probably separate from any other core or peripheral voltages
supplied.

ChenYu

> Cheers,
> Andre.
>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> index bd35a093e6cd..0439cff685d6 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> @@ -126,6 +126,13 @@
>>>
>>> #include "axp803.dtsi"
>>>
>>> +&reg_aldo1 {
>>> +    regulator-always-on;
>>> +    regulator-min-microvolt = <3300000>;
>>> +    regulator-max-microvolt = <3300000>;
>>> +    regulator-name = "vcc-pe";
>>> +};
>>> +
>>> &reg_aldo2 {
>>>      regulator-always-on;
>>>      regulator-min-microvolt = <1800000>;

[PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Sergey Suloev]

On 07/06/2018 11:52 AM, Andre Przywara wrote:
> The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
> to the usual MMC1 and UART1. The power is provided by the always-on
> VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.
>
> Add the respective nodes to the DT to make it usable.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
>   .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts   | 33 ++++++++++++++++++++++
>   1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> index 0439cff685d6..bb3ba7709dee 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
> @@ -53,11 +53,18 @@
>   	aliases {
>   		ethernet0 = &emac;
>   		serial0 = &uart0;
> +		serial1 = &uart1;
>   	};
>   
>   	chosen {
>   		stdout-path = "serial0:115200n8";
>   	};
> +
> +        wifi_pwrseq: wifi_pwrseq {
> +                compatible = "mmc-pwrseq-simple";
> +                reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
> +        };
> +
>   };
>   
>   &ehci0 {
> @@ -105,6 +112,25 @@
>   	status = "okay";
>   };
>   
> +&mmc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc1_pins>;
> +	vmmc-supply = <&reg_dcdc1>;
> +	vqmmc-supply = <&reg_dldo4>;
> +	mmc-pwrseq = <&wifi_pwrseq>;
> +	bus-width = <4>;
> +	non-removable;
> +	status = "okay";
> +
> +	brcmf: wifi at 1 {
> +		reg = <1>;
> +		compatible = "brcm,bcm4329-fmac";
> +		interrupt-parent = <&r_pio>;
> +		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
> +		interrupt-names = "host-wake";
> +	};
> +};
> +
>   &ohci0 {
>   	status = "okay";
>   };
> @@ -229,6 +255,13 @@
>   	status = "okay";
>   };
>   
> +/* Connected to the Bluetooth UART, with hardware handshake pins */
> +&uart1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
> +	status = "okay";
> +};
> +
>   &usbphy {
>   	status = "okay";
>   };

NanoPi A64 has rtl8189 Ethernet chip.

[PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Andre Przywara]

Hi,

On 06/07/18 15:23, Sergey Suloev wrote:
> On 07/06/2018 11:52 AM, Andre Przywara wrote:
>> The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
>> to the usual MMC1 and UART1. The power is provided by the always-on
>> VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.
>>
>> Add the respective nodes to the DT to make it usable.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> ? .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts?? | 33
>> ++++++++++++++++++++++
>> ? 1 file changed, 33 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> index 0439cff685d6..bb3ba7709dee 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>> @@ -53,11 +53,18 @@
>> ????? aliases {
>> ????????? ethernet0 = &emac;
>> ????????? serial0 = &uart0;
>> +??????? serial1 = &uart1;
>> ????? };
>> ? ????? chosen {
>> ????????? stdout-path = "serial0:115200n8";
>> ????? };
>> +
>> +??????? wifi_pwrseq: wifi_pwrseq {
>> +??????????????? compatible = "mmc-pwrseq-simple";
>> +??????????????? reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>> +??????? };
>> +
>> ? };
>> ? ? &ehci0 {
>> @@ -105,6 +112,25 @@
>> ????? status = "okay";
>> ? };
>> ? +&mmc1 {
>> +??? pinctrl-names = "default";
>> +??? pinctrl-0 = <&mmc1_pins>;
>> +??? vmmc-supply = <&reg_dcdc1>;
>> +??? vqmmc-supply = <&reg_dldo4>;
>> +??? mmc-pwrseq = <&wifi_pwrseq>;
>> +??? bus-width = <4>;
>> +??? non-removable;
>> +??? status = "okay";
>> +
>> +??? brcmf: wifi at 1 {
>> +??????? reg = <1>;
>> +??????? compatible = "brcm,bcm4329-fmac";
>> +??????? interrupt-parent = <&r_pio>;
>> +??????? interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
>> +??????? interrupt-names = "host-wake";
>> +??? };
>> +};
>> +
>
> NanoPi A64 has rtl8189 Ethernet chip.
Good point, thanks for mentioning it (though I guess you mean WiFi chip).
Do you have the board? Do you have WiFi working?
>From a very brief look over the tree I don't see any explicit driver for
an SDIO based 8189 variant, but other boards claiming to have a 8189
seem to just not provide a compatible at all. Does that actually work?
It would be great if you could share some insight here!

Thanks!
Andre.

>> ? &ohci0 {
>> ????? status = "okay";
>> ? };
>> @@ -229,6 +255,13 @@
>> ????? status = "okay";
>> ? };
>> ? +/* Connected to the Bluetooth UART, with hardware handshake pins */
>> +&uart1 {
>> +??? pinctrl-names = "default";
>> +??? pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>> +??? status = "okay";
>> +};
>> +
>> ? &usbphy {
>> ????? status = "okay";
>> ? };
> 
> 
> 

[linux-sunxi] Re: [PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Icenowy Zheng]

? 2018?7?6? GMT+08:00 ??10:49:05, Andre Przywara <andre.przywara@arm.com> ??:
>Hi,
>
>On 06/07/18 15:23, Sergey Suloev wrote:
>> On 07/06/2018 11:52 AM, Andre Przywara wrote:
>>> The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
>>> to the usual MMC1 and UART1. The power is provided by the always-on
>>> VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.
>>>
>>> Add the respective nodes to the DT to make it usable.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> ? .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts?? | 33
>>> ++++++++++++++++++++++
>>> ? 1 file changed, 33 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> index 0439cff685d6..bb3ba7709dee 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> @@ -53,11 +53,18 @@
>>> ????? aliases {
>>> ????????? ethernet0 = &emac;
>>> ????????? serial0 = &uart0;
>>> +??????? serial1 = &uart1;
>>> ????? };
>>> ? ????? chosen {
>>> ????????? stdout-path = "serial0:115200n8";
>>> ????? };
>>> +
>>> +??????? wifi_pwrseq: wifi_pwrseq {
>>> +??????????????? compatible = "mmc-pwrseq-simple";
>>> +??????????????? reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2
>*/
>>> +??????? };
>>> +
>>> ? };
>>> ? ? &ehci0 {
>>> @@ -105,6 +112,25 @@
>>> ????? status = "okay";
>>> ? };
>>> ? +&mmc1 {
>>> +??? pinctrl-names = "default";
>>> +??? pinctrl-0 = <&mmc1_pins>;
>>> +??? vmmc-supply = <&reg_dcdc1>;
>>> +??? vqmmc-supply = <&reg_dldo4>;
>>> +??? mmc-pwrseq = <&wifi_pwrseq>;
>>> +??? bus-width = <4>;
>>> +??? non-removable;
>>> +??? status = "okay";
>>> +
>>> +??? brcmf: wifi at 1 {
>>> +??????? reg = <1>;
>>> +??????? compatible = "brcm,bcm4329-fmac";
>>> +??????? interrupt-parent = <&r_pio>;
>>> +??????? interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
>>> +??????? interrupt-names = "host-wake";
>>> +??? };
>>> +};
>>> +
>>
>> NanoPi A64 has rtl8189 Ethernet chip.
>Good point, thanks for mentioning it (though I guess you mean WiFi
>chip).
>Do you have the board? Do you have WiFi working?
>From a very brief look over the tree I don't see any explicit driver
>for
>an SDIO based 8189 variant, but other boards claiming to have a 8189
>seem to just not provide a compatible at all. Does that actually work?

Work with out-of-tree drivers by Hans de Goede.

>It would be great if you could share some insight here!
>
>Thanks!
>Andre.
>
>>> ? &ohci0 {
>>> ????? status = "okay";
>>> ? };
>>> @@ -229,6 +255,13 @@
>>> ????? status = "okay";
>>> ? };
>>> ? +/* Connected to the Bluetooth UART, with hardware handshake pins
>*/
>>> +&uart1 {
>>> +??? pinctrl-names = "default";
>>> +??? pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>>> +??? status = "okay";
>>> +};
>>> +
>>> ? &usbphy {
>>> ????? status = "okay";
>>> ? };
>> 
>> 
>> 

[PATCH 03/10] arm64: dts: allwinner: a64: Olinuxino: fix DRAM voltage

[Martin Lucina]

On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
> The Olinuxino board uses DDR3L chips which are supposed to be driven
> with 1.35V. The reset default of the AXP is properly set to 1.36V.
> 
> While technically the chips can also run at 1.5 volts, changing the
> voltage on the fly while booting Linux is asking for trouble. Also
> running at a lower voltage saves power.
> 
> So fix the DCDC5 value to match the actual board design.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---

Tested-by: Martin Lucina <martin@lucina.net>

[PATCH 04/10] arm64: dts: allwinner: a64: Olinuxino: add Ethernet nodes

[Martin Lucina]

On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
> Add the DT nodes required to enable the Gigabit Ethernet on the board.
> The PHY is powered by the always-on power rail VDD_SYS_3.3V (DCDC1).
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---

This may not be directly related to just the DT, but:

While this patch does result in detecting and enabling the onboard Ethernet
correctly, I am failing to successfully transmit any packets. Receive does
work.

For details see this thread:
https://groups.google.com/forum/#!topic/linux-sunxi/J9w_gXYVRgw

-mato

[PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Martin Lucina]

On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
> The Olinuxino has two USB socket:
> USB0 is connected to a micro B socket. As it has the ID pin wired, we
> describe it as a proper OTG socket, which switches between host and
> device automatically.
> USB1 is connected to a normal USB A socket. PG9 enables the power line,
> so add the required regulator as well.
> 
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---

This is not sufficient. Booting with this change results in the following
in dmesg:

musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
musb-sunxi: probe of 1c19000.usb failed with error -22
[...]
usb0-vbus: disabling

... and neither of the USB ports work.

Adding

    dr_mode = "host";

to the &usb_otg node fixes this -- the above messages go away and both
ports work as expected.

-mato

[PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

Hi,

On 06/07/18 16:04, Martin Lucina wrote:
> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
>> The Olinuxino has two USB socket:
>> USB0 is connected to a micro B socket. As it has the ID pin wired, we
>> describe it as a proper OTG socket, which switches between host and
>> device automatically.
>> USB1 is connected to a normal USB A socket. PG9 enables the power line,
>> so add the required regulator as well.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
> 
> This is not sufficient. Booting with this change results in the following
> in dmesg:
> 
> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
> musb-sunxi: probe of 1c19000.usb failed with error -22
> [...]
> usb0-vbus: disabling
> 
> ... and neither of the USB ports work.
> 
> Adding
> 
>     dr_mode = "host";

Argh, right, I remember you mentioned this before.
Still it should not affect the other USB port, and actually it is a
proper OTG port, so host is not right here. So this points to some other
oddity or incorrect description. I need to go back to the schematics and
our previous thread.

Cheers,
Andre.

> 
> to the &usb_otg node fixes this -- the above messages go away and both
> ports work as expected.
> 
> -mato
> 

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Icenowy Zheng]

? 2018?7?6? GMT+08:00 ??11:35:38, Andre Przywara <andre.przywara@arm.com> ??:
>Hi,
>
>On 06/07/18 16:04, Martin Lucina wrote:
>> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
>>> The Olinuxino has two USB socket:
>>> USB0 is connected to a micro B socket. As it has the ID pin wired,
>we
>>> describe it as a proper OTG socket, which switches between host and
>>> device automatically.
>>> USB1 is connected to a normal USB A socket. PG9 enables the power
>line,
>>> so add the required regulator as well.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>> 
>> This is not sufficient. Booting with this change results in the
>following
>> in dmesg:
>> 
>> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
>> musb-sunxi: probe of 1c19000.usb failed with error -22
>> [...]
>> usb0-vbus: disabling
>> 
>> ... and neither of the USB ports work.
>> 
>> Adding
>> 
>>     dr_mode = "host";
>
>Argh, right, I remember you mentioned this before.
>Still it should not affect the other USB port, and actually it is a
>proper OTG port, so host is not right here. So this points to some
>other
>oddity or incorrect description. I need to go back to the schematics
>and
>our previous thread.

OTG needs dr_mode = "otg"; and a ID pin.

>
>Cheers,
>Andre.
>
>> 
>> to the &usb_otg node fixes this -- the above messages go away and
>both
>> ports work as expected.
>> 
>> -mato
>> 

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

Hi,

On 06/07/18 16:36, Icenowy Zheng wrote:
> 
> 
> ? 2018?7?6? GMT+08:00 ??11:35:38, Andre Przywara <andre.przywara@arm.com> ??:
>> Hi,
>>
>> On 06/07/18 16:04, Martin Lucina wrote:
>>> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
>>>> The Olinuxino has two USB socket:
>>>> USB0 is connected to a micro B socket. As it has the ID pin wired,
>> we
>>>> describe it as a proper OTG socket, which switches between host and
>>>> device automatically.
>>>> USB1 is connected to a normal USB A socket. PG9 enables the power
>> line,
>>>> so add the required regulator as well.
>>>>
>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>> ---
>>>
>>> This is not sufficient. Booting with this change results in the
>> following
>>> in dmesg:
>>>
>>> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
>>> musb-sunxi: probe of 1c19000.usb failed with error -22
>>> [...]
>>> usb0-vbus: disabling
>>>
>>> ... and neither of the USB ports work.
>>>
>>> Adding
>>>
>>>     dr_mode = "host";
>>
>> Argh, right, I remember you mentioned this before.
>> Still it should not affect the other USB port, and actually it is a
>> proper OTG port, so host is not right here. So this points to some
>> other
>> oddity or incorrect description. I need to go back to the schematics
>> and
>> our previous thread.
> 
> OTG needs dr_mode = "otg"; and a ID pin.

Yes, and we have the ID pin in the usbphy node.
Martin, can you please check if dr_mode = "otg"; works for you?

Icenowy: still, how does it affect USB1? I mean, even if MUSB does not
initialise, it should leave the other host controller working? Is that
related to them sharing the usbphy? And this one gives up and tears
*everything* down, including the power for USB1?

Cheers,
Andre.

>>>
>>> to the &usb_otg node fixes this -- the above messages go away and
>> both
>>> ports work as expected.
>>>
>>> -mato
>>>

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Icenowy Zheng]

? 2018?7?6? GMT+08:00 ??11:46:08, Andre Przywara <andre.przywara@arm.com> ??:
>Hi,
>
>On 06/07/18 16:36, Icenowy Zheng wrote:
>> 
>> 
>> ? 2018?7?6? GMT+08:00 ??11:35:38, Andre Przywara
><andre.przywara@arm.com> ??:
>>> Hi,
>>>
>>> On 06/07/18 16:04, Martin Lucina wrote:
>>>> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
>>>>> The Olinuxino has two USB socket:
>>>>> USB0 is connected to a micro B socket. As it has the ID pin wired,
>>> we
>>>>> describe it as a proper OTG socket, which switches between host
>and
>>>>> device automatically.
>>>>> USB1 is connected to a normal USB A socket. PG9 enables the power
>>> line,
>>>>> so add the required regulator as well.
>>>>>
>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>> ---
>>>>
>>>> This is not sufficient. Booting with this change results in the
>>> following
>>>> in dmesg:
>>>>
>>>> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
>>>> musb-sunxi: probe of 1c19000.usb failed with error -22
>>>> [...]
>>>> usb0-vbus: disabling
>>>>
>>>> ... and neither of the USB ports work.
>>>>
>>>> Adding
>>>>
>>>>     dr_mode = "host";
>>>
>>> Argh, right, I remember you mentioned this before.
>>> Still it should not affect the other USB port, and actually it is a
>>> proper OTG port, so host is not right here. So this points to some
>>> other
>>> oddity or incorrect description. I need to go back to the schematics
>>> and
>>> our previous thread.
>> 
>> OTG needs dr_mode = "otg"; and a ID pin.
>
>Yes, and we have the ID pin in the usbphy node.
>Martin, can you please check if dr_mode = "otg"; works for you?
>
>Icenowy: still, how does it affect USB1? I mean, even if MUSB does not
>initialise, it should leave the other host controller working? Is that
>related to them sharing the usbphy? And this one gives up and tears
>*everything* down, including the power for USB1?

You wrongly bound the regulator to USB0, not USB1.

USB0 regulator should be AXP's drivevbus if it's OTG in generic
design based on AW reference.

(No OLinuXino A64 schematics on hand)

>
>Cheers,
>Andre.
>
>>>>
>>>> to the &usb_otg node fixes this -- the above messages go away and
>>> both
>>>> ports work as expected.
>>>>
>>>> -mato
>>>>

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

Hi,

On 06/07/18 16:50, Icenowy Zheng wrote:
> 
> 
> ? 2018?7?6? GMT+08:00 ??11:46:08, Andre Przywara <andre.przywara@arm.com> ??:
>> Hi,
>>
>> On 06/07/18 16:36, Icenowy Zheng wrote:
>>>
>>>
>>> ? 2018?7?6? GMT+08:00 ??11:35:38, Andre Przywara
>> <andre.przywara@arm.com> ??:
>>>> Hi,
>>>>
>>>> On 06/07/18 16:04, Martin Lucina wrote:
>>>>> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
>>>>>> The Olinuxino has two USB socket:
>>>>>> USB0 is connected to a micro B socket. As it has the ID pin wired,
>>>> we
>>>>>> describe it as a proper OTG socket, which switches between host
>> and
>>>>>> device automatically.
>>>>>> USB1 is connected to a normal USB A socket. PG9 enables the power
>>>> line,
>>>>>> so add the required regulator as well.
>>>>>>
>>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>>> ---
>>>>>
>>>>> This is not sufficient. Booting with this change results in the
>>>> following
>>>>> in dmesg:
>>>>>
>>>>> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
>>>>> musb-sunxi: probe of 1c19000.usb failed with error -22
>>>>> [...]
>>>>> usb0-vbus: disabling
>>>>>
>>>>> ... and neither of the USB ports work.
>>>>>
>>>>> Adding
>>>>>
>>>>>     dr_mode = "host";
>>>>
>>>> Argh, right, I remember you mentioned this before.
>>>> Still it should not affect the other USB port, and actually it is a
>>>> proper OTG port, so host is not right here. So this points to some
>>>> other
>>>> oddity or incorrect description. I need to go back to the schematics
>>>> and
>>>> our previous thread.
>>>
>>> OTG needs dr_mode = "otg"; and a ID pin.
>>
>> Yes, and we have the ID pin in the usbphy node.
>> Martin, can you please check if dr_mode = "otg"; works for you?
>>
>> Icenowy: still, how does it affect USB1? I mean, even if MUSB does not
>> initialise, it should leave the other host controller working? Is that
>> related to them sharing the usbphy? And this one gives up and tears
>> *everything* down, including the power for USB1?
> 
> You wrongly bound the regulator to USB0, not USB1.

Oh dear ...

> USB0 regulator should be AXP's drivevbus if it's OTG in generic
> design based on AW reference.

Yes, it is.
So, like this?

--------------
	reg_usb0_vbus: usb0-vbus { ....
		(unchanged)
	};
};
....
&reg_drivevbus {
	regulator-name = "usb0-vbus";
	status = "okay";
};

&usb_otg {
	dr_mode = "otg";
	status = "okay";
};

&usbphy {
	usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
	usb0_vbus-supply = <&reg_drivevbus>;
	usb1_vbus-supply = <&reg_usb0_vbus>;
};
--------------

Martin, can you please give this a try? (It's PH9, not PH6 as in the
original patch).

Cheers,
Andre.

> (No OLinuXino A64 schematics on hand)
> 
>>
>> Cheers,
>> Andre.
>>
>>>>>
>>>>> to the &usb_otg node fixes this -- the above messages go away and
>>>> both
>>>>> ports work as expected.
>>>>>
>>>>> -mato
>>>>>

[PATCH 09/10] arm64: dts: allwinner: a64: NanoPi-A64: Add Wifi/Bluetooth chip

[Sergey Suloev]

On 07/06/2018 05:49 PM, Andre Przywara wrote:
> Hi,
>
> On 06/07/18 15:23, Sergey Suloev wrote:
>> On 07/06/2018 11:52 AM, Andre Przywara wrote:
>>> The NanoPi-A64 has an on-board WiFi/Bluetooth combo chip, connected
>>> to the usual MMC1 and UART1. The power is provided by the always-on
>>> VCC_SYS_3.3V, but it uses pin L2 to enable the regulator.
>>>
>>> Add the respective nodes to the DT to make it usable.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>>  ? .../boot/dts/allwinner/sun50i-a64-nanopi-a64.dts?? | 33
>>> ++++++++++++++++++++++
>>>  ? 1 file changed, 33 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> index 0439cff685d6..bb3ba7709dee 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-nanopi-a64.dts
>>> @@ -53,11 +53,18 @@
>>>  ????? aliases {
>>>  ????????? ethernet0 = &emac;
>>>  ????????? serial0 = &uart0;
>>> +??????? serial1 = &uart1;
>>>  ????? };
>>>  ? ????? chosen {
>>>  ????????? stdout-path = "serial0:115200n8";
>>>  ????? };
>>> +
>>> +??????? wifi_pwrseq: wifi_pwrseq {
>>> +??????????????? compatible = "mmc-pwrseq-simple";
>>> +??????????????? reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
>>> +??????? };
>>> +
>>>  ? };
>>>  ? ? &ehci0 {
>>> @@ -105,6 +112,25 @@
>>>  ????? status = "okay";
>>>  ? };
>>>  ? +&mmc1 {
>>> +??? pinctrl-names = "default";
>>> +??? pinctrl-0 = <&mmc1_pins>;
>>> +??? vmmc-supply = <&reg_dcdc1>;
>>> +??? vqmmc-supply = <&reg_dldo4>;
>>> +??? mmc-pwrseq = <&wifi_pwrseq>;
>>> +??? bus-width = <4>;
>>> +??? non-removable;
>>> +??? status = "okay";
>>> +
>>> +??? brcmf: wifi at 1 {
>>> +??????? reg = <1>;
>>> +??????? compatible = "brcm,bcm4329-fmac";
>>> +??????? interrupt-parent = <&r_pio>;
>>> +??????? interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
>>> +??????? interrupt-names = "host-wake";
>>> +??? };
>>> +};
>>> +
>> NanoPi A64 has rtl8189 Ethernet chip.
> Good point, thanks for mentioning it (though I guess you mean WiFi chip).
> Do you have the board? Do you have WiFi working?
>  From a very brief look over the tree I don't see any explicit driver for
> an SDIO based 8189 variant, but other boards claiming to have a 8189
> seem to just not provide a compatible at all. Does that actually work?
> It would be great if you could share some insight here!
>
> Thanks!
> Andre.
>
>>>  ? &ohci0 {
>>>  ????? status = "okay";
>>>  ? };
>>> @@ -229,6 +255,13 @@
>>>  ????? status = "okay";
>>>  ? };
>>>  ? +/* Connected to the Bluetooth UART, with hardware handshake pins */
>>> +&uart1 {
>>> +??? pinctrl-names = "default";
>>> +??? pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
>>> +??? status = "okay";
>>> +};
>>> +
>>>  ? &usbphy {
>>>  ????? status = "okay";
>>>  ? };
>>
>>
yes, I meant WiFi of course.

I am using the following driver 
https://github.com/jwrdegoede/rtl8189ES_linux.git, branch master

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Martin Lucina]

Hi,

On Friday, 06.07.2018 at?17:17, Andre Przywara wrote:
> Hi,
> 
> On 06/07/18 16:50, Icenowy Zheng wrote:
> > 
> > 
> > ? 2018?7?6? GMT+08:00 ??11:46:08, Andre Przywara <andre.przywara@arm.com> ??:
> >> Hi,
> >>
> >> On 06/07/18 16:36, Icenowy Zheng wrote:
> >>>
> >>>
> >>> ? 2018?7?6? GMT+08:00 ??11:35:38, Andre Przywara
> >> <andre.przywara@arm.com> ??:
> >>>> Hi,
> >>>>
> >>>> On 06/07/18 16:04, Martin Lucina wrote:
> >>>>> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
> >>>>>> The Olinuxino has two USB socket:
> >>>>>> USB0 is connected to a micro B socket. As it has the ID pin wired,
> >>>> we
> >>>>>> describe it as a proper OTG socket, which switches between host
> >> and
> >>>>>> device automatically.
> >>>>>> USB1 is connected to a normal USB A socket. PG9 enables the power
> >>>> line,
> >>>>>> so add the required regulator as well.
> >>>>>>
> >>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >>>>>> ---
> >>>>>
> >>>>> This is not sufficient. Booting with this change results in the
> >>>> following
> >>>>> in dmesg:
> >>>>>
> >>>>> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
> >>>>> musb-sunxi: probe of 1c19000.usb failed with error -22
> >>>>> [...]
> >>>>> usb0-vbus: disabling
> >>>>>
> >>>>> ... and neither of the USB ports work.
> >>>>>
> >>>>> Adding
> >>>>>
> >>>>>     dr_mode = "host";
> >>>>
> >>>> Argh, right, I remember you mentioned this before.
> >>>> Still it should not affect the other USB port, and actually it is a
> >>>> proper OTG port, so host is not right here. So this points to some
> >>>> other
> >>>> oddity or incorrect description. I need to go back to the schematics
> >>>> and
> >>>> our previous thread.
> >>>
> >>> OTG needs dr_mode = "otg"; and a ID pin.
> >>
> >> Yes, and we have the ID pin in the usbphy node.
> >> Martin, can you please check if dr_mode = "otg"; works for you?
> >>
> >> Icenowy: still, how does it affect USB1? I mean, even if MUSB does not
> >> initialise, it should leave the other host controller working? Is that
> >> related to them sharing the usbphy? And this one gives up and tears
> >> *everything* down, including the power for USB1?
> > 
> > You wrongly bound the regulator to USB0, not USB1.
> 
> Oh dear ...
> 
> > USB0 regulator should be AXP's drivevbus if it's OTG in generic
> > design based on AW reference.
> 
> Yes, it is.
> So, like this?
> 
> --------------
> 	reg_usb0_vbus: usb0-vbus { ....
> 		(unchanged)
> 	};
> };
> ....
> &reg_drivevbus {
> 	regulator-name = "usb0-vbus";
> 	status = "okay";
> };
> 
> &usb_otg {
> 	dr_mode = "otg";
> 	status = "okay";
> };
> 
> &usbphy {
> 	usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
> 	usb0_vbus-supply = <&reg_drivevbus>;
> 	usb1_vbus-supply = <&reg_usb0_vbus>;
> };
> --------------
> 
> Martin, can you please give this a try? (It's PH9, not PH6 as in the
> original patch).

I presume you mean all the above changes. This does not work, I see no USB
busses apart from the kernel's internal ones:

Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

and dmesg mentions "usb0-vbus: disabling", but no other complaints I can
see.

For completeness, with your original patch, I have the following "lsusb"
output (but non-working both ports):

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

With the addition of "dr_mode = "host"", I have the following (and working
ports):

Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Cheers,

Martin

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

Hi,

On 09/07/18 11:15, Martin Lucina wrote:
> Hi,
> 
> On Friday, 06.07.2018 at?17:17, Andre Przywara wrote:
>> Hi,
>>
>> On 06/07/18 16:50, Icenowy Zheng wrote:
>>>
>>>
>>> ? 2018?7?6? GMT+08:00 ??11:46:08, Andre Przywara <andre.przywara@arm.com> ??:
>>>> Hi,
>>>>
>>>> On 06/07/18 16:36, Icenowy Zheng wrote:
>>>>>
>>>>>
>>>>> ? 2018?7?6? GMT+08:00 ??11:35:38, Andre Przywara
>>>> <andre.przywara@arm.com> ??:
>>>>>> Hi,
>>>>>>
>>>>>> On 06/07/18 16:04, Martin Lucina wrote:
>>>>>>> On Friday, 06.07.2018 at?09:52, Andre Przywara wrote:
>>>>>>>> The Olinuxino has two USB socket:
>>>>>>>> USB0 is connected to a micro B socket. As it has the ID pin wired,
>>>>>> we
>>>>>>>> describe it as a proper OTG socket, which switches between host
>>>> and
>>>>>>>> device automatically.
>>>>>>>> USB1 is connected to a normal USB A socket. PG9 enables the power
>>>>>> line,
>>>>>>>> so add the required regulator as well.
>>>>>>>>
>>>>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>>>>> ---
>>>>>>>
>>>>>>> This is not sufficient. Booting with this change results in the
>>>>>> following
>>>>>>> in dmesg:
>>>>>>>
>>>>>>> musb-sunxi 1c19000.usb: Invalid or missing 'dr_mode' property
>>>>>>> musb-sunxi: probe of 1c19000.usb failed with error -22
>>>>>>> [...]
>>>>>>> usb0-vbus: disabling
>>>>>>>
>>>>>>> ... and neither of the USB ports work.
>>>>>>>
>>>>>>> Adding
>>>>>>>
>>>>>>>     dr_mode = "host";
>>>>>>
>>>>>> Argh, right, I remember you mentioned this before.
>>>>>> Still it should not affect the other USB port, and actually it is a
>>>>>> proper OTG port, so host is not right here. So this points to some
>>>>>> other
>>>>>> oddity or incorrect description. I need to go back to the schematics
>>>>>> and
>>>>>> our previous thread.
>>>>>
>>>>> OTG needs dr_mode = "otg"; and a ID pin.
>>>>
>>>> Yes, and we have the ID pin in the usbphy node.
>>>> Martin, can you please check if dr_mode = "otg"; works for you?
>>>>
>>>> Icenowy: still, how does it affect USB1? I mean, even if MUSB does not
>>>> initialise, it should leave the other host controller working? Is that
>>>> related to them sharing the usbphy? And this one gives up and tears
>>>> *everything* down, including the power for USB1?
>>>
>>> You wrongly bound the regulator to USB0, not USB1.
>>
>> Oh dear ...
>>
>>> USB0 regulator should be AXP's drivevbus if it's OTG in generic
>>> design based on AW reference.
>>
>> Yes, it is.
>> So, like this?
>>
>> --------------
>> 	reg_usb0_vbus: usb0-vbus { ....
>> 		(unchanged)
>> 	};
>> };
>> ....
>> &reg_drivevbus {
>> 	regulator-name = "usb0-vbus";
>> 	status = "okay";
>> };
>>
>> &usb_otg {
>> 	dr_mode = "otg";
>> 	status = "okay";
>> };
>>
>> &usbphy {
>> 	usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
>> 	usb0_vbus-supply = <&reg_drivevbus>;
>> 	usb1_vbus-supply = <&reg_usb0_vbus>;
>> };
>> --------------
>>
>> Martin, can you please give this a try? (It's PH9, not PH6 as in the
>> original patch).
> 
> I presume you mean all the above changes. This does not work, I see no USB
> busses apart from the kernel's internal ones:

Bummer!

I just saw that I forgot: 'status = "okay";' in the usbphy node. Can you
add this and recheck?

> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> and dmesg mentions "usb0-vbus: disabling", but no other complaints I can
> see.
> 
> For completeness, with your original patch, I have the following "lsusb"
> output (but non-working both ports):
> 
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> With the addition of "dr_mode = "host"", I have the following (and working
> ports):

Well, yes, but as Icenowy pointed out, dr_mode = "host" and the original
patch are wrong and just happen to work by chance:
Adding dr_mode makes the OTG part work, which now *didn't disable* the
usb0_vbus-supply, which actually drives USB1. The actual USB0 supply was
not touched (because Linux didn't know about it in the first place). So
both ports happened to work.

Can you please try using the .dts I attached?

Cheers,
Andre.

> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> Cheers,
> 
> Martin
> 
-------------- next part --------------
/*
 * Copyright (C) 2017 Jagan Teki <jteki@openedev.com>
 *
 * This file is dual-licensed: you can use it either under the terms
 * of the GPL or the X11 license, at your option. Note that this dual
 * licensing only applies to this file, and not this project as a
 * whole.
 *
 *  a) This library is free software; you can redistribute it and/or
 *     modify it under the terms of the GNU General Public License as
 *     published by the Free Software Foundation; either version 2 of the
 *     License, or (at your option) any later version.
 *
 *     This library is distributed in the hope that it will be useful,
 *     but WITHOUT ANY WARRANTY; without even the implied warranty of
 *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *     GNU General Public License for more details.
 *
 * Or, alternatively,
 *
 *  b) Permission is hereby granted, free of charge, to any person
 *     obtaining a copy of this software and associated documentation
 *     files (the "Software"), to deal in the Software without
 *     restriction, including without limitation the rights to use,
 *     copy, modify, merge, publish, distribute, sublicense, and/or
 *     sell copies of the Software, and to permit persons to whom the
 *     Software is furnished to do so, subject to the following
 *     conditions:
 *
 *     The above copyright notice and this permission notice shall be
 *     included in all copies or substantial portions of the Software.
 *
 *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 *     OTHER DEALINGS IN THE SOFTWARE.
 */

/dts-v1/;

#include "sun50i-a64.dtsi"

#include <dt-bindings/gpio/gpio.h>

/ {
	model = "Olimex A64-Olinuxino";
	compatible = "olimex,a64-olinuxino", "allwinner,sun50i-a64";

	aliases {
		serial0 = &uart0;
	};

	chosen {
		stdout-path = "serial0:115200n8";
	};

	wifi_pwrseq: wifi_pwrseq {
		compatible = "mmc-pwrseq-simple";
		reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
	};

	reg_usb0_vbus: usb0-vbus {
		compatible = "regulator-fixed";
		regulator-name = "usb0-vbus";
		regulator-min-microvolt = <5000000>;
		regulator-max-microvolt = <5000000>;
		regulator-boot-on;
		enable-active-high;
		gpio = <&pio 6 9 GPIO_ACTIVE_HIGH>; /* PG9 */
		status = "okay";
	};
};

&ehci0 {
	status = "okay";
};

&ehci1 {
	status = "okay";
};

&emac {
	pinctrl-names = "default";
	pinctrl-0 = <&rgmii_pins>;
	phy-mode = "rgmii";
	phy-handle = <&ext_rgmii_phy>;
	phy-supply = <&reg_dcdc1>;
	status = "okay";
};

&mdio {
	ext_rgmii_phy: ethernet-phy at 1 {
		compatible = "ethernet-phy-ieee802.3-c22";
		reg = <1>;
	};
};

&mmc0 {
	pinctrl-names = "default";
	pinctrl-0 = <&mmc0_pins>;
	vmmc-supply = <&reg_dcdc1>;
	cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
	disable-wp;
	bus-width = <4>;
	status = "okay";
};

&mmc1 {
	pinctrl-names = "default";
	pinctrl-0 = <&mmc1_pins>;
	vmmc-supply = <&reg_aldo2>;
	vqmmc-supply = <&reg_dldo4>;
	mmc-pwrseq = <&wifi_pwrseq>;
	bus-width = <4>;
	non-removable;
	status = "okay";

	rtl8723bs: wifi at 1 {
		reg = <1>;
		interrupt-parent = <&r_pio>;
		interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* PL3 */
		interrupt-names = "host-wake";
	};
};

&ohci0 {
	status = "okay";
};

&ohci1 {
	status = "okay";
};

&r_rsb {
	status = "okay";

	axp803: pmic at 3a3 {
		compatible = "x-powers,axp803";
		reg = <0x3a3>;
		interrupt-parent = <&r_intc>;
		interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
	};
};

#include "axp803.dtsi"

&reg_aldo1 {
	regulator-always-on;
	regulator-min-microvolt = <2800000>;
	regulator-max-microvolt = <2800000>;
	regulator-name = "vcc-pe";
};

&reg_aldo2 {
	regulator-always-on;
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
	regulator-name = "vcc-pl";
};

&reg_aldo3 {
	regulator-always-on;
	regulator-min-microvolt = <3000000>;
	regulator-max-microvolt = <3000000>;
	regulator-name = "vcc-pll-avcc";
};

&reg_dcdc1 {
	regulator-always-on;
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
	regulator-name = "vcc-3v3";
};

&reg_dcdc2 {
	regulator-always-on;
	regulator-min-microvolt = <1040000>;
	regulator-max-microvolt = <1300000>;
	regulator-name = "vdd-cpux";
};

/*
 * DCDC3 is polyphased with DCDC2 to supply the DDR3L DRAM chips.
 * 1.36V is the closest to the nominal 1.35V that the PMIC can drive.
 */
&reg_dcdc5 {
	regulator-always-on;
	regulator-min-microvolt = <1360000>;
	regulator-max-microvolt = <1360000>;
	regulator-name = "vcc-ddr3";
};

&reg_dcdc6 {
	regulator-always-on;
	regulator-min-microvolt = <1100000>;
	regulator-max-microvolt = <1100000>;
	regulator-name = "vdd-sys";
};

&reg_dldo1 {
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
	regulator-name = "vcc-hdmi";
};

&reg_dldo2 {
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
	regulator-name = "vcc-mipi";
};

&reg_dldo3 {
	regulator-min-microvolt = <2800000>;
	regulator-max-microvolt = <2800000>;
	regulator-name = "vcc-avdd-csi";
};

&reg_dldo4 {
	regulator-min-microvolt = <3300000>;
	regulator-max-microvolt = <3300000>;
	regulator-name = "vcc-wifi-io";
};

&reg_drivevbus {
	regulator-name = "usb0-vbus";
	status = "okay";
};

&reg_eldo1 {
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "cpvdd";
};

&reg_eldo2 {
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
	regulator-name = "vcc-dvdd-csi";
};

&reg_fldo1 {
	regulator-min-microvolt = <1200000>;
	regulator-max-microvolt = <1200000>;
	regulator-name = "vcc-1v2-hsic";
};

/*
 * The A64 chip cannot work without this regulator off, although
 * it seems to be only driving the AR100 core.
 * Maybe we don't still know well about CPUs domain.
 */
&reg_fldo2 {
	regulator-always-on;
	regulator-min-microvolt = <1100000>;
	regulator-max-microvolt = <1100000>;
	regulator-name = "vdd-cpus";
};

&reg_rtc_ldo {
	regulator-name = "vcc-rtc";
};

&simplefb_hdmi {
	vcc-hdmi-supply = <&reg_dldo1>;
};

&uart0 {
	pinctrl-names = "default";
	pinctrl-0 = <&uart0_pins_a>;
	status = "okay";
};

&usb_otg {
	dr_mode = "otg";
	status = "okay";
};

&usbphy {
	status = "okay";
	usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
	usb0_vbus-supply = <&reg_drivevbus>;
	usb1_vbus-supply = <&reg_usb0_vbus>;
};

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Martin Lucina]

Hi,

On Monday, 09.07.2018 at?12:30, Andre Przywara wrote:
> >>> You wrongly bound the regulator to USB0, not USB1.
> >>
> >> Oh dear ...
> >>
> >>> USB0 regulator should be AXP's drivevbus if it's OTG in generic
> >>> design based on AW reference.
> >>
> >> Yes, it is.
> >> So, like this?
> >>
> >> --------------
> >> 	reg_usb0_vbus: usb0-vbus { ....
> >> 		(unchanged)
> >> 	};
> >> };
> >> ....
> >> &reg_drivevbus {
> >> 	regulator-name = "usb0-vbus";
> >> 	status = "okay";
> >> };
> >>
> >> &usb_otg {
> >> 	dr_mode = "otg";
> >> 	status = "okay";
> >> };
> >>
> >> &usbphy {
> >> 	usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
> >> 	usb0_vbus-supply = <&reg_drivevbus>;
> >> 	usb1_vbus-supply = <&reg_usb0_vbus>;
> >> };
> >> --------------
> >>
> >> Martin, can you please give this a try? (It's PH9, not PH6 as in the
> >> original patch).
> > 
> > I presume you mean all the above changes. This does not work, I see no USB
> > busses apart from the kernel's internal ones:
> 
> Bummer!
> 
> I just saw that I forgot: 'status = "okay";' in the usbphy node. Can you
> add this and recheck?
> 
> > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > 
> > and dmesg mentions "usb0-vbus: disabling", but no other complaints I can
> > see.
> > 
> > For completeness, with your original patch, I have the following "lsusb"
> > output (but non-working both ports):
> > 
> > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > 
> > With the addition of "dr_mode = "host"", I have the following (and working
> > ports):
> 
> Well, yes, but as Icenowy pointed out, dr_mode = "host" and the original
> patch are wrong and just happen to work by chance:
> Adding dr_mode makes the OTG part work, which now *didn't disable* the
> usb0_vbus-supply, which actually drives USB1. The actual USB0 supply was
> not touched (because Linux didn't know about it in the first place). So
> both ports happened to work.
> 
> Can you please try using the .dts I attached?

The .dts you attached does not compile, you've added a "&simplefb_hdmi"
node, did you mean something else?

...if I remove that node, then I get:

[    0.289065] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
...
[    1.554921] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
...
[    1.659943] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe

and no USB.

(guessing) Did you mean to add a &usb1_vbus?

Martin

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

Hi,

(sorry for keeping you busy ...)

On 09/07/18 12:54, Martin Lucina wrote:
> Hi,
> 
> On Monday, 09.07.2018 at?12:30, Andre Przywara wrote:
>>>>> You wrongly bound the regulator to USB0, not USB1.
>>>>
>>>> Oh dear ...
>>>>
>>>>> USB0 regulator should be AXP's drivevbus if it's OTG in generic
>>>>> design based on AW reference.
>>>>
>>>> Yes, it is.
>>>> So, like this?
>>>>
>>>> --------------
>>>> 	reg_usb0_vbus: usb0-vbus { ....
>>>> 		(unchanged)
>>>> 	};
>>>> };
>>>> ....
>>>> &reg_drivevbus {
>>>> 	regulator-name = "usb0-vbus";
>>>> 	status = "okay";
>>>> };
>>>>
>>>> &usb_otg {
>>>> 	dr_mode = "otg";
>>>> 	status = "okay";
>>>> };
>>>>
>>>> &usbphy {
>>>> 	usb0_id_det-gpios = <&pio 7 9 GPIO_ACTIVE_HIGH>; /* PH9 */
>>>> 	usb0_vbus-supply = <&reg_drivevbus>;
>>>> 	usb1_vbus-supply = <&reg_usb0_vbus>;
>>>> };
>>>> --------------
>>>>
>>>> Martin, can you please give this a try? (It's PH9, not PH6 as in the
>>>> original patch).
>>>
>>> I presume you mean all the above changes. This does not work, I see no USB
>>> busses apart from the kernel's internal ones:
>>
>> Bummer!
>>
>> I just saw that I forgot: 'status = "okay";' in the usbphy node. Can you
>> add this and recheck?
>>
>>> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>> and dmesg mentions "usb0-vbus: disabling", but no other complaints I can
>>> see.
>>>
>>> For completeness, with your original patch, I have the following "lsusb"
>>> output (but non-working both ports):
>>>
>>> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>> With the addition of "dr_mode = "host"", I have the following (and working
>>> ports):
>>
>> Well, yes, but as Icenowy pointed out, dr_mode = "host" and the original
>> patch are wrong and just happen to work by chance:
>> Adding dr_mode makes the OTG part work, which now *didn't disable* the
>> usb0_vbus-supply, which actually drives USB1. The actual USB0 supply was
>> not touched (because Linux didn't know about it in the first place). So
>> both ports happened to work.
>>
>> Can you please try using the .dts I attached?
> 
> The .dts you attached does not compile, you've added a "&simplefb_hdmi"
> node, did you mean something else?

Ah, right, sorry about that. That was against sunxi/dt64-for-4.19 (as
the whole series was). So the base .dtsi is different.
Attaching the .dtb this time ...

Do you have fixed regulator support in your kernel?
CONFIG_REGULATOR_FIXED_VOLTAGE=y or fixed.ko as a module.

> ...if I remove that node, then I get:
> 
> [    0.289065] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
> ...
> [    1.554921] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
> ...
> [    1.659943] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
> 
> and no USB.
> 
> (guessing) Did you mean to add a &usb1_vbus?

Well, this regulator name should indeed read usb1_vbus now. But this is
mostly about the name. Changed this anyway in the attached .dtb.

But this failure in getting the GPIO looks suspicious. Do you have uart1
enabled, by any chance? As its CTS pin is on PG9.

Cheers,
Andre.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sun50i-a64-olinuxino.dtb
Type: application/octet-stream
Size: 16607 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180709/56662a54/attachment-0001.obj>

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Martin Lucina]

Hi,

On Monday, 09.07.2018 at?14:43, Andre Przywara wrote:
> >> Can you please try using the .dts I attached?
> > 
> > The .dts you attached does not compile, you've added a "&simplefb_hdmi"
> > node, did you mean something else?
> 
> Ah, right, sorry about that. That was against sunxi/dt64-for-4.19 (as
> the whole series was). So the base .dtsi is different.
> Attaching the .dtb this time ...

Ah, where exactly is that tree? I'm still testing with Linus' v4.18-rc2,
which is probably wrong. Booting with that dtb gives me the same result re
USB.

> Do you have fixed regulator support in your kernel?
> CONFIG_REGULATOR_FIXED_VOLTAGE=y or fixed.ko as a module.

Yes.

> > ...if I remove that node, then I get:
> > 
> > [    0.289065] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
> > ...
> > [    1.554921] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
> > ...
> > [    1.659943] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
> > 
> > and no USB.
> > 
> > (guessing) Did you mean to add a &usb1_vbus?
> 
> Well, this regulator name should indeed read usb1_vbus now. But this is
> mostly about the name. Changed this anyway in the attached .dtb.
> 
> But this failure in getting the GPIO looks suspicious. Do you have uart1
> enabled, by any chance? As its CTS pin is on PG9.

Not that I know of, and looking at the schematic there's no way I can get
at that pin to test?

Martin

[linux-sunxi] Re: [PATCH 05/10] arm64: dts: allwinner: a64: Olinuxino: enable USB

[Andre Przywara]

Hi,

On 09/07/18 15:49, Martin Lucina wrote:
> Hi,
> 
> On Monday, 09.07.2018 at?14:43, Andre Przywara wrote:
>>>> Can you please try using the .dts I attached?
>>>
>>> The .dts you attached does not compile, you've added a "&simplefb_hdmi"
>>> node, did you mean something else?
>>
>> Ah, right, sorry about that. That was against sunxi/dt64-for-4.19 (as
>> the whole series was). So the base .dtsi is different.
>> Attaching the .dtb this time ...
> 
> Ah, where exactly is that tree? I'm still testing with Linus' v4.18-rc2,
> which is probably wrong. Booting with that dtb gives me the same result re
> USB.

The base is the sunxi repo on kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/log/?h=sunxi/dt64-for-4.19

I updated my working branch for a v2 here:
https://github.com/apritzel/linux/commits/a64-dt-update-v2
You might want to use that for experiments.

>> Do you have fixed regulator support in your kernel?
>> CONFIG_REGULATOR_FIXED_VOLTAGE=y or fixed.ko as a module.
> 
> Yes.
> 
>>> ...if I remove that node, then I get:
>>>
>>> [    0.289065] sun4i-usb-phy 1c19400.phy: Couldn't request ID GPIO
>>> ...
>>> [    1.554921] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
>>> ...
>>> [    1.659943] sun4i-usb-phy 1c19400.phy: Couldn't get regulator usb0_vbus... Deferring probe
>>>
>>> and no USB.
>>>
>>> (guessing) Did you mean to add a &usb1_vbus?
>>
>> Well, this regulator name should indeed read usb1_vbus now. But this is
>> mostly about the name. Changed this anyway in the attached .dtb.
>>
>> But this failure in getting the GPIO looks suspicious. Do you have uart1
>> enabled, by any chance? As its CTS pin is on PG9.
> 
> Not that I know of, and looking at the schematic there's no way I can get
> at that pin to test?

The problem is not that pin on the board, but the pinctrl's impression
of it. PG9 is RTS for UART1 (and not CTS as I wrote above). UART1 is
connected to the Bluetooth part of the RTL WiFi chip, although only CTS
is used (in addition to RX and TX). So the current DT does not do this,
but technically we would need to enable UART1, since this is hardwired.
If you now use the uart1_rts_cts_pins pinmux node for that, you will
loose PG9 to the UART and the regulator couldn't claim it. But I guess
your DT doesn't do this? At least the version I am looking at does not.

Can you please try the DT from my repo mentioned above, and then post
the full kernel log somewhere? Maybe there is some other issue?

Thanks for staying on this!

Cheers,
Andre.