linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Paul <seanpaul@chromium.org>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Dave Airlie <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	freedesktop-bugs@paulsd.com, gleb@fastmail.com,
	stable@vger.kernel.org
Subject: Re: [PATCH v2] drm: Schedule the output_poll_work with 1s delay if we have delayed event
Date: Mon, 9 Jan 2017 11:50:59 -0500	[thread overview]
Message-ID: <CAOw6vbK7RCiQvYTFEkGv+uMcrnMY2JU_TQ+9swra=i+-e5y3gg@mail.gmail.com> (raw)
In-Reply-To: <20170109143158.21917-1-peter.ujfalusi@ti.com>

On Mon, Jan 9, 2017 at 9:31 AM, Peter Ujfalusi <peter.ujfalusi@ti.com> wrote:
> Instead of scheduling the work to handle the initial delayed event, use 1s
> delay.
>
> This delay should not be needed, but Optimus/nouveau will fail in a
> mysterious way if the delayed event is handled as soon as possible like it

Has anyone tried to demystify the failure? It seems like fixing the
root problem would be better than this.

Perhaps we should just revert 339fd36238dd to fix stable.

Sean

> is done in drm_helper_probe_single_connector_modes() in case the poll
> was enabled before.
>
> Reverting 339fd36238dd would give back the 10 sec (!) delay to handle the
> delayed event. Adding 1sec delay to the poll_work is enough to work around
> the issue in Optimus setups and gives shorter response on handling the
> initial delayed event.
>
> Fixes: 339fd36238dd ("drm: drm_probe_helper: Fix output_poll_work scheduling")
> Cc: stable@vger.kernel.org   # v4.9
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index 06a62e37fbdc..258abed43e38 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -146,8 +146,16 @@ void drm_kms_helper_poll_enable_locked(struct drm_device *dev)
>         drm_connector_list_iter_put(&conn_iter);
>
>         if (dev->mode_config.delayed_event) {
> +               /*
> +                * Use short (1s) delay to handle the initial delayed event.
> +                * This delay should not be needed, but Optimus/nouveau will
> +                * fail in a mysterious way if the delayed event is handled as
> +                * soon as possible like it is done in
> +                * drm_helper_probe_single_connector_modes() in case the poll
> +                * was enabled before.
> +                */
>                 poll = true;
> -               delay = 0;
> +               delay = HZ;
>         }
>
>         if (poll)
> --
> 2.11.0
>



-- 
Sean Paul, Software Engineer, Google / Chromium OS

  reply	other threads:[~2017-01-09 16:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09 14:31 [PATCH v2] drm: Schedule the output_poll_work with 1s delay if we have delayed event Peter Ujfalusi
2017-01-09 16:50 ` Sean Paul [this message]
2017-01-10 10:40   ` Daniel Vetter
2017-01-10 10:43     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOw6vbK7RCiQvYTFEkGv+uMcrnMY2JU_TQ+9swra=i+-e5y3gg@mail.gmail.com' \
    --to=seanpaul@chromium.org \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedesktop-bugs@paulsd.com \
    --cc=gleb@fastmail.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@ti.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).