* Re: [PATCH v5 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
From: sashiko-bot @ 2026-07-19 18:12 UTC (permalink / raw)
To: David Heidelberg; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260719-pixel3-camera-v5-2-99593f1bd8ec@ixit.cz>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] A preexisting logical error in the teardown and error paths of `leds-qcom-flash.c` reads out-of-bounds of the `v4l2_flash` array, causing it to either leak successfully initialized V4L2 flash devices or trigger a kernel panic.
--
--- Patch [2]: [PATCH v5 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs ---
commit 93ed1a73fa53c221bf41460abbfe7fe7c99737a0
Author: David Heidelberg <david@ixit.cz>
arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
Enable the PMI8998 flash LED block and describe two white flash LEDs
used for the rear camera.
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
[ ... ]
> +&pmi8998_flash {
> + status = "okay";
> +
> + /* upper part */
> + led-0 {
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <1>;
> + led-max-microamp = <500000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1280000>;
> + function-enumerator = <0>;
> + };
> +
> + /* bottom part */
> + led-1 {
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <2>;
> + led-max-microamp = <500000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1280000>;
> + function-enumerator = <1>;
> + };
> +};
[Severity: High]
This is a pre-existing issue, but configuring multiple flash LEDs exposes an
out-of-bounds array access in the leds-qcom-flash driver.
During driver teardown in qcom_flash_led_remove(), the code attempts to
access the v4l2_flash array at index leds_count:
drivers/leds/flash/leds-qcom-flash.c:qcom_flash_led_remove() {
...
while (flash_data->v4l2_flash[flash_data->leds_count] &&
flash_data->leds_count)
v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);
...
}
If the probe is successful, leds_count equals the number of LEDs. Accessing
the array at that index reads past the end of the dynamically allocated
structure, potentially causing a panic or leaking resources if the
out-of-bounds memory happens to be NULL.
The probe error path in qcom_flash_led_probe() shares this logic. If probing
fails on the second LED, v4l2_flash at that index is NULL. The loop
evaluates to false immediately and terminates without freeing the
successfully initialized first LED.
Could we fix the array bounds check and release logic in the driver before
exposing it via this multi-LED device tree configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz?part=2
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] nfc: s3fwrn5: support the S3NRN4V variant
From: Jorijn van der Graaf @ 2026-07-19 18:09 UTC (permalink / raw)
To: David Heidelberg, Luca Weiss, Krzysztof Kozlowski
Cc: Jorijn van der Graaf, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Conor Dooley,
oe-linux-nfc, netdev, devicetree, linux-kernel
In-Reply-To: <5d26f3ae-1287-4440-bd38-96c9900f16ea@ixit.cz>
Hello David,
On 19/07/2026 16:56, David Heidelberg wrote:
> now it makes more sense to me, feel free to name it as calibration
> data.
Will do -- v3 will say "RF calibration data" in the commit message and
comments.
> I would suggest to introduce something as a calibration-variant (see
> ath10k code).
>
> If I understand right, firmware location path could look like
>
> default path + driver vendor and model + device vendor and model +
> revision
>
> /lib/firmware/ + Samsung/s3nrn4v/ + Fairphone/FP5/hwrevision.bin
That layout makes sense to me. My inclination for v3:
- request the files from a chip-scoped directory:
samsung/s3nrn4v/hwreg.bin + samsung/s3nrn4v/swreg.bin (the existing
parts' sec_s3fwrn5_rfreg.bin is untouched);
- an optional samsung,calibration-variant string property (modelled
on ath10k's qcom,calibration-variant) that, when set, makes the
driver try a device-scoped location first, e.g.
samsung/s3nrn4v/fairphone-fp6/hwreg.bin, falling back to the bare
files above.
The variant lookup can also be added compatibly later, once a second
S3NRN4V design (or a diverging FP6 revision) actually appears -- so
if you'd rather keep v3 minimal, I'd do only the directory move now
and add the property when first needed. Either works for me.
So far I have seen no evidence of per-revision or per-region variants
on the FP6: the only difference I have identified between my two
units' tables is the vendor software release (build-date stamps).
But Fairphone would know better.
> /cc Luca here, as he may know more about the different configuration
> data shipped.
Luca, two questions your way:
- do FP6 hardware revisions (or regional SKUs) ship different NFC
hwreg/swreg tables, or is it one set per software release?
- could Fairphone submit these tables to linux-firmware? I assume
the redistribution question sits with Fairphone/Samsung, and having
them there would make NFC work out of the box on mainline.
> We should assume the configuration will be shipped with
> linux-firmware at some point.
Agreed -- that is exactly why I'd like to settle the path scheme now.
v3 is otherwise ready, including the Fairphone 6 DT patch; rather
than sending it right away as I said earlier today, I'll give this
a few days for Luca's input and then send it.
Thanks,
Jorijn
^ permalink raw reply
* [PATCH] dt-bindings: remoteproc: ti,wkup-m3: Convert to DT schema
From: Bhargav Joshi @ 2026-07-19 18:06 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Suman Anna
Cc: linux-remoteproc, devicetree, linux-kernel, goledhruva,
m-chawdhry, daniel.baluta, simona.toaca, j.bhargav.u
Convert Texas Instruments Wakeup M3 Remote Processor from text to Dt
schema. Add optional resets and reset-names property which was missing
from legacy binding. make ti,hwmods deprecated as it no longer needed,
it is kept to support older board files without ti,sysc.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
.../bindings/remoteproc/ti,am3352-wkup-m3.yaml | 89 ++++++++++++++++++++++
.../bindings/remoteproc/wkup_m3_rproc.txt | 52 -------------
2 files changed, 89 insertions(+), 52 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,am3352-wkup-m3.yaml b/Documentation/devicetree/bindings/remoteproc/ti,am3352-wkup-m3.yaml
new file mode 100644
index 000000000000..9e8a03acdec4
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/ti,am3352-wkup-m3.yaml
@@ -0,0 +1,89 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/ti,am3352-wkup-m3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI AM33xx/AM43xx Wakeup M3 Remote Processor
+
+maintainers:
+ - Suman Anna <s-anna@ti.com>
+ - Bhargav Joshi <j.bhargav.u@gmail.com>
+
+description:
+ The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
+ (commonly referred to as Wakeup M3 or CM3) to help with various low power
+ tasks that cannot be controlled from the MPU. This CM3 processor requires a
+ firmware binary to accomplish this. A wkup_m3 device node is used to
+ represent the Wakeup M3 processor instance within the SoC. It is added as a
+ child node of the parent interconnect bus (l4_wkup) through which it is
+ accessible to the MPU.
+
+properties:
+ compatible:
+ enum:
+ - ti,am3352-wkup-m3
+ - ti,am4372-wkup-m3
+
+ reg:
+ items:
+ - description: Address range for UMEM
+ - description: Address range for DMEM
+
+ reg-names:
+ items:
+ - const: umem
+ - const: dmem
+
+ ti,pm-firmware:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ Name of firmware file to be used for loading and booting the wkup_m3
+ remote processor.
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: rstctrl
+
+ ti,hwmods:
+ $ref: /schemas/types.yaml#/definitions/string
+ deprecated: true
+ description:
+ Name of the hwmod associated with the wkupm3 device.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,pm-firmware
+
+dependencies:
+ resets: [reset-names]
+ reset-names: [resets]
+
+additionalProperties: false
+
+examples:
+ - |
+ target-module@0 {
+ compatible = "ti,sysc-omap4", "ti,sysc";
+ reg = <0x0 0x4>;
+ reg-names = "rev";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00000000 0x00000000 0x4000>,
+ <0x00080000 0x00080000 0x2000>;
+
+ cpu@0 {
+ compatible = "ti,am3352-wkup-m3";
+ reg = <0x00000000 0x4000>,
+ <0x00080000 0x2000>;
+ reg-names = "umem", "dmem";
+ resets = <&prm_wkup 3>;
+ reset-names = "rstctrl";
+ ti,pm-firmware = "am335x-pm-firmware.elf";
+ };
+ };
diff --git a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt b/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
deleted file mode 100644
index 3a70073797eb..000000000000
--- a/Documentation/devicetree/bindings/remoteproc/wkup_m3_rproc.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-TI Wakeup M3 Remoteproc Driver
-==============================
-
-The TI AM33xx and AM43xx family of devices use a small Cortex M3 co-processor
-(commonly referred to as Wakeup M3 or CM3) to help with various low power tasks
-that cannot be controlled from the MPU. This CM3 processor requires a firmware
-binary to accomplish this. The wkup_m3 remoteproc driver handles the loading of
-the firmware and booting of the CM3.
-
-Wkup M3 Device Node:
-====================
-A wkup_m3 device node is used to represent the Wakeup M3 processor instance
-within the SoC. It is added as a child node of the parent interconnect bus
-(l4_wkup) through which it is accessible to the MPU.
-
-Required properties:
---------------------
-- compatible: Should be one of,
- "ti,am3352-wkup-m3" for AM33xx SoCs
- "ti,am4372-wkup-m3" for AM43xx SoCs
-- reg: Should contain the address ranges for the two internal
- memory regions, UMEM and DMEM. The parent node should
- provide an appropriate ranges property for properly
- translating these into bus addresses.
-- reg-names: Contains the corresponding names for the two memory
- regions. These should be named "umem" & "dmem".
-- ti,hwmods: Name of the hwmod associated with the wkupm3 device.
-- ti,pm-firmware: Name of firmware file to be used for loading and
- booting the wkup_m3 remote processor.
-
-Example:
---------
-/* AM33xx */
-ocp {
- l4_wkup: l4_wkup@44c00000 {
- compatible = "am335-l4-wkup", "simple-bus";
- ranges = <0 0x44c00000 0x400000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- wkup_m3: wkup_m3@100000 {
- compatible = "ti,am3352-wkup-m3";
- reg = <0x100000 0x4000>,
- <0x180000 0x2000>;
- reg-names = "umem", "dmem";
- ti,hwmods = "wkup_m3";
- ti,pm-firmware = "am335x-pm-firmware.elf";
- };
- };
-
- ...
-};
---
base-commit: c6859eed755df351a3978b33cb92365f9b3e8f06
change-id: 20260719-ti-wkup_m3-edac718d0d7c
Best regards,
--
Bhargav
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay
From: Vishnu Saini @ 2026-07-19 18:05 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Vishnu Saini,
venkata.valluru, Jessica Zhang
In-Reply-To: <20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com>
The QCS6490 RB3 Gen2 industrial mezzanine supports LVDS display output
using the Lontium LT9211C DSI-to-LVDS bridge as an alternative to the
default HDMI output via the LT9611UXC bridge.
Add a DTBO overlay,
qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso, that
disables HDMI (hdmi-connector and lt9611_codec) and wires up the LT9211C
bridge on I2C1 (address 0x29) with reset on GPIO117. The overlay adds a
dual-channel panel-lvds node for a 1920x1080 panel with VESA-24 mapping and
148.5 MHz pixel clock.
The overlay is built as a composite DTB combining the base
qcs6490-rb3gen2.dtb, the industrial mezzanine overlay, and this LVDS
overlay.
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 4 +
...industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso | 110 +++++++++++++++++++++
2 files changed, 114 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 85ee28d8f109..bd8db14c5acf 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -189,6 +189,10 @@ qcs6490-rb3gen2-vision-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-vis
qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
+
+qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2-industrial-mezzanine.dtbo qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-minipc-g1iot.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso
new file mode 100644
index 000000000000..65af68850342
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ model = "Qualcomm Technologies, Inc. rb3gen2 industrial mezzanine lvds";
+
+ hdmi-connector {
+ status = "disabled";
+ };
+
+ panel_lvds: panel-lvds {
+ compatible = "boe,dv215fhm-r01", "panel-lvds";
+ data-mapping = "vesa-24";
+ width-mm = <476>;
+ height-mm = <268>;
+
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ hsync-len = <44>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ de-active = <1>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in_lvds_odd: endpoint {
+ remote-endpoint = <<9211c_out_odd>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in_lvds_even: endpoint {
+ remote-endpoint = <<9211c_out_even>;
+ };
+ };
+ };
+ };
+};
+
+&i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ lvds_bridge: lvds-bridge@29 {
+ compatible = "lontium,lt9211c";
+ reg = <0x29>;
+ reset-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+ vccio-supply = <&vreg_l1c_1p8>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lt9211c_in: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ lt9211c_out_odd: endpoint {
+ remote-endpoint = <&panel_in_lvds_odd>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ lt9211c_out_even: endpoint {
+ remote-endpoint = <&panel_in_lvds_even>;
+ };
+ };
+ };
+ };
+};
+
+<9611_codec {
+ status = "disabled";
+};
+
+&mdss_dsi0_out {
+ remote-endpoint = <<9211c_in>;
+};
+
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: qcom: monaco-evk: Add LVDS display overlay
From: Vishnu Saini @ 2026-07-19 18:05 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Vishnu Saini,
venkata.valluru, Jessica Zhang
In-Reply-To: <20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com>
The Monaco EVK IFP mezzanine supports LVDS display output using the
Lontium LT9211C DSI-to-LVDS bridge. The bridge is connected to the
DSI0 output and drives a dual-channel 1920x1080 LVDS panel in
VESA-24 mapping.
Add a DTBO overlay, monaco-evk-lvds-boe,dv215fhm-r01.dtso, that wires up
the LT9211C bridge on I2C8 (address 0x2d) with reset on GPIO66, a
panel-lvds node describing the 476x268mm 1080p panel timing, and an LCD
display bias regulator supplied through the GPIO expander. DSI power is
provided by vreg_l5a with PHY supply from vreg_l4a.
The overlay is built as a composite DTB combining the base
monaco-evk.dtb, the IFP mezzanine overlay, and this LVDS overlay.
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 4 +
.../dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso | 131 +++++++++++++++++++++
2 files changed, 135 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 2c4e7a891717..85ee28d8f109 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -73,6 +73,10 @@ monaco-evk-el2-dtbs := monaco-evk.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-el2.dtb
monaco-evk-ifp-mezzanine-dtbs := monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-ifp-mezzanine.dtb
+
+monaco-evk-lvds-boe,dv215fhm-r01-dtbs := monaco-evk.dtb monaco-evk-ifp-mezzanine.dtbo monaco-evk-lvds-boe,dv215fhm-r01.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += monaco-evk-lvds-boe,dv215fhm-r01.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += msm8216-samsung-fortuna3g.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-acer-a1-724.dtb
dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso
new file mode 100644
index 000000000000..d62f6baeca85
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ model = "Qualcomm Technologies, Inc. Monaco-EVK Mezzanine Lvds";
+
+ panel_lvds: panel-lvds {
+ compatible = "boe,dv215fhm-r01", "panel-lvds";
+ data-mapping = "vesa-24";
+ width-mm = <476>;
+ height-mm = <268>;
+ power-supply = <&lcd_disp_bias>;
+
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ hsync-len = <44>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ de-active = <1>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in_lvds_odd: endpoint {
+ remote-endpoint = <<9211c_out_odd>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in_lvds_even: endpoint {
+ remote-endpoint = <<9211c_out_even>;
+ };
+ };
+ };
+ };
+
+ lcd_disp_bias: regulator-lcd-disp-bias {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_disp_bias";
+ regulator-min-microvolt = <5500000>;
+ regulator-max-microvolt = <5500000>;
+ gpio = <&expander3 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&i2c8 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c8_data_clk>;
+
+ status = "okay";
+
+ lt9211c_codec: lvds-bridge@2d {
+ compatible = "lontium,lt9211c";
+ reg = <0x2d>;
+ reset-gpios = <&tlmm 66 GPIO_ACTIVE_HIGH>;
+ vccio-supply = <&vreg_l5a>;
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lt9211c_in: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ lt9211c_out_odd: endpoint {
+ remote-endpoint = <&panel_in_lvds_odd>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ lt9211c_out_even: endpoint {
+ remote-endpoint = <&panel_in_lvds_even>;
+ };
+ };
+ };
+ };
+};
+
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&vreg_l5a>;
+ status = "okay";
+};
+
+&mdss_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <<9211c_in>;
+};
+
+&mdss_dsi0_phy {
+ vdds-supply = <&vreg_l4a>;
+ status = "okay";
+};
+
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: qcom: lemans-evk: Add LVDS display overlay
From: Vishnu Saini @ 2026-07-19 18:05 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Vishnu Saini,
venkata.valluru, Jessica Zhang
In-Reply-To: <20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com>
The Lemans EVK IFP mezzanine supports LVDS display output using the
Lontium LT9211C DSI-to-LVDS bridge. The bridge is connected to the
DSI0 output and drives a dual-channel 1920x1080 LVDS panel in
VESA-24 mapping.
Add a DTBO overlay, lemans-evk-lvds-boe,dv215fhm-r01.dtso, that wires
up the LT9211C bridge on I2C1 (address 0x2d) with reset on GPIO37,
a panel-lvds node describing the 476x268mm 1080p panel timing, and
an LCD display bias regulator supplied through the GPIO expander.
DSI power is provided by vreg_s4a.
The overlay is built as a composite DTB combining the base
lemans-evk.dtb, the IFP mezzanine overlay, and this LVDS overlay.
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 4 +
.../dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso | 127 +++++++++++++++++++++
2 files changed, 131 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 5a1c56cf98f6..2c4e7a891717 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -55,6 +55,10 @@ lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-el2.dtb
lemans-evk-ifp-mezzanine-dtbs := lemans-evk.dtb lemans-evk-ifp-mezzanine.dtbo
dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-ifp-mezzanine.dtb
+
+lemans-evk-lvds-boe,dv215fhm-r01-dtbs := lemans-evk.dtb lemans-evk-ifp-mezzanine.dtbo lemans-evk-lvds-boe,dv215fhm-r01.dtbo
+dtb-$(CONFIG_ARCH_QCOM) += lemans-evk-lvds-boe,dv215fhm-r01.dtb
+
dtb-$(CONFIG_ARCH_QCOM) += mahua-crd.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-fairphone-fp6.dtb
dtb-$(CONFIG_ARCH_QCOM) += milos-nothing-asteroids.dtb
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso
new file mode 100644
index 000000000000..17c20e86e950
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ model = "Qualcomm Technologies, Inc. Lemans-evk Mezzanine Lvds";
+
+ panel_lvds: panel-lvds {
+ compatible = "boe,dv215fhm-r01", "panel-lvds";
+ data-mapping = "vesa-24";
+ width-mm = <476>;
+ height-mm = <268>;
+ power-supply = <&lcd_disp_bias>;
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <148500000>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hfront-porch = <88>;
+ hback-porch = <148>;
+ hsync-len = <44>;
+ vfront-porch = <4>;
+ vback-porch = <36>;
+ vsync-len = <5>;
+ de-active = <1>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ panel_in_lvds_odd: endpoint {
+ remote-endpoint = <<9211c_out_odd>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ panel_in_lvds_even: endpoint {
+ remote-endpoint = <<9211c_out_even>;
+ };
+ };
+ };
+ };
+
+ lcd_disp_bias: regulator-lcd-disp-bias {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_disp_bias";
+ regulator-min-microvolt = <5500000>;
+ regulator-max-microvolt = <5500000>;
+ gpio = <&expander3 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&qup_i2c1_default>;
+ status = "okay";
+
+ lt9211c_codec: lvds-bridge@2d {
+ compatible = "lontium,lt9211c";
+ reg = <0x2d>;
+ reset-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+ vccio-supply = <&vreg_s4a>;
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ lt9211c_in: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&mdss0_dsi0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ lt9211c_out_odd: endpoint {
+ remote-endpoint = <&panel_in_lvds_odd>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ lt9211c_out_even: endpoint {
+ remote-endpoint = <&panel_in_lvds_even>;
+ };
+ };
+ };
+ };
+};
+
+&mdss0 {
+ status = "okay";
+};
+
+&mdss0_dsi0 {
+ vdda-supply = <&vreg_l1c>;
+ status = "okay";
+};
+
+&mdss0_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <<9211c_in>;
+};
+
+&mdss0_dsi0_phy {
+ vdds-supply = <&vreg_l4a>;
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: qcom: Add LVDS display overlays for lemans, monaco and rb3gen2
From: Vishnu Saini @ 2026-07-19 18:05 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Vishnu Saini,
venkata.valluru, Jessica Zhang
This series adds LVDS display support via device tree overlays for three
Qualcomm platforms: SA8775P Lemans EVK, SA8295P/QCS8300 Monaco EVK, and
QCS6490 RB3 Gen2 industrial mezzanine.
All three platforms use the Lontium LT9211C DSI-to-LVDS bridge chip, which
converts DSI output to dual-channel LVDS for driving 1920x1080 panels.
The overlays follow the established composite-DTB pattern already in use
on these platforms (IFP mezzanine, camera, el2) and are structured to be
applied on top of the existing IFP mezzanine overlay.
Each overlay:
- Wires the LT9211C bridge to the DSI output via an I2C node
- Defines a generic dual-channel panel-lvds node with VESA-24 mapping
targeting a 1920x1080 (476x268mm) panel at 148.5 MHz pixel clock
- Provides an LCD bias regulator through the GPIO expander
This series depends on:
[PATCH v6 0/2] This series adds LT9211C bridge driver by extending LT9211
https://lore.kernel.org/all/20260719-add-lt9211c-bridge-v6-0-e56d22152586@oss.qualcomm.com/
which adds lontium,lt9211c compatible support to the lontium-lt9211 driver
and extends the binding YAML accordingly, and:
[PATCH] dt-bindings: display: panel-lvds: Add boe,dv215fhm-r01
https://lore.kernel.org/all/20260719-b4-lvds-panel-doc-v1-1-6a18c213c2f6@oss.qualcomm.com/
which documents the boe,dv215fhm-r01 panel compatible used by these overlays.
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
Vishnu Saini (3):
arm64: dts: qcom: lemans-evk: Add LVDS display overlay
arm64: dts: qcom: monaco-evk: Add LVDS display overlay
arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay
arch/arm64/boot/dts/qcom/Makefile | 12 ++
.../dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso | 127 ++++++++++++++++++++
.../dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso | 131 +++++++++++++++++++++
...industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso | 110 +++++++++++++++++
4 files changed, 380 insertions(+)
---
base-commit: f86573e68e56a7df7d54eb58101ac413ba731996
change-id: 20260708-lvds-support-2d40d60654f1
prerequisite-message-id: <20260719-add-lt9211c-bridge-v6-0-e56d22152586@oss.qualcomm.com>
prerequisite-patch-id: dbba64d1ace696df388c5df3d1cb05a0701df194
prerequisite-patch-id: 7729b9c67a7c274b25fea08635dfede3fc604ae9
prerequisite-message-id: <20260719-b4-lvds-panel-doc-v1-1-6a18c213c2f6@oss.qualcomm.com>
prerequisite-patch-id: 4e67c4a837c7fe490e7c5d34a243543c76685eb5
Best regards,
--
Vishnu Saini <vishnu.saini@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: David Heidelberg via B4 Relay @ 2026-07-19 18:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel, David Heidelberg
In-Reply-To: <20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz>
From: David Heidelberg <david@ixit.cz>
The Pixel 3 features two front-facing Sony IMX355 sensors with
different focal lengths (standard and wide-angle).
Sensors are connected via CSIPHY port 1 and 2 and controlled over CCI
I2C1, using MCLK2 as the clock source.
This enables support for the dual front camera configuration.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 170 ++++++++++++++++++++-
1 file changed, 169 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index 9368fd6b87515..cb5c261802bc9 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -1,16 +1,17 @@
// SPDX-License-Identifier: GPL-2.0-only
/dts-v1/;
#include <dt-bindings/arm/qcom,ids.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
#include "pm8998.dtsi"
#include "pmi8998.dtsi"
/delete-node/ &mpss_region;
/delete-node/ &venus_mem;
@@ -127,16 +128,48 @@ vreg_s4a_1p8: regulator-vreg-s4a-1p8 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-boot-on;
vin-supply = <&vph_pwr>;
};
+ camera_front_avdd: front-cam-avdd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "front_cam_avdd";
+
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ gpios = <&tlmm 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_avdd_default_pin>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_bob>;
+ };
+
+ camera_front_aux_avdd: front-cam-aux-avdd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "front_cam_aux_avdd";
+
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ gpios = <&tlmm 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_aux_avdd_default_pin>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_bob>;
+ };
+
wcn3990-pmu {
compatible = "qcom,wcn3990-pmu";
vddio-supply = <&vreg_s4a_1p8>;
vddxo-supply = <&vreg_l7a_1p8>;
vddrf-supply = <&vreg_l17a_1p3>;
vddch0-supply = <&vreg_l25a_3p3>;
@@ -314,16 +347,21 @@ vreg_l28a_3p0: ldo28 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
regulator-boot-on;
/*
* We can't properly bring the panel back if it gets turned off
* so keep it's regulators always on for now.
*/
regulator-always-on;
};
+
+ vreg_lvs1_1p8: lvs1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
regulators-1 {
compatible = "qcom,pmi8998-rpmh-regulators";
qcom,pmic-id = "b";
vdd-bob-supply = <&vph_pwr>;
@@ -346,24 +384,126 @@ regulators-2 {
vreg_s3c_0p6: smps3 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <600000>;
};
};
};
+&camss {
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l26a_1p2>;
+
+ /*
+ * MCLK2 (GPIO15) is shared between both front camera sensors.
+ * The clock is generated by CAMCC, therefore the pin is
+ * configured here rather than in individual sensor nodes.
+ */
+ pinctrl-0 = <&cam_mclk2_default>;
+ pinctrl-1 = <&cam_mclk2_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ camss_endpoint1: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_aux_front_endpoint>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ camss_endpoint2: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_front_endpoint>;
+ };
+ };
+ };
+};
+
+&cci0_sleep {
+ /* bus has external pull-up, don't pull down */
+ bias-disable;
+};
+
&cci {
status = "okay";
};
&cci_i2c1 {
/* actuator @0c */
- /* front camera, imx355 @1a */
+ front_cam: camera@10 {
+ compatible = "sony,imx355";
+ reg = <0x10>;
+
+ clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ reset-gpios = <&tlmm 21 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&camera_front_avdd>;
+ dvdd-supply = <&vreg_s3a_1p35>;
+ dovdd-supply = <&vreg_lvs1_1p8>;
+
+ pinctrl-0 = <&cam_front_reset_default_pin>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint2>;
+ };
+ };
+ };
+
+ front_aux_cam: camera@1a {
+ compatible = "sony,imx355";
+ reg = <0x1a>;
+
+ clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&camera_front_aux_avdd>;
+ dvdd-supply = <&vreg_s3a_1p35>;
+ dovdd-supply = <&vreg_lvs1_1p8>;
+
+ pinctrl-0 = <&cam_front_aux_reset_default_pin>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_aux_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint1>;
+ };
+ };
+ };
/* eeprom @50, at24 driver says 8K */
};
&cdsp_pas {
firmware-name = "qcom/sdm845/Google/blueline/cdsp.mbn";
status = "okay";
@@ -485,16 +625,44 @@ nfc_int_default: nfc-int-default-state {
nfc_enable_default: nfc-enable-default-state {
pins = "gpio25", "gpio79";
function = "gpio";
drive-strength = <2>;
bias-pull-down;
};
+ cam_front_avdd_default_pin: cam-avdd-default-pins {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_aux_reset_default_pin: cam-front-aux-reset-default-pins {
+ pins = "gpio9";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_aux_avdd_default_pin: cam-avdd-aux-default-pins {
+ pins = "gpio14";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_reset_default_pin: cam-front-reset-default-pins {
+ pins = "gpio21";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
touchscreen_reset: ts-reset-state {
pins = "gpio99";
function = "gpio";
drive-strength = <8>;
bias-pull-up;
};
touchscreen_pins: ts-pins-gpio-state {
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/2] Add initial dual front camera and rear flash support for Pixel 3 / 3 XL
From: David Heidelberg via B4 Relay @ 2026-07-19 18:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel, David Heidelberg
Describe the dual front-facing IMX355 sensors (standard and wide)
and enable the PMI8998 flash LED with hardware-accurate limits.
This brings up the basic camera topology and flash support in DT.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v5:
- Added function-enumarator to flash LEDs. (Sashiko)
- Dropped l22a regulator needed only for NFOV actuator. (Sashiko)
- Dropped vdda-csi[0-2]-supply, as it was unused. (Sashiko).
- Added previously omited cam_mclk2_sleep sleep state.
- Link to v4: https://lore.kernel.org/r/20260719-pixel3-camera-v4-0-48cab1236852@ixit.cz
Changes in v4:
- Use 24 MHz ext clock for the cameras, as the downstream does, since
the upstream driver can now support it.
- Added additional LED, as the phone contains two separately controlled
white LEDs flash (upper and bottom, in one module).
- Increase flash-max-microamp, as I took wrong "flash" from the
downstream sources and dropped Dmitry R-b.
- Address formatting issues. (Konrad)
- Link to v3: https://lore.kernel.org/r/20260412-pixel3-camera-v3-0-e26b090a6110@ixit.cz
Changes in v3:
- Dropped cam_vio label. (Dmitry)
- Move the MCLK2 pinctrl from cameras to common camss. (Dmitry)
- Link to v2: https://lore.kernel.org/r/20260411-pixel3-camera-v2-0-41b889abb14c@ixit.cz
Changes in v2:
- leds.h include escaped the initial submission. Fixed.
- Link to v1: https://lore.kernel.org/r/20260411-pixel3-camera-v1-0-2757606515b6@ixit.cz
---
David Heidelberg (2):
arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 197 ++++++++++++++++++++-
1 file changed, 196 insertions(+), 1 deletion(-)
---
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
change-id: 20260315-pixel3-camera-a9989bf589ee
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH v5 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
From: David Heidelberg via B4 Relay @ 2026-07-19 18:03 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel, David Heidelberg
In-Reply-To: <20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Enable the PMI8998 flash LED block and describe two white flash LEDs
used for the rear camera.
Configure the LED in flash mode with hardware limits matching the
original device configuration, including maximum current and timeout.
In contrary to downstream, we can control both LEDs separately.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index cb5c261802bc9..f3c7333a4076e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -1,16 +1,17 @@
// SPDX-License-Identifier: GPL-2.0-only
/dts-v1/;
#include <dt-bindings/arm/qcom,ids.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
#include "pm8998.dtsi"
#include "pmi8998.dtsi"
/delete-node/ &mpss_region;
@@ -589,16 +590,42 @@ &pm8998_resin {
};
&pmi8998_charger {
monitored-battery = <&battery>;
status = "okay";
};
+&pmi8998_flash {
+ status = "okay";
+
+ /* upper part */
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1280000>;
+ function-enumerator = <0>;
+ };
+
+ /* bottom part */
+ led-1 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <2>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1280000>;
+ function-enumerator = <1>;
+ };
+};
+
&qupv3_id_0 {
status = "okay";
};
&qupv3_id_1 {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: sashiko-bot @ 2026-07-19 17:15 UTC (permalink / raw)
To: David Heidelberg; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260719-pixel3-camera-v4-1-48cab1236852@ixit.cz>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Hardware Pin Configuration Error overriding `cci0_sleep` instead of `cci1_sleep`, causing power drainage.
- [High] Placing the `MCLK2` pinctrl configuration in the `&camss` node creates a severe probe ordering race condition.
- [Medium] Mismatch between the commit message asserting both sensors share CSIPHY1 and the Device Tree mapping them to separate PHYs.
- [Medium] The `vreg_l22a_3p3` regulator is defined with a voltage of 2.864V instead of 3.3V and causes a continuous power leak.
- [Low] Addition of undocumented and unsupported `vdda-csiX-supply` properties in the CAMSS node.
--
--- Patch [1]: [PATCH v4 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras ---
commit 24802f71e3152de09fabf33fc17c82719cd2b67b
Author: David Heidelberg <david@ixit.cz>
arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
This commit adds device tree nodes for the Pixel 3's dual front-facing Sony
IMX355 sensors. It describes the camera nodes, MCLK2 clock source, CCI I2C1
bus connections, and associated regulators.
> The Pixel 3 features two front-facing Sony IMX355 sensors with
> different focal lengths (standard and wide-angle).
>
> Both sensors are connected via CSIPHY1 and controlled over CCI I2C1,
[Severity: Medium]
Is this commit message description accurate?
The device tree maps the endpoints to port@1 (CSIPHY1) and port@2 (CSIPHY2).
Because both sensors request 4 data lanes (data-lanes = <1 2 3 4>), is it
possible for them to concurrently share a single 4-lane CSIPHY without a
hardware multiplexer?
Could the commit message be updated to reflect the actual hardware
connectivity shown in the device tree?
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
[ ... ]
> @@ -288,6 +324,12 @@ vreg_l21a_2p95: ldo21 {
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
>
> + vreg_l22a_3p3: ldo22 {
> + regulator-min-microvolt = <2864000>;
> + regulator-max-microvolt = <2864000>;
> + regulator-boot-on;
> + };
> +
[Severity: Medium]
Does this regulator configuration inadvertently cause a continuous power leak?
The label indicates 3.3V, but the voltage is constrained to 2.864V. Also,
this regulator does not appear to be used by any device node in the device
tree, yet it is marked with regulator-boot-on. Should this unused, boot-on
regulator be removed to prevent battery drain?
[ ... ]
> +&camss {
> + vdda-phy-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l26a_1p2>;
> +
> + vdda-csi0-supply = <&vdda_mipi_csi0_0p9>;
> + vdda-csi1-supply = <&vdda_mipi_csi1_0p9>;
> + vdda-csi2-supply = <&vdda_mipi_csi2_0p9>;
[Severity: Low]
Will adding these properties cause dtbs_check validation errors?
The upstream qcom,sdm845-camss.yaml devicetree binding explicitly specifies
additionalProperties: false and only supports vdda-phy-supply and
vdda-pll-supply. Are these undocumented vdda-csiX-supply properties ignored
by the Linux camss driver?
> +
> + /*
> + * MCLK2 (GPIO15) is shared between both front camera sensors.
> + * The clock is generated by CAMSS, therefore the pin is
> + * configured here rather than in individual sensor nodes.
> + */
> + pinctrl-0 = <&cam_mclk2_default>;
> + pinctrl-names = "default";
> +
[Severity: High]
Does placing the MCLK2 pinctrl configuration in the &camss node create a
probe ordering race condition?
The comment states the clock is generated by CAMSS, but the clock is actually
generated by camcc. Since the sensors rely on camcc and the I2C controller,
they may probe before the camss node is initialized.
If the sensors attempt an initial I2C read before camss probes, the MCLK2
pinmux will not be applied to GPIO15, causing the clock signal to be missing
and the probe to intermittently fail. Should this pinctrl be managed
elsewhere to guarantee availability during sensor probe?
[ ... ]
> +&cci0_sleep {
> + /* bus has external pull-up, don't pull down */
> + bias-disable;
> +};
> +
[Severity: High]
Is this bias-disable override applied to the correct I2C bus?
The front cameras are connected to the cci_i2c1 bus. However, this override
is applied to the &cci0_sleep pinctrl node (which controls cci_i2c0 pins),
instead of the required &cci1_sleep node (which controls cci_i2c1 pins).
Will this leave the cci_i2c1 bus with its default bias-pull-down in sleep
mode, drawing current through the external pull-up and draining the battery?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-pixel3-camera-v4-0-48cab1236852@ixit.cz?part=1
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
From: sashiko-bot @ 2026-07-19 17:09 UTC (permalink / raw)
To: David Heidelberg; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260719-pixel3-camera-v4-2-48cab1236852@ixit.cz>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `function-enumerator` property causes LED sysfs name collision, leading to non-standard fallback naming.
--
--- Patch [2]: [PATCH v4 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs ---
commit b5868918114efddab825d07ade0f191b5b3123e1
Author: David Heidelberg <david@ixit.cz>
arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
This commit enables the PMI8998 flash LED block and describes two white
flash LEDs used for the rear camera. The LEDs are configured in flash mode
with hardware limits matching the original device configuration.
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
[ ... ]
> +&pmi8998_flash {
> + status = "okay";
> +
> + /* upper part */
> + led-0 {
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <1>;
> + led-max-microamp = <500000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1280000>;
> + };
> +
> + /* bottom part */
> + led-1 {
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
[Severity: Medium]
Does this missing function-enumerator property cause a sysfs name
collision?
Since both led-0 and led-1 share the identical color (LED_COLOR_ID_WHITE)
and function (LED_FUNCTION_FLASH), they both evaluate to the base name
white:flash.
Without a function-enumerator, the LED core's led_classdev_register_ext()
detects a collision on the second LED and falls back to appending an
underscore and a counter. This results in the sysfs nodes white:flash and
white:flash_1 instead of the modern standard LED naming convention
(white:flash-0 and white:flash-1) which user-space managers rely on for
consistent hardware discovery.
Could we add function-enumerator = <0>; to led-0 and
function-enumerator = <1>; to led-1 to ensure standard naming?
> + led-sources = <2>;
> + led-max-microamp = <500000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1280000>;
> + };
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-pixel3-camera-v4-0-48cab1236852@ixit.cz?part=2
^ permalink raw reply
* Re: [PATCH v2 5/6] hwmon: (adt7470) Register as a PWM provider
From: Uwe Kleine-König @ 2026-07-19 17:04 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chris Packham, Andrew Morton, Darrick J. Wong, linux-hwmon,
devicetree, linux-kernel, linux-pwm
In-Reply-To: <20260717-adt7470_thermalzone-v2-5-a55147958fad@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
Hello,
On Fri, Jul 17, 2026 at 05:59:18PM -0300, Luiz Angelo Daros de Luca wrote:
> @@ -864,6 +865,57 @@ static int adt7470_pwm_write(struct device *dev, u32 attr, int channel, long val
> return err;
> }
>
> +static int adt7470_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + struct adt7470_data *data = pwmchip_get_drvdata(chip);
> + unsigned int pwm_auto_reg_mask;
> + int err;
> + u8 val;
> +
> + if (pwm->hwpwm % 2)
> + pwm_auto_reg_mask = ADT7470_PWM2_AUTO_MASK;
> + else
> + pwm_auto_reg_mask = ADT7470_PWM1_AUTO_MASK;
> +
> + if (state->enabled && state->period > 0)
> + val = DIV_ROUND_CLOSEST_ULL(state->duty_cycle * 255, state->period);
rounding a division using closest is wrong in the context of PWM.
Also state->duty_cycle * 255 might overflow and you have to use the
actual period in the calculation of val instead of the requested value.
> + else
> + val = 0;
> +
> + mutex_lock(&data->lock);
If you use guard(), the control flow simplifies and using goto becomes
unnecessary.
> + if (data->pwm[pwm->hwpwm] == val &&
> + data->pwm_automatic[pwm->hwpwm] == 0) {
> + mutex_unlock(&data->lock);
> + return 0;
> + }
> +
> + /* Put the PWM channel in manual mode before updating it. */
> + err = regmap_update_bits(data->regmap,
> + ADT7470_REG_PWM_CFG(pwm->hwpwm),
> + pwm_auto_reg_mask, 0);
> + if (err < 0)
> + goto out;
> +
> + data->pwm_automatic[pwm->hwpwm] = 0;
> +
> + err = regmap_write(data->regmap,
> + ADT7470_REG_PWM(pwm->hwpwm), val);
> + if (err < 0)
> + goto out;
> +
> + data->pwm[pwm->hwpwm] = val;
> +out:
> + mutex_unlock(&data->lock);
> +
> + return err;
> +}
> +
> +static const struct pwm_ops adt7470_pwm_ops = {
> + .apply = adt7470_pwm_apply,
For new drivers please implement .round_waveform_tohw(),
.round_waveform_fromhw(), .write_waveform() and ideally so
.read_waveform().
> +};
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
From: David Heidelberg via B4 Relay @ 2026-07-19 17:02 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel, David Heidelberg
In-Reply-To: <20260719-pixel3-camera-v4-0-48cab1236852@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Enable the PMI8998 flash LED block and describe two white flash LEDs
used for the rear camera.
Configure the LED in flash mode with hardware limits matching the
original device configuration, including maximum current and timeout.
In contrary to downstream, we can control both LEDs separately.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index ad6f61b3baa21..0ce48c4647f17 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -1,16 +1,17 @@
// SPDX-License-Identifier: GPL-2.0-only
/dts-v1/;
#include <dt-bindings/arm/qcom,ids.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
#include "pm8998.dtsi"
#include "pmi8998.dtsi"
/delete-node/ &mpss_region;
@@ -601,16 +602,40 @@ &pm8998_resin {
};
&pmi8998_charger {
monitored-battery = <&battery>;
status = "okay";
};
+&pmi8998_flash {
+ status = "okay";
+
+ /* upper part */
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1280000>;
+ };
+
+ /* bottom part */
+ led-1 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <2>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1280000>;
+ };
+};
+
&qupv3_id_0 {
status = "okay";
};
&qupv3_id_1 {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 0/2] Add initial dual front camera and rear flash support for Pixel 3 / 3 XL
From: David Heidelberg via B4 Relay @ 2026-07-19 17:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel, David Heidelberg
Describe the dual front-facing IMX355 sensors (standard and wide)
and enable the PMI8998 flash LED with hardware-accurate limits.
This brings up the basic camera topology and flash support in DT.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v4:
- Use 24 MHz ext clock for the cameras, as the downstream does, since
the upstream driver can now support it.
- Added additional LED, as the phone contains two separately controlled
white LEDs flash (upper and bottom, in one module).
- Increase flash-max-microamp, as I took wrong "flash" from the
downstream sources and dropped Dmitry R-b.
- Address formatting issues. (Konrad)
- Link to v3: https://lore.kernel.org/r/20260412-pixel3-camera-v3-0-e26b090a6110@ixit.cz
Changes in v3:
- Dropped cam_vio label. (Dmitry)
- Move the MCLK2 pinctrl from cameras to common camss. (Dmitry)
- Link to v2: https://lore.kernel.org/r/20260411-pixel3-camera-v2-0-41b889abb14c@ixit.cz
Changes in v2:
- leds.h include escaped the initial submission. Fixed.
- Link to v1: https://lore.kernel.org/r/20260411-pixel3-camera-v1-0-2757606515b6@ixit.cz
---
David Heidelberg (2):
arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 207 ++++++++++++++++++++-
1 file changed, 206 insertions(+), 1 deletion(-)
---
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
change-id: 20260315-pixel3-camera-a9989bf589ee
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH v4 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: David Heidelberg via B4 Relay @ 2026-07-19 17:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel, David Heidelberg
In-Reply-To: <20260719-pixel3-camera-v4-0-48cab1236852@ixit.cz>
From: David Heidelberg <david@ixit.cz>
The Pixel 3 features two front-facing Sony IMX355 sensors with
different focal lengths (standard and wide-angle).
Both sensors are connected via CSIPHY1 and controlled over CCI I2C1,
using MCLK2 as the clock source. Describe the camera nodes and
associated resources in the device tree.
This enables support for the dual front camera configuration.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 182 ++++++++++++++++++++-
1 file changed, 181 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index 9368fd6b87515..ad6f61b3baa21 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -1,16 +1,17 @@
// SPDX-License-Identifier: GPL-2.0-only
/dts-v1/;
#include <dt-bindings/arm/qcom,ids.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
#include "pm8998.dtsi"
#include "pmi8998.dtsi"
/delete-node/ &mpss_region;
/delete-node/ &venus_mem;
@@ -127,16 +128,48 @@ vreg_s4a_1p8: regulator-vreg-s4a-1p8 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-boot-on;
vin-supply = <&vph_pwr>;
};
+ camera_front_avdd: front-cam-avdd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "front_cam_avdd";
+
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ gpios = <&tlmm 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_avdd_default_pin>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_bob>;
+ };
+
+ camera_front_aux_avdd: front-cam-aux-avdd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "front_cam_aux_avdd";
+
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ gpios = <&tlmm 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_aux_avdd_default_pin>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_bob>;
+ };
+
wcn3990-pmu {
compatible = "qcom,wcn3990-pmu";
vddio-supply = <&vreg_s4a_1p8>;
vddxo-supply = <&vreg_l7a_1p8>;
vddrf-supply = <&vreg_l17a_1p3>;
vddch0-supply = <&vreg_l25a_3p3>;
@@ -209,16 +242,19 @@ vreg_s5a_2p04: smps5 {
regulator-max-microvolt = <2040000>;
};
vreg_s7a_1p025: smps7 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1028000>;
};
+ vdda_mipi_csi0_0p9:
+ vdda_mipi_csi1_0p9:
+ vdda_mipi_csi2_0p9:
vdda_mipi_dsi0_pll:
vreg_l1a_0p875: ldo1 {
regulator-min-microvolt = <880000>;
regulator-max-microvolt = <880000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
regulator-boot-on;
};
@@ -283,16 +319,22 @@ vreg_l20a_2p95: ldo20 {
};
vreg_l21a_2p95: ldo21 {
regulator-min-microvolt = <2960000>;
regulator-max-microvolt = <2968000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
+ vreg_l22a_3p3: ldo22 {
+ regulator-min-microvolt = <2864000>;
+ regulator-max-microvolt = <2864000>;
+ regulator-boot-on;
+ };
+
vreg_l24a_3p075: ldo24 {
regulator-min-microvolt = <3088000>;
regulator-max-microvolt = <3088000>;
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
vreg_l25a_3p3: ldo25 {
regulator-min-microvolt = <3300000>;
@@ -314,16 +356,21 @@ vreg_l28a_3p0: ldo28 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
regulator-boot-on;
/*
* We can't properly bring the panel back if it gets turned off
* so keep it's regulators always on for now.
*/
regulator-always-on;
};
+
+ vreg_lvs1_1p8: lvs1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
regulators-1 {
compatible = "qcom,pmi8998-rpmh-regulators";
qcom,pmic-id = "b";
vdd-bob-supply = <&vph_pwr>;
@@ -346,24 +393,129 @@ regulators-2 {
vreg_s3c_0p6: smps3 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <600000>;
};
};
};
+&camss {
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l26a_1p2>;
+
+ vdda-csi0-supply = <&vdda_mipi_csi0_0p9>;
+ vdda-csi1-supply = <&vdda_mipi_csi1_0p9>;
+ vdda-csi2-supply = <&vdda_mipi_csi2_0p9>;
+
+ /*
+ * MCLK2 (GPIO15) is shared between both front camera sensors.
+ * The clock is generated by CAMSS, therefore the pin is
+ * configured here rather than in individual sensor nodes.
+ */
+ pinctrl-0 = <&cam_mclk2_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ camss_endpoint1: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_aux_front_endpoint>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ camss_endpoint2: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_front_endpoint>;
+ };
+ };
+ };
+};
+
+&cci0_sleep {
+ /* bus has external pull-up, don't pull down */
+ bias-disable;
+};
+
&cci {
status = "okay";
};
&cci_i2c1 {
/* actuator @0c */
- /* front camera, imx355 @1a */
+ front_cam: camera@10 {
+ compatible = "sony,imx355";
+ reg = <0x10>;
+
+ clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ reset-gpios = <&tlmm 21 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&camera_front_avdd>;
+ dvdd-supply = <&vreg_s3a_1p35>;
+ dovdd-supply = <&vreg_lvs1_1p8>;
+
+ pinctrl-0 = <&cam_front_reset_default_pin>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint2>;
+ };
+ };
+ };
+
+ front_aux_cam: camera@1a {
+ compatible = "sony,imx355";
+ reg = <0x1a>;
+
+ clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&camera_front_aux_avdd>;
+ dvdd-supply = <&vreg_s3a_1p35>;
+ dovdd-supply = <&vreg_lvs1_1p8>;
+
+ pinctrl-0 = <&cam_front_aux_reset_default_pin>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_aux_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint1>;
+ };
+ };
+ };
/* eeprom @50, at24 driver says 8K */
};
&cdsp_pas {
firmware-name = "qcom/sdm845/Google/blueline/cdsp.mbn";
status = "okay";
@@ -485,16 +637,44 @@ nfc_int_default: nfc-int-default-state {
nfc_enable_default: nfc-enable-default-state {
pins = "gpio25", "gpio79";
function = "gpio";
drive-strength = <2>;
bias-pull-down;
};
+ cam_front_avdd_default_pin: cam-avdd-default-pins {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_aux_reset_default_pin: cam-front-aux-reset-default-pins {
+ pins = "gpio9";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_aux_avdd_default_pin: cam-avdd-aux-default-pins {
+ pins = "gpio14";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_reset_default_pin: cam-front-reset-default-pins {
+ pins = "gpio21";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
touchscreen_reset: ts-reset-state {
pins = "gpio99";
function = "gpio";
drive-strength = <8>;
bias-pull-up;
};
touchscreen_pins: ts-pins-gpio-state {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/4] Add support for Versal Xilsem edac
From: Borislav Petkov @ 2026-07-19 16:27 UTC (permalink / raw)
To: Rama devi Veggalam
Cc: tony.luck, michal.simek, robh, krzk+dt, conor+dt, linux-kernel,
linux-edac, devicetree, james.morse, mchehab, rric, git
In-Reply-To: <20260624212545.2850787-1-rama.devi.veggalam@amd.com>
On Thu, Jun 25, 2026 at 02:55:41AM +0530, Rama devi Veggalam wrote:
> Add sysfs interface for Xilsem scan operations initialize, start,
> stop scan, error inject, read ECC, status and configuration values.
> Handle correctable and uncorrectable xilsem error events.
A lot of issues caught by Sashiko:
https://sashiko.dev/#/patchset/20260624212545.2850787-1-rama.devi.veggalam%40amd.com
they need to be addressed first, before adding anything new.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: fix label of sys_led for nanopi-r4s
From: sashiko-bot @ 2026-07-19 16:19 UTC (permalink / raw)
To: Vic B; +Cc: robh, devicetree, conor+dt
In-Reply-To: <alz112qGhm77liqi@vicb.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The patch assigns a new value to the deprecated `label` property instead of modernizing the LED Device Tree binding to use `color` and `function`.
--
--- Patch [1]: [PATCH] arm64: dts: rockchip: fix label of sys_led for nanopi-r4s ---
commit ceee1e0876cda2fa407388b630cd3de2ef149410
Author: Vic B <linux@vicb.net>
arm64: dts: rockchip: fix label of sys_led for nanopi-r4s
This commit corrects the system LED configuration for the NanoPi R4S by
changing the label from red:power to green:sys. It aligns the device tree
with the physical board schematics.
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
> index 4274d1b6e80ae..6fbc76e2e679e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
> @@ -31,7 +31,7 @@ lan_led: led-lan {
>
> sys_led: led-sys {
> gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
> - label = "red:power";
> + label = "green:sys";
[Severity: Low]
Since the label property is deprecated in modern LED Device Tree bindings,
would it be better to replace this with the color and function properties?
Modern user-space LED managers rely on standard sysfs directories named
color:function. Defining the LED using the color and function properties
would align the driver with current subsystem guidelines and prevent
userspace from relying on the legacy label field to correctly identify
the hardware role.
> default-state = "on";
> };
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/alz112qGhm77liqi@vicb.net?part=1
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix label of sys_led for nanopi-r4s
From: Vic B @ 2026-07-19 16:05 UTC (permalink / raw)
To: linux-kernel, linux-rockchip, devicetree, Heiko Stuebner,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, Jensen Huang
The sys_led of NanoPi R4S is labeled as SYS on the board and on the
original case, and it is green, not red.
The board also has a red power led, but that one is connected to 3V3
and cannot be controled via GPIO.
The above can checked on page 17 of board's schematics at
https://wiki.friendlyelec.com/wiki/images/0/06/NanoPi-R4S-1GB-2008-Schematic.pdf
This patch changes the label for sys_led from red:power to green:sys.
Signed-off-by: Vic B <linux@vicb.net>
---
arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
index 4274d1b6e80a..6fbc76e2e679 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
@@ -31,7 +31,7 @@ lan_led: led-lan {
sys_led: led-sys {
gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
- label = "red:power";
+ label = "green:sys";
default-state = "on";
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] dt-bindings: display: panel-lvds: Add boe,dv215fhm-r01 compatible
From: sashiko-bot @ 2026-07-19 16:15 UTC (permalink / raw)
To: Vishnu Saini; +Cc: robh, dri-devel, conor+dt, devicetree
In-Reply-To: <20260719-b4-lvds-panel-doc-v1-1-6a18c213c2f6@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Removing 'port' from the global required list without conditional replacements allows all panels to omit their display controller connection.
- [Medium] The schema fails to apply the dual-LVDS binding for the new dual-channel panel, breaking validation for pixel-order properties.
--
--- Patch [1]: [PATCH] dt-bindings: display: panel-lvds: Add boe,dv215fhm-r01 compatible ---
commit dda569bad0ff68efade6e9633f374c324001833a
Author: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
dt-bindings: display: panel-lvds: Add boe,dv215fhm-r01 compatible
This commit adds the BOE DV215FHM-R01 21.5" dual-channel LVDS panel
to the panel-lvds binding. It also removes the global port requirement
to allow dual-channel panels to use the ports topology with separate
port@0 and port@1 nodes.
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> index b89f86bc06837..584818b2df6ea 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
[ ... ]
> @@ -72,6 +74,12 @@ properties:
>
> - const: panel-lvds
>
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> + description:
> + For dual-channel LVDS panels, use 'ports' with port@0 for odd pixels
> + and port@1 for even pixels instead of the single 'port' property.
[Severity: Medium]
Since the boe,dv215fhm-r01 compatible requires dual-LVDS properties like
dual-lvds-odd-pixels and dual-lvds-even-pixels in its ports, shouldn't this
schema conditionally reference /schemas/display/lvds-dual-ports.yaml?
Without referencing the dual-LVDS schema, won't these properties fail
validation as unrecognized properties, or fail to have their mandatory
presence enforced when someone instantiates this dual-channel panel?
> +
> unevaluatedProperties: false
>
> required:
> @@ -80,6 +88,4 @@ required:
> - width-mm
> - height-mm
> - panel-timing
> - - port
> -
> ...
[Severity: High]
Does removing port from the global required list without providing
conditional replacements allow all existing single-channel LVDS panels to
silently pass validation even if they omit their display controller
connection?
Would it be safer to enforce this requirement using an anyOf block such as
anyOf: [{required: [port]}, {required: [ports]}], or to use conditional
if-then blocks to ensure validation constraints for prior generations are
not globally relaxed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-b4-lvds-panel-doc-v1-1-6a18c213c2f6@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: add support for lontium lt9211c bridge
From: sashiko-bot @ 2026-07-19 16:12 UTC (permalink / raw)
To: vishnu.saini; +Cc: conor+dt, dri-devel, robh, devicetree
In-Reply-To: <20260719-add-lt9211c-bridge-v6-2-e56d22152586@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] Missing cancellation of the delayed work in the disable path leads to I2C writes to an unpowered/reset device.
- [High] The delayed work timer is not cancelled during driver removal, resulting in a critical use-after-free.
- [High] The dynamically allocated workqueue is leaked if probe fails during host attach.
- [High] LVDS format configurations (bpp24, jeida, de) are left uninitialized when queuing the delayed work, resulting in incorrect hardware configuration.
- [High] Deferring hardware enablement to a delayed workqueue violates DRM atomic subsystem guarantees.
- [Low] Signed error codes from `regmap_write()` are accumulated using bitwise OR, mangling the error values.
--
--- Patch [2]: [PATCH v6 2/2] drm/bridge: add support for lontium lt9211c bridge ---
commit 1ae4415156f1af5c0293e73eda918915f0e313c8
Author: Yi Zhang <zhanyi@qti.qualcomm.com>
drm/bridge: add support for lontium lt9211c bridge
Adds support for the LT9211C variant to the existing lt9211 driver.
It detects the chip by ID, adds a new regmap for LT9211C, and implements
DSI-to-LVDS init sequences. A delayed workqueue is used to configure
LT9211C after the DSI clock is running.
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c b/drivers/gpu/drm/bridge/lontium-lt9211.c
> index f39d83a5ae377..36c004df34fcd 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9211.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9211.c
> @@ -454,6 +526,651 @@ static int lt9211_configure_tx(struct lt9211 *ctx, bool jeida,
> [ ... ]
> +static int lt9211c_configure_plls(struct lt9211 *ctx,
> + const struct drm_display_mode *mode)
> +{
> [ ... ]
> + if (mode->clock < 44000) {
> + ret = regmap_write(ctx->regmap, 0xd00c, 0x60);
> + ret |= regmap_write(ctx->regmap, 0xd01b, 0x00);
> + ret |= regmap_write(ctx->regmap, 0xd01c, 0x60);
> + } else {
> + ret = regmap_write(ctx->regmap, 0xd00c, 0x40);
> + ret |= regmap_write(ctx->regmap, 0xd01b, 0x00);
> + ret |= regmap_write(ctx->regmap, 0xd01c, 0x40);
> + }
[Severity: Low]
Does using bitwise OR here mangle the signed error codes returned by
regmap_write()?
Accumulating negative error values via bitwise OR creates a different
negative value, which destroys the semantic meaning of the original error
code.
> [ ... ]
> @@ -523,6 +1240,15 @@ static void lt9211_atomic_enable(struct drm_bridge *bridge,
> if (ret)
> return;
>
> + if (ctx->chip_type == LT9211C && ctx->wq) {
> + drm_mode_copy(&ctx->mode, mode);
> + /* LT9211C must enable after mipi clock enable */
> + queue_delayed_work(ctx->wq, &ctx->lt9211_dw,
> + msecs_to_jiffies(100));
> + dev_dbg(ctx->dev, "LT9211C enabled.\n");
> + return;
> + }
[Severity: High]
Does this code fail to save the LVDS format configurations to the context
struct?
The variables jeida, bpp24, and de are extracted from the bridge state
earlier in this function, but they are never saved to ctx->jeida, ctx->bpp24,
or ctx->de before queuing the work. When lt9211c_configure_tx() runs later
in the workqueue, won't it read uninitialized (zero) values for these fields?
[Severity: High]
By deferring the hardware initialization to a delayed workqueue, does this
introduce a regression violating the DRM atomic subsystem's expectation that
the hardware is fully configured when atomic_enable completes?
If the goal is to wait for the upstream DSI host to enable its clock first,
would it be better to set the pre_enable_prev_first flag on the bridge rather
than bypassing the synchronous atomic commit design?
[Severity: High]
What happens if the display pipeline is rapidly disabled before this 100ms
timer expires?
Since this patch introduces a delayed work item, if the driver's disable path
powers off the chip and asserts reset:
lt9211_atomic_disable()
gpiod_set_value(ctx->reset_gpio, 0);
usleep_range(10000, 11000);
ret = regulator_disable(ctx->vccio);
without calling cancel_delayed_work_sync(), the delayed work could execute
on a powered-down device, leading to I2C timeouts and bus lockups.
> [ ... ]
> @@ -747,10 +1489,25 @@ static int lt9211_probe(struct i2c_client *client)
> [ ... ]
> + if (ctx->chip_type == LT9211C) {
> + ctx->wq = create_workqueue("lt9211_work");
> + if (!ctx->wq)
> + return -ENOMEM;
> + INIT_DELAYED_WORK(&ctx->lt9211_dw, lt9211_delayed_work_func);
> + }
> +
> dev_set_drvdata(dev, ctx);
> i2c_set_clientdata(client, ctx);
>
> @@ -768,17 +1525,22 @@ static void lt9211_remove(struct i2c_client *client)
> ctx->bridge.of_node = dev->of_node;
> drm_bridge_add(&ctx->bridge);
>
> ret = lt9211_host_attach(ctx);
> if (ret)
> drm_bridge_remove(&ctx->bridge);
>
> return ret;
> }
[Severity: High]
If lt9211_host_attach() returns an error like -EPROBE_DEFER, does this error
path leak the dynamically allocated workqueue?
It looks like destroy_workqueue(ctx->wq) is missing before returning, which
could lead to resource exhaustion if probe is deferred multiple times.
> static void lt9211_remove(struct i2c_client *client)
> {
> struct lt9211 *ctx = i2c_get_clientdata(client);
>
> + if (ctx->wq)
> + destroy_workqueue(ctx->wq);
> +
> drm_bridge_remove(&ctx->bridge);
> }
[Severity: High]
Can this result in a regression where a use-after-free occurs if the delayed
work timer is still pending during driver removal?
destroy_workqueue() flushes active work, but it does not cancel pending
timers for delayed works. Should we call
cancel_delayed_work_sync(&ctx->lt9211_dw) before destroying the workqueue to
prevent the timer from firing after the context is freed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-add-lt9211c-bridge-v6-0-e56d22152586@oss.qualcomm.com?part=2
^ permalink raw reply
* [PATCH] dt-bindings: display: panel-lvds: Add boe,dv215fhm-r01 compatible
From: Vishnu Saini @ 2026-07-19 16:08 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lad Prabhakar, Thierry Reding
Cc: dri-devel, devicetree, linux-kernel, venkata.valluru,
Jessica Zhang, Vishnu Saini
Add BOE DV215FHM-R01 21.5" FHD (1920x1080) dual-channel LVDS panel
compatible string to the panel-lvds binding.
Also remove the 'port' requirement from the required list to allow
dual-channel LVDS panels to use the 'ports' graph topology with
separate port@0 (odd pixels) and port@1 (even pixels) nodes, as
required by the dual-LVDS binding.
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
.../devicetree/bindings/display/panel/panel-lvds.yaml | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index b89f86bc0683..584818b2df6e 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -58,6 +58,8 @@ properties:
- hydis,hv070wx2-1e0
# Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
- jenson,bl-jt60050-01a
+ # BOE DV215FHM-R01 21.5" FHD (1920x1080) dual-channel LVDS panel
+ - boe,dv215fhm-r01
# Riverdi RVT101HVLNWC00 10.1" WXGA (1280x800) TFT LCD LVDS panel
- riverdi,rvt101hvlnwc00
# Riverdi RVT70HSLNWCA0 7.0" WSVGA (1024x600) TFT LCD LVDS panel
@@ -72,6 +74,12 @@ properties:
- const: panel-lvds
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ For dual-channel LVDS panels, use 'ports' with port@0 for odd pixels
+ and port@1 for even pixels instead of the single 'port' property.
+
unevaluatedProperties: false
required:
@@ -80,6 +88,4 @@ required:
- width-mm
- height-mm
- panel-timing
- - port
-
...
---
base-commit: 104c00917264c5b9571072471e3a8689cd1a2c4d
change-id: 20260719-b4-lvds-panel-doc-cb503c4ba2be
Best regards,
--
Vishnu Saini <vishnu.saini@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH v6 2/2] drm/bridge: add support for lontium lt9211c bridge
From: vishnu.saini @ 2026-07-19 15:57 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Marek Vasut
Cc: dri-devel, devicetree, linux-kernel, Yi Zhang, Nilesh Laad,
Gopi Botlagunta, Vishnu Saini, venkata.valluru, Jessica Zhang
In-Reply-To: <20260719-add-lt9211c-bridge-v6-0-e56d22152586@oss.qualcomm.com>
From: Yi Zhang <zhanyi@qti.qualcomm.com>
LT9211C is a Single/Dual-Link DSI/LVDS or Single DPI input to
Single-Link/Dual-Link DSI/LVDS or Single DPI output bridge chip.
Extend the existing lontium-lt9211 driver to support DSI-to-LVDS
bridge configuration by detecting and handling both LT9211 and LT9211C
variants from a single driver.
Chip detection in lt9211_read_chipid() is extended to identify the
LT9211C by its distinct chip ID registers.
A separate regmap configuration is introduced for LT9211C to cover
its extended register map. The chip_type field added to struct lt9211
selects the appropriate regmap and code paths at probe time using
of_device_is_compatible().
Five new functions implement the LT9211C DSI-to-LVDS initialisation
sequence: lt9211c_configure_rx(), lt9211c_autodetect_rx(),
lt9211c_configure_timing(), lt9211c_configure_plls() and
lt9211c_configure_tx(). The LT9211C requires DSI clocks to be running
before the bridge can be initialised, so lt9211_atomic_enable() queues
a delayed workqueue item for LT9211C rather than initialising
synchronously as LT9211 does.
LT9211C uses VIDEO|LPM DSI mode flags, which differ from the
sync-pulse mode used by LT9211.
Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com>
Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com>
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/lontium-lt9211.c | 796 +++++++++++++++++++++++++++++++-
1 file changed, 779 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c b/drivers/gpu/drm/bridge/lontium-lt9211.c
index f39d83a5ae37..36c004df34fc 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9211.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9211.c
@@ -19,6 +19,7 @@
#include <linux/of_graph.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
+#include <linux/workqueue.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_bridge.h>
@@ -36,10 +37,21 @@
#define REG_CHIPID2 0x8102
#define REG_CHIPID2_VALUE 0xe3
+/* LT9211C chip ID values */
+#define REG_CHIPID0_LT9211C_VALUE 0x21
+#define REG_CHIPID1_LT9211C_VALUE 0x03
+#define REG_CHIPID2_LT9211C_VALUE 0xe1
+
#define REG_DSI_LANE 0xd000
/* DSI lane count - 0 means 4 lanes ; 1, 2, 3 means 1, 2, 3 lanes. */
#define REG_DSI_LANE_COUNT(n) ((n) & 3)
+/* Chip type enum */
+enum lt9211_chip_type {
+ LT9211,
+ LT9211C,
+};
+
struct lt9211 {
struct drm_bridge bridge;
struct device *dev;
@@ -50,6 +62,14 @@ struct lt9211 {
struct regulator *vccio;
bool lvds_dual_link;
bool lvds_dual_link_even_odd_swap;
+ /* LT9211C specific fields */
+ enum lt9211_chip_type chip_type;
+ struct workqueue_struct *wq;
+ struct delayed_work lt9211_dw;
+ struct drm_display_mode mode;
+ bool bpp24;
+ bool jeida;
+ bool de;
};
static const struct regmap_range lt9211_rw_ranges[] = {
@@ -93,6 +113,49 @@ static const struct regmap_config lt9211_regmap_config = {
.max_register = 0xda00,
};
+static const struct regmap_range lt9211c_rw_ranges[] = {
+ regmap_reg_range(0xff, 0xff),
+ regmap_reg_range(0x8100, 0x8182),
+ regmap_reg_range(0x8200, 0x82aa),
+ regmap_reg_range(0x8500, 0x85ff),
+ regmap_reg_range(0x8600, 0x86a0),
+ regmap_reg_range(0x8700, 0x8746),
+ regmap_reg_range(0xd000, 0xd0a7),
+ regmap_reg_range(0xd400, 0xd42c),
+ regmap_reg_range(0xd800, 0xd838),
+ regmap_reg_range(0xd9c0, 0xd9d5),
+};
+
+static const struct regmap_access_table lt9211c_rw_table = {
+ .yes_ranges = lt9211c_rw_ranges,
+ .n_yes_ranges = ARRAY_SIZE(lt9211c_rw_ranges),
+};
+
+static const struct regmap_range_cfg lt9211c_range = {
+ .name = "lt9211c",
+ .range_min = 0x0000,
+ .range_max = 0xda00,
+ .selector_reg = REG_PAGE_CONTROL,
+ .selector_mask = 0xff,
+ .selector_shift = 0,
+ .window_start = 0,
+ .window_len = 0x100,
+};
+
+static const struct regmap_config lt9211c_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .rd_table = <9211c_rw_table,
+ .wr_table = <9211c_rw_table,
+ .volatile_table = <9211c_rw_table,
+ .ranges = <9211c_range,
+ .num_ranges = 1,
+ .cache_type = REGCACHE_RBTREE,
+ .max_register = 0xda00,
+};
+
+static void lt9211_delayed_work_func(struct work_struct *work);
+
static struct lt9211 *bridge_to_lt9211(struct drm_bridge *bridge)
{
return container_of(bridge, struct lt9211, bridge);
@@ -120,14 +183,23 @@ static int lt9211_read_chipid(struct lt9211 *ctx)
return ret;
}
- /* Test for known Chip ID. */
- if (chipid[0] != REG_CHIPID0_VALUE || chipid[1] != REG_CHIPID1_VALUE) {
- dev_err(ctx->dev, "Unknown Chip ID: 0x%02x 0x%02x 0x%02x\n",
- chipid[0], chipid[1], chipid[2]);
- return -EINVAL;
+ /* Test for LT9211 Chip ID. */
+ if (chipid[0] == REG_CHIPID0_VALUE && chipid[1] == REG_CHIPID1_VALUE) {
+ dev_dbg(ctx->dev, "Detected LT9211 chip\n");
+ return 0;
}
- return 0;
+ /* Test for LT9211C Chip ID. */
+ if (chipid[0] == REG_CHIPID0_LT9211C_VALUE &&
+ chipid[1] == REG_CHIPID1_LT9211C_VALUE &&
+ chipid[2] == REG_CHIPID2_LT9211C_VALUE) {
+ dev_dbg(ctx->dev, "Detected LT9211C chip\n");
+ return 0;
+ }
+
+ dev_err(ctx->dev, "Unknown Chip ID: 0x%02x 0x%02x 0x%02x\n",
+ chipid[0], chipid[1], chipid[2]);
+ return -EINVAL;
}
static int lt9211_system_init(struct lt9211 *ctx)
@@ -454,6 +526,651 @@ static int lt9211_configure_tx(struct lt9211 *ctx, bool jeida,
return 0;
}
+static int lt9211c_configure_rx(struct lt9211 *ctx)
+{
+ unsigned int pval;
+
+ const struct reg_sequence lt9211c_rx_phy_seq[] = {
+ { REG_DSI_LANE, REG_DSI_LANE_COUNT(ctx->dsi->lanes) },
+ { 0x8201, 0x11 },
+ { 0x8218, 0x48 },
+ { 0x8201, 0x91 },
+ { 0x8202, 0x00 },
+ { 0x8203, 0xee },
+ { 0x8209, 0x21 },
+ { 0x8204, 0x44 },
+ { 0x8205, 0xc4 },
+ { 0x8206, 0x44 },
+ { 0x8213, 0x0c },
+
+ { 0xd001, 0x00 },
+ { 0xd002, 0x0e },
+ { 0xd005, 0x00 },
+ { 0xd00a, 0x59 },
+ { 0xd00b, 0x20 },
+ };
+
+ const struct reg_sequence lt9211c_rx_phy_reset_seq[] = {
+ { 0x8109, 0xde },
+ { 0x8109, 0xdf },
+ };
+
+ const struct reg_sequence lt9211c_rx_clk_sel_seq[] = {
+ { 0x85e9, 0x88 },
+ { 0x8180, 0x51 },
+ { 0x8181, 0x10 },
+ { 0x8632, 0x03 },
+ };
+
+ const struct reg_sequence lt9211c_rx_input_sel_seq[] = {
+ { 0xd004, 0x00 },
+ { 0xd021, 0x46 },
+ };
+
+ const struct reg_sequence lt9211c_rx_dig_seq[] = {
+ { 0x853f, 0x08 },
+ { 0x8540, 0x04 },
+ { 0x8541, 0x03 },
+ { 0x8542, 0x02 },
+ { 0x8543, 0x01 },
+ { 0x8545, 0x04 },
+ { 0x8546, 0x03 },
+ { 0x8547, 0x02 },
+ { 0x8548, 0x01 },
+ { 0x8544, 0x00 },
+ { 0x8549, 0x00 },
+ };
+
+ int ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_rx_phy_seq,
+ ARRAY_SIZE(lt9211c_rx_phy_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_rx_phy_reset_seq,
+ ARRAY_SIZE(lt9211c_rx_phy_reset_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_rx_clk_sel_seq,
+ ARRAY_SIZE(lt9211c_rx_clk_sel_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_read(ctx->regmap, 0x8180, &pval);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x8180, ((pval & 0xfc) | 0x03));
+ if (ret)
+ return ret;
+
+ ret = regmap_read(ctx->regmap, 0x8680, &pval);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x863f, (pval & 0xf8));
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x863f, 0x05);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(ctx->regmap, 0x8530, &pval);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x8530, ((pval & 0xf8) | 0x11));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_rx_input_sel_seq,
+ ARRAY_SIZE(lt9211c_rx_input_sel_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_rx_dig_seq,
+ ARRAY_SIZE(lt9211c_rx_dig_seq));
+ if (ret)
+ return ret;
+
+ /* Give the chip time to lock onto RX stream. */
+ msleep(100);
+
+ return 0;
+}
+
+static int lt9211c_autodetect_rx(struct lt9211 *ctx,
+ const struct drm_display_mode *mode)
+{
+ u16 width, height;
+ u8 buf[5];
+ u8 format;
+ u8 sot[8];
+ int ret;
+
+ /* Read the SOT from the chip. */
+ ret = regmap_bulk_read(ctx->regmap, 0xd088, sot, sizeof(sot));
+ if (ret)
+ return ret;
+
+ dev_dbg(ctx->dev, "Sot Num = 0x%02x, 0x%02x, 0x%02x, 0x%02x\n", sot[0],
+ sot[2], sot[4], sot[6]);
+
+ dev_dbg(ctx->dev, "Sot Data = 0x%02x, 0x%02x, 0x%02x, 0x%02x\n", sot[1],
+ sot[3], sot[5], sot[7]);
+ /* HS Settle Set */
+ if (sot[0] > 0x10 && sot[0] < 0x50)
+ regmap_write(ctx->regmap, 0xd002, sot[0] - 5);
+ else
+ regmap_write(ctx->regmap, 0xd002, 0x08);
+
+ /* Width/Height/Format Auto-detection */
+ ret = regmap_bulk_read(ctx->regmap, 0xd082, buf, sizeof(buf));
+ if (ret)
+ return ret;
+
+ width = (buf[0] << 8) | buf[1];
+ height = (buf[3] << 8) | buf[4];
+ format = buf[2] & 0xf;
+
+ if (format == 0x3) { /* YUV422 16bit */
+ width /= 2;
+ } else if (format == 0xa) { /* RGB888 24bit */
+ width /= 3;
+ } else {
+ dev_err(ctx->dev, "Unsupported DSI format 0x%01x\n", format);
+ return -EINVAL;
+ }
+
+ if (width != mode->hdisplay) {
+ dev_err(ctx->dev,
+ "RX: Detected DSI width (%d) does not match mode hdisplay (%d)\n",
+ width, mode->hdisplay);
+ return -EINVAL;
+ }
+
+ if (height != mode->vdisplay) {
+ dev_err(ctx->dev,
+ "RX: Detected DSI height (%d) does not match mode vdisplay (%d)\n",
+ height, mode->vdisplay);
+ return -EINVAL;
+ }
+
+ dev_dbg(ctx->dev, "RX: %dx%d format=0x%01x\n", width, height, format);
+ return 0;
+}
+
+static int lt9211c_configure_timing(struct lt9211 *ctx,
+ const struct drm_display_mode *mode)
+{
+ const struct reg_sequence lt9211c_timing[] = {
+ { 0xd00d, (mode->vtotal >> 8) & 0xff },
+ { 0xd00e, mode->vtotal & 0xff },
+ { 0xd00f, (mode->vdisplay >> 8) & 0xff },
+ { 0xd010, mode->vdisplay & 0xff },
+ { 0xd011, (mode->htotal >> 8) & 0xff },
+ { 0xd012, mode->htotal & 0xff },
+ { 0xd013, (mode->hdisplay >> 8) & 0xff },
+ { 0xd014, mode->hdisplay & 0xff },
+ { 0xd015, (mode->vsync_end - mode->vsync_start) & 0xff },
+ { 0xd04c, ((mode->hsync_end - mode->hsync_start) >> 8) & 0xff },
+ { 0xd016, (mode->hsync_end - mode->hsync_start) & 0xff },
+ { 0xd017, ((mode->vsync_start - mode->vdisplay) >> 8) & 0xff },
+ { 0xd018, (mode->vsync_start - mode->vdisplay) & 0xff },
+ { 0xd019, ((mode->hsync_start - mode->hdisplay) >> 8) & 0xff },
+ { 0xd01a, (mode->hsync_start - mode->hdisplay) & 0xff },
+ };
+
+ return regmap_multi_reg_write(ctx->regmap, lt9211c_timing,
+ ARRAY_SIZE(lt9211c_timing));
+}
+
+static int lt9211c_configure_plls(struct lt9211 *ctx,
+ const struct drm_display_mode *mode)
+{
+ const struct reg_sequence lt9211c_dessc_pll_reset[] = {
+ { 0x8103, 0xfe, 2000 },
+ { 0x8103, 0xff, 0 },
+ };
+
+ const struct reg_sequence lt9211c_pcr_cali_seq[] = {
+ { 0xd00a, 0x5f },
+ { 0xd01e, 0x51 },
+ { 0xd023, 0x80 },
+ { 0xd024, 0x70 },
+ { 0xd025, 0x80 },
+ { 0xd02a, 0x10 },
+ { 0xd021, 0x4f },
+ { 0xd022, 0xf0 },
+ { 0xd038, 0x04 },
+ { 0xd039, 0x08 },
+ { 0xd03a, 0x10 },
+ { 0xd03b, 0x20 },
+ { 0xd03f, 0x04 },
+ { 0xd040, 0x08 },
+ { 0xd041, 0x10 },
+ { 0xd042, 0x20 },
+ { 0xd02b, 0xa0 },
+ };
+
+ const struct reg_sequence lt9211c_pcr_reset_seq[] = {
+ { 0xd009, 0xdb },
+ { 0xd009, 0xdf },
+ { 0xd008, 0x80 },
+ { 0xd008, 0x00 },
+ };
+
+ unsigned int pval;
+ int ret;
+ u8 div;
+ u32 pcr_m;
+ u32 pcr_k;
+ u32 pcr_up;
+ u32 pcr_down;
+
+ /* DeSSC PLL reference clock is 25 MHz XTal. */
+ ret = regmap_write(ctx->regmap, 0x8226, 0x20);
+ if (ret)
+ return ret;
+
+ /* Prediv = 0 */
+ ret = regmap_write(ctx->regmap, 0x8227, 0x40);
+ if (ret)
+ return ret;
+
+ if (mode->clock < 22000) {
+ ret = regmap_write(ctx->regmap, 0x822f, 0x07);
+ ret |= regmap_write(ctx->regmap, 0x822c, 0x01);
+ div = 16;
+ } else if (mode->clock < 44000) {
+ ret = regmap_write(ctx->regmap, 0x822f, 0x07);
+ div = 16;
+ } else if (mode->clock < 88000) {
+ ret = regmap_write(ctx->regmap, 0x822f, 0x06);
+ div = 8;
+ } else if (mode->clock < 176000) {
+ ret = regmap_write(ctx->regmap, 0x822f, 0x05);
+ div = 4;
+ } else {
+ ret = regmap_write(ctx->regmap, 0x822f, 0x04);
+ div = 2;
+ }
+
+ if (ret)
+ return ret;
+
+ pcr_m = (mode->clock * div) / 25;
+ pcr_k = pcr_m % 1000;
+ pcr_m /= 1000;
+
+ pcr_up = pcr_m + 1;
+ pcr_down = pcr_m - 1;
+
+ pcr_k <<= 14;
+
+ ret = regmap_write(ctx->regmap, 0xd008, 0x00);
+ if (ret < 0)
+ return ret;
+
+ /* 0xd026: pcr_m */
+ ret = regmap_write(ctx->regmap, 0xd026, (0x80 | (u8)pcr_m) & 0x7f);
+ if (ret < 0)
+ return ret;
+
+ /* 0xd027 0xd028 0xd029: pcr_k */
+ ret = regmap_write(ctx->regmap, 0xd027, (pcr_k >> 16) & 0xff);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0xd028, (pcr_k >> 8) & 0xff);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0xd029, pcr_k & 0xff);
+ if (ret < 0)
+ return ret;
+
+ /* 0xd02d: pcr_m overflow limit setting */
+ ret = regmap_write(ctx->regmap, 0xd02d, pcr_up);
+ if (ret < 0)
+ return ret;
+
+ /* 0xd031: pcr_m underflow limit setting */
+ ret = regmap_write(ctx->regmap, 0xd031, pcr_down);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_dessc_pll_reset,
+ ARRAY_SIZE(lt9211c_dessc_pll_reset));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_pcr_cali_seq,
+ ARRAY_SIZE(lt9211c_pcr_cali_seq));
+ if (ret)
+ return ret;
+
+ if (mode->clock < 44000) {
+ ret = regmap_write(ctx->regmap, 0xd00c, 0x60);
+ ret |= regmap_write(ctx->regmap, 0xd01b, 0x00);
+ ret |= regmap_write(ctx->regmap, 0xd01c, 0x60);
+ } else {
+ ret = regmap_write(ctx->regmap, 0xd00c, 0x40);
+ ret |= regmap_write(ctx->regmap, 0xd01b, 0x00);
+ ret |= regmap_write(ctx->regmap, 0xd01c, 0x40);
+ }
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_pcr_reset_seq,
+ ARRAY_SIZE(lt9211c_pcr_reset_seq));
+ if (ret)
+ return ret;
+
+ /* PCR stability test takes seconds. */
+ ret = regmap_read_poll_timeout(ctx->regmap, 0xd087, pval,
+ ((pval & 0x18) == 0x18), 20000, 3000000);
+ if (ret)
+ dev_err(ctx->dev, "PCR unstable, ret=%i\n", ret);
+
+ ret = regmap_write(ctx->regmap, 0x8180, 0x51);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x863f, 0x00);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x863f, 0x01);
+ if (ret)
+ return ret;
+
+ ret = regmap_read_poll_timeout(ctx->regmap, 0x8640, pval,
+ ((pval & 0x01) == 0x01), 50000, 250000);
+ if (ret)
+ dev_err(ctx->dev, "Video check not stable, ret=%i\n", ret);
+
+ return ret;
+}
+
+static int lt9211c_configure_tx(struct lt9211 *ctx,
+ const struct drm_display_mode *mode)
+{
+ const struct reg_sequence lt9211c_tx_phy_off_seq[] = {
+ { 0x8236, 0x00 },
+ { 0x8237, 0x00 },
+ { 0x8108, 0x6f },
+ { 0x8103, 0xbf },
+ };
+
+ const struct reg_sequence lt9211c_tx_phy_seq[] = {
+ { 0x8236, 0x03 },
+ { 0x8237, 0x44 },
+ { 0x8238, 0x14 },
+ { 0x8239, 0x31 },
+ { 0x823a, 0xc8 },
+ { 0x823b, 0x00 },
+ { 0x823c, 0x0f },
+ { 0x8246, 0x40 },
+ { 0x8247, 0x40 },
+ { 0x8248, 0x40 },
+ { 0x8249, 0x40 },
+ { 0x824a, 0x40 },
+ { 0x824b, 0x40 },
+ { 0x824c, 0x40 },
+ { 0x824d, 0x40 },
+ { 0x824e, 0x40 },
+ { 0x824f, 0x40 },
+ { 0x8250, 0x40 },
+ { 0x8251, 0x40 },
+ };
+
+ const struct reg_sequence lt9211c_tx_mltx_reset[] = {
+ { 0x8103, 0xbf },
+ { 0x8103, 0xff },
+ };
+
+ const struct reg_sequence lt9211c_tx_dig_seq[] = {
+ { 0x854a, 0x01 },
+ { 0x854b, 0x00 },
+ { 0x854c, 0x10 },
+ { 0x854d, 0x20 },
+ { 0x854e, 0x50 },
+ { 0x854f, 0x30 },
+ { 0x8550, 0x46 },
+ { 0x8551, 0x10 },
+ { 0x8552, 0x20 },
+ { 0x8553, 0x50 },
+ { 0x8554, 0x30 },
+ { 0x8555, 0x00 },
+ { 0x8556, 0x20 },
+
+ { 0x8568, 0x00 },
+ { 0x856e, 0x10 | (ctx->de ? BIT(6) : 0) },
+ { 0x856f, 0x81 | (ctx->jeida ? BIT(6) : 0) |
+ (ctx->lvds_dual_link ? BIT(4) : 0) |
+ (ctx->bpp24 ? BIT(2) : 0) },
+ };
+
+ const struct reg_sequence lt9211c_tx_ssc_seq[] = {
+ { 0x8234, 0x00 },
+ { 0x856e, 0x10 },
+ { 0x8181, 0x15 },
+ { 0x871e, 0x00 },
+ { 0x8717, 0x02 },
+ { 0x8718, 0x04 },
+ { 0x8719, 0xd4 },
+ { 0x871a, 0x00 },
+ { 0x871b, 0x12 },
+ { 0x871c, 0x00 },
+ { 0x871d, 0x24 },
+ { 0x871f, 0x1c },
+ { 0x8720, 0x00 },
+ { 0x8721, 0x00 },
+ { 0x871e, 0x02 },
+ };
+
+ const struct reg_sequence lt9211c_tx_pll_reset_seq[] = {
+ { 0x810c, 0xfe, 2000 },
+ { 0x810c, 0xff, 0 },
+ };
+
+ const struct reg_sequence lt9211c_tx_sw_reset_seq[] = {
+ { 0x8108, 0x6f, 2000 },
+ { 0x8108, 0x7f, 0 },
+ };
+
+ unsigned int pval;
+ int ret;
+ u32 phy_clk;
+ u8 pixclk_div;
+ u8 pre_div;
+ u8 div_set;
+ u8 sericlk_div;
+ u8 val;
+
+ dev_info(ctx->dev,
+ "dual_link=%d,even_odd_swap=%d,bpp24=%d,jeida=%d,de=%d\n",
+ ctx->lvds_dual_link, ctx->lvds_dual_link_even_odd_swap,
+ ctx->bpp24, ctx->jeida, ctx->de);
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_phy_off_seq,
+ ARRAY_SIZE(lt9211c_tx_phy_off_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_read(ctx->regmap, 0x8530, &pval);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x8530, ((pval & 0x3f) | 0x40));
+ if (ret)
+ return ret;
+
+ /* [7]0:txpll normal work; txpll ref clk sel pix clk */
+ ret = regmap_write(ctx->regmap, 0x8230, 0x00);
+ if (ret)
+ return ret;
+
+ if (ctx->lvds_dual_link)
+ phy_clk = (u32)(mode->clock * 7 / 2);
+ else
+ phy_clk = (u32)(mode->clock * 7);
+
+ /* 0x8231: prediv sel */
+ if (mode->clock < 20000) {
+ val = 0x28;
+ pre_div = 1;
+ } else if (mode->clock < 40000) {
+ val = 0x28;
+ pre_div = 1;
+ } else if (mode->clock < 80000) {
+ val = 0x29;
+ pre_div = 2;
+ } else if (mode->clock < 160000) {
+ val = 0x2a;
+ pre_div = 4;
+ } else if (mode->clock < 320000) {
+ val = 0x2b;
+ pre_div = 8;
+ } else {
+ val = 0x2f;
+ pre_div = 16;
+ }
+ ret = regmap_write(ctx->regmap, 0x8231, val);
+ if (ret < 0)
+ return ret;
+
+ /* 0x8232: serickdiv sel */
+ if (phy_clk < 80000) {
+ val = 0x32;
+ sericlk_div = 16;
+ } else if (phy_clk < 160000) {
+ val = 0x22;
+ sericlk_div = 8;
+ } else if (phy_clk < 320000) {
+ val = 0x12;
+ sericlk_div = 4;
+ } else if (phy_clk < 640000) {
+ val = 0x02;
+ sericlk_div = 2;
+ } else {
+ val = 0x42;
+ sericlk_div = 1;
+ }
+ ret = regmap_write(ctx->regmap, 0x8232, val);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * 0x8233: pix_mux sel & pix_div sel
+ * To avoid floating point operations, The pixclk_div is enlarged by 10 times
+ */
+ if (mode->clock > 150000) {
+ val = 0x04;
+ pixclk_div = 35;
+ } else {
+ pixclk_div =
+ (u8)((phy_clk * sericlk_div * 10) / (mode->clock * 7));
+ if (pixclk_div <= 10)
+ val = 0x00;
+ else if (pixclk_div <= 20)
+ val = 0x01;
+ else if (pixclk_div <= 40)
+ val = 0x02;
+ else
+ val = 0x03;
+ }
+ ret = regmap_write(ctx->regmap, 0x8233, val);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_write(ctx->regmap, 0x8234, 0x01);
+ if (ret < 0)
+ return ret;
+
+ /* 0x8235: div set */
+ div_set = (u8)(phy_clk * sericlk_div / mode->clock / pre_div);
+ ret = regmap_write(ctx->regmap, 0x8235, div_set);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_ssc_seq,
+ ARRAY_SIZE(lt9211c_tx_ssc_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_pll_reset_seq,
+ ARRAY_SIZE(lt9211c_tx_pll_reset_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_read_poll_timeout(ctx->regmap, 0x8739, pval, pval & 0x04,
+ 10000, 1000000);
+ if (ret) {
+ dev_err(ctx->dev, "TX PLL unstable, ret=%i\n", ret);
+ return ret;
+ }
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_phy_seq,
+ ARRAY_SIZE(lt9211c_tx_phy_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_mltx_reset,
+ ARRAY_SIZE(lt9211c_tx_mltx_reset));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_dig_seq,
+ ARRAY_SIZE(lt9211c_tx_dig_seq));
+ if (ret)
+ return ret;
+
+ ret = regmap_multi_reg_write(ctx->regmap, lt9211c_tx_sw_reset_seq,
+ ARRAY_SIZE(lt9211c_tx_sw_reset_seq));
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void lt9211_delayed_work_func(struct work_struct *work)
+{
+ struct delayed_work *dw = to_delayed_work(work);
+ struct lt9211 *ctx = container_of(dw, struct lt9211, lt9211_dw);
+ const struct drm_display_mode *mode = &ctx->mode;
+ int ret;
+
+ if (ctx->chip_type != LT9211C) {
+ dev_err(ctx->dev, "LT9211: Delayed work called for non-LT9211C chip\n");
+ return;
+ }
+
+ ret = lt9211c_configure_rx(ctx);
+ if (ret)
+ return;
+
+ ret = lt9211c_autodetect_rx(ctx, mode);
+ if (ret)
+ return;
+
+ ret = lt9211c_configure_timing(ctx, mode);
+ if (ret)
+ return;
+
+ ret = lt9211c_configure_plls(ctx, mode);
+ if (ret)
+ return;
+
+ ret = lt9211c_configure_tx(ctx, mode);
+ if (ret)
+ return;
+}
+
static void lt9211_atomic_enable(struct drm_bridge *bridge,
struct drm_atomic_commit *state)
{
@@ -523,6 +1240,15 @@ static void lt9211_atomic_enable(struct drm_bridge *bridge,
if (ret)
return;
+ if (ctx->chip_type == LT9211C && ctx->wq) {
+ drm_mode_copy(&ctx->mode, mode);
+ /* LT9211C must enable after mipi clock enable */
+ queue_delayed_work(ctx->wq, &ctx->lt9211_dw,
+ msecs_to_jiffies(100));
+ dev_dbg(ctx->dev, "LT9211C enabled.\n");
+ return;
+ }
+
ret = lt9211_system_init(ctx);
if (ret)
return;
@@ -671,11 +1397,6 @@ static int lt9211_parse_dt(struct lt9211 *ctx)
static int lt9211_host_attach(struct lt9211 *ctx)
{
- const struct mipi_dsi_device_info info = {
- .type = "lt9211",
- .channel = 0,
- .node = NULL,
- };
struct device *dev = ctx->dev;
struct device_node *host_node;
struct device_node *endpoint;
@@ -697,7 +1418,22 @@ static int lt9211_host_attach(struct lt9211 *ctx)
if (dsi_lanes < 0)
return dsi_lanes;
- dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
+ if (ctx->chip_type == LT9211C) {
+ const struct mipi_dsi_device_info info = {
+ .type = "lt9211c",
+ .channel = 0,
+ .node = NULL,
+ };
+ dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
+ } else {
+ const struct mipi_dsi_device_info info = {
+ .type = "lt9211",
+ .channel = 0,
+ .node = NULL,
+ };
+ dsi = devm_mipi_dsi_device_register_full(dev, host, &info);
+ }
+
if (IS_ERR(dsi))
return dev_err_probe(dev, PTR_ERR(dsi),
"failed to create dsi device\n");
@@ -706,10 +1442,16 @@ static int lt9211_host_attach(struct lt9211 *ctx)
dsi->lanes = dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
- MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO_NO_HSA |
- MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
- MIPI_DSI_MODE_NO_EOT_PACKET;
+
+ if (ctx->chip_type == LT9211C) {
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_LPM;
+ } else {
+ dsi->mode_flags =
+ MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
+ MIPI_DSI_MODE_VIDEO_HSE | MIPI_DSI_MODE_VIDEO_NO_HSA |
+ MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
+ MIPI_DSI_MODE_NO_EOT_PACKET;
+ }
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
@@ -747,10 +1489,25 @@ static int lt9211_probe(struct i2c_client *client)
if (ret)
return ret;
- ctx->regmap = devm_regmap_init_i2c(client, <9211_regmap_config);
+ if (of_device_is_compatible(dev->of_node, "lontium,lt9211c")) {
+ ctx->chip_type = LT9211C;
+ ctx->regmap =
+ devm_regmap_init_i2c(client, <9211c_regmap_config);
+ } else {
+ ctx->chip_type = LT9211;
+ ctx->regmap =
+ devm_regmap_init_i2c(client, <9211_regmap_config);
+ }
if (IS_ERR(ctx->regmap))
return PTR_ERR(ctx->regmap);
+ if (ctx->chip_type == LT9211C) {
+ ctx->wq = create_workqueue("lt9211_work");
+ if (!ctx->wq)
+ return -ENOMEM;
+ INIT_DELAYED_WORK(&ctx->lt9211_dw, lt9211_delayed_work_func);
+ }
+
dev_set_drvdata(dev, ctx);
i2c_set_clientdata(client, ctx);
@@ -768,17 +1525,22 @@ static void lt9211_remove(struct i2c_client *client)
{
struct lt9211 *ctx = i2c_get_clientdata(client);
+ if (ctx->wq)
+ destroy_workqueue(ctx->wq);
+
drm_bridge_remove(&ctx->bridge);
}
static const struct i2c_device_id lt9211_id[] = {
{ "lontium,lt9211" },
+ { "lontium,lt9211c" },
{},
};
MODULE_DEVICE_TABLE(i2c, lt9211_id);
static const struct of_device_id lt9211_match_table[] = {
{ .compatible = "lontium,lt9211" },
+ { .compatible = "lontium,lt9211c" },
{},
};
MODULE_DEVICE_TABLE(of, lt9211_match_table);
--
2.34.1
^ permalink raw reply related
* [PATCH v6 1/2] dt-bindings: display: bridge: lontium,lt9211: Add lt9211c support
From: vishnu.saini @ 2026-07-19 15:57 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Marek Vasut
Cc: dri-devel, devicetree, linux-kernel, Yi Zhang, Nilesh Laad,
Gopi Botlagunta, Vishnu Saini, venkata.valluru, Jessica Zhang
In-Reply-To: <20260719-add-lt9211c-bridge-v6-0-e56d22152586@oss.qualcomm.com>
From: Yi Zhang <zhanyi@qti.qualcomm.com>
Add binding for the Lontium LT9211C bridge chip.
Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com>
Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
index 7cfe92a8bcd7..de61bda09db9 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
@@ -4,19 +4,20 @@
$id: http://devicetree.org/schemas/display/bridge/lontium,lt9211.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Lontium LT9211 DSI/LVDS/DPI to DSI/LVDS/DPI bridge.
+title: Lontium LT9211/LT9211C DSI/LVDS/DPI to DSI/LVDS/DPI bridge.
maintainers:
- Marek Vasut <marex@denx.de>
description: |
- The LT9211 are bridge devices which convert Single/Dual-Link DSI/LVDS
+ The LT9211 and LT9211C are bridge devices which convert Single/Dual-Link DSI/LVDS
or Single DPI to Single/Dual-Link DSI/LVDS or Single DPI.
properties:
compatible:
enum:
- lontium,lt9211
+ - lontium,lt9211c
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH v6 0/2] This series adds LT9211C bridge driver by extending LT9211
From: vishnu.saini @ 2026-07-19 15:57 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Marek Vasut
Cc: dri-devel, devicetree, linux-kernel, Yi Zhang, Nilesh Laad,
Gopi Botlagunta, Vishnu Saini, venkata.valluru, Jessica Zhang
LT9211c is a Single/Dual-Link DSI/LVDS or Single DPI input to
Single-link/Dual-Link DSI/LVDS or Single DPI output bridge chip.
This adds support for DSI to LVDS bridge configuration. By extending the
existing lontium-lt9211 driver to support DSI-to-LVDS bridge configuration.
Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com>
Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com>
Signed-off-by: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
---
Changes in v6:
- Nilesh Laad and Gopi Botlagunta moved to different org in Qualcomm. Further, i will followup on this series with community, will also submit the dt series where LT9211C bridge is used.
- Rebased onto current drm-misc-next (commit 671b7825dbfe)
- Fixed lt9211_read_chipid: LT9211 match no longer checks chipid[2],
preserving compatibility with LT9211 rev U5 (db74b04edce1)
- Fixed indentation in lt9211_atomic_enable LT9211 path (was double-indented)
- Fixed indentation in lt9211_delayed_work_func body (was double-indented)
- Gated workqueue creation on LT9211C chip type only
- Fixed few formatting warnings with coccinelle and W=1
- Link to v5: https://lore.kernel.org/r/20260323-add-lt9211c-bridge-v5-0-9c63bb035c17@oss.qualcomm.com
Changes in v5:
- Addressed code formatting in lt9211 driver (no functional or design changes)
- Addressed v4 comments on lontium-lt9211.yaml
- Link to v4: https://lore.kernel.org/r/20251224-add-lt9211c-bridge-v4-0-406e73ec28c5@oss.qualcomm.com
Changes in v4:
- Removed lontium-lt9211c.yaml
- Extended lontium-lt9211.yaml to support LT9211C
- Link to v3: https://lore.kernel.org/r/20251218-add-lt9211c-bridge-v3-0-1ee0670a0db2@oss.qualcomm.com
Changes in v3:
- Removed lontium-lt9211c as separate driver
- Add support to lontium-lt9211c bridge driver by extending the existing lontium-lt9211.c
- Fixed kernel test robot reported build errors
- Link to v2: https://lore.kernel.org/lkml/20251107-add-lt9211c-bridge-v2-0-b0616e23407c@oss.qualcomm.com/
Changes in v2:
- Combined driver patch from https://lore.kernel.org/lkml/20250911-lt9211c-bridge-support-v1-1-c221202cbcd5@oss.qualcomm.com/
- Added MODULE_AUTHOR
- Uppercase to lowercase for hex values
- Link to v1: https://lore.kernel.org/r/20250910-add-lt9211c-bridge-v1-1-4f23740fe101@oss.qualcomm.com
---
Yi Zhang (2):
dt-bindings: display: bridge: lontium,lt9211: Add lt9211c support
drm/bridge: add support for lontium lt9211c bridge
.../bindings/display/bridge/lontium,lt9211.yaml | 5 +-
drivers/gpu/drm/bridge/lontium-lt9211.c | 796 ++++++++++++++++++++-
2 files changed, 782 insertions(+), 19 deletions(-)
---
base-commit: 671b7825dbfe9ea6e3ad3001003aeee0df48d1b5
change-id: 20250910-add-lt9211c-bridge-5a21fcb1c803
Best regards,
--
Vishnu Saini <vishnu.saini@oss.qualcomm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox