Is this configuration issue?

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@dp-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT)
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3220/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3220/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5079/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5079/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3221/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3221/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3223/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3223/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3224/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3224/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6396/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6396/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13489/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13489/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13490/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13490/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3222/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3222/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13491/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13492/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13492/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3227/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3227/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6397/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13493/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13493/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6398/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6398/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13494/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13494/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13497/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13497/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13498/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13498/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4533/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_4533/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13499/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3228/fi-icl-u4/igt@kms_chamelium@dp-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3228/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-fast.html

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@dp-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(HDMI|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(HDMI|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter

This is a new host, so yes, there might be configuration mismatch. Port names and port IDs match though, so I'd be more inclined to think that the issue is in the USB-C hotplug side: that has never been tested before in our CI with Chamelium.

One USB-C port has USB-C-to-DP dongle, other has USB-C-to-HDMI dongle.

.igtrc:

[Chamelium]
URL=http://192.168.1.227:9992

[Chamelium:DP-3]
ChameliumPortID=1

[Chamelium:DP-4]
ChameliumPortID=3

/sys/kernel/debug/dri/0/i915_display_info:

connector 191: type eDP-1, status: connected
	physical dimensions: 290x170mm
	subpixel order: Unknown
	CEA rev: 0
	DPCD rev: 12
	audio support: no
	fixed mode:
		"3840x2160": 60 533250 3840 3888 3920 4000 2160 2163 2168 2222 0x48 0xa
...
connector 220: type DP-3, status: connected
	physical dimensions: 1020x570mm
	subpixel order: Unknown
	CEA rev: 3
	DPCD rev: 12
	audio support: yes
	DP branch device present: no
	modes:
		"1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
...
connector 223: type DP-4, status: connected
	physical dimensions: 1020x570mm
	subpixel order: Unknown
	CEA rev: 3
	DPCD rev: 12
	audio support: yes
	DP branch device present: yes
		Type: HDMI
		ID: 176GB0
		HW: 1.0
		SW: 7.38
		Max TMDS clock: 600000 kHz
		Max bpc: 12
	modes:
		"1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa

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. 

However probably all the DP kms_chamelium tests will fail expectedly on DP-alt outputs. 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.

So we'll have to blacklist at least kms_chamelium@dp-hpd-fast on iclu4 (if it'll keep the DP-alt only config in CI).

Next we'll have to add new kms_chamelium subtests that handle hotplug events properly which could be enabled with DP-alt outputs too.

Hotplug events are intentionally left out of Chamelium tests because some tests trigger HPD storms which make the driver disable HPD.

(In reply to emersion from comment #7)
> Hotplug events are intentionally left out of Chamelium tests because some
> tests trigger HPD storms which make the driver disable HPD.

Not sure what you mean here. Hotplug uevents are handled already by all the tests (those are the events the test is waiting for), the handling just lacks the corresponding output enabling/disabling.

(In reply to Imre Deak from comment #8)
> Not sure what you mean here. Hotplug uevents are handled already by all the
> tests (those are the events the test is waiting for), the handling just
> lacks the corresponding output enabling/disabling.

No, hotplug events aren't handled by kms_chamelium. Instead, the tests poll for the connector to become connected. See wait_for_connector.

Well, depends on the tests I guess. Some tests use igt_hotplug_detected.

(In reply to emersion from comment #9)
> (In reply to Imre Deak from comment #8)
> > Not sure what you mean here. Hotplug uevents are handled already by all the
> > tests (those are the events the test is waiting for), the handling just
> > lacks the corresponding output enabling/disabling.
> 
> No, hotplug events aren't handled by kms_chamelium. Instead, the tests poll
> for the connector to become connected. See wait_for_connector.

Oh, ok. Missed this fact. The solution for DP-alt in case of these tests is anyway (1) black-list them for the DP-alt machines, and then (2) add new tests that do the enabling/disabling when they detected the connector status via polling, or just disable the output for the whole duration of the subtest (and then restore the state to the pre-subtest state).

(In reply to emersion from comment #10)
> Well, depends on the tests I guess. Some tests use igt_hotplug_detected.

Ok, so these will need the same handling as above (1) and optionally (2).

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter

*** Bug 111049 has been marked as a duplicate of this bug. ***

(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.

> However probably all the DP kms_chamelium tests will fail expectedly on
> DP-alt outputs. 

Can you elaborate? I'm not sure I understand.

> 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?

Some tests currently assert HPD on the Chamelium side and expect a hotplug. Is this supposed not to work with DP-ext?

(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.

> 
> > 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.

(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.

@Simon / Imre,
Based on the impact, can you please set the severity/priority of this bug appropriately?

(In reply to Lakshmi from comment #17)
> @Simon / Imre,
> Based on the impact, can you please set the severity/priority of this bug
> appropriately?

For the end-user this doesn't have an impact, since user space is expected to react to hotplug events by enabling/disabling the output accordingly - in which case subsequent hotplug events will be reported as expected by the driver.

As for the kms_chamelium tests, I suggest not running the current ones on iclu4, which has only DP-alt sinks connected.

Thanks Imre, setting the priority to Medium based on the assessment.

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_321/fi-icl-u4/igt@kms_chamelium@dp-edid-change-during-suspend.html

*** Bug 111046 has been marked as a duplicate of this bug. ***

(In reply to Imre Deak from comment #15)
> 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.

Hmm, I see.

> 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. 

Thanks for the explanation!

> 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.

I'll try to send a patch to do this.

*** Bug 111084 has been marked as a duplicate of this bug. ***

(In reply to emersion from comment #22)
> (In reply to Imre Deak from comment #15)
> > 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.
> 
> Hmm, I see.
> 
> > 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. 
> 
> Thanks for the explanation!
> 
> > 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.
> 
> I'll try to send a patch to do this.

Ok, thanks a lot for looking into that. Btw, are you planning to add new subtests that work according to the above (instead of modifying the existing ones) and black list somehow the existing ones (at least for now) for DP-alt connectors? That would be ideal, since we should still keep the existing ones as-is to retain the coverage for all that scenarios.

Running the old ones (with reduced timeout) on DP-alt would be still good to check for any kernel breakage with enabled outputs, but atm that slows things down a lot since each subtest incurs a 20sec timeout on DP-alt...

*** Bug 111096 has been marked as a duplicate of this bug. ***

(In reply to Imre Deak from comment #24)
> Ok, thanks a lot for looking into that. Btw, are you planning to add new
> subtests that work according to the above (instead of modifying the existing
> ones) and black list somehow the existing ones (at least for now) for DP-alt
> connectors? That would be ideal, since we should still keep the existing
> ones as-is to retain the coverage for all that scenarios.

Hmm, that's a little bit annoying. What about adding a single test that doesn't disable an output when unplugged, and converting all existing tests to work on DP-alt? IMHO this would make more sense because userspace not disabling an output when unplugged is an edge-case.

(In reply to emersion from comment #26)
> (In reply to Imre Deak from comment #24)
> > Ok, thanks a lot for looking into that. Btw, are you planning to add new
> > subtests that work according to the above (instead of modifying the existing
> > ones) and black list somehow the existing ones (at least for now) for DP-alt
> > connectors? That would be ideal, since we should still keep the existing
> > ones as-is to retain the coverage for all that scenarios.
> 
> Hmm, that's a little bit annoying. What about adding a single test that
> doesn't disable an output when unplugged, and converting all existing tests
> to work on DP-alt? IMHO this would make more sense because userspace not
> disabling an output when unplugged is an edge-case.

Changing existing tests has been considered as bad, since that can introduce new issues into the CI bug-tracking system as regressions, whereas they would be an issue always present, just not tested before.

So I don't feel easy about changing the existing tests, but I suppose you could do it if:
- The change is simple like disabling the output only once before the subtest for the whole duration and not adding more complexity like dynamic enabling/disabling based on the connector state.
- You've discussed about the policy of changing existing tests with the CI folks (your team?) and Ville, Daniel, they're the best to decide about this.

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@dp-hpd-fast - fail - Failed assertion: reprobe_connector(data, port) == DRM_MODE_CONNECTED
  (No new failures associated)

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished
  (No new failures associated)

(In reply to Imre Deak from comment #27)
> Changing existing tests has been considered as bad, since that can introduce
> new issues into the CI bug-tracking system as regressions, whereas they
> would be an issue always present, just not tested before.

I've just sent an RFC that tries to fix it. We'll see if there are regressions and decide what to do from there.

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_322/fi-icl-u4/igt@kms_chamelium@dp-hpd.html

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_322/fi-icl-u4/igt@kms_chamelium@hdmi-edid-change-during-suspend.html

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_325/fi-icl-u4/igt@kms_chamelium@hdmi-hpd.html

(In reply to Imre Deak from comment #15)
> 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.

What happens if legacy userspace doesn't react to hotplug events? We need to re-enable the output automatically on hotplug. As of now, legacy userspace won't work on DP-alt.

I'm leaning towards marking this as a kernel bug. If userspace doesn't disable the mode, the kernel should re-enable it on hotplug.

*** Bug 111155 has been marked as a duplicate of this bug. ***

(In reply to emersion from comment #34)
> (In reply to Imre Deak from comment #15)
> > 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.
> 
> What happens if legacy userspace doesn't react to hotplug events? We need to
> re-enable the output automatically on hotplug. As of now, legacy userspace
> won't work on DP-alt.
> 
> I'm leaning towards marking this as a kernel bug. If userspace doesn't
> disable the mode, the kernel should re-enable it on hotplug.

The same is true for anything connected in DP-MST mode too though: you connect an MST display, disconnect, then reconnect it, then the mode won't be re-enabled automatically on the display, unless user space processes the hotplug events. So the requirement for user space to do proper hotplug event processing is not specific to USB-C connectors.

Why do you think we should handle USB-C connectors specially (and have the user space hotplug processing requirement only for DP-MST connectors)? We would need a very good justification listing the actual legacy userspace instances you mentioned (since there hasn't been any actual complaints for these even for MST).

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@hdmi-hpd-storm - fail - Failed assertion: igt_hpd_storm_detected(data->drm_fd)
  (No new failures associated)

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished +}


  No new failures caught with the new filter

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-* - fail - Failed assertion: finished +}


  No new failures caught with the new filter

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) -}
{+ fi-icl-u4: igt@kms_chamelium@(hdmi|dp)-hpd-fast|igt@kms_chamelium@dp-edid-change-during-suspend - fail - Failed assertion: igt_hotplug_detected(mon, HOTPLUG_TIMEOUT) +}


  No new failures caught with the new filter

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* fi-icl-u4: igt@kms_chamelium@dp-hpd-after-suspend - fail -  Failed assertion: wait_for_hotplug(mon, &timeout)
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_346/fi-icl-u4/igt@kms_chamelium@dp-hpd-after-suspend.html

It's still not clear what's the best way to proceed.

From a kernel perspective, the best solution so far would be to do an implicit modeset on hotplug if the pipe is still active. Hotplug-aware userspace will disable the pipe on unplug event so the implicit modeset shouldn't happen. Apparently, there are still some questions about power management that need to be answered.

From an IGT test point-of-view, I think I'd still prefer to have one test for the legacy behavior (skipped on MST and on ICL USB-C), and other tests doing the Right Thing.

WIP patch adding the legacy test: https://patchwork.freedesktop.org/series/65182/

Kernel patch to be able to tell apart Type-C ports: https://patchwork.freedesktop.org/series/65695/

With that we should be able to skip IGT tests on Type-C + ICL.

Assigning to Imre because the kernel patch he's working on should fix this bug.

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* SKL igt@kms_chamelium@hdmi-hpd-fast - fail -: Failed assertion: status == DRM_MODE_CONNECTED, Invalid connector status after hotplug: got disconnected, expected connected
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6926/fi-skl-6700k2/igt@kms_chamelium@hdmi-hpd-fast.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6927/fi-skl-6700k2/igt@kms_chamelium@hdmi-hpd-fast.html

A CI Bug Log filter associated to this bug has been updated:

{- fi-icl-u4: igt@kms_chamelium@dp-hpd-after-suspend - fail -  Failed assertion: wait_for_hotplug(mon, &timeout) -}
{+ fi-icl-u4: igt@kms_chamelium@dp-hpd-after-suspend - fail -  Failed assertion: wait_for_hotplug(mon, &timeout) +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_378/fi-icl-u4/igt@kms_chamelium@hdmi-hpd-after-suspend.html

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@kms_chamelium@common-hpd-after-suspend - fail - Failed assertion: current_state == target_state
  - http://gfx-ci.fi.intel.com/tree/drm-tip/CUSTOM_mupuf-1571984517/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html
  - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7185/fi-icl-u2/igt@kms_chamelium@common-hpd-after-suspend.html

A CI Bug Log filter associated to this bug has been updated:

{- SKL igt@kms_chamelium@hdmi-hpd-fast - fail -: Failed assertion: status == DRM_MODE_CONNECTED, Invalid connector status after hotplug: got disconnected, expected connected -}
{+ Chamelium: igt@kms_chamelium@hdmi-hpd-fast - fail -: Failed assertion: status == DRM_MODE_CONNECTED, Invalid connector status after hotplug: got disconnected, expected connected +}

New failures caught by the filter:

  * https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_392/fi-icl-u4/igt@kms_chamelium@dp-hpd.html

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/323.