linux/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts

340 lines
6.4 KiB
Text
Raw Permalink Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (C) 2020 Stephan Gerhold
*/
/dts-v1/;
#include "msm8916-pm8916.dtsi"
#include "msm8916-modem-qdsp6.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
/ {
model = "Xiaomi Redmi 2 (Wingtech WT88047)";
compatible = "wingtech,wt88047", "qcom,msm8916";
chassis-type = "handset";
aliases {
mmc0 = &sdhc_1; /* eMMC */
mmc1 = &sdhc_2; /* SD card */
serial0 = &blsp_uart2;
};
chosen {
stdout-path = "serial0";
};
speaker_amp: audio-amplifier {
compatible = "simple-audio-amplifier";
enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
sound-name-prefix = "Speaker Amp";
pinctrl-0 = <&speaker_amp_default>;
pinctrl-names = "default";
};
/*
* This seems to be actually an analog switch that either routes audio
* to the headphone jack or nowhere. Given that we need to enable a GPIO
* to get sound on headphones, modelling it as simple-audio-amplifier
* works just fine.
*/
headphones_switch: audio-switch {
compatible = "simple-audio-amplifier";
enable-gpios = <&tlmm 8 GPIO_ACTIVE_HIGH>;
sound-name-prefix = "Headphones Switch";
pinctrl-0 = <&headphones_switch_default>;
pinctrl-names = "default";
};
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = <&tlmm 31 GPIO_ACTIVE_HIGH>;
flash-gpios = <&tlmm 32 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&camera_flash_default>;
flash_led: led {
function = LED_FUNCTION_FLASH;
color = <LED_COLOR_ID_WHITE>;
};
};
gpio-keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&gpio_keys_default>;
label = "GPIO Buttons";
button-volume-up {
label = "Volume Up";
gpios = <&tlmm 107 GPIO_ACTIVE_LOW>;
linux,code = <KEY_VOLUMEUP>;
};
};
usb_id: usb-id {
compatible = "linux,extcon-usb-gpio";
id-gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&usb_id_default>;
};
};
&blsp_i2c2 {
status = "okay";
imu@68 {
compatible = "invensense,mpu6880";
reg = <0x68>;
interrupt-parent = <&tlmm>;
interrupts = <115 IRQ_TYPE_EDGE_RISING>;
vdd-supply = <&pm8916_l17>;
vddio-supply = <&pm8916_l6>;
pinctrl-names = "default";
pinctrl-0 = <&imu_default>;
mount-matrix = "1", "0", "0",
"0", "-1", "0",
"0", "0", "1";
};
};
&blsp_i2c5 {
status = "okay";
touchscreen@38 {
/* Likely some other model but works just fine with this one */
compatible = "edt,edt-ft5506";
reg = <0x38>;
interrupt-parent = <&tlmm>;
interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
reset-gpios = <&tlmm 12 GPIO_ACTIVE_LOW>;
vcc-supply = <&pm8916_l17>;
iovcc-supply = <&pm8916_l6>;
touchscreen-size-x = <720>;
touchscreen-size-y = <1280>;
pinctrl-names = "default";
pinctrl-0 = <&touchscreen_default>;
};
};
&blsp_i2c6 {
status = "okay";
led-controller@45 {
compatible = "awinic,aw2013";
reg = <0x45>;
#address-cells = <1>;
#size-cells = <0>;
vcc-supply = <&pm8916_l16>;
vio-supply = <&pm8916_l5>;
led@0 {
reg = <0>;
led-max-microamp = <15000>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_RED>;
};
led@1 {
reg = <1>;
led-max-microamp = <15000>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_GREEN>;
};
led@2 {
reg = <2>;
led-max-microamp = <15000>;
function = LED_FUNCTION_INDICATOR;
color = <LED_COLOR_ID_BLUE>;
};
};
};
&blsp_uart2 {
status = "okay";
pinctrl-0 = <&blsp_uart2_console_default>;
pinctrl-1 = <&blsp_uart2_console_sleep>;
pinctrl-names = "default", "sleep";
};
&mpss_mem {
reg = <0x0 0x86800000 0x0 0x5100000>;
};
&pm8916_codec {
qcom,micbias1-ext-cap;
qcom,micbias-lvl = <2800>;
qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
qcom,hphl-jack-type-normally-open;
};
&pm8916_resin {
status = "okay";
linux,code = <KEY_VOLUMEDOWN>;
};
arm64: dts: qcom: msm8916: Define regulator constraints next to usage Right now each MSM8916 device has a huge block of regulator constraints with allowed voltages for each regulator. For lack of better documentation these voltages are often copied as-is from the vendor device tree, without much extra thought. Unfortunately, the voltages in the vendor device trees are often misleading or even wrong, e.g. because: - There is a large voltage range allowed and the actual voltage is only set somewhere hidden in some messy vendor driver. This is often the case for pm8916_{l14,l15,l16} because they have a broad range of 1.8-3.3V by default. - The voltage is actually wrong but thanks to the voltage constraints in the RPM firmware it still ends up applying the correct voltage. To have proper regulator constraints it is important to review them in context of the usage. The current setup in the MSM8916 device trees makes this quite hard because each device duplicates the standard voltages for components of the SoC and mixes those with minor device-specific additions and dummy voltages for completely unused regulators. The actual usage of the regulators for the SoC components is in msm8916-pm8916.dtsi, so it can and should also define the related voltage constraints. These are not board-specific but defined in the APQ8016E/PM8916 Device Specification. The board DT can then focus on describing the actual board-specific regulators, which makes it much easier to review and spot potential mistakes there. Note that this commit does not make any functional change. All used regulators still have the same regulator constraints as before. Unused regulators do not have regulator constraints anymore because most of these were too broad or even entirely wrong. They should be added back with proper voltage constraints when there is an actual usage. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230510-msm8916-regulators-v1-7-54d4960a05fc@gerhold.net
2023-05-17 20:48:46 +02:00
&pm8916_rpm_regulators {
pm8916_l16: l16 {
/*
* L16 is only used for AW2013 which is fine with 2.5-3.3V.
* Use the recommended typical voltage of 2.8V as minimum.
*/
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <3300000>;
};
pm8916_l17: l17 {
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
};
};
&pm8916_vib {
status = "okay";
};
&sdhc_1 {
status = "okay";
};
&sdhc_2 {
status = "okay";
non-removable;
};
&sound {
/*
* Provide widgets/pin-switches to allow enabling speaker and headphones
* separately. Both are routed via the HPH_L/HPH_R pins of the codec.
*/
model = "wt88047";
widgets =
"Speaker", "Speaker",
"Headphone", "Headphones";
pin-switches = "Speaker", "Headphones";
audio-routing =
"Speaker", "Speaker Amp OUTL",
"Speaker", "Speaker Amp OUTR",
"Speaker Amp INL", "HPH_R",
"Speaker Amp INR", "HPH_R",
"Headphones", "Headphones Switch OUTL",
"Headphones", "Headphones Switch OUTR",
"Headphones Switch INL", "HPH_L",
"Headphones Switch INR", "HPH_R",
"AMIC1", "MIC BIAS External1",
"AMIC2", "MIC BIAS Internal2";
aux-devs = <&speaker_amp>, <&headphones_switch>;
};
&usb {
status = "okay";
extcon = <&usb_id>, <&usb_id>;
};
&usb_hs_phy {
extcon = <&usb_id>;
};
&venus {
status = "okay";
};
&venus_mem {
status = "okay";
};
arm64: dts: qcom: msm8916: Move WCN compatible to boards On MSM8916 the wireless connectivity functionality (WiFi/Bluetooth) is split into the digital part inside the SoC and the analog RF part inside a supplementary WCN36xx chip. For MSM8916, three different options exist: - WCN3620 (WLAN 802.11 b/g/n 2.4 GHz + Bluetooth) - WCN3660B (WLAN 802.11 a/b/g/n 2.4/5 GHz + Bluetooth) - WCN3680B (WLAN 802.11ac 2.4/5 GHz + Bluetooth) Choosing one of these is up to the board vendor. This means that the compatible belongs into the board-specific DT part so people porting new boards pay attention to set the correct compatible. Right now msm8916.dtsi sets "qcom,wcn3620" as default compatible, which does not work at all for boards that have WCN3660B or WCN3680B. Remove the default compatible from msm8196.dtsi and move it to the board DT as follows: - Boards with only &pronto { status = "okay"; } used the default "qcom,wcn3620" so far. They now set this explicitly for &wcnss_iris. - Boards with &pronto { ... iris { compatible = "qcom,wcn3660b"; }}; already had an override that just moves to &wcnss_iris now. - For msm8916-samsung-a2015-common.dtsi the WCN compatible differs for boards making use of it (a3u: wcn3620, a5u: wcn3660b, e2015: wcn3620) so the definitions move to the board-specific DT part. Since this requires touching all the board DTs, use this as a chance to name the WCNSS-related labels consistently, so everything is grouped properly when sorted alphabetically. No functional change, just clean-up for more clarity & easier porting. Aside from ordering the generated DTBs are identical. Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230309091452.1011776-1-stephan.gerhold@kernkonzept.com
2023-03-09 10:14:52 +01:00
&wcnss {
status = "okay";
};
&wcnss_iris {
compatible = "qcom,wcn3620";
};
&wcnss_mem {
status = "okay";
};
&tlmm {
camera_flash_default: camera-flash-default-state {
pins = "gpio31", "gpio32";
function = "gpio";
drive-strength = <2>;
bias-disable;
};
gpio_keys_default: gpio-keys-default-state {
pins = "gpio107";
function = "gpio";
drive-strength = <2>;
bias-pull-up;
};
headphones_switch_default: headphones-switch-default-state {
pins = "gpio8";
function = "gpio";
drive-strength = <2>;
bias-disable;
};
imu_default: imu-default-state {
pins = "gpio115";
function = "gpio";
drive-strength = <2>;
bias-disable;
};
speaker_amp_default: speaker-amp-default-state {
pins = "gpio117";
function = "gpio";
drive-strength = <2>;
bias-disable;
};
touchscreen_default: touchscreen-default-state {
touchscreen-pins {
pins = "gpio13";
function = "gpio";
drive-strength = <2>;
bias-pull-up;
};
reset-pins {
pins = "gpio12";
function = "gpio";
drive-strength = <2>;
bias-disable;
};
};
usb_id_default: usb-id-default-state {
pins = "gpio110";
function = "gpio";
drive-strength = <8>;
bias-pull-up;
};
};