leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
e21adc781b
linux/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi

1192 lines
26 KiB
Plaintext
Raw Normal View History

arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
/*
* Google Gru (and derivatives) board device tree source
*
* Copyright 2016-2017 Google, Inc
*
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
* licensing only applies to this file, and not this project as a
* whole.
*
* a) This file is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This file is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Or, alternatively,
*
* b) Permission is hereby granted, free of charge, to any person
* obtaining a copy of this software and associated documentation
* files (the "Software"), to deal in the Software without
* restriction, including without limitation the rights to use,
* copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following
* conditions:
*
* The above copyright notice and this permission notice shall be
* included in all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
* OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
* HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*/
#include <dt-bindings/input/input.h>
#include "rk3399.dtsi"
arm64: dts: rockchip: introduce rk3399-op1 operating points The OP1 is a rk3399 variant used in ChromeOS devices with a slightly higher frequency rating compared to the regular rk3399, but right now the only available operating points don't match either variant with both needing adjustments to actually fit their specs. Therefore introduce separate operting points, from the ChromeOS kernel, for the OP1 and use it on Gru devices. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-05-23 09:17:19 +00:00
#include "rk3399-op1-opp.dtsi"
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
/ {
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.
*/
ppvar_sys: ppvar-sys {
compatible = "regulator-fixed";
regulator-name = "ppvar_sys";
regulator-always-on;
regulator-boot-on;
};
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>;
};
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
ppvar_bigcpu_pwm: ppvar-bigcpu-pwm {
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
compatible = "pwm-regulator";
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
regulator-name = "ppvar_bigcpu_pwm";
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
pwms = <&pwm1 0 3337 0>;
pwm-supply = <&ppvar_sys>;
pwm-dutycycle-range = <100 0>;
pwm-dutycycle-unit = <100>;
/* EC turns on w/ ap_core_en; always on for AP */
regulator-always-on;
regulator-boot-on;
arm64: dts: rockchip: Update CPU regulator voltage ranges for Gru Gru derivatives besides Kevin have slightly different voltage ranges for their CPU regulators. Let's keep the base Gru file accurate and let Kevin override. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:35 +00:00
regulator-min-microvolt = <800107>;
regulator-max-microvolt = <1302232>;
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
};
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
ppvar_bigcpu: ppvar-bigcpu {
compatible = "vctrl-regulator";
regulator-name = "ppvar_bigcpu";
regulator-min-microvolt = <800107>;
regulator-max-microvolt = <1302232>;
ctrl-supply = <&ppvar_bigcpu_pwm>;
ctrl-voltage-range = <800107 1302232>;
regulator-settling-time-up-us = <322>;
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
ppvar_litcpu_pwm: ppvar-litcpu-pwm {
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
compatible = "pwm-regulator";
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
regulator-name = "ppvar_litcpu_pwm";
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
pwms = <&pwm2 0 3337 0>;
pwm-supply = <&ppvar_sys>;
pwm-dutycycle-range = <100 0>;
pwm-dutycycle-unit = <100>;
/* EC turns on w/ ap_core_en; always on for AP */
regulator-always-on;
regulator-boot-on;
arm64: dts: rockchip: Update CPU regulator voltage ranges for Gru Gru derivatives besides Kevin have slightly different voltage ranges for their CPU regulators. Let's keep the base Gru file accurate and let Kevin override. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:35 +00:00
regulator-min-microvolt = <797743>;
regulator-max-microvolt = <1307837>;
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
};
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
ppvar_litcpu: ppvar-litcpu {
compatible = "vctrl-regulator";
regulator-name = "ppvar_litcpu";
regulator-min-microvolt = <797743>;
regulator-max-microvolt = <1307837>;
ctrl-supply = <&ppvar_litcpu_pwm>;
ctrl-voltage-range = <797743 1307837>;
regulator-settling-time-up-us = <384>;
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
ppvar_gpu_pwm: ppvar-gpu-pwm {
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
compatible = "pwm-regulator";
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
regulator-name = "ppvar_gpu_pwm";
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
pwms = <&pwm0 0 3337 0>;
pwm-supply = <&ppvar_sys>;
pwm-dutycycle-range = <100 0>;
pwm-dutycycle-unit = <100>;
/* EC turns on w/ ap_core_en; always on for AP */
regulator-always-on;
regulator-boot-on;
arm64: dts: rockchip: Update CPU regulator voltage ranges for Gru Gru derivatives besides Kevin have slightly different voltage ranges for their CPU regulators. Let's keep the base Gru file accurate and let Kevin override. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:35 +00:00
regulator-min-microvolt = <786384>;
regulator-max-microvolt = <1217747>;
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
};
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
ppvar_gpu: ppvar-gpu {
compatible = "vctrl-regulator";
regulator-name = "ppvar_gpu";
regulator-min-microvolt = <786384>;
regulator-max-microvolt = <1217747>;
ctrl-supply = <&ppvar_gpu_pwm>;
ctrl-voltage-range = <786384 1217747>;
regulator-settling-time-up-us = <390>;
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
ppvar_centerlogic_pwm: ppvar-centerlogic-pwm {
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
compatible = "pwm-regulator";
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
regulator-name = "ppvar_centerlogic_pwm";
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
pwms = <&pwm3 0 3337 0>;
pwm-supply = <&ppvar_sys>;
pwm-dutycycle-range = <100 0>;
pwm-dutycycle-unit = <100>;
/* EC turns on w/ ppvar_centerlogic_en; always on for AP */
regulator-always-on;
regulator-boot-on;
arm64: dts: rockchip: Update CPU regulator voltage ranges for Gru Gru derivatives besides Kevin have slightly different voltage ranges for their CPU regulators. Let's keep the base Gru file accurate and let Kevin override. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:35 +00:00
regulator-min-microvolt = <799434>;
regulator-max-microvolt = <1049925>;
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
};
arm64: dts: rockchip: Use vctrl regulators for dynamic CPU voltages on Gru/Kevin The Gru device tree currently contains entries for the regulators ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however, the regulators have not been enabled, due to the lack of binding and driver support for keeping the over-voltage protection (OVP) at bay and preventing unintended regulator shutdowns on voltage downshifts. Now, the vctrl regulator driver has been merged, along with new bindings for asymmetric settling time. The driver is OVP aware, it splits larger voltage decreases in multiple steps when necessary and adds required delays. This change renames each of the aforementioned regulators to <orig_name>_pwm and adds a new vctrl regulator named <orig_name>. The vctrl regulators use the voltage of their corresponding PWM regulator as control voltage. The OVP related values are empirical and stem from the Chrome OS kernel tree. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Brian Norris <briannorris@chromium.org> [fixed node names and parent supplies of gpu and centerlogic] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-23 17:07:36 +00:00
ppvar_centerlogic: ppvar-centerlogic {
compatible = "vctrl-regulator";
regulator-name = "ppvar_centerlogic";
regulator-min-microvolt = <799434>;
regulator-max-microvolt = <1049925>;
ctrl-supply = <&ppvar_centerlogic_pwm>;
ctrl-voltage-range = <799434 1049925>;
regulator-settling-time-up-us = <378>;
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
/* 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>;
};
/* 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 {
};
/* 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 {
};
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>;
enable-active-high;
gpio = <&gpio0 2 GPIO_ACTIVE_HIGH>;
regulator-always-on;
regulator-boot-on;
vin-supply = <&pp1800>;
};
/* gpio is shared with pp3300_wifi_bt */
pp1800_pcie: pp1800-pcie {
compatible = "regulator-fixed";
regulator-name = "pp1800_pcie";
pinctrl-names = "default";
pinctrl-0 = <&wlan_module_pd_l>;
enable-active-high;
gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
/*
* 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>;
vin-supply = <&pp1800>;
};
/*
* 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";
arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset) Back in the early days when gru devices were still under development we found an issue where the WiFi reset line needed to be configured as early as possible during the boot process to avoid the WiFi module being in a bad state. We found that the way to get the kernel to do this in the earliest possible place was to configure this line in the pinctrl hogs, so that's what we did. For some history here you can see <http://crosreview.com/368770>. After the time that change landed in the kernel, we landed a firmware change to configure this line even earlier. See <http://crosreview.com/399919>. However, even after the firmware change landed we kept the kernel change to deal with the fact that some people working on devices might take a little while to update their firmware. At this there are definitely zero devices out in the wild that have firmware without the fix in it. Specifically looking in the firmware branch several critically important fixes for memory stability landed after the patch in coreboot and I know we didn't ship without those. Thus, by now, everyone should have the new firmware and it's safe to not have the kernel set this up in a pinctrl hog. Historically, even though it wasn't needed to have this in a pinctrl hog, we still kept it since it didn't hurt. Pinctrl would apply the default hog at bootup and then would never touch things again. That all changed with commit 981ed1bfbc6c ("pinctrl: Really force states during suspend/resume"). After that commit then we'll re-apply the default hog at resume time and that can screw up the reset state of WiFi. ...and on rk3399 if you touch a device on PCIe in the wrong way then the whole system can go haywire. That's what was happening. Specifically you'd resume a rk3399-gru-* device and it would mostly resume, then would crash with some crazy weird crash. One could say, perhaps, that the recent pinctrl change was at fault (and should be fixed) since it changed behavior. ...but that's not really true. The device tree for rk3399-gru is really to blame. Specifically since the pinctrl is defined in the hog and not in the "wlan-pd-n" node then the actual user of this pin doesn't have a pinctrl entry for it. That's bad. Let's fix our problems by just moving the control of "wlan_module_reset_l pinctrl" out of the hog and put them in the proper place. NOTE: in theory, I think it should actually be possible to have a pin controlled _both_ by the hog and by an actual device. Once the device claims the pin I think the hog is supposed to let go. I'm not 100% sure that this works and in any case this solution would be more complex than is necessary. Reported-by: Marc Zyngier <marc.zyngier@arm.com> Fixes: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS") Fixes: 981ed1bfbc6c ("pinctrl: Really force states during suspend/resume") Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-27 20:47:11 +00:00
pinctrl-names = "default";
pinctrl-0 = <&wlan_module_reset_l>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
enable-active-high;
gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
vin-supply = <&pp1800_pcie>;
};
/* Always on; plain and simple */
pp3000_ap: pp3000_emmc: pp3000 {
};
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>;
};
/* EC turns on w/ pp3300_trackpad_en_l */
pp3300_trackpad: pp3300-trackpad {
};
/* EC turns on w/ pp3300_usb_en_l */
pp3300_usb: pp3300 {
};
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>;
};
/* gpio is shared with pp1800_pcie and pinctrl is set there */
pp3300_wifi_bt: pp3300-wifi-bt {
compatible = "regulator-fixed";
regulator-name = "pp3300_wifi_bt";
enable-active-high;
gpio = <&gpio0 4 GPIO_ACTIVE_HIGH>;
vin-supply = <&pp3300>;
};
/* EC turns on w/ usb_a_en */
pp5000_usb_a_vbus: pp5000 {
};
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;
};
};
max98357a: max98357a {
compatible = "maxim,max98357a";
pinctrl-names = "default";
pinctrl-0 = <&sdmode_en>;
sdmode-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
sdmode-delay = <2>;
#sound-dai-cells = <0>;
status = "okay";
};
sound {
compatible = "rockchip,rk3399-gru-sound";
rockchip,cpu = <&i2s0 &i2s2>;
arm64: dts: rockchip: Add rt5514 dsp for rk3399 gru Add rt5514 dsp of_node to codec list for Gru boards. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-08-24 04:52:22 +00:00
rockchip,codec = <&max98357a &headsetcodec
arm64: dts: rockchip: enable DP for rk3399-gru Enable cdn_dp and create a cdn-dp-sound for the DP audio. Delete the endpoints between dp and vopL for gru, since we want the DP only use VOP big, which can support 4K mode. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [dropped vop-hacks] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-13 14:35:49 +00:00
&codec &wacky_spi_audio &cdn_dp>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
};
arm64: dts: rockchip: enable DP for rk3399-gru Enable cdn_dp and create a cdn-dp-sound for the DP audio. Delete the endpoints between dp and vopL for gru, since we want the DP only use VOP big, which can support 4K mode. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [dropped vop-hacks] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-13 14:35:49 +00:00
&cdn_dp {
status = "okay";
extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
arm64: dts: rockchip: describe Gru/Kevin OPPs + CPU regulators Used for Gru/Kevin only, as they're the only ones which have a described CPU regulator. Also, I'm not sure we've validated this table non-Gru boards. At the same time, partially describe PWM regulators for Gru, so cpufreq doesn't think it can crank up the clock speed without changing the voltage. However, we don't yet have the DT bindings to fully describe the Over Voltage Protection (OVP) circuits on these boards. Without that description, we might end up changing the voltage too much, too fast. Add the pwm-regulator descriptions and associate the CPU OPPs, but leave them disabled. Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:43 +00:00
/*
* 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>;
};
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
&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>,
arm64: dts: rockchip: assign clock rate for ACLK_VIO on rk3399 The ACLK_VIO is a parent clock used by a several children, its suggested clock rate is 400MHz. Right now it gets 400MHz because it sources from CPLL(800M) and divides by 2 after reset. It's good not to rely on default values like this, so let's explicitly set it. NOTE: it's expected that at least one board may override cru node and set the CPLL to 1.6 GHz. On that board it will be very important to be explicit about aclk-vio being 400 MHz. Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-03-12 01:50:48 +00:00
<&cru HCLK_PERILP1>, <&cru PCLK_PERILP1>,
arm64: dts: rockchip: assign clock rate for cpll child clocks on rk3399 These clocks do not assign default clock frequency, and use the default cru register value to get frequency, so if cpll increase frequency, these clocks also increase their frequency, that may exceed their signed off frequency. So assign default clock for them to avoid it. NOTE: on none of the boards currently in mainline do we expect CPLL to be anything other than 800 MHz, but some future boards might have it. It's still good to be explicit about the clock rates to make diffing against future boards easier and also to rely less on BIOS muxing. Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-03-20 02:06:29 +00:00
<&cru ACLK_VIO>, <&cru ACLK_HDCP>,
<&cru ACLK_GIC_PRE>,
<&cru PCLK_DDR>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
assigned-clock-rates =
<600000000>, <800000000>,
<1000000000>,
<150000000>, <75000000>,
<37500000>,
<100000000>, <100000000>,
<50000000>, <800000000>,
arm64: dts: rockchip: assign clock rate for ACLK_VIO on rk3399 The ACLK_VIO is a parent clock used by a several children, its suggested clock rate is 400MHz. Right now it gets 400MHz because it sources from CPLL(800M) and divides by 2 after reset. It's good not to rely on default values like this, so let's explicitly set it. NOTE: it's expected that at least one board may override cru node and set the CPLL to 1.6 GHz. On that board it will be very important to be explicit about aclk-vio being 400 MHz. Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-03-12 01:50:48 +00:00
<100000000>, <50000000>,
arm64: dts: rockchip: assign clock rate for cpll child clocks on rk3399 These clocks do not assign default clock frequency, and use the default cru register value to get frequency, so if cpll increase frequency, these clocks also increase their frequency, that may exceed their signed off frequency. So assign default clock for them to avoid it. NOTE: on none of the boards currently in mainline do we expect CPLL to be anything other than 800 MHz, but some future boards might have it. It's still good to be explicit about the clock rates to make diffing against future boards easier and also to rely less on BIOS muxing. Signed-off-by: Lin Huang <hl@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-03-20 02:06:29 +00:00
<400000000>, <400000000>,
<200000000>,
<200000000>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
&emmc_phy {
status = "okay";
};
arm64: dts: rockchip: enable the GPU for RK3399-GRU This patch enables the gpu and adds the mali-supply power for RK3399-GRU devices. Signed-off-by: Caesar Wang <wxt@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-07-17 08:14:30 +00:00
&gpu {
mali-supply = <&ppvar_gpu>;
status = "okay";
};
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
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>;
arm64: dts: rockchip: Fix wrong rt5514 dmic delay property for Gru According to rt5514 dt-binding, it should be "realtek,dmic-init-delay-ms". Fixes: 48f4d9796d99 (arm64: dts: rockchip: add Gru/Kevin DTS) Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-08-18 14:48:08 +00:00
realtek,dmic-init-delay-ms = <20>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
};
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";
clock-frequency = <400000>;
/* These are relatively safe rise/fall times */
i2c-scl-falling-time-ns = <50>;
i2c-scl-rising-time-ns = <300>;
/*
* 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>;
};
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>;
interrupt-parent = <&gpio1>;
interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
clocks = <&cru SCLK_I2S_8CH_OUT>;
clock-names = "mclk";
dlg,micbias-lvl = <2600>;
dlg,mic-amp-in-sel = "diff";
pinctrl-names = "default";
pinctrl-0 = <&headset_int_l>;
VDD-supply = <&pp1800>;
VDDMIC-supply = <&pp3300>;
VDDIO-supply = <&pp1800>;
da7219_aad {
dlg,adc-1bit-rpt = <1>;
dlg,btn-avg = <4>;
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>;
};
};
};
&i2s0 {
status = "okay";
};
&i2s2 {
status = "okay";
};
&io_domains {
status = "okay";
audio-supply = <&pp1800_audio>; /* APIO5_VDD; 3d 4a */
bt656-supply = <&pp1800_ap_io>; /* APIO2_VDD; 2a 2b */
gpio1830-supply = <&pp3000_ap>; /* APIO4_VDD; 4c 4d */
sdmmc-supply = <&ppvar_sd_card_io>; /* SDMMC0_VDD; 4b */
};
&pcie0 {
status = "okay";
ep-gpios = <&gpio2 27 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pcie_clkreqn_cpm>, <&wifi_perst_l>;
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>;
interrupt-parent = <&gpio0>;
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&wlan_host_wake_l>;
wakeup-source;
};
};
};
&pcie_phy {
status = "okay";
};
&pmu_io_domains {
status = "okay";
pmu1830-supply = <&pp1800_pmu>; /* PMUIO2_VDD */
};
&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>;
cap-mmc-highspeed;
cap-sd-highspeed;
cd-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>;
disable-wp;
sd-uhs-sdr12;
sd-uhs-sdr25;
sd-uhs-sdr50;
sd-uhs-sdr104;
vmmc-supply = <&pp3000_sd_slot>;
vqmmc-supply = <&ppvar_sd_card_io>;
};
&spi1 {
status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-1 = <&spi1_sleep>;
spiflash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
/* May run faster once verified. */
spi-max-frequency = <10000000>;
};
};
&spi2 {
status = "okay";
wacky_spi_audio: spi2@0 {
compatible = "realtek,rt5514";
reg = <0>;
arm64: dts: rockchip: Assign mic irq to correct device for Gru Currently we are assigning mic irq to rt5514 i2c driver, which is wrong. Assign it to rt5514 spi driver instead. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-08-16 09:24:32 +00:00
interrupt-parent = <&gpio1>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&mic_int>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
/* May run faster once verified. */
spi-max-frequency = <10000000>;
arm64: dts: rockchip: Assign mic irq to correct device for Gru Currently we are assigning mic irq to rt5514 i2c driver, which is wrong. Assign it to rt5514 spi driver instead. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-08-16 09:24:32 +00:00
wakeup-source;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
};
&spi5 {
status = "okay";
cros_ec: ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
interrupt-parent = <&gpio0>;
interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&ec_ap_int_l>;
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>;
};
arm64: dts: rockchip: add extcon nodes and enable tcphy rk3399-gru Enable tcphy and create the cros-ec's extcon node for the USB Type-C port. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-12-15 11:00:01 +00:00
usbc_extcon0: extcon@0 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <0>;
#extcon-cells = <0>;
};
usbc_extcon1: extcon@1 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <1>;
#extcon-cells = <0>;
};
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
};
&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 */
};
arm64: dts: rockchip: add extcon nodes and enable tcphy rk3399-gru Enable tcphy and create the cros-ec's extcon node for the USB Type-C port. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-12-15 11:00:01 +00:00
&tcphy0 {
status = "okay";
extcon = <&usbc_extcon0>;
};
&tcphy1 {
status = "okay";
extcon = <&usbc_extcon1>;
};
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
&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";
arm64: dts: rockchip: add extcon nodes and enable tcphy rk3399-gru Enable tcphy and create the cros-ec's extcon node for the USB Type-C port. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-12-15 11:00:01 +00:00
extcon = <&usbc_extcon0>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
&usbdrd_dwc3_0 {
status = "okay";
dr_mode = "host";
};
&usbdrd3_1 {
status = "okay";
arm64: dts: rockchip: add extcon nodes and enable tcphy rk3399-gru Enable tcphy and create the cros-ec's extcon node for the USB Type-C port. Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-12-15 11:00:01 +00:00
extcon = <&usbc_extcon1>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
&usbdrd_dwc3_1 {
status = "okay";
dr_mode = "host";
};
arm64: dts: rockchip: Enable edp disaplay on kevin Add edp panel and enable related nodes on kevin. Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by: Mark Yao <mark.yao@rock-chips.com> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-10-19 03:48:03 +00:00
&vopb {
status = "okay";
};
&vopb_mmu {
status = "okay";
};
&vopl {
status = "okay";
};
&vopl_mmu {
status = "okay";
};
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
#include <arm/cros-ec-keyboard.dtsi>
#include <arm/cros-ec-sbs.dtsi>
&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 */
>;
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>;
};
backlight-enable {
bl_en: bl-en {
rockchip,pins = <1 17 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
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>;
};
};
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>;
};
};
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.
*/
arm64: dts: rockchip: fix typo in mmc pinctrl replace all occurrences of sdmcc with sdmmc in the arm64 rockchip devicetree files. Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-06-27 19:58:31 +00:00
sdmmc_cd: sdmmc-cd {
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
rockchip,pins =
<0 7 RK_FUNC_1 &pcfg_pull_none>;
};
/* This is where we actually hook up CD; has external pull */
sdmmc_cd_gpio: sdmmc-cd-gpio {
rockchip,pins = <4 24 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
spi1 {
spi1_sleep: spi1-sleep {
/*
* Pull down SPI1 CLK/CS/RX/TX during suspend, to
* prevent leakage.
*/
rockchip,pins = <1 9 RK_FUNC_GPIO &pcfg_pull_down>,
<1 10 RK_FUNC_GPIO &pcfg_pull_down>,
<1 7 RK_FUNC_GPIO &pcfg_pull_down>,
<1 8 RK_FUNC_GPIO &pcfg_pull_down>;
};
};
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>;
};
};
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>;
};
};
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 {
arm64: dts: rockchip: Fix rk3399-gru-* s2r (pinctrl hogs, wifi reset) Back in the early days when gru devices were still under development we found an issue where the WiFi reset line needed to be configured as early as possible during the boot process to avoid the WiFi module being in a bad state. We found that the way to get the kernel to do this in the earliest possible place was to configure this line in the pinctrl hogs, so that's what we did. For some history here you can see <http://crosreview.com/368770>. After the time that change landed in the kernel, we landed a firmware change to configure this line even earlier. See <http://crosreview.com/399919>. However, even after the firmware change landed we kept the kernel change to deal with the fact that some people working on devices might take a little while to update their firmware. At this there are definitely zero devices out in the wild that have firmware without the fix in it. Specifically looking in the firmware branch several critically important fixes for memory stability landed after the patch in coreboot and I know we didn't ship without those. Thus, by now, everyone should have the new firmware and it's safe to not have the kernel set this up in a pinctrl hog. Historically, even though it wasn't needed to have this in a pinctrl hog, we still kept it since it didn't hurt. Pinctrl would apply the default hog at bootup and then would never touch things again. That all changed with commit 981ed1bfbc6c ("pinctrl: Really force states during suspend/resume"). After that commit then we'll re-apply the default hog at resume time and that can screw up the reset state of WiFi. ...and on rk3399 if you touch a device on PCIe in the wrong way then the whole system can go haywire. That's what was happening. Specifically you'd resume a rk3399-gru-* device and it would mostly resume, then would crash with some crazy weird crash. One could say, perhaps, that the recent pinctrl change was at fault (and should be fixed) since it changed behavior. ...but that's not really true. The device tree for rk3399-gru is really to blame. Specifically since the pinctrl is defined in the hog and not in the "wlan-pd-n" node then the actual user of this pin doesn't have a pinctrl entry for it. That's bad. Let's fix our problems by just moving the control of "wlan_module_reset_l pinctrl" out of the hog and put them in the proper place. NOTE: in theory, I think it should actually be possible to have a pin controlled _both_ by the hog and by an actual device. Once the device claims the pin I think the hog is supposed to let go. I'm not 100% sure that this works and in any case this solution would be more complex than is necessary. Reported-by: Marc Zyngier <marc.zyngier@arm.com> Fixes: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS") Fixes: 981ed1bfbc6c ("pinctrl: Really force states during suspend/resume") Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-02-27 20:47:11 +00:00
rockchip,pins = <1 11 RK_FUNC_GPIO &pcfg_pull_none>;
arm64: dts: rockchip: add Gru/Kevin DTS Kevin is part of a family of boards called Gru. As best as possible, the properties shared by the Gru family are placed in rk3399-gru.dtsi, while Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full support for the base Gru board. Working and tested (to some extent): * EC support -- including keyboard, battery, PWM, and probably more * UART / console * Thermal * Touchscreen * Touchpad * Digitizer (regulator still WIP) * PCIe / Wifi * Bluetooth / Webcam * SD card * eMMC * USB2 on TypeC - This works much of the time, but USB3 devices may or may not detect properly. Waiting on proper extcon support for USB3 over TypeC. - Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed * Backlight Not working: * CPUFreq -- relies on special OVP support for our PWM regulator circuits * EC / extcon support -- and with it, USB3/TypeC/DP * DRM -- won't even build on ARM64, so all display, eDP, etc. is not enabled Not tested: * Audio Signed-off-by: Brian Norris <briannorris@chromium.org> [shared gru/kevin parts on a gru device] Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> [with a bit of reordering] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2017-03-20 23:53:42 +00:00
};
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>;
};
};
write-protect {
ap_fw_wp: ap-fw-wp {
rockchip,pins = <1 18 RK_FUNC_GPIO &pcfg_pull_up>;
};
};
};
Reference in New Issue Copy Permalink