On Tue, Nov 22, 2016 at 10:23 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote: >> On Tue, Nov 22, 2016 at 9:38 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote: >> > Interestingly, without the msleep added in this patch, removing the >> > wait_event_interruptible_timeout() method in adv7511_wait_for_edid() >> > and using the polling loop seems to make things just as reliable. So >> > maybe something is off with the irq handling here instead? >> >> Ahhhh.. So I think the trouble here is the that when we fail waiting >> for the irq, the backtrace is as follows: >> >> [ 8.318654] [<ffffff8008087c28>] dump_backtrace+0x0/0x1a0 >> [ 8.318661] [<ffffff8008087ddc>] show_stack+0x14/0x20 >> [ 8.318671] [<ffffff80084344f0>] dump_stack+0x90/0xb0 >> [ 8.318680] [<ffffff8008534650>] adv7511_get_edid_block+0x2c8/0x320 >> [ 8.318687] [<ffffff80085214a8>] drm_do_get_edid+0x78/0x280 >> [ 8.318693] [<ffffff8008534728>] adv7511_get_modes+0x80/0xd8 >> [ 8.318700] [<ffffff8008534794>] adv7511_connector_get_modes+0x14/0x20 >> [ 8.318710] [<ffffff8008500a54>] >> drm_helper_probe_single_connector_modes+0x2bc/0x500 >> [ 8.318718] [<ffffff800850e400>] drm_fb_helper_hotplug_event+0x130/0x188 >> [ 8.318726] [<ffffff800850ee68>] drm_fbdev_cma_hotplug_event+0x10/0x20 >> [ 8.318733] [<ffffff8008535718>] >> kirin_fbdev_output_poll_changed+0x20/0x58 >> [ 8.318740] [<ffffff8008500cc0>] drm_kms_helper_hotplug_event+0x28/0x38 >> [ 8.318748] [<ffffff80085010d8>] drm_helper_hpd_irq_event+0x138/0x180 >> [ 8.318754] [<ffffff8008533850>] adv7511_irq_process+0x78/0xd8 >> [ 8.318761] [<ffffff80085338c4>] adv7511_irq_handler+0x14/0x28 >> [ 8.318769] [<ffffff8008100060>] irq_thread_fn+0x28/0x68 >> [ 8.318775] [<ffffff8008100350>] irq_thread+0x128/0x1e8 >> [ 8.318782] [<ffffff80080d2e68>] kthread+0xd0/0xe8 >> [ 8.318788] [<ffffff8008082e80>] ret_from_fork+0x10/0x50 >> >> So we're actually in irq handling the hotplug interrupt, which is why >> we never get the irq notification when the edid is read. >> >> I suspect we need to use a workqueue to do the hotplug handling out of irq. So yea, using schedule_work on a work_struct to defer the hotplug handling seems to solve this issue. Thanks again for pushing back on the msleep approach. :) > Lovely :-) > > Quoting the DRM documentation: > > /** > * drm_helper_hpd_irq_event - hotplug processing > * @dev: drm_device > * > * Drivers can use this helper function to run a detect cycle on all > connectors > * which have the DRM_CONNECTOR_POLL_HPD flag set in their &polled member. All > * other connectors are ignored, which is useful to avoid reprobing fixed > * panels. > * > * This helper function is useful for drivers which can't or don't track > hotplug > * interrupts for each connector. > * > * Drivers which support hotplug interrupts for each connector individually > and > * which have a more fine-grained detect logic should bypass this code and > * directly call drm_kms_helper_hotplug_event() in case the connector state > * changed. > * > * This function must be called from process context with no mode > * setting locks held. > * > * Note that a connector can be both polled and probed from the hotplug > handler, > * in case the hotplug interrupt is known to be unreliable. > */ > > So it looks like we should use drm_kms_helper_hotplug_event() instead. Ok. I'll switch to this in my patch set as well. It doesn't seem to have any behavioral effect that I can see right off. thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
