drm_do_probe_ddc_edid ENXIO check too aggressive?

Daniel Vetter daniel at ffwll.ch
Wed Dec 18 09:15:50 PST 2013


On Wed, Dec 18, 2013 at 10:28:37AM -0600, Daniel Drake wrote:
> 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?

Oh right, if you use the hpd pin for detection then this will happen. So I
guess always delaying is the right option. Or you could make the connector
state only conditional on an edid being present for HDMI, which would also
work.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list