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


Groups > linux.kernel > #1527854

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

From John Stultz <john.stultz@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 2/3] drm/bridge: adv7511: Add 200ms delay on power-on
Date 2016-11-22 20:00 +0100
Message-ID <sGosq-2Ad-27@gated-at.bofh.it> (permalink)
References <sG7hT-8nV-7@gated-at.bofh.it> <sGnmG-1SY-43@gated-at.bofh.it> <sGnPI-2mW-23@gated-at.bofh.it> <sGnZn-2q2-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Nov 22, 2016 at 10:23 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> 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@linaro.org> 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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[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
  [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

csiph-web