[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdVFrPanoO4CcRKVWhDsXCUm6ty3oayZ6yLs6AksZZJaBg@mail.gmail.com>
Date: Fri, 30 May 2025 09:51:05 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Jayesh Choudhary <j-choudhary@...com>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
neil.armstrong@...aro.org, khilman@...libre.com, devicetree@...r.kernel.org,
jbrunet@...libre.com, martin.blumenstingl@...glemail.com, shawnguo@...nel.org,
s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
cros-qcom-dts-watchers@...omium.org, andersson@...nel.org,
konradybcio@...nel.org, geert+renesas@...der.be, magnus.damm@...il.com,
linux-arm-kernel@...ts.infradead.org, linux-amlogic@...ts.infradead.org,
imx@...ts.linux.dev, linux-arm-msm@...r.kernel.org,
linux-renesas-soc@...r.kernel.org, dianders@...omium.org,
linux-kernel@...r.kernel.org, max.krummenacher@...adex.com,
ernestvanhoecke@...il.com
Subject: Re: [PATCH] arm64: dts: Add no-hpd property for all ti-sn65dsi86
bridge consumers
Hi Jayesh,
Thanks for your patch!
On Thu, 29 May 2025 at 13:24, Jayesh Choudhary <j-choudhary@...com> wrote:
> In the SN65DSI86 DSI-2-eDP bridge, HPD is not supported as of now.
> But DisplayPort connector_type usecases does need hpd to be enabled.
> In order not to break any platform from those driver changes, add
> "no-hpd" property to all the existing sn65dsi86 nodes (that don't
> have it already) as hpd is not being used there anyways.
>
> Signed-off-by: Jayesh Choudhary <j-choudhary@...com>
DT bindings day:
no-hpd:
type: boolean
description:
Set if the HPD line on the bridge isn't hooked up to anything or is
otherwise unusable.
On all Renesas platforms listed below, the DP bridge's HPD pin is wired
to the HPD pin on the mini-DP connector. What am I missing?
> Upcoming driver changes that will break platforms if we do not have this
> property in all the existing sn65dsi86 nodes that assumes hpd is disabled:
> <https://lore.kernel.org/all/20250529110418.481756-1-j-choudhary@ti.com/>
Breaking backwards-compatibility with existing DTBs is definitely a no-go.
I'll reply there, too...
> .../boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts | 1 +
> arch/arm64/boot/dts/freescale/imx8mq-mnt-reform2.dts | 1 +
> arch/arm64/boot/dts/qcom/sc7180-acer-aspire1.dts | 1 +
> arch/arm64/boot/dts/renesas/r8a779a0-falcon-cpu.dtsi | 1 +
> arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 1 +
> arch/arm64/boot/dts/renesas/r8a779h0-gray-hawk-single.dts | 1 +
> arch/arm64/boot/dts/renesas/white-hawk-cpu-common.dtsi | 1 +
> 7 files changed, 7 insertions(+)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists