Hi Daniel, On Wednesday 23 Nov 2016 08:55:37 Daniel Vetter wrote: > On Tue, Nov 22, 2016 at 08:23:38PM +0200, Laurent Pinchart wrote: > > On Tuesday 22 Nov 2016 10:07:53 John Stultz wrote: > >> On Tue, Nov 22, 2016 at 9:38 AM, John Stultz 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. > > > > 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. > > > > /** > > * drm_kms_helper_hotplug_event - fire off KMS hotplug events > > * @dev: drm_device whose connector state changed > > * > > * This function fires off the uevent for userspace and also calls the > > * output_poll_changed function, which is most commonly used to inform the > > fbdev > > * emulation code and allow it to update the fbcon output configuration. > > * > > * Drivers should call this from their hotplug handling code when a change > > is > > * detected. Note that this function does not do any output detection of > > its > > * own, like drm_helper_hpd_irq_event() does - this is assumed to be done > > by the > > * driver already. > > * > > * This function must be called from process context with no mode > > * setting locks held. > > */ > > > > The function suffers from the same problem though, that it must be called > > from process context. > > > > Daniel, why do we have an API the is clearly related to interrupt handling > > but requires the caller to implement a workqueue ? > > Because in general you need that workqueue anyway, and up to now there was > no driver ever who didn't have a work-queue already. None of the bridge drivers in drivers/gpu/drm/bridge/ have workqueues. They call the HPD helpers from a threaded interrupt handler though. Sleeping in that context is fine, calling functions that might rely on interrupts from the same device to signal completion (such as reading EDID through .get_modes()) isn't. > Nesting workqueues > within workqueues seemed beyond silly, hence why I removed them in: > > commit 69787f7da6b2adc4054357a661aaa1701a9ca76f > Author: Daniel Vetter <daniel.vetter@xxxxxxxx> > Date: Tue Oct 23 18:23:34 2012 +0000 > > drm: run the hpd irq event code directly > > I guess we could talk about re-introducing a work-item based version of > drm_helper_hpd_irq_event. But for drm_kms_helper_hotplug_event I think it > doesn't make sense - if you call that you've probably just done a pile of > i2c transactions, and those can sleep. If you haven't done i2c > transactions, then it's not an external panel, and why exactly are you > handling hpd for them? -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
