From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:33:39
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
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:33:41
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
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:33:43
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(+)
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:33:46
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(+)
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:33:54
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(+)
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:33:56
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(+)
@@ -172,6 +172,98 @@vin-supply=<&ppvar_sys>;};+ppvar_bigcpu:ppvar-bigcpu{+compatible="pwm-regulator";+regulator-name="ppvar_bigcpu";+/*+*OVPcircuitrequiresspecialhandlingwhichisnotyet+*represented.Keepdisabledfornow.+*/+status="disabled";++pwms=<&pwm1033370>;++/* 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=<1000>;+pwm-dutycycle-unit=<100>;+};++ppvar_litcpu:ppvar-litcpu{+compatible="pwm-regulator";+regulator-name="ppvar_litcpu";+/*+*OVPcircuitrequiresspecialhandlingwhichisnotyet+*represented.Keepdisabledfornow.+*/+status="disabled";++pwms=<&pwm2033370>;++/* 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=<1000>;+pwm-dutycycle-unit=<100>;+};++ppvar_gpu:ppvar-gpu{+compatible="pwm-regulator";+regulator-name="ppvar_gpu";+/*+*OVPcircuitrequiresspecialhandlingwhichisnotyet+*represented.Keepdisabledfornow.+*/+status="disabled";++pwms=<&pwm0033370>;++/* 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=<1000>;+pwm-dutycycle-unit=<100>;+};++ppvar_centerlogic:ppvar-centerlogic{+compatible="pwm-regulator";+regulator-name="ppvar_centerlogic";+/*+*OVPcircuitrequiresspecialhandlingwhichisnotyet+*represented.Keepdisabledfornow.+*/+status="disabled";++pwms=<&pwm3033370>;++/* 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=<1000>;+pwm-dutycycle-unit=<100>;+};+/* Schematics call this PPVAR even though it's fixed */ppvar_logic:ppvar-logic{compatible="regulator-fixed";
@@ -444,6 +536,60 @@};};+/*+*SetsomesuspendoperatingpointstoavoidOVPinsuspend+*+*WhenwegointoS3ARMTrustedFirmwarewilltransitionourPWMregulators+*fromwhereverthey'reatbacktothe"default"operatingpoint(whatever+*voltagewegetwhenwesetthePWMpinsto"input").+*+*Thisquicktransitionunderlightloadhasthepossibilitytotriggerthe+*regulator"over voltage protection"(OVP).+*+*Tomakeextracertainthatwedon'thitthisOVPatsuspendtime,we'll+*transitiontoavoltagethat'smuchclosertothedefault(~1.0V)sothat+*therewillnotbeabigjump.Technicallyweonlyneedtogetwithin200mV+*ofthedefaultvoltage,butthespeedhereshouldbefastenoughandweneed+*suspend/resumetoberocksolid.+*/++&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=<&cruPLL_GPLL>,<&cruPLL_CPLL>,
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:34:24
Kevin is part of a family of boards called Gru. As best as possible, the
properties shared by the Gru family are placed in rk3399-gru.dtsi, while
Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full
support for the base Gru board.
Working and tested (to some extent):
* EC support -- including keyboard, battery, PWM, and probably more
* UART / console
* Thermal
* Touchscreen
* Touchpad
* Digitizer (regulator still WIP)
* PCIe / Wifi
* Bluetooth / Webcam
* SD card
* eMMC
* USB2 on TypeC
- This works much of the time, but USB3 devices may or may not detect
properly. Waiting on proper extcon support for USB3 over TypeC.
- Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed
* Backlight
Not working:
* CPUFreq -- relies on special OVP support for our PWM regulator
circuits
* EC / extcon support -- and with it, USB3/TypeC/DP
* DRM -- won't even build on ARM64, so all display, eDP, etc. is not
enabled
Not tested:
* Audio
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 312 +++++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 1006 +++++++++++++++++++++
3 files changed, 1319 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -0,0 +1,312 @@+/*+*GoogleGru-KevinRev6+boarddevicetreesource+*+*Copyright2016Google,Inc+*+*Thisfileisdual-licensed:youcanuseiteitherundertheterms+*oftheGPLortheX11license,atyouroption.Notethatthisdual+*licensingonlyappliestothisfile,andnotthisprojectasa+*whole.+*+*a)Thisfileisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicenseas+*publishedbytheFreeSoftwareFoundation;eitherversion2ofthe+*License,or(atyouroption)anylaterversion.+*+*Thisfileisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*Or,alternatively,+*+*b)Permissionisherebygranted,freeofcharge,toanyperson+*obtainingacopyofthissoftwareandassociateddocumentation+*files(the"Software"),todealintheSoftwarewithout+*restriction,includingwithoutlimitationtherightstouse,+*copy,modify,merge,publish,distribute,sublicense,and/or+*sellcopiesoftheSoftware,andtopermitpersonstowhomthe+*Softwareisfurnishedtodoso,subjecttothefollowing+*conditions:+*+*Theabovecopyrightnoticeandthispermissionnoticeshallbe+*includedinallcopiesorsubstantialportionsoftheSoftware.+*+*THESOFTWAREISPROVIDED"AS IS",WITHOUTWARRANTYOFANYKIND,+*EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOTHEWARRANTIES+*OFMERCHANTABILITY,FITNESSFORAPARTICULARPURPOSEAND+*NONINFRINGEMENT.INNOEVENTSHALLTHEAUTHORSORCOPYRIGHT+*HOLDERSBELIABLEFORANYCLAIM,DAMAGESOROTHERLIABILITY,+*WHETHERINANACTIONOFCONTRACT,TORTOROTHERWISE,ARISING+*FROM,OUTOFORINCONNECTIONWITHTHESOFTWAREORTHEUSEOR+*OTHERDEALINGSINTHESOFTWARE.+*/++/dts-v1/;+#include"rk3399-gru.dtsi"+#include<include/dt-bindings/input/linux-event-codes.h>++/*+*Kevin-specificthings+*+*ThingsinthissectionshouldusenamesfromKevinschematicsinceno+*equivalentexistsinGruschematic.Ifreferringtosignalsthatexist+*inGruweusetheGrunames,though.Confusingenoughforyou?+*/+/{+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=<&gpio430GPIO_ACTIVE_HIGH>;+vin-supply=<&pp3300>;+};++/* END REGULATORS */++backlight:backlight{+compatible="pwm-backlight";+pwms=<&cros_ec_pwm1>;+brightness-levels=<012345678910111213141516+1718192021222324252627282930+3132333435363738394041424344+4546474849505152535455565758+5960616263646566676869707172+7374757677787980818283848586+87888990919293949596979899100>;+default-brightness-level=<51>;+enable-gpios=<&gpio117GPIO_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=<&saradc2>;+#thermal-sensor-cells=<0>;+};++thermistor_ppvar_litcpu:thermistor-ppvar-litcpu{+compatible="murata,ncp15wb473";+pullup-uv=<1800000>;+pullup-ohm=<25500>;+pulldown-ohm=<0>;+io-channels=<&saradc3>;+#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=<&gpio013GPIO_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_bigcpu0>;+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_l0THERMAL_NO_LIMITTHERMAL_NO_LIMIT>;+contribution=<4096>;+};+map1{+trip=<&ppvar_bigcpu_alert>;+cooling-device=+<&cpu_b0THERMAL_NO_LIMITTHERMAL_NO_LIMIT>;+contribution=<1024>;+};+};+};++litcpu_reg_thermal:litcpu-reg-thermal{+polling-delay-passive=<100>;/* milliseconds */+polling-delay=<1000>;/* milliseconds */+thermal-sensors=<&thermistor_ppvar_litcpu0>;+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:tpmat20{+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:digitizerat9{+compatible="hid-over-i2c";+reg=<0x9>;+pinctrl-names="default";+pinctrl-0=<&cpu1_dig_irq_l&cpu1_dig_pdct_l>;++interrupt-parent=<&gpio2>;+interrupts=<4IRQ_TYPE_LEVEL_LOW>;++hid-descr-addr=<0x1>;+};+};++/* Adjustments to things in the gru baseboard */++&ap_i2c_tp{+trackpadat4a{+compatible="atmel,atmel_mxt_tp";+reg=<0x4a>;+pinctrl-names="default";+pinctrl-0=<&trackpad_int_l>;+interrupt-parent=<&gpio1>;+interrupts=<4IRQ_TYPE_LEVEL_LOW>;+wakeup-source;+};+};++&ap_i2c_ts{+touchscreenat4b{+compatible="atmel,atmel_mxt_ts";+reg=<0x4b>;+pinctrl-names="default";+pinctrl-0=<&touch_int_l>;+interrupt-parent=<&gpio3>;+interrupts=<13IRQ_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=<24RK_FUNC_GPIO&pcfg_pull_none>;+};++/* Has external pullup */+cpu1_dig_pdct_l:cpu1-dig-pdct-l{+rockchip,pins=<25RK_FUNC_GPIO&pcfg_pull_none>;+};+};++discrete-regulators{+cpu3_pen_pwr_en:cpu3-pen-pwr-en{+rockchip,pins=<430RK_FUNC_GPIO&pcfg_pull_none>;+};+};++pen{+cpu1_pen_eject:cpu1-pen-eject{+rockchip,pins=<013RK_FUNC_GPIO&pcfg_pull_up>;+};+};++wifi{+wlan_host_wake_l:wlan-host-wake-l{+rockchip,pins=<08RK_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 */
@@ -0,0 +1,1006 @@+/*+*GoogleGru(andderivatives)boarddevicetreesource+*+*Copyright2016Google,Inc+*+*Thisfileisdual-licensed:youcanuseiteitherundertheterms+*oftheGPLortheX11license,atyouroption.Notethatthisdual+*licensingonlyappliestothisfile,andnotthisprojectasa+*whole.+*+*a)Thisfileisfreesoftware;youcanredistributeitand/or+*modifyitunderthetermsoftheGNUGeneralPublicLicenseas+*publishedbytheFreeSoftwareFoundation;eitherversion2ofthe+*License,or(atyouroption)anylaterversion.+*+*Thisfileisdistributedinthehopethatitwillbeuseful,+*butWITHOUTANYWARRANTY;withouteventheimpliedwarrantyof+*MERCHANTABILITYorFITNESSFORAPARTICULARPURPOSE.Seethe+*GNUGeneralPublicLicenseformoredetails.+*+*Or,alternatively,+*+*b)Permissionisherebygranted,freeofcharge,toanyperson+*obtainingacopyofthissoftwareandassociateddocumentation+*files(the"Software"),todealintheSoftwarewithout+*restriction,includingwithoutlimitationtherightstouse,+*copy,modify,merge,publish,distribute,sublicense,and/or+*sellcopiesoftheSoftware,andtopermitpersonstowhomthe+*Softwareisfurnishedtodoso,subjecttothefollowing+*conditions:+*+*Theabovecopyrightnoticeandthispermissionnoticeshallbe+*includedinallcopiesorsubstantialportionsoftheSoftware.+*+*THESOFTWAREISPROVIDED"AS IS",WITHOUTWARRANTYOFANYKIND,+*EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOTHEWARRANTIES+*OFMERCHANTABILITY,FITNESSFORAPARTICULARPURPOSEAND+*NONINFRINGEMENT.INNOEVENTSHALLTHEAUTHORSORCOPYRIGHT+*HOLDERSBELIABLEFORANYCLAIM,DAMAGESOROTHERLIABILITY,+*WHETHERINANACTIONOFCONTRACT,TORTOROTHERWISE,ARISING+*FROM,OUTOFORINCONNECTIONWITHTHESOFTWAREORTHEUSEOR+*OTHERDEALINGSINTHESOFTWARE.+*/++#include<dt-bindings/input/input.h>+#include"rk3399.dtsi"++/{+chosen{+stdout-path="serial2:115200n8";+};++/*+*PowerTree+*+*Ingeneralanattemptismadetoincludeallrailscalledoutby+*theschematicaslongasthoserailsinteractinsomewaywith+*theAP.AKA:+*-RailsthatonlyconnecttotheEC(ordevicesthattheECtalksto)+*arenotincluded.+*-Rails_are_includediftherailsgototheAPeveniftheAP+*doesn'tcurrentlycareaboutthem/theyarealwayson.Theidea+*hereisthatitmakesiteasiertomaptotheschematicorextend+*later.+*+*IftworailsaresubstantiallythesamefromtheAP'spointof+*view,though,wewon'tcreateafullfixedregulator.We'lljust+*putthechildrailasanaliasoftheparentrail.Sometimesrails+*lookthesametotheAPbecauseoneoftheseistrue:+*-TheECcontrolstheenableandtheECalwaysenablesarailas+*longastheAPisrunning.+*-Therailsareactuallyconnectedtoeachotherbyajumperand+*thedistinctionisjusttheretoaddclarity/flexibilitytothe+*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=<&gpio012GPIO_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=<&gpio010GPIO_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=<&gpio02GPIO_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>;++/*+*Needtowait1ms+ramp-uptimebeforewecanpoweronWiFi.+*Thishasbeenapproximatedas8mstotal.+*/+regulator-enable-ramp-delay=<8000>;++enable-active-high;+gpio=<&gpio04GPIO_ACTIVE_HIGH>;++vin-supply=<&pp1800>;+};++/*+*Seehttp://crosbug.com/p/56069/+*+*Thisisabitofahack.TheWiFimoduleshouldberesetatleast+*1msafteritsregulatorshaverampedup(maxrampuptimeis~7ms).+*Withsomestretchingoftheimagination,wecancallthe1.8V+*regulatorasupply.+*/+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=<&gpio111GPIO_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=<&gpio429GPIO_ACTIVE_HIGH>;++vin-supply=<&pp3000>;+};++/*+*Technically,thisisasmallabuseof'regulator-gpio';this+*regulatorisamuxbetweenpp1800andpp3300.pp1800andpp3300are+*alwaysonthough,soitissufficienttosimplycontrolthemux+*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=<&gpio22GPIO_ACTIVE_HIGH>;+gpios=<&gpio228GPIO_ACTIVE_HIGH>;+states=<18000000x1+30000000x0>;++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=<&gpio427GPIO_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=<&gpio04GPIO_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=<&gpio12GPIO_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=<&gpio03GPIO_ACTIVE_LOW>;+linux,code=<KEY_WAKEUP>;+wakeup-source;+};+};+};++&cru{+assigned-clocks=+<&cruPLL_GPLL>,<&cruPLL_CPLL>,+<&cruPLL_NPLL>,+<&cruACLK_PERIHP>,<&cruHCLK_PERIHP>,+<&cruPCLK_PERIHP>,+<&cruACLK_PERILP0>,<&cruHCLK_PERILP0>,+<&cruPCLK_PERILP0>,<&cruACLK_CCI>,+<&cruHCLK_PERILP1>,<&cruPCLK_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:rt5514at57{+compatible="realtek,rt5514";+reg=<0x57>;+pinctrl-names="default";+pinctrl-0=<&mic_int>;++interrupt-parent=<&gpio1>;+interrupts=<13IRQ_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";++/*+*Notestrangepullupenable.Apparentlythisavoidsleakagebut+*stillallowsustogetnice4.7Kpullupsforhighspeedi2c+*transfers.Basicallywewantthepulluponwhenevertheapis+*alive,sothe"en"pinjustgetssettooutputhigh.+*/+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:da7219at1a{+compatible="dlg,da7219";+reg=<0x1a>;++pinctrl-names="default";+pinctrl-0=<&headset_int_l>;++interrupt-parent=<&gpio1>;+interrupts=<23IRQ_TYPE_LEVEL_LOW>;++VDD-supply=<&pp1800>;+VDDMIC-supply=<&pp3300>;+VDDIO-supply=<&pp1800>;++clocks=<&cruSCLK_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=<&gpio227GPIO_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:pcieat0,0{+reg=<0x830000000x00x000000000x00x00000000>;+#address-cells=<3>;+#size-cells=<2>;+ranges;++mvl_wifi:wifiat0,0{+compatible="pci1b4b,2b42";+reg=<0x830100000x00x000000000x00x00100000+0x830100000x00x001000000x00x00100000>;+pinctrl-names="default";+pinctrl-0=<&wlan_host_wake_l>;+interrupt-parent=<&gpio0>;+interrupts=<8IRQ_TYPE_LEVEL_LOW>;+wakeup-source;+};+};+};++&pcie_phy{+status="okay";+};++&pwm0{+status="okay";+};++&pwm1{+status="okay";+};++&pwm2{+status="okay";+};++&pwm3{+status="okay";+};++&sdhci{+/*+*Signalintegrityisn'tgreatat200MHzand150MHz(DDR)givesthe+*same(ornearlythesame)performanceforalleMMCthatareintended+*tobeused.+*/+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"ascarddetecteventhoughit'sactually+*hookedtoground.Becausewespecified"cd-gpios"belowdw_mmc+*shouldbeignoringcarddetectanyway.Specifyingthepinas+*sdmmc_cdmeansthatevenifyou'vegotGRF_SOC_CON7[12](force_jtag)+*turnedonthatthesystemwillstillmakesuretheportis+*configuredasSDMMCandnotJTAG.+*/+pinctrl-names="default";+pinctrl-0=<&sdmmc_clk&sdmmc_cmd&sdmmc_cd&sdmmc_cd_gpio+&sdmmc_bus4>;++bus-width=<4>;+cd-gpios=<&gpio424GPIO_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";++spiflashat0{+compatible="jedec,spi-nor";++/* May run faster once verified. */+spi-max-frequency=<10000000>;+reg=<0>;+};+};++&spi2{+status="okay";++wacky_spi_audio:spi2at0{+compatible="realtek,rt5514";+reg=<0>;++/* May run faster once verified. */+spi-max-frequency=<10000000>;+};+};++&spi5{+status="okay";++cros_ec:ecat0{+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=<1IRQ_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{+/*+*pinctrlsettingsforpinsthathavenorealowners.+*+*AtthemomentsettingsareidenticalforS0andS3,butifwelater+*needtoconfigurethingsdifferentlyforS3we'lladjusthere.+*/+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 */++/*+*WewantthisdrivenlowASAP;firmwareshouldhelpus,but+*wecanhelpourselvestoo.+*/+&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_GPIO01RK_FUNC_GPIO&pcfg_pull_up>;+};+};++discrete-regulators{+pp1500_en:pp1500-en{+rockchip,pins=<RK_GPIO010RK_FUNC_GPIO+&pcfg_pull_none>;+};++pp1800_audio_en:pp1800-audio-en{+rockchip,pins=<RK_GPIO02RK_FUNC_GPIO+&pcfg_pull_down>;+};++pp3300_disp_en:pp3300-disp-en{+rockchip,pins=<RK_GPIO427RK_FUNC_GPIO+&pcfg_pull_none>;+};++pp3000_en:pp3000-en{+rockchip,pins=<RK_GPIO012RK_FUNC_GPIO+&pcfg_pull_none>;+};++sd_io_pwr_en:sd-io-pwr-en{+rockchip,pins=<RK_GPIO22RK_FUNC_GPIO+&pcfg_pull_none>;+};++sd_pwr_1800_sel:sd-pwr-1800-sel{+rockchip,pins=<RK_GPIO228RK_FUNC_GPIO+&pcfg_pull_none>;+};++sd_slot_pwr_en:sd-slot-pwr-en{+rockchip,pins=<RK_GPIO429RK_FUNC_GPIO+&pcfg_pull_none>;+};++wlan_module_pd_l:wlan-module-pd-l{+rockchip,pins=<RK_GPIO04RK_FUNC_GPIO+&pcfg_pull_down>;+};+};++codec{+/* Has external pullup */+headset_int_l:headset-int-l{+rockchip,pins=<123RK_FUNC_GPIO&pcfg_pull_none>;+};++mic_int:mic-int{+rockchip,pins=<113RK_FUNC_GPIO&pcfg_pull_down>;+};+};++max98357a{+sdmode_en:sdmode-en{+rockchip,pins=<12RK_FUNC_GPIO&pcfg_pull_down>;+};+};++sdmmc{+/*+*Werunsdmmcatmaxspeed;bumpupdrivestrength.+*Wealsohaveexternalpulls,sodisabletheinternalones.+*/+sdmmc_bus4:sdmmc-bus4{+rockchip,pins=+<48RK_FUNC_1&pcfg_pull_none_8ma>,+<49RK_FUNC_1&pcfg_pull_none_8ma>,+<410RK_FUNC_1&pcfg_pull_none_8ma>,+<411RK_FUNC_1&pcfg_pull_none_8ma>;+};++sdmmc_clk:sdmmc-clk{+rockchip,pins=+<412RK_FUNC_1&pcfg_pull_none_8ma>;+};++sdmmc_cmd:sdmmc-cmd{+rockchip,pins=+<413RK_FUNC_1&pcfg_pull_none_8ma>;+};++/*+*Inourcasetheofficialcarddetectishookedtoground+*toavoidgettingaccesstoJTAGjustbystickingsomething+*intheSDcardslot(seetheforce_jtagbitintheTRM).+*+*Westillconfigureitascarddetectbecauseitdoesn't+*hurtanddw_mmcwillignoreit.Wemakesuretodisable+*thepullthoughsowedon'tburnneedlesspower.+*/+sdmmc_cd:sdmcc-cd{+rockchip,pins=+<07RK_FUNC_1&pcfg_pull_none>;+};++/* This is where we actually hook up CD; has external pull */+sdmmc_cd_gpio:sdmmc-cd-gpio{+rockchip,pins=<424RK_FUNC_GPIO&pcfg_pull_none>;+};+};++trackpad{+ap_i2c_tp_pu_en:ap-i2c-tp-pu-en{+rockchip,pins=<312RK_FUNC_GPIO&pcfg_output_high>;+};++trackpad_int_l:trackpad-int-l{+rockchip,pins=<14RK_FUNC_GPIO&pcfg_pull_up>;+};+};++touchscreen{+touch_int_l:touch-int-l{+rockchip,pins=<313RK_FUNC_GPIO&pcfg_pull_up>;+};++touch_reset_l:touch-reset-l{+rockchip,pins=<426RK_FUNC_GPIO&pcfg_pull_none>;+};+};++wifi{+wifi_perst_l:wifi-perst-l{+rockchip,pins=<227RK_FUNC_GPIO&pcfg_pull_none>;+};++wlan_module_reset_l:wlan-module-reset-l{+/*+*WewantthisdrivenlowASAP(As{Soon,Strongly}As+*Possible),toavoidleakagethroughthepowered-down+*WiFi.+*/+rockchip,pins=<111RK_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=<03RK_FUNC_GPIO&pcfg_pull_up>;+};+};++backlight-enable{+bl_en:bl-en{+rockchip,pins=<117RK_FUNC_GPIO&pcfg_pull_none>;+};+};++write-protect{+ap_fw_wp:ap-fw-wp{+rockchip,pins=<118RK_FUNC_GPIO&pcfg_pull_up>;+};+};++pcie{+pcie_clkreqn_cpm:pci-clkreqn-cpm{+/*+*Sinceourpciedoesn'tsupportClockPM(CPM),wewant+*tohackthisasgpio,sotheEPcouldbeableto+*de-assertitalongandmakeClockPM(CPM)work.+*/+rockchip,pins=<226RK_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 */+
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:34:50
Used for Gru/Kevin, but they should be conservative enough for all
boards. (And ideally, any board-to-board differences can be represented
via, e.g., describing regulator offsets.)
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi | 145 +++++++++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 +
2 files changed, 146 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:35:08
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Somewhat rewritten from Caesar's reposting (v2) of my patch.
Changes:
* Include USB2 PHY (which is now in -next)
* Don't include USB3 PHY, as extcon support is not ready yet
* Drop non-upstream properties
* Fixup whitespace a bit
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60 ++++++++++++++++++++++++++++++++
1 file changed, 60 insertions(+)
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-02 02:35:43
We're going to need to amend this table in board files.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-07 17:09:22
Hi Heiko,
On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
quoted
We need to add regulators to the CPU nodes, so cpufreq doesn't think it
can crank up the clock speed without changing the voltage. However, we
don't yet have the DT bindings to fully describe the Over Voltage
Protection (OVP) circuits on these boards. Without that description, we
might end up changing the voltage too much, too fast.
Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
them disabled.
Signed-off-by: Brian Norris <briannorris@chromium.org>
is there a specific reason for keeping this change separate?
Maybe not a great one. I figured they were somewhat controversial, so I
at least wanted to split the "cpufreq patches" (i.e., this and the
previous) from the main DTS(I) additions. I also figured we typically
like to keep the base SoC changes separate from the board DTS(I)
changes.
While it is nice for documentation reasons, as it stands now the previous
patch introduces a regression (cpufreq trying to scale without regulators) and
immediately fixes it here.
Right. Additionally, as noted on the previous patch, we might do the
same with EVB. But I don't know what the regulators are like for EVB.
This is probably a bigger deal, since EVB has been working (allegedly)
upstream for a while now.
There's no way to split these up without either breaking compilation or
breaking bisectability. For Kevin/Gru, they don't function at all before
this series, so I figured some "settle" time wasn't a huge deal.
So if you're ok with it, I'd like to merge this one back into the previous
patch when applying.
That'd be OK with me, as long as we're also confident about EVB.
Maybe at a minimum, I should just patch in some empty regulator nodes,
so cpufreq doesn't think there's no need to handle voltage.
Brian
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
quoted hunk
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Somewhat rewritten from Caesar's reposting (v2) of my patch.
Changes:
* Include USB2 PHY (which is now in -next)
* Don't include USB3 PHY, as extcon support is not ready yet
* Drop non-upstream properties
* Fixup whitespace a bit
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
clock-names do not match binding. The dwc3-of-simple does not care, as it just
enables all of them it seems, but binding doc states the clock names as
- clock-names: Should contain the following:
"ref_clk" Controller reference clk, have to be 24 MHz
"suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
"bus_clk" Master/Core clock, have to be >= 62.5 MHz for SS
operation and >= 30MHz for HS operation
"grf_clk" Controller grf clk
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
quoted hunk
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(+)
@@ -99,6 +99,26 @@ Rockchip platforms device tree bindings "google,veyron-speedy-rev3", "google,veyron-speedy-rev2", "google,veyron-speedy", "google,veyron", "rockchip,rk3288";+- Google Gru (dev-board):
boards sorted alphabetically please
Brian, Gru, Jaq, ... Kevin, ...
While the sorting of old boards is not right yet, new boards should be sorted.
Thanks
Heiko
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
We need to add regulators to the CPU nodes, so cpufreq doesn't think it
can crank up the clock speed without changing the voltage. However, we
don't yet have the DT bindings to fully describe the Over Voltage
Protection (OVP) circuits on these boards. Without that description, we
might end up changing the voltage too much, too fast.
Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
them disabled.
Signed-off-by: Brian Norris <briannorris@chromium.org>
is there a specific reason for keeping this change separate?
While it is nice for documentation reasons, as it stands now the previous
patch introduces a regression (cpufreq trying to scale without regulators) and
immediately fixes it here.
So if you're ok with it, I'd like to merge this one back into the previous
patch when applying.
Heiko
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-07 17:41:45
On Wed, Dec 07, 2016 at 06:12:13PM +0100, Heiko Stuebner wrote:
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
quoted
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(+)
@@ -99,6 +99,26 @@ Rockchip platforms device tree bindings "google,veyron-speedy-rev3", "google,veyron-speedy-rev2", "google,veyron-speedy", "google,veyron", "rockchip,rk3288";+- Google Gru (dev-board):
boards sorted alphabetically please
Brian, Gru, Jaq, ... Kevin, ...
While the sorting of old boards is not right yet, new boards should be sorted.
I got the idea that there was some attempt to group logically before
alphabetically. Like keeping board/SoC families together. But maybe not.
I can do as you suggested, if you don't care about keeping actual
similar boards together (i.e., veyron/3288 vs gru/3399).
Brian
From: Brian Norris <briannorris@chromium.org> Date: 2016-12-07 17:52:13
Hi,
On Wed, Dec 07, 2016 at 06:09:16PM +0100, Heiko Stuebner wrote:
Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
quoted
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Somewhat rewritten from Caesar's reposting (v2) of my patch.
Changes:
* Include USB2 PHY (which is now in -next)
* Don't include USB3 PHY, as extcon support is not ready yet
* Drop non-upstream properties
* Fixup whitespace a bit
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
insert location above usb at fe380000 is sorted wrong
So, *how* do you think things are sorted here? Alphabetical by label? Or
by node name? Or by unit address? I guess I'm seeing you meant unit
address. But pcie at f8000000 is also out of order then. I guess maybe
that's the only one then.
clock-names do not match binding. The dwc3-of-simple does not care, as it just
enables all of them it seems, but binding doc states the clock names as
- clock-names: Should contain the following:
"ref_clk" Controller reference clk, have to be 24 MHz
"suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
"bus_clk" Master/Core clock, have to be >= 62.5 MHz for SS
operation and >= 30MHz for HS operation
"grf_clk" Controller grf clk
Ah, sorry. I'll try to go with the rockchip,dwc3.txt names better.
There are a few extra clocks here now, but I think those might only be
for USB3 support, which isn't really working yet. I'll either document
them or drop them.
you could update the binding documentation to list this one.
Similar story; this is only used for some of the hacky stuff Rockchip is
doing for USB3/TypeC stuff out of tree. I'll either document it or drop
it (as I'm not actually using it yet).
Thanks,
Brian
Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
Hi,
On Wed, Dec 07, 2016 at 06:09:16PM +0100, Heiko Stuebner wrote:
quoted
Am Donnerstag, 1. Dezember 2016, 18:27:28 CET schrieb Brian Norris:
quoted
Add the dwc3 usb needed node information for rk3399.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Somewhat rewritten from Caesar's reposting (v2) of my patch.
Changes:
* Include USB2 PHY (which is now in -next)
* Don't include USB3 PHY, as extcon support is not ready yet
* Drop non-upstream properties
* Fixup whitespace a bit
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 60
++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+)
clock-names do not match binding. The dwc3-of-simple does not care, as it
just enables all of them it seems, but binding doc states the clock names
as>
- clock-names: Should contain the following:
"ref_clk" Controller reference clk, have to be 24 MHz
"suspend_clk" Controller suspend clk, have to be 24 MHz or 32 KHz
"bus_clk" Master/Core clock, have to be >= 62.5 MHz for SS
operation and >= 30MHz for HS operation
"grf_clk" Controller grf clk
Ah, sorry. I'll try to go with the rockchip,dwc3.txt names better.
There are a few extra clocks here now, but I think those might only be
for USB3 support, which isn't really working yet. I'll either document
them or drop them.
you could update the binding documentation to list this one.
Similar story; this is only used for some of the hacky stuff Rockchip is
doing for USB3/TypeC stuff out of tree. I'll either document it or drop
it (as I'm not actually using it yet).
Thanks,
Brian
Am Mittwoch, 7. Dezember 2016, 11:03:02 CET schrieb Brian Norris:
On Wed, Dec 07, 2016 at 08:01:23PM +0100, Heiko Stuebner wrote:
quoted
Am Mittwoch, 7. Dezember 2016, 09:52:08 CET schrieb Brian Norris:
quoted
But pcie at f8000000 is also out of order then. I guess maybe
that's the only one then.
Yep, pcie is misplaced as sadly sometimes I miss those errors as well.
OK. Do you want me to patch that at the end of my series, or is that
unnecessary churn?
I'm still pondering [and am investing way to much brain cells in trying to
decide this ;-) ], but tend to want to move it.
That way the dtsi gives the correct sorting impression for future dt-patches
of which I guess we'll see a lot in the time to come.
So yes, please move it as well.
Thanks
Heiko
Am Mittwoch, 7. Dezember 2016, 09:41:39 CET schrieb Brian Norris:
On Wed, Dec 07, 2016 at 06:12:13PM +0100, Heiko Stuebner wrote:
quoted
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:30 CET schrieb Brian Norris:
quoted
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(+)
@@ -99,6 +99,26 @@ Rockchip platforms device tree bindings "google,veyron-speedy-rev3", "google,veyron-speedy-rev2", "google,veyron-speedy", "google,veyron", "rockchip,rk3288";+- Google Gru (dev-board):
boards sorted alphabetically please
Brian, Gru, Jaq, ... Kevin, ...
While the sorting of old boards is not right yet, new boards should be
sorted.
I got the idea that there was some attempt to group logically before
alphabetically. Like keeping board/SoC families together. But maybe not.
I can do as you suggested, if you don't care about keeping actual
similar boards together (i.e., veyron/3288 vs gru/3399).
I'd prefer a simple alphabetical sorting.
I think people reading the document will know what device they have, but not
necessarily the actual soc in it. At least I would look for Google Kevin
primarily without thinking of the soc at first.
And in general, most Rockchip boards (maybe except Google-boards) tend to
follow the reference design quite closely, so it may become hard to decide
when one is similar to another :-) . So best to keep it simple.
From: Rob Herring <robh@kernel.org> Date: 2016-12-09 17:54:06
On Thu, Dec 01, 2016 at 06:27:30PM -0800, Brian Norris wrote:
quoted hunk
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(+)
Am Freitag, 9. Dezember 2016, 11:54:02 CET schrieb Rob Herring:
On Thu, Dec 01, 2016 at 06:27:30PM -0800, Brian Norris wrote:
quoted
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(+)
All of these are supposed to be specified or just one rev at a time?
All of them. I.e. the devicetree is supposed to be compatible with all of
those, while the bootloader determines the actual board revision and sets the
choosen compatible - at least that was the way with the previous series of
devices based around the rk3288 (veyron) and I think it will be the same way
still.
I.e. as you can see below, Kevin starts being compatible at -rev6, as
(engineering) revisions before that probably had some differences on the
board.
Am Donnerstag, 1. Dezember 2016, 18:27:33 CET schrieb Brian Norris:
We need to enable this regulator before the digitizer can be used. Wacom
recommended waiting for 100 ms before talking to the HID.
Signed-off-by: Brian Norris <briannorris@chromium.org>
---
Uses WIP bindings:
[PATCH v3 1/2] devicetree: i2c-hid: Add regulator support
https://patchwork.kernel.org/patch/9457493/
if you notice the bindings being accepted before me, could you notify here
please?
Thanks
Heiko
Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris:
Hi Heiko,
On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
quoted
Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
quoted
We need to add regulators to the CPU nodes, so cpufreq doesn't think it
can crank up the clock speed without changing the voltage. However, we
don't yet have the DT bindings to fully describe the Over Voltage
Protection (OVP) circuits on these boards. Without that description, we
might end up changing the voltage too much, too fast.
Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
them disabled.
Signed-off-by: Brian Norris <briannorris@chromium.org>
is there a specific reason for keeping this change separate?
Maybe not a great one. I figured they were somewhat controversial, so I
at least wanted to split the "cpufreq patches" (i.e., this and the
previous) from the main DTS(I) additions. I also figured we typically
like to keep the base SoC changes separate from the board DTS(I)
changes.
I was scratching my head for a bit where this was affecting the evb, until I
found the include at the end of patch5 :-) .
quoted
While it is nice for documentation reasons, as it stands now the previous
patch introduces a regression (cpufreq trying to scale without regulators)
and immediately fixes it here.
Right. Additionally, as noted on the previous patch, we might do the
same with EVB. But I don't know what the regulators are like for EVB.
This is probably a bigger deal, since EVB has been working (allegedly)
upstream for a while now.
Yep, it was at least booting :-) . I guess I should wire it up again. My shiny
new Gru somehow did take up its space recently.
There's no way to split these up without either breaking compilation or
breaking bisectability. For Kevin/Gru, they don't function at all before
this series, so I figured some "settle" time wasn't a huge deal.
quoted
So if you're ok with it, I'd like to merge this one back into the previous
patch when applying.
That'd be OK with me, as long as we're also confident about EVB.
That somehow sounds unrelated, as this patch only touches gru stuff anyway. So
if the evb breaks, it would do so after patch5 already.
Maybe at a minimum, I should just patch in some empty regulator nodes,
so cpufreq doesn't think there's no need to handle voltage.
So I guess going forward we could do, describe the evb pwm regulators (in
disabled state), add general OPPs, add gru with pwm regulators?
I'll try to hook up my evb and check on the pwm-regulators in the schematics
this week.
Heiko
Am Dienstag, 13. Dezember 2016, 18:48:50 schrieb Heiko Stuebner:
Am Mittwoch, 7. Dezember 2016, 09:09:17 CET schrieb Brian Norris:
quoted
Hi Heiko,
On Wed, Dec 07, 2016 at 05:48:24PM +0100, Heiko Stuebner wrote:
quoted
Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
quoted
We need to add regulators to the CPU nodes, so cpufreq doesn't think
it
can crank up the clock speed without changing the voltage. However, we
don't yet have the DT bindings to fully describe the Over Voltage
Protection (OVP) circuits on these boards. Without that description,
we
might end up changing the voltage too much, too fast.
Add the pwm-regulator descriptions and associate the CPU OPPs, but
leave
them disabled.
Signed-off-by: Brian Norris <briannorris@chromium.org>
is there a specific reason for keeping this change separate?
Maybe not a great one. I figured they were somewhat controversial, so I
at least wanted to split the "cpufreq patches" (i.e., this and the
previous) from the main DTS(I) additions. I also figured we typically
like to keep the base SoC changes separate from the board DTS(I)
changes.
I was scratching my head for a bit where this was affecting the evb, until I
found the include at the end of patch5 :-) .
quoted
quoted
While it is nice for documentation reasons, as it stands now the
previous
patch introduces a regression (cpufreq trying to scale without
regulators)
and immediately fixes it here.
Right. Additionally, as noted on the previous patch, we might do the
same with EVB. But I don't know what the regulators are like for EVB.
This is probably a bigger deal, since EVB has been working (allegedly)
upstream for a while now.
Yep, it was at least booting :-) . I guess I should wire it up again. My
shiny new Gru somehow did take up its space recently.
quoted
There's no way to split these up without either breaking compilation or
breaking bisectability. For Kevin/Gru, they don't function at all before
this series, so I figured some "settle" time wasn't a huge deal.
quoted
So if you're ok with it, I'd like to merge this one back into the
previous
patch when applying.
That'd be OK with me, as long as we're also confident about EVB.
That somehow sounds unrelated, as this patch only touches gru stuff anyway.
So if the evb breaks, it would do so after patch5 already.
quoted
Maybe at a minimum, I should just patch in some empty regulator nodes,
so cpufreq doesn't think there's no need to handle voltage.
So I guess going forward we could do, describe the evb pwm regulators (in
disabled state), add general OPPs, add gru with pwm regulators?
I'll try to hook up my evb and check on the pwm-regulators in the schematics
this week.
Now I remember why I retired my evb ... ES1 silicon.
Anyway, I was able to describe the rk808 pmic that is used in some basic way
and was able to see a bit of cpu-scaling on the little cluster, but the big
cluster never was able to scale in a stable way and always hung the system.
I don't think that we should care about ES1 chips as they never reached any
public but that leaves me without the ability to test.
In another issue I read that Caesar also is using a rk3399evb sometimes, so
maybe he can give that a try on real ES2 silicon and I've thus Cc'ed him.
@Caesar I don't know how much the power rails differ between evb versions, so
maybe you can also provide the necessary rk808 devicetree nodes please?
Thanks
Heiko
From: Brian Norris <briannorris@chromium.org> Date: 2017-02-08 01:03:34
On Wed, Feb 08, 2017 at 02:01:42AM +0100, Heiko Stuebner wrote:
Am Donnerstag, 1. Dezember 2016, 18:27:24 CET schrieb Brian Norris:
quoted
This series adds basic support for Google Kevin, a board in the Gru device
family. I do not add a leaf .dts board file for Gru, but I have retained the
split between "things that apply to the Gru family" (rk3399-gru.dtsi) and
"things that apply to Kevin only" (rk3399-gru-kevin.dtsi).
do you plan on refreshing these patches against the current kernel and the
comments received at some point?
I've fixed up a few locally, but I haven't had the time to
retest/resend. I plan to do so eventually, but not soon.
Brian
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:24 CET schrieb Brian Norris:
This series adds basic support for Google Kevin, a board in the Gru device
family. I do not add a leaf .dts board file for Gru, but I have retained the
split between "things that apply to the Gru family" (rk3399-gru.dtsi) and
"things that apply to Kevin only" (rk3399-gru-kevin.dtsi).
do you plan on refreshing these patches against the current kernel and the
comments received at some point?
Heiko