* [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
@ 2026-02-06 12:37 Franz Schnyder
2026-02-06 15:46 ` Doug Anderson
0 siblings, 1 reply; 5+ messages in thread
From: Franz Schnyder @ 2026-02-06 12:37 UTC (permalink / raw)
To: Douglas Anderson, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter
Cc: Franz Schnyder, dri-devel, linux-kernel, Francesco Dolcini,
stable
From: Franz Schnyder <franz.schnyder@toradex.com>
Fallback to polling to detect hotplug events on systems without
interrupts.
On systems where the interrupt line of the bridge is not connected,
the bridge cannot notify hotplug events. Only add the
DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
otherwise remain in polling mode.
Fixes: 9133bc3f0564 ("drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD")
Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
Cc: stable@vger.kernel.org
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 276d05d25ad8..98d64ad791d0 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1415,6 +1415,7 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev,
{
struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
struct device_node *np = pdata->dev->of_node;
+ const struct i2c_client *client = to_i2c_client(pdata->dev);
int ret;
pdata->next_bridge = devm_drm_of_get_bridge(&adev->dev, np, 1, 0);
@@ -1433,8 +1434,9 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev,
? DRM_MODE_CONNECTOR_DisplayPort : DRM_MODE_CONNECTOR_eDP;
if (pdata->bridge.type == DRM_MODE_CONNECTOR_DisplayPort) {
- pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT |
- DRM_BRIDGE_OP_HPD;
+ pdata->bridge.ops = DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_DETECT;
+ if (client->irq)
+ pdata->bridge.ops |= DRM_BRIDGE_OP_HPD;
/*
* If comms were already enabled they would have been enabled
* with the wrong value of HPD_DISABLE. Update it now. Comms
--
2.43.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
2026-02-06 12:37 [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used Franz Schnyder
@ 2026-02-06 15:46 ` Doug Anderson
2026-02-06 16:10 ` Francesco Dolcini
0 siblings, 1 reply; 5+ messages in thread
From: Doug Anderson @ 2026-02-06 15:46 UTC (permalink / raw)
To: Franz Schnyder
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Franz Schnyder,
dri-devel, linux-kernel, Francesco Dolcini, stable
Hi,
On Fri, Feb 6, 2026 at 4:38 AM Franz Schnyder <fra.schnyder@gmail.com> wrote:
>
> From: Franz Schnyder <franz.schnyder@toradex.com>
>
> Fallback to polling to detect hotplug events on systems without
> interrupts.
>
> On systems where the interrupt line of the bridge is not connected,
> the bridge cannot notify hotplug events. Only add the
> DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
> otherwise remain in polling mode.
>
> Fixes: 9133bc3f0564 ("drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD")
> Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
> Cc: stable@vger.kernel.org
> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
It's weird that you have two fixes, but upon closer inspection, I see
why you tagged it as you did.
The first commit that landed, commit 55e8ff842051 ("drm/bridge:
ti-sn65dsi86: Add HPD for DisplayPort connector type"), was still
using polling mode and just using the HPD line for polling. That
commit incorrectly set the flag "DRM_BRIDGE_OP_HPD". So the proper
backport to kernels with just that commit would be to take away that
flag. Unfortunately, I didn't notice this problem during the review
and I don't personally have any hardware using this bridge for DP,
only eDP.
The second commit that landed, commit 9133bc3f0564 ("drm/bridge:
ti-sn65dsi86: Add support for DisplayPort mode with HPD"), actually
added support for the HPD interrupt. After this commit, your fix
(which makes the flag "DRM_BRIDGE_OP_HPD" depend on the IRQ) is the
correct one.
Unfortunately, I think the above will confuse the stable scripts.
Since your patch applied cleanly atop the first commit then it will
picked to any kernels with it, even if they don't have the second
commit.
I think the first commit landed in v6.16 and the second commit isn't
yet in any stable release.
Maybe the right way to look at this is to just call the 2nd patch a
prereq? So this:
Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for
DisplayPort connector type")
Cc: <stable@vger.kernel.org> # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
That will cause the 2nd patch to get picked up for stable too, but
that would be preferable to having just your fix without the 2nd
patch. Alternatively, you could try to add some other note to the
stable team to help them arrive at the right backport.
In any case:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
I'm going to let this sit on the lists for a little while in case
folks want to comment on the above.
-Doug
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
2026-02-06 15:46 ` Doug Anderson
@ 2026-02-06 16:10 ` Francesco Dolcini
2026-02-06 16:27 ` Doug Anderson
0 siblings, 1 reply; 5+ messages in thread
From: Francesco Dolcini @ 2026-02-06 16:10 UTC (permalink / raw)
To: Doug Anderson
Cc: Franz Schnyder, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Franz Schnyder, dri-devel, linux-kernel,
Francesco Dolcini, stable
Hello Doug,
On Fri, Feb 06, 2026 at 07:46:10AM -0800, Doug Anderson wrote:
> On Fri, Feb 6, 2026 at 4:38 AM Franz Schnyder <fra.schnyder@gmail.com> wrote:
> >
> > From: Franz Schnyder <franz.schnyder@toradex.com>
> >
> > Fallback to polling to detect hotplug events on systems without
> > interrupts.
> >
> > On systems where the interrupt line of the bridge is not connected,
> > the bridge cannot notify hotplug events. Only add the
> > DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
> > otherwise remain in polling mode.
> >
> > Fixes: 9133bc3f0564 ("drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD")
> > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
> It's weird that you have two fixes, but upon closer inspection, I see
> why you tagged it as you did.
>
> The first commit that landed, commit 55e8ff842051 ("drm/bridge:
> ti-sn65dsi86: Add HPD for DisplayPort connector type"), was still
> using polling mode and just using the HPD line for polling. That
> commit incorrectly set the flag "DRM_BRIDGE_OP_HPD". So the proper
> backport to kernels with just that commit would be to take away that
> flag. Unfortunately, I didn't notice this problem during the review
> and I don't personally have any hardware using this bridge for DP,
> only eDP.
>
> The second commit that landed, commit 9133bc3f0564 ("drm/bridge:
> ti-sn65dsi86: Add support for DisplayPort mode with HPD"), actually
> added support for the HPD interrupt. After this commit, your fix
> (which makes the flag "DRM_BRIDGE_OP_HPD" depend on the IRQ) is the
> correct one.
>
> Unfortunately, I think the above will confuse the stable scripts.
> Since your patch applied cleanly atop the first commit then it will
> picked to any kernels with it, even if they don't have the second
> commit.
>
> I think the first commit landed in v6.16 and the second commit isn't
> yet in any stable release.
>
> Maybe the right way to look at this is to just call the 2nd patch a
> prereq? So this:
>
> Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for
> DisplayPort connector type")
> Cc: <stable@vger.kernel.org> # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
>
> That will cause the 2nd patch to get picked up for stable too, but
> that would be preferable to having just your fix without the 2nd
> patch. Alternatively, you could try to add some other note to the
> stable team to help them arrive at the right backport.
We had some internal review before sending this patch and I am the one
that suggested to put both commit as fixes in the end.
I agree that your solution is the correct one (I am not familiar with
the syntax there, but I agree on the concept), assuming
nobody disagree on this, should we send a v2, or are you going to amend
the commit message when applying it?
Thanks,
Francesco
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
2026-02-06 16:10 ` Francesco Dolcini
@ 2026-02-06 16:27 ` Doug Anderson
2026-02-13 20:45 ` Doug Anderson
0 siblings, 1 reply; 5+ messages in thread
From: Doug Anderson @ 2026-02-06 16:27 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Franz Schnyder, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Franz Schnyder, dri-devel, linux-kernel, stable
Hi,
On Fri, Feb 6, 2026 at 8:11 AM Francesco Dolcini <francesco@dolcini.it> wrote:
>
> Hello Doug,
>
> On Fri, Feb 06, 2026 at 07:46:10AM -0800, Doug Anderson wrote:
> > On Fri, Feb 6, 2026 at 4:38 AM Franz Schnyder <fra.schnyder@gmail.com> wrote:
> > >
> > > From: Franz Schnyder <franz.schnyder@toradex.com>
> > >
> > > Fallback to polling to detect hotplug events on systems without
> > > interrupts.
> > >
> > > On systems where the interrupt line of the bridge is not connected,
> > > the bridge cannot notify hotplug events. Only add the
> > > DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
> > > otherwise remain in polling mode.
> > >
> > > Fixes: 9133bc3f0564 ("drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD")
> > > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> > > ---
> > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
> > > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > It's weird that you have two fixes, but upon closer inspection, I see
> > why you tagged it as you did.
> >
> > The first commit that landed, commit 55e8ff842051 ("drm/bridge:
> > ti-sn65dsi86: Add HPD for DisplayPort connector type"), was still
> > using polling mode and just using the HPD line for polling. That
> > commit incorrectly set the flag "DRM_BRIDGE_OP_HPD". So the proper
> > backport to kernels with just that commit would be to take away that
> > flag. Unfortunately, I didn't notice this problem during the review
> > and I don't personally have any hardware using this bridge for DP,
> > only eDP.
> >
> > The second commit that landed, commit 9133bc3f0564 ("drm/bridge:
> > ti-sn65dsi86: Add support for DisplayPort mode with HPD"), actually
> > added support for the HPD interrupt. After this commit, your fix
> > (which makes the flag "DRM_BRIDGE_OP_HPD" depend on the IRQ) is the
> > correct one.
> >
> > Unfortunately, I think the above will confuse the stable scripts.
> > Since your patch applied cleanly atop the first commit then it will
> > picked to any kernels with it, even if they don't have the second
> > commit.
> >
> > I think the first commit landed in v6.16 and the second commit isn't
> > yet in any stable release.
> >
> > Maybe the right way to look at this is to just call the 2nd patch a
> > prereq? So this:
> >
> > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for
> > DisplayPort connector type")
> > Cc: <stable@vger.kernel.org> # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
> >
> > That will cause the 2nd patch to get picked up for stable too, but
> > that would be preferable to having just your fix without the 2nd
> > patch. Alternatively, you could try to add some other note to the
> > stable team to help them arrive at the right backport.
>
> We had some internal review before sending this patch and I am the one
> that suggested to put both commit as fixes in the end.
>
> I agree that your solution is the correct one (I am not familiar with
> the syntax there, but I agree on the concept), assuming
> nobody disagree on this, should we send a v2, or are you going to amend
> the commit message when applying it?
You can see the docs at:
Documentation/process/stable-kernel-rules.rst
As long as you agree with what I came up with, there's no need for you
to resend and I can adjust it when I land the patch. I'll still let it
sit on the list for at least next week to give others a chance to
review / comment.
-Doug
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
2026-02-06 16:27 ` Doug Anderson
@ 2026-02-13 20:45 ` Doug Anderson
0 siblings, 0 replies; 5+ messages in thread
From: Doug Anderson @ 2026-02-13 20:45 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Franz Schnyder, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Franz Schnyder, dri-devel, linux-kernel, stable
Hi,
On Fri, Feb 6, 2026 at 8:27 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Fri, Feb 6, 2026 at 8:11 AM Francesco Dolcini <francesco@dolcini.it> wrote:
> >
> > Hello Doug,
> >
> > On Fri, Feb 06, 2026 at 07:46:10AM -0800, Doug Anderson wrote:
> > > On Fri, Feb 6, 2026 at 4:38 AM Franz Schnyder <fra.schnyder@gmail.com> wrote:
> > > >
> > > > From: Franz Schnyder <franz.schnyder@toradex.com>
> > > >
> > > > Fallback to polling to detect hotplug events on systems without
> > > > interrupts.
> > > >
> > > > On systems where the interrupt line of the bridge is not connected,
> > > > the bridge cannot notify hotplug events. Only add the
> > > > DRM_BRIDGE_OP_HPD flag if an interrupt has been registered
> > > > otherwise remain in polling mode.
> > > >
> > > > Fixes: 9133bc3f0564 ("drm/bridge: ti-sn65dsi86: Add support for DisplayPort mode with HPD")
> > > > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort connector type")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
> > > > ---
> > > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++++--
> > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > >
> > > It's weird that you have two fixes, but upon closer inspection, I see
> > > why you tagged it as you did.
> > >
> > > The first commit that landed, commit 55e8ff842051 ("drm/bridge:
> > > ti-sn65dsi86: Add HPD for DisplayPort connector type"), was still
> > > using polling mode and just using the HPD line for polling. That
> > > commit incorrectly set the flag "DRM_BRIDGE_OP_HPD". So the proper
> > > backport to kernels with just that commit would be to take away that
> > > flag. Unfortunately, I didn't notice this problem during the review
> > > and I don't personally have any hardware using this bridge for DP,
> > > only eDP.
> > >
> > > The second commit that landed, commit 9133bc3f0564 ("drm/bridge:
> > > ti-sn65dsi86: Add support for DisplayPort mode with HPD"), actually
> > > added support for the HPD interrupt. After this commit, your fix
> > > (which makes the flag "DRM_BRIDGE_OP_HPD" depend on the IRQ) is the
> > > correct one.
> > >
> > > Unfortunately, I think the above will confuse the stable scripts.
> > > Since your patch applied cleanly atop the first commit then it will
> > > picked to any kernels with it, even if they don't have the second
> > > commit.
> > >
> > > I think the first commit landed in v6.16 and the second commit isn't
> > > yet in any stable release.
> > >
> > > Maybe the right way to look at this is to just call the 2nd patch a
> > > prereq? So this:
> > >
> > > Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for
> > > DisplayPort connector type")
> > > Cc: <stable@vger.kernel.org> # 6.16: 9133bc3f0564: drm/bridge: ti-sn65dsi86: Add
> > >
> > > That will cause the 2nd patch to get picked up for stable too, but
> > > that would be preferable to having just your fix without the 2nd
> > > patch. Alternatively, you could try to add some other note to the
> > > stable team to help them arrive at the right backport.
> >
> > We had some internal review before sending this patch and I am the one
> > that suggested to put both commit as fixes in the end.
> >
> > I agree that your solution is the correct one (I am not familiar with
> > the syntax there, but I agree on the concept), assuming
> > nobody disagree on this, should we send a v2, or are you going to amend
> > the commit message when applying it?
>
> You can see the docs at:
>
> Documentation/process/stable-kernel-rules.rst
>
> As long as you agree with what I came up with, there's no need for you
> to resend and I can adjust it when I land the patch. I'll still let it
> sit on the list for at least next week to give others a chance to
> review / comment.
Pushed to drm-misc-fixes with the updated Fixes / stable line.
[1/1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used
commit: 0b87d51690dd5131cbe9fbd23746b037aab89815
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-02-13 20:45 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-06 12:37 [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used Franz Schnyder
2026-02-06 15:46 ` Doug Anderson
2026-02-06 16:10 ` Francesco Dolcini
2026-02-06 16:27 ` Doug Anderson
2026-02-13 20:45 ` Doug Anderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox