Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1527148 > unrolled thread

[RFC][PATCH 0/3] adv7511 EDID probing improvements

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH 0/3] adv7511 EDID probing improvements John Stultz <john.stultz@linaro.org> - 2016-11-22 01:40 +0100
    [RFC][PATCH 3/3] drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection John Stultz <john.stultz@linaro.org> - 2016-11-22 01:40 +0100
      Re: [RFC][PATCH 3/3] drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-22 09:30 +0100
    [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally John Stultz <john.stultz@linaro.org> - 2016-11-22 01:40 +0100
      Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-22 09:20 +0100
        Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off()  so they can be reused internally John Stultz <john.stultz@linaro.org> - 2016-11-22 09:20 +0100
          Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-22 09:30 +0100
        Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off()  so they can be reused internally John Stultz <john.stultz@linaro.org> - 2016-11-22 18:30 +0100
          Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-22 18:40 +0100
            Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off()  so they can be reused internally John Stultz <john.stultz@linaro.org> - 2016-11-22 18:50 +0100
            Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off()  so they can be reused internally John Stultz <john.stultz@linaro.org> - 2016-11-22 20:50 +0100
              Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework  adv7511_power_on/off() so they can be reused internally Archit Taneja <architt@codeaurora.org> - 2016-11-23 05:00 +0100
                Re: [RFC][PATCH 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off()  so they can be reused internally John Stultz <john.stultz@linaro.org> - 2016-11-28 19:50 +0100
    [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on John Stultz <john.stultz@linaro.org> - 2016-11-22 01:40 +0100
      Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-22 09:30 +0100
        Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on John Stultz <john.stultz@linaro.org> - 2016-11-22 18:50 +0100
          Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on John Stultz <john.stultz@linaro.org> - 2016-11-22 19:20 +0100
            Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-22 19:30 +0100
              Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on John Stultz <john.stultz@linaro.org> - 2016-11-22 20:00 +0100
              Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Daniel Vetter <daniel@ffwll.ch> - 2016-11-23 09:00 +0100
                Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-11-25 01:30 +0100
                  Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on Daniel Vetter <daniel@ffwll.ch> - 2016-11-25 07:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1529754 — Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on

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@ffwll.ch>
> 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

[toc] | [prev] | [next] | [standalone]

#1529830 — Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on

On Fri, Nov 25, 2016 at 1:23 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> > 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.

Hm, as long as they all use the bit-banging interfaces they'll
probably be all fine. For everyone else you need multiple layers of
work items to make sure you never end up stalling in an interrupt vs.
holding-mode_config.mutex deadlock. So still not convinced we need
this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web