* [PATCH v3 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Joe Sandom via B4 Relay @ 2026-04-09 15:26 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Joe Sandom
In-Reply-To: <20260409-rb5gen2-dts-v3-0-be736355d4b4@axon.com>
From: Joe Sandom <jsandom@axon.com>
The RB5gen2 is an embedded development platform for the
QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
This change implements the main board, the vision mezzanine
will be supported in a follow up patch.
The main board has the following features:
- Qualcomm Dragonwing QCS8550 SoC
- Adreno GPU 740
- Spectra ISP
- Adreno VPU 8550
- Adreno DPU 1295
- 1 x 1GbE Ethernet (USB Ethernet)
- WIFI 7 + Bluetooth 5.4
- 1 x USB 2.0 Micro B (Debug)
- 1 x USB 3.0 Type C (ADB, DP out)
- 2 x USB 3.0 Type A
- 1 x HDMI 1.4 Type A
- 1 x DP 1.4 Type C
- 2 x WSA8845 Speaker amplifiers
- 2 x Speaker connectors
- 1 x On Board PDM MIC
- Accelerometer + Gyro Sensor
- 96Boards compatible low-speed and high-speed connectors [1]
- 7 x LED indicators (4 user, 2 radio, 1 power)
- Buttons for power, volume up/down, force USB boot
- 3 x Dip switches
On-Board PMICs:
- PMK8550 2.1
- PM8550 2.0
- PM8550VS 2.0 x4
- PM8550VE 2.0
- PM8550B 2.0
- PMR735D 2.0
- PM8010 1.1 x2
Product Page: [2]
[1] https://www.96boards.org/specifications/
[2] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit
The default msi-map from sm8550.dtsi is deleted for both pcie0 and
pcie1. The QPS615 PCIe switch on each port exposes more than two
devices (1 USP + 3 DSPs), but Gunyah currently limits ITS device
mappings to two per root complex to save memory. With msi-map
present, the ITS MAPD command times out.
Deleting msi-map causes the DWC controller to fall back to its
internal iMSI-RX module, which handles MSIs without this limitation.
Signed-off-by: Joe Sandom <jsandom@axon.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts | 1573 ++++++++++++++++++++++++++
2 files changed, 1574 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 4ba8e73064194926096b98b9556a3207e8f24d72..f8c65771f76629d7fafee15ac8d7bb62cd24a20f 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -184,6 +184,7 @@ qcs8300-ride-el2-dtbs := qcs8300-ride.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs8550-rb5gen2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts b/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts
new file mode 100644
index 0000000000000000000000000000000000000000..efa6ea82445f1183c0cc79fe5b2c741695d5d593
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts
@@ -0,0 +1,1573 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 Axon Enterprise, Inc.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "qcs8550.dtsi"
+#include "pm8010.dtsi"
+#include "pm8550.dtsi"
+#include "pm8550b.dtsi"
+#define PMK8550VE_SID 5
+#include "pm8550ve.dtsi"
+#include "pm8550vs.dtsi"
+#include "pmk8550.dtsi"
+#include "pmr735d_a.dtsi"
+#include "pmr735d_b.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. QCS8550 RB5Gen2";
+ compatible = "qcom,qcs8550-rb5gen2", "qcom,qcs8550", "qcom,sm8550";
+ chassis-type = "embedded";
+
+ aliases {
+ serial0 = &uart7;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ clocks {
+ clk40m: can-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <40000000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&volume_up_n>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ gpios = <&pm8550_gpios 6 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <<9611_out>;
+ };
+ };
+ };
+
+ /* Lontium LT9611UXC fails FW upgrade and has timeouts with geni-i2c */
+ /* Workaround is to use bit-banged I2C */
+ i2c_hub_3_gpio: i2c {
+ compatible = "i2c-gpio";
+
+ sda-gpios = <&tlmm 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&tlmm 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "green:status-3";
+ function = LED_FUNCTION_STATUS;
+ color = <LED_COLOR_ID_GREEN>;
+ gpios = <&pm8550_gpios 2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ led-1 {
+ label = "blue:bt-power";
+ function = LED_FUNCTION_BLUETOOTH;
+ color = <LED_COLOR_ID_BLUE>;
+ gpios = <&pm8550b_gpios 7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "bluetooth-power";
+ default-state = "off";
+ };
+
+ led-2 {
+ label = "yellow:wlan";
+ function = LED_FUNCTION_WLAN;
+ color = <LED_COLOR_ID_YELLOW>;
+ gpios = <&pm8550b_gpios 9 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ default-state = "off";
+ };
+ };
+
+ lt9611_1v2: lt9611-regulator-1v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "LT9611_1V2";
+
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+
+ vin-supply = <&vreg_l14b_3p2>;
+ };
+
+ lt9611_3v3: lt9611-regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "LT9611_3V3";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ vin-supply = <&vreg_l14b_3p2>;
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_ss_in: endpoint {
+ remote-endpoint = <&redriver_usb_con_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ pmic_glink_sbu_in: endpoint {
+ remote-endpoint = <&redriver_usb_con_sbu>;
+ };
+ };
+ };
+ };
+ };
+
+ pcie_upd_1p05: regulator-pcie-upd-1p05 {
+ compatible = "regulator-fixed";
+ regulator-name = "PCIE_UPD_1P05";
+ gpio = <&tlmm 179 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vdd_ntn_0p9>;
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1050000>;
+ enable-active-high;
+ regulator-enable-ramp-delay = <5000>;
+ pinctrl-0 = <&upd_1p05_en>;
+ pinctrl-names = "default";
+ };
+
+ pcie_upd_3p3: regulator-pcie-upd-3p3 {
+ compatible = "regulator-fixed";
+ regulator-name = "PCIE_UPD_3P3";
+ gpio = <&tlmm 13 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&pcie_upd_1p05>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ regulator-enable-ramp-delay = <10000>;
+ pinctrl-0 = <&upd_3p3_en>;
+ pinctrl-names = "default";
+ };
+
+ vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_NTN_0P9";
+ vin-supply = <&vdd_ntn_1p8>;
+ regulator-min-microvolt = <899400>;
+ regulator-max-microvolt = <899400>;
+ regulator-enable-ramp-delay = <4300>;
+ };
+
+ vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_NTN_1P8";
+ gpio = <&tlmm 67 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ enable-active-high;
+ pinctrl-0 = <&ntn0_en>;
+ pinctrl-names = "default";
+ regulator-enable-ramp-delay = <10000>;
+ };
+
+ vdd_ntn1_0p9: regulator-vdd-ntn1-0p9 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_NTN1_0P9";
+ vin-supply = <&vdd_ntn1_1p8>;
+ regulator-min-microvolt = <899400>;
+ regulator-max-microvolt = <899400>;
+ regulator-enable-ramp-delay = <4300>;
+ };
+
+ vdd_ntn1_1p8: regulator-vdd-ntn1-1p8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_NTN1_1P8";
+ gpio = <&tlmm 42 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ enable-active-high;
+ pinctrl-0 = <&ntn1_en>;
+ pinctrl-names = "default";
+ regulator-enable-ramp-delay = <10000>;
+ };
+
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sound {
+ compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
+ model = "QCS8550-RB5Gen2";
+ audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
+ "SpkrRight IN", "WSA_SPK2 OUT",
+ "VA DMIC0", "vdd-micb",
+ "VA DMIC1", "vdd-micb";
+
+ wsa-dai-link {
+ link-name = "WSA Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
+ };
+
+ codec {
+ sound-dai = <&left_spkr>, <&right_spkr>,
+ <&swr0 0>, <&lpass_wsamacro 0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ va-dai-link {
+ link-name = "VA Capture";
+
+ cpu {
+ sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
+ };
+
+ codec {
+ sound-dai = <&lpass_vamacro 0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+
+ wcn7850-pmu {
+ compatible = "qcom,wcn7850-pmu";
+
+ pinctrl-0 = <&wlan_en>, <&bt_default>, <&sw_ctrl_default>,
+ <&pmk8550_sleep_clk>;
+ pinctrl-names = "default";
+
+ wlan-enable-gpios = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 81 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 82 GPIO_ACTIVE_HIGH>;
+
+ vdd-supply = <&vreg_s5g_0p85>;
+ vddio-supply = <&vreg_l15b_1p8>;
+ vddaon-supply = <&vreg_s2g_0p852>;
+ vdddig-supply = <&vreg_s4e_0p95>;
+ vddrfa1p2-supply = <&vreg_s4g_1p25>;
+ vddrfa1p8-supply = <&vreg_s6g_1p86>;
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-bob1-supply = <&vph_pwr>;
+ vdd-bob2-supply = <&vph_pwr>;
+ vdd-l1-l4-l10-supply = <&vreg_s6g_1p86>;
+ vdd-l2-l13-l14-supply = <&vreg_bob1>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+ vdd-l5-l16-supply = <&vreg_bob1>;
+ vdd-l6-l7-supply = <&vreg_bob1>;
+ vdd-l8-l9-supply = <&vreg_bob1>;
+ vdd-l11-supply = <&vreg_s4g_1p25>;
+ vdd-l12-supply = <&vreg_s6g_1p86>;
+ vdd-l15-supply = <&vreg_s6g_1p86>;
+ vdd-l17-supply = <&vreg_bob2>;
+
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3296000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2720000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1b_1p8: ldo1 {
+ regulator-name = "vreg_l1b_1p8";
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <1950000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p0: ldo2 {
+ regulator-name = "vreg_l2b_3p0";
+ regulator-min-microvolt = <2900000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p1: ldo5 {
+ regulator-name = "vreg_l5b_3p1";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p8: ldo6 {
+ regulator-name = "vreg_l6b_1p8";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_1p8: ldo7 {
+ regulator-name = "vreg_l7b_1p8";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_1p8: ldo8 {
+ regulator-name = "vreg_l8b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_2p9: ldo9 {
+ regulator-name = "vreg_l9b_2p9";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <3008000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p2: ldo11 {
+ regulator-name = "vreg_l11b_1p2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_1p8: ldo12 {
+ regulator-name = "vreg_l12b_1p8";
+ regulator-min-microvolt = <1710000>;
+ regulator-max-microvolt = <1950000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_3p0: ldo13 {
+ regulator-name = "vreg_l13b_3p0";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_3p2: ldo14 {
+ regulator-name = "vreg_l14b_3p2";
+ regulator-min-microvolt = <3200000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-always-on;
+ };
+
+ vreg_l15b_1p8: ldo15 {
+ regulator-name = "vreg_l15b_1p8";
+ regulator-min-microvolt = <1760000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_2p8: ldo16 {
+ regulator-name = "vreg_l16b_2p8";
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_2p5: ldo17 {
+ regulator-name = "vreg_l17b_2p5";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-l1-supply = <&vreg_s4g_1p25>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+
+ vreg_l3c_0p9: ldo3 {
+ regulator-name = "vreg_l3c_0p9";
+ regulator-min-microvolt = <835000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "d";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+
+ vreg_l1d_0p88: ldo1 {
+ regulator-name = "vreg_l1d_0p88";
+ regulator-min-microvolt = <825000>;
+ regulator-max-microvolt = <958000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2d_0p752: ldo2 {
+ regulator-name = "vreg_l2d_0p752";
+ regulator-min-microvolt = <675000>;
+ regulator-max-microvolt = <808000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4d_0p628: smps4 {
+ regulator-name = "vreg_s4d_0p628";
+ regulator-min-microvolt = <572000>;
+ regulator-max-microvolt = <988000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5d_0p728: smps5 {
+ regulator-name = "vreg_s5d_0p728";
+ regulator-min-microvolt = <572000>;
+ regulator-max-microvolt = <988000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-3 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+
+ vreg_l1e_0p88: ldo1 {
+ regulator-name = "vreg_l1e_0p88";
+ regulator-min-microvolt = <831000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2e_0p9: ldo2 {
+ regulator-name = "vreg_l2e_0p9";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3e_1p2: ldo3 {
+ regulator-name = "vreg_l3e_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s1e_0p72: smps1 {
+ regulator-name = "vreg_s1e_0p72";
+ regulator-min-microvolt = <532000>;
+ regulator-max-microvolt = <852000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3e_0p75: smps3 {
+ regulator-name = "vreg_s3e_0p75";
+ regulator-min-microvolt = <716000>;
+ regulator-max-microvolt = <884000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4e_0p95: smps4 {
+ regulator-name = "vreg_s4e_0p95";
+ regulator-min-microvolt = <870100>;
+ regulator-max-microvolt = <1152000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5e_1p08: smps5 {
+ regulator-name = "vreg_s5e_1p08";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s6e_0p728: smps6 {
+ regulator-name = "vreg_s6e_0p728";
+ regulator-min-microvolt = <528000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "f";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+
+ vreg_l1f_0p9: ldo1 {
+ regulator-name = "vreg_l1f_0p9";
+ regulator-min-microvolt = <866000>;
+ regulator-max-microvolt = <958000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_0p88: ldo2 {
+ regulator-name = "vreg_l2f_0p88";
+ regulator-min-microvolt = <866000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_0p88: ldo3 {
+ regulator-name = "vreg_l3f_0p88";
+ regulator-min-microvolt = <830000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s1f_0p728: smps1 {
+ regulator-name = "vreg_s1f_0p728";
+ regulator-min-microvolt = <516000>;
+ regulator-max-microvolt = <904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3f_0p852: smps3 {
+ regulator-name = "vreg_s3f_0p852";
+ regulator-min-microvolt = <688000>;
+ regulator-max-microvolt = <952000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4f_0p5: smps4 {
+ regulator-name = "vreg_s4f_0p5";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5f_0p752: smps5 {
+ regulator-name = "vreg_s5f_0p752";
+ regulator-min-microvolt = <716000>;
+ regulator-max-microvolt = <884000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s7f_0p628: smps7 {
+ regulator-name = "vreg_s7f_0p628";
+ regulator-min-microvolt = <516000>;
+ regulator-max-microvolt = <812000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-5 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "g";
+
+ vdd-l1-supply = <&vreg_s4g_1p25>;
+ vdd-l2-supply = <&vreg_s4g_1p25>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+
+ vreg_l1g_1p2: ldo1 {
+ regulator-name = "vreg_l1g_1p2";
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3g_1p2: ldo3 {
+ regulator-name = "vreg_l3g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s1g_1p256: smps1 {
+ regulator-name = "vreg_s1g_1p256";
+ regulator-min-microvolt = <1172000>;
+ regulator-max-microvolt = <1388000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s2g_0p852: smps2 {
+ regulator-name = "vreg_s2g_0p852";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1053200>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3g_0p752: smps3 {
+ regulator-name = "vreg_s3g_0p752";
+ regulator-min-microvolt = <532000>;
+ regulator-max-microvolt = <1148000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4g_1p25: smps4 {
+ regulator-name = "vreg_s4g_1p25";
+ regulator-min-microvolt = <1172000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5g_0p85: smps5 {
+ regulator-name = "vreg_s5g_0p85";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1002600>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s6g_1p86: smps6 {
+ regulator-name = "vreg_s6g_1p86";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2192000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-6 {
+ compatible = "qcom,pm8010-rpmh-regulators";
+
+ vdd-l1-l2-supply = <&vreg_s4g_1p25>;
+ vdd-l3-l4-supply = <&vreg_bob2>;
+ vdd-l5-supply = <&vreg_s6g_1p86>;
+ vdd-l6-supply = <&vreg_s6g_1p86>;
+ vdd-l7-supply = <&vreg_bob1>;
+
+ qcom,pmic-id = "m";
+
+ vreg_l1m_1p056: ldo1 {
+ regulator-name = "vreg_l1m_1p056";
+ regulator-min-microvolt = <1056000>;
+ regulator-max-microvolt = <1056000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2m_1p056: ldo2 {
+ regulator-name = "vreg_l2m_1p056";
+ regulator-min-microvolt = <1056000>;
+ regulator-max-microvolt = <1056000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3m_2p8: ldo3 {
+ regulator-name = "vreg_l3m_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4m_2p8: ldo4 {
+ regulator-name = "vreg_l4m_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5m_1p8: ldo5 {
+ regulator-name = "vreg_l5m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6m_1p8: ldo6 {
+ regulator-name = "vreg_l6m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7m_2p9: ldo7 {
+ regulator-name = "vreg_l7m_2p9";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-7 {
+ compatible = "qcom,pm8010-rpmh-regulators";
+
+ vdd-l1-l2-supply = <&vreg_s4g_1p25>;
+ vdd-l3-l4-supply = <&vreg_bob2>;
+ vdd-l5-supply = <&vreg_s6g_1p86>;
+ vdd-l6-supply = <&vreg_bob1>;
+ vdd-l7-supply = <&vreg_bob1>;
+
+ qcom,pmic-id = "n";
+
+ vreg_l1n_1p1: ldo1 {
+ regulator-name = "vreg_l1n_1p1";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2n_1p1: ldo2 {
+ regulator-name = "vreg_l2n_1p1";
+ regulator-min-microvolt = <1104000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3n_2p8: ldo3 {
+ regulator-name = "vreg_l3n_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4n_2p8: ldo4 {
+ regulator-name = "vreg_l4n_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5n_1p8: ldo5 {
+ regulator-name = "vreg_l5n_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6n_3p3: ldo6 {
+ regulator-name = "vreg_l6n_3p3";
+ regulator-min-microvolt = <3200000>;
+ regulator-max-microvolt = <3200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7n_2p96: ldo7 {
+ regulator-name = "vreg_l7n_2p96";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpi_dma2 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/qcs8550/a740_zap.mbn";
+};
+
+&i2c_hub_2 {
+ clock-frequency = <100000>;
+
+ status = "okay";
+
+ typec-mux@1c {
+ compatible = "onnn,nb7vpq904m";
+ reg = <0x1c>;
+
+ vcc-supply = <&vreg_l15b_1p8>;
+
+ retimer-switch;
+ orientation-switch;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ redriver_usb_con_ss: endpoint {
+ remote-endpoint = <&pmic_glink_ss_in>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ redriver_phy_con_ss: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_out>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ redriver_usb_con_sbu: endpoint {
+ remote-endpoint = <&pmic_glink_sbu_in>;
+ };
+ };
+ };
+ };
+};
+
+&i2c_hub_3_gpio {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ lt9611_codec: hdmi-bridge@2b {
+ compatible = "lontium,lt9611uxc";
+ reg = <0x2b>;
+
+ interrupts-extended = <&tlmm 40 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tlmm 7 GPIO_ACTIVE_HIGH>;
+
+ vdd-supply = <<9611_1v2>;
+ vcc-supply = <<9611_3v3>;
+
+ pinctrl-0 = <<9611_irq_pin <9611_rst_pin>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt9611_a: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ lt9611_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&i2c_hub_4 {
+ status = "okay";
+};
+
+&i2c_master_hub_0 {
+ status = "okay";
+};
+
+&ipa {
+ firmware-name = "qcom/qcs8550/ipa_fws.mbn";
+
+ status = "okay";
+};
+
+&iris {
+ status = "okay";
+};
+
+&lpass_vamacro {
+ pinctrl-0 = <&dmic01_default>;
+ pinctrl-names = "default";
+
+ qcom,dmic-sample-rate = <4800000>;
+
+ vdd-micb-supply = <&vreg_l15b_1p8>;
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&mdss_dsi0_out {
+ remote-endpoint = <<9611_a>;
+ data-lanes = <0 1 2 3>;
+};
+
+&mdss_dsi0_phy {
+ vdds-supply = <&vreg_l1e_0p88>;
+
+ status = "okay";
+};
+
+&mdss_dp0 {
+ status = "okay";
+};
+
+&pcie0 {
+ vddpe-3v3-supply = <&pcie_upd_3p3>;
+
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&pcie0_default_state>;
+ pinctrl-names = "default";
+
+ iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
+ <0x100 &apps_smmu 0x1401 0x1>,
+ <0x208 &apps_smmu 0x1402 0x1>,
+ <0x210 &apps_smmu 0x1403 0x1>,
+ <0x218 &apps_smmu 0x1404 0x1>,
+ <0x300 &apps_smmu 0x1407 0x1>,
+ <0x400 &apps_smmu 0x1408 0x1>,
+ <0x500 &apps_smmu 0x140c 0x1>,
+ <0x501 &apps_smmu 0x140e 0x1>;
+
+ /delete-property/ msi-map;
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&pcie0_port0 {
+ pcie@0,0 {
+ compatible = "pci1179,0623";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x2 0xff>;
+
+ vddc-supply = <&vdd_ntn_0p9>;
+ vdd18-supply = <&vdd_ntn_1p8>;
+ vdd09-supply = <&vdd_ntn_0p9>;
+ vddio1-supply = <&vdd_ntn_1p8>;
+ vddio2-supply = <&vdd_ntn_1p8>;
+ vddio18-supply = <&vdd_ntn_1p8>;
+
+ i2c-parent = <&i2c_hub_4 0x77>;
+
+ resx-gpios = <&tlmm 64 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&tc9563_0_rst &upd_ponrst>;
+ pinctrl-names = "default";
+
+ pcie@1,0 {
+ reg = <0x20800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x3 0xff>;
+ };
+
+ pcie@2,0 {
+ reg = <0x21000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x4 0xff>;
+ };
+
+ pcie@3,0 {
+ reg = <0x21800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ bus-range = <0x5 0xff>;
+
+ pci@0,0 {
+ reg = <0x50000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ };
+
+ pci@0,1 {
+ reg = <0x50100 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ };
+ };
+ };
+};
+
+&pcie1 {
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&pcie1_default_state>;
+ pinctrl-names = "default";
+
+ iommu-map = <0x0 &apps_smmu 0x1480 0x1>,
+ <0x100 &apps_smmu 0x1481 0x1>,
+ <0x208 &apps_smmu 0x1482 0x1>,
+ <0x210 &apps_smmu 0x1483 0x1>,
+ <0x218 &apps_smmu 0x1484 0x1>,
+ <0x300 &apps_smmu 0x1487 0x1>,
+ <0x400 &apps_smmu 0x1488 0x1>,
+ <0x500 &apps_smmu 0x148c 0x1>,
+ <0x501 &apps_smmu 0x148e 0x1>;
+
+ /delete-property/ msi-map;
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l3c_0p9>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+ vdda-qref-supply = <&vreg_l1e_0p88>;
+
+ status = "okay";
+};
+
+&pcie1_port0 {
+ pcie@0,0 {
+ compatible = "pci1179,0623";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x2 0xff>;
+
+ vddc-supply = <&vdd_ntn1_0p9>;
+ vdd18-supply = <&vdd_ntn1_1p8>;
+ vdd09-supply = <&vdd_ntn1_0p9>;
+ vddio1-supply = <&vdd_ntn1_1p8>;
+ vddio2-supply = <&vdd_ntn1_1p8>;
+ vddio18-supply = <&vdd_ntn1_1p8>;
+
+ i2c-parent = <&i2c_hub_3_gpio 0x77>;
+
+ resx-gpios = <&tlmm 65 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&tc9563_1_rst>;
+ pinctrl-names = "default";
+
+ pcie@1,0 {
+ reg = <0x20800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x3 0xff>;
+ };
+
+ pcie@2,0 {
+ reg = <0x21000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x4 0xff>;
+
+ wifi@0 {
+ compatible = "pci17cb,1107";
+ reg = <0x40000 0x0 0x0 0x0 0x0>;
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ };
+ };
+
+ pcie@3,0 {
+ reg = <0x21800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ bus-range = <0x5 0xff>;
+ };
+ };
+};
+
+&pm8550_gpios {
+ volume_up_n: volume-up-n-state {
+ pins = "gpio6";
+ function = "normal";
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+
+ sdc2_card_det_n: sdc2-card-det-state {
+ pins = "gpio12";
+ function = "normal";
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+};
+
+&pm8550_pwm {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <0>;
+ linux,default-trigger = "none";
+ default-state = "off";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ linux,default-trigger = "none";
+ default-state = "off";
+ };
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <2>;
+ linux,default-trigger = "none";
+ default-state = "off";
+ };
+};
+
+&pm8550b_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+};
+
+&pmk8550_gpios {
+ pmk8550_sleep_clk: sleep-clk-state {
+ pins = "gpio3";
+ function = "func1";
+ input-disable;
+ output-enable;
+ bias-disable;
+ power-source = <0>;
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/qcs8550/adsp.mbn",
+ "qcom/qcs8550/adsp_dtb.mbn";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs8550/cdsp.mbn",
+ "qcom/qcs8550/cdsp_dtb.mbn";
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/qcs8550/modem.mbn",
+ "qcom/qcs8550/modem_dtb.mbn";
+ status = "okay";
+};
+
+&sdhc_2 {
+ cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&sdc2_default>, <&sdc2_card_det_n>;
+ pinctrl-1 = <&sdc2_sleep>, <&sdc2_card_det_n>;
+ pinctrl-names = "default", "sleep";
+
+ vmmc-supply = <&vreg_l9b_2p9>;
+ vqmmc-supply = <&vreg_l8b_1p8>;
+
+ no-sdio;
+ no-mmc;
+
+ status = "okay";
+};
+
+&sleep_clk {
+ clock-frequency = <32764>;
+};
+
+&spi11 {
+ status = "okay";
+
+ can@0 {
+ compatible = "microchip,mcp2518fd";
+ reg = <0>;
+ interrupts-extended = <&tlmm 55 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&clk40m>;
+ spi-max-frequency = <10000000>;
+ vdd-supply = <&vreg_l14b_3p2>;
+ xceiver-supply = <&vreg_l14b_3p2>;
+ };
+};
+
+&swr0 {
+ status = "okay";
+
+ left_spkr: speaker@0,0 {
+ compatible = "sdw20217020400";
+ reg = <0 0>;
+
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+
+ vdd-1p8-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l15b_1p8>;
+
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrLeft";
+ qcom,port-mapping = <1 2 3 7 10 13>;
+ };
+
+ right_spkr: speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+
+ reset-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+
+ vdd-1p8-supply = <&vreg_l15b_1p8>;
+ vdd-io-supply = <&vreg_l15b_1p8>;
+
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "SpkrRight";
+ qcom,port-mapping = <4 5 6 7 11 13>;
+ };
+};
+
+&tlmm {
+ /* 32-35 for NFC secure element */
+ /* 36-39 for fingerprint sensor */
+ gpio-reserved-ranges = <32 8>;
+
+ lt9611_rst_pin: lt9611-rst-state {
+ pins = "gpio7";
+ function = "gpio";
+ };
+
+ upd_3p3_en: upd-3p3-en-state {
+ pins = "gpio13";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ lt9611_irq_pin: lt9611-irq-state {
+ pins = "gpio40";
+ function = "gpio";
+ bias-disable;
+ };
+
+ ntn1_en: ntn1-en-state {
+ pins = "gpio42";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ tc9563_0_rst: tc9563-0-rst-state {
+ pins = "gpio64";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ tc9563_1_rst: tc9563-1-rst-state {
+ pins = "gpio65";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ ntn0_en: ntn0-en-state {
+ pins = "gpio67";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wlan_en: wlan-en-state {
+ pins = "gpio80";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
+
+ bt_default: bt-default-state {
+ pins = "gpio81";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ sw_ctrl_default: sw-ctrl-default-state {
+ pins = "gpio82";
+ function = "gpio";
+ bias-pull-down;
+ };
+
+ upd_1p05_en: upd-1p05-en-state {
+ pins = "gpio179";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ upd_ponrst: upd-ponrst-state {
+ pins = "gpio182";
+ function = "gpio";
+ drive-strength = <2>;
+ output-high;
+ };
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&uart14 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn7850-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ };
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l1g_1p2>;
+ vccq-max-microamp = <1200000>;
+ vdd-hba-supply = <&vreg_l3g_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l1d_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_1_hsphy {
+ vdd-supply = <&vreg_l1e_0p88>;
+ vdda12-supply = <&vreg_l3e_1p2>;
+
+ phys = <&pm8550b_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l3f_0p88>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy_out {
+ remote-endpoint = <&redriver_phy_con_ss>;
+};
+
+&xo_board {
+ clock-frequency = <76800000>;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/5] dt-bindings: arm: qcom: document QCS8550 RB5Gen2 board
From: Joe Sandom via B4 Relay @ 2026-04-09 15:26 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Joe Sandom,
Krzysztof Kozlowski
In-Reply-To: <20260409-rb5gen2-dts-v3-0-be736355d4b4@axon.com>
From: Joe Sandom <jsandom@axon.com>
Document the Qualcomm RB5gen2 from Thundercomm based on the
QCS8550 chipset from Qualcomm.
[1] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Joe Sandom <jsandom@axon.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 1335a7bee397c46e8dc62806091531e32b7327d4..f9f8001e3e6b66e3a926255bdb15363f4c7c2b66 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1093,6 +1093,12 @@ properties:
- const: qcom,qcs8550
- const: qcom,sm8550
+ - items:
+ - enum:
+ - qcom,qcs8550-rb5gen2
+ - const: qcom,qcs8550
+ - const: qcom,sm8550
+
- items:
- enum:
- ayaneo,pocket-s2
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/5] arm64: dts: qcom: sm8550: move IPA properties to SoC device tree
From: Joe Sandom via B4 Relay @ 2026-04-09 15:26 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Joe Sandom,
Dmitry Baryshkov
In-Reply-To: <20260409-rb5gen2-dts-v3-0-be736355d4b4@axon.com>
From: Joe Sandom <jsandom@axon.com>
Move qcom,gsi-loader and memory-region properties from individual board
DTS files into the SoC DTSI, since these are common to all SM8550-based
boards.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Joe Sandom <jsandom@axon.com>
---
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 2 --
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 2 --
arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 ++
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index e821b731bdc496c872703723df02ae9b9b0233b5..b795589385520acd74eecc7701cab82f4f7da200 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -939,8 +939,6 @@ &i2c_master_hub_0 {
};
&ipa {
- qcom,gsi-loader = "self";
- memory-region = <&ipa_fw_mem>;
firmware-name = "qcom/sm8550/ipa_fws.mbn";
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index cf63109ff7bf7b6fc827f108e22e82b8b04273c1..f2effa55d8197819175bfd5a89d2fddb20561548 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -818,8 +818,6 @@ fsa4480_sbu_mux: endpoint {
};
&ipa {
- qcom,gsi-loader = "self";
- memory-region = <&ipa_fw_mem>;
firmware-name = "qcom/sm8550/ipa_fws.mbn";
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 54308cbde40732da072177eab533582c155df590..d292dfce6b66fff6cff918b8bd6ac0b9cd22c4b3 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2730,6 +2730,8 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
qcom,smem-state-names = "ipa-clock-enabled-valid",
"ipa-clock-enabled";
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
sram = <&ipa_modem_tables>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/5] arm64: dts: qcom: sm8550: add PCIe port labels
From: Joe Sandom via B4 Relay @ 2026-04-09 15:26 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Joe Sandom,
Neil Armstrong, Dmitry Baryshkov
In-Reply-To: <20260409-rb5gen2-dts-v3-0-be736355d4b4@axon.com>
From: Joe Sandom <jsandom@axon.com>
Add labels to the root port nodes (pcie0_port0, pcie1_port0) to
allow board DTS files to reference them for adding endpoint devices
to each pcie root port.
Update the pcieport0 reference to pcie0_port0 in sm8550-hdk.dts and
sm8550-qrd.dts to match the label rename in sm8550.dtsi.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Joe Sandom <jsandom@axon.com>
---
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 2 +-
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 2 +-
arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
index ee13e6136a8259d28540e718851e094f74ead278..e821b731bdc496c872703723df02ae9b9b0233b5 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
@@ -1012,7 +1012,7 @@ &pcie0 {
status = "okay";
};
-&pcieport0 {
+&pcie0_port0 {
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
index 2fb2e0be5e4c6b597f20f332cdf063daa2664205..cf63109ff7bf7b6fc827f108e22e82b8b04273c1 100644
--- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
@@ -912,7 +912,7 @@ &pcie0 {
status = "okay";
};
-&pcieport0 {
+&pcie0_port0 {
wifi@0 {
compatible = "pci17cb,1107";
reg = <0x10000 0x0 0x0 0x0 0x0>;
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 055ca931c04859f3a312eb9921aeb7a8cc676822..54308cbde40732da072177eab533582c155df590 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -2098,7 +2098,7 @@ opp-16000000-3 {
};
};
- pcieport0: pcie@0 {
+ pcie0_port0: pcie@0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
@@ -2300,7 +2300,7 @@ opp-32000000-4 {
};
};
- pcie@0 {
+ pcie1_port0: pcie@0 {
device_type = "pci";
reg = <0x0 0x0 0x0 0x0 0x0>;
bus-range = <0x01 0xff>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/5] arm64: dts: qcom: sm8550: add PCIe MHI register regions
From: Joe Sandom via B4 Relay @ 2026-04-09 15:26 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Joe Sandom
In-Reply-To: <20260409-rb5gen2-dts-v3-0-be736355d4b4@axon.com>
From: Joe Sandom <jsandom@axon.com>
Add the MHI register regions to the pcie0 and pcie1 controller nodes
to expose link power state transition counters (L0s/L1/L1.1/L1.2/L2)
via debugfs. The PCIe host driver uses this region to read the
link_transition_count from the MHI registers.
Signed-off-by: Joe Sandom <jsandom@axon.com>
---
arch/arm64/boot/dts/qcom/sm8550.dtsi | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index 912525e9bca6f5e1cbb8887ee0bf9e39650dc4ff..055ca931c04859f3a312eb9921aeb7a8cc676822 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1964,8 +1964,14 @@ pcie0: pcie@1c00000 {
<0 0x60000000 0 0xf1d>,
<0 0x60000f20 0 0xa8>,
<0 0x60001000 0 0x1000>,
- <0 0x60100000 0 0x100000>;
- reg-names = "parf", "dbi", "elbi", "atu", "config";
+ <0 0x60100000 0 0x100000>,
+ <0 0x01c03000 0 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x01000000 0x0 0x00000000 0x0 0x60200000 0x0 0x100000>,
@@ -2138,8 +2144,14 @@ pcie1: pcie@1c08000 {
<0x0 0x40000000 0x0 0xf1d>,
<0x0 0x40000f20 0x0 0xa8>,
<0x0 0x40001000 0x0 0x1000>,
- <0x0 0x40100000 0x0 0x100000>;
- reg-names = "parf", "dbi", "elbi", "atu", "config";
+ <0x0 0x40100000 0x0 0x100000>,
+ <0x0 0x01c0b000 0x0 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
#address-cells = <3>;
#size-cells = <2>;
ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/5] arm64: dts: qcom: add QCS8550 RB5Gen2 support
From: Joe Sandom via B4 Relay @ 2026-04-09 15:26 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Joe Sandom,
Neil Armstrong, Dmitry Baryshkov, Krzysztof Kozlowski
This series adds device tree support for the Thundercomm RB5Gen2
development kit, based on the Qualcomm QCS8550 chipset.
Patches 1-3 prepares for the RB5gen2 device tree by adding MHI register
regions and port labels to the PCIe controller nodes, as well as moving
common IPA properties into sm8550.dtsi. Then update the existing HDK
and QRD board files accordingly.
Patches 4-5 add the dt-bindings documentation and the board device tree
for the RB5Gen2. This initial submission covers the main board; the vision
mezzanine will be supported in a follow-up series.
Product page:
https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit
Signed-off-by: Joe Sandom <jsandom@axon.com>
---
Changes in v3:
- Reworded MHI commit message to describe actual usage (debugfs
link_transition_count) per Neil's feedback
- Reordered pinctrl-0 before pinctrl-names file-wide per Konrad's
feedback
- Removed output-high from lt9611_rst_pin since the driver handles
reset sequencing
- Reordered tlmm pinctrl entries by GPIO number
- Changed bias-pull-up to bias-disable for regulator enable pins
(upd_1p05_en, upd_3p3_en) since these are active-high enables
- Added comments for gpio-reserved-ranges explaining GPIOs 32-35
are for NFC secure element and 36-39 for fingerprint sensor
- Removed max-sd-hs-hz override since upstream clock driver already
provides the correct 37.5MHz frequency
- Updated msi-map deletion rationale with root cause: Gunyah limits
ITS device mappings to two per root complex on SM8550
- Link to v2: https://lore.kernel.org/r/20260407-rb5gen2-dts-v2-0-d0c7f447ee73@axon.com
Changes in v2:
- Lowercase hex in MHI region definitions for pcie0 and pcie1 nodes +
vertical alignment
- Change pcie0 and pcie1 reg-names for one entry per line
- Ensured pcie port labels + changes to sm8550-hdk.dts and sm8550-qrd.dts
are done in a single commit
- Moved IPA gsi-loader and memory-region to sm8550.dtsi since they are common
properties. Reflect changes in sm8550-hdk.dts and sm8550-qrd.dts
- Removed usbhub_reset since this is not required
- Added swctrl-gpios property to wcn7850-pmu
- Split sw_ctrl_default gpio from bt_default grouping and referenced the
pinctrl separately
- Replaced upd_reset regulator-fixed with pinctrl and vddpe-3v3-supply
on pcie0
- Aligned firmware-name values vertically on the quote mark
- Changed cdsp, adsp and modem remoteprocs to .mbn file type instead of
.mdt
- Added remark in rb5gen2 dts commit explaining the rationale for
deleting msi-map in pcie0 and pcie1 nodes
- Link to v1: https://lore.kernel.org/r/20260404-rb5gen2-dts-v1-0-895f8fc494fc@axon.com
---
Joe Sandom (5):
arm64: dts: qcom: sm8550: add PCIe MHI register regions
arm64: dts: qcom: sm8550: add PCIe port labels
arm64: dts: qcom: sm8550: move IPA properties to SoC device tree
dt-bindings: arm: qcom: document QCS8550 RB5Gen2 board
arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
Documentation/devicetree/bindings/arm/qcom.yaml | 6 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts | 1573 +++++++++++++++++++++++
arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 4 +-
arch/arm64/boot/dts/qcom/sm8550-qrd.dts | 4 +-
arch/arm64/boot/dts/qcom/sm8550.dtsi | 26 +-
6 files changed, 1602 insertions(+), 12 deletions(-)
---
base-commit: af241225893ac4933bb8f0615f2dfda8ea2326ce
change-id: 20260404-rb5gen2-dts-180cde0b716c
Best regards,
--
Joe Sandom <jsandom@axon.com>
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Mark Brown @ 2026-04-09 15:26 UTC (permalink / raw)
To: Rob Herring
Cc: Herve Codina, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <CAL_JsqK4SHQS6MciQpLSrGWo2knqs7-eB3yoAv2J54bSfW-Lxg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
On Thu, Apr 09, 2026 at 10:00:55AM -0500, Rob Herring wrote:
> On Wed, Apr 8, 2026 at 12:09 PM Herve Codina <herve.codina@bootlin.com> wrote:
> > Mark suggested to merge this gpio-audio-amp with simple-amplifier.
> Merging driver and merging binding are separate questions.
Yes, my comments were purely about the driver.
> > I didn't want to set a particular limit related to the number of GPIOs
> > used for thje gain value. Of course 2^32 is obviously a lot.
> > What do you think about 16 for maxItems?
> What is the most you are aware of? Take that and double it.
> Seems to me 256 levels would be way more than a human ear could distinguish.
There's plenty of gain controls with way more than 256 bits of
resolution, though I'm not aware of any that are configured via GPIO.
The step size and absolute values you want can vary dramatically
depending on application, possibly in the same system (eg, a DAC that
can be connected to both headphones or speakers) so you often end up
making practical adjustments in a small subset of the available range
but that subset can vary a lot for the same part.
> I guess my point was that really we could deprecate simple-amplifier
> binding because this one can handle it and more. But I'm not
> suggesting we do that yet.
That's my thinking.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Stefan Wahren @ 2026-04-09 15:21 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Srinivas Kandagatla, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <addd5ZpuUdKBV7Bn@gregor-framework>
Am 09.04.26 um 10:05 schrieb Gregor Herburger:
> On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
>> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
>>> Hi Stefan,
>>>
>>> thanks for the review.
>>>> Is there any reason, why we cannot register this driver in
>>>> rpi_firmware_probe() like hwmon and clk driver?
>>>>
>>>> I like to avoid the complete dt-binding from patch 1.
>>> The private OTP registers are not available on all Raspberries. Afaik
>>> only on 4 and 5. So I think these registers must be described through
>>> the device tree. Therefore the bindings are needed.
>> This binding doesn't represent some kind of hardware, it's just some
>> firmware interface. A proper DT binding would describe the MMIO address
>> range for OTP access.
> I think it does represent real hardware. Although it is hidden through the
> firmware. Not all hardware must be MMIO addresses.
>
> The only driver that does not have a DT node is the hwmon driver. All
> other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
> binding. Looking at the comment in rpi_register_clk_driver this
> seems to be some legacy behaviour for older DTs for the clock driver.
There is a long history of different approaches how to implement the
VideoCore firmware interface for the Raspberry Pi and not all of them
are good from today's perspective.
One big problem with DT binding is that the kernel must be compatible
with all mainline DTS versions. This sounds trivial, but it's not. Since
we cannot assume that kernel & DTB are updated at the same time. So we
need to keep these bad solutions from the past.
>> If you need some distinction between the Raspberry Pi generations there are
>> firmware tags to do this.
> So what is your suggestion? What tags do you mean?
Your driver already use firmware tags to access the OTPs via firmware.
You can ask the Raspberry Pi guys, how to do the distinction in a
efficient/maintainable way.
My suggestion would be to look at
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#get-board-model
and
https://github.com/u-boot/u-boot/blob/master/board/raspberrypi/rpi/rpi.c#L95
The compatible "raspberrypi,bcm2712-firmware" approach is more straight
forward, but requires a newer DTB. See above.
Best regards
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-04-09 15:19 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
Krzysztof Kozlowski
In-Reply-To: <80067706-1857-46a0-a281-7f4ff3937468@oss.qualcomm.com>
On 09/04/2026 14:41, Konrad Dybcio wrote:
> On 4/8/26 7:34 PM, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> We know the driver is reporting s3706b, introduce the compatible so we
>
> via Google search AI summary:
> "Bon Chef S3706B is a black dinner fork (Roman Euro Dinner Fork)" - the
> more you know!
Oh no, that's definitely not compatible hardware! Maybe it's some fork... :P
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: nxp,pca9564: convert to DT schema
From: Akhila YS @ 2026-04-09 15:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Rosin, linux-i2c, devicetree, linux-kernel
In-Reply-To: <20260409-rampant-swinging-wolf-51ab4e@quoll>
On 09-04-2026 13:56, Krzysztof Kozlowski wrote:
> On Wed, Apr 08, 2026 at 08:23:31AM +0000, Akhila YS wrote:
>> Convert NXP PCA PCA9564/PCA9665 I2C controller to YAML format.
> DT schema, not YAML format. Look at your subject.
Okay, i will change it.
>
> ...
>
>> + reg:
>> + maxItems: 1
>> +
>> + "#address-cells":
>> + const: 1
>> +
>> + "#size-cells":
>> + const: 0
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + reset-gpios:
>> + maxItems: 1
>> +
>> + clock-frequency:
>> + default: 100000
>> +
>> +required:
>> + - compatible
>> + - reg
>> +
>> +additionalProperties: false
> And if you tested any DTS with this, you would see this cannot work.
> Look at other bindings - you miss ref to i2c-controller and
> unevaluatedProps. But the problem is that you are doing something which
> would never work, so I have doubts that you know what you are doing. One
> thing is to make a mistake, other thing is to post something can never
> work thus putting quite noticeable requirements on review.
You are right, i missed referencing the common i2c controller schema and
did not handle unevaluated properties correctly,which makes binding invalid.
>
> Please first learn how DTS and DT bindings work, before you post new
> patches.
Thank you for the review, i will work on it.
> Best regards,
> Krzysztof
>
--
Best Regards,
Akhila.
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Rob Herring @ 2026-04-09 15:00 UTC (permalink / raw)
To: Herve Codina
Cc: Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <20260408190932.0ab936b0@bootlin.com>
On Wed, Apr 8, 2026 at 12:09 PM Herve Codina <herve.codina@bootlin.com> wrote:
>
> Hi Rob, Mark,
>
> On Wed, 8 Apr 2026 07:29:01 -0500
> Rob Herring <robh@kernel.org> wrote:
>
> ...
>
> > > +properties:
> > > + compatible:
> > > + const: audio-gpio-amp
> >
> > To be consistent with other GPIO controlled devices: gpio-audio-amp
>
> Ok.
>
> Mark suggested to merge this gpio-audio-amp with simple-amplifier.
Merging driver and merging binding are separate questions.
> This leads to the following question:
>
> Should I keep the 'gpio-audio-amp' compatible string ?
Yes. 'cause this binding isn't simple...
And I don't care for any compatible with 'simple' (or generic) in it.
Not sure why I agreed to that one. But I'm all for generic/common
drivers.
> Should I keep two bindings (this one and the simple-audio-amplifier.yaml) or
> should I merge bindings?
2 bindings. There's no overlap in property names.
> ...
> > > + gain-gpios:
> > > + description: |
> > > + GPIOs to control the amplifier gain
> > > +
> > > + The gain value is computed from GPIOs value from 0 to 2^N-1 with N the
> > > + number of GPIO described. The first GPIO described is the lsb of the gain
> > > + value.
> > > +
> > > + For instance assuming 2 gpios
> > > + gain-gpios = <&gpio1 GPIO_ACTIVE_HIGH> <&gpio2 GPIO_ACTIVE_HIGH>;
> > > + The gain value will be the following:
> > > +
> > > + gpio1 | gpio2 | gain
> > > + ------+-------+-----
> > > + 0 | 0 | 0b00 -> 0
> > > + 1 | 0 | 0b01 -> 1
> > > + 0 | 1 | 0b10 -> 2
> > > + 1 | 1 | 0b11 -> 3
> > > + ------+-------+-----
> > > +
> > > + Note: The gain value, bits set to 1 or 0, indicate the state active (bit
> > > + set) or the state inactive (bit unset) of the related GPIO. The
> > > + physical voltage corresponding to this active/inactive state is
> > > + given by the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags.
> > > +
> > > + minItems: 1
> > > + maxItems: 32
> >
> > 2^32 levels? Seems like a bit much. Also, unless you can change the
> > values of all the GPIOs atomically, aren't you going to get some
> > artifacts while the gain is being changed? Unless you mute I guess.
>
> I didn't want to set a particular limit related to the number of GPIOs
> used for thje gain value. Of course 2^32 is obviously a lot.
>
> What do you think about 16 for maxItems?
What is the most you are aware of? Take that and double it.
Seems to me 256 levels would be way more than a human ear could distinguish.
> Related to Artifacts, yes they can probably be there. Also the mute feature
> is not required. Some hardware use only one GPIO and doesn't implement mute
> feature. In that case no artifacts can be present.
>
> If mute is implemented, it is the application responsibility to handle
> mute / unmute while changing the gain value. I don't think we can do anything
> at driver level to avoid those artifacts if any.
>
> >
> > > +
> > > + gain-points:
> > > + $ref: /schemas/types.yaml#/definitions/int32-matrix
> > > + items:
> > > + items:
> > > + - description: The GPIOs value
> >
> > Can't this just be the index?
>
> Some GPIOs value can be skipped if they don't make any sense in the hardware
> design. With the index, this is not possible.
>
> gpios:
> 0b00 -3dB
> 0b01 0dB
> 0b10 Reserved, should not be used
> 0b11 +3dB
>
> With just the index, the reserved 0b10 value cannot be skipped. I would like
> to handle this kind of cases.
Okay.
> > If not, then gain-range could be expressed using gain-points instead.
>
> Do you have in mind something like the following?
> gain-range = <0 (-300)>, <3 600>;
>
> defining the range from -3dB to +6dB with GPIOs value 0 for -3dB and 3 for +6dB.
Yes, but since you can have reserved values, that won't work.
> > > + - description: The related amplifier gain in 0.01 dB unit
> > > + minItems: 2
> > > + description: |
> > > + List of the GPIOs value / Gain value in dB pair defining the gain
> > > + set on each GPIOs value.
> > > +
> > > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > > + Assuming that GPIOs values set the hardware gains according to the
> > > + following table:
> > > +
> > > + GPIOs | Hardware
> > > + value | amplification
> > > + ------+--------------
> > > + 0 | -10.0 dB
> > > + 1 | +3.0 dB
> > > + 2 | 0 dB
> > > + 3 | +6.0 dB
> > > + ------+--------------
> > > +
> > > + The description using gain points can be:
> > > + gain-points = <0 (-1000)>, <1 300>, <2 0>, <3 600>;
> > > +
> > > + gain-range:
> > > + $ref: /schemas/types.yaml#/definitions/int32-array
> > > + items:
> > > + - description: Gain in 0.01 dB unit when all GPIOs are inactive
> > > + - description: Gain in 0.01 dB unit when all GPIOs are active
> > > + description: |
> > > + Gains (in 0.01 dB unit) set by the extremum (minimal and maximum) value
> > > + of GPIOs. The following formula must be satisfied.
> > > +
> > > + gain-range[1] - gain-range[0]
> > > + Gain = ------------------------------- x GPIO_value + gain-range[0]
> > > + 2^N - 1
> > > +
> > > + With N, the number of GPIOs used to control the gain and Gain computed in
> > > + 0.01 dB unit.
> > > +
> > > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > > + Assuming that gain value set the hardware according to the following
> > > + table:
> > > +
> > > + GPIOs | Hardware 1 | Hardware 2
> > > + value | amplification | amplification
> > > + ------+---------------+---------------
> > > + 0 | -3.0 dB | +10.0 dB
> > > + 1 | 0 dB | +5.0 dB
> > > + 2 | +3.0 dB | 0 dB
> > > + 3 | +6.0 dB | -5.0 dB
> > > + ------+---------------+---------------
> > > +
> > > + The description for hardware 1 using a gain range can be:
> > > + gain-range = <(-300) 600>;
> > > +
> > > + The description for hardware 2 using a gain range can be:
> > > + gain-range = <1000 (-500)>;
> > > +
> > > + gain-labels:
> > > + $ref: /schemas/types.yaml#/definitions/string-array
> >
> > minItems: 2
> > maxItems: 0x100000000
>
> Ok, I will adjust maxItems according to the max number of GPIO supported.
>
> For my curiosity, is there a way to express maxItems with a computation
> based on some other properties value ?
No, there isn't.
>
> What could be relevant here is
> maxitems: 2^(number of items available in the gpio-gain properties)
>
> >
> > > + description: |
> > > + List of the gain labels attached to the combination of GPIOs controlling
> > > + the gain. The first label is related to the gain value 0, the second label
> > > + is related to the gain value 1 and so on.
> > > +
> > > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > > + Assuming that gain value set the hardware according to the following
> > > + table:
> > > +
> > > + GPIOs | Hardware
> > > + value | amplification
> > > + ------+--------------
> > > + 0 | Low
> > > + 1 | Middle
> > > + 2 | High
> > > + 3 | Max
> > > + ------+--------------
> > > +
> > > + The description using gain labels can be:
> > > + gain-labels = "Low", "Middle", "High", "Max";
> >
> > Do we need to allow these to be anything? It's going to get hard to come
> > up with 2^32 names.
>
> Well, "Normal" / "Boost" can make sense on some hardware.
>
> I don't think we need to restrict labels to a list of known label here.
As long as the names are meaningless to software.
>
> Of course 2^32 names is obviously a lot. What could be the limit?
I would guess at 8 or more, it's just going to be gain1, gain2, etc.
or something similar constructed from the gain values.
> ...
>
> > > +
> > > + /* A mutable amplifier without any gain control */
> > > + amplifier4 {
> > > + compatible = "audio-gpio-amp";
> > > + vdd-supply = <®ulator>;
> > > + mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> >
> > This case is just simple-amplifier...
>
> No, simple-amplifier uses 'enable' and not 'mute'.
Yes, I know...
> We can have the amplifier enabled ('enable' GPIO active) as it is
> used and a switch driven by an other GPIO to mute / un-mute the
> amplifier output.
But you have no 'enable' GPIO here. To me, enable just looks like
inverted mute. If there's some electrical difference, I can't tell
what that is from either binding.
I guess my point was that really we could deprecate simple-amplifier
binding because this one can handle it and more. But I'm not
suggesting we do that yet.
Rob
^ permalink raw reply
* Re: [PATCH] of: fdt: skip KHO when booting as crash kernel
From: Mike Rapoport @ 2026-04-09 14:22 UTC (permalink / raw)
To: Evangelos Petrongonas
Cc: Rob Herring, Saravana Kannan, Changyuan Lyu, Alexander Graf,
Pasha Tatashin, Pratyush Yadav, Andrew Morton, devicetree, kexec,
linux-kernel, nh-open-source
In-Reply-To: <20260407150639.69923-1-epetron@amazon.de>
Hi Evangelos,
On Tue, Apr 07, 2026 at 03:06:33PM +0000, Evangelos Petrongonas wrote:
> KHO preserves state across kexec by passing a KHO-specific FDT pointer
> and scratch memory region to the incoming kernel. These point to
> physical addresses in the outgoing kernel's memory that the incoming
> kernel is expected to access and restore from. This falls apart when
> the incoming kernel is a crash kernel as the crash kernel can run in a
> small reserved memory region. The scratch regions can sit outside this
> reservation, so the end result is quite unpleasant.
>
> kho_add_chosen() unconditionally propagates KHO properties into
> the device tree for all kexec image types, including crash images. The
> crash kernel then discovers these properties during
> early_init_dt_check_kho(), records the stale physical addresses via
> kho_populate(), and later faults in kho_memory_init() when it tries
> phys_to_virt() on the KHO FDT address:
>
> Unable to handle kernel paging request at virtual address xxxxxxxx
> ...
> fdt_offset_ptr+...
> fdt_check_node_offset_+...
> fdt_first_property_offset+...
> fdt_get_property_namelen_+...
> fdt_getprop+...
> kho_memory_init+...
> mm_core_init+...
> start_kernel+...
>
> kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
> images, but the DT property propagation and the consumer side were both
> missing the same guard.
>
> Fix this at both ends. Have kho_add_chosen() skip writing KHO properties
> for crash images so the stale pointers never reach the crash kernel's
> device tree. Also have early_init_dt_check_kho() bail out when
> is_kdump_kernel() is true. This way even if KHO properties end up in
> the DT through some other path, the crash kernel will not act on them.
>
> Fixes: 274cdcb1c004 ("arm64: add KHO support")
> Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> ---
>
> I think we should backport the fix on KHO compatible versions (6.16+),
> hence the "Fixes:" tag. Tested on an arm64 system.
>
> drivers/of/fdt.c | 3 +++
> drivers/of/kexec.c | 3 ++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
What about x86? ;-)
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 43a0944ca462..77018ec99fc8 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -926,6 +926,9 @@ static void __init early_init_dt_check_kho(void)
> if (!IS_ENABLED(CONFIG_KEXEC_HANDOVER) || (long)node < 0)
> return;
>
> + if (is_kdump_kernel())
> + return;
> +
This seems redundant if don't add KHO nodes at the first place.
> if (!of_flat_dt_get_addr_size(node, "linux,kho-fdt",
> &fdt_start, &fdt_size))
> return;
> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> index c4cf3552c018..b95f0b386684 100644
> --- a/drivers/of/kexec.c
> +++ b/drivers/of/kexec.c
> @@ -271,7 +271,8 @@ static int kho_add_chosen(const struct kimage *image, void *fdt, int chosen_node
> if (ret && ret != -FDT_ERR_NOTFOUND)
> return ret;
>
> - if (!image->kho.fdt || !image->kho.scratch)
> + if (!image->kho.fdt || !image->kho.scratch ||
> + image->type == KEXEC_TYPE_CRASH)
> return 0;
>
> fdt_mem = image->kho.fdt;
kho_add_chosen() bails out if there's no KHO buffer in kimage, so if
kho_fill_kimage won't add KHO buffer to kexec_crash_image it should be
enough.
> --
> 2.43.0
>
>
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v4 2/2] mfd: arizona: Convert GPIO IRQ handling to descriptors
From: Lee Jones @ 2026-04-09 14:21 UTC (permalink / raw)
To: Linus Walleij
Cc: Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Charles Keepax, patches, linux-kernel, linux-gpio,
devicetree
In-Reply-To: <20260326-mfd-arizona-irq-v4-2-50c47ed0a18e@kernel.org>
On Thu, 26 Mar 2026, Linus Walleij wrote:
> Convert the arizona polling GPIO handling to use a GPIO descriptor
> instead of passing a global GPIO number as platform data.
>
> This mechanism is not used in the kernel, but let's preserve
> the mechanism to be nice.
>
> Users can define "irq-gpios" in the devicetree or software node
> for the Arizona chip to provide the GPIO line corresponding to
> the IRQ.
>
> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
> ---
> drivers/mfd/arizona-irq.c | 46 +++++++++++++++++++--------------------
> include/linux/mfd/arizona/core.h | 2 ++
> include/linux/mfd/arizona/pdata.h | 5 -----
> 3 files changed, 24 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
> index 544016d420fe..8b752a1257b1 100644
> --- a/drivers/mfd/arizona-irq.c
> +++ b/drivers/mfd/arizona-irq.c
> @@ -136,21 +136,19 @@ static irqreturn_t arizona_irq_thread(int irq, void *data)
> dev_err(arizona->dev,
> "Failed to read main IRQ status: %d\n", ret);
> }
> -#ifdef CONFIG_GPIOLIB_LEGACY
> /*
> * Poll the IRQ pin status to see if we're really done
> * if the interrupt controller can't do it for us.
> */
> - if (!arizona->pdata.irq_gpio) {
> + if (!arizona->irq_gpiod) {
> break;
> } else if (arizona->pdata.irq_flags & IRQF_TRIGGER_RISING &&
> - gpio_get_value_cansleep(arizona->pdata.irq_gpio)) {
> + gpiod_get_value_cansleep(arizona->irq_gpiod)) {
> poll = true;
> } else if (arizona->pdata.irq_flags & IRQF_TRIGGER_FALLING &&
> - !gpio_get_value_cansleep(arizona->pdata.irq_gpio)) {
> + !gpiod_get_value_cansleep(arizona->irq_gpiod)) {
> poll = true;
> }
> -#endif
> } while (poll);
>
> pm_runtime_put_autosuspend(arizona->dev);
> @@ -350,27 +348,26 @@ int arizona_irq_init(struct arizona *arizona)
> goto err_map_main_irq;
> }
>
> -#ifdef CONFIG_GPIOLIB_LEGACY
> - /* Used to emulate edge trigger and to work around broken pinmux */
> - if (arizona->pdata.irq_gpio) {
> - if (gpio_to_irq(arizona->pdata.irq_gpio) != arizona->irq) {
> - dev_warn(arizona->dev, "IRQ %d is not GPIO %d (%d)\n",
> - arizona->irq, arizona->pdata.irq_gpio,
> - gpio_to_irq(arizona->pdata.irq_gpio));
> - arizona->irq = gpio_to_irq(arizona->pdata.irq_gpio);
> - }
> -
> - ret = devm_gpio_request_one(arizona->dev,
> - arizona->pdata.irq_gpio,
> - GPIOF_IN, "arizona IRQ");
> - if (ret != 0) {
> - dev_err(arizona->dev,
> - "Failed to request IRQ GPIO %d:: %d\n",
> - arizona->pdata.irq_gpio, ret);
> - arizona->pdata.irq_gpio = 0;
> + /*
> + * Used to emulate edge trigger and to work around broken pinmux
> + * define "irq-gpios" in device tree or software node.
> + */
Nit: Device Tree (not sure about software node).
> + arizona->irq_gpiod = devm_gpiod_get_optional(arizona->dev, "irq",
> + GPIOD_IN);
> + if (IS_ERR(arizona->irq_gpiod)) {
> + ret = dev_err_probe(arizona->dev,
> + PTR_ERR(arizona->irq_gpiod),
> + "error getting IRQ GPIO\n");
Nit: All other prints in this file are capitalised.
> + goto err_irq_gpiod;
> + }
> + if (arizona->irq_gpiod) {
> + if (gpiod_to_irq(arizona->irq_gpiod) != arizona->irq) {
> + dev_warn(arizona->dev, "IRQ %d does not match GPIO's IRQ %d\n",
> + arizona->irq, gpiod_to_irq(arizona->irq_gpiod));
> + arizona->irq = gpiod_to_irq(arizona->irq_gpiod);
Could we cache the result of 'gpiod_to_irq()' into a local variable rather than
calling it multiple times?
Does it make sense to check the value's for errors?
> }
> + gpiod_set_consumer_name(arizona->irq_gpiod, "arizona IRQ");
> }
> -#endif
>
> ret = request_threaded_irq(arizona->irq, NULL, arizona_irq_thread,
> flags, "arizona", arizona);
> @@ -409,6 +406,7 @@ int arizona_irq_init(struct arizona *arizona)
> arizona_free_irq(arizona, ARIZONA_IRQ_BOOT_DONE, arizona);
> err_boot_done:
> free_irq(arizona->irq, arizona);
> +err_irq_gpiod:
> err_main_irq:
Do we really need another goto label that jumps to the same place?
> regmap_del_irq_chip(irq_find_mapping(arizona->virq,
> ARIZONA_MAIN_IRQ_INDEX),
> diff --git a/include/linux/mfd/arizona/core.h b/include/linux/mfd/arizona/core.h
> index 6d6f96b2b29f..7129651c9af6 100644
> --- a/include/linux/mfd/arizona/core.h
> +++ b/include/linux/mfd/arizona/core.h
> @@ -11,6 +11,7 @@
> #define _WM_ARIZONA_CORE_H
>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/interrupt.h>
> #include <linux/notifier.h>
> #include <linux/regmap.h>
> @@ -136,6 +137,7 @@ struct arizona {
> struct irq_domain *virq;
> struct regmap_irq_chip_data *aod_irq_chip;
> struct regmap_irq_chip_data *irq_chip;
> + struct gpio_desc *irq_gpiod;
>
> bool hpdet_clamp;
> unsigned int hp_ena;
> diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h
> index f72e6d4b14a7..20118bad869a 100644
> --- a/include/linux/mfd/arizona/pdata.h
> +++ b/include/linux/mfd/arizona/pdata.h
> @@ -188,11 +188,6 @@ struct arizona_pdata {
> /** Haptic actuator type */
> unsigned int hap_act;
>
> -#ifdef CONFIG_GPIOLIB_LEGACY
> - /** GPIO for primary IRQ (used for edge triggered emulation) */
> - int irq_gpio;
> -#endif
> -
> /** General purpose switch control */
> unsigned int gpsw;
> };
>
> --
> 2.53.0
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 12/13] hwmon: spd5118: Add I3C support
From: Guenter Roeck @ 2026-04-09 14:19 UTC (permalink / raw)
To: Akhil R, Alexandre Belloni, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J . Wysocki,
Robert Moore, Len Brown, Philipp Zabel, Eric Biggers,
Sakari Ailus, Wolfram Sang, Miquel Raynal, linux-i3c, devicetree,
linux-kernel, linux-acpi, acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-13-akhilrajeev@nvidia.com>
On 4/9/26 03:57, Akhil R wrote:
> Add a regmap config and a probe function to support for I3C based
> communication to SPD5118 devices.
>
> On an I3C bus, SPD5118 are enumerated via SETAASA and always require an
> ACPI or device tree entry. The device matching is hence through the OF
> match tables only and do not need an I3C class match table. The device
> identity is verified in the type registers before proceeding to the
> common probe function.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: [PATCH v2 11/13] hwmon: spd5118: Remove 16-bit addressing
From: Guenter Roeck @ 2026-04-09 14:11 UTC (permalink / raw)
To: Akhil R, Alexandre Belloni, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J . Wysocki,
Robert Moore, Len Brown, Philipp Zabel, Eric Biggers,
Sakari Ailus, Wolfram Sang, Miquel Raynal, linux-i3c, devicetree,
linux-kernel, linux-acpi, acpica-devel, linux-hwmon
In-Reply-To: <20260409105747.48158-12-akhilrajeev@nvidia.com>
On 4/9/26 03:57, Akhil R wrote:
> The intent of introducing 16-bit addressing was to support I3C, but it
> turns out to be that I3C do not require to read the Legacy Mode register
> nor any specific encoding for page translation. The testing of 16-bit
> code was limited and there are no known users for this feature. Remove
> the sections which are there to support 16-bit addressing and prepare the
> driver to support I3C appropriately.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Suggested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* Re: (subset) [PATCH 4/7] dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
From: Lee Jones @ 2026-04-09 13:46 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Sean Young,
Michael Turquette, Stephen Boyd, Martin Botka, Biswapriyo Nath
Cc: linux-arm-msm, devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260325-ginkgo-add-usb-ir-vib-v1-4-446c6e865ad6@gmail.com>
On Wed, 25 Mar 2026 18:07:27 +0000, Biswapriyo Nath wrote:
> 30 duty cycle for IR transmitter is used in Xiaomi Redmi Note 8 (ginkgo).
Applied, thanks!
[4/7] dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
commit: 2bbd36622df51f22e6902b0a0743d9354bc8f6d4
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
From: Daniel Golle @ 2026-04-09 13:35 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Wunderlich, linux-kernel,
linux-arm-kernel, linux-mediatek, devicetree, Andrew LaMarche
In-Reply-To: <20260409131754.121737-3-linux@fw-web.de>
On Thu, Apr 09, 2026 at 03:17:50PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
>
> On the official case the red LED is named ERR, the blue LED is named ACT.
> Reflect these labels in function and set them default off.
>
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
> .../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> index 759f608d1081..7f770a76775a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
> @@ -61,14 +61,16 @@ gpio-leds {
>
> led_red: sys-led-red {
> color = <LED_COLOR_ID_RED>;
> + function = LED_FUNCTION_FAULT;
> gpios = <&pca9555 15 GPIO_ACTIVE_HIGH>;
> - default-state = "on";
> + default-state = "off";
Just drop 'default-state' entirely from both nodes.
> };
>
> led_blue: sys-led-blue {
> color = <LED_COLOR_ID_BLUE>;
> + function = LED_FUNCTION_ACTIVITY;
> gpios = <&pca9555 14 GPIO_ACTIVE_HIGH>;
> - default-state = "on";
> + default-state = "off";
> };
> };
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750-mtp: Set sufficient voltage for panel nt37801
From: Bjorn Andersson @ 2026-04-09 13:35 UTC (permalink / raw)
To: Ayushi Makhija
Cc: konrad.dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt,
dmitry.baryshkov, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, quic_rajeevny, quic_vproddut
In-Reply-To: <75d22f54-eb55-4e55-9582-5b407f41ee81@quicinc.com>
On Thu, Apr 09, 2026 at 11:14:10AM +0530, Ayushi Makhija wrote:
> On 3/26/2026 9:28 PM, Bjorn Andersson wrote:
> > On Thu, Mar 26, 2026 at 03:06:52PM +0530, Ayushi Makhija wrote:
> >> On 3/24/2026 7:34 AM, Bjorn Andersson wrote:
> >>> On Mon, Mar 23, 2026 at 03:52:29PM +0530, Ayushi Makhija wrote:
> >>>> The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> >>>> VDDI=1.65V~1.95V, so set sufficient voltage for panel nt37801.
> >>>>
> >>>
> >>> Please add Fixes: tag.
> >>>
> >>
> >> Hi Bjorn,
> >>
> >> Sure, will add in new patchset.
> >>
> >>>> Signed-off-by: Ayushi Makhija <quic_amakhija@quicinc.com>
> >>>
> >>> Please start using your oss.qualcomm.com address.
> >>>
> >>>> ---
> >>>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 2 +-
> >>>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >>>> index 3837f6785320..6ba4e69bf377 100644
> >>>> --- a/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >>>> +++ b/arch/arm64/boot/dts/qcom/sm8750-mtp.dts
> >>>> @@ -462,7 +462,7 @@ vreg_l11b_1p0: ldo11 {
> >>>>
> >>>> vreg_l12b_1p8: ldo12 {
> >>>> regulator-name = "vreg_l12b_1p8";
> >>>> - regulator-min-microvolt = <1200000>;
> >>>> + regulator-min-microvolt = <1650000>;
> >>>
> >>> Are you sure it's not supposed to be 1.8V, given the name of the rail?
> >>>
> >>> Regards,
> >>> Bjorn
> >>
> >> There was already discussion regarding the minimum voltage for this regulator on sm8550 target
> >> on other upstream patch.
> >>
> >> Link: https://lore.kernel.org/all/aQQdQoCLeKhYtY7W@yuanjiey.ap.qualcomm.com/
> >>
> >> This values is according to the NT37801 panel sec
> >> "The NT37801 Sepc V1.0 chapter "5.7.1 Power On Sequence" states
> >> VDDI=1.65V~1.95V."
> >>
> >
> > Yes, so the panel requires 1.65V, so regulator-min-microvolt needs to be
> > at least that. But regulator-min-microvolt should account for all the
> > consumers of the rail, are there any others?
> >
> > Which leads me to my question, the people designing the board named the
> > rail VREG_L12B_1P8 in the schematics, why didn't they name it
> > VREG_L12B_1P65?
> >
> > Please check all the consumers and make the regulator-min-microvolt work
> > for all of them - if that's 1.65V, then your change is good.
> >
> > Regards,
> > Bjorn
>
> Hi Bjorn,
>
> There is only one consumer of VREG_L12B_1P8 rail, i.e. NT37801 panel.
> So regulator-min-microvolt as 1.65V should be fine for VREG_L12B_1P8 rail.
>
Had to look it up myself. MTP power grid says it should be 1.8V.
Thank you,
Bjorn
> Thanks,
> Ayushi
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: rtc: nct3018y: add nuvoton,ctrl-reg-val property
From: Alexandre Belloni @ 2026-04-09 13:30 UTC (permalink / raw)
To: David Wang
Cc: Krzysztof Kozlowski, a.zummo, robh, krzk+dt, conor+dt, andrew,
avi.fishman, tmaimon77, tali.perry1, venture, yuenn, benjaminfair,
ctcchien, mimi05633, openbmc, linux-rtc, devicetree, linux-kernel,
davidwang
In-Reply-To: <CADSQSY1rAnZ69JAjosV_AWBw9OL77dyzHkewW5YGvpCZRwXq5A@mail.gmail.com>
On 09/04/2026 15:44:43+0800, David Wang wrote:
> On Apr 9, 2026, at 15:23, Krzysztof Kozlowski wrote:
> >
> > On 09/04/2026 09:21, David Wang wrote:
> > > Add "nuvoton,ctrl-reg-val" vendor property to allow optional
> > > initialization of the RTC control register (0x0A).
> > >
> > > This allows platform-specific configurations like 24h mode and
> > > write ownership to be defined via Device Tree.
> > >
> > > Signed-off-by: David Wang <tomato1220@gmail.com>
> > > ---
> > > Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > > index 4f9b5604acd9..0984dfb77170 100644
> > > --- a/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > > +++ b/Documentation/devicetree/bindings/rtc/nuvoton,nct3018y.yaml
> > > @@ -24,6 +24,10 @@ properties:
> > >
> > > reset-source: true
> > >
> > > + nuvoton,ctrl-reg-val:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description: Initial value for the control register (0x0A).
> >
> > 24h mode is not a property of a board. I don't know what "write
> > ownership" is.
> >
> > Best regards,
> > Krzysztof
>
> Hi Krzysztof,
>
> Thanks for your feedback. Let me clarify these two points based on the
> NCT3018Y datasheet:
> 1. Regarding "write ownership": The NCT3018Y features two I2C
> interfaces (Primary and Secondary). The TWO (Time Write Ownership) bit
> in the control register determines which interface has the authority
> to write to the RTC. We need to ensure the interface connected to our
> SoC is granted this ownership during probe—especially for factory-new
> chips—to ensure the RTC is writable.
You need a write-access property. For NXP, we settled with
nxp,write-access.
> 2. Regarding "24h mode": This bit determines the internal data format
> in which time is stored within the RTC hardware. Setting this ensures
> the hardware's internal storage layout matches the driver's
> expectation from the start.
The driver needs to always write 24h mode but can support reading both.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v1 0/3] some BPI-R4Pro dts updates
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
From: Frank Wunderlich <frank-w@public-files.de>
There are some parts of BPI-R4Pro DTS that need to be changed. Currently
there should be not much users of the mainline-dts and we noticed some
things while openwrt integration.
Frank Wunderlich (3):
arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
arch/arm64/boot/dts/mediatek/Makefile | 8 ++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn13.dtso | 20 +++++++++++++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn14.dtso | 20 +++++++++++++++++++
.../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 15 ++++----------
4 files changed, 52 insertions(+), 11 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
--
2.43.0
^ permalink raw reply
* [PATCH v1 3/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260409131754.121737-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
The active-high property in base-dt cannot be overwritten and must be
set in separate overlay.
Fixes: f397471a6a8c ("arm64: dts: mediatek: mt7988: Add devicetree for BananaPi R4 Pro")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
arch/arm64/boot/dts/mediatek/Makefile | 8 ++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn13.dtso | 20 +++++++++++++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn14.dtso | 20 +++++++++++++++++++
.../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 2 --
4 files changed, 48 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 387faa9c2a09..a86fb313b1a9 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -47,6 +47,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-emmc.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-4e.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn13.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn14.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
@@ -70,18 +72,24 @@ mt7988a-bananapi-bpi-r4-2g5-sd-dtbs := \
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5-sd.dtb
mt7988a-bananapi-bpi-r4-pro-8x-emmc-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-emmc.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-sd.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8167-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
new file mode 100644
index 000000000000..973b76ba0cbf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN13 on pcie2(11280000 1L0) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-2-hog} {
+ output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
new file mode 100644
index 000000000000..90b2a64459c3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN14 on pcie3(11290000 1L1) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-3-hog} {
+ output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 7f770a76775a..5c5d4e26aa56 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -432,14 +432,12 @@ mux {
pcie-2-hog {
gpio-hog;
gpios = <79 GPIO_ACTIVE_HIGH>;
- output-high;
};
/* 1L1 0=key-b (CN18), 1=key-m (CN14) */
pcie-3-hog {
gpio-hog;
gpios = <63 GPIO_ACTIVE_HIGH>;
- output-high;
};
pwm0_pins: pwm0-pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260409131754.121737-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
On the official case the red LED is named ERR, the blue LED is named ACT.
Reflect these labels in function and set them default off.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 759f608d1081..7f770a76775a 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -61,14 +61,16 @@ gpio-leds {
led_red: sys-led-red {
color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_FAULT;
gpios = <&pca9555 15 GPIO_ACTIVE_HIGH>;
- default-state = "on";
+ default-state = "off";
};
led_blue: sys-led-blue {
color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_ACTIVITY;
gpios = <&pca9555 14 GPIO_ACTIVE_HIGH>;
- default-state = "on";
+ default-state = "off";
};
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Laurent Pinchart @ 2026-04-09 13:24 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <61f294e8-f9ae-4868-8dba-60250279ef21@bp.renesas.com>
On Thu, Apr 09, 2026 at 01:15:18PM +0200, Tommaso Merciai wrote:
> On 4/8/26 17:00, Laurent Pinchart wrote:
> > On Wed, Apr 08, 2026 at 04:44:48PM +0200, Tommaso Merciai wrote:
> >> On 4/8/26 16:16, Laurent Pinchart wrote:
> >>> On Wed, Apr 08, 2026 at 04:02:14PM +0200, Tommaso Merciai wrote:
> >>>> On 4/8/26 14:24, Laurent Pinchart wrote:
> >>>>> On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
> >>>>>> The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
> >>>>>> Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
> >>>>>> Display Unit (DU).
> >>>>>>
> >>>>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> >>>>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >>>>>>
> >>>>>> Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
> >>>>>>
> >>>>>> Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
> >>>>>> allow up to four output ports, and explicitly disable port@2 and port@3
> >>>>>> for existing SoCs that do not expose them.
> >>>>>>
> >>>>>> Describe the four output ports of the RZ/G3E DU:
> >>>>>>
> >>>>>> - port@0: DSI (available on both LCDC instances)
> >>>>>> - port@1: DPAD / parallel RGB (LCDC1 only)
> >>>>>> - port@2: LVDS channel 0 (LCDC0 only)
> >>>>>> - port@3: LVDS channel 1 (available on both LCDC instances)
> >>>>>>
> >>>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> >>>>>> ---
> >>>>>> v5->v6:
> >>>>>> - Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
> >>>>>> explicitly disable port@2 and port@3 for existing SoCs that do not expose
> >>>>>> them.
> >>>>>> - Reworked ports numbering + improved/fixed ports descriptions in the
> >>>>>> bindings documentation.
> >>>>>> - Improved commit body.
> >>>>>>
> >>>>>> v4->v5:
> >>>>>> - Dropped renesas,id property and updated bindings
> >>>>>> accordingly.
> >>>>>>
> >>>>>> v2->v3:
> >>>>>> - No changes.
> >>>>>>
> >>>>>> v2->v3:
> >>>>>> - No changes.
> >>>>>>
> >>>>>> v1->v2:
> >>>>>> - Use single compatible string instead of multiple compatible strings
> >>>>>> for the two DU instances, leveraging a 'renesas,id' property to
> >>>>>> differentiate between DU0 and DU1.
> >>>>>> - Updated commit message accordingly.
> >>>>>>
> >>>>>> .../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
> >>>>>> 1 file changed, 29 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>>>> index 5add3b832eab..32da0b5ec88c 100644
> >>>>>> --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> >>>>>> @@ -20,6 +20,7 @@ properties:
> >>>>>> - enum:
> >>>>>> - renesas,r9a07g043u-du # RZ/G2UL
> >>>>>> - renesas,r9a07g044-du # RZ/G2{L,LC}
> >>>>>> + - renesas,r9a09g047-du # RZ/G3E
> >>>>>> - renesas,r9a09g057-du # RZ/V2H(P)
> >>>>>> - items:
> >>>>>> - enum:
> >>>>>> @@ -61,7 +62,7 @@ properties:
> >>>>>> model-dependent. Each port shall have a single endpoint.
> >>>>>>
> >>>>>> patternProperties:
> >>>>>> - "^port@[0-1]$":
> >>>>>> + "^port@[0-3]$":
> >>>>>> $ref: /schemas/graph.yaml#/properties/port
> >>>>>> unevaluatedProperties: false
> >>>>>>
> >>>>>> @@ -103,6 +104,8 @@ allOf:
> >>>>>> port@0:
> >>>>>> description: DPI
> >>>>>> port@1: false
> >>>>>> + port@2: false
> >>>>>> + port@3: false
> >>>>>>
> >>>>>> required:
> >>>>>> - port@0
> >>>>>> @@ -119,6 +122,8 @@ allOf:
> >>>>>> description: DSI
> >>>>>> port@1:
> >>>>>> description: DPI
> >>>>>> + port@2: false
> >>>>>> + port@3: false
> >>>>>>
> >>>>>> required:
> >>>>>> - port@0
> >>>>>> @@ -135,9 +140,32 @@ allOf:
> >>>>>> port@0:
> >>>>>> description: DSI
> >>>>>> port@1: false
> >>>>>> + port@2: false
> >>>>>> + port@3: false
> >>>>>>
> >>>>>> required:
> >>>>>> - port@0
> >>>>>> + - if:
> >>>>>> + properties:
> >>>>>> + compatible:
> >>>>>> + contains:
> >>>>>> + const: renesas,r9a09g047-du
> >>>>>> + then:
> >>>>>> + properties:
> >>>>>> + ports:
> >>>>>> + properties:
> >>>>>> + port@0:
> >>>>>> + description: DSI
> >>>>>> + port@1:
> >>>>>> + description: DPAD
> >>>>>> + port@2:
> >>>>>> + description: LVDS, Channel 0
> >>>>>> + port@3:
> >>>>>> + description: LVDS, Channel 1
> >>>>>> +
> >>>>>> + required:
> >>>>>> + - port@0
> >>>>>> + - port@3
> >>>>>
> >>>>> Why are ports 1 and 2 not required ?
> >>>>
> >>>> About this we had a similar discussion on v5[0]
> >>>> We are using the same compatible and:
> >>>>
> >>>> - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> >>>> |
> >>>> --> then has:
> >>>> port@0
> >>>> port@2
> >>>> port@3
> >>>>
> >>>>
> >>>> - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >>>> |
> >>>> --> then has:
> >>>> port@0
> >>>> port@1
> >>>> port@3
> >>>
> >>> Ah yes, I forget there are two LCDC instances with different output
> >>> configurations.
> >>>
> >>> Something still looks a bit weird to me though. For LCDC1, which
> >>> supports a single LVDS channel, you use the port described as the second
> >>> LVDS channel. Is there a reason not to use port@2 ?
> >>
> >> 9.11 Low Voltage Differential Signaling (LVDS)
> >> 9.11.1.2 Block Diagram
> >> Figure 9.11-1 shows a block diagram of LVDS.
> >>
> >> LCDC1 is connected to LVDS, Channel 1
> >> For this reason I'm using port@3.
> >
> > Re-reading that, I think I've misinterpreted the hardware architecture.
> > Doesn't the DU have a single output, that is connected the multiple
> > encoders (LVDS and DSI for LCDC0 and LVDS, DSI and DPI for LCDC1) ? It
> > seems modelling it with a single port and multiple endpoints would
> > better match the device.
> >
> > For LVDS in particular, I see a single LVDS encoder with two channels,
> > so there should not be two LVDS output ports in the DU. The two ports
> > should be on the output of the LVDS device.
>
> You are suggesting the following dt architecture:
>
> du0: display@16460000 {
> compatible = "renesas,r9a09g047-du";
> reg = <0 0x16460000 0 0x10000>;
> interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cpg CPG_MOD 0xed>,
> <&cpg CPG_MOD 0xee>,
> <&cpg CPG_MOD 0xef>;
> clock-names = "aclk", "pclk", "vclk";
> power-domains = <&cpg>;
> resets = <&cpg 0xdc>;
> renesas,vsps = <&vspd0 0>;
> status = "disabled";
>
> port {
> du0_out_dsi: endpoint@0 {
> reg = <0>;
> };
>
> du0_out_lvds0: endpoint@2 {
> reg = <2>;
> };
>
> du0_out_lvds1: endpoint@3 {
> reg = <3>;
> };
> }
> };
>
> du1: display@16490000 {
> compatible = "renesas,r9a09g047-du";
> reg = <0 0x16490000 0 0x10000>;
> interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&cpg CPG_MOD 0x1a8>,
> <&cpg CPG_MOD 0x1a9>,
> <&cpg CPG_MOD 0x1aa>;
> clock-names = "aclk", "pclk", "vclk";
> power-domains = <&cpg>;
> resets = <&cpg 0x11e>;
> renesas,vsps = <&vspd1 0>;
> status = "disabled";
>
> port {
> du1_out_dsi: endpoint@0 {
> reg = <0>;
> };
>
> du1_out_rgb: endpoint@1 {
> reg = <1>;
> };
>
> du1_out_lvds1: endpoint@3 {
> reg = <3>;
> };
> }
> };
>
>
> Please correct me if I'm wrong.
That's right. It would match the hardware, or at least my understanding
of the hardware based on the documentation. As far as I can tell, each
DU has a single 24-bit output port connected to multiple encoders.
> >>>> Then port@1 is required for DU1 but not for DU0.
> >>>> Same port@2 is required for DU0 but not for DU1.
> >>>>
> >>>> [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@bp.renesas.com/
> >>>>
> >>>>>>
> >>>>>> examples:
> >>>>>> # RZ/G2L DU
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v1 1/3] arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
From: Frank Wunderlich @ 2026-04-09 13:17 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260409131754.121737-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
These properties are already set in the original node and do not need
to be defined again.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 1175ee156cb3..759f608d1081 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -185,13 +185,6 @@ ð {
status = "okay";
};
-&fan {
- pinctrl-0 = <&pwm0_pins>;
- pinctrl-names = "default";
- pwms = <&pwm 0 50000>;
- status = "okay";
-};
-
&gmac0 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 13/21] drm: renesas: rz-du: mipi_dsi: Add RZ_MIPI_DSI_FEATURE_GPO0R feature
From: Laurent Pinchart @ 2026-04-09 13:22 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, geert, linux-renesas-soc, biju.das.jz,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Magnus Damm,
Tomi Valkeinen, dri-devel, devicetree, linux-kernel, linux-clk
In-Reply-To: <81165cf9-b1cc-4e75-b586-0e1ef7675b9d@bp.renesas.com>
On Thu, Apr 09, 2026 at 01:14:51PM +0200, Tommaso Merciai wrote:
> On 4/8/26 17:08, Laurent Pinchart wrote:
> > On Wed, Apr 08, 2026 at 04:58:01PM +0200, Tommaso Merciai wrote:
> >> On 4/8/26 16:17, Laurent Pinchart wrote:
> >>> On Wed, Apr 08, 2026 at 04:12:22PM +0200, Tommaso Merciai wrote:
> >>>> On 4/8/26 14:31, Laurent Pinchart wrote:
> >>>>> On Wed, Apr 08, 2026 at 12:36:58PM +0200, Tommaso Merciai wrote:
> >>>>>> The MIPI DSI ip found in the RZ/G3E SoC select the video input clock
> >>>>>> based on the DU instance actually connected using the GPO0R register.
> >>>>>>
> >>>>>> Add this feature to the driver using `RZ_MIPI_DSI_FEATURE_GPO0R`, update
> >>>>>> the code accordingly to manage the vclk selection with the introduction
> >>>>>> of `rzg2l_mipi_dsi_get_input_port()`.
> >>>>>>
> >>>>>> Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> >>>>>> ---
> >>>>>> v5->v6:
> >>>>>> - Moved rzg2l_mipi_dsi_link_write() into rzv2h_mipi_dsi_dphy_init()
> >>>>>> + comments from HW Manual.
> >>>>>>
> >>>>>> v4->v5:
> >>>>>> - No changes.
> >>>>>>
> >>>>>> v3->v4:
> >>>>>> - No changes.
> >>>>>>
> >>>>>> v2->v3:
> >>>>>> - No changes.
> >>>>>>
> >>>>>> v1->v2:
> >>>>>> - No changes.
> >>>>>>
> >>>>>> .../gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c | 71 +++++++++++++++++--
> >>>>>> .../drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h | 3 +
> >>>>>> 2 files changed, 68 insertions(+), 6 deletions(-)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >>>>>> index be6dbf19a24e..947c8e15fc4b 100644
> >>>>>> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >>>>>> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi.c
> >>>>>> @@ -37,7 +37,9 @@ MODULE_IMPORT_NS("RZV2H_CPG");
> >>>>>>
> >>>>>> #define RZG2L_DCS_BUF_SIZE 128 /* Maximum DCS buffer size in external memory. */
> >>>>>>
> >>>>>> +#define RZ_MIPI_DSI_MAX_INPUT 2
> >>>>>> #define RZ_MIPI_DSI_FEATURE_16BPP BIT(0)
> >>>>>> +#define RZ_MIPI_DSI_FEATURE_GPO0R BIT(1)
> >>>>>>
> >>>>>> struct rzg2l_mipi_dsi;
> >>>>>>
> >>>>>> @@ -81,13 +83,14 @@ struct rzg2l_mipi_dsi {
> >>>>>> struct drm_bridge bridge;
> >>>>>> struct drm_bridge *next_bridge;
> >>>>>>
> >>>>>> - struct clk *vclk;
> >>>>>> + struct clk *vclk[RZ_MIPI_DSI_MAX_INPUT];
> >>>>>> struct clk *lpclk;
> >>>>>>
> >>>>>> enum mipi_dsi_pixel_format format;
> >>>>>> unsigned int num_data_lanes;
> >>>>>> unsigned int lanes;
> >>>>>> unsigned long mode_flags;
> >>>>>> + u8 vclk_idx;
> >>>>>>
> >>>>>> struct rzv2h_dsi_mode_calc mode_calc;
> >>>>>>
> >>>>>> @@ -543,8 +546,8 @@ static int rzg2l_dphy_conf_clks(struct rzg2l_mipi_dsi *dsi, unsigned long mode_f
> >>>>>> unsigned long vclk_rate;
> >>>>>> unsigned int bpp;
> >>>>>>
> >>>>>> - clk_set_rate(dsi->vclk, mode_freq * KILO);
> >>>>>> - vclk_rate = clk_get_rate(dsi->vclk);
> >>>>>> + clk_set_rate(dsi->vclk[dsi->vclk_idx], mode_freq * KILO);
> >>>>>> + vclk_rate = clk_get_rate(dsi->vclk[dsi->vclk_idx]);
> >>>>>> if (vclk_rate != mode_freq * KILO)
> >>>>>> dev_dbg(dsi->dev, "Requested vclk rate %lu, actual %lu mismatch\n",
> >>>>>> mode_freq * KILO, vclk_rate);
> >>>>>> @@ -687,6 +690,19 @@ static int rzv2h_mipi_dsi_dphy_init(struct rzg2l_mipi_dsi *dsi,
> >>>>>> rzg2l_mipi_dsi_phy_write(dsi, PLLCLKSET1R,
> >>>>>> FIELD_PREP(PLLCLKSET1R_PLL_K, dsi_parameters->k));
> >>>>>>
> >>>>>> + /*
> >>>>>> + * From RZ/G3E HW manual (Rev.1.15) section 9.5.3 Operation,
> >>>>>> + * 9.5.3.1 Power on Reset and Initial Settings for All Operations.
> >>>>>> + * Figure 9.5-4 Power On/Off Sequence show that after writing to
> >>>>>> + * GPO0R.VICH register we need to wait for more than 1 x tp before
> >>>>>> + * writing to PLLENR.PLLEN.
> >>>>>> + *
> >>>>>> + * Note: GPO0R is a link register, not a PHY register. This setting
> >>>>>> + * is specific to RZ/G3E.
> >>>>>> + */
> >>>>>> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R)
> >>>>>> + rzg2l_mipi_dsi_link_write(dsi, GPO0R, dsi->vclk_idx);
> >>>>>> +
> >>>>>> /*
> >>>>>> * From RZ/V2H HW manual (Rev.1.20) section 9.5.3 Operation,
> >>>>>> * (C) After write to D-PHY registers we need to wait for more than 1 x tp
> >>>>>> @@ -1005,6 +1021,37 @@ static int rzg2l_mipi_dsi_stop_video(struct rzg2l_mipi_dsi *dsi)
> >>>>>> return ret;
> >>>>>> }
> >>>>>>
> >>>>>> +static int rzg2l_mipi_dsi_get_input_port(struct rzg2l_mipi_dsi *dsi)
> >>>>>> +{
> >>>>>> + struct device_node *np = dsi->dev->of_node;
> >>>>>> + struct device_node *remote_ep, *ep_node;
> >>>>>> + struct of_endpoint ep;
> >>>>>> + bool ep_enabled;
> >>>>>> + int in_port;
> >>>>>> +
> >>>>>> + /* DSI can have only one port enabled */
> >>>>>
> >>>>> Why is that ? The hardware supports dynamic input selection, why can't
> >>>>> it be supported at runtime ?
> >>>>
> >>>> For runtime/dynamic you mean using DT overlay??
> >>>> like, remove:
> >>>>
> >>>> Removing - DU0 --> DSI (input 0 | port@0 ) overlay and
> >>>> install - DU1 --> DSI (input 1 | port@1 ) overlay and
> >>>> viceversa?
> >>>
> >>> No, I mean configurable by userspace, with two CRTCs sharing one DSI
> >>> encoder.
> >>
> >> Sorry, question:
> >> - Is it possible to create CRTC from user space?
> >
> > No, the CRTCs are created by the driver, but you can have one DRM device
> > that covers two LCDCs, with one CRTC each, both connected to the same
> > DSI encoder (and apparently this applies to the LVDS encoder too).
> > Userspace then selects which CRTC drives which connector.
>
> Which user space tool would you suggest I use for testing this?
I usually use kmstest, part of https://github.com/tomba/kmsxx/. The
modetest application from libdrm should work fine too. This is standard
KMS API.
> And also, which user space tool is the user supposed to use at
> runtime on his final/production system to perform that selection?
Any compositor should support this. Multiple CRTCs with configurable
routing towards connectors is very standard.
> >> From hardware point only one DSI input is selectable out of 2 LCDC's at
> >> a time.
> >>
> >> References:
> >> - 9.5.2.2.3 9.5 MIPI DSI Interface (DSI)
> >> General Purpose Output 0 Register (DSI_LINK_GPO0R)
> >>
> >> - 9.5 MIPI DSI Interface (DSI)
> >> 9.5.1.2 Block Diagram
> >> Figure 9.5-1 Video Input Interface
> >>
> >>>>>> + for_each_endpoint_of_node(np, ep_node) {
> >>>>>> + of_graph_parse_endpoint(ep_node, &ep);
> >>>>>> + if (ep.port >= RZ_MIPI_DSI_MAX_INPUT)
> >>>>>> + break;
> >>>>>> +
> >>>>>> + remote_ep = of_graph_get_remote_endpoint(ep_node);
> >>>>>> + ep_enabled = of_device_is_available(remote_ep);
> >>>>>> + of_node_put(remote_ep);
> >>>>>> +
> >>>>>> + if (ep_enabled) {
> >>>>>> + in_port = ep.port;
> >>>>>> + break;
> >>>>>> + }
> >>>>>> + }
> >>>>>> +
> >>>>>> + if (!ep_enabled)
> >>>>>> + return -EINVAL;
> >>>>>> +
> >>>>>> + dev_dbg(dsi->dev, "input port@%d\n", in_port);
> >>>>>> + return in_port;
> >>>>>> +}
> >>>>>> +
> >>>>>> /* -----------------------------------------------------------------------------
> >>>>>> * Bridge
> >>>>>> */
> >>>>>> @@ -1425,9 +1472,21 @@ static int rzg2l_mipi_dsi_probe(struct platform_device *pdev)
> >>>>>> if (IS_ERR(dsi->mmio))
> >>>>>> return PTR_ERR(dsi->mmio);
> >>>>>>
> >>>>>> - dsi->vclk = devm_clk_get(dsi->dev, "vclk");
> >>>>>> - if (IS_ERR(dsi->vclk))
> >>>>>> - return PTR_ERR(dsi->vclk);
> >>>>>> + dsi->vclk[0] = devm_clk_get(dsi->dev, "vclk");
> >>>>>> + if (IS_ERR(dsi->vclk[0]))
> >>>>>> + return PTR_ERR(dsi->vclk[0]);
> >>>>>> +
> >>>>>> + if (dsi->info->features & RZ_MIPI_DSI_FEATURE_GPO0R) {
> >>>>>> + dsi->vclk[1] = devm_clk_get(dsi->dev, "vclk2");
> >>>>>> + if (IS_ERR(dsi->vclk[1]))
> >>>>>> + return PTR_ERR(dsi->vclk[1]);
> >>>>>> +
> >>>>>> + ret = rzg2l_mipi_dsi_get_input_port(dsi);
> >>>>>> + if (ret < 0)
> >>>>>> + return dev_err_probe(dsi->dev, -EINVAL,
> >>>>>> + "No available input port\n");
> >>>>>> + dsi->vclk_idx = ret;
> >>>>>> + }
> >>>>>>
> >>>>>> dsi->lpclk = devm_clk_get(dsi->dev, "lpclk");
> >>>>>> if (IS_ERR(dsi->lpclk))
> >>>>>> diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> >>>>>> index 2bef20566648..cee2e0bc5dc5 100644
> >>>>>> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> >>>>>> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_mipi_dsi_regs.h
> >>>>>> @@ -83,6 +83,9 @@
> >>>>>> #define LINKSR_SQCHRUN1 BIT(4)
> >>>>>> #define LINKSR_SQCHRUN0 BIT(0)
> >>>>>>
> >>>>>> +/* RZ/G3E General Purpose Output 0 Register */
> >>>>>> +#define GPO0R 0xc0
> >>>>>> +
> >>>>>> /* Tx Set Register */
> >>>>>> #define TXSETR 0x100
> >>>>>> #define TXSETR_NUMLANECAP (0x3 << 16)
--
Regards,
Laurent Pinchart
^ 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