* [PATCH 9/9] arm64: dts: rockchip: add regulator info for Kevin digitizer
From: Brian Norris @ 2016-12-02 2:27 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
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris@chromium.org>
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
^ permalink raw reply related
* [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru
From: Brian Norris @ 2016-12-02 2:27 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
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris@chromium.org>
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
^ permalink raw reply related
* [PATCH 7/9] arm64: dts: rockchip: add Gru/Kevin DTS
From: Brian Norris @ 2016-12-02 2:27 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Caesar Wang, Doug Anderson,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Zhong,
Brian Norris
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 6/9] dt-bindings: Document rk3399 Gru/Kevin
From: Brian Norris @ 2016-12-02 2:27 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
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris@chromium.org>
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
^ permalink raw reply related
* [PATCH 5/9] arm64: dts: rockchip: add rk3399 OPPs
From: Brian Norris @ 2016-12-02 2:27 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Caesar Wang, Doug Anderson,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Chris Zhong,
Brian Norris
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/9] arm64: dts: rockchip: support dwc3 USB for rk3399
From: Brian Norris @ 2016-12-02 2:27 UTC (permalink / raw)
To: Heiko Stuebner
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris, Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Chris Zhong, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Caesar Wang
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
^ permalink raw reply related
* [PATCH 3/9] arm64: dts: rockchip: add rk3399 eDP HPD pinctrl
From: Brian Norris @ 2016-12-02 2:27 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
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris@chromium.org>
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
^ permalink raw reply related
* [PATCH 2/9] arm64: dts: rockchip: add rk3399 thermal_zones phandle
From: Brian Norris @ 2016-12-02 2:27 UTC (permalink / raw)
To: Heiko Stuebner
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris, Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Chris Zhong, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Caesar Wang
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
We're going to need to amend this table in board files.
Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.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
^ permalink raw reply related
* [PATCH 1/9] arm64: dts: Add symlinks for cros-ec-keyboard and cros-ec-sbs
From: Brian Norris @ 2016-12-02 2:27 UTC (permalink / raw)
To: Heiko Stuebner
Cc: devicetree, Brian Norris, Doug Anderson, linux-kernel,
linux-rockchip, Rob Herring, Chris Zhong, Stephen Barber,
linux-arm-kernel, Caesar Wang
In-Reply-To: <1480645653-36943-1-git-send-email-briannorris@chromium.org>
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
^ permalink raw reply related
* [PATCH 0/9] arm64: dts: rockchip: support Google Kevin
From: Brian Norris @ 2016-12-02 2:27 UTC (permalink / raw)
To: Heiko Stuebner
Cc: devicetree, Brian Norris, Doug Anderson, linux-kernel,
linux-rockchip, Rob Herring, Chris Zhong, Stephen Barber,
linux-arm-kernel, Caesar Wang
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
^ permalink raw reply
* [PATCH v3 2/2] mmc: sdhci-cadence: add Cadence SD4HC support
From: Masahiro Yamada @ 2016-12-02 2:21 UTC (permalink / raw)
To: linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: Adrian Hunter, Ulf Hansson, Masahiro Yamada,
devicetree-u79uwXL29TY76Z2rM5mHXA, Joshua Henderson,
Linus Walleij, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stefan Wahren,
Rob Herring, Al Cooper, Wolfram Sang, Andrei Pistirica,
Mark Rutland, Simon Horman, Geert Uytterhoeven
In-Reply-To: <1480645311-13004-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Add a driver for the Cadence SD4HC SD/SDIO/eMMC Controller.
For SD, it basically relies on the SDHCI standard code.
For eMMC, this driver provides some callbacks to support the
hardware part that is specific to this IP design.
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
---
Changes in v3:
- Remove unneeded explanation about HRS and SRS from DT binding;
the offsets to HRS/SRS are fixed for this hardware and this is
quite normal, like each hardware has a fixed register view except
the register base. The detailed register map is what the driver
cares about, so no need to explain it in the binding.
Changes in v2:
- Remove unnecessary "select MMC_SDHCI_IO_ACCESSORS"
.../devicetree/bindings/mmc/sdhci-cadence.txt | 30 +++
drivers/mmc/host/Kconfig | 11 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-cadence.c | 279 +++++++++++++++++++++
4 files changed, 321 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
create mode 100644 drivers/mmc/host/sdhci-cadence.c
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
new file mode 100644
index 0000000..750374f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
@@ -0,0 +1,30 @@
+* Cadence SD/SDIO/eMMC Host Controller
+
+Required properties:
+- compatible: should be "cdns,sd4hc".
+- reg: offset and length of the register set for the device.
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+For eMMC configuration, supported speed modes are not indicated by the SDHCI
+Capabilities Register. Instead, the following properties should be specified
+if supported. See mmc.txt for details.
+- mmc-ddr-1_8v
+- mmc-ddr-1_2v
+- mmc-hs200-1_8v
+- mmc-hs200-1_2v
+- mmc-hs400-1_8v
+- mmc-hs400-1_2v
+
+Example:
+ emmc: sdhci@5a000000 {
+ compatible = "cdns,sd4hc";
+ reg = <0x5a000000 0x400>;
+ interrupts = <0 78 4>;
+ clocks = <&clk 4>;
+ bus-width = <8>;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index ab9181e..8ac1640 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -164,6 +164,17 @@ config MMC_SDHCI_OF_HLWD
If unsure, say N.
+config MMC_SDHCI_CADENCE
+ tristate "SDHCI support for the Cadence SD/SDIO/eMMC controller"
+ depends on MMC_SDHCI_PLTFM
+ depends on OF
+ help
+ This selects the Cadence SD/SDIO/eMMC driver.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_SDHCI_CNS3XXX
tristate "SDHCI support on the Cavium Networks CNS3xxx SoC"
depends on ARCH_CNS3XXX
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e49a82a..55f7193 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_MMC_REALTEK_PCI) += rtsx_pci_sdmmc.o
obj-$(CONFIG_MMC_REALTEK_USB) += rtsx_usb_sdmmc.o
obj-$(CONFIG_MMC_SDHCI_PLTFM) += sdhci-pltfm.o
+obj-$(CONFIG_MMC_SDHCI_CADENCE) += sdhci-cadence.o
obj-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
obj-$(CONFIG_MMC_SDHCI_DOVE) += sdhci-dove.o
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
new file mode 100644
index 0000000..a7daf00
--- /dev/null
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (C) 2016 Socionext Inc.
+ * Author: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
+ *
+ * This program 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 program 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.
+ */
+
+#include <linux/bitops.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mmc/host.h>
+
+#include "sdhci-pltfm.h"
+
+/* HRS - Host Register Set (specific to Cadence) */
+#define SDHCI_CDNS_HRS04 0x10 /* PHY access port */
+#define SDHCI_CDNS_HRS04_ACK BIT(26)
+#define SDHCI_CDNS_HRS04_RD BIT(25)
+#define SDHCI_CDNS_HRS04_WR BIT(24)
+#define SDHCI_CDNS_HRS04_RDATA_SHIFT 12
+#define SDHCI_CDNS_HRS04_WDATA_SHIFT 8
+#define SDHCI_CDNS_HRS04_ADDR_SHIFT 0
+
+#define SDHCI_CDNS_HRS06 0x18 /* eMMC control */
+#define SDHCI_CDNS_HRS06_TUNE_UP BIT(15)
+#define SDHCI_CDNS_HRS06_TUNE_SHIFT 8
+#define SDHCI_CDNS_HRS06_TUNE_MASK 0x3f
+#define SDHCI_CDNS_HRS06_MODE_MASK 0x7
+#define SDHCI_CDNS_HRS06_MODE_SD 0x0
+#define SDHCI_CDNS_HRS06_MODE_MMC_SDR 0x2
+#define SDHCI_CDNS_HRS06_MODE_MMC_DDR 0x3
+#define SDHCI_CDNS_HRS06_MODE_MMC_HS200 0x4
+#define SDHCI_CDNS_HRS06_MODE_MMC_HS400 0x5
+
+/* SRS - Slot Register Set (SDHCI-compatible) */
+#define SDHCI_CDNS_SRS_BASE 0x200
+
+/* PHY */
+#define SDHCI_CDNS_PHY_DLY_SD_HS 0x00
+#define SDHCI_CDNS_PHY_DLY_SD_DEFAULT 0x01
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR12 0x02
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR25 0x03
+#define SDHCI_CDNS_PHY_DLY_UHS_SDR50 0x04
+#define SDHCI_CDNS_PHY_DLY_UHS_DDR50 0x05
+#define SDHCI_CDNS_PHY_DLY_EMMC_LEGACY 0x06
+#define SDHCI_CDNS_PHY_DLY_EMMC_SDR 0x07
+#define SDHCI_CDNS_PHY_DLY_EMMC_DDR 0x08
+
+/*
+ * The tuned val register is 6 bit-wide, but not the whole of the range is
+ * available. The range 0-42 seems to be available (then 43 wraps around to 0)
+ * but I am not quite sure if it is official. Use only 0 to 39 for safety.
+ */
+#define SDHCI_CDNS_MAX_TUNING_LOOP 40
+
+struct sdhci_cdns_priv {
+ void __iomem *hrs_addr;
+};
+
+static void sdhci_cdns_write_phy_reg(struct sdhci_cdns_priv *priv,
+ u8 addr, u8 data)
+{
+ void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS04;
+ u32 tmp;
+
+ tmp = (data << SDHCI_CDNS_HRS04_WDATA_SHIFT) |
+ (addr << SDHCI_CDNS_HRS04_ADDR_SHIFT);
+ writel(tmp, reg);
+
+ tmp |= SDHCI_CDNS_HRS04_WR;
+ writel(tmp, reg);
+
+ tmp &= ~SDHCI_CDNS_HRS04_WR;
+ writel(tmp, reg);
+}
+
+static void sdhci_cdns_phy_init(struct sdhci_cdns_priv *priv)
+{
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_SD_HS, 4);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_SD_DEFAULT, 4);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_EMMC_LEGACY, 9);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_EMMC_SDR, 2);
+ sdhci_cdns_write_phy_reg(priv, SDHCI_CDNS_PHY_DLY_EMMC_DDR, 3);
+}
+
+static inline void *sdhci_cdns_priv(struct sdhci_host *host)
+{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+ return sdhci_pltfm_priv(pltfm_host);
+}
+
+static unsigned int sdhci_cdns_get_timeout_clock(struct sdhci_host *host)
+{
+ /*
+ * Cadence's spec says the Timeout Clock Frequency is the same as the
+ * Base Clock Frequency. Divide it by 1000 to return a value in kHz.
+ */
+ return host->max_clk / 1000;
+}
+
+static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
+{
+ struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+ void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS06;
+ u32 tmp;
+
+ if (WARN_ON(val > SDHCI_CDNS_HRS06_TUNE_MASK))
+ return -EINVAL;
+
+ tmp = readl(reg);
+ tmp &= ~(SDHCI_CDNS_HRS06_TUNE_MASK << SDHCI_CDNS_HRS06_TUNE_SHIFT);
+ tmp |= val << SDHCI_CDNS_HRS06_TUNE_SHIFT;
+ tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
+ writel(tmp, reg);
+
+ return readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
+ 0, 1);
+}
+
+static int sdhci_cdns_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ int max_streak = 0;
+ int cur_streak = 0;
+ int end_of_streak, i;
+
+ /*
+ * This handler only implements the eMMC tuning that is specific to
+ * this controller. Fall back to the standard method for SD timing.
+ */
+ if (host->timing != MMC_TIMING_MMC_HS200)
+ return -ENOTSUPP;
+
+ if (WARN_ON(opcode != MMC_SEND_TUNING_BLOCK_HS200))
+ return -EINVAL;
+
+ for (i = 0; i < SDHCI_CDNS_MAX_TUNING_LOOP; i++) {
+ if (sdhci_cdns_set_tune_val(host, i) ||
+ mmc_send_tuning(host->mmc, opcode, NULL)) { /* bad */
+ cur_streak = 0;
+ } else { /* good */
+ cur_streak++;
+ max_streak = max(max_streak, cur_streak);
+ end_of_streak = i;
+ }
+ }
+
+ if (!max_streak) {
+ dev_err(mmc_dev(host->mmc), "no tuning point found\n");
+ return -EIO;
+ }
+
+ return sdhci_cdns_set_tune_val(host, end_of_streak - max_streak / 2);
+}
+
+static void sdhci_cdns_set_uhs_signaling(struct sdhci_host *host,
+ unsigned int timing)
+{
+ struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
+ u32 mode, tmp;
+
+ switch (timing) {
+ case MMC_TIMING_MMC_HS:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_SDR;
+ break;
+ case MMC_TIMING_MMC_DDR52:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_DDR;
+ break;
+ case MMC_TIMING_MMC_HS200:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_HS200;
+ break;
+ case MMC_TIMING_MMC_HS400:
+ mode = SDHCI_CDNS_HRS06_MODE_MMC_HS400;
+ break;
+ default:
+ mode = SDHCI_CDNS_HRS06_MODE_SD;
+ break;
+ }
+
+ /* The speed mode for eMMC is selected by HRS06 register */
+ tmp = readl(priv->hrs_addr + SDHCI_CDNS_HRS06);
+ tmp &= ~SDHCI_CDNS_HRS06_MODE_MASK;
+ tmp |= mode;
+ writel(tmp, priv->hrs_addr + SDHCI_CDNS_HRS06);
+
+ /* For SD, fall back to the default handler */
+ if (mode == SDHCI_CDNS_HRS06_MODE_SD)
+ sdhci_set_uhs_signaling(host, timing);
+}
+
+static const struct sdhci_ops sdhci_cdns_ops = {
+ .set_clock = sdhci_set_clock,
+ .get_timeout_clock = sdhci_cdns_get_timeout_clock,
+ .set_bus_width = sdhci_set_bus_width,
+ .reset = sdhci_reset,
+ .platform_execute_tuning = sdhci_cdns_execute_tuning,
+ .set_uhs_signaling = sdhci_cdns_set_uhs_signaling,
+};
+
+static const struct sdhci_pltfm_data sdhci_cdns_pltfm_data = {
+ .ops = &sdhci_cdns_ops,
+};
+
+static int sdhci_cdns_probe(struct platform_device *pdev)
+{
+ struct sdhci_host *host;
+ struct sdhci_pltfm_host *pltfm_host;
+ struct sdhci_cdns_priv *priv;
+ struct clk *clk;
+ int ret;
+
+ clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
+
+ ret = clk_prepare_enable(clk);
+ if (ret)
+ return ret;
+
+ host = sdhci_pltfm_init(pdev, &sdhci_cdns_pltfm_data, sizeof(*priv));
+ if (IS_ERR(host)) {
+ ret = PTR_ERR(host);
+ goto disable_clk;
+ }
+
+ pltfm_host = sdhci_priv(host);
+ pltfm_host->clk = clk;
+
+ priv = sdhci_cdns_priv(host);
+ priv->hrs_addr = host->ioaddr;
+ host->ioaddr += SDHCI_CDNS_SRS_BASE;
+
+ ret = mmc_of_parse(host->mmc);
+ if (ret)
+ goto free;
+
+ sdhci_cdns_phy_init(priv);
+
+ ret = sdhci_add_host(host);
+ if (ret)
+ goto free;
+
+ return 0;
+free:
+ sdhci_pltfm_free(pdev);
+disable_clk:
+ clk_disable_unprepare(clk);
+
+ return ret;
+}
+
+static const struct of_device_id sdhci_cdns_match[] = {
+ { .compatible = "cdns,sd4hc" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sdhci_cdns_match);
+
+static struct platform_driver sdhci_cdns_driver = {
+ .driver = {
+ .name = "sdhci-cdns",
+ .pm = &sdhci_pltfm_pmops,
+ .of_match_table = sdhci_cdns_match,
+ },
+ .probe = sdhci_cdns_probe,
+ .remove = sdhci_pltfm_unregister,
+};
+module_platform_driver(sdhci_cdns_driver);
+
+MODULE_AUTHOR("Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>");
+MODULE_DESCRIPTION("Cadence SD/SDIO/eMMC Host Controller Driver");
+MODULE_LICENSE("GPL");
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 0/2] mmc: sdhci: one expansion for SDHCI base code and add Cadence SDHCI driver
From: Masahiro Yamada @ 2016-12-02 2:21 UTC (permalink / raw)
To: linux-mmc
Cc: Adrian Hunter, Ulf Hansson, Masahiro Yamada, devicetree,
Joshua Henderson, Linus Walleij, linux-kernel, Stefan Wahren,
Rob Herring, Al Cooper, Wolfram Sang, Andrei Pistirica,
Mark Rutland, Simon Horman, Geert Uytterhoeven
1/2 tweaks sdhci_execute_tuning(), which I want to use for 2/2.
2/2 adds a new driver for Cadence's controller IP.
Masahiro Yamada (2):
mmc: sdhci: continue normal tuning if unsupported by platform tuning
mmc: sdhci-cadence: add Cadence SD4HC support
.../devicetree/bindings/mmc/sdhci-cadence.txt | 30 +++
drivers/mmc/host/Kconfig | 11 +
drivers/mmc/host/Makefile | 1 +
drivers/mmc/host/sdhci-cadence.c | 279 +++++++++++++++++++++
drivers/mmc/host/sdhci.c | 4 +-
5 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
create mode 100644 drivers/mmc/host/sdhci-cadence.c
--
2.7.4
^ permalink raw reply
* [PATCH] arm: dts: mt2701: Sort DT nodes by register address
From: James Liao @ 2016-12-02 2:06 UTC (permalink / raw)
To: Matthias Brugger
Cc: Rob Herring, Russell King, Mark Rutland,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, James Liao
This patch rearrange MT2701 DT nodes to keep them in ascending order.
Signed-off-by: James Liao <jamesjj.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
This patch is based on latest v4.9-next/dts branch of [1], to fix MT2701
DT nodes ordering.
[1] https://github.com/mbgg/linux-mediatek/tree/v4.9-next/dts
arch/arm/boot/dts/mt2701.dtsi | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 7eab6f4..73f4b7c 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -96,24 +96,6 @@
<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
- pio: pinctrl@10005000 {
- compatible = "mediatek,mt2701-pinctrl";
- reg = <0 0x1000b000 0 0x1000>;
- mediatek,pctl-regmap = <&syscfg_pctl_a>;
- pins-are-numbered;
- gpio-controller;
- #gpio-cells = <2>;
- interrupt-controller;
- #interrupt-cells = <2>;
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
- };
-
- syscfg_pctl_a: syscfg@10005000 {
- compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
- reg = <0 0x10005000 0 0x1000>;
- };
-
topckgen: syscon@10000000 {
compatible = "mediatek,mt2701-topckgen", "syscon";
reg = <0 0x10000000 0 0x1000>;
@@ -134,6 +116,24 @@
#reset-cells = <1>;
};
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt2701-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl_a>;
+ pins-are-numbered;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ syscfg_pctl_a: syscfg@10005000 {
+ compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
+ reg = <0 0x10005000 0 0x1000>;
+ };
+
watchdog: watchdog@10007000 {
compatible = "mediatek,mt2701-wdt",
"mediatek,mt6589-wdt";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2016-12-02 1:18 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Benoît Cousson
In-Reply-To: <1480528685-26259-1-git-send-email-laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
* Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161130 09:58]:
> &usbhsehci {
> phys = <0 &hsusb2_phy>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb2@2 {
I think this should be usb1@2 instead of usb2@2? That's because it's
at /sys/bus/usb/devices/1-2 and not at /sys/bus/usb/devices/2-2?
Or what's the naming standard here?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/2] HID: i2c-hid: support regulator power on/off
From: Dmitry Torokhov @ 2016-12-02 1:16 UTC (permalink / raw)
To: Brian Norris
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Doug Anderson
In-Reply-To: <20161202004214.GA112550-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Thu, Dec 01, 2016 at 04:42:15PM -0800, Brian Norris wrote:
> Hi Dmitry,
>
> On Thu, Dec 01, 2016 at 04:37:37PM -0800, Dmitry Torokhov wrote:
> > On Thu, Dec 01, 2016 at 04:31:10PM -0800, Brian Norris wrote:
> > > On some boards, we need to enable a regulator before using the HID, and
> > > it's also nice to save power in suspend by disabling it. Support an
> > > optional "vdd-supply" and a companion initialization delay.
> > >
> > > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > ---
> > > v2:
> > > * support compatible property for wacom, with specific "vdd-supply" name
> > > * support the 100ms delay needed for this digitizer
> > > * target regulator support only at specific device
> > >
> > > v3:
> > > * drop Wacom specifics and allow this to be used generically
> > > * add "init-delay-ms" property support
> > >
> > > drivers/hid/i2c-hid/i2c-hid.c | 48 ++++++++++++++++++++++++++++++++++++++++++-
> > > include/linux/i2c/i2c-hid.h | 6 ++++++
> > > 2 files changed, 53 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> > > index b3ec4f2de875..4cb523133d13 100644
> > > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > > @@ -37,7 +37,9 @@
> > > #include <linux/mutex.h>
> > > #include <linux/acpi.h>
> > > #include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > #include <linux/gpio/consumer.h>
> > > +#include <linux/regulator/consumer.h>
> > >
> > > #include <linux/i2c/i2c-hid.h>
> > >
> > > @@ -937,6 +939,22 @@ static int i2c_hid_of_probe(struct i2c_client *client,
> > > }
> > > pdata->hid_descriptor_address = val;
> > >
> > > + ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val);
> > > + if (!ret)
> > > + pdata->init_delay_ms = ret;
> > > +
> > > + pdata->supply = devm_regulator_get_optional(dev, "vdd");
> >
> > Make it devm_regulator_get(), it's cleaner (you'll get a dummy regulator
> > that you can enable/disbale and not check if it is null or not).
> >
> > pdata->supply = devm_regulator_get_optional(dev, "vdd");
> > if (IS_ERR(pdata->supply)) {
> > ret = PTR_ERR(pdata->supply);
> > if (ret != -EPROBE_DEFER)
> > dev_err(...);
> > return ret;
> > }
>
> I had it as devm_regulator_get() in v1, but at that time, I was faking
> the firmware init delay using a regulator property. Now that I want to
> delay in this driver after enabling the regulator, I'd like to know the
> difference between a dummy and a real regulator. There's no need to wait
> after messing with the dummy regulator.
If there is no regulator in ACPI/DT there would not be "init-delay-ms"
property either.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/3] of: Support parsing phandle argument lists through a nexus node
From: Stephen Boyd @ 2016-12-02 1:10 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree@vger.kernel.org, Linus Walleij, Pantelis Antoniou,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
Mark Brown, Frank Rowand, linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAL_JsqKZ_Ohcdi0n6XU+5=3o6OwC=r_5Cv1=gx7mytUUVd2dzA@mail.gmail.com>
Quoting Rob Herring (2016-11-30 15:30:47)
> On Thu, Nov 24, 2016 at 4:25 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > Platforms like 96boards have a standardized connector/expansion
> > slot that exposes signals like GPIOs to expansion boards in an
> > SoC agnostic way. We'd like the DT overlays for the expansion
> > boards to be written once without knowledge of the SoC on the
> > other side of the connector. This avoids the unscalable
> > combinatorial explosion of a different DT overlay for each
> > expansion board and SoC pair.
> >
> > We need a way to describe the GPIOs routed through the connector
> > in an SoC agnostic way. Let's introduce nexus property parsing
> > into the OF core to do this. This is largely based on the
> > interrupt nexus support we already have. This allows us to remap
> > a phandle list in a consumer node (e.g. reset-gpios) through a
> > connector in a generic way (e.g. via gpio-map). Do this in a
> > generic routine so that we can remap any sort of variable length
> > phandle list.
> >
> > Taking GPIOs as an example, the connector would be a GPIO nexus,
> > supporting the remapping of a GPIO specifier space to multiple
> > GPIO providers on the SoC. DT would look as shown below, where
> > 'soc_gpio1' and 'soc_gpio2' are inside the SoC, 'connector' is an
> > expansion port where boards can be plugged in, and
> > 'expansion_device' is a device on the expansion board.
> >
> > soc {
> > soc_gpio1: gpio-controller1 {
> > #gpio-cells = <2>;
> > };
> >
> > soc_gpio2: gpio-controller2 {
> > #gpio-cells = <2>;
> > };
> > };
> >
> > connector: connector {
> > #gpio-cells = <2>;
> > gpio-map = <0 GPIO_ACTIVE_LOW &soc_gpio1 1 GPIO_ACTIVE_LOW>,
> > <1 GPIO_ACTIVE_LOW &soc_gpio2 4 GPIO_ACTIVE_LOW>,
> > <2 GPIO_ACTIVE_LOW &soc_gpio1 3 GPIO_ACTIVE_LOW>,
> > <3 GPIO_ACTIVE_LOW &soc_gpio2 2 GPIO_ACTIVE_LOW>;
> > gpio-map-mask = <0xf 0x1>;
>
> I think the common case is something more like this:
>
> gpio-map = <0 0 &soc_gpio1 1 0>,
> <1 0 &soc_gpio2 4 0>,
> <2 0 &soc_gpio1 3 0>,
> <3 0 &soc_gpio2 2 0>;
> gpio-map-mask = <0xf 0>;
>
> where we want to pass the 2nd cell of the consumer (e.g. reset-gpios)
> thru. So here the GPIO_ACTIVE_LOW flag below needs to pass thru to
> &soc_gpio1. Otherwise, the gpio-map is has to enumerate every possible
> combination or it will be specific to the daughterboard's usage.
>
> Also, GPIO cells are pretty well standardized, but some cases may need
> a translation function which I guess would be part of a connector
> driver. I don't think that affects the binding nor needs to be solved
> now, but just want to raise that possibility.
Right. I think that translation function could be done with DT though.
For example, we could remap an ACTIVE_LOW flag to an ACTIVE_HIGH flag,
by matching the GPIO on active low and changing it to active high during
the remap. That seems like something we can solve now if it ever happens
by keeping the remapping scheme that interrupts does. Of course, if it
becomes more complicated this breaks down, but then we can always have
the connector driver do the more complicated stuff.
If we want to support pass through, perhaps we should introduce yet
another property to indicate which cells and maybe even which bits in
those cells should be passed through from one side to the other. That
way we can support a compressed scheme without requiring all the
combinations of gpios and flags to be listed out.
For example, gpio-map-pass-thru = <0x0 0xff> would mean that we should
pass through the second cell values that are the lower 8 bits. Map
matching would still be done with the map-mask property, but this
property would indicate which part of the specifier to mask out of the
other side when copying it over.
>
> > };
> >
> > expansion_device {
> > reset-gpios = <&connector 2 GPIO_ACTIVE_LOW>;
> > };
> >
> > The GPIO core would use of_parse_phandle_with_args_map() instead
> > of of_parse_phandle_with_args() and arrive at the same type of
> > result, a phandle and argument list. The difference is that the
> > phandle and arguments will be remapped through the nexus node to
> > the underlying SoC GPIO controller node. In the example above,
> > we would remap 'reset-gpios' from <&connector 2 GPIO_ACTIVE_LOW>
> > to <&soc_gpio1 3 GPIO_ACTIVE_LOW>.
>
> GPIOs also are interrupts frequently, so we need to make sure
> interrupt translation works too. It's a bit tricky as interrupt-map
> depends on #address-cells and #interrupt-cells. I think we just set
> the #address-cells to 0 on the connector node and it will be fine. We
> may need the same pass thru of flags though.
Right I think that should work but I haven't tested it so far.
Unfortunately, interrupt mapping doesn't have pass through support, so
we may want to add the same pass through mask property there and update
the interrupt mapping code too? I was trying to figure out how to make
the interrupt code and this function the same, but the whole
interrupt-parent scan made it feel unwieldy to the point where I gave
up.
>
> >
> > Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Mark Brown <broonie@kernel.org>
> > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > ---
> > drivers/of/base.c | 146 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/of.h | 14 +++++
> > 2 files changed, 160 insertions(+)
> >
> > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > index d687e6de24a0..693b73f33675 100644
> > --- a/drivers/of/base.c
> > +++ b/drivers/of/base.c
> > @@ -1772,6 +1772,152 @@ int of_parse_phandle_with_args(const struct device_node *np, const char *list_na
> > EXPORT_SYMBOL(of_parse_phandle_with_args);
> >
> > /**
> > + * of_parse_phandle_with_args_map() - Find a node pointed by phandle in a list and remap it
> > + * @np: pointer to a device tree node containing a list
> > + * @list_name: property name that contains a list
> > + * @cells_name: property name that specifies phandles' arguments count
> > + * @index: index of a phandle to parse out
> > + * @out_args: optional pointer to output arguments structure (will be filled)
> > + *
> > + * This function is useful to parse lists of phandles and their arguments.
> > + * Returns 0 on success and fills out_args, on error returns appropriate
> > + * errno value.
> > + *
> > + * Caller is responsible to call of_node_put() on the returned out_args->np
> > + * pointer.
> > + *
> > + * Example:
> > + *
> > + * phandle1: node1 {
> > + * #list-cells = <2>;
> > + * }
> > + *
> > + * phandle2: node2 {
> > + * #list-cells = <1>;
> > + * }
> > + *
> > + * phandle3: node3 {
> > + * #list-cells = <1>;
> > + * list-map = <0 &phandle2 3>,
> > + * <1 &phandle2 2>,
> > + * <2 &phandle1 5 1>;
> > + * list-map-mask = <0x3>;
> > + * };
> > + *
> > + * node4 {
> > + * list = <&phandle1 1 2 &phandle3 0>;
> > + * }
> > + *
> > + * To get a device_node of the `node2' node you may call this:
> > + * of_parse_phandle_with_args(node4, "list", "#list-cells", "list-map",
> > + * "list-map-mask", 1, &args);
> > + */
> > +int of_parse_phandle_with_args_map(const struct device_node *np,
> > + const char *list_name,
> > + const char *cells_name,
> > + const char *map_name,
> > + const char *mask_name,
>
> Perhaps these 3 could be just a single base name (e.g. "gpio")?
> Doesn't really buy much other than enforce we don't mix 'gpios' and
> 'gpio'. That could never happen. ;)
>
I thought about that. I was worried that we wanted to support this API
being called in atomic context, but that seems like it can't possibly be
the case. So I'll have to allocate a string for each of those and free
them on exit. Should be ok.
^ permalink raw reply
* Re: [PATCH] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2016-12-02 0:50 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Benoît Cousson
In-Reply-To: <20161202002921.GD3703-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161201 16:29]:
> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161201 13:45]:
> > * Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161201 13:37]:
> > > Hi Tony,
> > >
> > > On Thursday 01 Dec 2016 13:12:34 Tony Lindgren wrote:
> > > > * Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161130 09:58]:
> > > > > The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> > > > > connected to port 2 of the OMAP EHCI controller. The board however has
> > > > > no EEPROM to store the ethernet MAC address, which is programmed by the
> > > > > boot loader.
> > > > >
> > > > > To allow Linux to use the same MAC address as the boot loader (or for
> > > > > that matter any fixed MAC address), we need a node in the device tree
> > > > > for the ethernet controller that the boot loader can update at runtime
> > > > > with a local-mac-address property. Add it, along with an alias for the
> > > > > ethernet controller to let the boot loader locate it easily.
> > > >
> > > > Does not seem to work here.. Do I need to set something in u-boot?
> > > > I'm using U-Boot 2016.09-00004-g26bb688.
> > >
> > > Some versions (possibly forked by vendors) might set the MAC address
> > > automatically in DT, but in my case I have the following in my boot script:
> > >
> > > tftp 0x80800000 beagle/omap3-beagle-xm.dtb
> > > fdt addr ${fileaddr} ${filesize}
> > > fdt resize
> > > fdt set /ocp@68000000/usbhshost@48064000/ehci@48064800/usb2@2/usbether@1 local-mac-address "[7a d2 a0 00 d1 f0]"
> >
> > OK. I just added setenv ethaddr ${usbethaddr} to my bootcmd..
>
> Here's a similar patch for omap5-uevm. Somehow u-boot does not populate the
> local-mac-address on it though although set in the environment.
>
> So I had to manually do the fdt set /ocp/usbhshost@4a064000/ehci@4a064c00/usbether@3
> command.
And here's one for pandaboard. That gets configured fine if ethaddr is
set.
Regards,
Tony
8< ------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Thu, 1 Dec 2016 16:33:20 -0800
Subject: [PATCH] ARM: dts: pandaboard: Allow bootloader to configure USB
Ethernet MAC
Inspired by a patch for beagleboard xm by Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>, similar patch also works for
pandaboard. The only difference is that the hub is address 1 instead
of 2.
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,6 +16,7 @@
aliases {
display0 = &dvi0;
display1 = &hdmi0;
+ ethernet = ðernet;
};
leds: leds {
@@ -520,6 +521,21 @@
&usbhsehci {
phys = <&hsusb1_phy>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb2@1 {
+ compatible = "usb424,9514";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet: usbether@1 {
+ compatible = "usb424,ec00";
+ reg = <1>;
+ };
+ };
};
&dss {
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
From: Jaehoon Chung @ 2016-12-02 0:48 UTC (permalink / raw)
To: Sergio Prado, ulf.hansson, robh+dt, mark.rutland, linux-mmc,
devicetree, linux-kernel, ben-linux, linux-arm-kernel
In-Reply-To: <1480637665-6325-2-git-send-email-sergio.prado@e-labworks.com>
On 12/02/2016 09:14 AM, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C24XX
> MMC/SD/SDIO controller, used as a connectivity interface with external
> MMC, SD and SDIO storage mediums.
>
> Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
> ---
> .../devicetree/bindings/mmc/samsung,s3cmci.txt | 38 ++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> new file mode 100644
> index 000000000000..3f044076e69a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
> @@ -0,0 +1,38 @@
> +* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
> +
> +Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
> +with external MMC, SD and SDIO storage mediums.
> +
> +This file documents differences between the core mmc properties described by
> +mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
> +implementation.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> + - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
> + - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
> + - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
> +- clocks: Should reference the controller clock
> +- clock-names: Should contain "sdi"
> +
> +Required Board Specific Properties:
> +- pinctrl-0: Should specify pin control groups used for this controller.
> +- pinctrl-names: Should contain only one value - "default".
I'm not sure but i think this description doesn't need at here.
> +
> +Example:
> + sdi: sdi@5a000000 {
I think it needs to use "mmc0: sdi@5a000000" instead of "sdi: sdi@5a000000"
Because mmc is more clear than sdi.
> + compatible = "samsung,s3c2440-sdi";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdi_pins>;
> + reg = <0x5a000000 0x100000>;
> + interrupts = <0 0 21 3>;
> + clocks = <&clocks PCLK_SDI>;
> + clock-names = "sdi";
> + bus-width = <4>;
> + cd-gpios = <&gpg 8 GPIO_ACTIVE_LOW>;
> + wp-gpios = <&gph 8 GPIO_ACTIVE_LOW>;
> + };
> +
> + Note: This example shows both SoC specific and board specific properties
> + in a single device node. The properties can be actually be separated
> + into SoC specific node and board specific node.
>
^ permalink raw reply
* Re: [PATCH v3 2/2] HID: i2c-hid: support regulator power on/off
From: Brian Norris @ 2016-12-02 0:42 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang, linux-rockchip,
Rob Herring, linux-input, devicetree, linux-kernel, Mark Rutland,
Doug Anderson
In-Reply-To: <20161202003737.GA24901@dtor-ws>
Hi Dmitry,
On Thu, Dec 01, 2016 at 04:37:37PM -0800, Dmitry Torokhov wrote:
> On Thu, Dec 01, 2016 at 04:31:10PM -0800, Brian Norris wrote:
> > On some boards, we need to enable a regulator before using the HID, and
> > it's also nice to save power in suspend by disabling it. Support an
> > optional "vdd-supply" and a companion initialization delay.
> >
> > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> > Cc: Jiri Kosina <jikos@kernel.org>
> > Cc: linux-input@vger.kernel.org
> > ---
> > v2:
> > * support compatible property for wacom, with specific "vdd-supply" name
> > * support the 100ms delay needed for this digitizer
> > * target regulator support only at specific device
> >
> > v3:
> > * drop Wacom specifics and allow this to be used generically
> > * add "init-delay-ms" property support
> >
> > drivers/hid/i2c-hid/i2c-hid.c | 48 ++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/i2c/i2c-hid.h | 6 ++++++
> > 2 files changed, 53 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> > index b3ec4f2de875..4cb523133d13 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > @@ -37,7 +37,9 @@
> > #include <linux/mutex.h>
> > #include <linux/acpi.h>
> > #include <linux/of.h>
> > +#include <linux/of_device.h>
> > #include <linux/gpio/consumer.h>
> > +#include <linux/regulator/consumer.h>
> >
> > #include <linux/i2c/i2c-hid.h>
> >
> > @@ -937,6 +939,22 @@ static int i2c_hid_of_probe(struct i2c_client *client,
> > }
> > pdata->hid_descriptor_address = val;
> >
> > + ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val);
> > + if (!ret)
> > + pdata->init_delay_ms = ret;
> > +
> > + pdata->supply = devm_regulator_get_optional(dev, "vdd");
>
> Make it devm_regulator_get(), it's cleaner (you'll get a dummy regulator
> that you can enable/disbale and not check if it is null or not).
>
> pdata->supply = devm_regulator_get_optional(dev, "vdd");
> if (IS_ERR(pdata->supply)) {
> ret = PTR_ERR(pdata->supply);
> if (ret != -EPROBE_DEFER)
> dev_err(...);
> return ret;
> }
I had it as devm_regulator_get() in v1, but at that time, I was faking
the firmware init delay using a regulator property. Now that I want to
delay in this driver after enabling the regulator, I'd like to know the
difference between a dummy and a real regulator. There's no need to wait
after messing with the dummy regulator.
Brian
^ permalink raw reply
* Re: [PATCH v3 2/2] HID: i2c-hid: support regulator power on/off
From: Dmitry Torokhov @ 2016-12-02 0:37 UTC (permalink / raw)
To: Brian Norris
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang, linux-rockchip,
Rob Herring, linux-input, devicetree, linux-kernel, Mark Rutland,
Doug Anderson
In-Reply-To: <1480638670-111492-2-git-send-email-briannorris@chromium.org>
On Thu, Dec 01, 2016 at 04:31:10PM -0800, Brian Norris wrote:
> On some boards, we need to enable a regulator before using the HID, and
> it's also nice to save power in suspend by disabling it. Support an
> optional "vdd-supply" and a companion initialization delay.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: linux-input@vger.kernel.org
> ---
> v2:
> * support compatible property for wacom, with specific "vdd-supply" name
> * support the 100ms delay needed for this digitizer
> * target regulator support only at specific device
>
> v3:
> * drop Wacom specifics and allow this to be used generically
> * add "init-delay-ms" property support
>
> drivers/hid/i2c-hid/i2c-hid.c | 48 ++++++++++++++++++++++++++++++++++++++++++-
> include/linux/i2c/i2c-hid.h | 6 ++++++
> 2 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index b3ec4f2de875..4cb523133d13 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -37,7 +37,9 @@
> #include <linux/mutex.h>
> #include <linux/acpi.h>
> #include <linux/of.h>
> +#include <linux/of_device.h>
> #include <linux/gpio/consumer.h>
> +#include <linux/regulator/consumer.h>
>
> #include <linux/i2c/i2c-hid.h>
>
> @@ -937,6 +939,22 @@ static int i2c_hid_of_probe(struct i2c_client *client,
> }
> pdata->hid_descriptor_address = val;
>
> + ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val);
> + if (!ret)
> + pdata->init_delay_ms = ret;
> +
> + pdata->supply = devm_regulator_get_optional(dev, "vdd");
Make it devm_regulator_get(), it's cleaner (you'll get a dummy regulator
that you can enable/disbale and not check if it is null or not).
pdata->supply = devm_regulator_get_optional(dev, "vdd");
if (IS_ERR(pdata->supply)) {
ret = PTR_ERR(pdata->supply);
if (ret != -EPROBE_DEFER)
dev_err(...);
return ret;
}
Thanks.
> + if (IS_ERR(pdata->supply)) {
> + ret = PTR_ERR(pdata->supply);
> + pdata->supply = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + if (ret == -ENODEV)
> + return 0;
> + dev_err(dev, "Failed to get regulator: %d\n", ret);
> + return ret;
> + }
> +
> return 0;
> }
>
> @@ -983,6 +1001,17 @@ static int i2c_hid_probe(struct i2c_client *client,
> ihid->pdata = *platform_data;
> }
>
> + if (ihid->pdata.supply) {
> + ret = regulator_enable(ihid->pdata.supply);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to enable regulator: %d\n",
> + ret);
> + return ret;
> + }
> + if (ihid->pdata.init_delay_ms)
> + msleep(ihid->pdata.init_delay_ms);
> + }
> +
> if (client->irq > 0) {
> ihid->irq = client->irq;
> } else if (ACPI_COMPANION(&client->dev)) {
> @@ -1100,6 +1129,9 @@ static int i2c_hid_remove(struct i2c_client *client)
> if (ihid->desc)
> gpiod_put(ihid->desc);
>
> + if (ihid->pdata.supply)
> + regulator_disable(ihid->pdata.supply);
> +
> kfree(ihid);
>
> acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
> @@ -1152,6 +1184,11 @@ static int i2c_hid_suspend(struct device *dev)
> else
> hid_warn(hid, "Failed to enable irq wake: %d\n",
> wake_status);
> + } else if (ihid->pdata.supply) {
> + ret = regulator_disable(ihid->pdata.supply);
> + if (ret < 0)
> + hid_warn(hid, "Failed to disable supply: %d\n",
> + ret);
> }
>
> return 0;
> @@ -1165,7 +1202,16 @@ static int i2c_hid_resume(struct device *dev)
> struct hid_device *hid = ihid->hid;
> int wake_status;
>
> - if (device_may_wakeup(&client->dev) && ihid->irq_wake_enabled) {
> + if (!device_may_wakeup(&client->dev)) {
> + if (ihid->pdata.supply) {
> + ret = regulator_enable(ihid->pdata.supply);
> + if (ret < 0)
> + hid_warn(hid, "Failed to enable supply: %d\n",
> + ret);
> + if (ihid->pdata.init_delay_ms)
> + msleep(ihid->pdata.init_delay_ms);
> + }
> + } else if (ihid->irq_wake_enabled) {
> wake_status = disable_irq_wake(ihid->irq);
> if (!wake_status)
> ihid->irq_wake_enabled = false;
> diff --git a/include/linux/i2c/i2c-hid.h b/include/linux/i2c/i2c-hid.h
> index 7aa901d92058..97688cde4a91 100644
> --- a/include/linux/i2c/i2c-hid.h
> +++ b/include/linux/i2c/i2c-hid.h
> @@ -14,9 +14,13 @@
>
> #include <linux/types.h>
>
> +struct regulator;
> +
> /**
> * struct i2chid_platform_data - used by hid over i2c implementation.
> * @hid_descriptor_address: i2c register where the HID descriptor is stored.
> + * @supply: regulator for powering on the device.
> + * @init_delay_ms: delay after powering on before device is usable.
> *
> * Note that it is the responsibility of the platform driver (or the acpi 5.0
> * driver, or the flattened device tree) to setup the irq related to the gpio in
> @@ -31,6 +35,8 @@
> */
> struct i2c_hid_platform_data {
> u16 hid_descriptor_address;
> + struct regulator *supply;
> + int init_delay_ms;
> };
>
> #endif /* __LINUX_I2C_HID_H */
> --
> 2.8.0.rc3.226.g39d4020
>
--
Dmitry
^ permalink raw reply
* [PATCH v3 2/2] HID: i2c-hid: support regulator power on/off
From: Brian Norris @ 2016-12-02 0:31 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Caesar Wang, linux-rockchip, Rob Herring, linux-input, devicetree,
linux-kernel, Dmitry Torokhov, Mark Rutland, Doug Anderson,
Brian Norris
In-Reply-To: <1480638670-111492-1-git-send-email-briannorris@chromium.org>
On some boards, we need to enable a regulator before using the HID, and
it's also nice to save power in suspend by disabling it. Support an
optional "vdd-supply" and a companion initialization delay.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: linux-input@vger.kernel.org
---
v2:
* support compatible property for wacom, with specific "vdd-supply" name
* support the 100ms delay needed for this digitizer
* target regulator support only at specific device
v3:
* drop Wacom specifics and allow this to be used generically
* add "init-delay-ms" property support
drivers/hid/i2c-hid/i2c-hid.c | 48 ++++++++++++++++++++++++++++++++++++++++++-
include/linux/i2c/i2c-hid.h | 6 ++++++
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index b3ec4f2de875..4cb523133d13 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -37,7 +37,9 @@
#include <linux/mutex.h>
#include <linux/acpi.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
#include <linux/i2c/i2c-hid.h>
@@ -937,6 +939,22 @@ static int i2c_hid_of_probe(struct i2c_client *client,
}
pdata->hid_descriptor_address = val;
+ ret = of_property_read_u32(dev->of_node, "init-delay-ms", &val);
+ if (!ret)
+ pdata->init_delay_ms = ret;
+
+ pdata->supply = devm_regulator_get_optional(dev, "vdd");
+ if (IS_ERR(pdata->supply)) {
+ ret = PTR_ERR(pdata->supply);
+ pdata->supply = NULL;
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ if (ret == -ENODEV)
+ return 0;
+ dev_err(dev, "Failed to get regulator: %d\n", ret);
+ return ret;
+ }
+
return 0;
}
@@ -983,6 +1001,17 @@ static int i2c_hid_probe(struct i2c_client *client,
ihid->pdata = *platform_data;
}
+ if (ihid->pdata.supply) {
+ ret = regulator_enable(ihid->pdata.supply);
+ if (ret < 0) {
+ dev_err(&client->dev, "Failed to enable regulator: %d\n",
+ ret);
+ return ret;
+ }
+ if (ihid->pdata.init_delay_ms)
+ msleep(ihid->pdata.init_delay_ms);
+ }
+
if (client->irq > 0) {
ihid->irq = client->irq;
} else if (ACPI_COMPANION(&client->dev)) {
@@ -1100,6 +1129,9 @@ static int i2c_hid_remove(struct i2c_client *client)
if (ihid->desc)
gpiod_put(ihid->desc);
+ if (ihid->pdata.supply)
+ regulator_disable(ihid->pdata.supply);
+
kfree(ihid);
acpi_dev_remove_driver_gpios(ACPI_COMPANION(&client->dev));
@@ -1152,6 +1184,11 @@ static int i2c_hid_suspend(struct device *dev)
else
hid_warn(hid, "Failed to enable irq wake: %d\n",
wake_status);
+ } else if (ihid->pdata.supply) {
+ ret = regulator_disable(ihid->pdata.supply);
+ if (ret < 0)
+ hid_warn(hid, "Failed to disable supply: %d\n",
+ ret);
}
return 0;
@@ -1165,7 +1202,16 @@ static int i2c_hid_resume(struct device *dev)
struct hid_device *hid = ihid->hid;
int wake_status;
- if (device_may_wakeup(&client->dev) && ihid->irq_wake_enabled) {
+ if (!device_may_wakeup(&client->dev)) {
+ if (ihid->pdata.supply) {
+ ret = regulator_enable(ihid->pdata.supply);
+ if (ret < 0)
+ hid_warn(hid, "Failed to enable supply: %d\n",
+ ret);
+ if (ihid->pdata.init_delay_ms)
+ msleep(ihid->pdata.init_delay_ms);
+ }
+ } else if (ihid->irq_wake_enabled) {
wake_status = disable_irq_wake(ihid->irq);
if (!wake_status)
ihid->irq_wake_enabled = false;
diff --git a/include/linux/i2c/i2c-hid.h b/include/linux/i2c/i2c-hid.h
index 7aa901d92058..97688cde4a91 100644
--- a/include/linux/i2c/i2c-hid.h
+++ b/include/linux/i2c/i2c-hid.h
@@ -14,9 +14,13 @@
#include <linux/types.h>
+struct regulator;
+
/**
* struct i2chid_platform_data - used by hid over i2c implementation.
* @hid_descriptor_address: i2c register where the HID descriptor is stored.
+ * @supply: regulator for powering on the device.
+ * @init_delay_ms: delay after powering on before device is usable.
*
* Note that it is the responsibility of the platform driver (or the acpi 5.0
* driver, or the flattened device tree) to setup the irq related to the gpio in
@@ -31,6 +35,8 @@
*/
struct i2c_hid_platform_data {
u16 hid_descriptor_address;
+ struct regulator *supply;
+ int init_delay_ms;
};
#endif /* __LINUX_I2C_HID_H */
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v3 1/2] devicetree: i2c-hid: Add regulator support
From: Brian Norris @ 2016-12-02 0:31 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires
Cc: Caesar Wang, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rob Herring, linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Mark Rutland, Doug Anderson, Brian Norris
From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Document a "vdd-supply" and an initialization delay. Can be used for
powering on/off a HID.
Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
v2:
* add compatible property for wacom, per Rob's request
* name the regulator property specifically (VDD)
v3:
* remove wacom property, per Benjamin's request
* add delay property
Documentation/devicetree/bindings/input/hid-over-i2c.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
index 488edcb264c4..1ea290167652 100644
--- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
+++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
@@ -17,6 +17,11 @@ Required properties:
- interrupt-parent: the phandle for the interrupt controller
- interrupts: interrupt line
+Optional properties:
+- vdd-supply: phandle of the regulator that provides the supply voltage.
+- init-delay-ms: time required by the device after power-on before it is ready
+ for communication.
+
Example:
i2c-hid-dev@2c {
--
2.8.0.rc3.226.g39d4020
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ARM: omap3: beagleboard-xm: dt: Add ethernet to the device tree
From: Tony Lindgren @ 2016-12-02 0:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Benoît Cousson
In-Reply-To: <20161201214457.GC3703-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [161201 13:45]:
> * Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161201 13:37]:
> > Hi Tony,
> >
> > On Thursday 01 Dec 2016 13:12:34 Tony Lindgren wrote:
> > > * Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> [161130 09:58]:
> > > > The Beagleboard-xM has a LAN9514 USB hub and ethernet controller,
> > > > connected to port 2 of the OMAP EHCI controller. The board however has
> > > > no EEPROM to store the ethernet MAC address, which is programmed by the
> > > > boot loader.
> > > >
> > > > To allow Linux to use the same MAC address as the boot loader (or for
> > > > that matter any fixed MAC address), we need a node in the device tree
> > > > for the ethernet controller that the boot loader can update at runtime
> > > > with a local-mac-address property. Add it, along with an alias for the
> > > > ethernet controller to let the boot loader locate it easily.
> > >
> > > Does not seem to work here.. Do I need to set something in u-boot?
> > > I'm using U-Boot 2016.09-00004-g26bb688.
> >
> > Some versions (possibly forked by vendors) might set the MAC address
> > automatically in DT, but in my case I have the following in my boot script:
> >
> > tftp 0x80800000 beagle/omap3-beagle-xm.dtb
> > fdt addr ${fileaddr} ${filesize}
> > fdt resize
> > fdt set /ocp@68000000/usbhshost@48064000/ehci@48064800/usb2@2/usbether@1 local-mac-address "[7a d2 a0 00 d1 f0]"
>
> OK. I just added setenv ethaddr ${usbethaddr} to my bootcmd..
Here's a similar patch for omap5-uevm. Somehow u-boot does not populate the
local-mac-address on it though although set in the environment.
So I had to manually do the fdt set /ocp/usbhshost@4a064000/ehci@4a064c00/usbether@3
command.
Regards,
Tony
8< ---------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Thu, 1 Dec 2016 12:57:24 -0800
Subject: [PATCH] ARM: dts: omap5-uevm: Allow bootloader to configure USB
Ethernet MAC
Note that with 9730 the wiring is different compared to 9514 found on
beagleboard xm for example.
On beagleboard xm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-2.1 9514
While on omap5-uevm we have:
/sys/bus/usb/devices/1-2 hub
/sys/bus/usb/devices/1-3 9730
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
arch/arm/boot/dts/omap5-uevm.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -18,6 +18,10 @@
reg = <0 0x80000000 0 0x7f000000>; /* 2032 MB */
};
+ aliases {
+ ethernet = ðernet;
+ };
+
leds {
compatible = "gpio-leds";
led1 {
@@ -164,6 +168,23 @@
>;
};
+&usbhsehci {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb2@2 {
+ compatible = "usb424,3503";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ ethernet: usbether@3 {
+ compatible = "usb424,9730";
+ reg = <3>;
+ };
+};
+
&wlcore {
compatible = "ti,wl1837";
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-02 0:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Rob Herring, Philipp Zabel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3900806.3NUubBDb0Q@wuerfel>
Hi, Arnd
On 2016年12月01日 20:05, Arnd Bergmann wrote:
> On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
>> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
>> + 0x20 0x10 /* 1: i2c1 */
>> + 0x20 0x20 /* 2: i2c2 */
>> + 0x20 0x8000000>; /* 3: i2c6 */
>> + };
>> +
>> +Specifying reset lines connected to IP modules
>> +==============================================
>> +example:
>> +
>> + i2c0: i2c@..... {
>> + ...
>> + resets = <&iomcu_rst 0>;
>> + ...
>> + };
> I don't really like this approach, since now the information is
> in two places. Why not put the data into the reset specifier
> directly when it is used?
Any example, still not understand.
They are consumer and provider.
>
> Also the format seems a little too close to the actual register
> layout and could be a little more abstract, using bit numbers instead
> of a bitmask and register numbers instead of offsets.
We use bit numbers first.
But in the developing process, we found several bits may be required for
one driver.
And they may not be continuous as the bits may already be occupied.
Directly using offset, we can set several bits together for simple, to
give more flexibility.
So after discussion, we directly use offset.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] mmc: host: s3cmci: allow probing from device tree
From: Sergio Prado @ 2016-12-02 0:14 UTC (permalink / raw)
To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ben-linux-elnMNo+KYs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sergio Prado
In-Reply-To: <1480637665-6325-1-git-send-email-sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
Allows configuring Samsung S3C24XX MMC/SD/SDIO controller using a device
tree.
Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
---
drivers/mmc/host/s3cmci.c | 155 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 131 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 932a4b1fed33..bfeb90e8ffee 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -23,6 +23,9 @@
#include <linux/gpio.h>
#include <linux/irq.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <plat/gpio-cfg.h>
#include <mach/dma.h>
@@ -127,6 +130,22 @@ enum dbg_channels {
dbg_conf = (1 << 8),
};
+struct s3cmci_drv_data {
+ int is2440;
+};
+
+static const struct s3cmci_drv_data s3c2410_s3cmci_drv_data = {
+ .is2440 = 0,
+};
+
+static const struct s3cmci_drv_data s3c2412_s3cmci_drv_data = {
+ .is2440 = 1,
+};
+
+static const struct s3cmci_drv_data s3c2440_s3cmci_drv_data = {
+ .is2440 = 1,
+};
+
static const int dbgmap_err = dbg_fail;
static const int dbgmap_info = dbg_info | dbg_conf;
static const int dbgmap_debug = dbg_err | dbg_debug;
@@ -1241,8 +1260,9 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_ON:
case MMC_POWER_UP:
/* Configure GPE5...GPE10 pins in SD mode */
- s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
- S3C_GPIO_PULL_NONE);
+ if (!host->pdev->dev.of_node)
+ s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
+ S3C_GPIO_PULL_NONE);
if (host->pdata->set_power)
host->pdata->set_power(ios->power_mode, ios->vdd);
@@ -1254,7 +1274,8 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_OFF:
default:
- gpio_direction_output(S3C2410_GPE(5), 0);
+ if (!host->pdev->dev.of_node)
+ gpio_direction_output(S3C2410_GPE(5), 0);
if (host->is2440)
mci_con |= S3C2440_SDICON_SDRESET;
@@ -1544,21 +1565,12 @@ static inline void s3cmci_debugfs_remove(struct s3cmci_host *host) { }
#endif /* CONFIG_DEBUG_FS */
-static int s3cmci_probe(struct platform_device *pdev)
+static int s3cmci_probe_pdata(struct s3cmci_host *host)
{
- struct s3cmci_host *host;
- struct mmc_host *mmc;
- int ret;
- int is2440;
- int i;
+ struct platform_device *pdev = host->pdev;
+ int i, ret;
- is2440 = platform_get_device_id(pdev)->driver_data;
-
- mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
- if (!mmc) {
- ret = -ENOMEM;
- goto probe_out;
- }
+ host->is2440 = platform_get_device_id(pdev)->driver_data;
for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++) {
ret = gpio_request(i, dev_name(&pdev->dev));
@@ -1568,14 +1580,90 @@ static int s3cmci_probe(struct platform_device *pdev)
for (i--; i >= S3C2410_GPE(5); i--)
gpio_free(i);
- goto probe_free_host;
+ return ret;
}
}
+ return 0;
+}
+
+static int s3cmci_probe_dt(struct s3cmci_host *host)
+{
+ struct platform_device *pdev = host->pdev;
+ struct s3c24xx_mci_pdata *pdata;
+ const struct s3cmci_drv_data *drvdata;
+ struct mmc_host *mmc = host->mmc;
+ int gpio, ret;
+
+ drvdata = of_device_get_match_data(&pdev->dev);
+ if (!drvdata)
+ return -ENODEV;
+
+ host->is2440 = drvdata->is2440;
+
+ ret = mmc_of_parse(mmc);
+ if (ret)
+ return ret;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->ocr_avail = mmc->ocr_avail;
+
+ if (mmc->caps2 & MMC_CAP2_NO_WRITE_PROTECT)
+ pdata->no_wprotect = 1;
+
+ if (mmc->caps & MMC_CAP_NEEDS_POLL)
+ pdata->no_detect = 1;
+
+ if (mmc->caps2 & MMC_CAP2_RO_ACTIVE_HIGH)
+ pdata->wprotect_invert = 1;
+
+ if (mmc->caps2 & MMC_CAP2_CD_ACTIVE_HIGH)
+ pdata->detect_invert = 1;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "cd-gpios", 0);
+ if (gpio_is_valid(gpio)) {
+ pdata->gpio_detect = gpio;
+ gpio_free(gpio);
+ }
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "wp-gpios", 0);
+ if (gpio_is_valid(gpio)) {
+ pdata->gpio_wprotect = gpio;
+ gpio_free(gpio);
+ }
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+
+static int s3cmci_probe(struct platform_device *pdev)
+{
+ struct s3cmci_host *host;
+ struct mmc_host *mmc;
+ int ret;
+ int i;
+
+ mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
+ if (!mmc) {
+ ret = -ENOMEM;
+ goto probe_out;
+ }
+
host = mmc_priv(mmc);
host->mmc = mmc;
host->pdev = pdev;
- host->is2440 = is2440;
+
+ if (pdev->dev.of_node)
+ ret = s3cmci_probe_dt(host);
+ else
+ ret = s3cmci_probe_pdata(host);
+
+ if (ret)
+ goto probe_free_host;
host->pdata = pdev->dev.platform_data;
if (!host->pdata) {
@@ -1586,7 +1674,7 @@ static int s3cmci_probe(struct platform_device *pdev)
spin_lock_init(&host->complete_lock);
tasklet_init(&host->pio_tasklet, pio_tasklet, (unsigned long) host);
- if (is2440) {
+ if (host->is2440) {
host->sdiimsk = S3C2440_SDIIMSK;
host->sdidata = S3C2440_SDIDATA;
host->clk_div = 1;
@@ -1789,8 +1877,9 @@ static int s3cmci_probe(struct platform_device *pdev)
release_mem_region(host->mem->start, resource_size(host->mem));
probe_free_gpio:
- for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
- gpio_free(i);
+ if (!pdev->dev.of_node)
+ for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
+ gpio_free(i);
probe_free_host:
mmc_free_host(mmc);
@@ -1837,9 +1926,9 @@ static int s3cmci_remove(struct platform_device *pdev)
if (!pd->no_detect)
gpio_free(pd->gpio_detect);
- for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
- gpio_free(i);
-
+ if (!pdev->dev.of_node)
+ for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
+ gpio_free(i);
iounmap(host->base);
release_mem_region(host->mem->start, resource_size(host->mem));
@@ -1848,6 +1937,23 @@ static int s3cmci_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id s3cmci_dt_match[] = {
+ {
+ .compatible = "samsung,s3c2410-sdi",
+ .data = &s3c2410_s3cmci_drv_data,
+ },
+ {
+ .compatible = "samsung,s3c2412-sdi",
+ .data = &s3c2412_s3cmci_drv_data,
+ },
+ {
+ .compatible = "samsung,s3c2440-sdi",
+ .data = &s3c2440_s3cmci_drv_data,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
+
static const struct platform_device_id s3cmci_driver_ids[] = {
{
.name = "s3c2410-sdi",
@@ -1867,6 +1973,7 @@ static int s3cmci_remove(struct platform_device *pdev)
static struct platform_driver s3cmci_driver = {
.driver = {
.name = "s3c-sdi",
+ .of_match_table = s3cmci_dt_match,
},
.id_table = s3cmci_driver_ids,
.probe = s3cmci_probe,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox