Bug 41561

Summary: [r600 KMS] Hotplug detect does not work for HDMI monitor on Fusion E-350 board
Product: DRI Reporter: Simon Farnsworth <simon.farnsworth>
Component: DRM/RadeonAssignee: Default DRI bug account <dri-devel>
Status: NEW --- QA Contact:
Severity: normal    
Priority: medium CC: qjn
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
1/2: fix the digital only cases
none
2/2: fix the mixed and analog cases none

Description Simon Farnsworth 2011-10-07 08:44:40 UTC
Using airlied-drm-fixes kernel as of commit 6777a4f6898a53974ef7fe7ce09ec41fae0f32db with Alex Deucher's patch "drm/radeon/kms: use hardcoded dig encoder to transmitter mapping for DCE4.1" on top, I'm not seeing uevents from the kernel when I plug and unplug a HDMI monitor.

dmesg with drm.debug=0xf shows me the following when I connect a monitor:

# dmesg -c
[15202.939581] [drm:evergreen_irq_process], r600_irq_process start: rptr 5872, wptr 5888
[15202.939609] [drm:evergreen_irq_process], IH: HPD2
[15203.050597] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
[15203.050605] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 1 to 1
[15203.052661] [drm:output_poll_execute], [CONNECTOR:17:VGA-1] status updated from 2 to 2

radeonreg suggests that the HPD sense bit is correctly set

# ./radeonreg regs all | grep 00006028 # DC_HPD2_INT_STATUS
00006028        ff0ff012 (-15732718)

When I remove the monitor, I get the following from dmesg and radeonreg:

# dmesg -c
[15307.075271] [drm:evergreen_irq_process], r600_irq_process start: rptr 5888, wptr 5904
[15307.075300] [drm:evergreen_irq_process], IH: HPD2
[15307.131727] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 192
[15307.131733] Raw EDID:
[15307.131738]          3f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131742]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131745]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131749]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131752]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131756]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131759]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.131763]          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[15307.141965] [drm:radeon_dvi_detect] *ERROR* HDMI-A-1: probed a monitor but no|invalid EDID
[15307.141975] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
[15307.141981] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 1 to 1
[15307.144028] [drm:output_poll_execute], [CONNECTOR:17:VGA-1] status updated from 2 to 2

# ./radeonreg regs all | grep 00006028 # DC_HPD2_INT_STATUS
00006028        ff0ff000 (-15732736)

suggesting that HPD sense bits are being updated correctly by the hardware, but that this isn't resulting in uevents following through.
Comment 1 Alex Deucher 2011-10-07 08:59:22 UTC
If you are getting HPD interrupts, radeon_hotplug_work_func() should be getting scheduled.  From there drm_helper_hpd_irq_event() gets called which actually generates the uevent.
Comment 2 Simon Farnsworth 2011-10-07 09:07:40 UTC
drm_helper_hpd_irq_event() isn't generating uevents, because connector->status is not being updated somewhere, and is remaining at connector_status_connected, when it should be being updated to connector_status_disconnected.

If I do cat /sys/class/drm/card0-HDMI-A-1/status, I see the status is "disconnected", but something resets it by the time the helper comes back round. Possibly connected to the following from dmesg:

# cat /sys/class/drm/card0-HDMI-A-1/status ; dmesg -c
[16791.042128] [drm:radeon_atombios_connected_scratch_regs], DFP1 disconnected

# sleep 10 ; dmesg -c
[16799.522394] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
[16799.522407] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 1 to 1
[16799.524465] [drm:output_poll_execute], [CONNECTOR:17:VGA-1] status updated from 2 to 2
Comment 3 Simon Farnsworth 2011-10-07 09:26:08 UTC
So, I think I see the proximate cause of the bug, but not the reason for it:

In radeon_dvi_detect at radeon_connectors.c:962, I see:

	if (!force) {
		ret = connector->status;
		goto out;
	}

A HPD interrupt causes output_poll_execute at drm_crtc_helper.c:897 to execute 		connector->status = connector->funcs->detect(connector, false); as a result, I cannot see how a hotplug interrupt will ever result in a connector state changing.
Comment 4 Alex Deucher 2011-10-07 10:35:06 UTC
Created attachment 52093 [details] [review]
1/2: fix the digital only cases
Comment 5 Alex Deucher 2011-10-07 10:35:43 UTC
Created attachment 52094 [details] [review]
2/2: fix the mixed and analog cases
Comment 6 Simon Farnsworth 2011-10-07 10:53:04 UTC
I've applied both patches, and am testing on a machine with DVI-I and DisplayPort.

Test sequence:

1) Boot system with no outputs connected.
2) Attach a DVI-D monitor, then remove it.
3) Attach a DVI-A to VGA adapter that has no load, then remove it.
4) Attach a DVI-A to VGA adapter that has load but no DDC, then remove it.
5) Attach a DVI-A to VGA adapter that has load and DDC, then remove it.
6) Repeat steps 2 to 5, watching for uevents.

Note that the DVI-A to VGA adapter asserts HPD when connected.

Results:

DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after the connector has been used for VGA, but I get an event within 10 seconds.

No events when I plug in the adapter with no load and wait 20 seconds.

No events when I plug in the adapter with load but not DDC and wait 20 seconds.

Events on connect only when I plug in the adapter with DDC.
Comment 7 Alex Deucher 2011-10-07 11:14:49 UTC
*** Bug 40252 has been marked as a duplicate of this bug. ***
Comment 8 Alex Deucher 2011-10-07 11:16:14 UTC
(In reply to comment #6)
> Results:
> 
> DVI-D hotplug works fine. There is a delay on the first DVI-D hotplug after the
> connector has been used for VGA, but I get an event within 10 seconds.

good.

> 
> No events when I plug in the adapter with no load and wait 20 seconds.
> 

As expected.

> No events when I plug in the adapter with load but not DDC and wait 20 seconds.
> 

There's no way to get events for this case without doing load detection in the hotplug polling.  We don't currently support that case as load detection has the potential to cause flicker on connectors that share resources.  If you need it, you can remove the !force checks in the connector detect functions, but you may get flicker on other connectors if they share resources.

> Events on connect only when I plug in the adapter with DDC.

As expected.
Comment 9 Florian Mickler 2012-01-12 14:19:31 UTC
A patch referencing this bug report has been merged in Linux v3.2-rc1:

commit d0d0a225e6ad43314c9aa7ea081f76adc5098ad4
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Oct 7 14:23:48 2011 -0400

    drm/radeon/kms: handle !force case in connector detect more gracefully
Comment 10 Florian Mickler 2012-01-21 08:46:25 UTC
A patch referencing this bug report has been merged in Linux v3.2-rc1:

commit 5f0a26128d66ef81613fe923d5c288942844ccdc
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Fri Oct 7 14:23:47 2011 -0400

    drm/radeon/kms: bail early in dvi_detect for digital only connectors
Comment 11 Florian Mickler 2012-01-21 13:23:51 UTC
A patch referencing a commit referencing this bug report has been merged in Linux v3.2-rc1:

commit 340764465aa4a586ca332e61ae64883e5ad6f183
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Mon Oct 24 18:16:34 2011 -0400

    drm/radeon: avoid bouncing connector status btw disconnected & unknown

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.