drm_do_probe_ddc_edid ENXIO check too aggressive?

Daniel Drake drake at endlessm.com
Wed Dec 18 08:28:37 PST 2013


On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> I think we can do it simpler. When you get a hpd interrupt you eventually
> call drm_helper_hpd_irq_event which will update all the state and poke
> connectors. I'd just create a delay_work which you launch from
> hdmi_irq_thread with a 1 second delay which again calls
> drm_helper_hpd_irq_event. That way you won't miss the EDID (presuming the
> user isn't _really_ careful with pluggin in the cable slowly).

OK, I like this more simplistic option.

However, one more pesky detail, if I am understanding your suggestion
correctly. You are hoping for:

1. I connect the display, causing HPD interrupt
2. hpd irq handler calls drm_helper_hpd_irq_event() directly. Fails to
read EDID, no big deal.
3. hpd irq handles schedules a work item to call
drm_helper_hpd_irq_event() a second time, 1 second later. Reads EDID
sucessfully, image gets output to display.

That doesn't quite work. drm_helper_hpd_irq_event() in step 2 notices
and records the state change (disconnected --> connected). And after
drm_helper_probe_single_connector_modes() fails to read the EDID, it
starts outputting an image at 1024x768. When we come to step 3, we
call drm_helper_hpd_irq_event again, but that just returns without
doing anything as it does not detect any new state change.

If we skip step 2, i.e. always delay the call to
drm_helper_hpd_irq_event by 1 second, the problem is solved. As a
user, the 1 second delay is not noticable. What do you think about
just doing this?

Daniel


More information about the dri-devel mailing list