* Re: [PATCH v4 0/2] Introduce TLMM driver for Qualcomm IPQ5210 SoC
From: Kathiravan Thirumoorthy @ 2026-04-06 9:04 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <CAD++jLkwGT2SxQrax5FFF2x6CznQF_03N_FC6-2n7OAiNH3Xng@mail.gmail.com>
On 3/30/2026 2:11 PM, Linus Walleij wrote:
> On Mon, Mar 30, 2026 at 6:51 AM Kathiravan Thirumoorthy
> <kathiravan.thirumoorthy@oss.qualcomm.com> wrote:
>
>> The IPQ5210 is Qualcomm's SoC for Routers, Gateways and Access Points.
>> Add the pinctrl support for the same.
>>
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> Patches applied!
Linus, I don't see these patches in linux-next or in linux-pinctrl tree.
Do I miss something here?
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Milos crypto engine
From: Kuldeep Singh @ 2026-04-06 8:59 UTC (permalink / raw)
To: Alexander Koskovich, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: linux-crypto, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260405-milos-qce-v1-1-6996fb0b8a9c@pm.me>
On 4/6/2026 7:40 AM, Alexander Koskovich wrote:
> Document the crypto engine on the Milos platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Milos crypto engine
From: Krzysztof Kozlowski @ 2026-04-06 8:45 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-crypto, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260405-milos-qce-v1-1-6996fb0b8a9c@pm.me>
On Mon, Apr 06, 2026 at 02:10:07AM +0000, Alexander Koskovich wrote:
> Document the crypto engine on the Milos platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: moxa,moxart-rtc: convert to YAML
From: Krzysztof Kozlowski @ 2026-04-06 8:44 UTC (permalink / raw)
To: Avi Radinsky
Cc: alexandre.belloni, robh, krzk+dt, conor+dt, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <CAK=E+3BLMV35g1hC2=aQ57yKxgw1y8qR8ufpHQdKcx4MdT9ioA@mail.gmail.com>
On Sun, Apr 05, 2026 at 09:31:36PM -0400, Avi Radinsky wrote:
> Convert the MOXA ART Real Time Clock text binding to YAML schema.
>
Same comments as for other try.
Also, do not duplicate work.
I don't find hopping on this entire GSoC program, while doing duplicated
and uncoordinated work with same issues, helpful.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
From: Krzysztof Kozlowski @ 2026-04-06 8:41 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Baojun Xu, Conor Dooley, Kevin Lu,
Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Rob Herring,
Shenghao Ding, linux-kernel, linux-sound
In-Reply-To: <20260405234502.154227-1-marex@nabladev.com>
On Mon, Apr 06, 2026 at 01:44:35AM +0200, Marek Vasut wrote:
> Add missing sound-sai-cells for this codec into schema.
> At the same time, drop trailing spaces from description.
>
> Fixes: 506e0825a4c9 ("ASoC: dt-bindings: Convert ti,tas2552 to DT schema")
> Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Krzysztof Kozlowski @ 2026-04-06 8:37 UTC (permalink / raw)
To: Harshal Dev, 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, Konrad Dybcio,
Kuldeep Singh, Krzysztof Kozlowski
In-Reply-To: <20260323-qcom_ice_power_and_clk_vote-v4-1-e36044bbdfe9@oss.qualcomm.com>
On 23/03/2026 10:17, 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(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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:35 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
* [PATCH v1 9/9] ARM: tegra: tf600t: Invert accelerometer calibration matrix
From: Svyatoslav Ryhel @ 2026-04-06 8:34 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>
IMU calibration matrix used in the device tree is inverted when testing on
the device which results in wrong screen orientation. Invert it to match
the matrix dumped from the device.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 0bebea0cb8c4..5c634b0f3f46 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -1091,9 +1091,9 @@ imu@69 {
vdd-supply = <&vdd_3v3_sys>;
vddio-supply = <&vdd_1v8_vio>;
- mount-matrix = "0", "-1", "0",
- "-1", "0", "0",
- "0", "0", "-1";
+ mount-matrix = "0", "1", "0",
+ "1", "0", "0",
+ "0", "0", "1";
/* External I2C interface */
i2c-gate {
--
2.51.0
^ permalink raw reply related
* [PATCH v1 8/9] ARM: tegra: tf600t: Drop backlight regulator
From: Svyatoslav Ryhel @ 2026-04-06 8:34 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>
Drop dedicated backlight regulator since the GPIO used in it is actually
SFIO controlling backlight and setting it as GPIO causes backlight to
freeze at maximum level.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 8b68bfef8dee..0bebea0cb8c4 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -2192,7 +2192,7 @@ backlight: backlight {
compatible = "pwm-backlight";
enable-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_HIGH>;
- power-supply = <&vdd_5v0_bl>;
+ power-supply = <&vdd_5v0_sys>;
pwms = <&pwm 0 71428>;
brightness-levels = <1 255>;
@@ -2422,17 +2422,6 @@ vdd_3v3_als: regulator-als {
vin-supply = <&vdd_3v3_sys>;
};
- vdd_5v0_bl: regulator-bl {
- compatible = "regulator-fixed";
- regulator-name = "vdd_5v0_bl";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-boot-on;
- gpio = <&gpio TEGRA_GPIO(H, 0) GPIO_ACTIVE_HIGH>;
- enable-active-high;
- vin-supply = <&vdd_5v0_bat>;
- };
-
vdd_panel: regulator-panel {
compatible = "regulator-fixed";
regulator-name = "vdd_panel";
--
2.51.0
^ permalink raw reply related
* [PATCH v1 7/9] ARM: tegra: tf600t: Configure panel
From: Svyatoslav Ryhel @ 2026-04-06 8:34 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>
Configure DSI panel used in ASUS VivoTab TF600T.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../boot/dts/nvidia/tegra30-asus-tf600t.dts | 62 ++++++++++++++++++-
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 9296e7970ce4..8b68bfef8dee 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -23,6 +23,7 @@ aliases {
rtc0 = &pmic;
rtc1 = "/rtc@7000e000";
+ display0 = &lcd;
display1 = &hdmi;
serial1 = &uartc; /* Bluetooth */
@@ -55,6 +56,37 @@ linux,cma@80000000 {
};
host1x@50000000 {
+ vi@54080000 {
+ status = "okay";
+
+ csi@800 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_ppa_input: endpoint {
+ /* Link to the rear camera */
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vi_ppb_input: endpoint {
+ /* Link to the front camera */
+ };
+ };
+ };
+ };
+
hdmi: hdmi@54280000 {
status = "okay";
@@ -68,6 +100,22 @@ hdmi_out: endpoint {
};
};
};
+
+ lcd: dsi@54300000 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+
+ panel@0 {
+ compatible = "hydis,hv101hd1";
+ reg = <0>;
+
+ vdd-supply = <&vdd_panel>;
+ vio-supply = <&vio_panel>;
+
+ backlight = <&backlight>;
+ };
+ };
};
vde@6001a000 {
@@ -1123,11 +1171,10 @@ pmic-sleep-hog {
};
regulators {
- vdd_lcd: vdd1 {
+ vio_panel: vdd1 {
regulator-name = "vddio_ddr_1v2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
- regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <8>;
};
@@ -2386,6 +2433,17 @@ vdd_5v0_bl: regulator-bl {
vin-supply = <&vdd_5v0_bat>;
};
+ vdd_panel: regulator-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_panel";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ gpio = <&gpio TEGRA_GPIO(L, 4) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
+
hdmi_5v0_sys: regulator-hdmi {
compatible = "regulator-fixed";
regulator-name = "hdmi_5v0_sys";
--
2.51.0
^ permalink raw reply related
* [PATCH v1 6/9] ARM: tegra: transformers: Add connector node for common trees
From: Svyatoslav Ryhel @ 2026-04-06 8:34 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>
All ASUS Transformers have micro-HDMI connector directly available. After
Tegra HDMI got bridge/connector support, we should use connector framework
for proper HW description.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30
Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../tegra20-asus-transformer-common.dtsi | 22 ++++++++++++++++---
.../tegra30-asus-transformer-common.dtsi | 21 ++++++++++++++++--
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi
index 73c7ee378865..fe05cfd2312f 100644
--- a/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi
@@ -79,9 +79,11 @@ hdmi@54280000 {
pll-supply = <&hdmi_pll_reg>;
hdmi-supply = <&vdd_hdmi_en>;
- nvidia,ddc-i2c-bus = <&hdmi_ddc>;
- nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7)
- GPIO_ACTIVE_HIGH>;
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
};
};
@@ -1029,6 +1031,20 @@ key-volume-up {
};
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "d";
+
+ hpd-gpios = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
+ ddc-i2c-bus = <&hdmi_ddc>;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+ };
+
i2cmux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
index d4a7bae51830..76db928b53bc 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
@@ -166,8 +166,11 @@ hdmi: hdmi@54280000 {
pll-supply = <&vdd_1v8_vio>;
vdd-supply = <&vdd_3v3_sys>;
- nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
- nvidia,ddc-i2c-bus = <&hdmi_ddc>;
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
};
};
@@ -1701,6 +1704,20 @@ key-volume-up {
};
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "d";
+
+ hpd-gpios = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
+ ddc-i2c-bus = <&hdmi_ddc>;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+ };
+
vdd_5v0_bat: regulator-bat {
compatible = "regulator-fixed";
regulator-name = "vdd_ac_bat";
--
2.51.0
^ permalink raw reply related
* [PATCH v1 5/9] ARM: tegra: transformer: Add support for front camera
From: Svyatoslav Ryhel @ 2026-04-06 8:34 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. Aptina MI1040 camera is used on all supported
ASUS Transformers, but only TF201 and TF700T will work since on
TF300T/TG/TL front camera is linked through an additional ISP.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../tegra30-asus-transformer-common.dtsi | 138 +++++++++++++++++-
1 file changed, 137 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
index 0e06136042a9..d4a7bae51830 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-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/thermal/thermal.h>
#include "tegra30.dtsi"
@@ -73,6 +74,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>;
+ /* Add 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>;
+ };
+ };
+ };
+ };
+
hdmi: hdmi@54280000 {
status = "okay";
@@ -1173,6 +1259,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 = <&vdd_1v8_cam>;
+ vdd-supply = <&vdd_1v8_cam>;
+ vaa-supply = <&avdd_2v85_fcam>;
+
+ 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>;
+ };
+ };
+ };
+
gyroscope@68 {
compatible = "invensense,mpu3050";
reg = <0x68>;
@@ -1310,7 +1426,7 @@ ldo4 {
/* LDO5 is not used by Transformers */
- ldo6 {
+ avdd_dsi_csi: ldo6 {
regulator-name = "avdd_dsi_csi,pwrdet_mipi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
@@ -1685,6 +1801,26 @@ hdmi_5v0_sys: regulator-hdmi {
vin-supply = <&vdd_5v0_sys>;
};
+ vdd_1v8_cam: regulator-viocam {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_1v8_cam";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio TEGRA_GPIO(BB, 4) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_1v8_vio>;
+ };
+
+ avdd_2v85_fcam: regulator-avcam-front {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_2v85_fcam";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ gpio = <&gpio TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
+
sound {
nvidia,i2s-controller = <&tegra_i2s1>;
--
2.51.0
^ permalink raw reply related
* [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
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