[PATCH v2 2/3] drm/bridge: dw-hdmi-qp: Add support for missing HPD

[Chris Morgan]

On Wed, Nov 19, 2025 at 10:02:23AM +0100, Maxime Ripard wrote:
> On Tue, Nov 18, 2025 at 02:36:09PM -0600, Chris Morgan wrote:
> > On Tue, Nov 18, 2025 at 09:46:04AM +0100, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Thu, Nov 13, 2025 at 01:29:38PM -0600, Chris Morgan wrote:
> > > > From: Chris Morgan <macromorgan at hotmail.com>
> > > > 
> > > > Add support for the dw-hdmi-qp driver to handle devices with missing
> > > > HPD pins.
> > > > 
> > > > Since in this situation we are now polling for the EDID data via i2c
> > > > change the error message to a debug message when we are unable to
> > > > complete an i2c read, as a disconnected device would otherwise fill
> > > > dmesg with i2c read errors.
> > > > 
> > > > Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
> > > 
> > > You must also disable any mode using the scrambler when there's no
> > > hotplug interrupt available.
> > 
> > Is there a simple way to do that? I'm not seeing any references to
> > scrambling in the current driver.
> > 
> > Should I just limit the rate to HDMI14_MAX_TMDSCLK (340000000)  under
> > dw_hdmi_qp_bridge_tmds_char_rate_valid() if using EDID polling? A
> > document I found online from Synopsys [1] claims that scrambling is
> > used by default at rates above 340 (if I'm reading it right) and used
> > opportunistically at rates below 340.
> 
> Yep, that's what you should be testing for :)
> 
> Maxime

Thanks, though now that I dig into it I'm a bit more confused on the
best way forward. It looks like for today the driver is hard-limited
to HDMI14_MAX_TMDSCLK because scrambling isn't supported. I'm assuming
it will be at some point, suggesting that we *will* need this in the
future. Is it sufficient to just add a comment there noting we need
to check, or should I add a check there (that does nothing today)
to ensure when we do support faster rates we are ready?

Thank you,
Chris