Re: [PATCH v1] drm/bridge: ti-sn65dsi86: Enable HPD polling if IRQ is not used

[Francesco Dolcini <francesco@dolcini.it>]

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