[PATCH 0/9] arm64: dts: rockchip: support Google Kevin

[PATCH 0/9] arm64: dts: rockchip: support Google Kevin

[Brian Norris]

Hi,

This series adds basic support for Google Kevin, a board in the Gru device
family. I do not add a leaf .dts board file for Gru, but I have retained the
split between "things that apply to the Gru family" (rk3399-gru.dtsi) and
"things that apply to Kevin only" (rk3399-gru-kevin.dtsi).

I've included resends of two patches (adding cros-ec*.dtsi symlinks, and adding
RK3399 DWC3). The former is unmodified, but the latter is rewritten to match
current upstream bindings better, and to allow it to function w/o extcon
support (USB2 only).

AFAICT, all these bindings are in -next, except for the root node compatible
property (added doc in this series) and some of the HID digitizer bindings (see
patch 9; bindings were sent separately).

I elaborate on what's working/not working below, but one of the big missing
pieces is cpufreq support. We still need some more work on getting good
bindings and driver support upstream for the PWM regulator + OVP circuit on
these boards. See patch 8 for more info.

Working and tested (to some extent):
 * EC support -- including keyboard, battery, PWM, and probably more
 * UART / console
 * Thermal
 * Touchscreen
 * Touchpad
 * Digitizer (regulator still WIP)
 * PCIe / Wifi
 * Bluetooth / Webcam
 * SD card
 * eMMC
 * USB2 on TypeC
   - This works much of the time, but USB3 devices may or may not detect
     properly. Waiting on proper extcon support for USB3 over TypeC.
   - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed
 * Backlight

Not working:
 * CPUFreq -- relies on special OVP support for our PWM regulator
   circuits
 * EC / extcon support -- and with it, USB3/TypeC/DP
 * DRM -- won't even build on ARM64, so all display, eDP, etc. is not
   enabled

Not tested:
 * Audio


Brian Norris (8):
  arm64: dts: rockchip: add rk3399 thermal_zones phandle
  arm64: dts: rockchip: add rk3399 eDP HPD pinctrl
  arm64: dts: rockchip: support dwc3 USB for rk3399
  arm64: dts: rockchip: add rk3399 OPPs
  dt-bindings: Document rk3399 Gru/Kevin
  arm64: dts: rockchip: add Gru/Kevin DTS
  arm64: dts: rockchip: partially describe PWM regulators for Gru
  arm64: dts: rockchip: add regulator info for Kevin digitizer

Douglas Anderson (1):
  arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs

 Documentation/devicetree/bindings/arm/rockchip.txt |   20 +
 .../boot/dts/include/common/cros-ec-keyboard.dtsi  |    1 +
 .../arm64/boot/dts/include/common/cros-ec-sbs.dtsi |    1 +
 arch/arm64/boot/dts/rockchip/Makefile              |    1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts  |  315 ++++++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       | 1152 ++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi       |  145 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |   70 +-
 8 files changed, 1704 insertions(+), 1 deletion(-)
 create mode 120000 arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
 create mode 120000 arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

-- 
2.8.0.rc3.226.g39d4020

[PATCH 1/9] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs

[Brian Norris]

From: Douglas Anderson <dianders@chromium.org>

We'd like to be able to use the cros-ec-keyboard.dtsi and
cros-ec-sbs.dtsi snippets for arm64 devices.  Currently those files live
in the arm/boot/dts directory.

Let's follow the convention set by commit 8ee57b8182c4 ("ARM64: dts:
vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm") and use
a symlink.  Note that in this case we put the files in a new
"include/common" directory since these snippets may need to be
referenced by dts files in many different subdirectories.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Heiko Stueber <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
---
This was submitted months ago but had no users

 arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi | 1 +
 arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi      | 1 +
 2 files changed, 2 insertions(+)
 create mode 120000 arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
 create mode 120000 arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi

diff --git a/arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi b/arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
new file mode 120000
index 000000000000..1c1889f0a791
--- /dev/null
+++ b/arch/arm64/boot/dts/include/common/cros-ec-keyboard.dtsi
@@ -0,0 +1 @@
+../../../../../arm/boot/dts/cros-ec-keyboard.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi b/arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi
new file mode 120000
index 000000000000..3d7ae9c88bcd
--- /dev/null
+++ b/arch/arm64/boot/dts/include/common/cros-ec-sbs.dtsi
@@ -0,0 +1 @@
+../../../../../arm/boot/dts/cros-ec-sbs.dtsi
\ No newline at end of file
-- 
2.8.0.rc3.226.g39d4020

[PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle

[Brian Norris]

We're going to need to amend this table in board files.

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 66a11d1a6eac..28772f6e77f0 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -606,7 +606,7 @@
 		status = "disabled";
 	};
 
-	thermal-zones {
+	thermal_zones: thermal-zones {
 		cpu_thermal: cpu {
 			polling-delay-passive = <100>;
 			polling-delay = <1000>;
-- 
2.8.0.rc3.226.g39d4020

[PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl

[Brian Norris]

We haven't enabled eDP support yet, but we might as well describe the
pin now.

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 28772f6e77f0..4ca8f9a7601c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1435,6 +1435,13 @@
 			};
 		};
 
+		edp {
+			edp_hpd: edp-hpd {
+				rockchip,pins =
+					<4 23 RK_FUNC_2 &pcfg_pull_none>;
+			};
+		};
+
 		gmac {
 			rgmii_pins: rgmii-pins {
 				rockchip,pins =
-- 
2.8.0.rc3.226.g39d4020

[PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Brian Norris]

Add the dwc3 usb needed node information for rk3399.

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Somewhat rewritten from Caesar's reposting (v2) of my patch.

Changes:
 * Include USB2 PHY (which is now in -next)
 * Don't include USB3 PHY, as extcon support is not ready yet
 * Drop non-upstream properties
 * Fixup whitespace a bit
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60 ++++++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 4ca8f9a7601c..1e97fb8c6415 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -316,6 +316,66 @@
 		};
 	};
 
+	usbdrd3_0: usb@fe800000 {
+		compatible = "rockchip,rk3399-dwc3";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+		clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
+			      "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
+			      "aclk_usb3", "aclk_usb3_grf";
+		resets = <&cru SRST_A_USB3_OTG0>;
+		reset-names = "usb3-otg";
+		status = "disabled";
+
+		usbdrd_dwc3_0: dwc3 {
+			compatible = "snps,dwc3";
+			reg = <0x0 0xfe800000 0x0 0x100000>;
+			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
+			dr_mode = "otg";
+			phys = <&u2phy0_otg>;
+			phy-names = "usb2-phy";
+			snps,dis_enblslpm_quirk;
+			snps,dis-u2-freeclk-exists-quirk;
+			snps,dis_u2_susphy_quirk;
+			snps,dis-del-phy-power-chg-quirk;
+			status = "disabled";
+		};
+	};
+
+	usbdrd3_1: usb@fe900000 {
+		compatible = "rockchip,rk3399-dwc3";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
+			 <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
+			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
+		clock-names = "clk_usb3otg1_ref", "clk_usb3otg1_suspend",
+			      "aclk_usb3otg1", "aclk_usb3_rksoc_axi_perf",
+			      "aclk_usb3", "aclk_usb3_grf";
+		resets = <&cru SRST_A_USB3_OTG1>;
+		reset-names = "usb3-otg";
+		status = "disabled";
+
+		usbdrd_dwc3_1: dwc3 {
+			compatible = "snps,dwc3";
+			reg = <0x0 0xfe900000 0x0 0x100000>;
+			interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
+			dr_mode = "otg";
+			phys = <&u2phy1_otg>;
+			phy-names = "usb2-phy";
+			snps,dis_enblslpm_quirk;
+			snps,dis-u2-freeclk-exists-quirk;
+			snps,dis_u2_susphy_quirk;
+			snps,dis-del-phy-power-chg-quirk;
+			status = "disabled";
+		};
+	};
+
 	usb_host0_ehci: usb@fe380000 {
 		compatible = "generic-ehci";
 		reg = <0x0 0xfe380000 0x0 0x20000>;
-- 
2.8.0.rc3.226.g39d4020

[PATCH 5/9] arm64: dts: rockchip: add rk3399 OPPs

[Brian Norris]

Used for Gru/Kevin, but they should be conservative enough for all
boards. (And ideally, any board-to-board differences can be represented
via, e.g., describing regulator offsets.)

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 145 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi     |   1 +
 2 files changed, 146 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
new file mode 100644
index 000000000000..e1038cd92ce5
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -0,0 +1,145 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * 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.
+ */
+
+/ {
+	cluster0_opp: opp-table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <800000>;
+			clock-latency-ns = <40000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <800000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <925000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1050000>;
+		};
+		opp06 {
+			opp-hz = /bits/ 64 <1512000000>;
+			opp-microvolt = <1125000>;
+		};
+	};
+
+	cluster1_opp: opp-table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <800000>;
+			clock-latency-ns = <40000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <950000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000>;
+		};
+		opp06 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <1075000>;
+		};
+		opp07 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1150000>;
+		};
+		opp08 {
+			opp-hz = /bits/ 64 <2016000000>;
+			opp-microvolt = <1250000>;
+		};
+	};
+};
+
+&cpu_l0 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l1 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l2 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l3 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_b0 {
+	operating-points-v2 = <&cluster1_opp>;
+};
+
+&cpu_b1 {
+	operating-points-v2 = <&cluster1_opp>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 1e97fb8c6415..02392c084607 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1948,3 +1948,4 @@
 
 	};
 };
+#include "rk3399-opp.dtsi"
-- 
2.8.0.rc3.226.g39d4020

[PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin

[Brian Norris]

Gru is a base dev board for a family of devices, including Kevin. Both
utilize Rockchip RK3399, and they share much of their design.

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 Documentation/devicetree/bindings/arm/rockchip.txt | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index cc4ace6397ab..830e13f5890c 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
 		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
 		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
 
+- Google Gru (dev-board):
+    Required root node properties:
+      - compatible = "google,gru-rev15", "google,gru-rev14",
+		     "google,gru-rev13", "google,gru-rev12",
+		     "google,gru-rev11", "google,gru-rev10",
+		     "google,gru-rev9", "google,gru-rev8",
+		     "google,gru-rev7", "google,gru-rev6",
+		     "google,gru-rev5", "google,gru-rev4",
+		     "google,gru-rev3", "google,gru-rev2",
+		     "google,gru", "rockchip,rk3399";
+
+- Google Kevin:
+    Required root node properties:
+      - compatible = "google,kevin-rev15", "google,kevin-rev14",
+		     "google,kevin-rev13", "google,kevin-rev12",
+		     "google,kevin-rev11", "google,kevin-rev10",
+		     "google,kevin-rev9", "google,kevin-rev8",
+		     "google,kevin-rev7", "google,kevin-rev6",
+		     "google,kevin", "google,gru", "rockchip,rk3399";
+
 - mqmaker MiQi:
     Required root node properties:
       - compatible = "mqmaker,miqi", "rockchip,rk3288";
-- 
2.8.0.rc3.226.g39d4020

[PATCH 7/9] arm64: dts: rockchip: add Gru/Kevin DTS

[Brian Norris]

Kevin is part of a family of boards called Gru. As best as possible, the
properties shared by the Gru family are placed in rk3399-gru.dtsi, while
Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full
support for the base Gru board.

Working and tested (to some extent):
 * EC support -- including keyboard, battery, PWM, and probably more
 * UART / console
 * Thermal
 * Touchscreen
 * Touchpad
 * Digitizer (regulator still WIP)
 * PCIe / Wifi
 * Bluetooth / Webcam
 * SD card
 * eMMC
 * USB2 on TypeC
   - This works much of the time, but USB3 devices may or may not detect
     properly. Waiting on proper extcon support for USB3 over TypeC.
   - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed
 * Backlight

Not working:
 * CPUFreq -- relies on special OVP support for our PWM regulator
   circuits
 * EC / extcon support -- and with it, USB3/TypeC/DP
 * DRM -- won't even build on ARM64, so all display, eDP, etc. is not
   enabled

Not tested:
 * Audio

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 arch/arm64/boot/dts/rockchip/Makefile             |    1 +
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts |  312 +++++++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi      | 1006 +++++++++++++++++++++
 3 files changed, 1319 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 3a862894ea44..b82f7b61ab6f 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-gru-kevin.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
new file mode 100644
index 000000000000..66db785375a8
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -0,0 +1,312 @@
+/*
+ * Google Gru-Kevin Rev 6+ board device tree source
+ *
+ * Copyright 2016 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "rk3399-gru.dtsi"
+#include <include/dt-bindings/input/linux-event-codes.h>
+
+/*
+ * Kevin-specific things
+ *
+ * Things in this section should use names from Kevin schematic since no
+ * equivalent exists in Gru schematic.  If referring to signals that exist
+ * in Gru we use the Gru names, though.  Confusing enough for you?
+ */
+/ {
+	model = "Google Kevin";
+	compatible = "google,kevin-rev15", "google,kevin-rev14",
+		     "google,kevin-rev13", "google,kevin-rev12",
+		     "google,kevin-rev11", "google,kevin-rev10",
+		     "google,kevin-rev9", "google,kevin-rev8",
+		     "google,kevin-rev7", "google,kevin-rev6",
+		     "google,kevin", "google,gru", "rockchip,rk3399";
+
+	/* Power tree */
+
+	/* pp3300 children */
+
+	p3_3v_dig: p3-3v-dig {
+		compatible = "regulator-fixed";
+		regulator-name = "p3.3v_dig";
+		pinctrl-names = "default";
+		pinctrl-0 = <&cpu3_pen_pwr_en>;
+
+		enable-active-high;
+		gpio = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&pp3300>;
+	};
+
+	/* END REGULATORS */
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&cros_ec_pwm 1>;
+		brightness-levels = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
+				     17 18 19 20 21 22 23 24 25 26 27 28 29 30
+				     31 32 33 34 35 36 37 38 39 40 41 42 43 44
+				     45 46 47 48 49 50 51 52 53 54 55 56 57 58
+				     59 60 61 62 63 64 65 66 67 68 69 70 71 72
+				     73 74 75 76 77 78 79 80 81 82 83 84 85 86
+				     87 88 89 90 91 92 93 94 95 96 97 98 99 100>;
+		default-brightness-level = <51>;
+		enable-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+		power-supply = <&pp3300_disp>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bl_en>;
+		pwm-delay-us = <10000>;
+	};
+
+	thermistor_ppvar_bigcpu: thermistor-ppvar-bigcpu {
+		compatible = "murata,ncp15wb473";
+		pullup-uv = <1800000>;
+		pullup-ohm = <25500>;
+		pulldown-ohm = <0>;
+		io-channels = <&saradc 2>;
+		#thermal-sensor-cells = <0>;
+	};
+
+	thermistor_ppvar_litcpu: thermistor-ppvar-litcpu {
+		compatible = "murata,ncp15wb473";
+		pullup-uv = <1800000>;
+		pullup-ohm = <25500>;
+		pulldown-ohm = <0>;
+		io-channels = <&saradc 3>;
+		#thermal-sensor-cells = <0>;
+	};
+};
+
+&gpio_keys {
+	pinctrl-names = "default";
+	pinctrl-0 = <&bt_host_wake_l>, <&cpu1_pen_eject>;
+
+	pen-insert {
+		label = "Pen Insert";
+		/* Insert = low, eject = high */
+		gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+		linux,code = <SW_PEN_INSERTED>;
+		linux,input-type = <EV_SW>;
+		wakeup-source;
+	};
+};
+
+&thermal_zones {
+	bigcpu_reg_thermal: bigcpu-reg-thermal {
+		polling-delay-passive = <100>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+		thermal-sensors = <&thermistor_ppvar_bigcpu 0>;
+		sustainable-power = <4000>;
+
+		ppvar_bigcpu_trips: trips {
+			ppvar_bigcpu_on: ppvar-bigcpu-on {
+				temperature = <40000>;	/* millicelsius */
+				hysteresis = <2000>;	/* millicelsius */
+				type = "passive";
+			};
+
+			ppvar_bigcpu_alert: ppvar-bigcpu-alert {
+				temperature = <50000>;	/* millicelsius */
+				hysteresis = <2000>;	/* millicelsius */
+				type = "passive";
+			};
+
+			ppvar_bigcpu_crit: ppvar-bigcpu-crit {
+				temperature = <90000>;	/* millicelsius */
+				hysteresis = <0>;	/* millicelsius */
+				type = "critical";
+			};
+		};
+
+		cooling-maps {
+			map0 {
+				trip = <&ppvar_bigcpu_alert>;
+				cooling-device =
+					<&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				contribution = <4096>;
+			};
+			map1 {
+				trip = <&ppvar_bigcpu_alert>;
+				cooling-device =
+					<&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				contribution = <1024>;
+			};
+		};
+	};
+
+	litcpu_reg_thermal: litcpu-reg-thermal {
+		polling-delay-passive = <100>; /* milliseconds */
+		polling-delay = <1000>; /* milliseconds */
+		thermal-sensors = <&thermistor_ppvar_litcpu 0>;
+		sustainable-power = <4000>;
+
+		ppvar_litcpu_trips: trips {
+			ppvar_litcpu_on: ppvar-litcpu-on {
+				temperature = <40000>;	/* millicelsius */
+				hysteresis = <2000>;	/* millicelsius */
+				type = "passive";
+			};
+
+			ppvar_litcpu_alert: ppvar-litcpu-alert {
+				temperature = <50000>;	/* millicelsius */
+				hysteresis = <2000>;	/* millicelsius */
+				type = "passive";
+			};
+
+			ppvar_litcpu_crit: ppvar-litcpu-crit {
+				temperature = <90000>;	/* millicelsius */
+				hysteresis = <0>;	/* millicelsius */
+				type = "critical";
+			};
+		};
+	};
+};
+
+ap_i2c_tpm: &i2c0 {
+	status = "okay";
+
+	clock-frequency = <400000>;
+
+	/* These are relatively safe rise/fall times. */
+	i2c-scl-falling-time-ns = <50>;
+	i2c-scl-rising-time-ns = <300>;
+
+	tpm: tpm@20 {
+		compatible = "infineon,slb9645tt";
+		reg = <0x20>;
+		powered-while-suspended;
+	};
+};
+
+ap_i2c_dig: &i2c2 {
+	status = "okay";
+
+	clock-frequency = <400000>;
+
+	/* These are relatively safe rise/fall times. */
+	i2c-scl-falling-time-ns = <50>;
+	i2c-scl-rising-time-ns = <300>;
+
+	digitizer: digitizer@9 {
+		compatible = "hid-over-i2c";
+		reg = <0x9>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cpu1_dig_irq_l &cpu1_dig_pdct_l>;
+
+		interrupt-parent = <&gpio2>;
+		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+		hid-descr-addr = <0x1>;
+	};
+};
+
+/* Adjustments to things in the gru baseboard */
+
+&ap_i2c_tp {
+	trackpad@4a {
+		compatible = "atmel,atmel_mxt_tp";
+		reg = <0x4a>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&trackpad_int_l>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+		wakeup-source;
+	};
+};
+
+&ap_i2c_ts {
+	touchscreen@4b {
+		compatible = "atmel,atmel_mxt_ts";
+		reg = <0x4b>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&touch_int_l>;
+		interrupt-parent = <&gpio3>;
+		interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+	};
+};
+
+&saradc {
+	status = "okay";
+	vref-supply = <&pp1800_ap_io>;
+};
+
+&mvl_wifi {
+	marvell,wakeup-pin = <14>; /* GPIO_14 on Marvell */
+};
+
+/* PINCTRL: always below everything else */
+
+&pinctrl {
+	digitizer {
+		/* Has external pullup */
+		cpu1_dig_irq_l: cpu1-dig-irq-l {
+			rockchip,pins = <2 4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		/* Has external pullup */
+		cpu1_dig_pdct_l: cpu1-dig-pdct-l {
+			rockchip,pins = <2 5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	discrete-regulators {
+		cpu3_pen_pwr_en: cpu3-pen-pwr-en {
+			rockchip,pins = <4 30 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pen {
+		cpu1_pen_eject: cpu1-pen-eject {
+			rockchip,pins = <0 13 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	wifi {
+		wlan_host_wake_l: wlan-host-wake-l {
+			rockchip,pins = <0 8 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+/* DON'T PUT ANYTHING BELOW HERE.  PUT IT ABOVE PINCTRL */
+/* DON'T PUT ANYTHING BELOW HERE.  PUT IT ABOVE PINCTRL */
+/* DON'T PUT ANYTHING BELOW HERE.  PUT IT ABOVE PINCTRL */
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
new file mode 100644
index 000000000000..59b452504106
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -0,0 +1,1006 @@
+/*
+ * Google Gru (and derivatives) board device tree source
+ *
+ * Copyright 2016 Google, Inc
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This file is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/input/input.h>
+#include "rk3399.dtsi"
+
+/ {
+	chosen {
+		stdout-path = "serial2:115200n8";
+	};
+
+	/*
+	 * Power Tree
+	 *
+	 * In general an attempt is made to include all rails called out by
+	 * the schematic as long as those rails interact in some way with
+	 * the AP.  AKA:
+	 * - Rails that only connect to the EC (or devices that the EC talks to)
+	 *   are not included.
+	 * - Rails _are_ included if the rails go to the AP even if the AP
+	 *   doesn't currently care about them / they are always on.  The idea
+	 *   here is that it makes it easier to map to the schematic or extend
+	 *   later.
+	 *
+	 * If two rails are substantially the same from the AP's point of
+	 * view, though, we won't create a full fixed regulator.  We'll just
+	 * put the child rail as an alias of the parent rail.  Sometimes rails
+	 * look the same to the AP because one of these is true:
+	 * - The EC controls the enable and the EC always enables a rail as
+	 *   long as the AP is running.
+	 * - The rails are actually connected to each other by a jumper and
+	 *   the distinction is just there to add clarity/flexibility to the
+	 *   schematic.
+	 */
+
+	/* parentless regulators */
+
+	ppvar_sys: ppvar-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "ppvar_sys";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	/* ppvar_sys children, sorted by name */
+
+	pp900_ap: pp900-ap {
+		compatible = "regulator-fixed";
+		regulator-name = "pp900_ap";
+
+		/* EC turns on w/ pp900_ap_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp1200_lpddr: pp1200-lpddr {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1200_lpddr";
+
+		/* EC turns on w/ lpddr_pwr_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp1800: pp1800 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1800";
+
+		/* Always on when ppvar_sys shows power good */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3000: pp3000 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3000";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pp3000_en>;
+
+		enable-active-high;
+		gpio = <&gpio0 12 GPIO_ACTIVE_HIGH>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3000000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300: pp3300 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300";
+
+		/* Always on; plain and simple */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp5000: pp5000 {
+		compatible = "regulator-fixed";
+		regulator-name = "pp5000";
+
+		/* EC turns on w/ pp5000_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* Schematics call this PPVAR even though it's fixed */
+	ppvar_logic: ppvar-logic {
+		compatible = "regulator-fixed";
+		regulator-name = "ppvar_logic";
+
+		/* EC turns on w/ ppvar_logic_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	/* pp900_ap aliases; these are always on for AP so just use alias */
+
+	/* EC turns on w/ pp900_ddrpll_en */
+	pp900_ddrpll: pp900-ap {
+	};
+
+	/* EC turns on w/ pp900_pcie_en */
+	pp900_pcie: pp900-ap {
+	};
+
+	/* EC turns on w/ pp900_pll_en */
+	pp900_pll: pp900-ap {
+	};
+
+	/* EC turns on w/ pp900_pmu_en */
+	pp900_pmu: pp900-ap {
+	};
+
+	/* EC turns on w/ pp900_usb_en */
+	pp900_usb: pp900-ap {
+	};
+
+	/* pp1800 aliases; these are always on for AP so just use alias */
+
+	/* EC turns on w/ pp1800_s0_en_l */
+	pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 {
+	};
+
+	/* EC turns on w/ pp1800_avdd_en_l */
+	pp1800_avdd: pp1800 {
+	};
+
+	/* EC turns on w/ pp1800_lid_en_l */
+	pp1800_lid: pp1800_mic: pp1800 {
+	};
+
+	/* EC turns on w/ lpddr_pwr_en */
+	pp1800_lpddr: pp1800 {
+	};
+
+	/* EC turns on w/ pp1800_pmu_en_l */
+	pp1800_pmu: pp1800 {
+	};
+
+	/* EC turns on w/ pp1800_usb_en_l */
+	pp1800_usb: pp1800 {
+	};
+
+	/* pp1800 children */
+
+	pp1500_ap_io: pp1500-ap-io {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1500_ap_io";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pp1500_en>;
+
+		enable-active-high;
+		gpio = <&gpio0 10 GPIO_ACTIVE_HIGH>;
+
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1500000>;
+		regulator-max-microvolt = <1500000>;
+
+		vin-supply = <&pp1800>;
+	};
+
+	pp1800_audio: pp1800-audio {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1800_audio";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pp1800_audio_en>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		enable-active-high;
+		gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+
+		vin-supply = <&pp1800>;
+	};
+
+	pp1800_pcie: pp1800-pcie {
+		compatible = "regulator-fixed";
+		regulator-name = "pp1800_pcie";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wlan_module_pd_l>;
+
+		/*
+		 * Need to wait 1ms + ramp-up time before we can power on WiFi.
+		 * This has been approximated as 8ms total.
+		 */
+		regulator-enable-ramp-delay = <8000>;
+
+		enable-active-high;
+		gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+
+		vin-supply = <&pp1800>;
+	};
+
+	/*
+	 * See http://crosbug.com/p/56069/
+	 *
+	 * This is a bit of a hack. The WiFi module should be reset at least
+	 * 1ms after its regulators have ramped up (max rampup time is ~7ms).
+	 * With some stretching of the imagination, we can call the 1.8V
+	 * regulator a supply.
+	 */
+	wlan_pd_n: wlan-pd-n {
+		compatible = "regulator-fixed";
+		regulator-name = "wlan_pd_n";
+
+		/* Note the wlan_module_reset_l pinctrl */
+		enable-active-high;
+		gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+
+		vin-supply = <&pp1800_pcie>;
+	};
+
+	/* pp3000 aliases; these are always on for AP so just use alias */
+
+	/* Always on; plain and simple */
+	pp3000_ap: pp3000_emmc: pp3000 {
+	};
+
+	/* pp3000 children */
+
+	pp3000_sd_slot: pp3000-sd-slot {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3000_sd_slot";
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd_slot_pwr_en>;
+
+		enable-active-high;
+		gpio = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+
+		vin-supply = <&pp3000>;
+	};
+
+	/*
+	 * Technically, this is a small abuse of 'regulator-gpio'; this
+	 * regulator is a mux between pp1800 and pp3300. pp1800 and pp3300 are
+	 * always on though, so it is sufficient to simply control the mux
+	 * here.
+	 */
+	ppvar_sd_card_io: ppvar-sd-card-io {
+		compatible = "regulator-gpio";
+		regulator-name = "ppvar_sd_card_io";
+		pinctrl-names = "default";
+		pinctrl-0 = <&sd_io_pwr_en &sd_pwr_1800_sel>;
+
+		enable-active-high;
+		enable-gpio = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+		gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>;
+		states = <1800000 0x1
+			  3000000 0x0>;
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3000000>;
+	};
+
+	/* pp3300 aliases; these are always on for AP so just use alias */
+
+	/* EC turns on w/ pp3300_trackpad_en_l */
+	pp3300_trackpad: pp3300-trackpad {
+	};
+
+	/* EC turns on w/ pp3300_usb_en_l */
+	pp3300_usb: pp3300 {
+	};
+
+	/* pp3300 children */
+
+	pp3300_disp: pp3300-disp {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_disp";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pp3300_disp_en>;
+
+		enable-active-high;
+
+		gpio = <&gpio4 27 GPIO_ACTIVE_HIGH>;
+
+		startup-delay-us = <2000>;
+		vin-supply = <&pp3300>;
+	};
+
+	pp3300_wifi_bt: pp3300-wifi-bt {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_wifi_bt";
+		/* NOTE: wlan_module_pd_l pinctrl in pp1800_pcie */
+
+		enable-active-high;
+
+		/* NOTE: this GPIO also used in pp1800_pcie */
+		gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
+
+		vin-supply = <&pp3300>;
+	};
+
+	/* pp5000 aliases; these are always on for AP so just use alias */
+
+	/* EC turns on w/ usb_a_en */
+	pp5000_usb_a_vbus: pp5000 {
+	};
+
+	/* END REGULATORS */
+
+	io-domains {
+		compatible = "rockchip,rk3399-io-voltage-domain";
+		rockchip,grf = <&grf>;
+
+		bt656-supply = <&pp1800_ap_io>;		/* APIO2_VDD;  2a 2b */
+		audio-supply = <&pp1800_audio>;		/* APIO5_VDD;  3d 4a */
+		sdmmc-supply = <&ppvar_sd_card_io>;	/* SDMMC0_VDD; 4b    */
+		gpio1830-supply = <&pp3000_ap>;		/* APIO4_VDD;  4c 4d */
+	};
+
+	max98357a: max98357a {
+		#sound-dai-cells = <0>;
+		status = "okay";
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmode_en>;
+
+		compatible = "maxim,max98357a";
+		sdmode-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+		sdmode-delay = <2>;
+	};
+
+	pmu-io-domains {
+		compatible = "rockchip,rk3399-pmu-io-voltage-domain";
+		rockchip,grf = <&pmugrf>;
+
+		pmu1830-supply = <&pp1800_pmu>;		/* PMUIO2_VDD */
+	};
+
+	sound {
+		compatible = "rockchip,rk3399-gru-sound";
+		rockchip,cpu = <&i2s0 &i2s2>;
+		rockchip,codec = <&max98357a &headsetcodec &codec>;
+	};
+
+	gpio_keys: gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_host_wake_l>;
+
+		wake-on-bt {
+			label = "Wake-on-Bluetooth";
+			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_WAKEUP>;
+			wakeup-source;
+		};
+	};
+};
+
+&cru {
+	assigned-clocks =
+		<&cru PLL_GPLL>, <&cru PLL_CPLL>,
+		<&cru PLL_NPLL>,
+		<&cru ACLK_PERIHP>, <&cru HCLK_PERIHP>,
+		<&cru PCLK_PERIHP>,
+		<&cru ACLK_PERILP0>, <&cru HCLK_PERILP0>,
+		<&cru PCLK_PERILP0>, <&cru ACLK_CCI>,
+		<&cru HCLK_PERILP1>, <&cru PCLK_PERILP1>;
+	assigned-clock-rates =
+		<594000000>, <800000000>,
+		<1000000000>,
+		<150000000>, <75000000>,
+		<37500000>,
+		<100000000>, <100000000>,
+		<50000000>, <800000000>,
+		<100000000>, <50000000>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+ap_i2c_mic: &i2c1 {
+	status = "okay";
+
+	clock-frequency = <400000>;
+
+	/* These are relatively safe rise/fall times */
+	i2c-scl-falling-time-ns = <50>;
+	i2c-scl-rising-time-ns = <300>;
+
+	headsetcodec: rt5514@57 {
+		compatible = "realtek,rt5514";
+		reg = <0x57>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&mic_int>;
+
+		interrupt-parent = <&gpio1>;
+		interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
+
+		realtek,dmic-init-delay = <20>;
+		wakeup-source;
+	};
+};
+
+ap_i2c_ts: &i2c3 {
+	status = "okay";
+
+	clock-frequency = <400000>;
+
+	/* These are relatively safe rise/fall times */
+	i2c-scl-falling-time-ns = <50>;
+	i2c-scl-rising-time-ns = <300>;
+};
+
+ap_i2c_tp: &i2c5 {
+	status = "okay";
+
+	/*
+	 * Note strange pullup enable.  Apparently this avoids leakage but
+	 * still allows us to get nice 4.7K pullups for high speed i2c
+	 * transfers.  Basically we want the pullup on whenever the ap is
+	 * alive, so the "en" pin just gets set to output high.
+	 */
+	pinctrl-0 = <&i2c5_xfer &ap_i2c_tp_pu_en>;
+
+	clock-frequency = <400000>;
+
+	/* These are relatively safe rise/fall times */
+	i2c-scl-falling-time-ns = <50>;
+	i2c-scl-rising-time-ns = <300>;
+};
+
+ap_i2c_audio: &i2c8 {
+	status = "okay";
+
+	clock-frequency = <400000>;
+
+	/* These are relatively safe rise/fall times */
+	i2c-scl-falling-time-ns = <50>;
+	i2c-scl-rising-time-ns = <300>;
+
+	codec: da7219@1a {
+		compatible = "dlg,da7219";
+		reg = <0x1a>;
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&headset_int_l>;
+
+		interrupt-parent = <&gpio1>;
+		interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+
+		VDD-supply = <&pp1800>;
+		VDDMIC-supply = <&pp3300>;
+		VDDIO-supply = <&pp1800>;
+
+		clocks = <&cru SCLK_I2S_8CH_OUT>;
+		clock-names = "mclk";
+
+		dlg,ldo-lvl = <1200>;
+		dlg,micbias-lvl = <2600>;
+		dlg,mic-amp-in-sel = "diff";
+
+		da7219_aad {
+			dlg,btn-cfg = <50>;
+			dlg,mic-det-thr = <500>;
+			dlg,jack-ins-deb = <20>;
+			dlg,jack-det-rate = "32ms_64ms";
+			dlg,jack-rem-deb = <1>;
+
+			dlg,a-d-btn-thr = <0xa>;
+			dlg,d-b-btn-thr = <0x16>;
+			dlg,b-c-btn-thr = <0x21>;
+			dlg,c-mic-btn-thr = <0x3E>;
+
+			dlg,btn-avg = <4>;
+			dlg,adc-1bit-rpt = <1>;
+		};
+	};
+};
+
+&i2s0 {
+	status = "okay";
+};
+
+&i2s2 {
+	status = "okay";
+};
+
+&pcie0 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pcie_clkreqn_cpm>, <&wifi_perst_l>;
+	ep-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
+
+	max-link-speed = <1>;
+
+	vpcie3v3-supply = <&pp3300_wifi_bt>;
+	vpcie1v8-supply = <&wlan_pd_n>; /* HACK: see &wlan_pd_n */
+	vpcie0v9-supply = <&pp900_pcie>;
+
+	pci_rootport: pcie@0,0 {
+		reg = <0x83000000 0x0 0x00000000 0x0 0x00000000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		ranges;
+
+		mvl_wifi: wifi@0,0 {
+			compatible = "pci1b4b,2b42";
+			reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
+			       0x83010000 0x0 0x00100000 0x0 0x00100000>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&wlan_host_wake_l>;
+			interrupt-parent = <&gpio0>;
+			interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+			wakeup-source;
+		};
+	};
+};
+
+&pcie_phy {
+	status = "okay";
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm1 {
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&pwm3 {
+	status = "okay";
+};
+
+&sdhci {
+	/*
+	 * Signal integrity isn't great at 200 MHz and 150 MHz (DDR) gives the
+	 * same (or nearly the same) performance for all eMMC that are intended
+	 * to be used.
+	 */
+	assigned-clock-rates = <150000000>;
+
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&sdmmc {
+	status = "okay";
+
+	/*
+	 * Note: configure "sdmmc_cd" as card detect even though it's actually
+	 * hooked to ground.  Because we specified "cd-gpios" below dw_mmc
+	 * should be ignoring card detect anyway.  Specifying the pin as
+	 * sdmmc_cd means that even if you've got GRF_SOC_CON7[12] (force_jtag)
+	 * turned on that the system will still make sure the port is
+	 * configured as SDMMC and not JTAG.
+	 */
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_cd_gpio
+		     &sdmmc_bus4>;
+
+	bus-width = <4>;
+	cd-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>;
+	disable-wp;
+
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	sd-uhs-sdr12;
+	sd-uhs-sdr25;
+	sd-uhs-sdr50;
+	sd-uhs-sdr104;
+
+	vmmc-supply = <&pp3000_sd_slot>;
+	vqmmc-supply = <&ppvar_sd_card_io>;
+};
+
+&spi1 {
+	status = "okay";
+
+	spiflash@0 {
+		compatible = "jedec,spi-nor";
+
+		/* May run faster once verified. */
+		spi-max-frequency = <10000000>;
+		reg = <0>;
+	};
+};
+
+&spi2 {
+	status = "okay";
+
+	wacky_spi_audio: spi2@0 {
+		compatible = "realtek,rt5514";
+		reg = <0>;
+
+		/* May run faster once verified. */
+		spi-max-frequency = <10000000>;
+	};
+};
+
+&spi5 {
+	status = "okay";
+
+	cros_ec: ec@0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ec_ap_int_l>;
+
+		google,cros-ec-spi-pre-delay = <30>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+		spi-max-frequency = <3000000>;
+
+		i2c_tunnel: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			google,remote-bus = <4>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		cros_ec_pwm: ec-pwm {
+			compatible = "google,cros-ec-pwm";
+			#pwm-cells = <1>;
+		};
+	};
+};
+
+&tsadc {
+	status = "okay";
+
+	rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
+};
+
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy0_host {
+	status = "okay";
+};
+
+&u2phy1_host {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+#include "common/cros-ec-keyboard.dtsi"
+#include "common/cros-ec-sbs.dtsi"
+
+/* PINCTRL: always below everything else */
+
+&pinctrl {
+	/*
+	 * pinctrl settings for pins that have no real owners.
+	 *
+	 * At the moment settings are identical for S0 and S3, but if we later
+	 * need to configure things differently for S3 we'll adjust here.
+	 */
+	pinctrl-names = "default";
+	pinctrl-0 = <
+		&ap_pwroff	/* AP will auto-assert this when in S3 */
+		&clk_32k	/* This pin is always 32k on gru boards */
+
+		/*
+		 * We want this driven low ASAP; firmware should help us, but
+		 * we can help ourselves too.
+		 */
+		&wlan_module_reset_l
+	>;
+
+	pcfg_output_low: pcfg-output-low {
+		output-low;
+	};
+
+	pcfg_output_high: pcfg-output-high {
+		output-high;
+	};
+
+	pcfg_pull_none_8ma: pcfg-pull-none-8ma {
+		bias-disable;
+		drive-strength = <8>;
+	};
+
+	cros-ec {
+		ec_ap_int_l: ec-ap-int-l {
+			rockchip,pins = <RK_GPIO0 1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	discrete-regulators {
+		pp1500_en: pp1500-en {
+			rockchip,pins = <RK_GPIO0 10 RK_FUNC_GPIO
+					 &pcfg_pull_none>;
+		};
+
+		pp1800_audio_en: pp1800-audio-en {
+			rockchip,pins = <RK_GPIO0 2 RK_FUNC_GPIO
+					 &pcfg_pull_down>;
+		};
+
+		pp3300_disp_en: pp3300-disp-en {
+			rockchip,pins = <RK_GPIO4 27 RK_FUNC_GPIO
+					 &pcfg_pull_none>;
+		};
+
+		pp3000_en: pp3000-en {
+			rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO
+					 &pcfg_pull_none>;
+		};
+
+		sd_io_pwr_en: sd-io-pwr-en {
+			rockchip,pins = <RK_GPIO2 2 RK_FUNC_GPIO
+					 &pcfg_pull_none>;
+		};
+
+		sd_pwr_1800_sel: sd-pwr-1800-sel {
+			rockchip,pins = <RK_GPIO2 28 RK_FUNC_GPIO
+					 &pcfg_pull_none>;
+		};
+
+		sd_slot_pwr_en: sd-slot-pwr-en {
+			rockchip,pins = <RK_GPIO4 29 RK_FUNC_GPIO
+					 &pcfg_pull_none>;
+		};
+
+		wlan_module_pd_l: wlan-module-pd-l {
+			rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO
+					 &pcfg_pull_down>;
+		};
+	};
+
+	codec {
+		/* Has external pullup */
+		headset_int_l: headset-int-l {
+			rockchip,pins = <1 23 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		mic_int: mic-int {
+			rockchip,pins = <1 13 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	max98357a {
+		sdmode_en: sdmode-en {
+			rockchip,pins = <1 2 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	sdmmc {
+		/*
+		 * We run sdmmc at max speed; bump up drive strength.
+		 * We also have external pulls, so disable the internal ones.
+		 */
+		sdmmc_bus4: sdmmc-bus4 {
+			rockchip,pins =
+				<4 8 RK_FUNC_1 &pcfg_pull_none_8ma>,
+				<4 9 RK_FUNC_1 &pcfg_pull_none_8ma>,
+				<4 10 RK_FUNC_1 &pcfg_pull_none_8ma>,
+				<4 11 RK_FUNC_1 &pcfg_pull_none_8ma>;
+		};
+
+		sdmmc_clk: sdmmc-clk {
+			rockchip,pins =
+				<4 12 RK_FUNC_1 &pcfg_pull_none_8ma>;
+		};
+
+		sdmmc_cmd: sdmmc-cmd {
+			rockchip,pins =
+				<4 13 RK_FUNC_1 &pcfg_pull_none_8ma>;
+		};
+
+		/*
+		 * In our case the official card detect is hooked to ground
+		 * to avoid getting access to JTAG just by sticking something
+		 * in the SD card slot (see the force_jtag bit in the TRM).
+		 *
+		 * We still configure it as card detect because it doesn't
+		 * hurt and dw_mmc will ignore it.  We make sure to disable
+		 * the pull though so we don't burn needless power.
+		 */
+		sdmmc_cd: sdmcc-cd {
+			rockchip,pins =
+				<0 7 RK_FUNC_1 &pcfg_pull_none>;
+		};
+
+		/* This is where we actually hook up CD; has external pull */
+		sdmmc_cd_gpio: sdmmc-cd-gpio {
+			rockchip,pins = <4 24 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	trackpad {
+		ap_i2c_tp_pu_en: ap-i2c-tp-pu-en {
+			rockchip,pins = <3 12 RK_FUNC_GPIO &pcfg_output_high>;
+		};
+
+		trackpad_int_l: trackpad-int-l {
+			rockchip,pins = <1 4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	touchscreen {
+		touch_int_l: touch-int-l {
+			rockchip,pins = <3 13 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		touch_reset_l: touch-reset-l {
+			rockchip,pins = <4 26 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		wifi_perst_l: wifi-perst-l {
+			rockchip,pins = <2 27 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wlan_module_reset_l: wlan-module-reset-l {
+			/*
+			 * We want this driven low ASAP (As {Soon,Strongly} As
+			 * Possible), to avoid leakage through the powered-down
+			 * WiFi.
+			 */
+			rockchip,pins = <1 11 RK_FUNC_GPIO &pcfg_output_low>;
+		};
+
+		bt_host_wake_l: bt-host-wake-l {
+			/* Kevin has an external pull up, but Gru does not */
+			rockchip,pins = <0 3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	backlight-enable {
+		bl_en: bl-en {
+			rockchip,pins = <1 17 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	write-protect {
+		ap_fw_wp: ap-fw-wp {
+			rockchip,pins = <1 18 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	pcie {
+		pcie_clkreqn_cpm: pci-clkreqn-cpm {
+			/*
+			 * Since our pcie doesn't support ClockPM(CPM), we want
+			 * to hack this as gpio, so the EP could be able to
+			 * de-assert it along and make ClockPM(CPM) work.
+			 */
+			rockchip,pins = <2 26 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+/* DON'T PUT ANYTHING BELOW HERE.  PUT IT ABOVE PINCTRL */
+/* DON'T PUT ANYTHING BELOW HERE.  PUT IT ABOVE PINCTRL */
+/* DON'T PUT ANYTHING BELOW HERE.  PUT IT ABOVE PINCTRL */
+
-- 
2.8.0.rc3.226.g39d4020

[PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

[Brian Norris]

We need to add regulators to the CPU nodes, so cpufreq doesn't think it
can crank up the clock speed without changing the voltage. However, we
don't yet have the DT bindings to fully describe the Over Voltage
Protection (OVP) circuits on these boards. Without that description, we
might end up changing the voltage too much, too fast.

Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
them disabled.

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 146 +++++++++++++++++++++++++++
 1 file changed, 146 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 59b452504106..90adfb5cba38 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -172,6 +172,98 @@
 		vin-supply = <&ppvar_sys>;
 	};
 
+	ppvar_bigcpu: ppvar-bigcpu {
+		compatible = "pwm-regulator";
+		regulator-name = "ppvar_bigcpu";
+		/*
+		 * OVP circuit requires special handling which is not yet
+		 * represented. Keep disabled for now.
+		 */
+		status = "disabled";
+
+		pwms = <&pwm1 0 3337 0>;
+
+		/* EC turns on w/ ap_core_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <798674>;
+		regulator-max-microvolt = <1302172>;
+
+		pwm-supply = <&ppvar_sys>;
+		pwm-dutycycle-range = <100 0>;
+		pwm-dutycycle-unit = <100>;
+	};
+
+	ppvar_litcpu: ppvar-litcpu {
+		compatible = "pwm-regulator";
+		regulator-name = "ppvar_litcpu";
+		/*
+		 * OVP circuit requires special handling which is not yet
+		 * represented. Keep disabled for now.
+		 */
+		status = "disabled";
+
+		pwms = <&pwm2 0 3337 0>;
+
+		/* EC turns on w/ ap_core_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <799065>;
+		regulator-max-microvolt = <1303738>;
+
+		pwm-supply = <&ppvar_sys>;
+		pwm-dutycycle-range = <100 0>;
+		pwm-dutycycle-unit = <100>;
+	};
+
+	ppvar_gpu: ppvar-gpu {
+		compatible = "pwm-regulator";
+		regulator-name = "ppvar_gpu";
+		/*
+		 * OVP circuit requires special handling which is not yet
+		 * represented. Keep disabled for now.
+		 */
+		status = "disabled";
+
+		pwms = <&pwm0 0 3337 0>;
+
+		/* EC turns on w/ ap_core_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <785782>;
+		regulator-max-microvolt = <1217729>;
+
+		pwm-supply = <&ppvar_sys>;
+		pwm-dutycycle-range = <100 0>;
+		pwm-dutycycle-unit = <100>;
+	};
+
+	ppvar_centerlogic: ppvar-centerlogic {
+		compatible = "pwm-regulator";
+		regulator-name = "ppvar_centerlogic";
+		/*
+		 * OVP circuit requires special handling which is not yet
+		 * represented. Keep disabled for now.
+		 */
+		status = "disabled";
+
+		pwms = <&pwm3 0 3337 0>;
+
+		/* EC turns on w/ ppvar_centerlogic_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		regulator-min-microvolt = <800069>;
+		regulator-max-microvolt = <1049692>;
+
+		pwm-supply = <&ppvar_sys>;
+		pwm-dutycycle-range = <100 0>;
+		pwm-dutycycle-unit = <100>;
+	};
+
 	/* Schematics call this PPVAR even though it's fixed */
 	ppvar_logic: ppvar-logic {
 		compatible = "regulator-fixed";
@@ -444,6 +536,60 @@
 	};
 };
 
+/*
+ * Set some suspend operating points to avoid OVP in suspend
+ *
+ * When we go into S3 ARM Trusted Firmware will transition our PWM regulators
+ * from wherever they're at back to the "default" operating point (whatever
+ * voltage we get when we set the PWM pins to "input").
+ *
+ * This quick transition under light load has the possibility to trigger the
+ * regulator "over voltage protection" (OVP).
+ *
+ * To make extra certain that we don't hit this OVP at suspend time, we'll
+ * transition to a voltage that's much closer to the default (~1.0 V) so that
+ * there will not be a big jump.  Technically we only need to get within 200 mV
+ * of the default voltage, but the speed here should be fast enough and we need
+ * suspend/resume to be rock solid.
+ */
+
+&cluster0_opp {
+	opp05 {
+		opp-suspend;
+	};
+};
+
+&cluster1_opp {
+	opp06 {
+		opp-suspend;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&ppvar_litcpu>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&ppvar_litcpu>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&ppvar_litcpu>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&ppvar_litcpu>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&ppvar_bigcpu>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&ppvar_bigcpu>;
+};
+
+
 &cru {
 	assigned-clocks =
 		<&cru PLL_GPLL>, <&cru PLL_CPLL>,
-- 
2.8.0.rc3.226.g39d4020

[PATCH 9/9] arm64: dts: rockchip: add regulator info for Kevin digitizer

[Brian Norris]

We need to enable this regulator before the digitizer can be used. Wacom
recommended waiting for 100 ms before talking to the HID.

Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Uses WIP bindings:

[PATCH v3 1/2] devicetree: i2c-hid: Add regulator support
https://patchwork.kernel.org/patch/9457493/
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
index 66db785375a8..d260079de2ab 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
@@ -232,6 +232,9 @@ ap_i2c_dig: &i2c2 {
 		pinctrl-names = "default";
 		pinctrl-0 = <&cpu1_dig_irq_l &cpu1_dig_pdct_l>;
 
+		vdd-supply = <&p3_3v_dig>;
+		init-delay-ms = <100>;
+
 		interrupt-parent = <&gpio2>;
 		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
 
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

[Heiko Stuebner]

Hi Brian,

Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> We need to add regulators to the CPU nodes, so cpufreq doesn't think it
> can crank up the clock speed without changing the voltage. However, we
> don't yet have the DT bindings to fully describe the Over Voltage
> Protection (OVP) circuits on these boards. Without that description, we
> might end up changing the voltage too much, too fast.
> 
> Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
> them disabled.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>

is there a specific reason for keeping this change separate?
While it is nice for documentation reasons, as it stands now the previous 
patch introduces a regression (cpufreq trying to scale without regulators) and 
immediately fixes it here.

So if you're ok with it, I'd like to merge this one back into the previous 
patch when applying.


Heiko

Re: [PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle

[Heiko Stuebner]

Am Donnerstag, 1. Dezember 2016, 18:27:26 CET schrieb Brian Norris:
> We're going to need to amend this table in board files.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>

applied for 4.11

Thanks
Heiko

Re: [PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl

[Heiko Stuebner]

Am Donnerstag, 1. Dezember 2016, 18:27:27 CET schrieb Brian Norris:
> We haven't enabled eDP support yet, but we might as well describe the
> pin now.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>

applied for 4.11

Thanks
Heiko

Re: [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Heiko Stuebner]

Hi Brian,

Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
> Add the dwc3 usb needed node information for rk3399.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Somewhat rewritten from Caesar's reposting (v2) of my patch.
> 
> Changes:
>  * Include USB2 PHY (which is now in -next)
>  * Don't include USB3 PHY, as extcon support is not ready yet
>  * Drop non-upstream properties
>  * Fixup whitespace a bit
> ---
>  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
> ++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 4ca8f9a7601c..1e97fb8c6415
> 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -316,6 +316,66 @@
>  		};
>  	};
> 
> +	usbdrd3_0: usb@fe800000 {

insert location above usb@fe380000 is sorted wrong

> +		compatible = "rockchip,rk3399-dwc3";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +		clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
> +			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
> +			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
> +		clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
> +			      "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
> +			      "aclk_usb3", "aclk_usb3_grf";

clock-names do not match binding. The dwc3-of-simple does not care, as it just 
enables all of them it seems, but binding doc states the clock names as

- clock-names:  Should contain the following:
  "ref_clk"     Controller reference clk, have to be 24 MHz
  "suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
  "bus_clk"     Master/Core clock, have to be >= 62.5 MHz for SS
                operation and >= 30MHz for HS operation
  "grf_clk"     Controller grf clk

> +		resets = <&cru SRST_A_USB3_OTG0>;
> +		reset-names = "usb3-otg";

you could update the binding documentation to list this one.


Heiko

> +		status = "disabled";
> +
> +		usbdrd_dwc3_0: dwc3 {
> +			compatible = "snps,dwc3";
> +			reg = <0x0 0xfe800000 0x0 0x100000>;
> +			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
> +			dr_mode = "otg";
> +			phys = <&u2phy0_otg>;
> +			phy-names = "usb2-phy";
> +			snps,dis_enblslpm_quirk;
> +			snps,dis-u2-freeclk-exists-quirk;
> +			snps,dis_u2_susphy_quirk;
> +			snps,dis-del-phy-power-chg-quirk;
> +			status = "disabled";
> +		};
> +	};
> +
> +	usbdrd3_1: usb@fe900000 {
> +		compatible = "rockchip,rk3399-dwc3";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +		clocks = <&cru SCLK_USB3OTG1_REF>, <&cru SCLK_USB3OTG1_SUSPEND>,
> +			 <&cru ACLK_USB3OTG1>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
> +			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
> +		clock-names = "clk_usb3otg1_ref", "clk_usb3otg1_suspend",
> +			      "aclk_usb3otg1", "aclk_usb3_rksoc_axi_perf",
> +			      "aclk_usb3", "aclk_usb3_grf";
> +		resets = <&cru SRST_A_USB3_OTG1>;
> +		reset-names = "usb3-otg";
> +		status = "disabled";
> +
> +		usbdrd_dwc3_1: dwc3 {
> +			compatible = "snps,dwc3";
> +			reg = <0x0 0xfe900000 0x0 0x100000>;
> +			interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>;
> +			dr_mode = "otg";
> +			phys = <&u2phy1_otg>;
> +			phy-names = "usb2-phy";
> +			snps,dis_enblslpm_quirk;
> +			snps,dis-u2-freeclk-exists-quirk;
> +			snps,dis_u2_susphy_quirk;
> +			snps,dis-del-phy-power-chg-quirk;
> +			status = "disabled";
> +		};
> +	};
> +
>  	usb_host0_ehci: usb@fe380000 {
>  		compatible = "generic-ehci";
>  		reg = <0x0 0xfe380000 0x0 0x20000>;

Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

[Brian Norris]

Hi Heiko,

On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
> Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> > We need to add regulators to the CPU nodes, so cpufreq doesn't think it
> > can crank up the clock speed without changing the voltage. However, we
> > don't yet have the DT bindings to fully describe the Over Voltage
> > Protection (OVP) circuits on these boards. Without that description, we
> > might end up changing the voltage too much, too fast.
> > 
> > Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
> > them disabled.
> > 
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> 
> is there a specific reason for keeping this change separate?

Maybe not a great one. I figured they were somewhat controversial, so I
at least wanted to split the "cpufreq patches" (i.e., this and the
previous) from the main DTS(I) additions. I also figured we typically
like to keep the base SoC changes separate from the board DTS(I)
changes.

> While it is nice for documentation reasons, as it stands now the previous 
> patch introduces a regression (cpufreq trying to scale without regulators) and 
> immediately fixes it here.

Right. Additionally, as noted on the previous patch, we might do the
same with EVB. But I don't know what the regulators are like for EVB.
This is probably a bigger deal, since EVB has been working (allegedly)
upstream for a while now.

There's no way to split these up without either breaking compilation or
breaking bisectability. For Kevin/Gru, they don't function at all before
this series, so I figured some "settle" time wasn't a huge deal.

> So if you're ok with it, I'd like to merge this one back into the previous 
> patch when applying.

That'd be OK with me, as long as we're also confident about EVB.

Maybe at a minimum, I should just patch in some empty regulator nodes,
so cpufreq doesn't think there's no need to handle voltage.

Brian

Re: [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin

[Heiko Stuebner]

Hi Brian,

Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
> Gru is a base dev board for a family of devices, including Kevin. Both
> utilize Rockchip RK3399, and they share much of their design.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>  Documentation/devicetree/bindings/arm/rockchip.txt | 20
> ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> b/Documentation/devicetree/bindings/arm/rockchip.txt index
> cc4ace6397ab..830e13f5890c 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
>  		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
>  		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> 
> +- Google Gru (dev-board):

boards sorted alphabetically please

Brian, Gru, Jaq, ... Kevin, ...

While the sorting of old boards is not right yet, new boards should be sorted.


Thanks
Heiko

> +    Required root node properties:
> +      - compatible = "google,gru-rev15", "google,gru-rev14",
> +		     "google,gru-rev13", "google,gru-rev12",
> +		     "google,gru-rev11", "google,gru-rev10",
> +		     "google,gru-rev9", "google,gru-rev8",
> +		     "google,gru-rev7", "google,gru-rev6",
> +		     "google,gru-rev5", "google,gru-rev4",
> +		     "google,gru-rev3", "google,gru-rev2",
> +		     "google,gru", "rockchip,rk3399";
> +
> +- Google Kevin:
> +    Required root node properties:
> +      - compatible = "google,kevin-rev15", "google,kevin-rev14",
> +		     "google,kevin-rev13", "google,kevin-rev12",
> +		     "google,kevin-rev11", "google,kevin-rev10",
> +		     "google,kevin-rev9", "google,kevin-rev8",
> +		     "google,kevin-rev7", "google,kevin-rev6",
> +		     "google,kevin", "google,gru", "rockchip,rk3399";
> +
>  - mqmaker MiQi:
>      Required root node properties:
>        - compatible = "mqmaker,miqi", "rockchip,rk3288";

Re: [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin

[Brian Norris]

On Wed, Dec 07, 2016 at 06:12:13PM +0100, Heiko Stuebner wrote:
> Hi Brian,
> 
> Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
> > Gru is a base dev board for a family of devices, including Kevin. Both
> > utilize Rockchip RK3399, and they share much of their design.
> > 
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> >  Documentation/devicetree/bindings/arm/rockchip.txt | 20
> > ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > cc4ace6397ab..830e13f5890c 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> >  		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> >  		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> > 
> > +- Google Gru (dev-board):
> 
> boards sorted alphabetically please
> 
> Brian, Gru, Jaq, ... Kevin, ...
> 
> While the sorting of old boards is not right yet, new boards should be sorted.

I got the idea that there was some attempt to group logically before
alphabetically. Like keeping board/SoC families together. But maybe not.

I can do as you suggested, if you don't care about keeping actual
similar boards together (i.e., veyron/3288 vs gru/3399).

Brian

Re: [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Brian Norris]

Hi,

On Wed, Dec 07, 2016 at 06:09:16PM +0100, Heiko Stuebner wrote:
> Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
> > Add the dwc3 usb needed node information for rk3399.
> > 
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> > Somewhat rewritten from Caesar's reposting (v2) of my patch.
> > 
> > Changes:
> >  * Include USB2 PHY (which is now in -next)
> >  * Don't include USB3 PHY, as extcon support is not ready yet
> >  * Drop non-upstream properties
> >  * Fixup whitespace a bit
> > ---
> >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
> > ++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index 4ca8f9a7601c..1e97fb8c6415
> > 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > @@ -316,6 +316,66 @@
> >  		};
> >  	};
> > 
> > +	usbdrd3_0: usb@fe800000 {
> 
> insert location above usb@fe380000 is sorted wrong

So, *how* do you think things are sorted here? Alphabetical by label? Or
by node name? Or by unit address? I guess I'm seeing you meant unit
address. But pcie@f8000000 is also out of order then. I guess maybe
that's the only one then.

> > +		compatible = "rockchip,rk3399-dwc3";
> > +		#address-cells = <2>;
> > +		#size-cells = <2>;
> > +		ranges;
> > +		clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
> > +			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
> > +			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
> > +		clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
> > +			      "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
> > +			      "aclk_usb3", "aclk_usb3_grf";
> 
> clock-names do not match binding. The dwc3-of-simple does not care, as it just 
> enables all of them it seems, but binding doc states the clock names as
> 
> - clock-names:  Should contain the following:
>   "ref_clk"     Controller reference clk, have to be 24 MHz
>   "suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
>   "bus_clk"     Master/Core clock, have to be >= 62.5 MHz for SS
>                 operation and >= 30MHz for HS operation
>   "grf_clk"     Controller grf clk

Ah, sorry. I'll try to go with the rockchip,dwc3.txt names better.

There are a few extra clocks here now, but I think those might only be
for USB3 support, which isn't really working yet. I'll either document
them or drop them.

> > +		resets = <&cru SRST_A_USB3_OTG0>;
> > +		reset-names = "usb3-otg";
> 
> you could update the binding documentation to list this one.

Similar story; this is only used for some of the hacky stuff Rockchip is
doing for USB3/TypeC stuff out of tree. I'll either document it or drop
it (as I'm not actually using it yet).

Thanks,
Brian

> Heiko
> 
> > +		status = "disabled";
> > +
> > +		usbdrd_dwc3_0: dwc3 {
> > +			compatible = "snps,dwc3";
> > +			reg = <0x0 0xfe800000 0x0 0x100000>;
> > +			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
> > +			dr_mode = "otg";
> > +			phys = <&u2phy0_otg>;
> > +			phy-names = "usb2-phy";
> > +			snps,dis_enblslpm_quirk;
> > +			snps,dis-u2-freeclk-exists-quirk;
> > +			snps,dis_u2_susphy_quirk;
> > +			snps,dis-del-phy-power-chg-quirk;
> > +			status = "disabled";
> > +		};
> > +	};
[...]

Re: [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Heiko Stuebner]

Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> Hi,
> 
> On Wed, Dec 07, 2016 at 06:09:16PM +0100, Heiko Stuebner wrote:
> > Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
> > > Add the dwc3 usb needed node information for rk3399.
> > > 
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > Somewhat rewritten from Caesar's reposting (v2) of my patch.
> > > 
> > > Changes:
> > >  * Include USB2 PHY (which is now in -next)
> > >  * Don't include USB3 PHY, as extcon support is not ready yet
> > >  * Drop non-upstream properties
> > >  * Fixup whitespace a bit
> > > 
> > > ---
> > > 
> > >  arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
> > > 
> > > ++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index
> > > 4ca8f9a7601c..1e97fb8c6415
> > > 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> > > @@ -316,6 +316,66 @@
> > > 
> > >  		};
> > >  	
> > >  	};
> > > 
> > > +	usbdrd3_0: usb@fe800000 {
> > 
> > insert location above usb@fe380000 is sorted wrong
> 
> So, *how* do you think things are sorted here? Alphabetical by label? Or
> by node name? Or by unit address? I guess I'm seeing you meant unit
> address.

correct. Per unit-address first, nodes without address alphabetical by node-
name (above nodes with addresses), never by label.

> But pcie@f8000000 is also out of order then. I guess maybe
> that's the only one then.

Yep, pcie is misplaced as sadly sometimes I miss those errors as well.


Heiko

> > > +		compatible = "rockchip,rk3399-dwc3";
> > > +		#address-cells = <2>;
> > > +		#size-cells = <2>;
> > > +		ranges;
> > > +		clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
> > > +			 <&cru ACLK_USB3OTG0>, <&cru ACLK_USB3_RKSOC_AXI_PERF>,
> > > +			 <&cru ACLK_USB3>, <&cru ACLK_USB3_GRF>;
> > > +		clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
> > > +			      "aclk_usb3otg0", "aclk_usb3_rksoc_axi_perf",
> > > +			      "aclk_usb3", "aclk_usb3_grf";
> > 
> > clock-names do not match binding. The dwc3-of-simple does not care, as it
> > just enables all of them it seems, but binding doc states the clock names
> > as> 
> > - clock-names:  Should contain the following:
> >   "ref_clk"     Controller reference clk, have to be 24 MHz
> >   "suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
> >   "bus_clk"     Master/Core clock, have to be >= 62.5 MHz for SS
> >   
> >                 operation and >= 30MHz for HS operation
> >   
> >   "grf_clk"     Controller grf clk
> 
> Ah, sorry. I'll try to go with the rockchip,dwc3.txt names better.
> 
> There are a few extra clocks here now, but I think those might only be
> for USB3 support, which isn't really working yet. I'll either document
> them or drop them.
> 
> > > +		resets = <&cru SRST_A_USB3_OTG0>;
> > > +		reset-names = "usb3-otg";
> > 
> > you could update the binding documentation to list this one.
> 
> Similar story; this is only used for some of the hacky stuff Rockchip is
> doing for USB3/TypeC stuff out of tree. I'll either document it or drop
> it (as I'm not actually using it yet).
> 
> Thanks,
> Brian
> 
> > Heiko
> > 
> > > +		status = "disabled";
> > > +
> > > +		usbdrd_dwc3_0: dwc3 {
> > > +			compatible = "snps,dwc3";
> > > +			reg = <0x0 0xfe800000 0x0 0x100000>;
> > > +			interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH 0>;
> > > +			dr_mode = "otg";
> > > +			phys = <&u2phy0_otg>;
> > > +			phy-names = "usb2-phy";
> > > +			snps,dis_enblslpm_quirk;
> > > +			snps,dis-u2-freeclk-exists-quirk;
> > > +			snps,dis_u2_susphy_quirk;
> > > +			snps,dis-del-phy-power-chg-quirk;
> > > +			status = "disabled";
> > > +		};
> > > +	};
> 
> [...]

Re: [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Brian Norris]

On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
> Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> > But pcie@f8000000 is also out of order then. I guess maybe
> > that's the only one then.
> 
> Yep, pcie is misplaced as sadly sometimes I miss those errors as well.

OK. Do you want me to patch that at the end of my series, or is that
unnecessary churn?

Brian

Re: [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399

[Heiko Stuebner]

Am Mittwoch, 7. Dezember 2016, 11:03:02 CET schrieb Brian Norris:
> On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
> > Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
> > > But pcie@f8000000 is also out of order then. I guess maybe
> > > that's the only one then.
> > 
> > Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
> 
> OK. Do you want me to patch that at the end of my series, or is that
> unnecessary churn?

I'm still pondering [and am investing way to much brain cells in trying to 
decide this ;-) ], but tend to want to move it.

That way the dtsi gives the correct sorting impression for future dt-patches 
of which I guess we'll see a lot in the time to come.

So yes, please move it as well.


Thanks
Heiko

Re: [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin

[Heiko Stuebner]

Am Mittwoch, 7. Dezember 2016, 09:41:39 CET schrieb Brian Norris:
> On Wed, Dec 07, 2016 at 06:12:13PM +0100, Heiko Stuebner wrote:
> > Hi Brian,
> > 
> > Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
> > > Gru is a base dev board for a family of devices, including Kevin. Both
> > > utilize Rockchip RK3399, and they share much of their design.
> > > 
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > 
> > >  Documentation/devicetree/bindings/arm/rockchip.txt | 20
> > > 
> > > ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > > cc4ace6397ab..830e13f5890c 100644
> > > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > > @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> > > 
> > >  		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> > >  		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> > > 
> > > +- Google Gru (dev-board):
> > boards sorted alphabetically please
> > 
> > Brian, Gru, Jaq, ... Kevin, ...
> > 
> > While the sorting of old boards is not right yet, new boards should be
> > sorted.
> I got the idea that there was some attempt to group logically before
> alphabetically. Like keeping board/SoC families together. But maybe not.
> 
> I can do as you suggested, if you don't care about keeping actual
> similar boards together (i.e., veyron/3288 vs gru/3399).

I'd prefer a simple alphabetical sorting.

I think people reading the document will know what device they have, but not 
necessarily the actual soc in it. At least I would look for Google Kevin 
primarily without thinking of the soc at first.

And in general, most Rockchip boards (maybe except Google-boards) tend to 
follow the reference design quite closely, so it may become hard to decide 
when one is similar to another :-) . So best to keep it simple.

Re: [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin

[Rob Herring]

On Thu, Dec 01, 2016 at 06:27:30PM -0800, Brian Norris wrote:
> Gru is a base dev board for a family of devices, including Kevin. Both
> utilize Rockchip RK3399, and they share much of their design.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
>  Documentation/devicetree/bindings/arm/rockchip.txt | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index cc4ace6397ab..830e13f5890c 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
>  		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
>  		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
>  
> +- Google Gru (dev-board):
> +    Required root node properties:
> +      - compatible = "google,gru-rev15", "google,gru-rev14",
> +		     "google,gru-rev13", "google,gru-rev12",
> +		     "google,gru-rev11", "google,gru-rev10",
> +		     "google,gru-rev9", "google,gru-rev8",
> +		     "google,gru-rev7", "google,gru-rev6",
> +		     "google,gru-rev5", "google,gru-rev4",
> +		     "google,gru-rev3", "google,gru-rev2",
> +		     "google,gru", "rockchip,rk3399";

All of these are supposed to be specified or just one rev at a time?

> +
> +- Google Kevin:
> +    Required root node properties:
> +      - compatible = "google,kevin-rev15", "google,kevin-rev14",
> +		     "google,kevin-rev13", "google,kevin-rev12",
> +		     "google,kevin-rev11", "google,kevin-rev10",
> +		     "google,kevin-rev9", "google,kevin-rev8",
> +		     "google,kevin-rev7", "google,kevin-rev6",
> +		     "google,kevin", "google,gru", "rockchip,rk3399";
> +
>  - mqmaker MiQi:
>      Required root node properties:
>        - compatible = "mqmaker,miqi", "rockchip,rk3288";
> -- 
> 2.8.0.rc3.226.g39d4020
> 

Re: [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin

[Heiko Stuebner]

Am Freitag, 9. Dezember 2016, 11:54:02 CET schrieb Rob Herring:
> On Thu, Dec 01, 2016 at 06:27:30PM -0800, Brian Norris wrote:
> > Gru is a base dev board for a family of devices, including Kevin. Both
> > utilize Rockchip RK3399, and they share much of their design.
> > 
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > ---
> > 
> >  Documentation/devicetree/bindings/arm/rockchip.txt | 20
> >  ++++++++++++++++++++ 1 file changed, 20 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt
> > b/Documentation/devicetree/bindings/arm/rockchip.txt index
> > cc4ace6397ab..830e13f5890c 100644
> > --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> > +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> > @@ -99,6 +99,26 @@ Rockchip platforms device tree bindings
> > 
> >  		     "google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
> >  		     "google,veyron-speedy", "google,veyron", "rockchip,rk3288";
> > 
> > +- Google Gru (dev-board):
> > +    Required root node properties:
> > +      - compatible = "google,gru-rev15", "google,gru-rev14",
> > +		     "google,gru-rev13", "google,gru-rev12",
> > +		     "google,gru-rev11", "google,gru-rev10",
> > +		     "google,gru-rev9", "google,gru-rev8",
> > +		     "google,gru-rev7", "google,gru-rev6",
> > +		     "google,gru-rev5", "google,gru-rev4",
> > +		     "google,gru-rev3", "google,gru-rev2",
> > +		     "google,gru", "rockchip,rk3399";
> 
> All of these are supposed to be specified or just one rev at a time?

All of them. I.e. the devicetree is supposed to be compatible with all of 
those, while the bootloader determines the actual board revision and sets the 
choosen compatible - at least that was the way with the previous series of 
devices based around the rk3288 (veyron) and I think it will be the same way 
still.

I.e. as you can see below, Kevin starts being compatible at -rev6, as 
(engineering) revisions before that probably had some differences on the 
board.


> 
> > +
> > +- Google Kevin:
> > +    Required root node properties:
> > +      - compatible = "google,kevin-rev15", "google,kevin-rev14",
> > +		     "google,kevin-rev13", "google,kevin-rev12",
> > +		     "google,kevin-rev11", "google,kevin-rev10",
> > +		     "google,kevin-rev9", "google,kevin-rev8",
> > +		     "google,kevin-rev7", "google,kevin-rev6",
> > +		     "google,kevin", "google,gru", "rockchip,rk3399";
> > +
> > 
> >  - mqmaker MiQi:
> >      Required root node properties:
> >        - compatible = "mqmaker,miqi", "rockchip,rk3288";

Re: [PATCH 9/9] arm64: dts: rockchip: add regulator info for Kevin digitizer

[Heiko Stuebner]

Am Donnerstag, 1. Dezember 2016, 18:27:33 CET schrieb Brian Norris:
> We need to enable this regulator before the digitizer can be used. Wacom
> recommended waiting for 100 ms before talking to the HID.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> Uses WIP bindings:
> 
> [PATCH v3 1/2] devicetree: i2c-hid: Add regulator support
> https://patchwork.kernel.org/patch/9457493/

if you notice the bindings being accepted before me, could you notify here 
please?


Thanks
Heiko

Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

[Heiko Stuebner]

Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris:
> Hi Heiko,
> 
> On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
> > Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> > > We need to add regulators to the CPU nodes, so cpufreq doesn't think it
> > > can crank up the clock speed without changing the voltage. However, we
> > > don't yet have the DT bindings to fully describe the Over Voltage
> > > Protection (OVP) circuits on these boards. Without that description, we
> > > might end up changing the voltage too much, too fast.
> > > 
> > > Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
> > > them disabled.
> > > 
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > 
> > is there a specific reason for keeping this change separate?
> 
> Maybe not a great one. I figured they were somewhat controversial, so I
> at least wanted to split the "cpufreq patches" (i.e., this and the
> previous) from the main DTS(I) additions. I also figured we typically
> like to keep the base SoC changes separate from the board DTS(I)
> changes.

I was scratching my head for a bit where this was affecting the evb, until I 
found the include at the end of patch5 :-) .

> > While it is nice for documentation reasons, as it stands now the previous
> > patch introduces a regression (cpufreq trying to scale without regulators)
> > and immediately fixes it here.
> 
> Right. Additionally, as noted on the previous patch, we might do the
> same with EVB. But I don't know what the regulators are like for EVB.
> This is probably a bigger deal, since EVB has been working (allegedly)
> upstream for a while now.

Yep, it was at least booting :-) . I guess I should wire it up again. My shiny 
new Gru somehow did take up its space recently.

> There's no way to split these up without either breaking compilation or
> breaking bisectability. For Kevin/Gru, they don't function at all before
> this series, so I figured some "settle" time wasn't a huge deal.
> 
> > So if you're ok with it, I'd like to merge this one back into the previous
> > patch when applying.
> 
> That'd be OK with me, as long as we're also confident about EVB.

That somehow sounds unrelated, as this patch only touches gru stuff anyway. So 
if the evb breaks, it would do so after patch5 already.


> Maybe at a minimum, I should just patch in some empty regulator nodes,
> so cpufreq doesn't think there's no need to handle voltage.

So I guess going forward we could do, describe the evb pwm regulators (in 
disabled state), add general OPPs, add gru with pwm regulators?

I'll try to hook up my evb and check on the pwm-regulators in the schematics 
this week.


Heiko

Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru

[Heiko Stübner]

Am Dienstag, 13. Dezember 2016, 18:48:50 schrieb Heiko Stuebner:
> Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris:
> > Hi Heiko,
> > 
> > On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
> > > Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> > > > We need to add regulators to the CPU nodes, so cpufreq doesn't think
> > > > it
> > > > can crank up the clock speed without changing the voltage. However, we
> > > > don't yet have the DT bindings to fully describe the Over Voltage
> > > > Protection (OVP) circuits on these boards. Without that description,
> > > > we
> > > > might end up changing the voltage too much, too fast.
> > > > 
> > > > Add the pwm-regulator descriptions and associate the CPU OPPs, but
> > > > leave
> > > > them disabled.
> > > > 
> > > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > 
> > > is there a specific reason for keeping this change separate?
> > 
> > Maybe not a great one. I figured they were somewhat controversial, so I
> > at least wanted to split the "cpufreq patches" (i.e., this and the
> > previous) from the main DTS(I) additions. I also figured we typically
> > like to keep the base SoC changes separate from the board DTS(I)
> > changes.
> 
> I was scratching my head for a bit where this was affecting the evb, until I
> found the include at the end of patch5 :-) .
> 
> > > While it is nice for documentation reasons, as it stands now the
> > > previous
> > > patch introduces a regression (cpufreq trying to scale without
> > > regulators)
> > > and immediately fixes it here.
> > 
> > Right. Additionally, as noted on the previous patch, we might do the
> > same with EVB. But I don't know what the regulators are like for EVB.
> > This is probably a bigger deal, since EVB has been working (allegedly)
> > upstream for a while now.
> 
> Yep, it was at least booting :-) . I guess I should wire it up again. My
> shiny new Gru somehow did take up its space recently.
> 
> > There's no way to split these up without either breaking compilation or
> > breaking bisectability. For Kevin/Gru, they don't function at all before
> > this series, so I figured some "settle" time wasn't a huge deal.
> > 
> > > So if you're ok with it, I'd like to merge this one back into the
> > > previous
> > > patch when applying.
> > 
> > That'd be OK with me, as long as we're also confident about EVB.
> 
> That somehow sounds unrelated, as this patch only touches gru stuff anyway.
> So if the evb breaks, it would do so after patch5 already.
> 
> > Maybe at a minimum, I should just patch in some empty regulator nodes,
> > so cpufreq doesn't think there's no need to handle voltage.
> 
> So I guess going forward we could do, describe the evb pwm regulators (in
> disabled state), add general OPPs, add gru with pwm regulators?
> 
> I'll try to hook up my evb and check on the pwm-regulators in the schematics
> this week.

Now I remember why I retired my evb ... ES1 silicon.

Anyway, I was able to describe the rk808 pmic that is used in some basic way 
and was able to see a bit of cpu-scaling on the little cluster, but the big 
cluster never was able to scale in a stable way and always hung the system.

I don't think that we should care about ES1 chips as they never reached any 
public but that leaves me without the ability to test.

In another issue I read that Caesar also is using a rk3399evb sometimes, so 
maybe he can give that a try on real ES2 silicon and I've thus Cc'ed him.

@Caesar I don't know how much the power rails differ between evb versions, so 
maybe you can also provide the necessary rk808 devicetree nodes please?


Thanks
Heiko

Re: [PATCH 0/9] arm64: dts: rockchip: support Google Kevin

[Heiko Stuebner]

Hi Brian,

Am Donnerstag, 1. Dezember 2016, 18:27:24 CET schrieb Brian Norris:
> This series adds basic support for Google Kevin, a board in the Gru device
> family. I do not add a leaf .dts board file for Gru, but I have retained the
> split between "things that apply to the Gru family" (rk3399-gru.dtsi) and
> "things that apply to Kevin only" (rk3399-gru-kevin.dtsi).

do you plan on refreshing these patches against the current kernel and the 
comments received at some point?


Heiko

Re: [PATCH 0/9] arm64: dts: rockchip: support Google Kevin

[Brian Norris]

On Wed, Feb 08, 2017 at 02:01:42AM +0100, Heiko Stuebner wrote:
> Am Donnerstag, 1. Dezember 2016, 18:27:24 CET schrieb Brian Norris:
> > This series adds basic support for Google Kevin, a board in the Gru device
> > family. I do not add a leaf .dts board file for Gru, but I have retained the
> > split between "things that apply to the Gru family" (rk3399-gru.dtsi) and
> > "things that apply to Kevin only" (rk3399-gru-kevin.dtsi).
> 
> do you plan on refreshing these patches against the current kernel and the 
> comments received at some point?

I've fixed up a few locally, but I haven't had the time to
retest/resend. I plan to do so eventually, but not soon.

Brian