* [PATCH v6 27/36] ARM: dts: qcom: pm8058: switch to interrupts-extended
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
Merge interrups and interrupt-parent properties into a single
interrupts-extended property.
Suggested-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/pm8058.dtsi | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/pm8058.dtsi b/arch/arm/boot/dts/qcom/pm8058.dtsi
index 3683d7b60918..984b79777984 100644
--- a/arch/arm/boot/dts/qcom/pm8058.dtsi
+++ b/arch/arm/boot/dts/qcom/pm8058.dtsi
@@ -11,9 +11,8 @@ pm8058: pmic {
pwrkey@1c {
compatible = "qcom,pm8058-pwrkey";
reg = <0x1c>;
- interrupt-parent = <&pm8058>;
- interrupts = <50 IRQ_TYPE_EDGE_RISING>,
- <51 IRQ_TYPE_EDGE_RISING>;
+ interrupts-extended = <&pm8058 50 IRQ_TYPE_EDGE_RISING>,
+ <&pm8058 51 IRQ_TYPE_EDGE_RISING>;
debounce = <15625>;
pull-up;
};
@@ -61,9 +60,8 @@ pm8058_led133: led@133 {
pm8058_keypad: keypad@148 {
compatible = "qcom,pm8058-keypad";
reg = <0x148>;
- interrupt-parent = <&pm8058>;
- interrupts = <74 IRQ_TYPE_EDGE_RISING>,
- <75 IRQ_TYPE_EDGE_RISING>;
+ interrupts-extended = <&pm8058 74 IRQ_TYPE_EDGE_RISING>,
+ <&pm8058 75 IRQ_TYPE_EDGE_RISING>;
debounce = <15>;
scan-delay = <32>;
row-hold = <91500>;
@@ -136,8 +134,7 @@ ref_muxoff: adc-channel@f {
rtc@1e8 {
compatible = "qcom,pm8058-rtc";
reg = <0x1e8>;
- interrupt-parent = <&pm8058>;
- interrupts = <39 IRQ_TYPE_EDGE_RISING>;
+ interrupts-extended = <&pm8058 39 IRQ_TYPE_EDGE_RISING>;
allow-set-time;
};
};
--
2.39.2
^ permalink raw reply related
* [PATCH v6 29/36] ARM: dts: qcom: mdm9615: move RPM regulators to board files
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
The set of regulators available over the RPM requests is not a property
of the SoC. Move them to board files.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../boot/dts/qcom/qcom-mdm9615-wp8548.dtsi | 136 ++++++++++++++++++
arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi | 134 -----------------
2 files changed, 136 insertions(+), 134 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-mdm9615-wp8548.dtsi b/arch/arm/boot/dts/qcom/qcom-mdm9615-wp8548.dtsi
index 27c3d92d9452..0dd52cac0e2e 100644
--- a/arch/arm/boot/dts/qcom/qcom-mdm9615-wp8548.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-mdm9615-wp8548.dtsi
@@ -134,6 +134,142 @@ &gsbi5_serial {
pinctrl-names = "default";
};
+&rpm {
+ regulators {
+ compatible = "qcom,rpm-pm8018-regulators";
+
+ vin_lvs1-supply = <&pm8018_s3>;
+
+ vdd_l7-supply = <&pm8018_s4>;
+ vdd_l8-supply = <&pm8018_s3>;
+ vdd_l9_l10_l11_l12-supply = <&pm8018_s5>;
+
+ /* Buck SMPS */
+ pm8018_s1: s1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1150000>;
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+ };
+
+ pm8018_s2: s2 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1300000>;
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+ };
+
+ pm8018_s3: s3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+ };
+
+ pm8018_s4: s4 {
+ regulator-min-microvolt = <2100000>;
+ regulator-max-microvolt = <2200000>;
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+ };
+
+ pm8018_s5: s5 {
+ regulator-always-on;
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ qcom,switch-mode-frequency = <1600000>;
+ bias-pull-down;
+ };
+
+ /* PMOS LDO */
+ pm8018_l2: l2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ bias-pull-down;
+ };
+
+ pm8018_l3: l3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ bias-pull-down;
+ };
+
+ pm8018_l4: l4 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ bias-pull-down;
+ };
+
+ pm8018_l5: l5 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ bias-pull-down;
+ };
+
+ pm8018_l6: l6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2850000>;
+ bias-pull-down;
+ };
+
+ pm8018_l7: l7 {
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1900000>;
+ bias-pull-down;
+ };
+
+ pm8018_l8: l8 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ bias-pull-down;
+ };
+
+ pm8018_l9: l9 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1150000>;
+ bias-pull-down;
+ };
+
+ pm8018_l10: l10 {
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ bias-pull-down;
+ };
+
+ pm8018_l11: l11 {
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ bias-pull-down;
+ };
+
+ pm8018_l12: l12 {
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ bias-pull-down;
+ };
+
+ pm8018_l13: l13 {
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <2950000>;
+ bias-pull-down;
+ };
+
+ pm8018_l14: l14 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ bias-pull-down;
+ };
+
+ /* Low Voltage Switch */
+ pm8018_lvs1: lvs1 {
+ bias-pull-down;
+ };
+ };
+};
+
&sdcc1 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi
index e23ca6c42683..07e712e890f6 100644
--- a/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi
@@ -338,140 +338,6 @@ rpm: rpm@108000 {
<GIC_SPI 21 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 22 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "ack", "err", "wakeup";
-
- regulators {
- compatible = "qcom,rpm-pm8018-regulators";
-
- vin_lvs1-supply = <&pm8018_s3>;
-
- vdd_l7-supply = <&pm8018_s4>;
- vdd_l8-supply = <&pm8018_s3>;
- vdd_l9_l10_l11_l12-supply = <&pm8018_s5>;
-
- /* Buck SMPS */
- pm8018_s1: s1 {
- regulator-min-microvolt = <500000>;
- regulator-max-microvolt = <1150000>;
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
- };
-
- pm8018_s2: s2 {
- regulator-min-microvolt = <1225000>;
- regulator-max-microvolt = <1300000>;
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
- };
-
- pm8018_s3: s3 {
- regulator-always-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
- };
-
- pm8018_s4: s4 {
- regulator-min-microvolt = <2100000>;
- regulator-max-microvolt = <2200000>;
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
- };
-
- pm8018_s5: s5 {
- regulator-always-on;
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- qcom,switch-mode-frequency = <1600000>;
- bias-pull-down;
- };
-
- /* PMOS LDO */
- pm8018_l2: l2 {
- regulator-always-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- bias-pull-down;
- };
-
- pm8018_l3: l3 {
- regulator-always-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- bias-pull-down;
- };
-
- pm8018_l4: l4 {
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- bias-pull-down;
- };
-
- pm8018_l5: l5 {
- regulator-min-microvolt = <2850000>;
- regulator-max-microvolt = <2850000>;
- bias-pull-down;
- };
-
- pm8018_l6: l6 {
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <2850000>;
- bias-pull-down;
- };
-
- pm8018_l7: l7 {
- regulator-min-microvolt = <1850000>;
- regulator-max-microvolt = <1900000>;
- bias-pull-down;
- };
-
- pm8018_l8: l8 {
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- bias-pull-down;
- };
-
- pm8018_l9: l9 {
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1150000>;
- bias-pull-down;
- };
-
- pm8018_l10: l10 {
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- bias-pull-down;
- };
-
- pm8018_l11: l11 {
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- bias-pull-down;
- };
-
- pm8018_l12: l12 {
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- bias-pull-down;
- };
-
- pm8018_l13: l13 {
- regulator-min-microvolt = <1850000>;
- regulator-max-microvolt = <2950000>;
- bias-pull-down;
- };
-
- pm8018_l14: l14 {
- regulator-min-microvolt = <2850000>;
- regulator-max-microvolt = <2850000>;
- bias-pull-down;
- };
-
- /* Low Voltage Switch */
- pm8018_lvs1: lvs1 {
- bias-pull-down;
- };
- };
};
};
};
--
2.39.2
^ permalink raw reply related
* [PATCH v6 31/36] ARM: dts: qcom: msm8960: drop useless rpm regulators node
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
The set of regulators available over the RPM requests is not a property
of the SoC. The only msm8960 board file (qcom-msm8960-cdp) also defines
this node together with the compatible string. Drop the useless device
node.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index 774f507fa25a..f420740e068e 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -200,10 +200,6 @@ rpm: rpm@108000 {
<GIC_SPI 21 IRQ_TYPE_EDGE_RISING>,
<GIC_SPI 22 IRQ_TYPE_EDGE_RISING>;
interrupt-names = "ack", "err", "wakeup";
-
- regulators {
- compatible = "qcom,rpm-pm8921-regulators";
- };
};
acc0: clock-controller@2088000 {
--
2.39.2
^ permalink raw reply related
* [PATCH v6 28/36] ARM: dts: qcom: apq8064: move RPM regulators to board files
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
The set of regulators available over the RPM requests is not a property
of the SoC. Move them to board files.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../dts/qcom/qcom-apq8064-asus-nexus7-flo.dts | 42 ++++----
.../boot/dts/qcom/qcom-apq8064-cm-qs600.dts | 22 ++---
.../boot/dts/qcom/qcom-apq8064-ifc6410.dts | 29 +++---
.../qcom-apq8064-sony-xperia-lagan-yuga.dts | 98 +++++++++++--------
arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 63 ------------
5 files changed, 108 insertions(+), 146 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
index d709d6e840ec..329c2546aa0a 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-asus-nexus7-flo.dts
@@ -199,11 +199,12 @@ &pm8921 {
&rpm {
regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+
vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
vin_lvs1_3_6-supply = <&pm8921_s4>;
vin_lvs4_5_7-supply = <&pm8921_s4>;
-
vdd_l24-supply = <&pm8921_s1>;
vdd_l25-supply = <&pm8921_s1>;
vin_lvs2-supply = <&pm8921_s1>;
@@ -215,7 +216,7 @@ regulators {
vdd_ncp-supply = <&pm8921_l6>;
/* Buck SMPS */
- s1 {
+ pm8921_s1: s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
@@ -224,7 +225,7 @@ s1 {
};
/* msm otg HSUSB_VDDCX */
- s3 {
+ pm8921_s3: s3 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1150000>;
qcom,switch-mode-frequency = <4800000>;
@@ -237,55 +238,58 @@ s3 {
* tabla2x-slim-CDC_VDD_CP
* tabla2x-slim-VDDIO_CDC
*/
- s4 {
+ pm8921_s4: s4 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
qcom,switch-mode-frequency = <3200000>;
regulator-always-on;
};
- s7 {
+ pm8921_s7: s7 {
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
qcom,switch-mode-frequency = <3200000>;
};
/* mipi_dsi.1-dsi1_pll_vdda */
- l2 {
+ pm8921_l2: l2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
};
/* msm_otg-HSUSB_3p3 */
- l3 {
+ pm8921_l3: l3 {
regulator-min-microvolt = <3075000>;
regulator-max-microvolt = <3075000>;
bias-pull-down;
};
/* msm_otg-HSUSB_1p8 */
- l4 {
+ pm8921_l4: l4 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
/* msm_sdcc.1-sdc_vdd */
- l5 {
+ pm8921_l5: l5 {
regulator-min-microvolt = <2950000>;
regulator-max-microvolt = <2950000>;
regulator-always-on;
bias-pull-down;
};
- l6 {
+ pm8921_l6: l6 {
regulator-min-microvolt = <2950000>;
regulator-max-microvolt = <2950000>;
};
+ pm8921_l8: l8 {
+ };
+
/* mipi_dsi.1-dsi1_avdd */
- l11 {
+ pm8921_l11: l11 {
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
bias-pull-down;
@@ -293,14 +297,14 @@ l11 {
};
/* pwm_power for backlight */
- l17 {
+ pm8921_l17: l17 {
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
};
/* camera, qdsp6 */
- l23 {
+ pm8921_l23: l23 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
@@ -310,32 +314,32 @@ l23 {
* tabla2x-slim-CDC_VDDA_A_1P2V
* tabla2x-slim-VDDD_CDC_D
*/
- l25 {
+ pm8921_l25: l25 {
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <1250000>;
bias-pull-down;
};
- lvs1 {
+ pm8921_lvs1: lvs1 {
bias-pull-down;
};
- lvs4 {
+ pm8921_lvs4: lvs4 {
bias-pull-down;
};
- lvs5 {
+ pm8921_lvs5: lvs5 {
bias-pull-down;
};
- lvs6 {
+ pm8921_lvs6: lvs6 {
bias-pull-down;
};
/*
* mipi_dsi.1-dsi1_vddio
* pil_riva-pll_vdd
*/
- lvs7 {
+ pm8921_lvs7: lvs7 {
bias-pull-down;
};
};
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
index d4db84e9fcf3..671d58cc2741 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-cm-qs600.dts
@@ -93,6 +93,8 @@ pinconf {
&rpm {
regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+
vin_lvs1_3_6-supply = <&pm8921_s4>;
vin_lvs2-supply = <&pm8921_s1>;
vin_lvs4_5_7-supply = <&pm8921_s4>;
@@ -104,9 +106,8 @@ regulators {
vdd_l27-supply = <&pm8921_s7>;
vdd_l28-supply = <&pm8921_s7>;
-
/* Buck SMPS */
- s1 {
+ pm8921_s1: s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
@@ -114,52 +115,51 @@ s1 {
bias-pull-down;
};
- s3 {
+ pm8921_s3: s3 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1400000>;
qcom,switch-mode-frequency = <4800000>;
};
- s4 {
+ pm8921_s4: s4 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
qcom,switch-mode-frequency = <3200000>;
};
- s7 {
+ pm8921_s7: s7 {
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
qcom,switch-mode-frequency = <3200000>;
};
- l3 {
+ pm8921_l3: l3 {
regulator-min-microvolt = <3050000>;
regulator-max-microvolt = <3300000>;
bias-pull-down;
};
- l4 {
+ pm8921_l4: l4 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l5 {
+ pm8921_l5: l5 {
regulator-min-microvolt = <2750000>;
regulator-max-microvolt = <3000000>;
bias-pull-down;
};
- l23 {
+ pm8921_l23: l23 {
regulator-min-microvolt = <1700000>;
regulator-max-microvolt = <1900000>;
bias-pull-down;
};
- lvs6 {
+ pm8921_lvs6: lvs6 {
bias-pull-down;
};
-
};
};
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
index 5fd84319254e..3078afda37c6 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-ifc6410.dts
@@ -204,6 +204,8 @@ pinconf {
&rpm {
regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+
vin_lvs1_3_6-supply = <&pm8921_s4>;
vin_lvs2-supply = <&pm8921_s1>;
vin_lvs4_5_7-supply = <&pm8921_s4>;
@@ -215,9 +217,8 @@ regulators {
vdd_l27-supply = <&pm8921_s7>;
vdd_l28-supply = <&pm8921_s7>;
-
/* Buck SMPS */
- s1 {
+ pm8921_s1: s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
@@ -225,59 +226,63 @@ s1 {
bias-pull-down;
};
- s3 {
+ pm8921_s3: s3 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1400000>;
qcom,switch-mode-frequency = <4800000>;
};
- s4 {
+ pm8921_s4: s4 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
qcom,switch-mode-frequency = <3200000>;
};
- s7 {
+ pm8921_s7: s7 {
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
qcom,switch-mode-frequency = <3200000>;
};
- l3 {
+ pm8921_l3: l3 {
regulator-min-microvolt = <3050000>;
regulator-max-microvolt = <3300000>;
bias-pull-down;
};
- l4 {
+ pm8921_l4: l4 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l5 {
+ pm8921_l5: l5 {
regulator-min-microvolt = <2750000>;
regulator-max-microvolt = <3000000>;
bias-pull-down;
};
- l6 {
+ pm8921_l6: l6 {
regulator-min-microvolt = <2950000>;
regulator-max-microvolt = <2950000>;
bias-pull-down;
};
- l23 {
+ pm8921_l23: l23 {
regulator-min-microvolt = <1700000>;
regulator-max-microvolt = <1900000>;
bias-pull-down;
};
- lvs1 {
+ pm8921_lvs1: lvs1 {
+ bias-pull-down;
+ };
+
+ pm8921_lvs6: lvs6 {
bias-pull-down;
};
- lvs6 {
+ pm8921_hdmi_switch: hdmi-switch {
bias-pull-down;
};
};
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
index ba18a02b1c57..2412aa3e3e8d 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-sony-xperia-lagan-yuga.dts
@@ -93,11 +93,25 @@ gpio_keys_pin_a: gpio-keys-active-state {
&riva {
pinctrl-names = "default";
pinctrl-0 = <&riva_wlan_pin_a>, <&riva_bt_pin_a>, <&riva_fm_pin_a>;
+
+ vddcx-supply = <&pm8921_s3>;
+ vddmx-supply = <&pm8921_l24>;
+ vddpx-supply = <&pm8921_s4>;
+
status = "okay";
+
+ iris {
+ vddxo-supply = <&pm8921_l4>;
+ vddrfa-supply = <&pm8921_s2>;
+ vddpa-supply = <&pm8921_l10>;
+ vdddig-supply = <&pm8921_lvs2>;
+ };
};
&rpm {
regulators {
+ compatible = "qcom,rpm-pm8921-regulators";
+
vin_l1_l2_l12_l18-supply = <&pm8921_s4>;
vin_lvs_1_3_6-supply = <&pm8921_s4>;
vin_lvs_4_5_7-supply = <&pm8921_s4>;
@@ -109,7 +123,7 @@ regulators {
vin_l28-supply = <&pm8921_s7>;
/* Buck SMPS */
- s1 {
+ pm8921_s1: s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
@@ -117,21 +131,21 @@ s1 {
bias-pull-down;
};
- s2 {
+ pm8921_s2: s2 {
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
qcom,switch-mode-frequency = <1600000>;
bias-pull-down;
};
- s3 {
+ pm8921_s3: s3 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <1150000>;
qcom,switch-mode-frequency = <4800000>;
bias-pull-down;
};
- s4 {
+ pm8921_s4: s4 {
regulator-always-on;
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
@@ -140,205 +154,207 @@ s4 {
qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
};
- s7 {
+ pm8921_s7: s7 {
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
qcom,switch-mode-frequency = <3200000>;
};
- s8 {
+ pm8921_s8: s8 {
regulator-min-microvolt = <2200000>;
regulator-max-microvolt = <2200000>;
qcom,switch-mode-frequency = <1600000>;
};
/* PMOS LDO */
- l1 {
+ pm8921_l1: l1 {
regulator-always-on;
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
bias-pull-down;
};
- l2 {
+ pm8921_l2: l2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l3 {
+ pm8921_l3: l3 {
regulator-min-microvolt = <3075000>;
regulator-max-microvolt = <3075000>;
bias-pull-down;
};
- l4 {
+ pm8921_l4: l4 {
regulator-always-on;
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l5 {
+ pm8921_l5: l5 {
regulator-min-microvolt = <2950000>;
regulator-max-microvolt = <2950000>;
bias-pull-down;
};
- l6 {
+ pm8921_l6: l6 {
regulator-min-microvolt = <2950000>;
regulator-max-microvolt = <2950000>;
bias-pull-down;
};
- l7 {
+ pm8921_l7: l7 {
regulator-min-microvolt = <1850000>;
regulator-max-microvolt = <2950000>;
bias-pull-down;
};
- l8 {
+ pm8921_l8: l8 {
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
bias-pull-down;
};
- l9 {
+ pm8921_l9: l9 {
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
bias-pull-down;
};
- l10 {
+ pm8921_l10: l10 {
regulator-min-microvolt = <2900000>;
regulator-max-microvolt = <2900000>;
bias-pull-down;
};
- l11 {
+ pm8921_l11: l11 {
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
bias-pull-down;
};
- l12 {
+ pm8921_l12: l12 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l14 {
+ pm8921_l14: l14 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l15 {
+ pm8921_l15: l15 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2950000>;
bias-pull-down;
};
- l16 {
+ pm8921_l16: l16 {
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
bias-pull-down;
};
- l17 {
+ pm8921_l17: l17 {
regulator-min-microvolt = <2000000>;
regulator-max-microvolt = <2000000>;
bias-pull-down;
};
- l18 {
+ pm8921_l18: l18 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l21 {
+ pm8921_l21: l21 {
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
bias-pull-down;
};
- l22 {
+ pm8921_l22: l22 {
regulator-min-microvolt = <2600000>;
regulator-max-microvolt = <2600000>;
bias-pull-down;
};
- l23 {
+ pm8921_l23: l23 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l24 {
+ pm8921_l24: l24 {
regulator-min-microvolt = <750000>;
regulator-max-microvolt = <1150000>;
bias-pull-down;
};
- l25 {
+ pm8921_l25: l25 {
regulator-always-on;
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <1250000>;
bias-pull-down;
};
- l27 {
+ pm8921_l27: l27 {
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
};
- l28 {
+ pm8921_l28: l28 {
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
bias-pull-down;
};
- l29 {
+ pm8921_l29: l29 {
regulator-min-microvolt = <2000000>;
regulator-max-microvolt = <2000000>;
bias-pull-down;
};
/* Low Voltage Switch */
- lvs1 {
+ pm8921_lvs1: lvs1 {
bias-pull-down;
};
- lvs2 {
+ pm8921_lvs2: lvs2 {
bias-pull-down;
};
- lvs3 {
+ pm8921_lvs3: lvs3 {
bias-pull-down;
};
- lvs4 {
+ pm8921_lvs4: lvs4 {
bias-pull-down;
};
- lvs5 {
+ pm8921_lvs5: lvs5 {
bias-pull-down;
};
- lvs6 {
+ pm8921_lvs6: lvs6 {
bias-pull-down;
};
- lvs7 {
+ pm8921_lvs7: lvs7 {
bias-pull-down;
};
- usb-switch {};
+ pm8921_usb_switch: usb-switch {};
- hdmi-switch {};
+ pm8921_hdmi_switch: hdmi-switch {
+ bias-pull-down;
+ };
- ncp {
+ pm8921_ncp: ncp {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
qcom,switch-mode-frequency = <1600000>;
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index 5704d0598b96..5b7d2c6f0ce9 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -757,60 +757,6 @@ rpmcc: clock-controller {
clocks = <&pxo_board>, <&cxo_board>;
clock-names = "pxo", "cxo";
};
-
- regulators {
- compatible = "qcom,rpm-pm8921-regulators";
-
- pm8921_s1: s1 {};
- pm8921_s2: s2 {};
- pm8921_s3: s3 {};
- pm8921_s4: s4 {};
- pm8921_s7: s7 {};
- pm8921_s8: s8 {};
-
- pm8921_l1: l1 {};
- pm8921_l2: l2 {};
- pm8921_l3: l3 {};
- pm8921_l4: l4 {};
- pm8921_l5: l5 {};
- pm8921_l6: l6 {};
- pm8921_l7: l7 {};
- pm8921_l8: l8 {};
- pm8921_l9: l9 {};
- pm8921_l10: l10 {};
- pm8921_l11: l11 {};
- pm8921_l12: l12 {};
- pm8921_l14: l14 {};
- pm8921_l15: l15 {};
- pm8921_l16: l16 {};
- pm8921_l17: l17 {};
- pm8921_l18: l18 {};
- pm8921_l21: l21 {};
- pm8921_l22: l22 {};
- pm8921_l23: l23 {};
- pm8921_l24: l24 {};
- pm8921_l25: l25 {};
- pm8921_l26: l26 {};
- pm8921_l27: l27 {};
- pm8921_l28: l28 {};
- pm8921_l29: l29 {};
-
- pm8921_lvs1: lvs1 {};
- pm8921_lvs2: lvs2 {};
- pm8921_lvs3: lvs3 {};
- pm8921_lvs4: lvs4 {};
- pm8921_lvs5: lvs5 {};
- pm8921_lvs6: lvs6 {};
- pm8921_lvs7: lvs7 {};
-
- pm8921_usb_switch: usb-switch {};
-
- pm8921_hdmi_switch: hdmi-switch {
- bias-pull-down;
- };
-
- pm8921_ncp: ncp {};
- };
};
usb1: usb@12500000 {
@@ -1490,10 +1436,6 @@ riva: riva-pil@3200800 {
memory-region = <&wcnss_mem>;
- vddcx-supply = <&pm8921_s3>;
- vddmx-supply = <&pm8921_l24>;
- vddpx-supply = <&pm8921_s4>;
-
status = "disabled";
iris {
@@ -1501,11 +1443,6 @@ iris {
clocks = <&cxo_board>;
clock-names = "xo";
-
- vddxo-supply = <&pm8921_l4>;
- vddrfa-supply = <&pm8921_s2>;
- vddpa-supply = <&pm8921_l10>;
- vdddig-supply = <&pm8921_lvs2>;
};
smd-edge {
--
2.39.2
^ permalink raw reply related
* [PATCH v6 32/36] ARM: dts: qcom: msm8974: move regulators to board files
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
The vph-pwr and boost regulators (even if they are unified by design)
are not a property of SoC, so move them to board files.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../dts/qcom/qcom-apq8074-dragonboard.dts | 27 +++++++++++++++++++
.../qcom-msm8974-lge-nexus5-hammerhead.dts | 27 +++++++++++++++++++
.../qcom/qcom-msm8974-sony-xperia-rhine.dtsi | 27 +++++++++++++++++++
arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 27 -------------------
.../qcom/qcom-msm8974pro-fairphone-fp2.dts | 27 +++++++++++++++++++
.../qcom/qcom-msm8974pro-oneplus-bacon.dts | 27 +++++++++++++++++++
.../dts/qcom/qcom-msm8974pro-samsung-klte.dts | 10 ++++++-
...-msm8974pro-sony-xperia-shinano-castor.dts | 27 +++++++++++++++++++
8 files changed, 171 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts
index 950fa652f985..d7fb3e0e8886 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts
@@ -49,6 +49,33 @@ mpss_region: mpss@ac00000 {
no-map;
};
};
+
+ vreg_boost: vreg-boost {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg-boost";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&boost_bypass_n_pin>;
+ };
+
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
};
&blsp1_uart2 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
index da99f770d4f5..ca402b4a68bd 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -60,6 +60,33 @@ vibrator {
enable-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
};
+ vreg_boost: vreg-boost {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg-boost";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&boost_bypass_n_pin>;
+ };
+
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
+
vreg_wlan: wlan-regulator {
compatible = "regulator-fixed";
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
index 23ae474698aa..a43341ae4495 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
@@ -65,6 +65,33 @@ ramoops@3e8e0000 {
pmsg-size = <0x80000>;
};
};
+
+ vreg_boost: vreg-boost {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg-boost";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&boost_bypass_n_pin>;
+ };
+
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
};
&blsp1_i2c2 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 706fef53767e..d54be72fe3b2 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -2376,31 +2376,4 @@ timer {
<GIC_PPI 1 0xf08>;
clock-frequency = <19200000>;
};
-
- vreg_boost: vreg-boost {
- compatible = "regulator-fixed";
-
- regulator-name = "vreg-boost";
- regulator-min-microvolt = <3150000>;
- regulator-max-microvolt = <3150000>;
-
- regulator-always-on;
- regulator-boot-on;
-
- gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
- enable-active-high;
-
- pinctrl-names = "default";
- pinctrl-0 = <&boost_bypass_n_pin>;
- };
-
- vreg_vph_pwr: vreg-vph-pwr {
- compatible = "regulator-fixed";
- regulator-name = "vph-pwr";
-
- regulator-min-microvolt = <3600000>;
- regulator-max-microvolt = <3600000>;
-
- regulator-always-on;
- };
};
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
index 6c4153689b39..66c422004dcd 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
@@ -57,6 +57,33 @@ vibrator {
enable-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>;
vcc-supply = <&pm8941_l18>;
};
+
+ vreg_boost: vreg-boost {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg-boost";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&boost_bypass_n_pin>;
+ };
+
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
};
&blsp1_i2c2 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
index c0ca264d8140..6d1412aec45a 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
@@ -51,6 +51,33 @@ event-hall-sensor {
debounce-interval = <150>;
};
};
+
+ vreg_boost: vreg-boost {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg-boost";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&boost_bypass_n_pin>;
+ };
+
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
};
&blsp1_i2c1 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
index 325feb89b343..ca3aa16b4b10 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte.dts
@@ -155,7 +155,15 @@ vreg_panel: panel-regulator {
enable-active-high;
};
- /delete-node/ vreg-boost;
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
};
&blsp1_i2c2 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
index 0798cce3dbea..818ff5835031 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-castor.dts
@@ -84,6 +84,33 @@ vreg_vsp: lcd-dcdc-regulator {
pinctrl-0 = <&lcd_dcdc_en_pin_a>;
};
+ vreg_boost: vreg-boost {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vreg-boost";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+
+ gpio = <&pm8941_gpios 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&boost_bypass_n_pin>;
+ };
+
+ vreg_vph_pwr: vreg-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph-pwr";
+
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+
+ regulator-always-on;
+ };
+
vreg_wlan: wlan-regulator {
compatible = "regulator-fixed";
--
2.39.2
^ permalink raw reply related
* [PATCH v6 36/36] ARM: dts: qcom: mdm9615: drop qcom, prefix from SSBI node name
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
Device tree node names should not use vendor prefix, they contain a
generic name of the device. Drop the qcom, prefix from the SSBI node
name.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi b/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi
index 07e712e890f6..b02336bd8370 100644
--- a/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-mdm9615.dtsi
@@ -258,7 +258,7 @@ gsbi5_serial: serial@16440000 {
};
};
- ssbi: qcom,ssbi@500000 {
+ ssbi: ssbi@500000 {
compatible = "qcom,ssbi";
reg = <0x500000 0x1000>;
qcom,controller-type = "pmic-arbiter";
--
2.39.2
^ permalink raw reply related
* [PATCH v6 35/36] ARM: dts: qcom: ipq8064: drop qcom, prefix from SSBI node name
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
Device tree node names should not use vendor prefix, they contain a
generic name of the device. Drop the qcom, prefix from the SSBI node
name.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi
index 6198f42f6a9c..c3677440b786 100644
--- a/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi
@@ -366,7 +366,7 @@ rpmcc: clock-controller {
};
};
- qcom,ssbi@500000 {
+ ssbi@500000 {
compatible = "qcom,ssbi";
reg = <0x00500000 0x1000>;
qcom,controller-type = "pmic-arbiter";
--
2.39.2
^ permalink raw reply related
* [PATCH v6 34/36] ARM: dts: qcom: apq8060-dragonboard: rename mpp ADC channels to adc-channel
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
Use generic `adc-channel@N' node names for board-specific ADC channels
(routed to MPP pins) to follow the schema.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts
index 8b70d4a59c7b..bf2527941917 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts
@@ -998,23 +998,27 @@ &pm8058_xoadc {
xoadc-ref-supply = <&pm8058_l18>;
/* Board-specific channels */
- mpp5@5 {
+ adc-channel@5 {
/* Connected to AOUT of ALS sensor */
reg = <0x00 0x05>;
};
- mpp6@6 {
+
+ adc-channel@6 {
/* Connected to test point TP43 */
reg = <0x00 0x06>;
};
- mpp7@7 {
+
+ adc-channel@7 {
/* Connected to battery thermistor */
reg = <0x00 0x07>;
};
- mpp8@8 {
+
+ adc-channel@8 {
/* Connected to battery ID detector */
reg = <0x00 0x08>;
};
- mpp9@9 {
+
+ adc-channel@9 {
/* Connected to XO thermistor */
reg = <0x00 0x09>;
};
--
2.39.2
^ permalink raw reply related
* [PATCH v6 33/36] ARM: dts: qcom: pm8921: Disable keypad by default
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
Since keypad is used only by some devices, disable it by default and enable explicitly.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm/boot/dts/qcom/pm8921.dtsi | 1 +
arch/arm/boot/dts/qcom/qcom-msm8960-cdp.dts | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/pm8921.dtsi b/arch/arm/boot/dts/qcom/pm8921.dtsi
index 360a179670c5..058962af3005 100644
--- a/arch/arm/boot/dts/qcom/pm8921.dtsi
+++ b/arch/arm/boot/dts/qcom/pm8921.dtsi
@@ -43,6 +43,7 @@ pm8921_keypad: keypad@148 {
debounce = <15>;
scan-delay = <32>;
row-hold = <91500>;
+ status = "disabled";
};
pm8921_gpio: gpio@150 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960-cdp.dts b/arch/arm/boot/dts/qcom/qcom-msm8960-cdp.dts
index a5ea4843db43..36f4c997b0b3 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960-cdp.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960-cdp.dts
@@ -102,6 +102,8 @@ MATRIX_KEY(0, 3, KEY_CAMERA)
>;
keypad,num-rows = <1>;
keypad,num-columns = <5>;
+
+ status = "okay";
};
&rpm {
--
2.39.2
^ permalink raw reply related
* [PATCH v6 30/36] ARM: dts: qcom: msm8660: move RPM regulators to board files
From: Dmitry Baryshkov @ 2023-09-28 11:03 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-1-dmitry.baryshkov@linaro.org>
The set of regulators available over the RPM requests is not a property
of the SoC. Move them to board files.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
.../dts/qcom/qcom-apq8060-dragonboard.dts | 141 ++++++++++++------
arch/arm/boot/dts/qcom/qcom-msm8660-surf.dts | 10 ++
arch/arm/boot/dts/qcom/qcom-msm8660.dtsi | 66 --------
3 files changed, 102 insertions(+), 115 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts
index 10b8f529c337..8b70d4a59c7b 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8060-dragonboard.dts
@@ -453,6 +453,8 @@ &rpm {
* that means
*/
regulators-0 {
+ compatible = "qcom,rpm-pm8901-regulators";
+
vdd_l0-supply = <&pm8901_s4>;
vdd_l1-supply = <&vph>;
vdd_l2-supply = <&vph>;
@@ -470,57 +472,63 @@ regulators-0 {
lvs3_in-supply = <&pm8058_s2>;
mvs_in-supply = <&pm8058_s3>;
- l0 {
+ pm8901_l0: l0 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l1 {
+
+ pm8901_l1: l1 {
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
bias-pull-down;
};
- l2 {
+
+ pm8901_l2: l2 {
/* TMA340 requires strictly 3.3V */
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
bias-pull-down;
};
- l3 {
+
+ pm8901_l3: l3 {
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
bias-pull-down;
};
- l4 {
+
+ pm8901_l4: l4 {
regulator-min-microvolt = <2600000>;
regulator-max-microvolt = <2600000>;
bias-pull-down;
};
- l5 {
+
+ pm8901_l5: l5 {
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
bias-pull-down;
};
- l6 {
+
+ pm8901_l6: l6 {
regulator-min-microvolt = <2200000>;
regulator-max-microvolt = <2200000>;
bias-pull-down;
};
/* s0 and s1 are SAW regulators controlled over SPM */
- s2 {
+ pm8901_s2: s2 {
regulator-min-microvolt = <1300000>;
regulator-max-microvolt = <1300000>;
qcom,switch-mode-frequency = <1600000>;
bias-pull-down;
};
- s3 {
+ pm8901_s3: s3 {
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
qcom,switch-mode-frequency = <1600000>;
bias-pull-down;
};
- s4 {
+ pm8901_s4: s4 {
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
qcom,switch-mode-frequency = <1600000>;
@@ -528,17 +536,22 @@ s4 {
};
/* LVS0 thru 3 and mvs are just switches */
- lvs0 {
+ pm8901_lvs0: lvs0 {
regulator-always-on;
};
- lvs1 { };
- lvs2 { };
- lvs3 { };
- mvs { };
+ pm8901_lvs1: lvs1 { };
+
+ pm8901_lvs2: lvs2 { };
+
+ pm8901_lvs3: lvs3 { };
+
+ pm8901_mvs: mvs { };
};
regulators-1 {
+ compatible = "qcom,rpm-pm8058-regulators";
+
vdd_l0_l1_lvs-supply = <&pm8058_s3>;
vdd_l2_l11_l12-supply = <&vph>;
vdd_l3_l4_l5-supply = <&vph>;
@@ -560,144 +573,169 @@ regulators-1 {
vdd_s4-supply = <&vph>;
vdd_ncp-supply = <&vph>;
- l0 {
+ pm8058_l0: l0 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l1 {
+
+ pm8058_l1: l1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l2 {
+
+ pm8058_l2: l2 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2600000>;
bias-pull-down;
};
- l3 {
+
+ pm8058_l3: l3 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l4 {
+
+ pm8058_l4: l4 {
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
bias-pull-down;
};
- l5 {
+
+ pm8058_l5: l5 {
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
bias-pull-down;
};
- l6 {
+
+ pm8058_l6: l6 {
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3600000>;
bias-pull-down;
};
- l7 {
+
+ pm8058_l7: l7 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l8 {
+
+ pm8058_l8: l8 {
regulator-min-microvolt = <2900000>;
regulator-max-microvolt = <3050000>;
bias-pull-down;
};
- l9 {
+
+ pm8058_l9: l9 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l10 {
+
+ pm8058_l10: l10 {
regulator-min-microvolt = <2600000>;
regulator-max-microvolt = <2600000>;
bias-pull-down;
};
- l11 {
+
+ pm8058_l11: l11 {
regulator-min-microvolt = <1500000>;
regulator-max-microvolt = <1500000>;
bias-pull-down;
};
- l12 {
+
+ pm8058_l12: l12 {
regulator-min-microvolt = <2900000>;
regulator-max-microvolt = <2900000>;
bias-pull-down;
};
- l13 {
+
+ pm8058_l13: l13 {
regulator-min-microvolt = <2050000>;
regulator-max-microvolt = <2050000>;
bias-pull-down;
};
- l14 {
+
+ pm8058_l14: l14 {
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
};
- l15 {
+
+ pm8058_l15: l15 {
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
bias-pull-down;
};
- l16 {
+
+ pm8058_l16: l16 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
regulator-always-on;
};
- l17 {
+
+ pm8058_l17: l17 {
// 1.5V according to schematic
regulator-min-microvolt = <2600000>;
regulator-max-microvolt = <2600000>;
bias-pull-down;
};
- l18 {
+
+ pm8058_l18: l18 {
regulator-min-microvolt = <2200000>;
regulator-max-microvolt = <2200000>;
bias-pull-down;
};
- l19 {
+
+ pm8058_l19: l19 {
regulator-min-microvolt = <2500000>;
regulator-max-microvolt = <2500000>;
bias-pull-down;
};
- l20 {
+
+ pm8058_l20: l20 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
bias-pull-down;
};
- l21 {
+
+ pm8058_l21: l21 {
// 1.1 V according to schematic
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
regulator-always-on;
};
- l22 {
+
+ pm8058_l22: l22 {
// 1.2 V according to schematic
regulator-min-microvolt = <1150000>;
regulator-max-microvolt = <1150000>;
bias-pull-down;
};
- l23 {
+
+ pm8058_l23: l23 {
// Unused
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l24 {
+
+ pm8058_l24: l24 {
// Unused
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- l25 {
+
+ pm8058_l25: l25 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
bias-pull-down;
};
- s0 {
+ pm8058_s0: s0 {
// regulator-min-microvolt = <500000>;
// regulator-max-microvolt = <1325000>;
regulator-min-microvolt = <1100000>;
@@ -705,7 +743,8 @@ s0 {
qcom,switch-mode-frequency = <1600000>;
bias-pull-down;
};
- s1 {
+
+ pm8058_s1: s1 {
// regulator-min-microvolt = <500000>;
// regulator-max-microvolt = <1250000>;
regulator-min-microvolt = <1100000>;
@@ -713,21 +752,24 @@ s1 {
qcom,switch-mode-frequency = <1600000>;
bias-pull-down;
};
- s2 {
+
+ pm8058_s2: s2 {
// 1.3 V according to schematic
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1400000>;
qcom,switch-mode-frequency = <1600000>;
bias-pull-down;
};
- s3 {
+
+ pm8058_s3: s3 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
qcom,switch-mode-frequency = <1600000>;
regulator-always-on;
bias-pull-down;
};
- s4 {
+
+ pm8058_s4: s4 {
regulator-min-microvolt = <2200000>;
regulator-max-microvolt = <2200000>;
qcom,switch-mode-frequency = <1600000>;
@@ -736,14 +778,15 @@ s4 {
};
/* LVS0 and LVS1 are just switches */
- lvs0 {
+ pm8058_lvs0: lvs0 {
bias-pull-down;
};
- lvs1 {
+
+ pm8058_lvs1: lvs1 {
bias-pull-down;
};
- ncp {
+ pm8058_ncp: ncp {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
qcom,switch-mode-frequency = <1600000>;
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom/qcom-msm8660-surf.dts
index be2fbc1e0950..69fe651f564d 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8660-surf.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8660-surf.dts
@@ -65,6 +65,16 @@ MATRIX_KEY(5, 4, KEY_MENU)
keypad,num-columns = <5>;
};
+&rpm {
+ regulators-0 {
+ compatible = "qcom,rpm-pm8901-regulators";
+ };
+
+ regulators-1 {
+ compatible = "qcom,rpm-pm8058-regulators";
+ };
+};
+
/* eMMC */
&sdcc1 {
vmmc-supply = <&vsdcc_fixed>;
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8660.dtsi
index eef4712bbcc4..a7c245b9c8f9 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8660.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8660.dtsi
@@ -347,72 +347,6 @@ rpmcc: clock-controller {
clocks = <&pxo_board>;
clock-names = "pxo";
};
-
- regulators-0 {
- compatible = "qcom,rpm-pm8901-regulators";
-
- pm8901_l0: l0 {};
- pm8901_l1: l1 {};
- pm8901_l2: l2 {};
- pm8901_l3: l3 {};
- pm8901_l4: l4 {};
- pm8901_l5: l5 {};
- pm8901_l6: l6 {};
-
- /* S0 and S1 Handled as SAW regulators by SPM */
- pm8901_s2: s2 {};
- pm8901_s3: s3 {};
- pm8901_s4: s4 {};
-
- pm8901_lvs0: lvs0 {};
- pm8901_lvs1: lvs1 {};
- pm8901_lvs2: lvs2 {};
- pm8901_lvs3: lvs3 {};
-
- pm8901_mvs: mvs {};
- };
-
- regulators-1 {
- compatible = "qcom,rpm-pm8058-regulators";
-
- pm8058_l0: l0 {};
- pm8058_l1: l1 {};
- pm8058_l2: l2 {};
- pm8058_l3: l3 {};
- pm8058_l4: l4 {};
- pm8058_l5: l5 {};
- pm8058_l6: l6 {};
- pm8058_l7: l7 {};
- pm8058_l8: l8 {};
- pm8058_l9: l9 {};
- pm8058_l10: l10 {};
- pm8058_l11: l11 {};
- pm8058_l12: l12 {};
- pm8058_l13: l13 {};
- pm8058_l14: l14 {};
- pm8058_l15: l15 {};
- pm8058_l16: l16 {};
- pm8058_l17: l17 {};
- pm8058_l18: l18 {};
- pm8058_l19: l19 {};
- pm8058_l20: l20 {};
- pm8058_l21: l21 {};
- pm8058_l22: l22 {};
- pm8058_l23: l23 {};
- pm8058_l24: l24 {};
- pm8058_l25: l25 {};
-
- pm8058_s0: s0 {};
- pm8058_s1: s1 {};
- pm8058_s2: s2 {};
- pm8058_s3: s3 {};
- pm8058_s4: s4 {};
-
- pm8058_lvs0: lvs0 {};
- pm8058_lvs1: lvs1 {};
-
- pm8058_ncp: ncp {};
- };
};
amba {
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v6 35/36] ARM: dts: qcom: ipq8064: drop qcom, prefix from SSBI node name
From: Konrad Dybcio @ 2023-09-28 13:49 UTC (permalink / raw)
To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-36-dmitry.baryshkov@linaro.org>
On 28.09.2023 13:03, Dmitry Baryshkov wrote:
> Device tree node names should not use vendor prefix, they contain a
> generic name of the device. Drop the qcom, prefix from the SSBI node
> name.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH v6 36/36] ARM: dts: qcom: mdm9615: drop qcom, prefix from SSBI node name
From: Konrad Dybcio @ 2023-09-28 13:50 UTC (permalink / raw)
To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-input
In-Reply-To: <20230928110309.1212221-37-dmitry.baryshkov@linaro.org>
On 28.09.2023 13:03, Dmitry Baryshkov wrote:
> Device tree node names should not use vendor prefix, they contain a
> generic name of the device. Drop the qcom, prefix from the SSBI node
> name.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* Re: [PATCH V2 1/2] dt-bindings: input: Introduce Himax HID-over-SPI device
From: Conor Dooley @ 2023-09-28 16:56 UTC (permalink / raw)
To: yang tylor
Cc: Conor Dooley, dmitry.torokhov, robh+dt, krzysztof.kozlowski+dt,
conor+dt, jikos, benjamin.tissoires, linux-input, devicetree,
linux-kernel, poyuan_chang, hbarnor, jingyliang@chromium.org,
wuxy23, luolm1, hung poyu
In-Reply-To: <CAGD2q_ZzNPOL+Mhg7aWFTQd+UJJYVLz1ZE9hbNb0roS2M6y34g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6000 bytes --]
On Thu, Sep 28, 2023 at 10:12:41AM +0800, yang tylor wrote:
> On Tue, Sep 26, 2023 at 8:53 PM Conor Dooley <conor@kernel.org> wrote:
> > On Tue, Sep 26, 2023 at 05:52:39PM +0800, yang tylor wrote:
> > > On Tue, Sep 26, 2023 at 5:02 PM Conor Dooley <conor@kernel.org> wrote:
> > > > On Mon, Sep 25, 2023 at 06:16:29PM +0800, yang tylor wrote:
> > > > > On Mon, Sep 25, 2023 at 4:41 PM Conor Dooley <conor.dooley@microchip.com> wrote:
> > > > > > On Mon, Sep 25, 2023 at 09:44:21AM +0800, yang tylor wrote:
> > > > > > > On Fri, Sep 22, 2023 at 11:31 PM Conor Dooley <conor@kernel.org> wrote:
> > > > > > > >
> > > > > > > > On Fri, Sep 22, 2023 at 05:43:54PM +0800, yang tylor wrote:
> > > > > > > > > On Fri, Sep 22, 2023 at 5:22 PM Conor Dooley <conor@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, Sep 22, 2023 at 03:56:25PM +0800, yang tylor wrote:
> > > > > > > > > > > On Tue, Sep 19, 2023 at 7:09 PM Conor Dooley <conor@kernel.org> wrote:
> > > > > > > > > > > > On Tue, Sep 19, 2023 at 05:31:29PM +0800, yang tylor wrote:
> > > > > > > > > >
> > > > > > > > > > > > > The behavior of "himax,boot_time_fw_upgrade" seems not stable and
> > > > > > > > > > > > > should be removed. "himax,fw_in_flash", I use the kernel config for
> > > > > > > > > > > > > user to select.
> > > > > > > > > > > >
> > > > > > > > > > > > That seems like a bad idea, we want to be able to build one kernel that
> > > > > > > > > > > > works for all hardware at the same time.
> > > > > > > > > > > >
> > > > > > > > > > > I see, so I should take that back?
> > > > > > > > > > > I'll explain more about it.
> > > > > > > > > >
> > > > > > > > > > Are there particular ICs where the firmware would always be in flash and
> > > > > > > > > > others where it would never be? Or is this a choice made by the board or
> > > > > > > > > > system designer?
> > > > > > > > > >
> > > > > > > > > Most cases it's about the system designer's decision. But some ICs may be forced
> > > > > > > > > to use flash because of its architecture(multiple IC inside, need to
> > > > > > > > > load firmware to
> > > > > > > > > multiple IC's sram by master IC). But if there is no limitation on
> > > > > > > > > this part, most system
> > > > > > > > > designers will prefer flashless.
> > > > > > > >
> > > > > > > > Forgive me if I am not understanding correctly, there are some ICs that
> > > > > > > > will need to load the firmware from flash and there are some where it
> > > > > > > > will be a decision made by the designer of the board. Is the flash part
> > > > > > > > of the IC or is it an external flash chip?
> > > > > > > >
> > > > > > >
> > > > > > > Both are possible, it depends on the IC type. For TDDI, the IC is long
> > > > > > > and thin, placed on panel PCB, flash will be located at the external
> > > > > > > flash chip. For the OLED TP, IC is usually placed at FPC and its flash
> > > > > > > is embedded, thus the IC size is large compared to TDDI. But from the
> > > > > > > driver's perspective either external flash or embedded flash, the IC
> > > > > > > itself will load firmware from flash automatically when reset pin is
> > > > > > > released. Only if firmware is loading from the host storage system,
> > > > > > > the driver needs to operate the IC in detail.
> > > > > >
> > > > > >
> > > > > > Since there are ICs that can use the external flash or have it loaded
> > > > > > from the host, it sounds like you do need a property to differentiate
> > > > > > between those cases.
> > > > > Yep.
> > > > >
> > > > > > Is it sufficient to just set the firmware-name property for these cases?
> > > > > > If the property exists, then you know you need to load firmware & what
> > > > > > its name is. If it doesn't, then the firmware either isn't needed or
> > > > > > will be automatically loaded from the external flash.
> > > >
> > > > > We have a default prefix firmware name(like himax_xxxx.bin) in the driver code.
> > > >
> > > > How do you intend generating the name of the firmware file? I assume the
> > > > same firmware doesn't work on every IC, so you'll need to pick a
> > > > different one depending on the compatible?
> > > >
> > > If considering a firmware library line-up for all the incoming panels
> > > of this driver.
> > > We would use PID as part of the file name. Because all the support panels would
> > > have a unique PID associated. Which will make the firmware name like
> > > himax_xxx_{$PID}.bin. The problem is, we need to know PID before firmware load
> > > at no flash condition. Thus PID information is required in dts when
> > > no-flash-flag
> > > is specified.
> >
> > Firstly, where does the "xxx" come from?
> > And you're making it sound more like having firmware-name is suitable
> > for this use case, given you need to determine the name of the file to
> > use based on something that is hardware specific but is not
> > dynamically detectable.
> Current driver patch uses a prefix name "himax_i2chid" which comes
> from the previous project
> and seems not suitable for this condition, so I use "xxx" and plan to
> replace it in the next version.
> For finding firmware, I think both solutions are reasonable.
> - provide firmware name directly: implies no-flash and use user
> specified firmware, no PID info.
> - provide no-flash-flag and PID info: loading firmware from organized
> names with PID info.
> I prefer the 2nd solution, but it needs more properties in dts. 1st
> has less properties and more
> intuitive.
>
> I don't know which one is more acceptable by the community, as you
> know I'm a newbie here.
To be honest, I am not all that sure either! Does the panel id have
value in its own right, or is that only used to determine the firmware
filename?
Also, if it does have value in its own right, rather than a "pid",
should the panel be a child node of this hid device with its own
compatible?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] input: Imagis: add support for the IST3032C touchscreen
From: Karel Balej @ 2023-09-28 17:56 UTC (permalink / raw)
To: Jeff LaBundy, Karel Balej
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Markuss Broks, linux-input, devicetree, linux-kernel,
Duje Mihanović, ~postmarketos/upstreaming
In-Reply-To: <ZROIKSVCiTI3VB2B@nixie71>
Hello, Jeff,
thank you very much for your feedback.
> > + if (chip_id == IST3032C_WHOAMI) {
> > + /*
> > + * if the regulator voltage is not set like this, the touchscreen
> > + * generates random touches without user interaction
> > + */
> > + error = regulator_set_voltage(ts->supplies[0].consumer, 3100000, 3100000);
> > + if (error)
> > + dev_warn(dev, "failed to set regulator voltage\n");
> > + }
> > +
>
> Opinions may vary, but mine is that this kind of hard-coded board-level policy
> does not belong in the driver. Surely the supply need not be equal to exactly
> 3.1 V and this is merely an upper or lower limit? Assuming so, what if the board
> designer opts to share this supply with another consumer that requires a specific
> voltage not equal to 3.1 V, but still within the safe range of IST3032C?
>
> To me, this restriction belongs in dts, specifically within the regulator child
> node referenced by the client which bears the new 'ist3032c' compatible string.
> Maybe a better solution is to simply note this presumed silicon erratum in the
> description of the vdd supply in the binding which, as Conor states, must not be
> clubbed with driver patches.
I agree that the voltage should not be hardcoded. I do not know what the
safe range for the touchscreen is though, because the downstream driver
does exactly this. I will try to test it with several values within the
range allowed by the regulator and see if I can determine some limits on
when the "ghost" touches do not appear.
However I am not sure whether this setting should be moved to the
regulator DT - it is my understanding that the DT for the regulator
should list the min/max range *supported* by the regulator, not conform
to requirements of its consumers, which should instead ask for the
regulator to be set to a range they require themselves, via their driver
- is it not so?
The regulator driver is not mainlined yet (although I managed to get the
downstream code working with mainline), however the downstream DT
contains much wider range of supported voltage (compared to those 3.1 V
used by the touchscreen) - an information which would get lost if I set
the DT for the regulator by the requirements of the touchscreen, which I
believe would have similiar implications as what you said regarding
using this regulator with other consumers.
What would seem a reasonable solution to me would be to move the voltage
range values to the touchscreen DT (which incidentally is what the
downstream driver does also, except it uses one value for both min and
max), so that they would be set by the driver but not hardcoded in the
code - what do you think about this?
Best regards,
K. B.
^ permalink raw reply
* Re: [PATCH 1/2] input: generalize the Imagis touchscreen driver
From: Karel Balej @ 2023-09-28 18:07 UTC (permalink / raw)
To: Markuss Broks, Karel Balej
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel, Duje Mihanović,
~postmarketos/upstreaming, Jeff LaBundy, linmengbo0689
In-Reply-To: <72e02837-9a82-4007-8ba2-fa05f3c17670@gmail.com>
Hello, Markuss,
thank you for your response and please forgive that my original emails
didn't reach you - I am trying to see if I can get the SMTP server I use
for my primary address officially authorized to send emails in its name
so that Google does not reject them.
> To be fair, this driver should work with all Imagis3 chips, which could
> be a better name for it. However, I agree with Jeff here: the driver
> doesn't necessarily need renaming.
I will be sure to drop the renaming for v2.
> Additionally, there used to be my series [1] that generalized the
> driver, but it never got applied. I will re-send it. It introduces
> `struct imagis_properties`, which contains register addresses for the
> registers that we use to read the touch input. In your specific case, I
> believe it should be:
>
> static const struct imagis_properties imagis_3032c_data =
> {
> .interrupt_msg_cmd = IST3038C_REG_INTR_MESSAGE,
> .touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
> .whoami_cmd = IST3038C_REG_CHIPID,
> .whoami_val = IST3032C_WHOAMI, /* change it to your whoami */
> };
I have come across your patch series and in fact my original experiments
were based on it. However I thought it was abandoned and decided not to
try to make any further generalizations to the driver for now, except
making it work with IST3032C. Should I then perhaps wait before your
series gets applied before sending v2 of my changes? Or should I send
you a patch on top of your series, where I would add the `struct
imagis_properties` for the IST3032C (which you surely could do yourself,
but I can at least test it with my device). Please let me know if and
how we should coordinate.
> As for the voltage set, I believe this does not belong in a kernel
> driver. You should set it in device-tree with `regulator-max-microvolt`
> and `regulator-min-microvolt`.
Please see my response to Jeff regarding this. I will be happy to hear
your thoughts on what I propose.
Kind regards,
K. B.
^ permalink raw reply
* Re: [RFC PATCH] of: device: Support 2nd sources of probeable but undiscoverable devices
From: Rob Herring @ 2023-09-28 20:11 UTC (permalink / raw)
To: Doug Anderson
Cc: Krzysztof Kozlowski, Conor Dooley, devicetree, Benjamin Tissoires,
Chen-Yu Tsai, linux-input, Jiri Kosina, Hsin-Yi Wang, linux-gpio,
linus.walleij, Dmitry Torokhov, Johan Hovold, andriy.shevchenko,
broonie, frowand.list, gregkh, hdegoede, james.clark, james,
keescook, linux-kernel, rafael, tglx
In-Reply-To: <CAD=FV=UgFzT0TW2WEV0Wmk05EXUad2EYhN2DcckAxE_Lw5gV1Q@mail.gmail.com>
On Fri, Sep 22, 2023 at 7:11 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Fri, Sep 22, 2023 at 12:08 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > > > This seems like overkill to me. Do we really need groups and a mutex
> > > > for each group? Worst case is what? 2-3 groups of 2-3 devices?
> > > > Instead, what about extending "status" with another value
> > > > ("fail-needs-probe"? (fail-xxx is a documented value)). Currently, the
> > > > kernel would just ignore nodes with that status. Then we can process
> > > > those nodes separately 1-by-1.
> > >
> > > My worry here is that this has the potential to impact boot speed in a
> > > non-trivial way. While trackpads and touchscreens _are_ probable,
> > > their probe routines are often quite slow. This is even mentioned in
> > > Dmitry's initial patches adding async probe to the kernel. See commit
> > > 765230b5f084 ("driver-core: add asynchronous probing support for
> > > drivers") where he specifically brings up input devices as examples.
> >
> > Perhaps then this should be solved in userspace where it can learn
> > which device is actually present and save that information for
> > subsequent boots.
>
> Yeah, the thought occurred to me as well. I think there are a few
> problems, though:
>
> a) Userspace can't itself probe these devices effectively. While
> userspace could turn on GPIOs manually and query the i2c bus manually,
> it can't (I believe) turn on regulators nor can it turn on clocks, if
> they are needed. About the best userspace could do would be to blindly
> try binding an existing kernel driver, and in that case why did we
> need userspace involved anyway?
>
> b) While deferring to userspace can work for solutions like ChromeOS
> or Android where it's easy to ensure the userspace bits are there,
> it's less appealing as a general solution. I think in Johan's case
> he's taking a laptop that initially ran Windows and then is trying to
> run a generic Linux distro on it. For anyone in a similar situation,
> they'd either need to pick a Linux distro that has the magic userspace
> bits that are needed or they need to know that, on their laptop, they
> need to manually install some software. While requiring special
> userspace might make sense if you've got a special peripheral, like an
> LTE modem, it makes less sense to need special userspace just to get
> the right devices bound...
I did not mean do it all in userspace, but for userspace to save off
what devices are actually present. For example, if userspace has
access to the dtb, it could just update the dtb to enable the right
nodes. Then after the first boot, boot time is faster. Or a driver
could try to load an overlay with the config enabling the right
devices. Though maybe waiting til userspace is available wouldn't
speed things up.
> > > It wouldn't be absurd to have a system that has multiple sources for
> > > both the trackpad and the touchscreen. If we have to probe each of
> > > these one at a time then it could be slow. It would be quicker to be
> > > able to probe the trackpads (one at a time) at the same time we're
> > > probing the touchscreens (one at a time). Using the "fail-needs-probe"
> > > doesn't provide information needed to know which devices conflict with
> > > each other.
> >
> > I would guess most of the time that's pretty evident. They are going
> > to be on the same bus/link. If unrelated devices are on the same bus,
> > then that's going to get serialized anyways (if bus accesses are what
> > make things slow).
> >
> > We could add information on the class of device. touchscreen and
> > touchpad aliases or something.
>
> Ah, I see. So something like "fail-needs-probe-<class>". The
> touchscreens could have "fail-needs-probe-touchscreen" and the
> trackpads could have "fail-needs-probe-trackpad" ? That could work. In
> theory that could fall back to the same solution of grabbing a mutex
> based on the group ID...
I would not combine the 2 things. Knowing the class/type of the device
may be useful independent of your problem.
> Also: if having the mutex in the "struct device" is seen as a bad
> idea, it would also be easy to remove. __driver_probe_device() could
> just make a call like "of_device_probe_start()" at the beginning that
> locks the mutex and then "of_device_probe_end()" that unlocks it. Both
> of those calls could easily lookup the mutex in a list, which would
> get rid of the need to store it in the "struct device".
That could be useful for other things too. Like moving some of the hw
init we do outside of probe (though that's mostly abstracted to be not
DT specific, so maybe not).
> > > That would lead me to suggest this:
> > >
> > > &i2c_bus {
> > > trackpad-prober {
> > > compatible = "mt8173-elm-hana-trackpad-prober";
> > >
> > > tp1: trackpad@10 {
> > > compatible = "hid-over-i2c";
> > > reg = <0x10>;
> > > ...
> > > post-power-on-delay-ms = <200>;
> > > };
> > > tp2: trackpad@20 {
> > > compatible = "hid-over-i2c";
> > > reg = <0x20>;
> > > ...
> > > post-power-on-delay-ms = <200>;
> > > };
> > > };
> > > };
> > >
> > > ...but I suspect that would be insta-NAKed because it's creating a
> > > completely virtual device ("mt8173-elm-hana-trackpad-prober") in the
> > > device tree. I don't know if there's something that's functionally
> > > similar that would be OK?
> >
> > Why do you need the intermediate node other than a convenient way to
> > instantiate a driver? You just need a flag in each node which needs
> > this special handling. Again, "status" could work well here since it
> > keeps the normal probe from happening. But I'm not saying you can't
> > have some board specific code. Sometimes you just need code to deal
> > with this stuff. Don't try to parameterize everything to DT
> > properties.
>
> I think I'd have an easier time understanding if I knew where you
> envisioned the board-specific code living. Do you have an example of
> board specific code running at boot time in the kernel on DT systems?
drivers/soc/ or drivers/platform/ are the dumping grounds. Don't we
already have CrOS stuff there?
> > Note that the above only works with "generic" compatibles with
> > "generic" power sequencing properties (I won't repeat my dislike
> > again).
>
> I don't think so? I was imagining that we'd have some board specific
> code that ran that knew all the possible combinations of devices,
> could probe them, and then could instantiate the correct driver.
Okay, just making sure you weren't trying to parameterize everything
when generally, how to power sequence is implicit.
>
> Imagine that instead of the hated "hid-over-i2c" compatible we were
> using two other devices. Imagine that a given board could have a
> "elan,ekth6915" and a "goodix,gt7375p". Both of these devices have
> specific timing requirements on how to sequence their supplies and
> reset GPIOs. For Elan we power on the supplies, wait at least 1 ms,
> deassert reset, wait at least 300 ms, and then can talk i2c. For
> Goodix we power on the supply, wait at least 10 ms, deassert reset,
> wait at least 180 ms, and then can talk i2c. If we had a
> board-specific probing driver then it would power on the supplies,
> wait at least 10 ms (the max of the two), deassert reset, wait at
> least 300 ms (the max of the two), and then see which device talked.
> Then it would instantiate whichever of the two drivers. This could be
> done for any two devices that EEs have determined have "compatible"
> probing sequences.
My point was that in the above example, all these delay times would
have to be defined in the kernel, not DT.
> Ideally in the above situation we'd be able to avoid turning the
> device off and on again between the board-specific probe code and the
> normal driver. That optimization might need special code per-driver
> but it feels doable by passing some sort of hint to the child driver
> when it's instantiated.
I think fixing regulators getting turned off on failed probes and
having a "regulator on time" would go a long way towards providing
that hint even if the on time was just since clocksource started.
> > If only the driver knows how to handle the device, then you
> > still just have to have the driver probe. If you *only* wanted to
> > solve the above case, I'd just make "hid-over-i2c" take a 2nd (and
> > 3rd) I2C address in reg and have those as fallbacks.
>
> Yeah, it did occur to me that having "hid-over-i2c" take more than one
> register (and I guess more than one "hid-descr-addr") would work in my
> earlier example and this might actually be a good solution for Johan.
> I'm hoping for a better generic solution, though.
>
>
> > You could always make the driver probe smarter where if your supply
> > was already powered on, then don't delay. Then something else could
> > ensure that the supply is enabled. I'm not sure if regulators have the
> > same issue as clocks where the clock might be on from the bootloader,
> > then a failed probe which gets then puts the clock turns it off.
>
> I'm not sure it's that simple. Even if the supply didn't turn off by
> itself in some cases, we wouldn't know how long the supply was on.
We know the time since the clocksource was initialized. I'd imagine
for most cases, more than enough time would elapse by the time you get
to these drivers.
Rob
^ permalink raw reply
* Re: [PATCH 1/2] input: generalize the Imagis touchscreen driver
From: Markuss Broks @ 2023-09-28 20:22 UTC (permalink / raw)
To: Karel Balej, Karel Balej
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel, Duje Mihanović,
~postmarketos/upstreaming, Jeff LaBundy, linmengbo0689
In-Reply-To: <CVUR18U9FUME.XSF1MML0B1QN@gimli.ms.mff.cuni.cz>
Hi Karel,
On 9/28/23 21:07, Karel Balej wrote:
> Hello, Markuss,
>
> thank you for your response and please forgive that my original emails
> didn't reach you - I am trying to see if I can get the SMTP server I use
> for my primary address officially authorized to send emails in its name
> so that Google does not reject them.
Yeah, I have not received your first series, only knew of it when the
replies came. It's fine though :)
>
>> To be fair, this driver should work with all Imagis3 chips, which could
>> be a better name for it. However, I agree with Jeff here: the driver
>> doesn't necessarily need renaming.
> I will be sure to drop the renaming for v2.
>
>> Additionally, there used to be my series [1] that generalized the
>> driver, but it never got applied. I will re-send it. It introduces
>> `struct imagis_properties`, which contains register addresses for the
>> registers that we use to read the touch input. In your specific case, I
>> believe it should be:
>>
>> static const struct imagis_properties imagis_3032c_data =
>> {
>> .interrupt_msg_cmd = IST3038C_REG_INTR_MESSAGE,
>> .touch_coord_cmd = IST3038C_REG_TOUCH_COORD,
>> .whoami_cmd = IST3038C_REG_CHIPID,
>> .whoami_val = IST3032C_WHOAMI, /* change it to your whoami */
>> };
> I have come across your patch series and in fact my original experiments
> were based on it. However I thought it was abandoned and decided not to
> try to make any further generalizations to the driver for now, except
> making it work with IST3032C. Should I then perhaps wait before your
> series gets applied before sending v2 of my changes? Or should I send
> you a patch on top of your series, where I would add the `struct
> imagis_properties` for the IST3032C (which you surely could do yourself,
> but I can at least test it with my device). Please let me know if and
> how we should coordinate.
If you don't mind the extra hassle, I'm all in for my generalization
thing going together with your series.
Alternatively, I can resend it myself, but I believe it would be better
if they go in bulk since they need to be applied together.
>
>> As for the voltage set, I believe this does not belong in a kernel
>> driver. You should set it in device-tree with `regulator-max-microvolt`
>> and `regulator-min-microvolt`.
> Please see my response to Jeff regarding this. I will be happy to hear
> your thoughts on what I propose.
Actually, the regulator values belong to the device-tree, because the
device-tree for the board is what describes the board's regulators, and
since you know what components are installed on that specific board you
can know which regulator values are supposed to be set for it. This
manual voltage setting can cause conflicts with other drivers for
example. Also some device can use a variable wide voltage range, and
some only specific narrow one, and e.g. the driver with wide range would
set it to voltage that isn't suitable for the narrow range device, so
it's much better to just specify it manually than have it resolved.
The actual min/max values for regulators or its voltage table is
provided by the regulator driver itself, so there's not much point in
specifying those again in the device-tree.
>
> Kind regards,
> K. B.
- Markuss
^ permalink raw reply
* Re: [RFC PATCH] of: device: Support 2nd sources of probeable but undiscoverable devices
From: Rob Herring @ 2023-09-28 20:37 UTC (permalink / raw)
To: Doug Anderson
Cc: Jeff LaBundy, Krzysztof Kozlowski, Conor Dooley, devicetree,
Benjamin Tissoires, Chen-Yu Tsai, linux-input, Jiri Kosina,
Hsin-Yi Wang, linux-gpio, linus.walleij, Dmitry Torokhov,
Johan Hovold, andriy.shevchenko, broonie, frowand.list, gregkh,
hdegoede, james.clark, james, keescook, linux-kernel, rafael,
tglx
In-Reply-To: <CAD=FV=UR47x+t37B2+Myv0qvvOJMFxVe-Fj7js=-Ez2GWuDySg@mail.gmail.com>
On Wed, Sep 27, 2023 at 6:50 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Tue, Sep 26, 2023 at 7:37 PM Jeff LaBundy <jeff@labundy.com> wrote:
> >
> > Hi Doug,
> >
> > On Fri, Sep 22, 2023 at 05:11:10PM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Fri, Sep 22, 2023 at 12:08 PM Rob Herring <robh+dt@kernel.org> wrote:
> > > >
> > > > > > This seems like overkill to me. Do we really need groups and a mutex
> > > > > > for each group? Worst case is what? 2-3 groups of 2-3 devices?
> > > > > > Instead, what about extending "status" with another value
> > > > > > ("fail-needs-probe"? (fail-xxx is a documented value)). Currently, the
> > > > > > kernel would just ignore nodes with that status. Then we can process
> > > > > > those nodes separately 1-by-1.
> > > > >
> > > > > My worry here is that this has the potential to impact boot speed in a
> > > > > non-trivial way. While trackpads and touchscreens _are_ probable,
> > > > > their probe routines are often quite slow. This is even mentioned in
> > > > > Dmitry's initial patches adding async probe to the kernel. See commit
> > > > > 765230b5f084 ("driver-core: add asynchronous probing support for
> > > > > drivers") where he specifically brings up input devices as examples.
> >
> > Ideally, all but one driver in a group should bail out of probe quickly if
> > the device is not populated. If not, I would consider that to be a bug or at
> > least room for improvement in that driver.
> >
> > The reason input devices can take a while to probe is because they may be
> > loading FW over I2C or performing some sort of calibration procedure; only
> > one driver in the group should get that far.
>
> Hmm, that's not my experience. Specifically I've seen i2c-hid devices
> whose datasheets say that you're not allowed to talk i2c to them at
> all for hundreds of milliseconds after you power them on. See, for
> instance, "i2c-hid-of-goodix.c" which has a "post_gpio_reset_delay_ms"
> of 180 ms and "i2c-hid-of-elan.c" which has one of 300 ms.
>
> As I understand it these touchscreens have firmware on them and that
> firmware can take a while to boot. Until the firmware boots they won't
> respond over i2c. This is simply not something that Linux can do
> anything about.
>
> About the best you could do would be to add a board-specific driver
> that understood that it could power up the rails, wait the maximum
> amount of time that all possible touchscreens might need, and then
> look for i2c ACKs. I'm still hoping to hear from Rob about how I would
> get a board-specific driver to load on a DT system so I can
> investigate / prototype this.
foo_initcall()
{
if (of_machine_is_compatible(...))
platform_device_create();
}
That chunk would have to be built in and if that's part of the driver
module, autoloading wouldn't work.
We could have a match table of board compatibles and driver names. I'm
not worried about that list being big, so I'm happy to stick that in
drivers/of/.
> > > > We could add information on the class of device. touchscreen and
> > > > touchpad aliases or something.
> > >
> > > Ah, I see. So something like "fail-needs-probe-<class>". The
> > > touchscreens could have "fail-needs-probe-touchscreen" and the
> > > trackpads could have "fail-needs-probe-trackpad" ? That could work. In
> > > theory that could fall back to the same solution of grabbing a mutex
> > > based on the group ID...
> > >
> > > Also: if having the mutex in the "struct device" is seen as a bad
> > > idea, it would also be easy to remove. __driver_probe_device() could
> > > just make a call like "of_device_probe_start()" at the beginning that
> > > locks the mutex and then "of_device_probe_end()" that unlocks it. Both
> > > of those calls could easily lookup the mutex in a list, which would
> > > get rid of the need to store it in the "struct device".
> > >
> > >
> > > > > That would lead me to suggest this:
> > > > >
> > > > > &i2c_bus {
> > > > > trackpad-prober {
> > > > > compatible = "mt8173-elm-hana-trackpad-prober";
> > > > >
> > > > > tp1: trackpad@10 {
> > > > > compatible = "hid-over-i2c";
> > > > > reg = <0x10>;
> > > > > ...
> > > > > post-power-on-delay-ms = <200>;
> > > > > };
> > > > > tp2: trackpad@20 {
> > > > > compatible = "hid-over-i2c";
> > > > > reg = <0x20>;
> > > > > ...
> > > > > post-power-on-delay-ms = <200>;
> > > > > };
> > > > > };
> > > > > };
> > > > >
> > > > > ...but I suspect that would be insta-NAKed because it's creating a
> > > > > completely virtual device ("mt8173-elm-hana-trackpad-prober") in the
> > > > > device tree. I don't know if there's something that's functionally
> > > > > similar that would be OK?
> >
> > This solution seems a bit confusing to me, and would require more edits
> > to the dts each time a second source is added. It also means one would
> > have to write a small platform driver for each group of devices, correct?
>
> No matter what we need to add something to the dts each time a second
> source is added, right?
That was my thought. There is the case of the devices are almost the
same, so we lie. That's what you are doing for displays IIRC.
> While it's true that we'd end up with some extra drivers, if we do it
> correctly we don't necessarily need a driver for each group of devices
> nor even a driver per board. If several boards have very similar
> probing requirements then, even if they have unique "compatible"
> strings they could still end up using the same Linux driver.
>
> I've actually been talking offline with folks on ChromeOS more about
> this problem as well. Chen-Yu actually pointed at a patch series (that
> never landed, I guess) that has some similar ideas [1]. I guess in
> that case Hans was actually constructing device tree properties
> manually in the driver. I was thinking more of having all of the
> options listed in the device tree and then doing something that only
> causes some of them to probe.
>
> If Rob was OK with it, I guess I could have some sort of top-level
> "hwmanager" node like Hans did and then have phandle links to all the
> hardware that are managed by it. Then I could just change those to
> "okay"?
That's really just making the mutex node link the other direction. The
devices link to the common mutex node vs. the hwmanager node(s) links
to all the devices. That's really just picking the paint colors.
> Ideally, though, this could somehow use device tree "overlays" I
> guess. That seems like almost a perfect fit. I guess the issue here,
> though, is that I'd want the overlays bundled together with the
> original DT and then the board-specific "hardware prober" driver to
> actually apply the overlays after probing. Does that seem sensible?
BTW, there was an idea long ago from maintainer emeritus Likely to
append overlays to the base DTB for the kernel to apply.
How would that help you here? Are you going to have an overlay for
each device that enables it? It's much easier to just call
of_update_property() to change "status".
Rob
^ permalink raw reply
* Re: [RFC PATCH 2/2] hid: lenovo: move type checks to lenovo_features_set_cptkbd()
From: Jamie Lentin @ 2023-09-28 21:06 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: jikos, benjamin.tissoires, linux-kernel, linux-input
In-Reply-To: <137ee9ed434fe98fd773cd27895afc564f92a23c.camel@posteo.de>
On 2023-09-27 12:20, Martin Kepplinger wrote:
> Am Mittwoch, dem 27.09.2023 um 09:19 +0100 schrieb Jamie Lentin:
>> On 2023-09-25 11:23, Martin Kepplinger wrote:
>> > These custom commands will be sent to both the USB keyboard & mouse
>> > devices but only the mouse will respond. Avoid sending known-
>> > useless
>> > messages by always prepending the filter before sending them.
>> >
>> > Suggested-by: Jamie Lentin <jm@lentin.co.uk>
>> > Signed-off-by: Martin Kepplinger <martink@posteo.de>
>> > ---
>> > drivers/hid/hid-lenovo.c | 27 +++++++++------------------
>> > 1 file changed, 9 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c
>> > index 29aa6d372bad..922f3e5462f4 100644
>> > --- a/drivers/hid/hid-lenovo.c
>> > +++ b/drivers/hid/hid-lenovo.c
>> > @@ -521,6 +521,14 @@ static void lenovo_features_set_cptkbd(struct
>> > hid_device *hdev)
>> > int ret;
>> > struct lenovo_drvdata *cptkbd_data = hid_get_drvdata(hdev);
>> >
>> > + /* All the custom action happens on the USBMOUSE device for
>> > USB */
>> > + if (((hdev->product == USB_DEVICE_ID_LENOVO_CUSBKBD) ||
>> > + (hdev->product == USB_DEVICE_ID_LENOVO_TPIIUSBKBD)) &&
>> > + hdev->type != HID_TYPE_USBMOUSE) {
>> > + hid_dbg(hdev, "Ignoring keyboard half of
>> > device\n");
>> > + return;
>> > + }
>> > +
>> > /*
>> > * Tell the keyboard a driver understands it, and turn F7,
>> > F9, F11
>> > into
>> > * regular keys
>> > @@ -1122,14 +1130,6 @@ static int lenovo_probe_cptkbd(struct
>> > hid_device
>> > *hdev)
>> > int ret;
>> > struct lenovo_drvdata *cptkbd_data;
>> >
>> > - /* All the custom action happens on the USBMOUSE device for
>> > USB */
>> > - if (((hdev->product == USB_DEVICE_ID_LENOVO_CUSBKBD) ||
>> > - (hdev->product == USB_DEVICE_ID_LENOVO_TPIIUSBKBD)) &&
>> > - hdev->type != HID_TYPE_USBMOUSE) {
>> > - hid_dbg(hdev, "Ignoring keyboard half of
>> > device\n");
>> > - return 0;
>> > - }
>> > -
>>
>> I like the idea of doing it once then forgetting about it, but
>> removing
>> this will mean that the "keyboard half" will have it's own set of
>> non-functional sysfs parameters I think? Currently:-
>>
>> # evtest
>> . . .
>> /dev/input/event10: ThinkPad Compact Bluetooth Keyboard with
>> TrackPoint
>> /dev/input/event11: Lenovo ThinkPad Compact USB Keyboard with
>> TrackPoint
>> /dev/input/event12: Lenovo ThinkPad Compact USB Keyboard with
>> TrackPoint
>>
>> # ls -1 /sys/class/input/event*/device/device/fn_lock
>> /sys/class/input/event10/device/device/fn_lock
>> /sys/class/input/event12/device/device/fn_lock
>>
>> (note 11 is missing.)
>>
>> I think the easiest (but ugly) thing to do is to copy-paste this lump
>> of
>> code to the top of lenovo_reset_resume.
>> Cheers,
>>
>> > cptkbd_data = devm_kzalloc(&hdev->dev,
>> > sizeof(*cptkbd_data),
>> > GFP_KERNEL);
>> > @@ -1264,16 +1264,7 @@ static int lenovo_probe(struct hid_device
>> > *hdev,
>> > #ifdef CONFIG_PM
>> > static int lenovo_reset_resume(struct hid_device *hdev)
>> > {
>> > - switch (hdev->product) {
>> > - case USB_DEVICE_ID_LENOVO_CUSBKBD:
>> > - if (hdev->type == HID_TYPE_USBMOUSE) {
>> > - lenovo_features_set_cptkbd(hdev);
>> > - }
>> > -
>> > - break;
>> > - default:
>> > - break;
>> > - }
>> > + lenovo_features_set_cptkbd(hdev);
>
> ok. ignore my change (this whole patch) and look at your addition here,
> don't you already make sure only the mouse-part gets the messages? you
> just write switch()case instead of if(); what do you think is missing
> here?
Correct, this switch statement() that you're removing in this patch
already does exactly this, so replacing it with the
if()-and-return-early block would result in equivalent code (ignoring
the Trackpoint keyboard II). That suggestion wasn't the most helpful of
mine, sorry!
The reason I originally used a switch here is for symmetry with
lenovo_probe(), lenovo_remove(), etc. It might some day be useful to add
something like:
case USB_DEVICE_ID_LENOVO_X1_TAB:
lenovo_reset_resume_tp10ubkbd(hdev);
break;
...to the switch. For completeness, lenovo_reset_resume() should
probably call a separate lenovo_reset_resume_cptkbd() that does the
work. For just 3 lines of code it didn't seem worth it at the time
though.
Cheers,
>
> thanks,
> martin
>
>> >
>> > return 0;
>> > }
^ permalink raw reply
* Re: [RFC PATCH] of: device: Support 2nd sources of probeable but undiscoverable devices
From: Doug Anderson @ 2023-09-28 23:21 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, devicetree, Benjamin Tissoires,
Chen-Yu Tsai, linux-input, Jiri Kosina, Hsin-Yi Wang, linux-gpio,
linus.walleij, Dmitry Torokhov, Johan Hovold, andriy.shevchenko,
broonie, frowand.list, gregkh, hdegoede, james.clark, james,
keescook, linux-kernel, rafael, tglx, Jeff LaBundy
In-Reply-To: <CAL_JsqKK0tjeXNv=a8L3k0AjhCa15XOq1tPWqVod9mycsKXJHg@mail.gmail.com>
Hi,
On Thu, Sep 28, 2023 at 1:12 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> > > Perhaps then this should be solved in userspace where it can learn
> > > which device is actually present and save that information for
> > > subsequent boots.
> >
> > Yeah, the thought occurred to me as well. I think there are a few
> > problems, though:
> >
> > a) Userspace can't itself probe these devices effectively. While
> > userspace could turn on GPIOs manually and query the i2c bus manually,
> > it can't (I believe) turn on regulators nor can it turn on clocks, if
> > they are needed. About the best userspace could do would be to blindly
> > try binding an existing kernel driver, and in that case why did we
> > need userspace involved anyway?
> >
> > b) While deferring to userspace can work for solutions like ChromeOS
> > or Android where it's easy to ensure the userspace bits are there,
> > it's less appealing as a general solution. I think in Johan's case
> > he's taking a laptop that initially ran Windows and then is trying to
> > run a generic Linux distro on it. For anyone in a similar situation,
> > they'd either need to pick a Linux distro that has the magic userspace
> > bits that are needed or they need to know that, on their laptop, they
> > need to manually install some software. While requiring special
> > userspace might make sense if you've got a special peripheral, like an
> > LTE modem, it makes less sense to need special userspace just to get
> > the right devices bound...
>
> I did not mean do it all in userspace, but for userspace to save off
> what devices are actually present. For example, if userspace has
> access to the dtb, it could just update the dtb to enable the right
> nodes. Then after the first boot, boot time is faster. Or a driver
> could try to load an overlay with the config enabling the right
> devices. Though maybe waiting til userspace is available wouldn't
> speed things up.
At least for the ChromeOS boot flow userspace isn't able to make any
changes to the dtb so I don't think this would help us unless I'm
misunderstanding.
> > Imagine that instead of the hated "hid-over-i2c" compatible we were
> > using two other devices. Imagine that a given board could have a
> > "elan,ekth6915" and a "goodix,gt7375p". Both of these devices have
> > specific timing requirements on how to sequence their supplies and
> > reset GPIOs. For Elan we power on the supplies, wait at least 1 ms,
> > deassert reset, wait at least 300 ms, and then can talk i2c. For
> > Goodix we power on the supply, wait at least 10 ms, deassert reset,
> > wait at least 180 ms, and then can talk i2c. If we had a
> > board-specific probing driver then it would power on the supplies,
> > wait at least 10 ms (the max of the two), deassert reset, wait at
> > least 300 ms (the max of the two), and then see which device talked.
> > Then it would instantiate whichever of the two drivers. This could be
> > done for any two devices that EEs have determined have "compatible"
> > probing sequences.
>
> My point was that in the above example, all these delay times would
> have to be defined in the kernel, not DT.
In the case of using the actual "hid-over-i2c" driver and not one of
the specialized ones, I think we'd still need to put the delay times
in the DT for the individual "hid-over-i2c" nodes, right? The
board-specific driver could still have an implicit delay depending on
the board compatible, but if you set the "hid-over-i2c" node to "okay"
then that driver is going to be expecting to read the delay from DT.
It will use the delay it reads from the DT for powering on after
suspend/resume...
> > Ideally in the above situation we'd be able to avoid turning the
> > device off and on again between the board-specific probe code and the
> > normal driver. That optimization might need special code per-driver
> > but it feels doable by passing some sort of hint to the child driver
> > when it's instantiated.
>
> I think fixing regulators getting turned off on failed probes and
> having a "regulator on time" would go a long way towards providing
> that hint even if the on time was just since clocksource started.
You're suggesting that when a touchscreen fails to probe because it
didn't find the touchscreen on the i2c bus that it should leave its
regulator on? That doesn't seem right to me. While we might find a way
for it to help in the 2nd sourcing case, it doesn't seem right in the
case of a device truly being missing...
I'm also not sure that it truly solves the problem since the power
sequencing of these devices is more than just a regulator but often
involves several regulators being turned on (perhaps with delays in
between) and some enable and/or reset GPIOs. In the case of many
touchscreens the delay needed is actually the delay from after the
reset GPIO is deasserted.
In any case, we can talk more about this in my other response.
-Doug
^ permalink raw reply
* Re: [RFC PATCH] of: device: Support 2nd sources of probeable but undiscoverable devices
From: Doug Anderson @ 2023-09-28 23:21 UTC (permalink / raw)
To: Rob Herring
Cc: Jeff LaBundy, Krzysztof Kozlowski, Conor Dooley, devicetree,
Benjamin Tissoires, Chen-Yu Tsai, linux-input, Jiri Kosina,
Hsin-Yi Wang, linux-gpio, linus.walleij, Dmitry Torokhov,
Johan Hovold, andriy.shevchenko, broonie, frowand.list, gregkh,
hdegoede, james.clark, james, keescook, linux-kernel, rafael,
tglx
In-Reply-To: <CAL_JsqLohA20q4TpWQ=67Am-dwP43RXm-PPw5Crc4AdzBhTVoA@mail.gmail.com>
Hi,
On Thu, Sep 28, 2023 at 1:38 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> > About the best you could do would be to add a board-specific driver
> > that understood that it could power up the rails, wait the maximum
> > amount of time that all possible touchscreens might need, and then
> > look for i2c ACKs. I'm still hoping to hear from Rob about how I would
> > get a board-specific driver to load on a DT system so I can
> > investigate / prototype this.
>
> foo_initcall()
> {
> if (of_machine_is_compatible(...))
> platform_device_create();
> }
>
> That chunk would have to be built in and if that's part of the driver
> module, autoloading wouldn't work.
>
> We could have a match table of board compatibles and driver names. I'm
> not worried about that list being big, so I'm happy to stick that in
> drivers/of/.
Ah, got it. So your proposal is that we don't add anything to the
device tree but we just probe the hardware manager based on the top
level compatible string. I guess it could work. It wouldn't mesh
amazingly well with the current Chromebook rev/sku stuff in the
top-level compatible without being a bit of a jumble. It could
probably work with some sort of wildcarding (I'd assume glob-style is
enough?). So essentially:
static const struct hw_prober_map[] {
{ .glob = "google,lazor*", .func = lazor_hw_prober_init },
{ .glob = "google,homestar*", .func = homestar_hw_prober_init },
...
};
for (i = 0; i < ARRAY_SIZE(hw_prober_map), i++) {
if (of_machine_is_compatible_glob(hw_prober_map[i].glob)
hw_prober_map[i].func();
}
If that got to be too big to be built-in then I guess we could always
figure out a way to move stuff to modules and have them auto-loaded.
For now the driver could be in
"drivers/platform/chrome/cros_hwprober.c" or something?
Hmmm, I guess one issue of doing this, though, is that it's going to
be more of a pain to find the DT nodes associated with the resources
we want to enable, right? Since there's no DT note associated with the
"HW prober" driver we don't just have phandles to them. Do we just use
the whole "status" concept and search the whole DT for
"fail-needs-probe" type statuses? Like if we have an elan vs. goodix
touchscreen and we have a realtek vs. synaptic trackpad then we have
statuses like:
status = "fail-needs-probe-touchscreen-elan";
status = "fail-needs-probe-touchscreen-goodix";
status = "fail-needs-probe-trackpad-realtek";
status = "fail-needs-probe-trackpad-synaptic";
...or did you have something else in mind? I'd rather not have the HW
prober driver need to hardcode full DT paths for the devices it's
looking for.
> > > This solution seems a bit confusing to me, and would require more edits
> > > to the dts each time a second source is added. It also means one would
> > > have to write a small platform driver for each group of devices, correct?
> >
> > No matter what we need to add something to the dts each time a second
> > source is added, right?
>
> That was my thought.
OK, cool.
> There is the case of the devices are almost the
> same, so we lie. That's what you are doing for displays IIRC.
Well, we used to do it for display, but it kept biting us. That's why
we created the generic "edp-panel", right? In any case, I'd tend to
keep it as one node per possible device and have HW prober just update
the status.
> > While it's true that we'd end up with some extra drivers, if we do it
> > correctly we don't necessarily need a driver for each group of devices
> > nor even a driver per board. If several boards have very similar
> > probing requirements then, even if they have unique "compatible"
> > strings they could still end up using the same Linux driver.
> >
> > I've actually been talking offline with folks on ChromeOS more about
> > this problem as well. Chen-Yu actually pointed at a patch series (that
> > never landed, I guess) that has some similar ideas [1]. I guess in
> > that case Hans was actually constructing device tree properties
> > manually in the driver. I was thinking more of having all of the
> > options listed in the device tree and then doing something that only
> > causes some of them to probe.
> >
> > If Rob was OK with it, I guess I could have some sort of top-level
> > "hwmanager" node like Hans did and then have phandle links to all the
> > hardware that are managed by it. Then I could just change those to
> > "okay"?
>
> That's really just making the mutex node link the other direction. The
> devices link to the common mutex node vs. the hwmanager node(s) links
> to all the devices. That's really just picking the paint colors.
I don't think the HW Manager concept is the same as the common mutex
at all, so I probably didn't explain it properly.
With the mutex approach the idea is that you simply keep probing each
device one at a time until one succeeds and the mutex keeps them all
from probing at the same time.
With the hardware manager approach you run a bit of board-specific
code that understands which devices are available and can probe for
them in a way that's safer and more efficient. It's safer because it
can take into account the timing requirements of all the possible
devices to ensure that none of their power sequences are violated.
Imagine two touchscreens that each have two power rails and a reset
line. The power sequences are:
TS1:
1. Power up VCC
2. Wait 0 ms (ensure ordering between VCC and VCCIO)
3. Power up VCCIO
4. Wait 100 ms
5. Deassert reset
6. Wait 50 ms.
7. Talk I2C
TS2:
1. Power up VCC
2. Wait 10 ms
3. Power up VCCIO
4. Wait 50 ms.
5. Deassert reset
6. Wait 100 ms
7. Talk I2C
With the "mutex" approach then when we try probing TS1 we'll violate
TS2's specs (not enough delay between VCC and VCCIO). When we try
probing TS2 we'll violate TS1's specs (not enough time between VCCIO
and deasserting reset).
With the a board-specific hardware manager we could know that, for all
possible touchscreens on this board, we can always safely probe for
them with:
1. Power up VCC
2. Wait 10 ms
3. Power up VCCIO
4. Wait 100 ms.
5. Deassert reset
6. Wait 100 ms
7. Talk I2C
Once we've realized which touchscreen is actually present then all
future power ons (like after suspend/resume) can be faster, but this
would be safer for the initial probe.
The above is not only safer but also more efficient. If, in the mutex
case, we probed TS1 first but actually had TS2 then we'd spend 100 +
50 + 10 + 50 + 100 = 310 ms. With the hardware manager we'd probe for
both touchscreens in step 7 and thus we'd only take 10 + 100 + 100 =
210 ms.
The issue with the hardware manager is that we'd then run the normal
driver probe and, unless we could somehow give it a hint, it would
need to re-run through the power sequence again. In your other
response you suggested that the normal driver could just detect that
its regulator was already on and it could skip the regulator power
sequence. I'm not convinced that's a reliable hint. If nothing else
there are some boards the touchscreen regulator is shared and/or
always-on but that doesn't mean someone has properly power sequenced
the "reset" GPIO. I feel like we'd want a more explicit hint, but
that's more something to solve in the Linux driver model and not
something to solve in DT bindings.
> > Ideally, though, this could somehow use device tree "overlays" I
> > guess. That seems like almost a perfect fit. I guess the issue here,
> > though, is that I'd want the overlays bundled together with the
> > original DT and then the board-specific "hardware prober" driver to
> > actually apply the overlays after probing. Does that seem sensible?
>
> BTW, there was an idea long ago from maintainer emeritus Likely to
> append overlays to the base DTB for the kernel to apply.
>
> How would that help you here? Are you going to have an overlay for
> each device that enables it? It's much easier to just call
> of_update_property() to change "status".
Ah, OK. Somehow I assumed that using overlays would be more palatable.
If it's OK to just update the property then that seems fine to me.
...although one other reason I thought to use overlays is I think you
mentioned there was code to make late-arriving devices probe, but I'm
sure that can be handled.
---
So I guess the overall summary is: I'm strongly leaning towards
prototyping the "HW prober" approach. Hopefully that sounds OK.
-Doug
^ permalink raw reply
* Re: [PATCH] Fix strange behavior of touchpad on Clevo NS70PU
From: Werner Sembach @ 2023-09-29 10:16 UTC (permalink / raw)
To: hdegoede
Cc: chenhuacai, dmitry.torokhov, linux-input, linux-kernel,
mkorpershoek, tiwai, wsa+renesas, wse
In-Reply-To: <0e2b5e9d-d68f-59dd-6e9c-b5cdabc086c2@redhat.com>
Hi,
I just checked and saw that this never got merged. So I wanted to gently bump it.
Kind regards,
Werner Sembach
^ permalink raw reply
* Re: [PATCH 1/2] input: generalize the Imagis touchscreen driver
From: Karel Balej @ 2023-09-29 16:37 UTC (permalink / raw)
To: Markuss Broks, Karel Balej
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel, Duje Mihanović,
~postmarketos/upstreaming, Jeff LaBundy, linmengbo0689
In-Reply-To: <06e71bb8-370d-4b66-bedb-3041d6e3b2c6@gmail.com>
Hello, Markuss,
> If you don't mind the extra hassle, I'm all in for my generalization
> thing going together with your series.
>
> Alternatively, I can resend it myself, but I believe it would be better
> if they go in bulk since they need to be applied together.
great. Do you wish to make any changes to your original series? If not,
please let me know and I will use the v2 [1] as it is.
> >> As for the voltage set, I believe this does not belong in a kernel
> >> driver. You should set it in device-tree with `regulator-max-microvolt`
> >> and `regulator-min-microvolt`.
> > Please see my response to Jeff regarding this. I will be happy to hear
> > your thoughts on what I propose.
>
> Actually, the regulator values belong to the device-tree, because the
> device-tree for the board is what describes the board's regulators, and
> since you know what components are installed on that specific board you
> can know which regulator values are supposed to be set for it.
>
> [...]
>
> The actual min/max values for regulators or its voltage table is
> provided by the regulator driver itself, so there's not much point in
> specifying those again in the device-tree.
I see. I think the reason why I thought what I wrote before is that
downstream the regulator DTS lives separately from the board as a .dtsi
file which made me think that it can be used universally. So if I
understand correctly now, the hardware specifications of the regulator,
such as the minimal and maximal voltage should be part of the driver,
while the DT should contain requirements for the given use of the
regulator (with a specific board) - is this correct?
> This manual voltage setting can cause conflicts with other drivers for
> example. Also some device can use a variable wide voltage range, and
> some only specific narrow one, and e.g. the driver with wide range
> would set it to voltage that isn't suitable for the narrow range
> device, so it's much better to just specify it manually than have it
> resolved.
I would expect that in the case you describe, the kernel would set the
voltage to a value which would satisfy both the ranges. I don't know
what would happen if that was not possible (i. e. there was no
intersection in the two requested voltage ranges), though. Or does a
call to regulator_set_voltage set the voltage immediately taking notice
only of the hardware contraints? I think I am having trouble
understanding what this quote from the regulator_set_voltage
documentation means:
> If the regulator is shared between several devices then the lowest
> request voltage that meets the system constraints will be used.
But actually, it probably doesn't make sense that the kernel would try
to resolve a range suitable for all calls to this function as, I assume,
a single driver could call it multiple times with disjoint voltage
intervals.
Thank you for your patience.
Kind regards,
K. B.
^ permalink raw reply
* [PATCH] Input: xpad - add PXN V900 support
From: Matthias Berndt @ 2023-09-29 17:45 UTC (permalink / raw)
To: Dmitry Torokhov, Vicki Pfau, Ismael Ferreras Morezuelas,
Lyude Paul, Matthias Benkmann, John Butler,
Pierre-Loup A. Griffais, Jonathan Frederick, linux-input,
linux-kernel
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Hi everybody,
I recently sent this patch to the linux-input list where it was ignored, so
now I'm sending it again to every email address that get_maintainer.pl gives
me in the hope that it'll somehow get merged.
This is a trivial patch that enables support for the PXN V900 steering wheel
in the xpad driver. It's just a matter of adding the relevant USB vendorId/
productId to the list of supported IDs. I've tried it and it works.
All the best,
Matthias
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Input-xpad-add-PXN-V900-support.patch --]
[-- Type: text/x-patch; charset="x-UTF_8J"; name="0001-Input-xpad-add-PXN-V900-support.patch", Size: 1468 bytes --]
From 9b0af40bc3c064be1c7c5ba36d7fb4b8d6535fc7 Mon Sep 17 00:00:00 2001
From: Matthias Berndt <matthias_berndt@gmx.de>
Date: Mon, 25 Sep 2023 17:54:13 +0200
Subject: [PATCH] Input: xpad - add PXN V900 support
Add VID and PID to the xpad_device table to allow driver
to use the PXN V900 steering wheel, which is
XTYPE_XBOX360 compatible in xinput mode.
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index ede380551e55..478bf657efc2 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -272,6 +272,7 @@ static const struct xpad_device {
{ 0x1038, 0x1430, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
{ 0x1038, 0x1431, "SteelSeries Stratus Duo", 0, XTYPE_XBOX360 },
{ 0x11c9, 0x55f0, "Nacon GC-100XF", 0, XTYPE_XBOX360 },
+ { 0x11ff, 0x0511, "PXN V900", 0, XTYPE_XBOX360 },
{ 0x1209, 0x2882, "Ardwiino Controller", 0, XTYPE_XBOX360 },
{ 0x12ab, 0x0004, "Honey Bee Xbox360 dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360 },
{ 0x12ab, 0x0301, "PDP AFTERGLOW AX.1", 0, XTYPE_XBOX360 },
@@ -503,6 +504,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x3285), /* Nacon GC-100 */
XPAD_XBOX360_VENDOR(0x3537), /* GameSir Controllers */
XPAD_XBOXONE_VENDOR(0x3537), /* GameSir Controllers */
+ XPAD_XBOX360_VENDOR(0x11ff), /* PXN V900 */
{ }
};
--
2.41.0
^ permalink raw reply related
* Re: [PATCH] HID: prodikeys: refactor deprecated strncpy
From: Kees Cook @ 2023-09-29 18:47 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, Justin Stitt
Cc: Kees Cook, linux-input, linux-kernel, linux-hardening
In-Reply-To: <20230914-strncpy-drivers-hid-hid-prodikeys-c-v1-1-10c00550f2c2@google.com>
On Thu, 14 Sep 2023 22:20:55 +0000, Justin Stitt wrote:
> `strncpy` is deprecated for use on NUL-terminated destination strings [1].
>
> We should prefer more robust and less ambiguous string interfaces.
>
> A suitable replacement is `strscpy` [2] due to the fact that it guarantees
> NUL-termination on the destination buffer without unnecessarily NUL-padding.
>
> [...]
Applied to for-next/hardening, thanks!
[1/1] HID: prodikeys: refactor deprecated strncpy
https://git.kernel.org/kees/c/31a602bd2f48
Take care,
--
Kees Cook
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox