* [PATCH v1 4/9] ARM: tegra: grouper: Add support for front camera
From: Svyatoslav Ryhel @ 2026-04-06 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
Add front camera video path.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../tegra30-asus-nexus7-grouper-common.dtsi | 128 ++++++++++++++++++
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 4 +-
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 4 +-
3 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
index 15f53babdc21..892d718294dd 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
@@ -2,6 +2,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/power/summit,smb347-charger.h>
#include <dt-bindings/thermal/thermal.h>
@@ -84,6 +85,93 @@ init-mode-hog {
};
};
+ host1x@50000000 {
+ vi@54080000 {
+ status = "okay";
+
+ csi@800 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+
+ /* CSI-A */
+ channel@0 {
+ reg = <0>;
+
+ nvidia,mipi-calibrate = <&csi 0>; /* CSIA pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csia_input: endpoint {
+ data-lanes = <1 2>;
+ /* No rear camera */
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csia_output: endpoint {
+ remote-endpoint = <&vi_ppa_input>;
+ };
+ };
+ };
+
+ /* CSI-B */
+ channel@1 {
+ reg = <1>;
+
+ nvidia,mipi-calibrate = <&csi 1>; /* CSIB pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csib_input: endpoint {
+ data-lanes = <3>;
+ remote-endpoint = <&front_camera_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csib_output: endpoint {
+ remote-endpoint = <&vi_ppb_input>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_ppa_input: endpoint {
+ remote-endpoint = <&csia_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vi_ppb_input: endpoint {
+ remote-endpoint = <&csib_output>;
+ };
+ };
+ };
+ };
+ };
+
pinmux@70000868 {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
@@ -890,6 +978,36 @@ light-sensor@1c {
vdd-supply = <&vdd_3v3_sys>;
};
+ /* Aptina 1/6" HD SOC (MI1040) */
+ front-camera@48 {
+ compatible = "aptina,mi1040";
+ reg = <0x48>;
+
+ clocks = <&tegra_car TEGRA30_CLK_CSUS>;
+
+ reset-gpios = <&gpio TEGRA_GPIO(O, 0) GPIO_ACTIVE_LOW>;
+
+ vddio-supply = <&avdd_cam1>;
+ vdd-supply = <&vddio_cam>;
+ vaa-supply = <&avdd_cam1>;
+
+ orientation = <0>; /* Front camera */
+
+ assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
+ <&tegra_car TEGRA30_CLK_CSUS>;
+ assigned-clock-rates = <24000000>;
+ assigned-clock-parents = <&tegra_car TEGRA30_CLK_PLL_P>,
+ <&tegra_car TEGRA30_CLK_VI_SENSOR>;
+
+ port {
+ front_camera_output: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ link-frequencies = /bits/ 64 <384000000>;
+ remote-endpoint = <&csib_input>;
+ };
+ };
+ };
+
accelerometer@68 {
compatible = "invensense,mpu6050";
reg = <0x68>;
@@ -1203,6 +1321,16 @@ vcc_3v3_ts: regulator-ts {
vin-supply = <&vdd_5v0_sys>;
};
+ avdd_cam1: regulator-vcam1 {
+ compatible = "regulator-fixed";
+ regulator-name = "avdd_cam1";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ gpio = <&gpio TEGRA_GPIO(R, 6) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_5v0_sys>;
+ };
+
sound {
compatible = "nvidia,tegra-audio-rt5640-grouper",
"nvidia,tegra-audio-rt5640";
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
index 694c7fe37eb8..4bd98935031b 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
@@ -135,7 +135,7 @@ ldo4 {
regulator-boot-on;
};
- ldo5 {
+ vddio_cam: ldo5 {
regulator-name = "vdd_camera";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
@@ -149,7 +149,7 @@ ldo6 {
regulator-boot-on;
};
- ldo7 {
+ avdd_dsi_csi: ldo7 {
regulator-name = "avdd_dsi_csi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
index ee4a3f482769..8fe3c62c9052 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
@@ -92,13 +92,13 @@ ldo4 {
regulator-always-on;
};
- ldo5 {
+ vddio_cam: ldo5 {
regulator-name = "vddio_sdmmc,avdd_vdac";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- ldo6 {
+ avdd_dsi_csi: ldo6 {
regulator-name = "avdd_dsi_csi,pwrdet_mipi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 3/9] ARM: tegra: p880: Lower CPU thermal limit
From: Svyatoslav Ryhel @ 2026-04-06 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
From: Ion Agorria <ion@agorria.com>
Lower the CPU thermal limit for the LG P880, since its chassis has less
thermal dissipation capability than the P895.
Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
index 1b21d7628c8c..6b30e17459ac 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
@@ -537,4 +537,17 @@ sound {
nvidia,int-mic-en-gpios = <&gpio TEGRA_GPIO(I, 6) GPIO_ACTIVE_HIGH>;
};
+
+ thermal-zones {
+ cpu-thermal {
+ trips {
+ cpu-alert {
+ /* throttle at 60C until temperature drops to 59.8C */
+ temperature = <60000>;
+ hysteresis = <200>;
+ type = "passive";
+ };
+ };
+ };
+ };
};
--
2.51.0
^ permalink raw reply related
* [PATCH v1 2/9] ARM: tegra: lg-x3: Set PMIC's RTC address
From: Svyatoslav Ryhel @ 2026-04-06 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
LG X3 devices have the PMIC's RTC module located at a non-standard
address. Set the correct address.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
index d2a5904cebed..60e8a19aa70e 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
@@ -1297,7 +1297,8 @@ pwr_i2c: i2c@7000d000 {
pmic: max77663@1c {
compatible = "maxim,max77663";
- reg = <0x1c>;
+ reg = <0x1c>, <0x48>;
+ reg-names = "pmic", "rtc";
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <2>;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 1/9] ARM: tegra: lg-x3: Complete video device graph
From: Svyatoslav Ryhel @ 2026-04-06 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
Add front and rear camera nodes and interlink them with Tegra CSI and VI.
Adjust camera PMIC voltages to better fit requirements and fix the focuser
node.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 28 ++++
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 46 ++++++
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 154 +++++++++++++++++--
3 files changed, 214 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
index cc14e6dca770..1b21d7628c8c 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts
@@ -12,6 +12,18 @@ aliases {
mmc2 = &sdmmc1; /* WiFi */
};
+ host1x@50000000 {
+ vi@54080000 {
+ csi@800 {
+ /delete-node/ channel@1;
+ };
+
+ ports {
+ /delete-node/ port@1;
+ };
+ };
+ };
+
pinmux@70000868 {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
@@ -116,6 +128,22 @@ rmi4-f11@11 {
};
};
+ i2c@7000c500 {
+ camera-pmic@7d {
+ vt_1v2_front: ldo1 {
+ regulator-name = "vt_1v2_dig";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ vt_2v7_front: ldo2 {
+ regulator-name = "vt_2v7_vana";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <2700000>;
+ };
+ };
+ };
+
spi@7000dc00 {
dsi@2 {
/*
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
index 414117fd4382..896639599c12 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
@@ -118,6 +118,52 @@ rmi4-f1a@1a {
};
};
+ i2c@7000c500 {
+ /* Aptina 1/6" HD SOC (MT9M114) */
+ front-camera@48 {
+ compatible = "onnn,mt9m114";
+ reg = <0x48>;
+
+ clocks = <&tegra_car TEGRA30_CLK_CSUS>;
+
+ reset-gpios = <&gpio TEGRA_GPIO(BB, 5) GPIO_ACTIVE_LOW>;
+
+ vddio-supply = <&vio_1v8_front>;
+ vdd-supply = <&vt_1v8_front>;
+ vaa-supply = <&vt_2v8_front>;
+
+ orientation = <0>; /* Front camera */
+
+ assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
+ <&tegra_car TEGRA30_CLK_CSUS>;
+ assigned-clock-rates = <24000000>;
+ assigned-clock-parents = <&tegra_car TEGRA30_CLK_PLL_P>,
+ <&tegra_car TEGRA30_CLK_VI_SENSOR>;
+
+ port {
+ front_camera_output: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ link-frequencies = /bits/ 64 <384000000>;
+ remote-endpoint = <&csib_input>;
+ };
+ };
+ };
+
+ camera-pmic@7d {
+ vt_1v8_front: ldo1 {
+ regulator-name = "vt_1v8_dig";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ vt_2v8_front: ldo2 {
+ regulator-name = "vt_2v8_vana";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+ };
+ };
+ };
+
spi@7000dc00 {
dsi@2 {
/*
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
index 768e201456d8..d2a5904cebed 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
@@ -3,6 +3,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/mfd/max77620.h>
#include <dt-bindings/thermal/thermal.h>
@@ -74,6 +75,91 @@ trustzone@bfe00000 {
};
host1x@50000000 {
+ vi@54080000 {
+ status = "okay";
+
+ csi@800 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+
+ /* CSI-A */
+ channel@0 {
+ reg = <0>;
+
+ nvidia,mipi-calibrate = <&csi 0>; /* CSIA pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csia_input: endpoint {
+ data-lanes = <1 2>;
+ remote-endpoint = <&rear_camera_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csia_output: endpoint {
+ remote-endpoint = <&vi_ppa_input>;
+ };
+ };
+ };
+
+ /* CSI-B */
+ channel@1 {
+ reg = <1>;
+
+ nvidia,mipi-calibrate = <&csi 1>; /* CSIB pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csib_input: endpoint {
+ data-lanes = <3>;
+ remote-endpoint = <&front_camera_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csib_output: endpoint {
+ remote-endpoint = <&vi_ppb_input>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_ppa_input: endpoint {
+ remote-endpoint = <&csia_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vi_ppb_input: endpoint {
+ remote-endpoint = <&csib_output>;
+ };
+ };
+ };
+ };
+
lcd: dc@54200000 {
rgb {
status = "okay";
@@ -1112,29 +1198,68 @@ dw9714: coil@c {
compatible = "dongwoon,dw9714";
reg = <0x0c>;
- enable-gpios = <&gpio TEGRA_GPIO(R, 1) GPIO_ACTIVE_HIGH>;
+ powerdown-gpios = <&gpio TEGRA_GPIO(R, 1) GPIO_ACTIVE_LOW>;
vcc-supply = <&vcc_focuser>;
};
+ /* SONY IMX111 1/4" BSI */
+ rear-camera@10 {
+ compatible = "sony,imx111";
+ reg = <0x10>;
+
+ clocks = <&tegra_car TEGRA30_CLK_CSUS>;
+
+ reset-gpios = <&gpio TEGRA_GPIO(K, 4) GPIO_ACTIVE_LOW>;
+
+ iovdd-supply = <&vio_1v8_rear>;
+ dvdd-supply = <&vdd_1v2_rear>;
+ avdd-supply = <&vdd_2v7_rear>;
+
+ orientation = <1>; /* Rear camera */
+ rotation = <90>;
+
+ nvmem = <&m24c08>;
+ lens-focus = <&dw9714>;
+
+ assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
+ <&tegra_car TEGRA30_CLK_CSUS>;
+ assigned-clock-rates = <24000000>;
+ assigned-clock-parents = <&tegra_car TEGRA30_CLK_PLL_P>,
+ <&tegra_car TEGRA30_CLK_VI_SENSOR>;
+
+ port {
+ rear_camera_output: endpoint {
+ data-lanes = <1 2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ link-frequencies = /bits/ 64 <542400000>;
+ remote-endpoint = <&csia_input>;
+ };
+ };
+ };
+
+ /* rear camera sensor eeprom m24c08 from ST */
+ m24c08: eeprom@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+
+ /* if high then WP is on, if low then off */
+ wp-gpios = <&gpio TEGRA_GPIO(K, 3) GPIO_ACTIVE_HIGH>;
+
+ /* it is not OTP but writing is unwanted */
+ read-only;
+ pagesize = <16>;
+ num-addresses = <1>;
+
+ vcc-supply = <&vio_1v8_rear>;
+ };
+
camera-pmic@7d {
compatible = "ti,lp8720";
reg = <0x7d>;
enable-gpios = <&gpio TEGRA_GPIO(BB, 4) GPIO_ACTIVE_HIGH>;
- vt_1v2_front: ldo1 {
- regulator-name = "vt_1v2_dig";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- };
-
- vt_2v7_front: ldo2 {
- regulator-name = "vt_2v7_vana";
- regulator-min-microvolt = <2700000>;
- regulator-max-microvolt = <2700000>;
- };
-
vdd_2v7_rear: ldo3 {
regulator-name = "8m_2v7_vana";
regulator-min-microvolt = <2700000>;
@@ -1348,10 +1473,11 @@ vdd_1v2_mhl: ldo7 {
maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
};
- ldo8 {
+ avdd_dsi_csi: ldo8 {
regulator-name = "avdd_dsi_csi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
+ regulator-boot-on;
maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
};
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/9] ARM: tegra: complete a few Tegra30 device trees
From: Svyatoslav Ryhel @ 2026-04-06 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
Configure camera support for ASUS Transformers, Google Nexus 7 and
LG X3 devices. Fix RTC on LG X3 devices. Lower throttling temperature
for LG P880. Add panel support for TF600T.
Ion Agorria (1):
ARM: tegra: p880: Lower CPU thermal limit
Svyatoslav Ryhel (8):
ARM: tegra: lg-x3: Complete video device graph
ARM: tegra: lg-x3: Set PMIC's RTC address
ARM: tegra: grouper: Add support for front camera
ARM: tegra: transformer: Add support for front camera
ARM: tegra: transformers: Add connector node for common trees
ARM: tegra: tf600t: Configure panel
ARM: tegra: tf600t: Drop backlight regulator
ARM: tegra: tf600t: Invert accelerometer calibration matrix
.../tegra20-asus-transformer-common.dtsi | 22 ++-
.../tegra30-asus-nexus7-grouper-common.dtsi | 128 ++++++++++++++
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 4 +-
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 4 +-
.../boot/dts/nvidia/tegra30-asus-tf600t.dts | 71 ++++++--
.../tegra30-asus-transformer-common.dtsi | 159 +++++++++++++++++-
arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 41 +++++
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 46 +++++
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 157 +++++++++++++++--
9 files changed, 595 insertions(+), 37 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
From: tessolveupstream @ 2026-04-06 8:32 UTC (permalink / raw)
To: Luca Ceresoli, andrzej.hajda, neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
marex, valentin, philippe.schenker, dri-devel, linux-kernel,
devicetree
In-Reply-To: <DH5S3RB2XZ31.3C994FZK5U4OV@bootlin.com>
On 18-03-2026 14:22, Luca Ceresoli wrote:
> Hello Sudarshan,
>
> On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>>> + if (ctx->dual_link_video_mode) {
>>>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>>>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>>>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>>>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>>>> + }
>>>
>>> I guess these hard-coded values are sepcific to your panel. They must
>>> instead be computed based on the timings in order to work for every panel.
>>>
>>
>> The hard-coded values were initially derived from the TI DSI Tuner output
>> during our bring-up testing. TI had also mentioned that when PATGEN is
>> enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
>> must be divided by 2. They also noted that the current driver does not
>> appear to divide the horizontal timings when PATGEN is enabled in
>> dual-LVDS mode.
>>
>> Based on that suggestion, we had tried adjusting the horizontal timing
>> registers accordingly to match the tuner output.
>> Could you please advise how these register values are expected to be
>> derived from the mode timings so that they work correctly for different
>> panels?
>
> Well, the principle is quite simple:
>
> 1. the panel docs tell you which timings the panel needs, e.g. HBP must be
> 10 clock cycles
>
> 2. your panel description in dts or implementation in a panel driver will
> then be written accordingly
>
> 3. the ti-sn65dsi83 driver will receive a struct drm_display_mode* with
> these values
>
> 4. based on those values it sets the registers so the SN65DSI84 uses the
> timings required by the panel (with a bit of math if needed):
>
> regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> mode->htotal - mode->hsync_end);
>
> Same for all other timings.
>
> Ti is more complicated if more cases need to be handled, such as dual-LVDS,
> and the chip documentation is vague about what must be done in those cases.
>
> I suggested next steps to move forward in reply to the cover letter.
>
Thank you so much for your suggestion.
>>>> @@ -965,9 +1001,15 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
>>>>
>>>> dsi->lanes = dsi_lanes;
>>>> dsi->format = MIPI_DSI_FMT_RGB888;
>>>> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>>>> - MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>>>> + if (ctx->dual_link_video_mode)
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>>>> + else
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>>> + MIPI_DSI_MODE_VIDEO_BURST |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>>>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>>>
>>> There is no explanation about this, can you elaborate on why?
>>>
>>> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
>>> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
>>> no idea why. Should you have any info, maybe from TI, it would be very
>>> interesting.
>>>
>>
>> During our earlier bring-up, TI mentioned that one possible reason for the DSI
>> REFCLK not behaving as expected could be that the DSI output is configured in
>> burst mode instead of non-burst mode. In burst mode the DSI clock may not be
>> continuous, whereas non-burst mode provides a more predictable DSI clock.
>
> Uhm, this is a bit vague. They basically said "burst can be more
> problematic than continuous", which is obvious, and "try disabling burst
> and see whether it helps" with no explanation on why one works and not the
> other. Shoudl you have more info from them you'd be welcome to share it. In
> particular, is disabling burst mode specifically related to dual-LVDS, or
> just a way to (try to) get rid of some problems without a clear
> understanding?
>
> On my side I also have a dual-LVDS panel connected to a SN65DSI84, which
> works only by disabling burst mode. I haven't tried upstreaming it because
> I don't have an explanation of why it fixes the panel and so I have no idea
> how to teach the driver when it should disable burst mode.
>
> Additionally inyour patch you remove many other flags. Any explanation from
> those?
>
Thanks for your inputs.
I wanted to share a quick observation from our side. With your suggested 3
patches (links below), the panel started working after simplifying the
dsi-> mode_flags:
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
Earlier configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
Working configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
MIPI_DSI_MODE_NO_EOT_PACKET;
From our testing, removing MIPI_DSI_MODE_VIDEO_BURST along with the NO_HFP/NO_HBP
flags results in stable LVDS output in dual-link mode.
Could you please suggest how you would prefer to handle this change for
upstreaming?
> Best regards,
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 2/4] platform: arm64: dell-xps-ec: new driver
From: Bryan O'Donoghue @ 2026-04-06 8:30 UTC (permalink / raw)
To: Aleksandrs Vinarskis
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans de Goede, Ilpo Järvinen, linux-arm-msm,
devicetree, linux-kernel, platform-driver-x86, laurentiu.tudor1,
Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <P9IQ5Penud7CH3Yfn0bw0RXJfIhFhFGksRjP-aZwLoAxmajMfeOtLEItrcWOXwVjHE_zObIA8SYjcPVR9dkAk9KgDYLun0DJJ6dBIU-IRDI=@vinarskis.com>
On 05/04/2026 21:48, Aleksandrs Vinarskis wrote:
> On Sunday, April 5th, 2026 at 02:29, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
>
>> On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
>>> Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
>>> partially of fully compatible with Snapdragon-based Dell Latitude,
>>> Inspiron ('thena'). Primary function of this driver is unblock EC's
>>> thermal management, specifically to provide it with necessary
>>> information to control device fans, peripherals power.
>>>
>>> The driver was developed primarily by analyzing ACPI DSDT's _DSM and
>>> i2c dumps of communication between SoC and EC. Changes to Windows
>>> driver's behavior include increasing temperature feed loop from ~50ms
>>> to 100ms here.
>>>
>>> While Xps's EC is rather complex and controls practically all device
>>> peripherals including touch row's brightness and special keys such as
>>> mic mute, these do not go over this particular i2c interface.
>>>
>>> Not yet implemented features:
>>> - On lid-close IRQ event is registered. Windows performs what to
>>> appears to be thermistor constants readout, though its not obvious
>>> what it used for.
>>> - According to ACPI's _DSM there is a method to readout fans' RPM.
>>> - Initial thermistor constants were sniffed from Windows, these can be
>>> likely fine tuned for better cooling performance.
>>> - There is additional temperature reading that Windows sents to EC but
>>> more rare than others, likely SoC T_j / TZ98 or TZ4. This is the only
>>> thermal zone who's reading can exceed 115C without triggering thermal
>>> shutdown.
>>> - Given similarities between 'tributo' and 'thena' platforms, including
>>> EC i2c address, driver can be potentially extended to support both.
>>>
>>> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
>>> ---
>>> MAINTAINERS | 1 +
>>> drivers/platform/arm64/Kconfig | 12 ++
>>> drivers/platform/arm64/Makefile | 1 +
>>> drivers/platform/arm64/dell-xps-ec.c | 267 +++++++++++++++++++++++++++++++++++
>>> 4 files changed, 281 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index a5d175559f4468dfe363b319a1b08d3425f4d712..c150f57b60706224e5b24b0dfb3d8a9b81f36398 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7240,6 +7240,7 @@ DELL XPS EMBEDDED CONTROLLER DRIVER
>>> M: Aleksandrs Vinarskis <alex@vinarskis.com>
>>> S: Maintained
>>> F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
>>> +F: drivers/platform/arm64/dell-xps-ec.c
>>>
>>> DELTA AHE-50DC FAN CONTROL MODULE DRIVER
>>> M: Zev Weiss <zev@bewilderbeest.net>
>>> diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
>>> index 10f905d7d6bfa5fad30a0689d3a20481268c781e..0bc8f016032bb05cb3a7cc50bdf1092da04153bc 100644
>>> --- a/drivers/platform/arm64/Kconfig
>>> +++ b/drivers/platform/arm64/Kconfig
>>> @@ -33,6 +33,18 @@ config EC_ACER_ASPIRE1
>>> laptop where this information is not properly exposed via the
>>> standard ACPI devices.
>>>
>>> +config EC_DELL_XPS
>>> + tristate "Dell XPS 9345 Embedded Controller driver"
>>> + depends on ARCH_QCOM || COMPILE_TEST
>>> + depends on I2C
>>> + depends on IIO
>>> + help
>>> + Driver for the Embedded Controller in the Qualcomm Snapdragon-based
>>> + Dell XPS 13 9345, which handles thermal management and fan speed
>>> + control.
>>> +
>>> + Say M or Y here to include this support.
>>> +
>>> config EC_HUAWEI_GAOKUN
>>> tristate "Huawei Matebook E Go Embedded Controller driver"
>>> depends on ARCH_QCOM || COMPILE_TEST
>>> diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
>>> index 60c131cff6a15bb51a49c9edab95badf513ee0f6..6768dc6c2310837374e67381cfc729bed1fdaaef 100644
>>> --- a/drivers/platform/arm64/Makefile
>>> +++ b/drivers/platform/arm64/Makefile
>>> @@ -6,6 +6,7 @@
>>> #
>>>
>>> obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
>>> +obj-$(CONFIG_EC_DELL_XPS) += dell-xps-ec.o
>>> obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
>>> obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
>>> obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
>>> diff --git a/drivers/platform/arm64/dell-xps-ec.c b/drivers/platform/arm64/dell-xps-ec.c
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..bf1495fbe473ccdb82b95a66b56e8525f782cc8e
>>> --- /dev/null
>>> +++ b/drivers/platform/arm64/dell-xps-ec.c
>>> @@ -0,0 +1,267 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) 2026, Aleksandrs Vinarskis <alex@vinarskis.com>
>>> + */
>>> +
>>> +#include <linux/array_size.h>
>>> +#include <linux/dev_printk.h>
>>> +#include <linux/device.h>
>>> +#include <linux/devm-helpers.h>
>>> +#include <linux/err.h>
>>> +#include <linux/i2c.h>
>>> +#include <linux/iio/consumer.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/jiffies.h>
>>> +#include <linux/module.h>
>>> +#include <linux/pm.h>
>>> +#include <linux/unaligned.h>
>>> +#include <linux/workqueue.h>
>>> +
>>> +#define DELL_XPS_EC_SUSPEND_CMD 0xb9
>>> +#define DELL_XPS_EC_SUSPEND_MSG_LEN 64
>>> +
>>> +#define DELL_XPS_EC_TEMP_CMD0 0xfb
>>> +#define DELL_XPS_EC_TEMP_CMD1 0x20
>>> +#define DELL_XPS_EC_TEMP_CMD3 0x02
>>> +#define DELL_XPS_EC_TEMP_MSG_LEN 6
>>> +#define DELL_XPS_EC_TEMP_POLL_JIFFIES msecs_to_jiffies(100)
>>> +
>>> +/*
>>> + * Format:
>>> + * - header/unknown (2 bytes)
>>> + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
>>> + */
>>> +static const u8 dell_xps_ec_thermistor_profile[] = {
>>> + 0xff, 0x54,
>>> + 0x01, 0x00, 0x2b, /* sys_therm0 */
>>> + 0x02, 0x44, 0x2a, /* sys_therm1 */
>>> + 0x03, 0x44, 0x2b, /* sys_therm2 */
>>> + 0x04, 0x44, 0x28, /* sys_therm3 */
>>> + 0x05, 0x55, 0x2a, /* sys_therm4 */
>>> + 0x06, 0x44, 0x26, /* sys_therm5 */
>>> + 0x07, 0x44, 0x2b, /* sys_therm6 */
>>> +};
>>> +
>>> +/*
>>> + * Mapping from IIO channel name to EC command byte
>>> + */
>>> +static const struct {
>>> + const char *name;
>>> + u8 cmd;
>>> +} dell_xps_ec_therms[] = {
>>> + /* TODO: 0x01 is sent only occasionally, likely TZ98 or TZ4 */
>>> + { "sys_therm0", 0x02 },
>>> + { "sys_therm1", 0x03 },
>>> + { "sys_therm2", 0x04 },
>>> + { "sys_therm3", 0x05 },
>>> + { "sys_therm4", 0x06 },
>>> + { "sys_therm5", 0x07 },
>>> + { "sys_therm6", 0x08 },
>>> +};
>>
>> You could probably retrieve these strings from the dt if you really need
>> them.
>>
>> I don't think you need static consts in your driver though you could
>> just as easily do `sprintf("sys_therm%d\n", i) where you use
>> ec_therms[i].name - the name is only used to print errors and you have
>> the index of the channel when you do.
>>
>> It would be nicer to get the strings from DT - certainly make the string
>> names mandatory but, then let the DT specify those names.
>>
>> Either that or just do the sprintf("sys_therm%d\n", i); for the index,
>> whichever you wish yourself.
>
> Hi Bryan,
>
> Will answer here to all three comments about `sys_thermX`.
>
> The reason I have added them as static consts here, and defined them in
> the schema is because the order of the channels matters:
Two different things.
You have an array of strings here which you only use to print two error
messages, you always know the index, so you don't need those strings.
At the same time, you could read the assigned names in the DT if you
_really_ care to print the names.
You don't match the static names in the .c file to the .dts so the
consts here serve no purpose.
Ideally you'd read the names out of DT - which is what I recommend. You
then print the name you read from the DT via an index.
> 1. On my XPS (UEFI v2.11.0) changes in sys_therm2 immediately result in
> changes in fan speeds. Other channels seemingly have no affect, at
> least when spoofed one by one, implying that EC cares which value
> is which.
> 2. As I do not know internals of the EC firmware, even if today the other
> thermistor channels ordering is seemingly not relevant, we cannot be
> sure it will not change with EC firmware upgrade.
But the PCB maps certain ADC channels to certain thermistors the lpddr5
thermistor always maps to the lpddr5 thermistor and adc input 0 on the
EC, that won't change with a firmware upgrade, the PCB is the PCB.
> I have reconstructed the order of channels by comparing i2c data dumps
> and real-time temps on Windows, eg. sys_therm0 is sent to EC under id 0x02
> and represents the TZ71 (around dram on XPS). There is no other reason to
> have the names of the channels in this driver except for enforcing the
> channel mapping, so `sprintf("sys_therm%d\n", i)` wouldn't be useful.
>
> By allowing source and sink to define the names and not enforcing it in
> schema we lose ability to force the correct order, there is no way of
> knowing whether "lpddr5-therm" or "ssd-therm" goes first.
But there is, by looking at the schematics. You have the correct order
now and it maps to what the schematics say, I checked.
By forcing
> "sys_thermX" convention, one would need to figure which one is which,
> for example by referring to laptop schematics. I assume, "thena"'s
> schematics has thermistors labeled as "sys_thermX"?
>
> I do agree that labels of the ADC nodes could be more useful for the
> user. So far I followed the example of sc8280xp platforms that define
> ADC channels with "sys_thermX". Perhaps, we could separate the
> io-channel-names and ADC node labels then? eg:
I mean it doesn't matter a whole lot to me how the source and the sink
connect in DT.
BTW if we denoted the source and the sink lpddr5 today and the firmware
was changed the name of the mapping would be wrong but the functional
conneciton would still be correct.
So I'm not very concerned about source/sink names, its a bike shed
> + io-channel-names = "sys_therm0",
> + "sys_therm1",
> ...
>
> + &pmk8550_vadc {
> + sys_therm0: channel@14c {
> + reg = <PM8350_ADC7_GPIO3_100K_PU(1)>;
> + qcom,hw-settle-time = <200>;
> + qcom,ratiometric;
> + label = "lpddr5x-therm";
>
> Though not sure if such approach is 'legal'?
I mean the important thing is what user-space "sees" right ? I believe
the label here is that but, please check.
A list of sys_therm0 entries in the dropdown from waybar is 100% meh,
but if I can see "CPU temp" spike I suddenly have useful information.
>
> Alex
>
>>
>>> +
>>> +struct dell_xps_ec {
>>> + struct device *dev;
>>> + struct i2c_client *client;
>>> + struct iio_channel *therm_channels[ARRAY_SIZE(dell_xps_ec_therms)];
>>> + struct delayed_work temp_work;
>>> +};
>>> +
>>> +static int dell_xps_ec_suspend_cmd(struct dell_xps_ec *ec, bool suspend)
>>> +{
>>> + u8 buf[DELL_XPS_EC_SUSPEND_MSG_LEN] = {};
>>> + int ret;
>>> +
>>> + buf[0] = DELL_XPS_EC_SUSPEND_CMD;
>>> + buf[1] = suspend ? 0x01 : 0x00;
>>> + /* bytes 2..63 remain zero */
>>> +
>>> + ret = i2c_master_send(ec->client, buf, sizeof(buf));
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int dell_xps_ec_send_temp(struct dell_xps_ec *ec, u8 cmd_byte,
>>> + int milli_celsius)
>>> +{
>>> + u8 buf[DELL_XPS_EC_TEMP_MSG_LEN];
>>> + u16 deci_celsius;
>>> + int ret;
>>> +
>>> + /* Convert milli-Celsius to deci-Celsius (Celsius * 10) */
>>> + deci_celsius = milli_celsius / 100;
>>> +
>>> + buf[0] = DELL_XPS_EC_TEMP_CMD0;
>>> + buf[1] = DELL_XPS_EC_TEMP_CMD1;
>>> + buf[2] = cmd_byte;
>>> + buf[3] = DELL_XPS_EC_TEMP_CMD3;
>>> + put_unaligned_le16(deci_celsius, &buf[4]);
>>> +
>>> + ret = i2c_master_send(ec->client, buf, sizeof(buf));
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static void dell_xps_ec_temp_work_fn(struct work_struct *work)
>>> +{
>>> + struct dell_xps_ec *ec = container_of(work, struct dell_xps_ec,
>>> + temp_work.work);
>>> + int val, ret, i;
>>> +
>>> + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
>>> + if (!ec->therm_channels[i])
>>> + continue;
>>> +
>>> + ret = iio_read_channel_processed(ec->therm_channels[i], &val);
>>> + if (ret < 0) {
>>> + dev_err_ratelimited(ec->dev,
>>> + "Failed to read thermistor %s: %d\n",
>>> + dell_xps_ec_therms[i].name, ret);
>>> + continue;
>>> + }
>>> +
>>> + ret = dell_xps_ec_send_temp(ec, dell_xps_ec_therms[i].cmd, val);
>>> + if (ret < 0) {
>>> + dev_err_ratelimited(ec->dev,
>>> + "Failed to send temp for %s: %d\n",
>>> + dell_xps_ec_therms[i].name, ret);
>>> + }
>>> + }
>>> +
>>> + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
>>> +}
>>> +
>>> +static irqreturn_t dell_xps_ec_irq_handler(int irq, void *data)
>>> +{
>>> + struct dell_xps_ec *ec = data;
>>> +
>>> + /*
>>> + * TODO: IRQ is fired on lid-close. Follow Windows example to read out
>>> + * the thermistor thresholds and potentially fan speeds.
>>> + */
>>> + dev_info_ratelimited(ec->dev, "IRQ triggered! (irq=%d)\n", irq);
>>> +
>>> + return IRQ_HANDLED;
>>> +}
>>> +
>>> +static int dell_xps_ec_probe(struct i2c_client *client)
>>> +{
>>> + struct device *dev = &client->dev;
>>> + struct dell_xps_ec *ec;
>>> + int ret, i;
>>> +
>>> + ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
>>> + if (!ec)
>>> + return -ENOMEM;
>>> +
>>> + ec->dev = dev;
>>> + ec->client = client;
>>> + i2c_set_clientdata(client, ec);
>>> +
>>> + /* Set default thermistor profile */
>>> + ret = i2c_master_send(client, dell_xps_ec_thermistor_profile,
>>> + sizeof(dell_xps_ec_thermistor_profile));
>>> + if (ret < 0)
>>> + return dev_err_probe(dev, ret, "Failed to set thermistor profile\n");
>>> +
>>> + /* Get IIO channels for thermistors */
>>> + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
>>> + ec->therm_channels[i] =
>>> + devm_iio_channel_get(dev, dell_xps_ec_therms[i].name);
>>> + if (IS_ERR(ec->therm_channels[i])) {
>>> + ret = PTR_ERR(ec->therm_channels[i]);
>>> + ec->therm_channels[i] = NULL;
>>> + if (ret == -EPROBE_DEFER)
>>> + return ret;
>>> + dev_warn(dev, "Thermistor %s not available: %d\n",
>>> + dell_xps_ec_therms[i].name, ret);
>>> + }
>>> + }
>>> +
>>> + /* Start periodic temperature reporting */
>>> + ret = devm_delayed_work_autocancel(dev, &ec->temp_work,
>>> + dell_xps_ec_temp_work_fn);
>>> + if (ret)
>>> + return ret;
>> \n
>>> + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
>>> + dev_dbg(dev, "Started periodic temperature reporting to EC every %d ms\n",
>>> + jiffies_to_msecs(DELL_XPS_EC_TEMP_POLL_JIFFIES));
>>> +
>>> + /* Request IRQ for EC events */
>>> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
>>> + dell_xps_ec_irq_handler,
>>> + IRQF_ONESHOT, dev_name(dev), ec);
>>> + if (ret < 0)
>>> + return dev_err_probe(dev, ret, "Failed to request IRQ\n");
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Notify EC of suspend
>>> + *
>>> + * This will:
>>> + * - Cut power to display/trackpad/keyboard/touchrow, wake-up source still works
>>> + */
>>> +static int dell_xps_ec_suspend(struct device *dev)
>>> +{
>>> + struct dell_xps_ec *ec = dev_get_drvdata(dev);
>>> +
>>> + cancel_delayed_work_sync(&ec->temp_work);
>>> +
>>> + return dell_xps_ec_suspend_cmd(ec, true);
>>> +}
>>> +
>>> +/*
>>> + * Notify EC of resume
>>> + *
>>> + * This will undo the suspend actions
>>> + * Without the resume signal, device would wake up but be forced back into
>>> + * suspend by EC within seconds
>>> + */
>>> +static int dell_xps_ec_resume(struct device *dev)
>>> +{
>>> + struct dell_xps_ec *ec = dev_get_drvdata(dev);
>>> + int ret;
>>> +
>>> + ret = dell_xps_ec_suspend_cmd(ec, false);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
>>> + return 0;
>>> +}
>>> +
>>> +static const struct of_device_id dell_xps_ec_of_match[] = {
>>> + { .compatible = "dell,xps13-9345-ec" },
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(of, dell_xps_ec_of_match);
>>> +
>>> +static const struct i2c_device_id dell_xps_ec_i2c_id[] = {
>>> + { "dell-xps-ec" },
>>> + {}
>>> +};
>>> +MODULE_DEVICE_TABLE(i2c, dell_xps_ec_i2c_id);
>>> +
>>> +static const struct dev_pm_ops dell_xps_ec_pm_ops = {
>>> + SYSTEM_SLEEP_PM_OPS(dell_xps_ec_suspend, dell_xps_ec_resume)
>>> +};
>>> +
>>> +static struct i2c_driver dell_xps_ec_driver = {
>>> + .driver = {
>>> + .name = "dell-xps-ec",
>>> + .of_match_table = dell_xps_ec_of_match,
>>> + .pm = &dell_xps_ec_pm_ops,
>>> + },
>>> + .probe = dell_xps_ec_probe,
>>> + .id_table = dell_xps_ec_i2c_id,
>>> +};
>>> +module_i2c_driver(dell_xps_ec_driver);
>>> +
>>> +MODULE_AUTHOR("Aleksandrs Vinarskis <alex@vinarskis.com>");
>>> +MODULE_DESCRIPTION("Dell XPS 13 9345 Embedded Controller");
>>> +MODULE_LICENSE("GPL");
>>>
>>
>>
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-04-06 8:25 UTC (permalink / raw)
To: Kuldeep Singh, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Abel Vesa, Manivannan Sadhasivam, cros-qcom-dts-watchers,
Eric Biggers, Dmitry Baryshkov, Jingyi Wang, Tengfei Fan,
Bartosz Golaszewski, David Wronek, Luca Weiss, Neil Armstrong,
Melody Olvera, Alexander Koskovich
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <2b71dd68-ff35-411e-905d-3ffa2ea3efe4@oss.qualcomm.com>
Hi Krzysztof,
May I request your review on this commit once again. Hopefully I have resolved
the issues pointed out in the previous version of this commit.
Thank you very much,
Harshal
On 3/31/2026 3:10 PM, Harshal Dev wrote:
> Hi Kuldeep,
>
> On 3/24/2026 4:16 PM, Kuldeep Singh wrote:
>>
>> On 3/23/2026 2:47 PM, Harshal Dev wrote:
>>> The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
>>> power-domain and iface clock. Without enabling the iface clock and the
>>> associated power-domain the ICE hardware cannot function correctly and
>>> leads to unclocked hardware accesses being observed during probe.
>>>
>>> Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
>>> power-domain and iface clock for new devices (Eliza and Milos) introduced
>>> in the current release (7.0) with yet-to-stabilize ABI, while preserving
>>> backward compatibility for older devices.
>>>
>>> Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
>>> Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>> ---
>>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
>>> 1 file changed, 34 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>> index 876bf90ed96e..ccb6b8dd8e11 100644
>>> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
>>> @@ -30,6 +30,16 @@ properties:
>>> maxItems: 1
>>>
>>> clocks:
>>> + minItems: 1
>>> + maxItems: 2
>>> +
>>> + clock-names:
>>> + minItems: 1
>>> + items:
>>> + - const: core
>>> + - const: iface
>>> +
>>> + power-domains:
>>> maxItems: 1
>>>
>>> operating-points-v2: true
>>> @@ -44,6 +54,25 @@ required:
>>>
>>> additionalProperties: false
>>>
>>> +allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - qcom,eliza-inline-crypto-engine
>>> + - qcom,milos-inline-crypto-engine
>>> +
>>> + then:
>>> + required:
>>> + - power-domains
>>> + - clock-names
>>> + properties:
>>> + clocks:
>>> + minItems: 2
>>> + clock-names:
>>> + minItems: 2
>>> +
>>
>> Hi Krzysztof,
>>
>> As motive here is to enforce 2 clocks for upcoming targets and keep
>> minItems as 1 for already merged ones for ensuring backward
>> compatibility. Can we do like below?
>>
>> allOf:
>> - if:
>> not:
>> properties:
>> compatible:
>> contains:
>> enum:
>> - qcom,kaanapali-inline-crypto-engine
>> - qcom,qcs8300-inline-crypto-engine
>> - qcom,sa8775p-inline-crypto-engine
>> - qcom,sc7180-inline-crypto-engine
>> - qcom,sc7280-inline-crypto-engine
>> - qcom,sm8450-inline-crypto-engine
>> - qcom,sm8550-inline-crypto-engine
>> - qcom,sm8650-inline-crypto-engine
>> - qcom,sm8750-inline-crypto-engine
>>
>> then:
>> required:
>> - power-domains
>> - clock-names
>> properties:
>> clocks:
>> minItems: 2
>> clock-names:
>> minItems: 2
>>
>> This will ensure for every new target addition, default clock count is
>> enforced as 2 default.
>> Please share your thoughts as well.
>>
>
> I don't really have any particular objections to this proposal, but I can
> see that other bindings where the need for an additional clock was realized
> later on use a similar pattern as this patchset does:
> https://elixir.bootlin.com/linux/v7.0-rc2/source/Documentation/devicetree/bindings/timer/fsl,imxgpt.yaml
>
> I'll wait for Krzysztof to take a final call on this.
>
> Regards,
> Harshal
>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: platform: introduce EC for Dell XPS 13 9345
From: Bryan O'Donoghue @ 2026-04-06 8:15 UTC (permalink / raw)
To: Aleksandrs Vinarskis
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans de Goede, Ilpo Järvinen, linux-arm-msm,
devicetree, linux-kernel, platform-driver-x86, laurentiu.tudor1,
Abel Vesa, Tobias Heider, Val Packett, Krzysztof Kozlowski
In-Reply-To: <21_zFoUYN_HKM8GMSFC7b0uIgOQevyqpWbjtIX1vVP7YtK9tlMgqC3XRgwo35ANlvZ1veGNShZuQFHkKWcf3B_qhjhD90FS7kvR3qCpKzIY=@vinarskis.com>
On 05/04/2026 21:50, Aleksandrs Vinarskis wrote:
> On Sunday, April 5th, 2026 at 02:05, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
>
>> On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
>>> Add bindings for Embedded Controller (EC) in Dell XPS 13 9345 (platform
>>> codename 'tributo'). It may be partially or fully compatible with EC
>>> found in Snapdragon-based Dell Latitude, Inspiron ('thena').
>>>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
>>> ---
>>> .../embedded-controller/dell,xps13-9345-ec.yaml | 91 ++++++++++++++++++++++
>>> MAINTAINERS | 5 ++
>>> 2 files changed, 96 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
>>> new file mode 100644
>>> index 0000000000000000000000000000000000000000..e14dbf2f1a6af8cc7511890fbef08c6c717c0aa6
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
>>
>> I believe the part name of this embedded controller is the "mec5200" so
>> instead of calling it dell,xps13-9345-ec suggest "dell,mec5200"
>
> Correct, its Microchip MEC5200. I remember reading some series discussion
> about not naming driver after IC its based on, but rather platform its
> used for since driver depends on firmware which is platform specific...
> cannot find that discussion now.
>
>>
>>> @@ -0,0 +1,91 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/embedded-controller/dell,xps13-9345-ec.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Dell XPS 13 9345 Embedded Controller
>>> +
>>> +maintainers:
>>> + - Aleksandrs Vinarskis <alex@vinarskis.com>
>>> +
>>> +description:
>>> + The Dell XPS 13 9345 has an Embedded Controller (EC) which handles thermal
>>> + and power management. It is communicating with SoC over multiple i2c busses.
>>> + Among other things, it handles fan speed control, thermal shutdown, peripheral
>>> + power supply including trackpad, touch-row, display. For these functions, it
>>> + requires frequently updated thermal readings from onboard thermistors.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: dell,xps13-9345-ec
>>
>> Ditto the compat - name it after the IC not the laptop its a "mec5200"
>> or "mec5200-ec" - I suspect the -ec postfix is a tautology the ec bit in
>> "mec" probably captures.
>
> I'm not sure I agree regarding the compatible, its supposed to be as exact as
> possible. "dell,mec5200" will not allow us to differentiate between EC drivers
> of "tributo" and "thena" for example.
>
> Suggestion:
> - Schema filename to be generalized "dell,mec5200-ec.yaml"
> - Driver filename to be generalized "dell-mec5200-ec.c"
> - Config to be generalized "EC_DELL_MEC5200"
> - Compatible to stay specific "dell,xps13-9345-ec", with fallback to
> "dell,mec5200-ec".
>
> I would also keep "-ec" to stay consistent with naming convention of
> existing drivers and bindings.
>
> Let me know if this would work for you.
>
> Alex
To me including the laptop model in the IC name, when our best
information is that this same chip is used on both Thena variants isn't
very logical.
The thing is the IC not the platform it resides on.
But if you think the firmware is specific to each platform - something
like dell-mec5200-ec, dell,mec5200-xps13-9345-ec makes sense to me.
>
>>
>>> +
>>> + reg:
>>> + const: 0x3b
>>> +
>>> + interrupts:
>>> + maxItems: 1
>>> +
>>> + io-channels:
>>> + description:
>>> + ADC channels connected to the 7 onboard thermistors on PMK8550.
>>> + EC requires frequent thermal readings of these channels to perform
>>> + automated fan speed control.
>>> + items:
>>> + - description: ADC channel for sys_therm0
>>> + - description: ADC channel for sys_therm1
>>> + - description: ADC channel for sys_therm2
>>> + - description: ADC channel for sys_therm3
>>> + - description: ADC channel for sys_therm4
>>> + - description: ADC channel for sys_therm5
>>> + - description: ADC channel for sys_therm6
>>> +
>>> + io-channel-names:
>>> + items:
>>> + - const: sys_therm0
>>> + - const: sys_therm1
>>> + - const: sys_therm2
>>> + - const: sys_therm3
>>> + - const: sys_therm4
>>> + - const: sys_therm5
>>> + - const: sys_therm6
>>
>>
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - interrupts
>>> + - io-channels
>>> + - io-channel-names
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/interrupt-controller/irq.h>
>>> + #include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h>
>>> + i2c {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + embedded-controller@3b {
>>> + compatible = "dell,xps13-9345-ec";
>>> + reg = <0x3b>;
>>> + interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_LOW>;
>>> +
>>> + io-channels = <&pmk8550_vadc PM8350_ADC7_GPIO3_100K_PU(1)>,
>>> + <&pmk8550_vadc PM8350_ADC7_GPIO4_100K_PU(1)>,
>>> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM1_100K_PU(1)>,
>>> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM2_100K_PU(1)>,
>>> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM3_100K_PU(1)>,
>>> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM4_100K_PU(1)>,
>>> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM5_100K_PU(1)>;
>>> + io-channel-names = "sys_therm0",
>>> + "sys_therm1",
>>> + "sys_therm2",
>>> + "sys_therm3",
>>> + "sys_therm4",
>>> + "sys_therm5",
>>> + "sys_therm6";
>>> + };
>>> + };
>>> +...
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 96e0781f2201b41b976dfa69efd44d62c4ff0058..a5d175559f4468dfe363b319a1b08d3425f4d712 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7236,6 +7236,11 @@ S: Maintained
>>> F: Documentation/ABI/testing/sysfs-class-firmware-attributes
>>> F: drivers/platform/x86/dell/dell-wmi-sysman/
>>>
>>> +DELL XPS EMBEDDED CONTROLLER DRIVER
>>> +M: Aleksandrs Vinarskis <alex@vinarskis.com>
>>> +S: Maintained
>>> +F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
>>> +
>>> DELTA AHE-50DC FAN CONTROL MODULE DRIVER
>>> M: Zev Weiss <zev@bewilderbeest.net>
>>> L: linux-hwmon@vger.kernel.org
>>>
>>
>>
^ permalink raw reply
* [PATCH v1 1/1] dt-bindings: media: mt9m114: document common video device properties
From: Svyatoslav Ryhel @ 2026-04-06 8:13 UTC (permalink / raw)
To: Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Svyatoslav Ryhel
Cc: linux-media, devicetree, linux-kernel
In-Reply-To: <20260406081330.30362-1-clamor95@gmail.com>
Document common video interface device properties, such as rotation and
orientation.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../devicetree/bindings/media/i2c/onnn,mt9m114.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
index e896f4db2421..2b39614f5cbf 100644
--- a/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/onnn,mt9m114.yaml
@@ -15,6 +15,9 @@ description: |-
an I2C interface and outputs image data over a 8-bit parallel or 1-lane MIPI
CSI-2 connection.
+allOf:
+ - $ref: /schemas/media/video-interface-devices.yaml#
+
properties:
compatible:
enum:
@@ -90,7 +93,7 @@ required:
- vaa-supply
- port
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/1] dt-bindings: media: mt9m114: document common video device properties
From: Svyatoslav Ryhel @ 2026-04-06 8:13 UTC (permalink / raw)
To: Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Svyatoslav Ryhel
Cc: linux-media, devicetree, linux-kernel
Document common video interface device properties, such as rotation and
orientation.
Svyatoslav Ryhel (1):
dt-bindings: media: mt9m114: document common video device properties
.../devicetree/bindings/media/i2c/onnn,mt9m114.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Krzysztof Kozlowski @ 2026-04-06 7:59 UTC (permalink / raw)
To: Markus Probst
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <20260405-synology_microp_initial-v6-2-08fde474b6c9@posteo.de>
On Sun, Apr 05, 2026 at 07:36:29PM +0200, Markus Probst wrote:
> Add the Synology Microp devicetree bindings. Those devices are
> microcontrollers found on Synology NAS devices. They are connected to a
> serial port on the host device.
>
> Those devices are used to control certain LEDs, fan speeds, a beeper, to
> handle buttons, fan failures and to properly shutdown and reboot the
> device.
>
> This includes the following compatible ids:
> - synology,ds923p-microp
> - synology,ds918p-microp
> - synology,ds214play-microp
> - synology,ds225p-microp
> - synology,ds425p-microp
> - synology,ds710p-microp
> - synology,ds1010p-microp
> - synology,ds723p-microp
> - synology,ds1522p-microp
> - synology,rs422p-microp
> - synology,ds725p-microp
> - synology,ds118-microp
> - synology,ds124-microp
> - synology,ds223-microp
> - synology,ds223j-microp
> - synology,ds1823xsp-microp
> - synology,rs822p-microp
> - synology,rs1221p-microp
> - synology,rs1221rpp-microp
> - synology,ds925p-microp
> - synology,ds1525p-microp
> - synology,ds1825p-microp
Drop, we see this in the diff.
>
> Signed-off-by: Markus Probst <markus.probst@posteo.de>
> ---
> .../synology,ds923p-microp.yaml | 112 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 113 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> new file mode 100644
> index 000000000000..4518e9b74be1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> @@ -0,0 +1,112 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/embedded-controller/synology,ds923p-microp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synology NAS on-board Microcontroller
> +
> +maintainers:
> + - Markus Probst <markus.probst@posteo.de>
> +
> +description: |
> + Synology Microp is a microcontroller found in Synology NAS devices.
> + It is connected to a serial port on the host device.
> +
> + It is necessary to properly shutdown and reboot the NAS device and
> + provides additional functionality such as led control, fan speed control,
> + a beeper and buttons on the NAS device.
> +
> +properties:
> + compatible:
> + enum:
> + - synology,ds923p-microp
> + - synology,ds918p-microp
> + - synology,ds214play-microp
> + - synology,ds225p-microp
> + - synology,ds425p-microp
> + - synology,ds710p-microp
> + - synology,ds1010p-microp
> + - synology,ds723p-microp
> + - synology,ds1522p-microp
> + - synology,rs422p-microp
> + - synology,ds725p-microp
> + - synology,ds118-microp
> + - synology,ds124-microp
> + - synology,ds223-microp
> + - synology,ds223j-microp
> + - synology,ds1823xsp-microp
> + - synology,rs822p-microp
> + - synology,rs1221p-microp
> + - synology,rs1221rpp-microp
> + - synology,ds925p-microp
> + - synology,ds1525p-microp
> + - synology,ds1825p-microp
So we already talked about this and you were told to use compatibility.
Your driver clearly states several of these are compatible, so I am
confused that I do not see it expressed here.
> +
> + fan-failure-gpios:
> + description: GPIOs needed to determine which fans stopped working on a fan failure event.
> + minItems: 2
> + maxItems: 3
> +
> +required:
> + - compatible
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - synology,ds214play-microp
> + - synology,ds225p-microp
> + - synology,ds710p-microp
> + - synology,ds723p-microp
> + - synology,ds725p-microp
> + - synology,ds118-microp
> + - synology,ds124-microp
> + - synology,ds223-microp
> + - synology,ds223j-microp
> + - synology,ds1823xsp-microp
> + - synology,rs822p-microp
> + - synology,rs1221p-microp
> + - synology,rs1221rpp-microp
> + - synology,ds1825p-microp
> + then:
> + properties:
> + fan-failure-gpios: false
> + else:
> + required:
> + - fan-failure-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/leds/common.h>
> + #include <dt-bindings/gpio/gpio.h>
> +
> + embedded-controller {
> + compatible = "synology,ds923p-microp";
> +
> + fan-failure-gpios = <&gpio 68 GPIO_ACTIVE_HIGH>, <&gpio 69 GPIO_ACTIVE_HIGH>;
Keep only one example, they are basically the same. Difference in one
property does not need a new example.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 2/2] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-06 7:51 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260406075114.25672-1-clamor95@gmail.com>
Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../pinctrl/maxim,max77620-pinctrl.yaml | 98 ++++++++++++++
.../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
2 files changed, 98 insertions(+), 127 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
new file mode 100644
index 000000000000..b3ea36474317
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Pinmux controller function for Maxim MAX77620 Power management IC
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ Device has 8 GPIO pins which can be configured as GPIO as well as the
+ special IO functions.
+
+allOf:
+ - $ref: /schemas/pinctrl/pincfg-node.yaml
+ - $ref: /schemas/pinctrl/pinmux-node.yaml
+
+patternProperties:
+ "^(pin|gpio).":
+ type: object
+ additionalProperties: false
+
+ properties:
+ pins:
+ items:
+ enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7 ]
+
+ function:
+ items:
+ enum: [ gpio, lpm-control-in, fps-out, 32k-out1, sd0-dvs-in, sd1-dvs-in,
+ reference-out ]
+
+ drive-push-pull: true
+ drive-open-drain: true
+ bias-pull-up: true
+ bias-pull-down: true
+
+ maxim,active-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ FPS source for the GPIOs to get enabled/disabled when system is in
+ active state. Valid values are:
+ - MAX77620_FPS_SRC_0: FPS source is FPS0.
+ - MAX77620_FPS_SRC_1: FPS source is FPS1
+ - MAX77620_FPS_SRC_2: FPS source is FPS2
+ - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and
+ it gets enabled/disabled by register access.
+ Absence of this property will leave the FPS configuration register
+ for that GPIO to default configuration.
+
+ maxim,active-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get enabled when
+ master FPS input event set to HIGH. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,active-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get disabled when
+ master FPS input event set to LOW. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-source" but value get
+ configured when system enters in to suspend state.
+
+ maxim,suspend-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-up-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-down-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ required:
+ - pins
+
+additionalProperties: false
+
+# see maxim,max77620.yaml for an example
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
deleted file mode 100644
index 28fbca180068..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-Pincontrol driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has 8 GPIO pins which can be configured as GPIO as well as the
-special IO functions.
-
-Please refer file <devicetree/bindings/pinctrl/pinctrl-bindings.txt>
-for details of the common pinctrl bindings used by client devices,
-including the meaning of the phrase "pin configuration node".
-
-Optional Pinmux properties:
---------------------------
-Following properties are required if default setting of pins are required
-at boot.
-- pinctrl-names: A pinctrl state named per <pinctrl-bindings.txt>.
-- pinctrl[0...n]: Properties to contain the phandle for pinctrl states per
- <pinctrl-bindings.txt>.
-
-The pin configurations are defined as child of the pinctrl states node. Each
-sub-node have following properties:
-
-Required properties:
-------------------
-- pins: List of pins. Valid values of pins properties are:
- gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7.
-
-Optional properties:
--------------------
-Following are optional properties defined as pinmux DT binding document
-<pinctrl-bindings.txt>. Absence of properties will leave the configuration
-on default.
- function,
- drive-push-pull,
- drive-open-drain,
- bias-pull-up,
- bias-pull-down.
-
-Valid values for function properties are:
- gpio, lpm-control-in, fps-out, 32k-out, sd0-dvs-in, sd1-dvs-in,
- reference-out
-
-There are also customised properties for the GPIO1, GPIO2 and GPIO3. These
-customised properties are required to configure FPS configuration parameters
-of these GPIOs. Please refer <devicetree/bindings/mfd/max77620.txt> for more
-detail of Flexible Power Sequence (FPS).
-
-- maxim,active-fps-source: FPS source for the GPIOs to get
- enabled/disabled when system is in
- active state. Valid values are:
- - MAX77620_FPS_SRC_0,
- FPS source is FPS0.
- - MAX77620_FPS_SRC_1,
- FPS source is FPS1
- - MAX77620_FPS_SRC_2 and
- FPS source is FPS2
- - MAX77620_FPS_SRC_NONE.
- GPIO is not controlled
- by FPS events and it gets
- enabled/disabled by register
- access.
- Absence of this property will leave
- the FPS configuration register for that
- GPIO to default configuration.
-
-- maxim,active-fps-power-up-slot: Sequencing event slot number on which
- the GPIO get enabled when
- master FPS input event set to HIGH.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,active-fps-power-down-slot: Sequencing event slot number on which
- the GPIO get disabled when master
- FPS input event set to LOW.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,suspend-fps-source: This is same as property
- "maxim,active-fps-source" but value
- get configured when system enters in
- to suspend state.
-
-- maxim,suspend-fps-power-up-slot: This is same as property
- "maxim,active-fps-power-up-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
-
-- maxim,suspend-fps-power-down-slot: This is same as property
- "maxim,active-fps-power-down-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
- FPS2.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
-
- pinctrl-names = "default";
- pinctrl-0 = <&spmic_default>;
-
- spmic_default: pinmux@0 {
- pin_gpio0 {
- pins = "gpio0";
- function = "gpio";
- };
-
- pin_gpio1 {
- pins = "gpio1";
- function = "fps-out";
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- pin_gpio2 {
- pins = "gpio2";
- function = "fps-out";
- maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
- };
- };
-};
--
2.51.0
^ permalink raw reply related
* [PATCH v5 1/2] regulator: dt-bindings: regulator-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-04-06 7:51 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260406075114.25672-1-clamor95@gmail.com>
Convert regulator-max77620 devicetree bindings for the MAX77620 PMIC from
TXT to YAML format. This patch does not change any functionality; the
bindings remain the same.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../regulator/maxim,max77620-regulator.yaml | 99 ++++++++
.../bindings/regulator/regulator-max77620.txt | 222 ------------------
2 files changed, 99 insertions(+), 222 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
new file mode 100644
index 000000000000..7118c34961ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/maxim,max77620-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Regulator for MAX77620 Power management IC from Maxim Semiconductor.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+description:
+ Device has multiple DCDC(sd[0-3]) and LDOs(ldo[0-8]). The input supply
+ of these regulators are defined under parent device node. Details of
+ regulator properties are defined as child node under sub-node "regulators"
+ which is child node of device node.
+
+patternProperties:
+ "^in-(sd[0-3]|ldo(0-1|2|3-5|4-6|7-8))-supply$":
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Input supply for DCDC or LDO
+
+ "^(sd[0-3]|ldo[0-8])$":
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ maxim,active-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ FPS source for the GPIOs to get enabled/disabled when system is in
+ active state. Valid values are:
+ - MAX77620_FPS_SRC_0: FPS source is FPS0.
+ - MAX77620_FPS_SRC_1: FPS source is FPS1
+ - MAX77620_FPS_SRC_2: FPS source is FPS2
+ - MAX77620_FPS_SRC_NONE: GPIO is not controlled by FPS events and
+ it gets enabled/disabled by register access.
+ Absence of this property will leave the FPS configuration register
+ for that GPIO to default configuration.
+
+ maxim,active-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get enabled when
+ master FPS input event set to HIGH. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,active-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Sequencing event slot number on which the GPIO get disabled when
+ master FPS input event set to LOW. This is applicable if FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-source" but value get
+ configured when system enters in to suspend state.
+
+ maxim,suspend-fps-power-up-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-up-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,suspend-fps-power-down-slot:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ This is same as property "maxim,active-fps-power-down-slot" but this
+ value get configured into FPS configuration register when system
+ enters into suspend. This is applicable if suspend state FPS source
+ is selected as FPS0, FPS1 or FPS2.
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+ maxim,ramp-rate-setting:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Ramp rate(uV/us) setting to be configured to the device. The platform
+ may have different ramp rate than advertised ramp rate if it has design
+ variation from Maxim's recommended. On this case, platform specific
+ ramp rate is used for ramp time calculation and this property is used
+ for device register configurations. The measured ramp rate of platform
+ is provided by the regulator-ramp-delay.
+
+ Maxim Max77620 supports following ramp delay:
+ SD: 13.75mV/us, 27.5mV/us, 55mV/us
+ LDOs: 5mV/us, 100mV/us
+ enum: [5000, 13750, 27500, 55000, 100000]
+
+additionalProperties: false
+
+# see maxim,max77620.yaml for an example
diff --git a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt b/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
deleted file mode 100644
index bcf788897e44..000000000000
--- a/Documentation/devicetree/bindings/regulator/regulator-max77620.txt
+++ /dev/null
@@ -1,222 +0,0 @@
-Regulator DT binding for MAX77620 Power management IC from Maxim Semiconductor.
-
-Device has multiple DCDC(sd[0-3] and LDOs(ldo[0-8]). The input supply
-of these regulators are defined under parent device node.
-Details of regulator properties are defined as child node under
-sub-node "regulators" which is child node of device node.
-
-Please refer file <Documentation/devicetree/bindings/regulator/regulator.txt>
-for common regulator bindings used by client.
-
-Following are properties of parent node related to regulators.
-
-Optional properties:
--------------------
-The input supply of regulators are the optional properties on the
-parent device node. The input supply of these regulators are provided
-through following properties:
-in-sd0-supply: Input supply for SD0, INA-SD0 or INB-SD0 pins.
-in-sd1-supply: Input supply for SD1.
-in-sd2-supply: Input supply for SD2.
-in-sd3-supply: Input supply for SD3.
-in-ldo0-1-supply: Input supply for LDO0 and LDO1.
-in-ldo2-supply: Input supply for LDO2.
-in-ldo3-5-supply: Input supply for LDO3 and LDO5
-in-ldo4-6-supply: Input supply for LDO4 and LDO6.
-in-ldo7-8-supply: Input supply for LDO7 and LDO8.
-
-Optional sub nodes for regulators under "regulators" subnode:
-------------------------------------------------------------
-The subnodes name is the name of regulator and it must be one of:
- sd[0-3], ldo[0-8]
-
-Each sub-node should contain the constraints and initialization
-information for that regulator. The definition for each of these
-nodes is defined using the standard binding for regulators found at
-<Documentation/devicetree/bindings/regulator/regulator.txt>.
-
-There are also additional properties for SD/LDOs. These additional properties
-are required to configure FPS configuration parameters for SDs and LDOs.
-Please refer <devicetree/bindings/mfd/max77620.txt> for more detail of Flexible
-Power Sequence (FPS).
-Following are additional properties:
-
-- maxim,active-fps-source: FPS source for the regulators to get
- enabled/disabled when system is in
- active state. Valid values are:
- - MAX77620_FPS_SRC_0,
- FPS source is FPS0.
- - MAX77620_FPS_SRC_1,
- FPS source is FPS1
- - MAX77620_FPS_SRC_2 and
- FPS source is FPS2
- - MAX77620_FPS_SRC_NONE.
- Regulator is not controlled
- by FPS events and it gets
- enabled/disabled by register
- access.
- Absence of this property will leave
- the FPS configuration register for that
- regulator to default configuration.
-
-- maxim,active-fps-power-up-slot: Sequencing event slot number on which
- the regulator get enabled when
- master FPS input event set to HIGH.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,active-fps-power-down-slot: Sequencing event slot number on which
- the regulator get disabled when master
- FPS input event set to LOW.
- Valid values are 0 to 7.
- This is applicable if FPS source is
- selected as FPS0, FPS1 or FPS2.
-
-- maxim,suspend-fps-source: This is same as property
- "maxim,active-fps-source" but value
- get configured when system enters in
- to suspend state.
-
-- maxim,suspend-fps-power-up-slot: This is same as property
- "maxim,active-fps-power-up-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
-
-- maxim,suspend-fps-power-down-slot: This is same as property
- "maxim,active-fps-power-down-slot" but
- this value get configured into FPS
- configuration register when system
- enters into suspend.
- This is applicable if suspend state
- FPS source is selected as FPS0, FPS1 or
- FPS2.
-- maxim,ramp-rate-setting: integer, ramp rate(uV/us) setting to be
- configured to the device.
- The platform may have different ramp
- rate than advertised ramp rate if it has
- design variation from Maxim's
- recommended. On this case, platform
- specific ramp rate is used for ramp time
- calculation and this property is used
- for device register configurations.
- The measured ramp rate of platform is
- provided by the regulator-ramp-delay
- as described in <devicetree/bindings/
- regulator/regulator.txt>.
- Maxim Max77620 supports following ramp
- delay:
- SD: 13.75mV/us, 27.5mV/us, 55mV/us
- LDOs: 5mV/us, 100mV/us
-
-Note: If the measured ramp delay is same as advertised ramp delay then it is not
-required to provide the ramp delay with property "maxim,ramp-rate-setting". The
-ramp rate can be provided by the regulator-ramp-delay which will be used for
-ramp time calculation for voltage change as well as for device configuration.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-...
-max77620@3c {
- in-ldo0-1-supply = <&max77620_sd2>;
- in-ldo7-8-supply = <&max77620_sd2>;
- regulators {
- sd0 {
- regulator-name = "vdd-core";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1400000>;
- regulator-boot-on;
- regulator-always-on;
- maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
- };
-
- sd1 {
- regulator-name = "vddio-ddr";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
- };
-
- sd2 {
- regulator-name = "vdd-pre-reg";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- };
-
- sd3 {
- regulator-name = "vdd-1v8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo0 {
- regulator-name = "avdd-sys";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo1 {
- regulator-name = "vdd-pex";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
-
- ldo2 {
- regulator-name = "vddio-sdmmc3";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo3 {
- regulator-name = "vdd-cam-hv";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo4 {
- regulator-name = "vdd-rtc";
- regulator-min-microvolt = <1250000>;
- regulator-max-microvolt = <1250000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo5 {
- regulator-name = "avdd-ts-hv";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo6 {
- regulator-name = "vdd-ts";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo7 {
- regulator-name = "vdd-gen-pll-edp";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo8 {
- regulator-name = "vdd-hdmi-dp";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
- };
-};
--
2.51.0
^ permalink raw reply related
* [PATCH v5 0/2] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-04-06 7:51 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
I have tested this patch on LG Optimus Vu P895 with max77663 PMIC and
non-default RTC position. RTC is registered correctly.
---
Changes in v5
- fixed pincontrol schema
- dropped applied patches
Changes in v4
- adjusted pinconfig node naming
- changed interrupt in the example
- fixed indentation in the example
- corrected pinconfig node name in the example
- commit "dt-bindings: gpio: trivial-gpio: remove max77620 compatible"
squashed with the converting patch for this compatible
Changes in v3
- max77620 files converted to DT schema.
Changes in v2
- dropped patch that changes max77686 and adjusted max77620 where max77663
is described.
---
Svyatoslav Ryhel (2):
regulator: dt-bindings: regulator-max77620: convert to DT schema
dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
.../pinctrl/maxim,max77620-pinctrl.yaml | 98 ++++++++
.../bindings/pinctrl/pinctrl-max77620.txt | 127 ----------
.../regulator/maxim,max77620-regulator.yaml | 99 ++++++++
.../bindings/regulator/regulator-max77620.txt | 222 ------------------
4 files changed, 197 insertions(+), 349 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
create mode 100644 Documentation/devicetree/bindings/regulator/maxim,max77620-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/regulator-max77620.txt
--
2.51.0
^ permalink raw reply
* Re: [PATCH v4 0/8] can: flexcan: Add NXP S32N79 SoC support
From: Ciprian Marian Costea @ 2026-04-06 7:50 UTC (permalink / raw)
To: Marc Kleine-Budde, Vincent Mailhol, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Fabio Estevam
Cc: Pengutronix Kernel Team, linux-can, devicetree, linux-kernel, imx,
linux-arm-kernel, NXP S32 Linux Team, Christophe Lizzi,
Alberto Ruiz, Enric Balletbo, Eric Chanudet
In-Reply-To: <20260326135825.3428856-1-ciprianmarian.costea@oss.nxp.com>
On 3/26/2026 3:58 PM, Ciprian Costea wrote:
> From: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com>
>
Hello Marc,
I was wondering if you had a chance to look at v4 of this series.
I've integrated all your suggestions from v3. Please let me know if you
see any further issues.
Best Regards,
Ciprian
> This patch series adds FlexCAN support for the NXP S32N79 SoC.
>
> The S32N79 is an automotive-grade processor from NXP with multiple
> FlexCAN instances. The FlexCAN IP integration on S32N79 differs from
> other SoCs in the interrupt routing - it uses two separate interrupt
> lines:
> - one interrupt for mailboxes 0-127
> - one interrupt for bus error detection and device state changes
>
> The CAN controllers are connected through an irqsteer interrupt
> controller in the RCU (Resource Control Unit) domain.
>
> This series:
> 1. Splits flexcan_irq() into dedicated handlers for multi-IRQ platforms
> 2. Adds dt-bindings documentation for S32N79 FlexCAN
> 3. Introduces FLEXCAN_QUIRK_IRQ_BERR to handle the two-interrupt
> configuration
> 4. Adds S32N79 device data and compatible string to the driver
> 5. Adds FlexCAN device tree nodes for S32N79 SoC
> 6. Enables FlexCAN devices on the S32N79-RDB board
>
> Tested on S32N79-RDB board with CAN and CAN FD communication.
>
> v4 -> v3
> - flexcan_chip_interrupts_enable(): disable/enable all IRQ lines
> (not just dev->irq) during IMASK register writes
> - Split rx/tx masks per mailbox IRQ line (struct flexcan_mb_irq) so
> each handler on S32G2 only processes its own MB range
> - Added received Acked-by tag on DT bindings patch
>
> v3 -> v2
> - Split flexcan_irq() into dedicated handlers (flexcan_irq_mb,
> flexcan_irq_boff, flexcan_irq_berr) to fix duplicate event
> processing when multiple IRQ lines run concurrently (new patch).
> - Added flexcan_irq_esr() handler composing state + berr for S32N79
> - Ordered quirks used by s32n devtype data by value.
>
> v2 -> v1
> - Renamed FLEXCAN_QUIRK_NR_IRQ_2 to FLEXCAN_QUIRK_IRQ_BERR to better
> describe the actual hardware feature
> - Appended new quirk at the end
> - Switched from platform_get_irq to platform_get_irq_byname usage
> - Updated interrupt description in dt-bindings
>
> Ciprian Marian Costea (8):
> can: flexcan: use dedicated IRQ handlers for multi-IRQ platforms
> can: flexcan: disable all IRQ lines in
> flexcan_chip_interrupts_enable()
> can: flexcan: split rx/tx masks per mailbox IRQ line
> dt-bindings: can: fsl,flexcan: add NXP S32N79 SoC support
> can: flexcan: add FLEXCAN_QUIRK_IRQ_BERR quirk
> can: flexcan: add NXP S32N79 SoC support
> arm64: dts: s32n79: add FlexCAN nodes
> arm64: dts: s32n79: enable FlexCAN devices
>
> .../bindings/net/can/fsl,flexcan.yaml | 30 ++-
> arch/arm64/boot/dts/freescale/s32n79-rdb.dts | 12 +
> arch/arm64/boot/dts/freescale/s32n79.dtsi | 50 ++++
> drivers/net/can/flexcan/flexcan-core.c | 249 +++++++++++++++---
> drivers/net/can/flexcan/flexcan.h | 12 +-
> 5 files changed, 316 insertions(+), 37 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 1/2] Revert "arm64: tegra: Disable ISO SMMU for Tegra194"
From: Aaron Kling @ 2026-04-06 7:49 UTC (permalink / raw)
To: Thierry Reding
Cc: Mikko Perttunen, Thierry Reding, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Hunter, devicetree, linux-tegra,
linux-kernel
In-Reply-To: <aZQ-cMn-3vI7UH7t@orome>
On Tue, Feb 17, 2026 at 4:13 AM Thierry Reding
<thierry.reding@kernel.org> wrote:
>
> On Tue, Feb 17, 2026 at 12:53:54PM +0900, Mikko Perttunen wrote:
> > On Thursday, January 22, 2026 7:22 PM Mikko Perttunen wrote:
> > > On Tuesday, December 9, 2025 1:21 PM Aaron Kling wrote:
> > > > On Mon, Nov 3, 2025 at 12:05 PM Aaron Kling <webgeek1234@gmail.com> wrote:
> > > > >
> > > > > On Mon, Nov 3, 2025 at 5:07 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > >
> > > > > > On Sat, Nov 01, 2025 at 06:13:26PM -0500, Aaron Kling wrote:
> > > > > > > On Sat, Nov 1, 2025 at 6:01 PM Aaron Kling via B4 Relay
> > > > > > > <devnull+webgeek1234.gmail.com@kernel.org> wrote:
> > > > > > > >
> > > > > > > > From: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > >
> > > > > > > > This reverts commit ebea268ea583ba4970df425dfef8c8e21d0a4e12.
> > > > > > > >
> > > > > > > > Mmu is now being enabled for the display controllers.
> > > > > > > >
> > > > > > > > Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> > > > > > > > ---
> > > > > > > > arch/arm64/boot/dts/nvidia/tegra194.dtsi | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > index 1399342f23e1c4f73b278adc66dfb948fc30d326..854ed6d46aa1d8eedcdfbae1fdde1374adf40337 100644
> > > > > > > > --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> > > > > > > > @@ -1807,7 +1807,7 @@ iommu@10000000 {
> > > > > > > > #iommu-cells = <1>;
> > > > > > > >
> > > > > > > > nvidia,memory-controller = <&mc>;
> > > > > > > > - status = "disabled";
> > > > > > > > + status = "okay";
> > > > > > > > };
> > > > > > > >
> > > > > > > > smmu: iommu@12000000 {
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.51.0
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > Question for Jon as the author of the commit being reverted. The
> > > > > > > commit message states "we do not have a way to pass frame-buffer
> > > > > > > memory from the bootloader to the kernel". If I understand this
> > > > > > > correctly, this is talking about seamless handoff. What does this have
> > > > > > > to do with enabling mmu on the display controllers? Seamless does not
> > > > > > > work on any tegra arch as far as I'm aware, but Tegra194 is the only
> > > > > > > one that doesn't have mmu enabled for the dc's. But enabling mmu
> > > > > > > allows for better and faster memory allocation. My initial attempts to
> > > > > > > enable this didn't work because I tried to attach them to the main mmu
> > > > > > > unit, see the related freedesktop issue [0]. After noticing in the
> > > > > > > downstream dt that the dc's are on a separate unit, I made it work.
> > > > > > > And so far, it seems to work just as well as Tegra186. Then when I was
> > > > > > > packaging up the change to submit, I found that this had been
> > > > > > > explicitly disabled. But I'm not seeing why. Am I missing some
> > > > > > > additional factors?
> > > > > >
> > > > > > This isn't seamless handoff to the Tegra DRM driver for display, but
> > > > > > rather to simple-framebuffer. While this does technically work, it also
> > > > > > causes a spew of SMMU faults during early boot because the firmware does
> > > > > > not properly pass the SMMU mapping information to the kernel.
> > > > > >
> > > > > > In a nutshell what happens is that the firmware sets up the display
> > > > > > controller to scan out from a reserved memory region, but it does so
> > > > > > without involving the SMMU, so it uses physical addresses directly. When
> > > > > > the kernel boots and the SMMU is enabled the continued accesses from
> > > > > > display hardware cause SMMU faults (because there is no mapping for the
> > > > > > framebuffer addresses).
> > > > > >
> > > > > > That said, we did solve these issues and this may not be happening
> > > > > > anymore with the most recent L4T releases, so it may be okay to revert
> > > > > > this now. We should find out exactly which release includes all the
> > > > > > needed changes so that it can be referenced in the commit message. I
> > > > > > want to avoid people running new kernels with an old L4T release and
> > > > > > then seeing these errors without any reference as to why that might
> > > > > > suddenly happen.
> > > > >
> > > > > For reference, I have rolled back my Android usecase to use the L4T
> > > > > r32.7.6 bootloaders on T194 for a variety of reasons. So I am using
> > > > > cboot as the final bootloader and not edk2 as in L4T r34/r35. I have a
> > > > > pending cboot patch to support simple-framebuffer handoff, but haven't
> > > > > fully verified it as tegra-drm is currently unable to takeover from
> > > > > simplefb like openrm does for t234. But all that to say that since I
> > > > > no longer use r35 for t194 I don't have the setup to easily verify
> > > > > which point release works here and what doesn't.
> > > >
> > > > Any further thoughts on this patch?
> > > >
> > > > Aaron
> > >
> > > FWIW,
> > >
> > > looks like the edk2 patch to update iommu-addresses --
> > >
> > > commit 6071946461389221d2314cbbae0377610b5b1f6a
> > > Author: Jan Bobek <jbobek@nvidia.com>
> > > Date: Tue Mar 21 00:15:27 2023 +0000
> > >
> > > feat(NvDisplayControllerDxe): update FDT with framebuffer info
> > >
> > > On ready-to-boot and whenever FDT is installed, update FDT with
> > > framebuffer mode information, base address and size.
> > >
> > > Signed-off-by: Jan Bobek <jbobek@nvidia.com>
> > > Reviewed-by: Ashish Singhal <ashishsingha@nvidia.com>
> > >
> > > is in since r36.2
> > >
> > > $ git tag --contains 6071946461389221d2314cbbae0377610b5b1f6a | grep "^r"
> > > r36.2
> > > r36.3.0
> > > r36.4.0
> > > r36.4.3
> > > r36.4.4
> > > r36.4.5
> > > r38.2
> > > r38.4
> > >
> > > Not so good for T194 since r36 only supports Orin.
> > >
> > > I'll look into getting this cherry-picked to r35.
> > >
> > > Mikko
> > >
> > >
> >
> > I looked into this and it appears a version of this is in r35, but it
> > only supports T234. However, I also found that at one point, L4T
> > bootloader configuration has been modified to place the display
> > controllers into SMMU bypass until otherwise configured by the kernel
> > -- which the kernel does in tegra_mc_probe_device.
> >
> > I think that means there is still potential for an issue where the
> > display continues to be on between tegra_mc_probe_device and tegradrm
> > reconfiguring it. However, I cannot reproduce that happening -- most
> > likely the display is being turned off before that because of a clock
> > or power domain being turned off.
> >
> > In any case, this means that we no longer need to pass the
> > framebuffer's information to the kernel. I think it would be good to
> > have some clarity to ensure the issue described above cannot happen,
> > but otherwise we should be able to enable IOMMU.
>
> The problem would happen if you enable some sort of early framebuffer
> support, such as simple-drm or simple-framebuffer. Maybe even efifb. I
> think it'd still be worth getting the iommu-addresses code into r35 if
> for nothing else but to have a bit more of a safety buffer for the
> future.
>
> If we don't and for some reason decide that we want early framebuffer
> support, it might be too late to get UEFI updated for Tegra194. I recall
> that the UEFI code for Tegra194 is different from the one for Tegra234,
> so it is probably not as trivial as a simple cherry-pick, but I'll try
> to do some digging and find the code that does this for Xavier.
Any updates on this?
Aaron
^ permalink raw reply
* [PATCH v4 3/3 RESEND] drm/bridge: simple-bridge: Add support for MStar TSUMU88ADT3-LF-1
From: Svyatoslav Ryhel @ 2026-04-06 7:39 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260406073930.24662-1-clamor95@gmail.com>
From: Maxim Schwalm <maxim.schwalm@gmail.com>
A simple HDMI bridge used in ASUS Transformer AiO P1801-T.
Signed-off-by: Maxim Schwalm <maxim.schwalm@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..cc13c98f9be6 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "mstar,tsumu88adt3-lf-1",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.51.0
^ permalink raw reply related
* [PATCH v4 2/3 RESEND] dt-bindigs: display: extend the simple bridge with MStar TSUMU88ADT3-LF-1 bridge
From: Svyatoslav Ryhel @ 2026-04-06 7:39 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260406073930.24662-1-clamor95@gmail.com>
A simple bridge used in ASUS Transformer AiO P1801-T.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..7636c24906ba 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - mstar,tsumu88adt3-lf-1
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.51.0
^ permalink raw reply related
* [PATCH v4 1/3 RESEND] dt-bindigs: display: extend the LVDS codec with Triple 10-BIT LVDS Transmitter
From: Svyatoslav Ryhel @ 2026-04-06 7:39 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
In-Reply-To: <20260406073930.24662-1-clamor95@gmail.com>
From: David Heidelberg <david@ixit.cz>
LVDS transmitter used in the Microsoft Surface RT.
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 7586d681bcc6..0363201f0e61 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
@@ -34,6 +34,7 @@ properties:
- items:
- enum:
- doestek,dtc34lm85am # For the Doestek DTC34LM85AM Flat Panel Display (FPD) Transmitter
+ - idt,v103 # For the Triple 10-BIT LVDS Transmitter
- onnn,fin3385 # OnSemi FIN3385
- ti,ds90c185 # For the TI DS90C185 FPD-Link Serializer
- ti,ds90c187 # For the TI DS90C187 FPD-Link Serializer
--
2.51.0
^ permalink raw reply related
* [PATCH v4 0/3 RESEND] drm: bridge: add support for Triple 10-BIT
From: Svyatoslav Ryhel @ 2026-04-06 7:39 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
David Airlie, Simona Vetter, Svyatoslav Ryhel
Cc: dri-devel, devicetree, linux-kernel
Triple 10-BIT LVDS Transmitter is used in Microsoft Surface RT and
MStar TSUMU88ADT3-LF-1 HDMI bridge is used in ASUS Transformer AiO
P1801-T.
Link to v3: https://lore.kernel.org/lkml/20250824092728.105643-1-clamor95@gmail.com/
---
Changes on switching from v3 to v4:
- rebased on top of v7.0
Changes on switching from v2 to v3:
- place mstar,tsumu88adt3-lf-1 alphabetically
- fix typos
Changes on switching from v1 to v2:
- sort compatible alphabetically in schema
---
David Heidelberg (1):
dt-bindigs: display: extend the LVDS codec with Triple 10-BIT LVDS
Transmitter
Maxim Schwalm (1):
drm/bridge: simple-bridge: Add support for MStar TSUMU88ADT3-LF-1
Svyatoslav Ryhel (1):
dt-bindigs: display: extend the simple bridge with MStar
TSUMU88ADT3-LF-1 bridge
.../devicetree/bindings/display/bridge/lvds-codec.yaml | 1 +
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
3 files changed, 7 insertions(+)
--
2.51.0
^ permalink raw reply
* Re: [PATCH v20 00/10] Implement PSCI reboot mode driver for PSCI resets
From: Pankaj Patil @ 2026-04-06 7:36 UTC (permalink / raw)
To: Shivendra Pratap, Lorenzo Pieralisi, Arnd Bergmann,
Bjorn Andersson, Sebastian Reichel, Rob Herring,
Souvik Chakravarty, Krzysztof Kozlowski, Andy Yan,
Matthias Brugger, Mark Rutland, Conor Dooley, Konrad Dybcio,
John Stultz, Moritz Fischer, Bartosz Golaszewski, Sudeep Holla
Cc: Florian Fainelli, Krzysztof Kozlowski, Dmitry Baryshkov,
Mukesh Ojha, Andre Draszik, Kathiravan Thirumoorthy, linux-pm,
linux-kernel, linux-arm-kernel, linux-arm-msm, devicetree,
Srinivas Kandagatla, Song Xue
In-Reply-To: <20260304-arm-psci-system_reset2-vendor-reboots-v20-0-cf7d346b8372@oss.qualcomm.com>
On 3/4/2026 11:33 PM, Shivendra Pratap wrote:
> Userspace should be able to initiate device reboots using the various
> PSCI SYSTEM_RESET and SYSTEM_RESET2 types defined by PSCI spec. This
> patch series introduces psci-reboot-mode driver that registers with
> reboot-mode framework to provide this functionality.
>
> The PSCI system reset calls takes two arguments: reset_type and cookie.
> It defines predefined reset types, such as warm and cold reset, and
> vendor-specific reset types which are SoC vendor specific. To support
> these requirements, the reboot-mode framework is enhanced in two key
> ways:
> 1. 64-bit magic support: Extend reboot-mode to handle two 32-bit
> arguments (reset_type and cookie) by encoding them into a single 64-bit
> magic value.
> 2. Predefined modes: Add support for predefined reboot modes in the
> framework.
>
> With these enhancements, the patch series enables:
> - Warm reset and cold reset as predefined reboot modes.
> - Vendor-specific resets exposed as tunables, configurable via the
> SoC-specific device tree.
>
> Together, these changes allow userspace to trigger all above PSCI resets
> from userspace.
>
> Currently three drivers register with reboot-mode framework -
> syscon-reboot-mode, nvmem-reboot-mode and qcom-pon. Consolidated
> list of commands currently added across various vendor DTs:
> mode-loader
> mode-normal
> mode-bootloader
> mode-charge
> mode-fastboot
> mode-reboot-ab-update
> mode-recovery
> mode-rescue
> mode-shutdown-thermal
> mode-shutdown-thermal-battery
>
> On gs101 we also pass kernel-generated modes from kernel_restart()
> or panic(), specifically DM verity's 'dm-verity device corrupted':
> mode-dm-verity-device-corrupted = <0x50>;
>
> - thanks Andre' for providing this.
>
> Detailed list of commands being used by syscon-reboot-mode:
> arm64/boot/dts/exynos/exynosautov9.dtsi:
> mode-bootloader = <EXYNOSAUTOV9_BOOT_BOOTLOADER>;
> mode-fastboot = <EXYNOSAUTOV9_BOOT_FASTBOOT>;
> mode-recovery = <EXYNOSAUTOV9_BOOT_RECOVERY>;
>
> arm64/boot/dts/exynos/google/gs101.dtsi:
> mode-bootloader = <0xfc>;
> mode-charge = <0x0a>;
> mode-fastboot = <0xfa>;
> mode-reboot-ab-update = <0x52>;
> mode-recovery = <0xff>;
> mode-rescue = <0xf9>;
> mode-shutdown-thermal = <0x51>;
> mode-shutdown-thermal-battery = <0x51>;
>
> arm64/boot/dts/hisilicon/hi3660-hikey960.dts:
> mode-normal = <0x77665501>;
> mode-bootloader = <0x77665500>;
> mode-recovery = <0x77665502>;
>
> arm64/boot/dts/hisilicon/hi6220-hikey.dts:
> mode-normal = <0x77665501>;
> mode-bootloader = <0x77665500>;
> mode-recovery = <0x77665502>;
>
> arm64/boot/dts/rockchip/px30.dtsi:
> mode-bootloader = <BOOT_BL_DOWNLOAD>;
> mode-fastboot = <BOOT_FASTBOOT>;
> mode-loader = <BOOT_BL_DOWNLOAD>;
> mode-normal = <BOOT_NORMAL>;
> mode-recovery = <BOOT_RECOVERY>;
>
> arm64/boot/dts/rockchip/rk3308.dtsi:
> mode-bootloader = <BOOT_BL_DOWNLOAD>;
> mode-loader = <BOOT_BL_DOWNLOAD>;
> mode-normal = <BOOT_NORMAL>;
> mode-recovery = <BOOT_RECOVERY>;
> mode-fastboot = <BOOT_FASTBOOT>;
>
> arm64/boot/dts/rockchip/rk3566-lckfb-tspi.dts:
> mode-normal = <BOOT_NORMAL>;
> mode-loader = <BOOT_BL_DOWNLOAD>;
> mode-recovery = <BOOT_RECOVERY>;
> mode-bootloader = <BOOT_FASTBOOT>;
>
> Detailed list of commands being used by nvmem-reboot-mode:
> arm64/boot/dts/qcom/pmXXXX.dtsi:(multiple qcom DTs)
> mode-recovery = <0x01>;
> mode-bootloader = <0x02>;
>
> The patch is tested on rb3Gen2, lemans-ride, lemans-evk, monaco-ride,
> qcs615-ride.
>
> @Florian/@Kathiravan, Please note that reset_type in DT needs to be
> full in itself with 31st bit set. (eg: 0x80000000).
>
> PS: As advised from Lorenzo, "PSCI maintainers should be added as
> maintainers for psci-reboot-mode".
>
> Previous discussions around SYSTEM_RESET2:
> - https://lore.kernel.org/lkml/20230724223057.1208122-2-quic_eberman@quicinc.com/T/
> - https://lore.kernel.org/all/4a679542-b48d-7e11-f33a-63535a5c68cb@quicinc.com/
>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>
Tested-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 1/2] memory: tegra: Add T238 MC support
From: Ashish Mhetre @ 2026-04-06 7:20 UTC (permalink / raw)
To: Jon Hunter, krzk, robh, conor+dt, =thierry.reding, sumitg
Cc: linux-kernel, devicetree, linux-tegra
In-Reply-To: <1ec86de6-9282-46fb-bdba-521ac25b5fc8@nvidia.com>
On 3/31/2026 5:08 PM, Jon Hunter wrote:
>
>
> On 31/03/2026 12:23, Ashish Mhetre wrote:
>> Add Memory Controller driver support for Tegra238 SOC, including:
>> - MC client definitions with Tegra238-specific stream IDs
>> - Reuse of Tegra234 ICC operations for bandwidth management via BPMP-FW
>> - Device tree compatible string "nvidia,tegra238-mc"
>>
>> Export tegra234_mc_icc_ops so it can be shared with the Tegra238 MC
>> driver, as both SoCs use the same ICC aggregation and bandwidth
>> management logic.
>>
>> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
>> ---
>> drivers/memory/tegra/Makefile | 1 +
>> drivers/memory/tegra/mc.c | 3 +
>> drivers/memory/tegra/mc.h | 6 +
>> drivers/memory/tegra/tegra234.c | 2 +-
>> drivers/memory/tegra/tegra238.c | 395 ++++++++++++++++++++++++++++++++
>> 5 files changed, 406 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/memory/tegra/tegra238.c
>>
>> diff --git a/drivers/memory/tegra/Makefile
>> b/drivers/memory/tegra/Makefile
>> index 6334601e6120..0d50e37d43af 100644
>> --- a/drivers/memory/tegra/Makefile
>> +++ b/drivers/memory/tegra/Makefile
>> @@ -10,6 +10,7 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
>> tegra-mc-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
>> tegra-mc-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra186.o tegra194.o
>> tegra-mc-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra186.o tegra234.o
>> +tegra-mc-$(CONFIG_ARCH_TEGRA_238_SOC) += tegra186.o tegra238.o
>> tegra-mc-$(CONFIG_ARCH_TEGRA_264_SOC) += tegra186.o tegra264.o
>> obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
>> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
>> index d620660da331..10ef3c323e22 100644
>> --- a/drivers/memory/tegra/mc.c
>> +++ b/drivers/memory/tegra/mc.c
>> @@ -49,6 +49,9 @@ static const struct of_device_id
>> tegra_mc_of_match[] = {
>> #ifdef CONFIG_ARCH_TEGRA_234_SOC
>> { .compatible = "nvidia,tegra234-mc", .data = &tegra234_mc_soc },
>> #endif
>> +#ifdef CONFIG_ARCH_TEGRA_238_SOC
>> + { .compatible = "nvidia,tegra238-mc", .data = &tegra238_mc_soc },
>> +#endif
>
> It is always better/preferred for the dt-binding patch to be 1st in
> the series. The above does not exist until after patch 2 is applied.
>
Ack, I will resend with correct ordering.
>> #ifdef CONFIG_ARCH_TEGRA_264_SOC
>> { .compatible = "nvidia,tegra264-mc", .data = &tegra264_mc_soc },
>> #endif
>> diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
>> index 649b54369263..d0da4a5f192d 100644
>> --- a/drivers/memory/tegra/mc.h
>> +++ b/drivers/memory/tegra/mc.h
>> @@ -238,6 +238,11 @@ extern const struct tegra_mc_soc tegra194_mc_soc;
>> #ifdef CONFIG_ARCH_TEGRA_234_SOC
>> extern const struct tegra_mc_soc tegra234_mc_soc;
>> +extern const struct tegra_mc_icc_ops tegra234_mc_icc_ops;
>> +#endif
>> +
>> +#ifdef CONFIG_ARCH_TEGRA_238_SOC
>> +extern const struct tegra_mc_soc tegra238_mc_soc;
>> #endif
>
> Does this work? Tegra238 is dependent upon stuff in Tegra234, but
> there is no guarantee that both of these CONFIG options are always
> enabled?
>
Good point, thanks for catching this Jon. If CONFIG_ARCH_TEGRA_238_SOC
is enabled without CONFIG_ARCH_TEGRA_234_SOC, the build would fail
since tegra234_mc_icc_ops wouldn't be compiled or declared.
I'll fix this in V2 with combined Tegra234 and Tegra238 SOC guard for
struct.
>> #ifdef CONFIG_ARCH_TEGRA_264_SOC
>> @@ -256,6 +261,7 @@ extern const struct tegra_mc_ops tegra30_mc_ops;
>> #if defined(CONFIG_ARCH_TEGRA_186_SOC) || \
>> defined(CONFIG_ARCH_TEGRA_194_SOC) || \
>> defined(CONFIG_ARCH_TEGRA_234_SOC) || \
>> + defined(CONFIG_ARCH_TEGRA_238_SOC) || \
>> defined(CONFIG_ARCH_TEGRA_264_SOC)
>> extern const struct tegra_mc_ops tegra186_mc_ops;
>> #endif
>> diff --git a/drivers/memory/tegra/tegra234.c
>> b/drivers/memory/tegra/tegra234.c
>> index 87b22038a5fb..9fbd34d4abe0 100644
>> --- a/drivers/memory/tegra/tegra234.c
>> +++ b/drivers/memory/tegra/tegra234.c
>> @@ -1125,7 +1125,7 @@ static int tegra234_mc_icc_get_init_bw(struct
>> icc_node *node, u32 *avg, u32 *pea
>> return 0;
>> }
>> -static const struct tegra_mc_icc_ops tegra234_mc_icc_ops = {
>> +const struct tegra_mc_icc_ops tegra234_mc_icc_ops = {
>> .xlate = tegra_mc_icc_xlate,
>> .aggregate = tegra234_mc_icc_aggregate,
>> .get_bw = tegra234_mc_icc_get_init_bw,
>> diff --git a/drivers/memory/tegra/tegra238.c
>> b/drivers/memory/tegra/tegra238.c
>> new file mode 100644
>> index 000000000000..5abdca16a275
>> --- /dev/null
>> +++ b/drivers/memory/tegra/tegra238.c
>> @@ -0,0 +1,395 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2026, NVIDIA CORPORATION. All rights reserved.
>> + */
>
> ...
>
>> +const struct tegra_mc_soc tegra238_mc_soc = {
>> + .num_clients = ARRAY_SIZE(tegra238_mc_clients),
>> + .clients = tegra238_mc_clients,
>> + .num_address_bits = 40,
>> + .num_channels = 8,
>> + .client_id_mask = 0x1ff,
>> + .intmasks = tegra238_mc_intmasks,
>> + .num_intmasks = ARRAY_SIZE(tegra238_mc_intmasks),
>> + .has_addr_hi_reg = true,
>> + .ops = &tegra186_mc_ops,
>> + .icc_ops = &tegra234_mc_icc_ops,
>> + .ch_intmask = 0x0000ff00,
>> + .global_intstatus_channel_shift = 8,
>> + /*
>> + * Additionally, there are lite carveouts but those are not
>> currently
>> + * supported.
>> + */
>
> I don't know what this means?
>
I have kept this comment similar to Tegra234. tegra_mc_get_carveout_info()
function uses num_carveouts variable as upper limit for supported carveouts.
On top of it, there are few lite carveouts which are supported by SOC
but are
not used by the driver.
It's redundant info IMO and can be removed from both Tegra234 and Tegra238.
Jon, Can you please share your thoughts on this?
Thanks,
Ashish Mhetre
>> + .num_carveouts = 32,
>> + .regs = &tegra20_mc_regs,
>> + .handle_irq = tegra30_mc_irq_handlers,
>> + .num_interrupts = ARRAY_SIZE(tegra30_mc_irq_handlers),
>> + .mc_addr_hi_mask = 0x3,
>> + .mc_err_status_type_mask = (0x7 << 28),
>> +};
>
> Jon
>
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay LED Driver
From: Jan Carlo Roleda @ 2026-04-06 7:17 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-kernel, linux-leds, devicetree, Jan Carlo Roleda
In-Reply-To: <20260406-upstream-ltc3208-v3-0-7f0b1d20ee7a@analog.com>
Add Documentation for LTC3208 Multidisplay LED Driver.
Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
---
.../devicetree/bindings/leds/adi,ltc3208.yaml | 129 +++++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 130 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/adi,ltc3208.yaml b/Documentation/devicetree/bindings/leds/adi,ltc3208.yaml
new file mode 100644
index 000000000000..2d53cf70e572
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/adi,ltc3208.yaml
@@ -0,0 +1,129 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2026 Analog Devices, Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/adi,ltc3208.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LTC3208 Multidisplay LED Controller from Linear Technologies (Now Analog Devices)
+
+maintainers:
+ - Jan Carlo Roleda <jancarlo.roleda@analog.com>
+
+description:
+ The LTC3208 is a multidisplay LED controller that can support up to 1A to all
+ connected LEDs.
+
+ The datasheet for this device can be found in
+ https://www.analog.com/en/products/ltc3208.html
+
+properties:
+ compatible:
+ const: adi,ltc3208
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ adi,disable-camhl-pin:
+ type: boolean
+ description:
+ Configures whether the external CAMHL pin is disabled.
+ If disabled then the output pins associated with CAM will always select
+ the CAM register's high half-byte brightness.
+
+ adi,cfg-enrgbs-pin:
+ type: boolean
+ description:
+ Configures which channel the ENRGBS pin toggles when it receives a signal.
+ ENRGBS pin controls the SUB channel's output pins if this is set,
+ or RGB channel's output pins if this is unset.
+
+ adi,disable-rgb-aux4-dropout:
+ type: boolean
+ description:
+ Configures the RGB and AUX4 dropout signals to be disabled.
+
+ adi,aux1-channel:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ LED Channel that the AUX1 output pin mirrors its brightness level from.
+ enum: [aux, main, sub, cam]
+ default: aux
+
+ adi,aux2-channel:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ LED Channel that the AUX2 output pin mirrors its brightness level from.
+ enum: [aux, main, sub, cam]
+ default: aux
+
+ adi,aux3-channel:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ LED Channel that the AUX3 output pin mirrors its brightness level from.
+ enum: [aux, main, sub, cam]
+ default: aux
+
+ adi,aux4-channel:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ LED Channel that the AUX4 output pin mirrors its brightness level from.
+ enum: [aux, main, sub, cam]
+ default: aux
+
+patternProperties:
+ "^led@[0-7]$":
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ description:
+ LED Channel Number. each channel maps to a specific channel group used
+ to configure the brightness level of the output pins corresponding to
+ the channel.
+ enum:
+ - 0 # Main Channel (8-bit brightness)
+ - 1 # Sub Channel (8-bit brightness)
+ - 2 # AUX Channel (4-bit brightness)
+ - 3 # Camera Channel, Low-side byte (4-bit brightness)
+ - 4 # Camera Channel, High-side byte (4-bit brightness)
+ - 5 # Red Channel (4-bit brightness)
+ - 6 # Blue Channel (4-bit brightness)
+ - 7 # Green Channel (4-bit brightness)
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1b {
+ compatible = "adi,ltc3208";
+ reg = <0x1b>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adi,disable-camhl-pin;
+ adi,cfg-enrgbs-pin;
+ adi,disable-rgb-aux4-dropout;
+
+ led@0 {
+ reg = <0>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 48bae02057d5..97072e906928 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15131,6 +15131,7 @@ M: Jan Carlo Roleda <jancarlo.roleda@analog.com>
L: linux-leds@vger.kernel.org
S: Maintained
W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/leds/adi,ltc3208.yaml
F: drivers/leds/leds-ltc3208.c
LTC4282 HARDWARE MONITOR DRIVER
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/2] leds: ltc3208: add driver
From: Jan Carlo Roleda @ 2026-04-06 7:17 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-kernel, linux-leds, devicetree, Jan Carlo Roleda
In-Reply-To: <20260406-upstream-ltc3208-v3-0-7f0b1d20ee7a@analog.com>
Kernel driver implementation for LTC3208 Multidisplay LED Driver
Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
---
MAINTAINERS | 7 ++
drivers/leds/Kconfig | 11 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-ltc3208.c | 298 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 317 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 55af015174a5..48bae02057d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15126,6 +15126,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
F: drivers/iio/temperature/ltc2983.c
+LTC3208 LED DRIVER
+M: Jan Carlo Roleda <jancarlo.roleda@analog.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+W: https://ez.analog.com/linux-software-drivers
+F: drivers/leds/leds-ltc3208.c
+
LTC4282 HARDWARE MONITOR DRIVER
M: Nuno Sa <nuno.sa@analog.com>
L: linux-hwmon@vger.kernel.org
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 597d7a79c988..867b120ea8ba 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -1029,6 +1029,17 @@ config LEDS_ACER_A500
This option enables support for the Power Button LED of
Acer Iconia Tab A500.
+config LEDS_LTC3208
+ tristate "LED Driver for Analog Devices LTC3208"
+ depends on LEDS_CLASS && I2C
+ select REGMAP_I2C
+ help
+ Say Y to enable the LTC3208 LED driver.
+ This supports the LED device LTC3208.
+
+ To compile this driver as a module, choose M here: the module will
+ be called ltc3208.
+
source "drivers/leds/blink/Kconfig"
comment "Flash and Torch LED drivers"
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8fdb45d5b439..b08b539112b6 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_LEDS_LP8788) += leds-lp8788.o
obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
obj-$(CONFIG_LEDS_LP8864) += leds-lp8864.o
obj-$(CONFIG_LEDS_LT3593) += leds-lt3593.o
+obj-$(CONFIG_LEDS_LTC3208) += leds-ltc3208.o
obj-$(CONFIG_LEDS_MAX5970) += leds-max5970.o
obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
obj-$(CONFIG_LEDS_MAX77705) += leds-max77705.o
diff --git a/drivers/leds/leds-ltc3208.c b/drivers/leds/leds-ltc3208.c
new file mode 100644
index 000000000000..65e65cd73d73
--- /dev/null
+++ b/drivers/leds/leds-ltc3208.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LED driver for Analog Devices LTC3208 Multi-Display Driver
+ *
+ * Copyright 2026 Analog Devices Inc.
+ *
+ * Author: Jan Carlo Roleda <jancarlo.roleda@analog.com>
+ */
+#include <linux/bitfield.h>
+#include <linux/errno.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/workqueue.h>
+
+#define LTC3208_SET_HIGH_BYTE_DATA(x) FIELD_PREP(GENMASK(7, 4), (x))
+
+/* Registers */
+#define LTC3208_REG_A_GRNRED 0x1 /* Green (High half-byte) and Red (Low half-byte) current DAC*/
+#define LTC3208_REG_B_AUXBLU 0x2 /* AUX (High half-byte) and Blue (Low half-byte) current DAC*/
+#define LTC3208_REG_C_MAIN 0x3 /* Main current DAC */
+#define LTC3208_REG_D_SUB 0x4 /* Sub current DAC */
+#define LTC3208_REG_E_AUX 0x5 /* AUX DAC Select */
+#define LTC3208_REG_F_CAM 0x6 /* CAM (High half-byte and Low half-byte) current DAC*/
+#define LTC3208_REG_G_OPT 0x7 /* Device Options */
+
+/* Device Options register */
+#define LTC3208_OPT_CPO_MASK GENMASK(7, 6)
+#define LTC3208_OPT_DIS_RGBDROP BIT(3)
+#define LTC3208_OPT_DIS_CAMHILO BIT(2)
+#define LTC3208_OPT_EN_RGBS BIT(1)
+
+/* Auxiliary DAC select masks */
+#define LTC3208_AUX1_MASK GENMASK(1, 0)
+#define LTC3208_AUX2_MASK GENMASK(3, 2)
+#define LTC3208_AUX3_MASK GENMASK(5, 4)
+#define LTC3208_AUX4_MASK GENMASK(7, 6)
+
+#define LTC3208_MAX_BRIGHTNESS_4BIT 0xF
+#define LTC3208_MAX_BRIGHTNESS_8BIT 0xFF
+
+#define LTC3208_NUM_LED_GRPS 8
+#define LTC3208_NUM_AUX_LEDS 4
+
+#define LTC3208_NUM_AUX_OPT 4
+#define LTC3208_MAX_CPO_OPT 3
+
+enum ltc3208_aux_channel {
+ LTC3208_AUX_CHAN_AUX = 0,
+ LTC3208_AUX_CHAN_MAIN,
+ LTC3208_AUX_CHAN_SUB,
+ LTC3208_AUX_CHAN_CAM
+};
+
+enum ltc3208_channel {
+ LTC3208_CHAN_MAIN = 0,
+ LTC3208_CHAN_SUB,
+ LTC3208_CHAN_AUX,
+ LTC3208_CHAN_CAML,
+ LTC3208_CHAN_CAMH,
+ LTC3208_CHAN_RED,
+ LTC3208_CHAN_BLUE,
+ LTC3208_CHAN_GREEN
+};
+
+static const char * const ltc3208_dt_aux_channels[] = {
+ "adi,aux1-channel", "adi,aux2-channel",
+ "adi,aux3-channel", "adi,aux4-channel"
+};
+
+static const char * const ltc3208_aux_opt[] = {
+ "aux", "main", "sub", "cam"
+};
+
+
+struct ltc3208_led {
+ struct led_classdev cdev;
+ struct i2c_client *client;
+ enum ltc3208_channel channel;
+};
+
+struct ltc3208_dev {
+ struct i2c_client *client;
+ struct regmap *map;
+ struct ltc3208_led *leds;
+};
+
+static const struct regmap_config ltc3208_regmap_cfg = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int ltc3208_led_set_brightness(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct ltc3208_led *led = container_of(led_cdev,
+ struct ltc3208_led, cdev);
+ struct i2c_client *client = led->client;
+ struct ltc3208_dev *dev = i2c_get_clientdata(client);
+ struct regmap *map = dev->map;
+ u8 current_level = brightness;
+
+ /*
+ * For registers with 4-bit splits (CAM, AUX/BLUE, GREEN/RED), the other
+ * half of the byte will be retrieved from the stored DAC value before
+ * updating the register.
+ */
+ switch (led->channel) {
+ case LTC3208_CHAN_MAIN:
+ return regmap_write(map, LTC3208_REG_C_MAIN, current_level);
+ case LTC3208_CHAN_SUB:
+ return regmap_write(map, LTC3208_REG_D_SUB, current_level);
+ case LTC3208_CHAN_AUX:
+ /* combine both low and high halves of byte */
+ current_level = LTC3208_SET_HIGH_BYTE_DATA(current_level);
+ current_level |= dev->leds[LTC3208_CHAN_BLUE].cdev.brightness;
+ return regmap_write(map, LTC3208_REG_B_AUXBLU, current_level);
+ case LTC3208_CHAN_BLUE:
+ /* apply high bits stored in other led */
+ current_level |= LTC3208_SET_HIGH_BYTE_DATA(
+ dev->leds[LTC3208_CHAN_AUX].cdev.brightness);
+ return regmap_write(map, LTC3208_REG_B_AUXBLU, current_level);
+ case LTC3208_CHAN_CAMH:
+ current_level = LTC3208_SET_HIGH_BYTE_DATA(current_level);
+ current_level |= dev->leds[LTC3208_CHAN_CAML].cdev.brightness;
+ return regmap_write(map, LTC3208_REG_F_CAM, current_level);
+ case LTC3208_CHAN_CAML:
+ current_level |= LTC3208_SET_HIGH_BYTE_DATA(
+ dev->leds[LTC3208_CHAN_CAMH].cdev.brightness);
+ return regmap_write(map, LTC3208_REG_F_CAM, current_level);
+ case LTC3208_CHAN_GREEN:
+ current_level = LTC3208_SET_HIGH_BYTE_DATA(current_level);
+ current_level |= dev->leds[LTC3208_CHAN_RED].cdev.brightness;
+ return regmap_write(map, LTC3208_REG_A_GRNRED, current_level);
+ case LTC3208_CHAN_RED:
+ current_level |= LTC3208_SET_HIGH_BYTE_DATA(
+ dev->leds[LTC3208_CHAN_GREEN].cdev.brightness);
+ return regmap_write(map, LTC3208_REG_A_GRNRED, current_level);
+ default:
+ dev_err(&client->dev, "Invalid LED Channel\n");
+ return -EINVAL;
+ }
+}
+
+static int ltc3208_update_options(struct ltc3208_dev *dev,
+ bool is_sub, bool is_cam_hi, bool is_rgb_drop)
+{
+ struct regmap *map = dev->map;
+ u8 val = FIELD_PREP(LTC3208_OPT_EN_RGBS, is_sub) |
+ FIELD_PREP(LTC3208_OPT_DIS_CAMHILO, is_cam_hi) |
+ FIELD_PREP(LTC3208_OPT_DIS_RGBDROP, is_rgb_drop);
+
+ return regmap_write(map, LTC3208_REG_G_OPT, val);
+}
+
+static int ltc3208_update_aux_dac(struct ltc3208_dev *dev,
+ enum ltc3208_aux_channel aux_1, enum ltc3208_aux_channel aux_2,
+ enum ltc3208_aux_channel aux_3, enum ltc3208_aux_channel aux_4)
+{
+ struct regmap *map = dev->map;
+ u8 val = FIELD_PREP(LTC3208_AUX1_MASK, aux_1) |
+ FIELD_PREP(LTC3208_AUX2_MASK, aux_2) |
+ FIELD_PREP(LTC3208_AUX3_MASK, aux_3) |
+ FIELD_PREP(LTC3208_AUX4_MASK, aux_4);
+
+ return regmap_write(map, LTC3208_REG_E_AUX, val);
+}
+
+static int ltc3208_probe(struct i2c_client *client)
+{
+ enum ltc3208_aux_channel aux_channels[LTC3208_NUM_AUX_LEDS];
+ struct ltc3208_dev *data;
+ struct ltc3208_led *leds;
+ struct regmap *map;
+ int ret, i;
+ u32 val;
+ bool dropdis_rgb_aux4;
+ bool dis_camhl;
+ bool en_rgbs;
+
+ map = devm_regmap_init_i2c(client, <c3208_regmap_cfg);
+ if (IS_ERR(map))
+ return dev_err_probe(&client->dev, PTR_ERR(map),
+ "Failed to initialize regmap\n");
+
+ data = devm_kzalloc(&client->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ leds = devm_kcalloc(&client->dev, LTC3208_NUM_LED_GRPS,
+ sizeof(struct ltc3208_led), GFP_KERNEL);
+ if (!leds)
+ return -ENOMEM;
+
+ data->client = client;
+ data->map = map;
+
+ /* initialize options from devicetree */
+ dis_camhl = device_property_read_bool(&client->dev,
+ "adi,disable-camhl-pin");
+ en_rgbs = device_property_read_bool(&client->dev,
+ "adi,cfg-enrgbs-pin");
+ dropdis_rgb_aux4 = device_property_read_bool(&client->dev,
+ "adi,disable-rgb-aux4-dropout");
+
+ ret = ltc3208_update_options(data, en_rgbs, dis_camhl,
+ dropdis_rgb_aux4);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "error writing to options register\n");
+
+ /* initialize aux channel configurations from devicetree */
+ for (i = 0; i < LTC3208_NUM_AUX_LEDS; i++) {
+ ret = device_property_match_property_string(&client->dev,
+ ltc3208_dt_aux_channels[i],
+ ltc3208_aux_opt,
+ LTC3208_NUM_AUX_OPT);
+ /* use default value if absent in devicetree */
+ if (ret == -EINVAL)
+ aux_channels[i] = LTC3208_AUX_CHAN_AUX;
+ else if (ret >= 0)
+ aux_channels[i] = ret;
+ else
+ return dev_err_probe(&client->dev, ret,
+ "Failed getting aux-channel.\n");
+ }
+
+ ret = ltc3208_update_aux_dac(data, aux_channels[0], aux_channels[1],
+ aux_channels[2], aux_channels[3]);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "error writing to aux %u channel register.\n", i);
+
+ i2c_set_clientdata(client, data);
+
+ device_for_each_child_node_scoped(&client->dev, child) {
+ struct ltc3208_led *led;
+ struct led_init_data init_data = {};
+
+ ret = fwnode_property_read_u32(child, "reg", &val);
+ if (ret || val >= LTC3208_NUM_LED_GRPS)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Invalid reg property for LED\n");
+
+ led = &leds[val];
+ led->client = client;
+ led->channel = val;
+ led->cdev.brightness_set_blocking = ltc3208_led_set_brightness;
+ led->cdev.max_brightness = LTC3208_MAX_BRIGHTNESS_4BIT;
+ if (val == LTC3208_CHAN_MAIN || val == LTC3208_CHAN_SUB)
+ led->cdev.max_brightness = LTC3208_MAX_BRIGHTNESS_8BIT;
+
+ init_data.fwnode = child;
+
+ ret = devm_led_classdev_register_ext(&client->dev, &led->cdev,
+ &init_data);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "Failed to register LED %u\n", val);
+ }
+
+ data->leds = leds;
+
+ return 0;
+}
+
+static const struct of_device_id ltc3208_match_table[] = {
+ {.compatible = "adi,ltc3208"},
+ { }
+};
+MODULE_DEVICE_TABLE(of, ltc3208_match_table);
+
+static const struct i2c_device_id ltc3208_idtable[] = {
+ { "ltc3208" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, ltc3208_idtable);
+
+static struct i2c_driver ltc3208_driver = {
+ .driver = {
+ .name = "ltc3208",
+ .of_match_table = ltc3208_match_table,
+ },
+ .id_table = ltc3208_idtable,
+ .probe = ltc3208_probe,
+};
+module_i2c_driver(ltc3208_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jan Carlo Roleda <jancarlo.roleda@analog.com>");
+MODULE_DESCRIPTION("LTC3208 LED Driver");
--
2.43.0
^ permalink raw reply related
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