* Re: [PATCH v2 04/21] dt-bindings: display/panel: ilitek,ili9881c: describe Waveshare panel
From: Krzysztof Kozlowski @ 2026-04-12 9:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, dri-devel, devicetree,
linux-kernel, linux-gpio
In-Reply-To: <20260411-waveshare-dsi-touch-v2-4-75cdbeac5156@oss.qualcomm.com>
On Sat, Apr 11, 2026 at 03:10:24PM +0300, Dmitry Baryshkov wrote:
> Describe Waveshare 7" DSI panel which uses ILI9881 as a panel
> controller. This panel requires two voltags supplies, so add separate
> iovcc supply.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
From: Frank Wunderlich @ 2026-04-12 9:23 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
The active-high property in base-dt cannot be overwritten and must be
set in separate overlay.
Fixes: f397471a6a8c ("arm64: dts: mediatek: mt7988: Add devicetree for BananaPi R4 Pro")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
arch/arm64/boot/dts/mediatek/Makefile | 8 ++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn13.dtso | 20 +++++++++++++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn14.dtso | 20 +++++++++++++++++++
.../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 2 --
4 files changed, 48 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
diff --git a/arch/arm64/boot/dts/mediatek/Makefile b/arch/arm64/boot/dts/mediatek/Makefile
index 387faa9c2a09..a86fb313b1a9 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -47,6 +47,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-emmc.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-4e.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn13.dtbo
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn14.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
@@ -70,18 +72,24 @@ mt7988a-bananapi-bpi-r4-2g5-sd-dtbs := \
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-2g5-sd.dtb
mt7988a-bananapi-bpi-r4-pro-8x-emmc-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-emmc.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-emmc.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-sd.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn14.dtbo \
mt7988a-bananapi-bpi-r4-pro-cn15.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn15.dtb
mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18-dtbs := \
mt7988a-bananapi-bpi-r4-pro-8x-sd.dtb \
+ mt7988a-bananapi-bpi-r4-pro-cn13.dtbo \
mt7988a-bananapi-bpi-r4-pro-cn18.dtbo
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7988a-bananapi-bpi-r4-pro-8x-sd-cn18.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8167-pumpkin.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
new file mode 100644
index 000000000000..973b76ba0cbf
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN13 on pcie2(11280000 1L0) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-2-hog} {
+ output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
new file mode 100644
index 000000000000..90b2a64459c3
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2025 MediaTek Inc.
+ * Author: Frank Wunderlich <frank-w@public-files.de>
+ */
+
+/* This enables key-m slot CN14 on pcie3(11290000 1L1) on BPI-R4-Pro */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ compatible = "bananapi,bpi-r4-pro", "mediatek,mt7988a";
+};
+
+&{/soc/pinctrl@1001f000/pcie-3-hog} {
+ output-high;
+};
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index bbd6c16a8cb0..1eeb72108b9b 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -430,14 +430,12 @@ mux {
pcie-2-hog {
gpio-hog;
gpios = <79 GPIO_ACTIVE_HIGH>;
- output-high;
};
/* 1L1 0=key-b (CN18), 1=key-m (CN14) */
pcie-3-hog {
gpio-hog;
gpios = <63 GPIO_ACTIVE_HIGH>;
- output-high;
};
pwm0_pins: pwm0-pins {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] some BPI-R4Pro dts updates
From: Frank Wunderlich @ 2026-04-12 9:23 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
From: Frank Wunderlich <frank-w@public-files.de>
There are some parts of BPI-R4Pro DTS that need to be changed. Currently
there should be not much users of the mainline-dts and we noticed some
things while openwrt integration.
v2:
- added mgmt port renaming as this patch is still outstanding to keep
all in one series
https://patchwork.kernel.org/project/linux-mediatek/patch/20260303202006.37515-1-linux@fw-web.de/
- dropped default-state in gpio-leds patch as suggested by daniel
Frank Wunderlich (4):
arm64: dts: mediatek: mt7988a-bpi-r4pro: rename mgmt port to lan5
arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
arm64: dts: mediatek: mt7988a-bpi-r4pro: rework pcie gpio-hog handling
arch/arm64/boot/dts/mediatek/Makefile | 8 ++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn13.dtso | 20 +++++++++++++++++++
.../mt7988a-bananapi-bpi-r4-pro-cn14.dtso | 20 +++++++++++++++++++
.../mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 15 +++-----------
4 files changed, 51 insertions(+), 12 deletions(-)
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn13.dtso
create mode 100644 arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro-cn14.dtso
--
2.43.0
^ permalink raw reply
* [PATCH v2 2/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: drop duplicate fan properties
From: Frank Wunderlich @ 2026-04-12 9:23 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
These properties are already set in the original node and do not need
to be defined again.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
.../boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 1175ee156cb3..759f608d1081 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -185,13 +185,6 @@ ð {
status = "okay";
};
-&fan {
- pinctrl-0 = <&pwm0_pins>;
- pinctrl-names = "default";
- pwms = <&pwm 0 50000>;
- status = "okay";
-};
-
&gmac0 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: rename mgmt port to lan5
From: Frank Wunderlich @ 2026-04-12 9:23 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
It turns out that the label mgmt confuses users and now official case is
released where the port is labeled with number 5. So just rename it to
lan5 to follow naming convension (lan1-4 from mxl switch and lan6 for lan-
combo).
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
---
arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index a48132f09411..1175ee156cb3 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -207,7 +207,7 @@ &gsw_phy0_led0 {
};
&gsw_port0 {
- label = "mgmt";
+ label = "lan5";
};
/* R4Pro has only port 0 connected, so disable the others */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: mediatek: mt7988a-bpi-r4pro: update gpio-leds
From: Frank Wunderlich @ 2026-04-12 9:23 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Frank Wunderlich, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, Daniel Golle, Andrew LaMarche
In-Reply-To: <20260412092333.6371-1-linux@fw-web.de>
From: Frank Wunderlich <frank-w@public-files.de>
On the official case the red LED is named ERR, the blue LED is named ACT.
Reflect these labels in function and set them default off.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
---
v2:
- dropped default-state as suggested by daniel
---
arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
index 759f608d1081..bbd6c16a8cb0 100644
--- a/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7988a-bananapi-bpi-r4-pro.dtsi
@@ -61,14 +61,14 @@ gpio-leds {
led_red: sys-led-red {
color = <LED_COLOR_ID_RED>;
+ function = LED_FUNCTION_FAULT;
gpios = <&pca9555 15 GPIO_ACTIVE_HIGH>;
- default-state = "on";
};
led_blue: sys-led-blue {
color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_ACTIVITY;
gpios = <&pca9555 14 GPIO_ACTIVE_HIGH>;
- default-state = "on";
};
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Krzysztof Kozlowski @ 2026-04-12 9:20 UTC (permalink / raw)
To: Andrea della Porta
Cc: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <6f0fa1a817b5af5040b652320daa7268297932a9.1775829499.git.andrea.porta@suse.com>
On Fri, Apr 10, 2026 at 04:09:57PM +0200, Andrea della Porta wrote:
> From: Naushir Patuck <naush@raspberrypi.com>
>
> Add the devicetree binding documentation for the PWM
> controller found in the Raspberry Pi RP1 chipset.
>
> Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> ---
> .../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++++++++++++++++++
> 1 file changed, 54 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Krzysztof Kozlowski @ 2026-04-12 9:18 UTC (permalink / raw)
To: Anushka Badhe
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, linux-sound, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260410055532.60868-1-anushkabadhe@gmail.com>
On Fri, Apr 10, 2026 at 11:25:32AM +0530, Anushka Badhe wrote:
> Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
> format.
>
> Update rockchip,cpu from a single I2S controller phandle to a
> phandle-array. Add an optional second entry for the SPDIF controller,
> as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
>
> Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
> ---
> Changes in v2:
> - Fix subject and body: "YAML Schema" -> "DT Schema"
> - Fix title: "ROCKCHIP" -> "Rockchip"
> - List items for rockchip,cpu with I2S and SPDIF descriptions
> - List items for rockchip,codec
> - Update descriptions for rockchip,cpu, rockchip,codec and
> dmic-wakeup-delay-ms
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: sdm845-xiaomi-beryllium-tianma: Disable MDSS
From: David Heidelberg @ 2026-04-12 9:03 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sam Day, linux-arm-msm, devicetree, linux-kernel,
phone-devel, Petr Hodina
In-Reply-To: <eyg2ivnoe7weschcvyuhlzqfnqdfnomxc7b56kuypawj6ui7ds@tkdhm2ckrpq6>
On 12/04/2026 02:36, Dmitry Baryshkov wrote:
> On Fri, Apr 10, 2026 at 03:51:12PM +0200, David Heidelberg wrote:
>> On 18/03/2026 15:47, Dmitry Baryshkov wrote:
>>> On Tue, Mar 17, 2026 at 11:12:35PM +0100, David Heidelberg via B4 Relay wrote:
>>>> From: Petr Hodina <petr.hodina@protonmail.com>
>>>>
>>>> Currently the panel driver for tianma is broken.
>>>> Disable MDSS to prevent DRM taking over the framebuffer.
>>>
>>> I'd still hope that somebody can get it to work. I'd start by using
>>> prepare_prev_first. Sumit reported the panel as working in 2020 and I
>>> have no doubts that it was the case. Another option migt be something
>>> related to the dispcc (see my [1]).
>>
>> Sadly, the prepare_prev_first didn't solve the issue. The framebuffer ->
>> MDSS takover happens, but at greetd (login) loading screen goes black and
>> never restores.
>>
>> Will need more work.
>
> Do you see a console _while_ it boots, after the handover? I'd check the
> mode programming. Maybe, disabling panel reset would also (temporarily)
> help.
When I get access to the phone for longer period of time I'll try to debug it
step by step. This time I had only time to flash kernel and test if it boots
with prepare_prev_first.
David
>
>>
>> David>
>>> [1] https://lore.kernel.org/linux-arm-msm/20260217-sdm845-hdk-v1-1-866f1965fef7@oss.qualcomm.com/
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH v7 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Krzysztof Kozlowski @ 2026-04-12 8:26 UTC (permalink / raw)
To: Markus Probst
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <20260411-synology_microp_initial-v7-2-9a3a094e763a@posteo.de>
On Sat, Apr 11, 2026 at 05:27:35PM +0200, Markus Probst wrote:
> +properties:
> + compatible:
> + enum:
> + - synology,ds923p-microp
> + - synology,ds918p-microp
> + - synology,ds214play-microp
> + - synology,ds225p-microp
> + - synology,ds425p-microp
> + - synology,ds710p-microp
> + - synology,ds1010p-microp
> + - synology,ds723p-microp
> + - synology,ds1522p-microp
> + - synology,rs422p-microp
> + - synology,ds725p-microp
> + - synology,ds118-microp
> + - synology,ds124-microp
> + - synology,ds223-microp
> + - synology,ds223j-microp
> + - synology,ds1823xsp-microp
> + - synology,rs822p-microp
> + - synology,rs1221p-microp
> + - synology,rs1221rpp-microp
> + - synology,ds925p-microp
> + - synology,ds1525p-microp
> + - synology,ds1825p-microp
Previous comment is not resolved. For example you stated that ds723p is
compatible with ds725p, so this should be expressed.
ds918p and ds415p as well. ds925p and several others you EXPLICITLY
wrote they are compatible:
"ds925p, ds1525p, ds1825p, ds1823xsp:
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor"
Probably many more cases, I did not verify all of them.
If there is going to be new version, please organize the patch
documenting the compatible (DT bindings) before the patch using that
compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
> +
> + fan-failure-gpios:
> + description: GPIOs needed to determine which fans stopped working on a fan failure event.
> + minItems: 2
> + maxItems: 3
> +
> +required:
> + - compatible
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mmc: dw-mshc-common: add option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-12 4:46 UTC (permalink / raw)
To: Kaustabh Chakraborty, Krzysztof Kozlowski, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaehoon Chung,
Shawn Lin
Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <DHQW60ZTLODV.3C6OG2KUNVSBR@disroot.org>
On 2026-04-12 09:59 +05:30, Kaustabh Chakraborty wrote:
> On 2026-04-11 22:27 +02:00, Krzysztof Kozlowski wrote:
>> On 11/04/2026 21:43, Kaustabh Chakraborty wrote:
>>> Some controllers, such as certain Exynos SDIO ones, are unable to
>>> perform DMA transfers of small amount of bytes properly. Add a property
>>> to configure the DMA transfer threshold.
>>>
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>> .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> index 6f11b2adf1036..1693277957a91 100644
>>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>>> @@ -57,6 +57,14 @@ properties:
>>> force fifo watermark setting accordingly.
>>> $ref: /schemas/types.yaml#/definitions/flag
>>>
>>> + dma-threshold-bytes:
>>> + description:
>>> + DMA transfer takes place only if the transfer size is equal to or greater
>>> + than the number of bytes defined by the threshold value. Some controllers are
>>> + unable to perform the DMA transfer properly with small amounts of data.
>>
>> Looks like controller specific, thus should be deducible from the
>> compatible.
>
> "samsung,dma-threshold-bytes"? So you also suggest I move it to the
> Samsung's schema? Okay.
Ahh, nevermind I get it. A separate controller compatible which sets a
higher threshold.
>
>>
>> Best regards,
>> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mmc: dw-mshc-common: add option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-12 4:29 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaehoon Chung,
Shawn Lin
Cc: linux-mmc, devicetree, linux-kernel
In-Reply-To: <6d692d1f-ab67-463a-9135-520a36977d5d@kernel.org>
On 2026-04-11 22:27 +02:00, Krzysztof Kozlowski wrote:
> On 11/04/2026 21:43, Kaustabh Chakraborty wrote:
>> Some controllers, such as certain Exynos SDIO ones, are unable to
>> perform DMA transfers of small amount of bytes properly. Add a property
>> to configure the DMA transfer threshold.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> .../devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>> index 6f11b2adf1036..1693277957a91 100644
>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc-common.yaml
>> @@ -57,6 +57,14 @@ properties:
>> force fifo watermark setting accordingly.
>> $ref: /schemas/types.yaml#/definitions/flag
>>
>> + dma-threshold-bytes:
>> + description:
>> + DMA transfer takes place only if the transfer size is equal to or greater
>> + than the number of bytes defined by the threshold value. Some controllers are
>> + unable to perform the DMA transfer properly with small amounts of data.
>
> Looks like controller specific, thus should be deducible from the
> compatible.
"samsung,dma-threshold-bytes"? So you also suggest I move it to the
Samsung's schema? Okay.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 11/12] ASoC: dt-bindings: google,sc7280-herobrine: Add Radxa Dragon Q6A sound card
From: Xilin Wu @ 2026-04-12 3:47 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Liam Girdwood, Mark Brown,
Judy Hsiao, linux-arm-msm, linux-kernel, devicetree,
Konrad Dybcio, linux-sound
In-Reply-To: <20260408-pretty-poodle-from-atlantis-dfd1fb@quoll>
On 4/8/2026 4:48 PM, Krzysztof Kozlowski wrote:
> On Tue, Apr 07, 2026 at 11:20:03PM +0800, Xilin Wu wrote:
>> The Radxa Dragon Q6A can boot in EL2, allowing the kernel to access the
>> LPASS hardware directly. Add the compatible for it to the bindings.
>
> You are not adding compatible for LPASS, but for the sound card. And
> since you mentioned it, what happens when you boot in EL1?
>
> You need to post bindings for both cases.
>
> Best regards,
> Krzysztof
>
>
Hi Krzysztof,
Thank you for the review. You are right that this patch adds a
board-specific compatible for the sound card, not for the LPASS block
itself.
For EL1, the default Dragon Q6A DTS already uses the generic
"qcom,qcs6490-rb3gen2-sndcard" compatible, and for the EL2 LPASS-CPU
variant I can also just keep using the generic
"google,sc7280-herobrine" compatible.
Would it be better if I simply drop this binding patch and keep both
cases on their existing generic compatibles instead of introducing
"radxa,dragon-q6a-sndcard"?
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* Re: [PATCH 03/12] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Enable USB 3.0 and HDMI ports
From: Xilin Wu @ 2026-04-12 3:14 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Liam Girdwood, Mark Brown, Judy Hsiao
Cc: linux-arm-msm, linux-kernel, devicetree, linux-sound
In-Reply-To: <eb745e3f-4bc6-4713-97aa-1a1a584c9a9d@oss.qualcomm.com>
On 4/8/2026 5:03 PM, Konrad Dybcio wrote:
> On 4/7/26 5:19 PM, Xilin Wu wrote:
>> This board doesn't feature a regular Type-C port. The usb_1_qmpphy's
>
> I guess the receptacle on board is power-only?
Yes. The Type-C port is power only.
>
>> RX1/TX1 pair is statically connected to the USB-A port, while its RX0/TX0
>> pair is connected to the RA620 DP-to-HDMI bridge.
>>
>> Add and enable the nodes for the features to work.
>>
>> Signed-off-by: Xilin Wu <sophon@radxa.com>
>> ---
>> .../boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts | 152 +++++++++++++++++++++
>> 1 file changed, 152 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> index c961d3ec625f..8d649b3a1cfa 100644
>> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
>> @@ -111,6 +111,71 @@ usb2_3_connector: endpoint {
>> };
>> };
>>
>> + usb3_con: connector {
>
> This label is unused
Ack. I will remove the label.
>
>> + compatible = "usb-a-connector";
>
> No vbus-supply?
It's supplied by vcc_5v_peri. I'll add it in v2.
>
> [...]
>
>> +&mdss_dp {
>> + sound-name-prefix = "Display Port0";
>
> Hmmmmm.. other platforms call it "DisplayPort0" (without a space)..
> But I suppose this name needs to match UCM..
>
> We'd also normally push this property to the SoC DTSI
Actually I don't think the name is used in UCM. I can rename it and push
the property to SoC DTSI if necessary.
>
> Konrad
>
--
Best regards,
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* Re: [PATCH 11/16] clk: tests: Add Kunit testing for nexus nodes
From: Stephen Boyd @ 2026-04-12 1:40 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric), Antoine Tenart,
Christian Marangi, Conor Dooley, David S. Miller,
Geert Uytterhoeven, Herbert Xu, Jayesh Choudhary,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette,
Olivia Mackall, Rob Herring, Thomas Gleixner
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-11-5e6ff7853994@bootlin.com>
Quoting Miquel Raynal (Schneider Electric) (2026-03-27 13:09:33)
> Add a nexus node with a child requesting a mapped clock in the fake DT
> overlay to verify that the parsing is also correctly working.
>
> Suggested-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
> drivers/clk/clk_test.c | 20 ++++++++++++++++++++
> drivers/clk/kunit_clk_parse_clkspec.dtso | 10 ++++++++++
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
> index 8a17ad0d185f..cb0071955146 100644
> --- a/drivers/clk/clk_test.c
> +++ b/drivers/clk/clk_test.c
> @@ -3660,10 +3660,30 @@ static void clk_parse_and_get_parent_name(struct kunit *test)
> clk_parse_clkspec_1_init_data.name);
> }
>
> +static void clk_parse_and_get_nexus(struct kunit *test)
of_clk_get_hw_maps_thru_nexus()
> +{
> + struct clk_parse_clkspec_ctx *ctx = test->priv;
> + struct clk_hw *hw1, *hw2;
> + struct device_node *np;
> +
> + /* Get clocks by index */
> + np = of_find_node_by_name(NULL, "kunit-clock-nexus-child");
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
> + hw1 = of_clk_get_hw(np, 0, NULL);
> + KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw1);
> +
> + hw2 = of_clk_get_hw(ctx->cons_np, 1, NULL);
> + KUNIT_EXPECT_NOT_ERR_OR_NULL(test, hw2);
> + KUNIT_EXPECT_PTR_EQ(test, hw1, hw2);
I think hw2 is expected? Rewrite it like this?
struct clk_parse_clkspec_ctx *ctx = test->priv;
struct clk_hw *expected;
struct device_node *np;
np = of_find_node_by_name(NULL, "kunit-clock-nexus-child");
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, np);
expected = of_clk_get_hw(ctx->cons_np, 1, NULL);
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, expected);
KUNIT_EXPECT_PTR_EQ(test, expected, of_clk_get_hw(np, 0, NULL));
We're also leaking the of_node if an assert triggers so we need to use a
kunit wrapper version of of_find_node_by_name() or do a hand code
version of putting the node when kunit asserts.
^ permalink raw reply
* Re: [PATCH 07/16] clk: tests: Add Kunit testing for of_clk_get_parent_name()
From: Stephen Boyd @ 2026-04-12 1:29 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric), Antoine Tenart,
Christian Marangi, Conor Dooley, David S. Miller,
Geert Uytterhoeven, Herbert Xu, Jayesh Choudhary,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette,
Olivia Mackall, Rob Herring, Thomas Gleixner
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-7-5e6ff7853994@bootlin.com>
Quoting Miquel Raynal (Schneider Electric) (2026-03-27 13:09:29)
> diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
> index b814b45f1f7e..8a17ad0d185f 100644
> --- a/drivers/clk/clk_test.c
> +++ b/drivers/clk/clk_test.c
> @@ -3651,9 +3651,19 @@ static void clk_parse_clkspec_with_incorrect_index_and_name(struct kunit *test)
> KUNIT_EXPECT_TRUE(test, IS_ERR(hw));
> }
>
Add a comment here to tell us what the test is expecting.
> +static void clk_parse_and_get_parent_name(struct kunit *test)
> +{
> + struct clk_parse_clkspec_ctx *ctx = test->priv;
> +
> + KUNIT_EXPECT_STREQ(test,
> + of_clk_get_parent_name(ctx->cons_np, 0),
> + clk_parse_clkspec_1_init_data.name);
> +}
Reading this test is pretty hard because all the context is in the
common setup. Maybe the common setup is too broad in this case and
should be simplified so that tests can show more setup and assert code
for the things it wants to do. For example, if the name can be passed
from this test directly it would clarify by moving context into test
function scope.
const char *pname = "expected-name";
KUNIT_ASSERT_EQ(test, 0, setup_parent(pname));
KUNIT_EXPECT_STREQ(test, pname,
of_clk_get_parent_name(ctx->cons_np, 0));
> +
> static struct kunit_case clk_parse_clkspec_test_cases[] = {
> KUNIT_CASE(clk_parse_clkspec_with_correct_index_and_name),
> KUNIT_CASE(clk_parse_clkspec_with_incorrect_index_and_name),
> + KUNIT_CASE(clk_parse_and_get_parent_name),
Better to call the test something like
of_clk_get_parent_name_gets_parent_name to indicate what we're testing.
^ permalink raw reply
* Re: [PATCH 01/16] dt-bindings: clock: Introduce nexus nodes
From: Stephen Boyd @ 2026-04-12 1:16 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric), Antoine Tenart,
Christian Marangi, Conor Dooley, David S. Miller,
Geert Uytterhoeven, Herbert Xu, Jayesh Choudhary,
Krzysztof Kozlowski, Magnus Damm, Michael Turquette,
Olivia Mackall, Rob Herring, Thomas Gleixner
Cc: Thomas Petazzoni, Pascal EBERHARD, Wolfram Sang, linux-clk,
devicetree, linux-kernel, linux-crypto, linux-renesas-soc,
Miquel Raynal (Schneider Electric)
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-1-5e6ff7853994@bootlin.com>
Quoting Miquel Raynal (Schneider Electric) (2026-03-27 13:09:23)
> diff --git a/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> new file mode 100644
> index 000000000000..f07e2972e8aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/clock-nexus-node.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Clock Nexus
> +
> +description: >
> + A nexus node allows to remap a phandle list in a consumer node through a
Should this say "remap a clock specifier list" instead of "remap a
phandle list"? A phandle list sounds like there are zero cells.
> + container or a connector node in a generic way. With this remapping,
> + the consumer node needs to know only about the nexus node. Resources
> + behind the nexus node are decoupled by the nexus node itself.
^ permalink raw reply
* Re: [PATCH 10/16] clk: Add support for clock nexus dt bindings
From: Stephen Boyd @ 2026-04-12 1:12 UTC (permalink / raw)
To: Brian Masney, Miquel Raynal
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thomas Gleixner, Olivia Mackall, Herbert Xu, Jayesh Choudhary,
David S. Miller, Christian Marangi, Antoine Tenart,
Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc, Herve Codina
In-Reply-To: <87y0j76p8o.fsf@bootlin.com>
Quoting Miquel Raynal (2026-04-01 01:47:51)
> Hello Brian,
>
> First, thanks for the whole review.
>
> On 30/03/2026 at 11:16:44 -04, Brian Masney <bmasney@redhat.com> wrote:
> >> - ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
> >> - index, out_args);
> >> + ret = of_parse_phandle_with_args_map(np, "clocks", "clock",
> >> + index, out_args);
> >
> > Before I left my Reviewed-by, I should have double checked Sashiko. It
> > has several questions about this patch. The first is:
> >
> > Are there other places in the clock framework that need to transition to the
> > new map API to ensure assigned clocks work?
> >
> > For instance, assigned-clocks and assigned-clock-parents are parsed in
> > drivers/clk/clk-conf.c using of_parse_phandle_with_args(). If a device
> > specifies an assigned clock that routes through a nexus node, will it fail
> > to configure because the map is not traversed?
>
> The goal of the nexus node is to isolate what is behind. Are
> assigned-clocks et al. supposed to traverse a nexus node? I am tempted
> to say "no", but I'm open to discussing this ofc.
Why would assigned-clocks not traverse the nexus node? If I'm a DT
author I would think any clock specifier should be routed properly
through the nexus node.
^ permalink raw reply
* Re: [PATCH v2 19/21] drm/panel: add driver for Waveshare 8.8" DSI TOUCH-A panel
From: Jie Gan @ 2026-04-12 1:09 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260411-waveshare-dsi-touch-v2-19-75cdbeac5156@oss.qualcomm.com>
On 4/11/2026 8:10 PM, Dmitry Baryshkov wrote:
> Add driver for the panel found on Waveshare 8.8" DSI TOUCH-A kit. It
> uses ota7290b IC as a controller.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/panel/Kconfig | 12 ++
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-focaltech-ota7290b.c | 208 +++++++++++++++++++++++
> 3 files changed, 221 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index ba527b4d7737..979109c27b9b 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -144,6 +144,18 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
> Say Y if you want to enable support for panels based on the
> Feiyang FY07024DI26A30-D MIPI-DSI interface.
>
> +config DRM_PANEL_FOCALTECH_OTA7290B
> + tristate "Focaltech OTA7290B"
> + depends on DRM_MIPI_DSI
> + depends on I2C
> + depends on BACKLIGHT_CLASS_DEVICE
> + select DRM_KMS_HELPER
> + help
> + Enable support for panels using OTA7290B as a controller (for
> + example, Waveshare 12.3" DSI TOUCH-A panel). Say Y here if you want
> + to enable support for this panel. To compile this driver as a module,
> + choose M here.
> +
> config DRM_PANEL_DSI_CM
> tristate "Generic DSI command mode panels"
> depends on OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index a4291dc3905b..0d694acbfbb6 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
> obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
> obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
> obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o
> +obj-$(CONFIG_DRM_PANEL_FOCALTECH_OTA7290B) += panel-focaltech-ota7290b.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX8279) += panel-himax-hx8279.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
> diff --git a/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c b/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c
> new file mode 100644
> index 000000000000..991d6a4caf17
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2024 Waveshare International Limited
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +
> +struct ota7290b {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> +
> + struct regulator *power;
> + struct gpio_desc *reset;
> + struct regulator *avdd;
> + struct regulator *iovcc;
> +
> + enum drm_panel_orientation orientation;
> +};
> +
> +static inline struct ota7290b *panel_to_ota(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ota7290b, panel);
> +}
> +
> +static int ota7290b_prepare(struct drm_panel *panel)
> +{
> + struct ota7290b *ctx = panel_to_ota(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> + int ret;
> +
> + if (ctx->iovcc) {
> + ret = regulator_enable(ctx->iovcc);
> + if (ret)
> + dev_err(panel->dev, "failed to enable IO regulator: %d\n", ret);
> + }
> +
> + if (ctx->avdd) {
> + ret = regulator_enable(ctx->avdd);
> + if (ret)
> + dev_err(panel->dev, "failed to enable AVDD regulator: %d\n", ret);
> + }
> +
> + if (ctx->reset) {
> + gpiod_set_value_cansleep(ctx->reset, 0);
> + msleep(60);
> + gpiod_set_value_cansleep(ctx->reset, 1);
> + msleep(60);
> + gpiod_set_value_cansleep(ctx->reset, 0);
> + msleep(60);
> + }
> +
> + mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 120);
> + mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + if (dsi_ctx.accum_err < 0)
> + dev_err(panel->dev, "failed to init panel: %d\n", ret);
better to check dsi_ctx.accum_err instead ret here?
dev_err(panel->dev, "failed to init panel: %d\n", dsi_ctx.accum_err);
Thanks,
Jie
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ota7290b_unprepare(struct drm_panel *panel)
> +{
> + struct ota7290b *ctx = panel_to_ota(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> +
> + if (ctx->reset) {
> + gpiod_set_value_cansleep(ctx->reset, 1);
> + msleep(5);
> + }
> +
> + if (ctx->avdd)
> + regulator_disable(ctx->avdd);
> +
> + if (ctx->iovcc)
> + regulator_disable(ctx->iovcc);
> +
> + return 0;
> +}
> +
> +static const struct drm_display_mode waveshare_dsi_touch_8_8_a_mode = {
> + .clock = 75000,
> +
> + .hdisplay = 480,
> + .hsync_start = 480 + 50,
> + .hsync_end = 480 + 50 + 50,
> + .htotal = 480 + 50 + 50 + 50,
> +
> + .vdisplay = 1920,
> + .vsync_start = 1920 + 20,
> + .vsync_end = 1920 + 20 + 20,
> + .vtotal = 1920 + 20 + 20 + 20,
> +
> + .width_mm = 68,
> + .height_mm = 219,
> + .type = DRM_MODE_TYPE_DRIVER,
> +};
> +
> +static int ota7290b_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + return drm_connector_helper_get_modes_fixed(connector, &waveshare_dsi_touch_8_8_a_mode);
> +}
> +
> +static enum drm_panel_orientation ota7290b_get_orientation(struct drm_panel *panel)
> +{
> + struct ota7290b *ctx = panel_to_ota(panel);
> +
> + return ctx->orientation;
> +}
> +
> +static const struct drm_panel_funcs ota7290b_funcs = {
> + .prepare = ota7290b_prepare,
> + .unprepare = ota7290b_unprepare,
> + .get_modes = ota7290b_get_modes,
> + .get_orientation = ota7290b_get_orientation,
> +};
> +
> +static int ota7290b_probe(struct mipi_dsi_device *dsi)
> +{
> + struct ota7290b *ctx;
> + int ret;
> +
> + ctx = devm_drm_panel_alloc(&dsi->dev, struct ota7290b, panel,
> + &ota7290b_funcs,
> + DRM_MODE_CONNECTOR_DSI);
> + if (!ctx)
> + return -ENOMEM;
> + mipi_dsi_set_drvdata(dsi, ctx);
> + ctx->dsi = dsi;
> +
> + ctx->reset = devm_gpiod_get_optional(&dsi->dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(ctx->reset))
> + return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
> + "Couldn't get our reset GPIO\n");
> +
> + ctx->iovcc = devm_regulator_get_optional(&dsi->dev, "iovcc");
> + if (IS_ERR(ctx->iovcc))
> + return dev_err_probe(&dsi->dev, PTR_ERR(ctx->iovcc),
> + "Couldn't get our iovcc supply\n");
> +
> + ctx->avdd = devm_regulator_get_optional(&dsi->dev, "avdd");
> + if (IS_ERR(ctx->avdd))
> + return dev_err_probe(&dsi->dev, PTR_ERR(ctx->avdd),
> + "Couldn't get our avdd supply\n");
> +
> + ret = of_drm_get_panel_orientation(
> + dsi->dev.of_node, &ctx->orientation);
> + if (ret) {
> + dev_err(&dsi->dev, "%pOF: failed to get orientation: %d\n",
> + dsi->dev.of_node, ret);
> + return ret;
> + }
> +
> + ret = drm_panel_of_backlight(&ctx->panel);
> + if (ret)
> + return ret;
> +
> + ctx->panel.prepare_prev_first = true;
> +
> + ret = devm_drm_panel_add(&dsi->dev, &ctx->panel);
> + if (ret)
> + return ret;
> +
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE |
> + MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS,
> + dsi->format = MIPI_DSI_FMT_RGB888,
> + dsi->lanes = 2;
> +
> + return devm_mipi_dsi_attach(&dsi->dev, dsi);
> +}
> +
> +static const struct of_device_id ota7290b_of_match[] = {
> + { .compatible = "waveshare,8.8-dsi-touch-a", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, ota7290b_of_match);
> +
> +static struct mipi_dsi_driver ota7290b_driver = {
> + .probe = ota7290b_probe,
> + .driver = {
> + .name = "focaltech-ota7290b",
> + .of_match_table = ota7290b_of_match,
> + },
> +};
> +module_mipi_dsi_driver(ota7290b_driver);
> +
> +MODULE_DESCRIPTION("Panel driver for Focaltech OTA7290B panels");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v2 21/21] gpio: add GPIO controller found on Waveshare DSI TOUCH panels
From: Jie Gan @ 2026-04-12 1:06 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260411-waveshare-dsi-touch-v2-21-75cdbeac5156@oss.qualcomm.com>
On 4/11/2026 8:10 PM, Dmitry Baryshkov wrote:
> The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> controller, which controls power supplies to the panel and the touch
> screen and provides reset pins for both the panel and the touchscreen.
> Also it provides a simple PWM controller for panel backlight. Add
> support for this GPIO controller.
>
> Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpio/Kconfig | 10 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-waveshare-dsi.c | 208 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 219 insertions(+)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index dbe7c6e63eab..1b210c451151 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -805,6 +805,16 @@ config GPIO_VISCONTI
> help
> Say yes here to support GPIO on Tohisba Visconti.
>
> +config GPIO_WAVESHARE_DSI_TOUCH
> + tristate "Waveshare GPIO controller for DSI panels"
> + depends on BACKLIGHT_CLASS_DEVICE
> + depends on I2C
> + select REGMAP_I2C
> + help
> + Enable support for the GPIO and PWM controller found on Waveshare DSI
> + TOUCH panel kits. It provides GPIOs (used for regulator control and
> + resets) and backlight support.
> +
> config GPIO_WCD934X
> tristate "Qualcomm Technologies Inc WCD9340/WCD9341 GPIO controller driver"
> depends on MFD_WCD934X
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 20d4a57afdaa..75ce89fc3b93 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -207,6 +207,7 @@ obj-$(CONFIG_GPIO_VIRTUSER) += gpio-virtuser.o
> obj-$(CONFIG_GPIO_VIRTIO) += gpio-virtio.o
> obj-$(CONFIG_GPIO_VISCONTI) += gpio-visconti.o
> obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
> +obj-$(CONFIG_GPIO_WAVESHARE_DSI_TOUCH) += gpio-waveshare-dsi.o
> obj-$(CONFIG_GPIO_WCD934X) += gpio-wcd934x.o
> obj-$(CONFIG_GPIO_WHISKEY_COVE) += gpio-wcove.o
> obj-$(CONFIG_GPIO_WINBOND) += gpio-winbond.o
> diff --git a/drivers/gpio/gpio-waveshare-dsi.c b/drivers/gpio/gpio-waveshare-dsi.c
> new file mode 100644
> index 000000000000..f4a1d4d3b872
> --- /dev/null
> +++ b/drivers/gpio/gpio-waveshare-dsi.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2024 Waveshare International Limited
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/err.h>
> +#include <linux/fb.h>
> +#include <linux/gpio/driver.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regmap.h>
> +
> +/* I2C registers of the microcontroller. */
> +#define REG_TP 0x94
> +#define REG_LCD 0x95
> +#define REG_PWM 0x96
> +#define REG_SIZE 0x97
> +#define REG_ID 0x98
> +#define REG_VERSION 0x99
> +
> +enum {
> + GPIO_AVDD = 0,
> + GPIO_PANEL_RESET = 1,
> + GPIO_BL_ENABLE = 2,
> + GPIO_IOVCC = 4,
> + GPIO_VCC = 8,
> + GPIO_TS_RESET = 9,
> +};
> +
> +#define NUM_GPIO 16
> +
> +struct waveshare_gpio {
> + struct mutex dir_lock;
> + struct mutex pwr_lock;
> + struct regmap *regmap;
> + u16 poweron_state;
> +
> + struct gpio_chip gc;
> +};
> +
> +static const struct regmap_config waveshare_gpio_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = REG_PWM,
.max_register = REG_VERSION,
check comments in probe
> +};
> +
> +static int waveshare_gpio_get(struct waveshare_gpio *state, unsigned int offset)
> +{
> + u16 pwr_state;
> +
> + guard(mutex)(&state->pwr_lock);
> + pwr_state = state->poweron_state & BIT(offset);
> +
> + return !!pwr_state;
> +}
> +
> +static int waveshare_gpio_set(struct waveshare_gpio *state, unsigned int offset, int value)
> +{
> + u16 last_val;
> + int err;
> +
> + guard(mutex)(&state->pwr_lock);
> +
> + last_val = state->poweron_state;
> + if (value)
> + last_val |= BIT(offset);
> + else
> + last_val &= ~BIT(offset);
> +
> + state->poweron_state = last_val;
> +
> + err = regmap_write(state->regmap, REG_TP, last_val >> 8);
> + if (!err)
> + err = regmap_write(state->regmap, REG_LCD, last_val & 0xff);
> +
> + return err;
> +}
> +
> +static int waveshare_gpio_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
> +{
> + return GPIO_LINE_DIRECTION_OUT;
> +}
> +
> +static int waveshare_gpio_gpio_get(struct gpio_chip *gc, unsigned int offset)
> +{
> + struct waveshare_gpio *state = gpiochip_get_data(gc);
> +
> + return waveshare_gpio_get(state, offset);
> +}
> +
> +static int waveshare_gpio_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
> +{
> + struct waveshare_gpio *state = gpiochip_get_data(gc);
> +
> + return waveshare_gpio_set(state, offset, value);
> +}
> +
> +static int waveshare_gpio_update_status(struct backlight_device *bl)
> +{
> + struct waveshare_gpio *state = bl_get_data(bl);
> + int brightness = backlight_get_brightness(bl);
> +
> + waveshare_gpio_set(state, GPIO_BL_ENABLE, brightness);
> +
> + return regmap_write(state->regmap, REG_PWM, brightness);
> +}
> +
> +static const struct backlight_ops waveshare_gpio_bl = {
> + .update_status = waveshare_gpio_update_status,
> +};
> +
> +static int waveshare_gpio_probe(struct i2c_client *i2c)
> +{
> + struct backlight_properties props = {};
> + struct waveshare_gpio *state;
> + struct device *dev = &i2c->dev;
> + struct backlight_device *bl;
> + struct regmap *regmap;
> + unsigned int data;
> + int ret;
> +
> + state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return -ENOMEM;
> +
> + ret = devm_mutex_init(dev, &state->dir_lock);
> + if (ret)
> + return ret;
> +
> + ret = devm_mutex_init(dev, &state->pwr_lock);
> + if (ret)
> + return ret;
> +
> + regmap = devm_regmap_init_i2c(i2c, &waveshare_gpio_regmap_config);
for waveshare_gpio_regmap_config: .max_register = REG_PWM,
> + if (IS_ERR(regmap))
> + return dev_err_probe(dev, PTR_ERR(regmap), "Failed to allocate register map\n");
> +
> + state->regmap = regmap;
> + i2c_set_clientdata(i2c, state);
> +
> + ret = regmap_read(regmap, REG_ID, &data);
REG_ID here is 0x98,
in _regmap_read -> regmap_readable will check the max_register, then
return -EIO.
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to read register\n");
> +
> + dev_dbg(dev, "waveshare panel hw id = 0x%x\n", data);
> +
> + ret = regmap_read(regmap, REG_SIZE, &data);
ditto.
Thanks,
Jie
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to read register\n");
> +
> + dev_dbg(dev, "waveshare panel size = %d\n", data);
> +
> + ret = regmap_read(regmap, REG_VERSION, &data);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to read register\n");
> +
> + dev_dbg(dev, "waveshare panel mcu version = 0x%x\n", data);
> +
> + ret = waveshare_gpio_set(state, GPIO_TS_RESET, 1);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to program GPIOs\n");
> +
> + msleep(20);
> +
> + state->gc.parent = dev;
> + state->gc.label = i2c->name;
> + state->gc.owner = THIS_MODULE;
> + state->gc.base = -1;
> + state->gc.ngpio = NUM_GPIO;
> +
> + /* it is output only */
> + state->gc.get = waveshare_gpio_gpio_get;
> + state->gc.set = waveshare_gpio_gpio_set;
> + state->gc.get_direction = waveshare_gpio_gpio_get_direction;
> + state->gc.can_sleep = true;
> +
> + ret = devm_gpiochip_add_data(dev, &state->gc, state);
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to create gpiochip\n");
> +
> + props.type = BACKLIGHT_RAW;
> + props.max_brightness = 255;
> + props.brightness = 255;
> + bl = devm_backlight_device_register(dev, dev_name(dev), dev, state,
> + &waveshare_gpio_bl, &props);
> + return PTR_ERR_OR_ZERO(bl);
> +}
> +
> +static const struct of_device_id waveshare_gpio_dt_ids[] = {
> + { .compatible = "waveshare,dsi-touch-gpio" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, waveshare_gpio_dt_ids);
> +
> +static struct i2c_driver waveshare_gpio_regulator_driver = {
> + .driver = {
> + .name = "waveshare-regulator",
> + .of_match_table = of_match_ptr(waveshare_gpio_dt_ids),
> + },
> + .probe = waveshare_gpio_probe,
> +};
> +
> +module_i2c_driver(waveshare_gpio_regulator_driver);
> +
> +MODULE_DESCRIPTION("GPIO controller driver for Waveshare DSI touch panels");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v2 12/21] drm/panel: jadard-jd9365da-h3: support variable DSI configuration
From: Jie Gan @ 2026-04-12 0:55 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260411-waveshare-dsi-touch-v2-12-75cdbeac5156@oss.qualcomm.com>
On 4/11/2026 8:10 PM, Dmitry Baryshkov wrote:
> Several panels support attachment either using 4 DSI lanes or just 2. In
> some cases, this requires a different panel mode to fulfill clock
> requirements. Extend the driver to handle such cases by letting the
> panel description to omit lanes specification and parsing number of
> lanes from the DT.
>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c | 32 +++++++++++++++++-------
> 1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> index 1884ad2404cd..5d9db2e1f28f 100644
> --- a/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> +++ b/drivers/gpu/drm/panel/panel-jadard-jd9365da-h3.c
> @@ -10,6 +10,7 @@
>
> #include <drm/drm_mipi_dsi.h>
> #include <drm/drm_modes.h>
> +#include <drm/drm_of.h>
> #include <drm/drm_panel.h>
> #include <drm/drm_print.h>
> #include <drm/drm_probe_helper.h>
> @@ -23,7 +24,8 @@
> struct jadard;
>
> struct jadard_panel_desc {
> - const struct drm_display_mode mode;
> + const struct drm_display_mode *mode_4ln;
> + const struct drm_display_mode *mode_2ln;
> unsigned int lanes;
> enum mipi_dsi_pixel_format format;
> int (*init)(struct jadard *jadard);
> @@ -57,7 +59,10 @@ static void jadard_enable_standard_cmds(struct mipi_dsi_multi_context *dsi_ctx)
> mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xe1, 0x93);
> mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xe2, 0x65);
> mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xe3, 0xf8);
> - mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x80, 0x03);
> + if (dsi_ctx->dsi->lanes == 2)
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x80, 0x01);
> + else
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x80, 0x03);
> }
>
> static inline struct jadard *panel_to_jadard(struct drm_panel *panel)
> @@ -151,7 +156,10 @@ static int jadard_get_modes(struct drm_panel *panel,
> {
> struct jadard *jadard = panel_to_jadard(panel);
>
> - return drm_connector_helper_get_modes_fixed(connector, &jadard->desc->mode);
> + if (jadard->dsi->lanes == 2)
Worth to add a check here:
if (jadard->dsi->lanes == 2 && jadard->desc->mode_2ln)
Some pre-existing panel desc(e.g. radxa_display_8hd_ad002_desc) only set
mode_4ln, leaving mode_2ln = NULL. So if such a panel attaches to a
2-lane DSI host, the NULL pointer dereference causes a kernel oops.
Thanks,
Jie
> + return drm_connector_helper_get_modes_fixed(connector, jadard->desc->mode_2ln);
> + else
> + return drm_connector_helper_get_modes_fixed(connector, jadard->desc->mode_4ln);
> }
>
> static enum drm_panel_orientation jadard_panel_get_orientation(struct drm_panel *panel)
> @@ -354,7 +362,7 @@ static int radxa_display_8hd_ad002_init_cmds(struct jadard *jadard)
> };
>
> static const struct jadard_panel_desc radxa_display_8hd_ad002_desc = {
> - .mode = {
> + .mode_4ln = &(const struct drm_display_mode) {
> .clock = 70000,
>
> .hdisplay = 800,
> @@ -586,7 +594,7 @@ static int cz101b4001_init_cmds(struct jadard *jadard)
> };
>
> static const struct jadard_panel_desc cz101b4001_desc = {
> - .mode = {
> + .mode_4ln = &(const struct drm_display_mode) {
> .clock = 70000,
>
> .hdisplay = 800,
> @@ -819,7 +827,7 @@ static int kingdisplay_kd101ne3_init_cmds(struct jadard *jadard)
> };
>
> static const struct jadard_panel_desc kingdisplay_kd101ne3_40ti_desc = {
> - .mode = {
> + .mode_4ln = &(const struct drm_display_mode) {
> .clock = (800 + 24 + 24 + 24) * (1280 + 30 + 4 + 8) * 60 / 1000,
>
> .hdisplay = 800,
> @@ -1070,7 +1078,7 @@ static int melfas_lmfbx101117480_init_cmds(struct jadard *jadard)
> };
>
> static const struct jadard_panel_desc melfas_lmfbx101117480_desc = {
> - .mode = {
> + .mode_4ln = &(const struct drm_display_mode) {
> .clock = (800 + 24 + 24 + 24) * (1280 + 30 + 4 + 8) * 60 / 1000,
>
> .hdisplay = 800,
> @@ -1326,7 +1334,7 @@ static int anbernic_rgds_init_cmds(struct jadard *jadard)
> };
>
> static const struct jadard_panel_desc anbernic_rgds_display_desc = {
> - .mode = {
> + .mode_4ln = &(const struct drm_display_mode) {
> .clock = (640 + 260 + 220 + 260) * (480 + 10 + 2 + 16) * 60 / 1000,
>
> .hdisplay = 640,
> @@ -1562,7 +1570,7 @@ static int taiguan_xti05101_01a_init_cmds(struct jadard *jadard)
> };
>
> static const struct jadard_panel_desc taiguan_xti05101_01a_desc = {
> - .mode = {
> + .mode_4ln = &(const struct drm_display_mode) {
> .clock = (800 + 24 + 24 + 24) * (1280 + 30 + 4 + 8) * 60 / 1000,
>
> .hdisplay = 800,
> @@ -1614,6 +1622,12 @@ static int jadard_dsi_probe(struct mipi_dsi_device *dsi)
>
> dsi->format = desc->format;
> dsi->lanes = desc->lanes;
> + if (!dsi->lanes) {
> + dsi->lanes = drm_of_get_data_lanes_count_remote(dsi->dev.of_node, 0, -1, 2, 4);
> + if (dsi->lanes < 0)
> + return dsi->lanes;
> + }
> + dev_dbg(&dsi->dev, "lanes: %d\n", dsi->lanes);
>
> jadard->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> if (IS_ERR(jadard->reset))
>
^ permalink raw reply
* Re: [PATCH v2 05/21] dt-bindings: dipslay/panel: describe panels using Focaltech OTA7290B
From: Jie Gan @ 2026-04-12 0:44 UTC (permalink / raw)
To: Dmitry Baryshkov, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cong Yang, Ondrej Jirman, Javier Martinez Canillas, Jagan Teki,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260411-waveshare-dsi-touch-v2-5-75cdbeac5156@oss.qualcomm.com>
On 4/11/2026 8:10 PM, Dmitry Baryshkov wrote:
> Add schema for the panels using Focaltech OTA7290B controller. For now
> there is only one such panel, from the Waveshare 8.8 DSI TOUCH-A kit.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../bindings/display/panel/focaltech,ota7290b.yaml | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml b/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml
> new file mode 100644
> index 000000000000..f2f6e254b7de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/focaltech,ota7290b.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Focaltech OTA7290B DSI panels
> +
> +maintainers:
> + - Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> +
> +allOf:
> + - $ref: panel-common.yaml#
> +
> +properties:
> + compatible:
> + const: waveshare,8.88-dsi-touch-a
mismatch with the compatible in the example.
> +
> + reg:
> + maxItems: 1
> +
> + vdd-supply:
> + description: supply regulator for VDD, usually 3.3V
> +
> + vdda-supply:
> + description: supply regulator for VDDA, 7-10V
> +
> + vcc-supply:
> + description: supply regulator for VCCIO, usually 1.5V
> +
> + reset-gpios: true
> + backlight: true
> + rotation: true
> + port: true
> +
> +required:
> + - compatible
> + - reg
> + - vdd-supply
> + - vccio-supply
defined as vcc-supply in property block.
Thanks,
Jie
> + - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + dsi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel@0 {
> + compatible = "waveshare,8.8-dsi-touch-a";
> + reg = <0>;
> + vdd-supply = <&vdd>;
> + vccio-supply = <&vccio>;
> + reset-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
> + backlight = <&backlight>;
> +
> + port {
> + endpoint {
> + remote-endpoint = <&mipi_out_panel>;
> + };
> + };
> + };
> + };
> +
> +...
> +
>
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset
From: Dmitry Baryshkov @ 2026-04-12 0:41 UTC (permalink / raw)
To: Konrad Dybcio
Cc: David Heidelberg, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Ulf Hansson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <5b45a40d-54a6-40b5-b4b6-eac344827dc9@oss.qualcomm.com>
On Fri, Apr 10, 2026 at 10:55:53AM +0200, Konrad Dybcio wrote:
> On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
> > On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
> >> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
> >>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
> >>>>
> >>>>
> >>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
> >>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
> >>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
> >>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
> >>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
> >>>>>>>>> From: David Heidelberg <david@ixit.cz>
> >>>>>>>>>
> >>>>>>>>> If the OS does not support recovering the state left by the
> >>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
> >>>>>>>>> start from a clean state. Add a reference to the relevant reset.
> >>>>>>>>
> >>>>>>>> This is not the relevant reset
> >>>>>>>>
> >>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
> >>>>>>>
> >>>>>>> Thanks, I prepared the fixes [1].
> >>>>>>>
> >>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
> >>>>>>>
> >>>>>>> David
> >>>>>>>
> >>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
> >>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@ixit.cz/
> >>>>>>
> >>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
> >>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
> >>>>>> place
> >>>>>
> >>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
> >>>>> change that to CORE behind the scene. I'd prefer David's approach.
> >>>>
> >>>> Back when I replied, David had a patch that removed the current RSCC
> >>>> reset definition in dt-bindings (at index 0) and re-used that index
> >>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
> >>>> specific commits when making comments, note to self :P
> >>>
> >>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
> >>> work.
> >>
> >> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
> >>
> >> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
> >> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
> >> arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0xc88
> >> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
> >
> > [...]
> >
> >>
> >> These (or very similar warnings) are around sdm845 definitely 6.19+ /
> >> linux-next kernels for some time, but pretty harmless.
> >>
> >> LLM suggested multiple fixes, but when presenting possibility of
> >> implementing mdss reset it found it as most preferable [1].
> >>
> >> Adding MDSS reset would most likely solve it. It's not critical, but not
> >> nice to see many red lines in the dmesg.
> >>
> >> Is there something I could experiment with to get closer to have proper MDSS reset?
> >
> > I don't have a sensible solution at this point. We tried using the MDSS
> > reset on several SDM845 devices, but they just reset. So... I don't have
> > any possible solution.
>
> The older context talks about altering the existing dt-bindings values
> and now we're at hardware (mis)behaving? What is the issue here?
The HDK and DB845c reset if I try touching MDSS core reset.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v6 6/6] clk: fsl-sai: Add MCLK generation support
From: Stephen Boyd @ 2026-04-12 0:37 UTC (permalink / raw)
To: Marek Vasut, linux-clk
Cc: Marek Vasut, Michael Walle, Brian Masney, Conor Dooley,
Krzysztof Kozlowski, Michael Turquette, Michael Walle,
Rob Herring, devicetree, linux-kernel
In-Reply-To: <20260409002952.319668-6-marex@nabladev.com>
Quoting Marek Vasut (2026-04-08 17:29:06)
> The driver currently supports generating BCLK. There are systems which
> require generation of MCLK instead. Register new MCLK clock and handle
> clock-cells = <1> to differentiate between BCLK and MCLK. In case of a
> legacy system with clock-cells = <0>, the driver behaves as before, i.e.
> always returns BCLK.
>
> Note that it is not possible re-use the current SAI audio driver to
> generate MCLK and correctly enable and disable the MCLK.
>
> If SAI (audio driver) is used to control the MCLK enablement, then MCLK
> clock is not always enabled, and it is not necessarily enabled when the
> codec may need the clock to be enabled. There is also no way for the
> codec node to specify phandle to clock provider in DT, because the SAI
> (audio driver) is not clock provider.
>
> If SAI (clock driver) is used to control the MCLK enablement, then MCLK
> clock is enabled when the codec needs the clock enabled, because the
> codec is the clock consumer and the SAI (clock driver) is the clock
> provider, and the codec driver can request the clock to be enabled when
> needed. There is also the usual phandle to clock provider in DT, because
> the SAI (clock driver) is clock provider.
>
> Acked-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
Applied to clk-next
^ permalink raw reply
* Re: [PATCH v6 5/6] clk: fsl-sai: Extract clock setup into fsl_sai_clk_register()
From: Stephen Boyd @ 2026-04-12 0:37 UTC (permalink / raw)
To: Marek Vasut, linux-clk
Cc: Marek Vasut, Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Michael Walle, Rob Herring, devicetree,
linux-kernel
In-Reply-To: <20260409002952.319668-5-marex@nabladev.com>
Quoting Marek Vasut (2026-04-08 17:29:05)
> Create helper function fsl_sai_clk_register() to set up and register
> SAI clock. Rename BCLK specific struct fsl_sai_clk members with bclk_
> prefix. Use of_node_full_name(dev->of_node) and clock name to register
> uniquely named clock. This is done in preparation for the follow up
> patch, which adds MCLK support.
>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
Applied to clk-next
^ 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