[Bug 111045] [CI][BAT] igt at kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=111045

--- Comment #16 from Imre Deak <imre.deak at intel.com> ---
(In reply to Imre Deak from comment #15)
> (In reply to emersion from comment #14)
> > (In reply to Imre Deak from comment #6)
> > > There could be a chamelium config issue wrt. HDMI, since there is no HDMI
> > > sinks connected (even the USBC->HDMI dongle will show up as DP), but the
> > > HDMI chamelium subtests are not skipped as they should be. 
> > 
> > I think the configuration is fine. I routinely run HDMI tests on my DP port
> > with lspcon, and configuring .igtrc to map the DUT DP output to the
> > Chamelium HDMI input works.
> 
> With DP++ connectors that should work (with a DP++->HDMI dongle), but here
> we're talking about a USB-C connector which does not have HDMI output
> support. The driver doesn't even register an HDMI output for these connector.
> 
> You can connect a USB-C connector to an HDMI input via a TypeC-DP-alt->HDMI
> dongle, but that is still a DP connector from the driver's and the igt
> test's POV, and so all the Chamelium HDMI subtests should be skipped - which
> is what I talked about above.

Ah, now I got how the chamelium HDMI subtests work, they also allow a DP source
connected to an HDMI sink. So you are right the HDMI subtests should also be
run for DP-alt connectors, but they have the same problem as discussed below
about having a mode enabled all the time while toggling HPD.

> 
> > 
> > > However probably all the DP kms_chamelium tests will fail expectedly on
> > > DP-alt outputs. 
> > 
> > Can you elaborate? I'm not sure I understand.
> 
> If unplugging a DP-alt display while there is an active modeset on it, and
> then replugging the DP-alt display, the HW/FW/driver won't signal the
> corresponding plug-in hotplug event until the mode is disabled.
> 
> > > The exceptions could be kms_chamelium subtests where the
> > > subtest properly handles hotplug events: enables/disables the output
> > > according to the connect/disconnect hotplug event it receives. That's not
> > > the case atm with most of the kms_chamelium subtests.
> > 
> > Why is this needed? If a user plugs a USB-C to HDMI dongle, the DRM client
> > should see a hotplug event even if the output hasn't been enabled yet, right?
> 
> The failing tests do this:
> 
> - <have the output enabled>
> - unplug the display, keeping the output enabled
> - wait/poll for the disconnect status -> success
> - replug the display, while the output is still enabled
> - wait/poll for the connect status -> fail
> 
> This sequence is not supported with DP-alt sinks (like the USB-C to HDMI
> dongle), as I described above. 
> 
> > Some tests currently assert HPD on the Chamelium side and expect a hotplug.
> > Is this supposed not to work with DP-ext?
> 
> If there wouldn't be any mode enabled for the whole duration of the
> sequence, or the client would enable/disable the mode according to the
> output's connected/disconnected status, then all the hotplug uevents,
> polling would work as the test expects.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20190705/3beaf0d1/attachment.html>