Re: drm_do_probe_ddc_edid ENXIO check too aggressive?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Dec 17, 2013 at 11:12 PM, Daniel Drake <drake@xxxxxxxxxxxx> wrote:
>
> On Mon, Dec 16, 2013 at 5:40 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> > Have a bit of logic in the exynos ->detect function to re-try a 2nd
> > round of edid probing after each hdp interrupt if the first one
> > returns an -ENXIO. Only tricky part is to be careful with edge
> > detection so that userspace gets all the hotplug events still.
> > Presuming you don't have any funkiness with reprobing causing yet
> > another hpd interrupt and stuff like that (seen it all), as long as
> > you're using the helpers in drm_crtc_helper.c it should all be working
> > correctly. So you want a work item which just grabs all modeset locks
> > and then calls drm_helper_probe_single_connector_modes or something on
> > the right connector.
>
> Thanks for the tips. Having trouble sticking to those details though.
> exynos_drm_connector_detect() is actually a long way away from EDID
> probing so it is hard to detect the ENXIO case there.
>
> What happens here is:
> exynos hdmi_irq_thread() calls drm_helper_hpd_irq_event()
> That then calls exynos_drm_connector_detect(), which returns a simple
> "yes, hpd detection says we are connected"
> Then it calls drm_kms_helper_hotplug_event() for which the call chain is:
>
> drm_kms_helper_hotplug_event
> exynos_drm_output_poll_changed
> drm_fb_helper_hotplug_event
> drm_fb_helper_probe_connector_mode
> exynos_drm_connector_fill_modes
> drm_helper_probe_single_connector_modes
> exynos_drm_connector_get_modes
> drm_get_edid
> drm_do_get_edid
> drm_do_probe_ddc_edid <-- ENXIO in here
>
> drm_do_probe_ddc_edid actually swallows the ENXIO code and just
> returns -1, so that particular error is indistinguishable from others.
>
> Trying to follow your suggestions, the closest would seem to be something like:
>
> 1. Modify exynos_drm_connector_detect to read and cache the EDID right
> away. If EDID read fails for any reason, report "no connection" and
> schedule a work item to retry the EDID read. If the later EDID read
> succeeds, call drm_kms_helper_hotplug_event()
>
> 2. Modify exynos_drm_connector_get_modes to return cached EDID
>
> Does that sound sensible?

+seanpaul

I think the problem is that the hdmi irq is really just an undebounced
gpio interrupt, and thus, it is firing way too soon.
The chromium kernel adds an excplicit 1.1 second timer to debounce hpd
between the hdmi hpd-gpio irq and taking any action (ie reading the
edid).  I believe this will eventually make its way upstream, but is
still pending some other patches:

http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel-next.git;a=blob;f=drivers/gpu/drm/exynos/exynos_hdmi.c;h=1258c67e87f360c846c64bb3f04436a68018b4fe;hb=refs/heads/chromeos-3.8#l2647

-Dan

>
> Thanks
> Daniel
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  Powered by Linux