AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-28 11:18:45 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
30eb8ea46c
linux_dsm_epyc7002/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi

403 lines
8.1 KiB
Plaintext
Raw Normal View History

arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
* Google Gru-Chromebook shared properties
*
* Copyright 2018 Google, Inc
*/
#include "rk3399-gru.dtsi"
/ {
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>;
};
/* EC turns on w/ pp900_usb_en */
pp900_usb: pp900-ap {
};
/* EC turns on w/ pp900_pcie_en */
pp900_pcie: pp900-ap {
};
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>;
};
ppvar_centerlogic_pwm: ppvar-centerlogic-pwm {
compatible = "pwm-regulator";
regulator-name = "ppvar_centerlogic_pwm";
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;
regulator-min-microvolt = <799434>;
regulator-max-microvolt = <1049925>;
};
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>;
};
/* 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>;
};
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>;
};
/* Always on; plain and simple */
pp3000_ap: pp3000_emmc: pp3000 {
};
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>;
};
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>;
};
/* EC turns on w/ pp3300_usb_en_l */
pp3300_usb: 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>;
};
/*
* 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";
pinctrl-names = "default";
pinctrl-0 = <&wlan_module_reset_l>;
enable-active-high;
gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
vin-supply = <&pp1800_pcie>;
};
arm64: dts: rockchip: move core edp from rk3399-kevin to shared chromebook Bob needs the same backlight and core edp settings, so move these nodes to the shared dtsi that both will use as a base. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 21:06:30 +07:00
backlight: backlight {
compatible = "pwm-backlight";
enable-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
power-supply = <&pp3300_disp>;
pinctrl-names = "default";
pinctrl-0 = <&bl_en>;
pwm-delay-us = <10000>;
};
arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node Currently, we don't coordinate BT USB activity with our handling of the BT out-of-band wake pin, and instead just use gpio-keys. That causes problems because we have no way of distinguishing wake activity due to a BT device (e.g., mouse) vs. the BT controller (e.g., re-configuring wake mask before suspend). This can cause spurious wake events just because we, for instance, try to reconfigure the host controller's event mask before suspending. We can avoid these synchronization problems by handling the BT wake pin directly in the btusb driver -- for all activity up until BT controller suspend(), we simply listen to normal USB activity (e.g., to know the difference between device and host activity); once we're really ready to suspend the host controller, there should be no more host activity, and only *then* do we unmask the GPIO interrupt. This is already supported by btusb; we just need to describe the wake pin in the right node. We list 2 compatible properties, since both PID/VID pairs show up on Scarlet devices, and they're both essentially identical QCA6174A-based modules. Also note that the polarity was wrong before: Qualcomm implemented WAKE as active high, not active low. We only got away with this because gpio-keys always reconfigured us as bi-directional edge-triggered. Finally, we have an external pull-up and a level-shifter on this line (we didn't notice Qualcomm's polarity in the initial design), so we can't do pull-down. Switch to pull-none. Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-02-23 05:53:45 +07:00
gpio_keys: gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&bt_host_wake_l>;
wake_on_bt: wake-on-bt {
label = "Wake-on-Bluetooth";
gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
linux,code = <KEY_WAKEUP>;
wakeup-source;
};
};
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
};
&ppvar_bigcpu {
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
&ppvar_litcpu {
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
&ppvar_gpu {
min-slew-down-rate = <225>;
ovp-threshold-percent = <16>;
};
&cdn_dp {
extcon = <&usbc_extcon0>, <&usbc_extcon1>;
};
arm64: dts: rockchip: move core edp from rk3399-kevin to shared chromebook Bob needs the same backlight and core edp settings, so move these nodes to the shared dtsi that both will use as a base. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 21:06:30 +07:00
&edp {
status = "okay";
ports {
edp_out: port@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
edp_out_panel: endpoint@0 {
reg = <0>;
remote-endpoint = <&panel_in_edp>;
};
};
};
};
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07: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>;
realtek,dmic-init-delay-ms = <20>;
};
};
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>;
};
&cros_ec {
cros_ec_pwm: ec-pwm {
compatible = "google,cros-ec-pwm";
#pwm-cells = <1>;
};
usbc_extcon1: extcon@1 {
compatible = "google,extcon-usbc-cros-ec";
google,usb-port-id = <1>;
#extcon-cells = <0>;
};
};
&sound {
rockchip,codec = <&max98357a &headsetcodec
&codec &wacky_spi_audio &cdn_dp>;
};
&spi2 {
wacky_spi_audio: spi2@0 {
compatible = "realtek,rt5514";
reg = <0>;
interrupt-parent = <&gpio1>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&mic_int>;
/* May run faster once verified. */
spi-max-frequency = <10000000>;
wakeup-source;
};
};
&pci_rootport {
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;
};
};
&tcphy1 {
status = "okay";
extcon = <&usbc_extcon1>;
};
&u2phy1 {
status = "okay";
};
&usb_host0_ehci {
status = "okay";
};
&usb_host1_ehci {
status = "okay";
};
&usb_host1_ohci {
status = "okay";
};
&usbdrd3_1 {
status = "okay";
extcon = <&usbc_extcon1>;
};
&usbdrd_dwc3_1 {
status = "okay";
dr_mode = "host";
};
&pinctrl {
discrete-regulators {
pp1500_en: pp1500-en {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
&pcfg_pull_none>;
};
pp1800_audio_en: pp1800-audio-en {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
&pcfg_pull_down>;
};
pp3000_en: pp3000-en {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <0 RK_PB4 RK_FUNC_GPIO
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
&pcfg_pull_none>;
};
pp3300_disp_en: pp3300-disp-en {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <4 RK_PD3 RK_FUNC_GPIO
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
&pcfg_pull_none>;
};
wlan_module_pd_l: wlan-module-pd-l {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
&pcfg_pull_down>;
};
};
};
&wifi {
wifi_perst_l: wifi-perst-l {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
};
wlan_host_wake_l: wlan-host-wake-l {
arm64: dts: rockchip: bulk convert gpios to their constant counterparts Rockchip SoCs use 2 different numbering schemes. Where the gpio- controllers just count 0-31 for their 32 gpios, the underlying iomux controller splits these into 4 separate entities A-D. Device-schematics always use these iomux-values to identify pins, so to make mapping schematics to devicetree easier Andy Yan introduced named constants for the pins but so far we only used them on new additions. Using a sed-script created by Emil Renner Berthing bulk-convert the remaining raw gpio numbers into their descriptive counterparts and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x mappings: /rockchip,pins *=/bcheck b # to end of script :append-next-line N :check /^[^;]*$/bappend-next-line s/<RK_GPIO\([0-9]\) /<\1 /g s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g Suggested-by: Emil Renner Berthing <esmil@mailme.dk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Acked-by: Robin Murphy <robin.murphy@arm.com>
2019-04-02 18:56:24 +07:00
rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
arm64: dts: rockchip: move Chromebook-specific Gru-parts to a separate file Similar to rk3288-Veyron before, the Gru-series does contain Chromebook (aka clamshell laptops) and non-Chromebook devices. And while the two Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet- device is quite different in its design. Therefore move the Chromebook parts into a gru-chromebook dtsi file to make sharing easier. Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2018-06-02 13:53:40 +07:00
};
};
Reference in New Issue Copy Permalink