Use panel-dpi driver instead of the deprecated tilcdc-panel driver in
preparation for removing the tilcdc-panel driver and binding.
Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
---
This patch is not tested. It would be nice if someone with one of this
board could test and validate it.
---
arch/arm/boot/dts/ti/davinci/da850-evm.dts | 26 +++++++++++++-------------
arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 25 +++++++++----------------
arch/arm/boot/dts/ti/omap/am335x-pdu001.dts | 21 ++++++++++-----------
arch/arm/boot/dts/ti/omap/am335x-pepper.dts | 22 +++++++++++-----------
arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts | 25 +++++++++++++------------
arch/arm/boot/dts/ti/omap/am335x-sl50.dts | 25 ++++++++++++-------------
6 files changed, 68 insertions(+), 76 deletions(-)
diff --git a/arch/arm/boot/dts/ti/davinci/da850-evm.dts b/arch/arm/boot/dts/ti/davinci/da850-evm.dts
index 38a191fb04149..79cca1f6205ef 100644
--- a/arch/arm/boot/dts/ti/davinci/da850-evm.dts
+++ b/arch/arm/boot/dts/ti/davinci/da850-evm.dts
@@ -40,7 +40,7 @@ backlight: backlight-pwm {
};
panel {
- compatible = "ti,tilcdc,panel";
+ compatible = "panel-dpi";
pinctrl-names = "default";
pinctrl-0 = <&lcd_pins>;
/*
@@ -50,17 +50,10 @@ panel {
*/
status = "okay";
enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
-
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <16>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <1>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
};
display-timings {
@@ -222,6 +215,13 @@ &rtc0 {
};
&lcdc {
+ fifo-threshold = <16>;
+
+ port {
+ lcdc_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
status = "okay";
};
@@ -459,7 +459,7 @@ &vpif {
pinctrl-0 = <&vpif_capture_pins>, <&vpif_display_pins>;
/*
* The vpif and the LCD are mutually exclusive.
- * To enable VPIF, disable the ti,tilcdc,panel then
+ * To enable VPIF, disable the panel-dpi then
* change the status below to 'okay'
*/
status = "disabled";
diff --git a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
index 4b070e634b281..f38ce9be2c106 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
@@ -68,10 +68,15 @@ gpio-poweroff {
};
panel {
- compatible = "ti,tilcdc,panel";
+ compatible = "panel-dpi";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&lcd_pins_default &lcd_disen_pins>;
pinctrl-1 = <&lcd_pins_sleep>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
+ };
display-timings {
timing-320x240 {
@@ -86,21 +91,9 @@ timing-320x240 {
clock-frequency = <9000000>;
hsync-active = <0>;
vsync-active = <0>;
+ pixelclk-active = <1>;
};
};
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <24>;
- bus-width = <16>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
- };
-
};
guardian_beeper: pwm-7 {
@@ -265,8 +258,8 @@ &lcdc {
blue-and-red-wiring = "crossed";
status = "okay";
port {
- lcdc_0: endpoint@0 {
- remote-endpoint = <0>;
+ lcdc_out: endpoint@0 {
+ remote-endpoint = <&panel_in>;
};
};
};
diff --git a/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts b/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts
index c9ccb9de21ad7..2c5229d05ade7 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts
@@ -50,20 +50,14 @@ lis3_reg: fixedregulator@1 {
};
panel {
- compatible = "ti,tilcdc,panel";
+ compatible = "panel-dpi";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&lcd_pins_s0>;
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <16>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
};
display-timings {
@@ -395,6 +389,11 @@ &rtc {
&lcdc {
status = "okay";
+ port {
+ lcdc_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
};
&elm {
diff --git a/arch/arm/boot/dts/ti/omap/am335x-pepper.dts b/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
index e7d561a527fdd..2760c0eab50c2 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
@@ -31,7 +31,7 @@ leds: user-leds-pins {
};
panel: lcd_panel {
- compatible = "ti,tilcdc,panel";
+ compatible = "panel-dpi";
};
sound: sound_iface {
@@ -189,16 +189,10 @@ &panel {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&lcd_pins>;
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <32>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
};
display-timings {
native-mode = <&timing0>;
@@ -214,12 +208,18 @@ timing0: timing-480x272 {
vsync-len = <10>;
hsync-active = <1>;
vsync-active = <1>;
+ pixelclk-active = <1>;
};
};
};
&lcdc {
status = "okay";
+ port {
+ lcdc_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
};
&am33xx_pinmux {
diff --git a/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts b/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts
index 2841e95d9a094..25ee855dd21a7 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts
@@ -13,23 +13,17 @@ / {
/* DRM display driver */
panel {
- compatible = "ti,tilcdc,panel";
+ compatible = "panel-dpi";
status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&lcd_pins_default>;
pinctrl-1 = <&lcd_pins_sleep>;
-
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <32>;
- fdd = <0x80>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
};
+
display-timings {
/* Timing selection performed by U-Boot */
timing0: lcd {/* 800x480p62 */
@@ -44,6 +38,7 @@ timing0: lcd {/* 800x480p62 */
vsync-len = <2>;
hsync-active = <1>;
vsync-active = <1>;
+ pixelclk-active = <1>;
};
timing1: dvi { /* 1024x768p60 */
clock-frequency = <65000000>;
@@ -57,6 +52,7 @@ timing1: dvi { /* 1024x768p60 */
vsync-len = <6>;
hsync-active = <0>;
vsync-active = <0>;
+ pixelclk-active = <1>;
};
};
};
@@ -173,4 +169,9 @@ lcd-ena-hog {
/* Display */
&lcdc {
status = "okay";
+ port {
+ lcdc_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/ti/omap/am335x-sl50.dts b/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
index f3524e5ee43e2..b4b2b6d18d646 100644
--- a/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
+++ b/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
@@ -123,22 +123,14 @@ audio_mclk: audio_mclk_gate@0 {
};
panel: lcd_panel {
- compatible = "ti,tilcdc,panel";
+ compatible = "panel-dpi";
pinctrl-names = "default";
pinctrl-0 = <&lcd_pins>;
- panel-info {
- ac-bias = <255>;
- ac-bias-intrpt = <0>;
- dma-burst-sz = <16>;
- bpp = <16>;
- fdd = <0x80>;
- tft-alt-mode = <0>;
- mono-8bit-mode = <0>;
- sync-edge = <0>;
- sync-ctrl = <1>;
- raster-order = <0>;
- fifo-th = <0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lcdc_out>;
+ };
};
display-timings {
@@ -157,6 +149,8 @@ timing0: 960x128 {
vfront-porch = <8>;
vsync-len = <4>;
vsync-active = <0>;
+
+ pixelclk-active = <1>;
};
};
};
@@ -711,6 +705,11 @@ &ehrpwm1 {
&lcdc {
status = "okay";
+ port {
+ lcdc_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
};
&tscadc {
--
2.43.0Hi Kory,
On 26/11/2025 19:35, Kory Maincent (TI.com) wrote:
> Use panel-dpi driver instead of the deprecated tilcdc-panel driver in
> preparation for removing the tilcdc-panel driver and binding.
>
> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com>
> ---
>
> This patch is not tested. It would be nice if someone with one of this
> board could test and validate it.
> ---
> arch/arm/boot/dts/ti/davinci/da850-evm.dts | 26 +++++++++++++-------------
> arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 25 +++++++++----------------
> arch/arm/boot/dts/ti/omap/am335x-pdu001.dts | 21 ++++++++++-----------
> arch/arm/boot/dts/ti/omap/am335x-pepper.dts | 22 +++++++++++-----------
> arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts | 25 +++++++++++++------------
> arch/arm/boot/dts/ti/omap/am335x-sl50.dts | 25 ++++++++++++-------------
> 6 files changed, 68 insertions(+), 76 deletions(-)
>
Doesn't this, or rather the following patches, break DTB compatibility
with all the above boards?
Tomi
> diff --git a/arch/arm/boot/dts/ti/davinci/da850-evm.dts b/arch/arm/boot/dts/ti/davinci/da850-evm.dts
> index 38a191fb04149..79cca1f6205ef 100644
> --- a/arch/arm/boot/dts/ti/davinci/da850-evm.dts
> +++ b/arch/arm/boot/dts/ti/davinci/da850-evm.dts
> @@ -40,7 +40,7 @@ backlight: backlight-pwm {
> };
>
> panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "panel-dpi";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins>;
> /*
> @@ -50,17 +50,10 @@ panel {
> */
> status = "okay";
> enable-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>; /* lcd_panel_pwr */
> -
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt = <0>;
> - dma-burst-sz = <16>;
> - bpp = <16>;
> - fdd = <0x80>;
> - sync-edge = <0>;
> - sync-ctrl = <1>;
> - raster-order = <0>;
> - fifo-th = <1>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdc_out>;
> + };
> };
>
> display-timings {
> @@ -222,6 +215,13 @@ &rtc0 {
> };
>
> &lcdc {
> + fifo-threshold = <16>;
> +
> + port {
> + lcdc_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> status = "okay";
> };
>
> @@ -459,7 +459,7 @@ &vpif {
> pinctrl-0 = <&vpif_capture_pins>, <&vpif_display_pins>;
> /*
> * The vpif and the LCD are mutually exclusive.
> - * To enable VPIF, disable the ti,tilcdc,panel then
> + * To enable VPIF, disable the panel-dpi then
> * change the status below to 'okay'
> */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
> index 4b070e634b281..f38ce9be2c106 100644
> --- a/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
> +++ b/arch/arm/boot/dts/ti/omap/am335x-guardian.dts
> @@ -68,10 +68,15 @@ gpio-poweroff {
> };
>
> panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "panel-dpi";
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&lcd_pins_default &lcd_disen_pins>;
> pinctrl-1 = <&lcd_pins_sleep>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdc_out>;
> + };
> + };
>
> display-timings {
> timing-320x240 {
> @@ -86,21 +91,9 @@ timing-320x240 {
> clock-frequency = <9000000>;
> hsync-active = <0>;
> vsync-active = <0>;
> + pixelclk-active = <1>;
> };
> };
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt = <0>;
> - dma-burst-sz = <16>;
> - bpp = <24>;
> - bus-width = <16>;
> - fdd = <0x80>;
> - sync-edge = <0>;
> - sync-ctrl = <1>;
> - raster-order = <0>;
> - fifo-th = <0>;
> - };
> -
> };
>
> guardian_beeper: pwm-7 {
> @@ -265,8 +258,8 @@ &lcdc {
> blue-and-red-wiring = "crossed";
> status = "okay";
> port {
> - lcdc_0: endpoint@0 {
> - remote-endpoint = <0>;
> + lcdc_out: endpoint@0 {
> + remote-endpoint = <&panel_in>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts b/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts
> index c9ccb9de21ad7..2c5229d05ade7 100644
> --- a/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts
> +++ b/arch/arm/boot/dts/ti/omap/am335x-pdu001.dts
> @@ -50,20 +50,14 @@ lis3_reg: fixedregulator@1 {
> };
>
> panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "panel-dpi";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins_s0>;
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt = <0>;
> - dma-burst-sz = <16>;
> - bpp = <16>;
> - fdd = <0x80>;
> - sync-edge = <0>;
> - sync-ctrl = <1>;
> - raster-order = <0>;
> - fifo-th = <0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdc_out>;
> + };
> };
>
> display-timings {
> @@ -395,6 +389,11 @@ &rtc {
>
> &lcdc {
> status = "okay";
> + port {
> + lcdc_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> };
>
> &elm {
> diff --git a/arch/arm/boot/dts/ti/omap/am335x-pepper.dts b/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
> index e7d561a527fdd..2760c0eab50c2 100644
> --- a/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
> +++ b/arch/arm/boot/dts/ti/omap/am335x-pepper.dts
> @@ -31,7 +31,7 @@ leds: user-leds-pins {
> };
>
> panel: lcd_panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "panel-dpi";
> };
>
> sound: sound_iface {
> @@ -189,16 +189,10 @@ &panel {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins>;
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt = <0>;
> - dma-burst-sz = <16>;
> - bpp = <32>;
> - fdd = <0x80>;
> - sync-edge = <0>;
> - sync-ctrl = <1>;
> - raster-order = <0>;
> - fifo-th = <0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdc_out>;
> + };
> };
> display-timings {
> native-mode = <&timing0>;
> @@ -214,12 +208,18 @@ timing0: timing-480x272 {
> vsync-len = <10>;
> hsync-active = <1>;
> vsync-active = <1>;
> + pixelclk-active = <1>;
> };
> };
> };
>
> &lcdc {
> status = "okay";
> + port {
> + lcdc_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> };
>
> &am33xx_pinmux {
> diff --git a/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts b/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts
> index 2841e95d9a094..25ee855dd21a7 100644
> --- a/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts
> +++ b/arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts
> @@ -13,23 +13,17 @@ / {
>
> /* DRM display driver */
> panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "panel-dpi";
> status = "okay";
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&lcd_pins_default>;
> pinctrl-1 = <&lcd_pins_sleep>;
> -
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt = <0>;
> - dma-burst-sz = <16>;
> - bpp = <32>;
> - fdd = <0x80>;
> - sync-edge = <0>;
> - sync-ctrl = <1>;
> - raster-order = <0>;
> - fifo-th = <0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdc_out>;
> + };
> };
> +
> display-timings {
> /* Timing selection performed by U-Boot */
> timing0: lcd {/* 800x480p62 */
> @@ -44,6 +38,7 @@ timing0: lcd {/* 800x480p62 */
> vsync-len = <2>;
> hsync-active = <1>;
> vsync-active = <1>;
> + pixelclk-active = <1>;
> };
> timing1: dvi { /* 1024x768p60 */
> clock-frequency = <65000000>;
> @@ -57,6 +52,7 @@ timing1: dvi { /* 1024x768p60 */
> vsync-len = <6>;
> hsync-active = <0>;
> vsync-active = <0>;
> + pixelclk-active = <1>;
> };
> };
> };
> @@ -173,4 +169,9 @@ lcd-ena-hog {
> /* Display */
> &lcdc {
> status = "okay";
> + port {
> + lcdc_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> };
> diff --git a/arch/arm/boot/dts/ti/omap/am335x-sl50.dts b/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
> index f3524e5ee43e2..b4b2b6d18d646 100644
> --- a/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
> +++ b/arch/arm/boot/dts/ti/omap/am335x-sl50.dts
> @@ -123,22 +123,14 @@ audio_mclk: audio_mclk_gate@0 {
> };
>
> panel: lcd_panel {
> - compatible = "ti,tilcdc,panel";
> + compatible = "panel-dpi";
> pinctrl-names = "default";
> pinctrl-0 = <&lcd_pins>;
>
> - panel-info {
> - ac-bias = <255>;
> - ac-bias-intrpt = <0>;
> - dma-burst-sz = <16>;
> - bpp = <16>;
> - fdd = <0x80>;
> - tft-alt-mode = <0>;
> - mono-8bit-mode = <0>;
> - sync-edge = <0>;
> - sync-ctrl = <1>;
> - raster-order = <0>;
> - fifo-th = <0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&lcdc_out>;
> + };
> };
>
> display-timings {
> @@ -157,6 +149,8 @@ timing0: 960x128 {
> vfront-porch = <8>;
> vsync-len = <4>;
> vsync-active = <0>;
> +
> + pixelclk-active = <1>;
> };
> };
> };
> @@ -711,6 +705,11 @@ &ehrpwm1 {
>
> &lcdc {
> status = "okay";
> + port {
> + lcdc_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> };
>
> &tscadc {
>
On 01/12/2025 15:13, Tomi Valkeinen wrote: > Hi Kory, > > On 26/11/2025 19:35, Kory Maincent (TI.com) wrote: >> Use panel-dpi driver instead of the deprecated tilcdc-panel driver in >> preparation for removing the tilcdc-panel driver and binding. >> >> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> >> --- >> >> This patch is not tested. It would be nice if someone with one of this >> board could test and validate it. >> --- >> arch/arm/boot/dts/ti/davinci/da850-evm.dts | 26 +++++++++++++------------- >> arch/arm/boot/dts/ti/omap/am335x-guardian.dts | 25 +++++++++---------------- >> arch/arm/boot/dts/ti/omap/am335x-pdu001.dts | 21 ++++++++++----------- >> arch/arm/boot/dts/ti/omap/am335x-pepper.dts | 22 +++++++++++----------- >> arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts | 25 +++++++++++++------------ >> arch/arm/boot/dts/ti/omap/am335x-sl50.dts | 25 ++++++++++++------------- >> 6 files changed, 68 insertions(+), 76 deletions(-) >> > > Doesn't this, or rather the following patches, break DTB compatibility > with all the above boards? Stuffing DTS change in the middle of the driver change tries to hide impact, which is not nice on its own. Please follow soc maintainer profile and submitting patches in DT regarding DTS patches. Best regards, Krzysztof
On Mon, 1 Dec 2025 22:46:01 +0100 Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 01/12/2025 15:13, Tomi Valkeinen wrote: > > Hi Kory, > > > > On 26/11/2025 19:35, Kory Maincent (TI.com) wrote: > >> Use panel-dpi driver instead of the deprecated tilcdc-panel driver in > >> preparation for removing the tilcdc-panel driver and binding. > >> > >> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> > >> --- > >> > >> This patch is not tested. It would be nice if someone with one of this > >> board could test and validate it. > >> --- > >> arch/arm/boot/dts/ti/davinci/da850-evm.dts | 26 > >> +++++++++++++------------- arch/arm/boot/dts/ti/omap/am335x-guardian.dts | > >> 25 +++++++++---------------- arch/arm/boot/dts/ti/omap/am335x-pdu001.dts > >> | 21 ++++++++++----------- arch/arm/boot/dts/ti/omap/am335x-pepper.dts | > >> 22 +++++++++++----------- arch/arm/boot/dts/ti/omap/am335x-sbc-t335.dts | > >> 25 +++++++++++++------------ arch/arm/boot/dts/ti/omap/am335x-sl50.dts > >> | 25 ++++++++++++------------- 6 files changed, 68 insertions(+), 76 > >> deletions(-) > > > > Doesn't this, or rather the following patches, break DTB compatibility > > with all the above boards? Yes, I know this but I still wanted to try and begin a discussion on this, as I really thought it is not a good idea to add and maintain an new non-standard panel driver solely for this tilcdc panel binding. I have gathered more arguments on this topic on next patch. > Stuffing DTS change in the middle of the driver change tries to hide > impact, which is not nice on its own. As it needs driver change before the removal for not breaking things it can't be done at the beginning of the series. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On 02/12/2025 10:42, Kory Maincent wrote: > >> Stuffing DTS change in the middle of the driver change tries to hide >> impact, which is not nice on its own. > > As it needs driver change before the removal for not breaking things it can't > be done at the beginning of the series. And that is the problem which should stop you there and rethink how to organize it without impacting users. DTS cannot go via DRM. If that was your intention, that's my: NAK Best regards, Krzysztof
On Tue, 2 Dec 2025 11:28:55 +0100 Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 02/12/2025 10:42, Kory Maincent wrote: > > > >> Stuffing DTS change in the middle of the driver change tries to hide > >> impact, which is not nice on its own. > > > > As it needs driver change before the removal for not breaking things it > > can't be done at the beginning of the series. > > And that is the problem which should stop you there and rethink how to > organize it without impacting users. DTS cannot go via DRM. If that was > your intention, that's my: > > NAK My intention was to raise discussion over the ugly and legacy tilcdc-panel binding and what to do with it. But it seems you don't want to, that's a shame. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On 02/12/2025 11:44, Kory Maincent wrote: > On Tue, 2 Dec 2025 11:28:55 +0100 > Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> On 02/12/2025 10:42, Kory Maincent wrote: >>> >>>> Stuffing DTS change in the middle of the driver change tries to hide >>>> impact, which is not nice on its own. >>> >>> As it needs driver change before the removal for not breaking things it >>> can't be done at the beginning of the series. >> >> And that is the problem which should stop you there and rethink how to >> organize it without impacting users. DTS cannot go via DRM. If that was >> your intention, that's my: >> >> NAK > > My intention was to raise discussion over the ugly and legacy tilcdc-panel > binding and what to do with it. But it seems you don't want to, that's a shame. I don't see how you get to these conclusions. I comment that putting here DTS in the middle without any explanation of the impact is not correct and this one alone I disagree with. From that you claim I don't want to fix things... DTS cannot go to drm, which means you either need to separate the change and make entire work bisectable and backwards compatible for some time OR at least document clearly the impact as we always ask. Best regards, Krzysztof
On Tue, 2 Dec 2025 11:47:40 +0100 Krzysztof Kozlowski <krzk@kernel.org> wrote: > On 02/12/2025 11:44, Kory Maincent wrote: > > On Tue, 2 Dec 2025 11:28:55 +0100 > > Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > >> On 02/12/2025 10:42, Kory Maincent wrote: > >>> > >>>> Stuffing DTS change in the middle of the driver change tries to hide > >>>> impact, which is not nice on its own. > >>> > >>> As it needs driver change before the removal for not breaking things it > >>> can't be done at the beginning of the series. > >> > >> And that is the problem which should stop you there and rethink how to > >> organize it without impacting users. DTS cannot go via DRM. If that was > >> your intention, that's my: > >> > >> NAK > > > > My intention was to raise discussion over the ugly and legacy tilcdc-panel > > binding and what to do with it. But it seems you don't want to, that's a > > shame. > > I don't see how you get to these conclusions. I comment that putting > here DTS in the middle without any explanation of the impact is not > correct and this one alone I disagree with. Because you didn't replied to the first line of my answer: "Yes, I know this but I still wanted to try and begin a discussion on this, as I really thought it is not a good idea to add and maintain an new non-standard panel driver solely for this tilcdc panel binding." But indeed you are right, I should have put more explanation on why there is DTS and binding change in the middle of the series. Sorry for that. > From that you claim I don't want to fix things... > > DTS cannot go to drm, which means you either need to separate the change > and make entire work bisectable and backwards compatible for some time > OR at least document clearly the impact as we always ask. The thing is, if I split it, it has to be in 3. One for the of DRM bus flags support, a second for the the devicetree and binding change and a third for the whole tilcdc and tda998x cleaning stuff. I think I will go for one series, with better documentation. Now, what is your point of view on my question. Will you nak any binding removal even if the binding is ugly and legacy and imply maintaining an non-standard tilcdc panel driver? I know it breaks DTB compatibility but there is several argument to not keep it. See patch 6. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
On 02/12/2025 12:18, Kory Maincent wrote: > On Tue, 2 Dec 2025 11:47:40 +0100 > Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> On 02/12/2025 11:44, Kory Maincent wrote: >>> On Tue, 2 Dec 2025 11:28:55 +0100 >>> Krzysztof Kozlowski <krzk@kernel.org> wrote: >>> >>>> On 02/12/2025 10:42, Kory Maincent wrote: >>>>> >>>>>> Stuffing DTS change in the middle of the driver change tries to hide >>>>>> impact, which is not nice on its own. >>>>> >>>>> As it needs driver change before the removal for not breaking things it >>>>> can't be done at the beginning of the series. >>>> >>>> And that is the problem which should stop you there and rethink how to >>>> organize it without impacting users. DTS cannot go via DRM. If that was >>>> your intention, that's my: >>>> >>>> NAK >>> >>> My intention was to raise discussion over the ugly and legacy tilcdc-panel >>> binding and what to do with it. But it seems you don't want to, that's a >>> shame. >> >> I don't see how you get to these conclusions. I comment that putting >> here DTS in the middle without any explanation of the impact is not >> correct and this one alone I disagree with. > > Because you didn't replied to the first line of my answer: > "Yes, I know this but I still wanted to try and begin a discussion on this, as I > really thought it is not a good idea to add and maintain an new non-standard > panel driver solely for this tilcdc panel binding." > > But indeed you are right, I should have put more explanation on why there is DTS > and binding change in the middle of the series. Sorry for that. > >> From that you claim I don't want to fix things... >> >> DTS cannot go to drm, which means you either need to separate the change >> and make entire work bisectable and backwards compatible for some time >> OR at least document clearly the impact as we always ask. > > The thing is, if I split it, it has to be in 3. One for the of DRM bus flags > support, a second for the the devicetree and binding change and a third for the > whole tilcdc and tda998x cleaning stuff. I think I will go for one series, with > better documentation. > > Now, what is your point of view on my question. Will you nak any binding > removal even if the binding is ugly and legacy and imply maintaining an > non-standard tilcdc panel driver? I know it breaks DTB compatibility but there > is several argument to not keep it. See patch 6. I will not NAK, removing bindings and breaking users is under some conditions acceptable. You just need to come with the reasons and impact. Reason "is ugly" is usually not good enough. Especially if things were working. Best regards, Krzysztof
Hi Kory, On 02/12/2025 13:18, Kory Maincent wrote: > On Tue, 2 Dec 2025 11:47:40 +0100 > Krzysztof Kozlowski <krzk@kernel.org> wrote: > >> On 02/12/2025 11:44, Kory Maincent wrote: >>> On Tue, 2 Dec 2025 11:28:55 +0100 >>> Krzysztof Kozlowski <krzk@kernel.org> wrote: >>> >>>> On 02/12/2025 10:42, Kory Maincent wrote: >>>>> >>>>>> Stuffing DTS change in the middle of the driver change tries to hide >>>>>> impact, which is not nice on its own. >>>>> >>>>> As it needs driver change before the removal for not breaking things it >>>>> can't be done at the beginning of the series. >>>> >>>> And that is the problem which should stop you there and rethink how to >>>> organize it without impacting users. DTS cannot go via DRM. If that was >>>> your intention, that's my: >>>> >>>> NAK >>> >>> My intention was to raise discussion over the ugly and legacy tilcdc-panel >>> binding and what to do with it. But it seems you don't want to, that's a >>> shame. >> >> I don't see how you get to these conclusions. I comment that putting >> here DTS in the middle without any explanation of the impact is not >> correct and this one alone I disagree with. > > Because you didn't replied to the first line of my answer: > "Yes, I know this but I still wanted to try and begin a discussion on this, as I > really thought it is not a good idea to add and maintain an new non-standard > panel driver solely for this tilcdc panel binding." > > But indeed you are right, I should have put more explanation on why there is DTS > and binding change in the middle of the series. Sorry for that. > >> From that you claim I don't want to fix things... >> >> DTS cannot go to drm, which means you either need to separate the change >> and make entire work bisectable and backwards compatible for some time >> OR at least document clearly the impact as we always ask. > > The thing is, if I split it, it has to be in 3. One for the of DRM bus flags > support, a second for the the devicetree and binding change and a third for the > whole tilcdc and tda998x cleaning stuff. I think I will go for one series, with > better documentation. > > Now, what is your point of view on my question. Will you nak any binding > removal even if the binding is ugly and legacy and imply maintaining an > non-standard tilcdc panel driver? I know it breaks DTB compatibility but there > is several argument to not keep it. See patch 6. The binding being ugly and having to maintain non-standard tilcdc panel driver may be nice things for us, the users don't care. The users care if their board no longer works. And how does this sync with u-boot? It also has code for at least for a few of these boards. Are there even users for these boards? If not, maybe they can be just removed? I'm personally not familiar with these boards, so I have no idea of their age or distribution. One trick that can be done is to modify the loaded DTB at boot time, detecting the old format, converting it to the new one, so that when the drivers are probed they only see the new DTB. Tomi
On Tue, 2 Dec 2025 13:51:59 +0200
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
> Hi Kory,
>
> On 02/12/2025 13:18, Kory Maincent wrote:
> > On Tue, 2 Dec 2025 11:47:40 +0100
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> I will not NAK, removing bindings and breaking users is under some
> conditions acceptable. You just need to come with the reasons and impact.
>
> Reason "is ugly" is usually not good enough. Especially if things were
> working.
Thanks for you reply.
> >>
> >> DTS cannot go to drm, which means you either need to separate the change
> >> and make entire work bisectable and backwards compatible for some time
> >> OR at least document clearly the impact as we always ask.
> >
> > The thing is, if I split it, it has to be in 3. One for the of DRM bus flags
> > support, a second for the the devicetree and binding change and a third for
> > the whole tilcdc and tda998x cleaning stuff. I think I will go for one
> > series, with better documentation.
> >
> > Now, what is your point of view on my question. Will you nak any binding
> > removal even if the binding is ugly and legacy and imply maintaining an
> > non-standard tilcdc panel driver? I know it breaks DTB compatibility but
> > there is several argument to not keep it. See patch 6.
> The binding being ugly and having to maintain non-standard tilcdc panel
> driver may be nice things for us, the users don't care. The users care
> if their board no longer works.
Yes I understand but then I have another question. At what cost should we
continue to support legacy binding?
Just figured out this case already happened, ti,tilcdc,slave binding was
removed from the tilcdc driver:
739acd85ffdb7 ("drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding
support")
Even if there is still one mainline device tree that uses it:
am335x-base0033.dts. :/
> And how does this sync with u-boot? It also has code for at least for a
> few of these boards.
U-boot has indeed a driver for the ti,tilcdc,panel binding.
Changing this devicetree would beak display for these board in U-boot as it
currently does not support the "panel-dpi" binding.
> Are there even users for these boards? If not, maybe they can be just
> removed? I'm personally not familiar with these boards, so I have no
> idea of their age or distribution.
These boards are quite old (>10 years) but I don't know if they are still used
by people. After a quick look they seem not available on the market.
> One trick that can be done is to modify the loaded DTB at boot time,
> detecting the old format, converting it to the new one, so that when the
> drivers are probed they only see the new DTB.
Yes, indeed that could do the trick. The things is, I don't have one of
theses board to test it. I will try to look for an other way to test it.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
On Tue, Dec 02, 2025 at 01:56:05PM +0100, Kory Maincent wrote:
> On Tue, 2 Dec 2025 13:51:59 +0200
> Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
>
> > Hi Kory,
> >
> > On 02/12/2025 13:18, Kory Maincent wrote:
> > > On Tue, 2 Dec 2025 11:47:40 +0100
> > > Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> > I will not NAK, removing bindings and breaking users is under some
> > conditions acceptable. You just need to come with the reasons and impact.
> >
> > Reason "is ugly" is usually not good enough. Especially if things were
> > working.
>
> Thanks for you reply.
>
> > >>
> > >> DTS cannot go to drm, which means you either need to separate the change
> > >> and make entire work bisectable and backwards compatible for some time
> > >> OR at least document clearly the impact as we always ask.
> > >
> > > The thing is, if I split it, it has to be in 3. One for the of DRM bus flags
> > > support, a second for the the devicetree and binding change and a third for
> > > the whole tilcdc and tda998x cleaning stuff. I think I will go for one
> > > series, with better documentation.
> > >
> > > Now, what is your point of view on my question. Will you nak any binding
> > > removal even if the binding is ugly and legacy and imply maintaining an
> > > non-standard tilcdc panel driver? I know it breaks DTB compatibility but
> > > there is several argument to not keep it. See patch 6.
> > The binding being ugly and having to maintain non-standard tilcdc panel
> > driver may be nice things for us, the users don't care. The users care
> > if their board no longer works.
>
> Yes I understand but then I have another question. At what cost should we
> continue to support legacy binding?
That's mostly question to platform maintainers and users. Extrapolating
kernel rule - we never break the user-space - we never break the users,
thus we take significant cost.
And that significant cost can be the cost of making the transition
smooth or smoother.
>
> Just figured out this case already happened, ti,tilcdc,slave binding was
> removed from the tilcdc driver:
> 739acd85ffdb7 ("drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding
> support")
>
> Even if there is still one mainline device tree that uses it:
> am335x-base0033.dts. :/
If that commit broke existing users, it is a good argument for your
changes, but you need to explicitly use that argument in commit msg.
>
> > And how does this sync with u-boot? It also has code for at least for a
> > few of these boards.
>
> U-boot has indeed a driver for the ti,tilcdc,panel binding.
> Changing this devicetree would beak display for these board in U-boot as it
> currently does not support the "panel-dpi" binding.
Thanks for checking, regardless of decision this also should be in
commit msg.
Maybe things were not working correctly for long time, so there is a
choice of fixing Linux side while breaking U-boot and not fixing, but
keeping bootloader working.
Best regards,
Krzysztof
On 02/12/2025 12:51, Tomi Valkeinen wrote: > Hi Kory, > > On 02/12/2025 13:18, Kory Maincent wrote: >> On Tue, 2 Dec 2025 11:47:40 +0100 >> Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >>> On 02/12/2025 11:44, Kory Maincent wrote: >>>> On Tue, 2 Dec 2025 11:28:55 +0100 >>>> Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> >>>>> On 02/12/2025 10:42, Kory Maincent wrote: >>>>>> >>>>>>> Stuffing DTS change in the middle of the driver change tries to hide >>>>>>> impact, which is not nice on its own. >>>>>> >>>>>> As it needs driver change before the removal for not breaking things it >>>>>> can't be done at the beginning of the series. >>>>> >>>>> And that is the problem which should stop you there and rethink how to >>>>> organize it without impacting users. DTS cannot go via DRM. If that was >>>>> your intention, that's my: >>>>> >>>>> NAK >>>> >>>> My intention was to raise discussion over the ugly and legacy tilcdc-panel >>>> binding and what to do with it. But it seems you don't want to, that's a >>>> shame. >>> >>> I don't see how you get to these conclusions. I comment that putting >>> here DTS in the middle without any explanation of the impact is not >>> correct and this one alone I disagree with. >> >> Because you didn't replied to the first line of my answer: >> "Yes, I know this but I still wanted to try and begin a discussion on this, as I >> really thought it is not a good idea to add and maintain an new non-standard >> panel driver solely for this tilcdc panel binding." >> >> But indeed you are right, I should have put more explanation on why there is DTS >> and binding change in the middle of the series. Sorry for that. >> >>> From that you claim I don't want to fix things... >>> >>> DTS cannot go to drm, which means you either need to separate the change >>> and make entire work bisectable and backwards compatible for some time >>> OR at least document clearly the impact as we always ask. >> >> The thing is, if I split it, it has to be in 3. One for the of DRM bus flags >> support, a second for the the devicetree and binding change and a third for the >> whole tilcdc and tda998x cleaning stuff. I think I will go for one series, with >> better documentation. >> >> Now, what is your point of view on my question. Will you nak any binding >> removal even if the binding is ugly and legacy and imply maintaining an >> non-standard tilcdc panel driver? I know it breaks DTB compatibility but there >> is several argument to not keep it. See patch 6. > The binding being ugly and having to maintain non-standard tilcdc panel > driver may be nice things for us, the users don't care. The users care > if their board no longer works. Exactly. > > And how does this sync with u-boot? It also has code for at least for a > few of these boards. +1 > > Are there even users for these boards? If not, maybe they can be just > removed? I'm personally not familiar with these boards, so I have no > idea of their age or distribution. > > One trick that can be done is to modify the loaded DTB at boot time, > detecting the old format, converting it to the new one, so that when the > drivers are probed they only see the new DTB. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.