linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin
@ 2017-02-10  1:05 Brian Norris
  2017-02-10  1:05 ` [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs Brian Norris
                   ` (5 more replies)
  0 siblings, 6 replies; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, Brian Norris

Hi,

This is v2, adding 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 know it's close to the 4.11 merge window, so I expect this won't make it for
that. But since I got it ready for testing anyway, I thought I might as well
get it out the door, ready for 4.12.

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).

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 5 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; working on this in another series)
 * 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


I include a more detailed changelog in the patches themselves, but a rough
summary:

v1 -> v2:
 * merge the OPP and CPU regulators into 1 patch; don't support them on non-Gru
   boards yet, as that will break them (and we're not sure if the same table is
   applicable anyway)
 * drop some patches that were applied already
 * update copyrights
 * match USB bindings more closely
 * drop digitizer regulator patches; this isn't ready (working on in another
   series)


Brian Norris (5):
  arm64: dts: rockchip: support dwc3 USB for rk3399
  dt-bindings: Document rk3399 Gru/Kevin
  arm64: dts: rockchip: add Gru/Kevin DTS
  arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators
  arm64: dts: rockchip: sort rk3399 by unit address

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  |  312 ++++++
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi       | 1165 ++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi       |  145 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  142 ++-
 8 files changed, 1743 insertions(+), 44 deletions(-)
 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.11.0.483.g087da7b7c-goog

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
@ 2017-02-10  1:05 ` Brian Norris
  2017-02-21 23:47   ` Olof Johansson
  2017-02-10  1:05 ` [PATCH v2 2/6] arm64: dts: rockchip: support dwc3 USB for rk3399 Brian Norris
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, 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>
---
 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.11.0.483.g087da7b7c-goog

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v2 2/6] arm64: dts: rockchip: support dwc3 USB for rk3399
  2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
  2017-02-10  1:05 ` [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs Brian Norris
@ 2017-02-10  1:05 ` Brian Norris
  2017-02-10 22:01   ` Heiko Stuebner
  2017-02-10  1:05 ` [PATCH v2 3/6] dt-bindings: Document rk3399 Gru/Kevin Brian Norris
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, 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 (?? -> v1):
 * 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

v1 -> v2:
 * add phy_type = "utmi_wide"
 * sort by unit address
 * match upstream clock names and delete unnecessary ones
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 54 ++++++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8e6d1bdeb9c3..a9702c29d71a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -371,6 +371,60 @@
 		status = "disabled";
 	};
 
+	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_GRF>;
+		clock-names = "ref_clk", "suspend_clk",
+			      "bus_clk", "grf_clk";
+		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";
+			phy_type = "utmi_wide";
+			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_GRF>;
+		clock-names = "ref_clk", "suspend_clk",
+			      "bus_clk", "grf_clk";
+		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";
+			phy_type = "utmi_wide";
+			snps,dis_enblslpm_quirk;
+			snps,dis-u2-freeclk-exists-quirk;
+			snps,dis_u2_susphy_quirk;
+			snps,dis-del-phy-power-chg-quirk;
+			status = "disabled";
+		};
+	};
+
 	gic: interrupt-controller@fee00000 {
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <4>;
-- 
2.11.0.483.g087da7b7c-goog

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v2 3/6] dt-bindings: Document rk3399 Gru/Kevin
  2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
  2017-02-10  1:05 ` [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs Brian Norris
  2017-02-10  1:05 ` [PATCH v2 2/6] arm64: dts: rockchip: support dwc3 USB for rk3399 Brian Norris
@ 2017-02-10  1:05 ` Brian Norris
  2017-02-16  2:12   ` Rob Herring
  2017-02-10  1:05 ` [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS Brian Norris
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, 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..5328e1f2badc 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -56,6 +56,17 @@ Rockchip platforms device tree bindings
       - compatible = "google,veyron-brain-rev0", "google,veyron-brain",
 		     "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 Jaq (Haier Chromebook 11 and more):
     Required root node properties:
       - compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
@@ -70,6 +81,15 @@ Rockchip platforms device tree bindings
 		     "google,veyron-jerry-rev3", "google,veyron-jerry",
 		     "google,veyron", "rockchip,rk3288";
 
+- 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";
+
 - Google Mickey (Asus Chromebit CS10):
     Required root node properties:
       - compatible = "google,veyron-mickey-rev8", "google,veyron-mickey-rev7",
-- 
2.11.0.483.g087da7b7c-goog

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS
  2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
                   ` (2 preceding siblings ...)
  2017-02-10  1:05 ` [PATCH v2 3/6] dt-bindings: Document rk3399 Gru/Kevin Brian Norris
@ 2017-02-10  1:05 ` Brian Norris
  2017-02-28 22:00   ` Heiko Stuebner
  2017-02-10  1:05 ` [PATCH v2 5/6] arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Brian Norris
  2017-02-10  1:05 ` [PATCH v2 6/6] arm64: dts: rockchip: sort rk3399 by unit address Brian Norris
  5 siblings, 1 reply; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, 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>
---
v1 -> v2:
 * drop deprecated da7219 'dlg,ldo-lvl' property
 * update copyrights
 * adjust GPLL to 600 MHz
 * drop PCIe link speed overrides (they're in rk3399.dtsi now)
 * fix spi1 leakage with "sleep" state pinctrl
 * drop unneeded "google,cros-ec-spi-pre-delay"
---
 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      | 1018 +++++++++++++++++++++
 3 files changed, 1331 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..2f720cf2fd07
--- /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-2017 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..f6c745810da9
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -0,0 +1,1018 @@
+/*
+ * Google Gru (and derivatives) board device tree source
+ *
+ * Copyright 2016-2017 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 =
+		<600000000>, <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,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>;
+
+	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";
+
+	pinctrl-names = "default", "sleep";
+	pinctrl-1 = <&spi1_sleep>;
+
+	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>;
+
+		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>;
+		};
+	};
+
+	spi1 {
+		spi1_sleep: spi1-sleep {
+			/*
+			 * Pull down SPI1 CLK/CS/RX/TX during suspend, to
+			 * prevent leakage.
+			 */
+			rockchip,pins = <1 9 RK_FUNC_GPIO &pcfg_pull_down>,
+					<1 10 RK_FUNC_GPIO &pcfg_pull_down>,
+					<1 7 RK_FUNC_GPIO &pcfg_pull_down>,
+					<1 8 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	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.11.0.483.g087da7b7c-goog

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v2 5/6] arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators
  2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
                   ` (3 preceding siblings ...)
  2017-02-10  1:05 ` [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS Brian Norris
@ 2017-02-10  1:05 ` Brian Norris
  2017-02-10  1:05 ` [PATCH v2 6/6] arm64: dts: rockchip: sort rk3399 by unit address Brian Norris
  5 siblings, 0 replies; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, Brian Norris

Used for Gru/Kevin only, as they're the only ones which have a described
CPU regulator. Also, I'm not sure we've validated this table non-Gru
boards.

At the same time, partially describe PWM regulators for Gru, 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>
---
v1 --> v2:
 * combine the OPP table into the regulator patch, to keep from
   regressing
 * don't include the OPP table in top-level rk3399.dtsi, to avoid
   breaking other boards
---
 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 147 +++++++++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 145 ++++++++++++++++++++++++++
 2 files changed, 292 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index f6c745810da9..5a9ed09ee316 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -44,6 +44,7 @@
 
 #include <dt-bindings/input/input.h>
 #include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
 
 / {
 	chosen {
@@ -172,6 +173,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 +537,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>,
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..dd82e16236a8
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
@@ -0,0 +1,145 @@
+/*
+ * Copyright (c) 2016-2017 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>;
+};
-- 
2.11.0.483.g087da7b7c-goog

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* [PATCH v2 6/6] arm64: dts: rockchip: sort rk3399 by unit address
  2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
                   ` (4 preceding siblings ...)
  2017-02-10  1:05 ` [PATCH v2 5/6] arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Brian Norris
@ 2017-02-10  1:05 ` Brian Norris
  2017-02-10 21:39   ` Heiko Stuebner
  5 siblings, 1 reply; 18+ messages in thread
From: Brian Norris @ 2017-02-10  1:05 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong, Brian Norris

f8000000 is less than all the other (top-level) unit addresses.

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index a9702c29d71a..f5681bea1271 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -211,6 +211,50 @@
 		};
 	};
 
+	pcie0: pcie@f8000000 {
+		compatible = "rockchip,rk3399-pcie";
+		reg = <0x0 0xf8000000 0x0 0x2000000>,
+		      <0x0 0xfd000000 0x0 0x1000000>;
+		reg-names = "axi-base", "apb-base";
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		aspm-no-l0s;
+		bus-range = <0x0 0x1>;
+		clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
+			 <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
+		clock-names = "aclk", "aclk-perf",
+			      "hclk", "pm";
+		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>;
+		interrupt-names = "sys", "legacy", "client";
+		interrupt-map-mask = <0 0 0 7>;
+		interrupt-map = <0 0 0 1 &pcie0_intc 0>,
+				<0 0 0 2 &pcie0_intc 1>,
+				<0 0 0 3 &pcie0_intc 2>,
+				<0 0 0 4 &pcie0_intc 3>;
+		max-link-speed = <1>;
+		msi-map = <0x0 &its 0x0 0x1000>;
+		phys = <&pcie_phy>;
+		phy-names = "pcie-phy";
+		ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
+			  0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
+		resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
+			 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>,
+			 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>,
+			 <&cru SRST_A_PCIE>;
+		reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
+			      "pm", "pclk", "aclk";
+		status = "disabled";
+
+		pcie0_intc: interrupt-controller {
+			interrupt-controller;
+			#address-cells = <0>;
+			#interrupt-cells = <1>;
+		};
+	};
+
 	gmac: ethernet@fe300000 {
 		compatible = "rockchip,rk3399-gmac";
 		reg = <0x0 0xfe300000 0x0 0x10000>;
@@ -275,50 +319,6 @@
 		status = "disabled";
 	};
 
-	pcie0: pcie@f8000000 {
-		compatible = "rockchip,rk3399-pcie";
-		reg = <0x0 0xf8000000 0x0 0x2000000>,
-		      <0x0 0xfd000000 0x0 0x1000000>;
-		reg-names = "axi-base", "apb-base";
-		#address-cells = <3>;
-		#size-cells = <2>;
-		#interrupt-cells = <1>;
-		aspm-no-l0s;
-		bus-range = <0x0 0x1>;
-		clocks = <&cru ACLK_PCIE>, <&cru ACLK_PERF_PCIE>,
-			 <&cru PCLK_PCIE>, <&cru SCLK_PCIE_PM>;
-		clock-names = "aclk", "aclk-perf",
-			      "hclk", "pm";
-		interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH 0>,
-			     <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH 0>,
-			     <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH 0>;
-		interrupt-names = "sys", "legacy", "client";
-		interrupt-map-mask = <0 0 0 7>;
-		interrupt-map = <0 0 0 1 &pcie0_intc 0>,
-				<0 0 0 2 &pcie0_intc 1>,
-				<0 0 0 3 &pcie0_intc 2>,
-				<0 0 0 4 &pcie0_intc 3>;
-		max-link-speed = <1>;
-		msi-map = <0x0 &its 0x0 0x1000>;
-		phys = <&pcie_phy>;
-		phy-names = "pcie-phy";
-		ranges = <0x83000000 0x0 0xfa000000 0x0 0xfa000000 0x0 0x600000
-			  0x81000000 0x0 0xfa600000 0x0 0xfa600000 0x0 0x100000>;
-		resets = <&cru SRST_PCIE_CORE>, <&cru SRST_PCIE_MGMT>,
-			 <&cru SRST_PCIE_MGMT_STICKY>, <&cru SRST_PCIE_PIPE>,
-			 <&cru SRST_PCIE_PM>, <&cru SRST_P_PCIE>,
-			 <&cru SRST_A_PCIE>;
-		reset-names = "core", "mgmt", "mgmt-sticky", "pipe",
-			      "pm", "pclk", "aclk";
-		status = "disabled";
-
-		pcie0_intc: interrupt-controller {
-			interrupt-controller;
-			#address-cells = <0>;
-			#interrupt-cells = <1>;
-		};
-	};
-
 	usb_host0_ehci: usb@fe380000 {
 		compatible = "generic-ehci";
 		reg = <0x0 0xfe380000 0x0 0x20000>;
-- 
2.11.0.483.g087da7b7c-goog

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 6/6] arm64: dts: rockchip: sort rk3399 by unit address
  2017-02-10  1:05 ` [PATCH v2 6/6] arm64: dts: rockchip: sort rk3399 by unit address Brian Norris
@ 2017-02-10 21:39   ` Heiko Stuebner
  0 siblings, 0 replies; 18+ messages in thread
From: Heiko Stuebner @ 2017-02-10 21:39 UTC (permalink / raw)
  To: Brian Norris
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong

Am Donnerstag, 9. Februar 2017, 17:05:21 CET schrieb Brian Norris:
> f8000000 is less than all the other (top-level) unit addresses.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>

applied for 4.12


Thanks
Heiko

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/6] arm64: dts: rockchip: support dwc3 USB for rk3399
  2017-02-10  1:05 ` [PATCH v2 2/6] arm64: dts: rockchip: support dwc3 USB for rk3399 Brian Norris
@ 2017-02-10 22:01   ` Heiko Stuebner
  0 siblings, 0 replies; 18+ messages in thread
From: Heiko Stuebner @ 2017-02-10 22:01 UTC (permalink / raw)
  To: Brian Norris
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong

Am Donnerstag, 9. Februar 2017, 17:05:17 CET schrieb Brian Norris:
> Add the dwc3 usb needed node information for rk3399.
> 
> Signed-off-by: Brian Norris <briannorris@chromium.org>

applied for 4.12

Thanks
Heiko

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 3/6] dt-bindings: Document rk3399 Gru/Kevin
  2017-02-10  1:05 ` [PATCH v2 3/6] dt-bindings: Document rk3399 Gru/Kevin Brian Norris
@ 2017-02-16  2:12   ` Rob Herring
  0 siblings, 0 replies; 18+ messages in thread
From: Rob Herring @ 2017-02-16  2:12 UTC (permalink / raw)
  To: Brian Norris
  Cc: Heiko Stuebner, linux-rockchip, linux-kernel, Caesar Wang,
	Doug Anderson, devicetree, Stephen Barber, linux-arm-kernel,
	Chris Zhong

On Thu, Feb 09, 2017 at 05:05:18PM -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(+)

Acked-by: Rob Herring <robh@kernel.org> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-02-10  1:05 ` [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs Brian Norris
@ 2017-02-21 23:47   ` Olof Johansson
  2017-02-27 18:20     ` Heiko Stuebner
  0 siblings, 1 reply; 18+ messages in thread
From: Olof Johansson @ 2017-02-21 23:47 UTC (permalink / raw)
  To: Brian Norris
  Cc: Heiko Stuebner, devicetree, Doug Anderson, linux-kernel,
	open list:ARM/Rockchip SoC...,
	Rob Herring, Chris Zhong, Stephen Barber, linux-arm-kernel,
	Caesar Wang

Hi,

On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
> 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.

I'd rather have something like this:

https://marc.info/?m=147547436324674&w=2

Instead of having everybody move things over. I.e. make it easy to
refer to the arm version from arm64 instead of creating a "common"
layer inbetween.


-Olof

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-02-21 23:47   ` Olof Johansson
@ 2017-02-27 18:20     ` Heiko Stuebner
  2017-03-20 23:07       ` Brian Norris
  2017-04-19 12:54       ` Olof Johansson
  0 siblings, 2 replies; 18+ messages in thread
From: Heiko Stuebner @ 2017-02-27 18:20 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Brian Norris, devicetree, Doug Anderson, linux-kernel,
	open list:ARM/Rockchip SoC...,
	Rob Herring, Chris Zhong, Stephen Barber, linux-arm-kernel,
	Caesar Wang

Hi Olof,

Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
> > 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.
> 
> I'd rather have something like this:
> 
> https://marc.info/?m=147547436324674&w=2
> 
> Instead of having everybody move things over. I.e. make it easy to
> refer to the arm version from arm64 instead of creating a "common"
> layer inbetween.

just so it gets noticed, I've done and tested [0], which hopefully should
implement your suggestions above.

If that looks ok, how do you want that picked up? Should I just include
them in my regular rockchip branches or do you to pick them into some
immutable branch, if other surprise-users turn up in time for 4.12?


Thanks
Heiko


[0] http://lists.infradead.org/pipermail/linux-rockchip/2017-February/014226.html

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS
  2017-02-10  1:05 ` [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS Brian Norris
@ 2017-02-28 22:00   ` Heiko Stuebner
  2017-02-28 22:54     ` Doug Anderson
  0 siblings, 1 reply; 18+ messages in thread
From: Heiko Stuebner @ 2017-02-28 22:00 UTC (permalink / raw)
  To: Brian Norris
  Cc: linux-rockchip, linux-kernel, Caesar Wang, Doug Anderson,
	devicetree, Rob Herring, Stephen Barber, linux-arm-kernel,
	Chris Zhong

Hi Brian,

Am Donnerstag, 9. Februar 2017, 17:05:19 CET schrieb 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.
> 

short summary of what we just talked about, and some more minor things I found

[...]

> +	/* pp3300 children */

drop that. I may not have caught all of them, but you get the idea ;-)


> +	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 */

does the gpio subsystem like this double usage?

> +		gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
> +
> +		vin-supply = <&pp3300>;
> +	};
> +
> +	/* pp5000 aliases; these are always on for AP so just use alias */

drop that

> +
> +	/* EC turns on w/ usb_a_en */
> +	pp5000_usb_a_vbus: pp5000 {
> +	};
> +
> +	/* END REGULATORS */

drop that

> +
> +	io-domains {

&io_domains instead

> +		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 */
> +	};


> +	pmu-io-domains {

&pmu_io_domains instead

> +		compatible = "rockchip,rk3399-pmu-io-voltage-domain";
> +		rockchip,grf = <&pmugrf>;
> +
> +		pmu1830-supply = <&pp1800_pmu>;		/* PMUIO2_VDD */
> +	};


> +#include "common/cros-ec-keyboard.dtsi"
> +#include "common/cros-ec-sbs.dtsi"

please try the arm include symlinks instead


> +
> +/* PINCTRL: always below everything else */
> +

 drop this

> +
> +/* 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 */
> +

drop these


Heiko

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS
  2017-02-28 22:00   ` Heiko Stuebner
@ 2017-02-28 22:54     ` Doug Anderson
  0 siblings, 0 replies; 18+ messages in thread
From: Doug Anderson @ 2017-02-28 22:54 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Brian Norris, open list:ARM/Rockchip SoC...,
	linux-kernel, Caesar Wang, devicetree, Rob Herring,
	Stephen Barber, linux-arm-kernel, Chris Zhong

Hi,

On Tue, Feb 28, 2017 at 2:00 PM, Heiko Stuebner <heiko@sntech.de> wrote:
>> +     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 */
>
> does the gpio subsystem like this double usage?

Yes, see commit f19b00da8ed3 ("regulator: core: support shared enable
GPIO concept").  ...but there's no great place to put the pinctrl node
though, unfortunately.  It's either randomly pick one of the two or
add it as a system-level hog.

-Doug

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-02-27 18:20     ` Heiko Stuebner
@ 2017-03-20 23:07       ` Brian Norris
  2017-04-19 12:54       ` Olof Johansson
  1 sibling, 0 replies; 18+ messages in thread
From: Brian Norris @ 2017-03-20 23:07 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Olof Johansson, devicetree, Doug Anderson, linux-kernel,
	open list:ARM/Rockchip SoC...,
	Rob Herring, Chris Zhong, Stephen Barber, linux-arm-kernel,
	Caesar Wang

In case this thread is easier to notice...

Olof,

On Mon, Feb 27, 2017 at 07:20:48PM +0100, Heiko Stuebner wrote:
> Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
> > On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
> > > 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.
> > 
> > I'd rather have something like this:
> > 
> > https://marc.info/?m=147547436324674&w=2
> > 
> > Instead of having everybody move things over. I.e. make it easy to
> > refer to the arm version from arm64 instead of creating a "common"
> > layer inbetween.
> 
> just so it gets noticed, I've done and tested [0], which hopefully should
> implement your suggestions above.
> 
> If that looks ok, how do you want that picked up? Should I just include
> them in my regular rockchip branches or do you to pick them into some
> immutable branch, if other surprise-users turn up in time for 4.12?

Ping? I suppose we can prevent users in 4.12 by never merging this :)

Brian

> 
> 
> [0] http://lists.infradead.org/pipermail/linux-rockchip/2017-February/014226.html
> 
> 

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-02-27 18:20     ` Heiko Stuebner
  2017-03-20 23:07       ` Brian Norris
@ 2017-04-19 12:54       ` Olof Johansson
  2017-04-19 13:25         ` Heiko Stuebner
  1 sibling, 1 reply; 18+ messages in thread
From: Olof Johansson @ 2017-04-19 12:54 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Brian Norris, devicetree, Doug Anderson, linux-kernel,
	open list:ARM/Rockchip SoC...,
	Rob Herring, Chris Zhong, Stephen Barber, linux-arm-kernel,
	Caesar Wang

Hi,

On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> Hi Olof,
>
> Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
>> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
>> > 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.
>>
>> I'd rather have something like this:
>>
>> https://marc.info/?m=147547436324674&w=2
>>
>> Instead of having everybody move things over. I.e. make it easy to
>> refer to the arm version from arm64 instead of creating a "common"
>> layer inbetween.
>
> just so it gets noticed, I've done and tested [0], which hopefully should
> implement your suggestions above.
>
> If that looks ok, how do you want that picked up? Should I just include
> them in my regular rockchip branches or do you to pick them into some
> immutable branch, if other surprise-users turn up in time for 4.12?

Sigh. I completely dropped the ball on this, and I didn't see it
included in any of your pull requests for 4.12 since I never actually
acked that approach.

I've applied the patches onto a dt/include-paths stable branch, but
we're late for merging dependent code on top of it for 4.12.


-Olof

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-04-19 12:54       ` Olof Johansson
@ 2017-04-19 13:25         ` Heiko Stuebner
  2017-04-19 13:31           ` Olof Johansson
  0 siblings, 1 reply; 18+ messages in thread
From: Heiko Stuebner @ 2017-04-19 13:25 UTC (permalink / raw)
  To: Olof Johansson
  Cc: Brian Norris, devicetree, Doug Anderson, linux-kernel,
	open list:ARM/Rockchip SoC...,
	Rob Herring, Chris Zhong, Stephen Barber, linux-arm-kernel,
	Caesar Wang

Am Mittwoch, 19. April 2017, 21:54:09 CEST schrieb Olof Johansson:
> Hi,
> 
> On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko@sntech.de> wrote:
> > Hi Olof,
> >
> > Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
> >> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
> >> > 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.
> >>
> >> I'd rather have something like this:
> >>
> >> https://marc.info/?m=147547436324674&w=2
> >>
> >> Instead of having everybody move things over. I.e. make it easy to
> >> refer to the arm version from arm64 instead of creating a "common"
> >> layer inbetween.
> >
> > just so it gets noticed, I've done and tested [0], which hopefully should
> > implement your suggestions above.
> >
> > If that looks ok, how do you want that picked up? Should I just include
> > them in my regular rockchip branches or do you to pick them into some
> > immutable branch, if other surprise-users turn up in time for 4.12?
> 
> Sigh. I completely dropped the ball on this, and I didn't see it
> included in any of your pull requests for 4.12 since I never actually
> acked that approach.
> 
> I've applied the patches onto a dt/include-paths stable branch, but
> we're late for merging dependent code on top of it for 4.12.

Didn't you merge the patches into a branch already and the rk3399-gru
support on top of it?

Aka
https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=shared/dt-symlinks

Which one of my previous pull requests was already based on.


Heiko

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
  2017-04-19 13:25         ` Heiko Stuebner
@ 2017-04-19 13:31           ` Olof Johansson
  0 siblings, 0 replies; 18+ messages in thread
From: Olof Johansson @ 2017-04-19 13:31 UTC (permalink / raw)
  To: Heiko Stuebner
  Cc: Brian Norris, devicetree, Doug Anderson, linux-kernel,
	open list:ARM/Rockchip SoC...,
	Rob Herring, Chris Zhong, Stephen Barber, linux-arm-kernel,
	Caesar Wang, Maxime Ripard

On Wed, Apr 19, 2017 at 10:25 PM, Heiko Stuebner <heiko@sntech.de> wrote:
> Am Mittwoch, 19. April 2017, 21:54:09 CEST schrieb Olof Johansson:
>> Hi,
>>
>> On Tue, Feb 28, 2017 at 3:20 AM, Heiko Stuebner <heiko@sntech.de> wrote:
>> > Hi Olof,
>> >
>> > Am Dienstag, 21. Februar 2017, 15:47:31 CET schrieb Olof Johansson:
>> >> On Thu, Feb 9, 2017 at 5:05 PM, Brian Norris <briannorris@chromium.org> wrote:
>> >> > 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.
>> >>
>> >> I'd rather have something like this:
>> >>
>> >> https://marc.info/?m=147547436324674&w=2
>> >>
>> >> Instead of having everybody move things over. I.e. make it easy to
>> >> refer to the arm version from arm64 instead of creating a "common"
>> >> layer inbetween.
>> >
>> > just so it gets noticed, I've done and tested [0], which hopefully should
>> > implement your suggestions above.
>> >
>> > If that looks ok, how do you want that picked up? Should I just include
>> > them in my regular rockchip branches or do you to pick them into some
>> > immutable branch, if other surprise-users turn up in time for 4.12?
>>
>> Sigh. I completely dropped the ball on this, and I didn't see it
>> included in any of your pull requests for 4.12 since I never actually
>> acked that approach.
>>
>> I've applied the patches onto a dt/include-paths stable branch, but
>> we're late for merging dependent code on top of it for 4.12.
>
> Didn't you merge the patches into a branch already and the rk3399-gru
> support on top of it?
>
> Aka
> https://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git/log/?h=shared/dt-symlinks
>
> Which one of my previous pull requests was already based on.

Yeah, ignore the above (the original branch is the one to use). I must
be turning blind.

Adding Maxime on Cc since I asked him to move over to the new include
model post-rc1 for some of his stuff.


-Olof

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2017-04-19 13:31 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-10  1:05 [PATCH v2 0/6] arm64: dts: rockchip: support Google Kevin Brian Norris
2017-02-10  1:05 ` [PATCH v2 1/6] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs Brian Norris
2017-02-21 23:47   ` Olof Johansson
2017-02-27 18:20     ` Heiko Stuebner
2017-03-20 23:07       ` Brian Norris
2017-04-19 12:54       ` Olof Johansson
2017-04-19 13:25         ` Heiko Stuebner
2017-04-19 13:31           ` Olof Johansson
2017-02-10  1:05 ` [PATCH v2 2/6] arm64: dts: rockchip: support dwc3 USB for rk3399 Brian Norris
2017-02-10 22:01   ` Heiko Stuebner
2017-02-10  1:05 ` [PATCH v2 3/6] dt-bindings: Document rk3399 Gru/Kevin Brian Norris
2017-02-16  2:12   ` Rob Herring
2017-02-10  1:05 ` [PATCH v2 4/6] arm64: dts: rockchip: add Gru/Kevin DTS Brian Norris
2017-02-28 22:00   ` Heiko Stuebner
2017-02-28 22:54     ` Doug Anderson
2017-02-10  1:05 ` [PATCH v2 5/6] arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Brian Norris
2017-02-10  1:05 ` [PATCH v2 6/6] arm64: dts: rockchip: sort rk3399 by unit address Brian Norris
2017-02-10 21:39   ` Heiko Stuebner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).