On Wed, Dec 18, 2013 at 2:43 AM, Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
