All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Douglas Anderson <dianders@chromium.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: Rob Clark <robdclark@chromium.org>,
	Douglas Anderson <dianders@chromium.org>,
	Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/5] drm/panel-simple: Retry if we timeout waiting for HPD
Date: Mon, 25 Jan 2021 12:28:39 -0800	[thread overview]
Message-ID: <161160651990.76967.1833069919954122114@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20210115144345.v2.3.I6916959daa7c5c915e889442268d23338de17923@changeid>

Quoting Douglas Anderson (2021-01-15 14:44:18)
> On an Innolux N116BCA panel that I have in front of me, sometimes HPD
> simply doesn't assert no matter how long you wait for it. As per the
> very wise advice of The IT Crowd ("Have you tried turning it off and
> on again?") it appears that power cycling is enough to kick this panel
> back into a sane state.
> 
> From tests on this panel, it appears that leaving it powered off for a
> while stimulates the problem. Adding a 6 second sleep at the start of
> panel_simple_prepare_once() makes it happen fairly reliably and, with
> this delay, I saw up to 3 retries needed sometimes. Without the 6
> second sleep, however, the panel came up much more reliably the first
> time or after only 1 retry.
> 
> While it's unknown what the problems are with this panel (and probably
> the hardware should be debugged), adding a few retries to the power on
> routine doesn't seem insane. Even if this panel's problems are
> attributed to the fact that it's pre-production and/or can be fixed,
> retries clearly can help in some cases and really don't hurt.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

> @@ -440,6 +441,31 @@ static int panel_simple_prepare(struct drm_panel *panel)
>         return err;
>  }
>  
> +/*
> + * Some panels simply don't always come up and need to be power cycled to
> + * work properly.  We'll allow for a handful of retries.
> + */
> +#define MAX_PANEL_PREPARE_TRIES                5

Is this define used anywhere else? Feels like it would be better to
inline the constant and move the comment above the loop, but I guess
this is OK too.

> +
> +static int panel_simple_prepare(struct drm_panel *panel)
> +{
> +       int ret;
> +       int try;
> +
> +       for (try = 0; try < MAX_PANEL_PREPARE_TRIES; try++) {
> +               ret = panel_simple_prepare_once(panel);
> +               if (ret != -ETIMEDOUT)
> +                       break;
> +       }
> +
> +       if (ret == -ETIMEDOUT)
> +               dev_err(panel->dev, "Prepare timeout after %d tries\n", try);
> +       else if (try)
> +               dev_warn(panel->dev, "Prepare needed %d retries\n", try);
> +

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <swboyd@chromium.org>
To: Douglas Anderson <dianders@chromium.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: Rob Clark <robdclark@chromium.org>,
	David Airlie <airlied@linux.ie>,
	Douglas Anderson <dianders@chromium.org>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/5] drm/panel-simple: Retry if we timeout waiting for HPD
Date: Mon, 25 Jan 2021 12:28:39 -0800	[thread overview]
Message-ID: <161160651990.76967.1833069919954122114@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20210115144345.v2.3.I6916959daa7c5c915e889442268d23338de17923@changeid>

Quoting Douglas Anderson (2021-01-15 14:44:18)
> On an Innolux N116BCA panel that I have in front of me, sometimes HPD
> simply doesn't assert no matter how long you wait for it. As per the
> very wise advice of The IT Crowd ("Have you tried turning it off and
> on again?") it appears that power cycling is enough to kick this panel
> back into a sane state.
> 
> From tests on this panel, it appears that leaving it powered off for a
> while stimulates the problem. Adding a 6 second sleep at the start of
> panel_simple_prepare_once() makes it happen fairly reliably and, with
> this delay, I saw up to 3 retries needed sometimes. Without the 6
> second sleep, however, the panel came up much more reliably the first
> time or after only 1 retry.
> 
> While it's unknown what the problems are with this panel (and probably
> the hardware should be debugged), adding a few retries to the power on
> routine doesn't seem insane. Even if this panel's problems are
> attributed to the fact that it's pre-production and/or can be fixed,
> retries clearly can help in some cases and really don't hurt.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

Reviewed-by: Stephen Boyd <swboyd@chromium.org>

> @@ -440,6 +441,31 @@ static int panel_simple_prepare(struct drm_panel *panel)
>         return err;
>  }
>  
> +/*
> + * Some panels simply don't always come up and need to be power cycled to
> + * work properly.  We'll allow for a handful of retries.
> + */
> +#define MAX_PANEL_PREPARE_TRIES                5

Is this define used anywhere else? Feels like it would be better to
inline the constant and move the comment above the loop, but I guess
this is OK too.

> +
> +static int panel_simple_prepare(struct drm_panel *panel)
> +{
> +       int ret;
> +       int try;
> +
> +       for (try = 0; try < MAX_PANEL_PREPARE_TRIES; try++) {
> +               ret = panel_simple_prepare_once(panel);
> +               if (ret != -ETIMEDOUT)
> +                       break;
> +       }
> +
> +       if (ret == -ETIMEDOUT)
> +               dev_err(panel->dev, "Prepare timeout after %d tries\n", try);
> +       else if (try)
> +               dev_warn(panel->dev, "Prepare needed %d retries\n", try);
> +
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-01-25 20:31 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 22:44 [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 Douglas Anderson
2021-01-15 22:44 ` Douglas Anderson
2021-01-15 22:44 ` [PATCH v2 1/5] drm/panel-simple: Undo enable if HPD never asserts Douglas Anderson
2021-01-15 22:44   ` Douglas Anderson
2021-01-15 22:49   ` Stephen Boyd
2021-01-15 22:49     ` Stephen Boyd
2021-01-15 22:44 ` [PATCH v2 2/5] drm/panel-simple: Don't wait longer for HPD than hpd_absent_delay Douglas Anderson
2021-01-15 22:44   ` Douglas Anderson
2021-01-25 20:26   ` Stephen Boyd
2021-01-25 20:26     ` Stephen Boyd
2021-01-15 22:44 ` [PATCH v2 3/5] drm/panel-simple: Retry if we timeout waiting for HPD Douglas Anderson
2021-01-15 22:44   ` Douglas Anderson
2021-01-25 20:28   ` Stephen Boyd [this message]
2021-01-25 20:28     ` Stephen Boyd
2021-01-27 21:11     ` Doug Anderson
2021-01-27 21:11       ` Doug Anderson
2021-01-15 22:44 ` [PATCH v2 4/5] dt-bindings: dt-bindings: display: simple: Add N116BCA-EA1 Douglas Anderson
2021-01-15 22:44   ` Douglas Anderson
2021-01-15 22:59   ` Doug Anderson
2021-01-15 22:59     ` Doug Anderson
2021-01-25 20:29   ` Stephen Boyd
2021-01-25 20:29     ` Stephen Boyd
2021-02-08 21:50   ` Rob Herring
2021-02-08 21:50     ` Rob Herring
2021-01-15 22:44 ` [PATCH v2 5/5] drm/panel-simple: " Douglas Anderson
2021-01-15 22:44   ` Douglas Anderson
2021-01-25 20:29   ` Stephen Boyd
2021-01-25 20:29     ` Stephen Boyd
2021-03-05 15:42 ` [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1 Doug Anderson
2021-03-05 15:42   ` Doug Anderson
2021-03-10 23:25 ` Linus Walleij
2021-03-10 23:25   ` Linus Walleij
2021-03-10 23:47   ` Doug Anderson
2021-03-10 23:47     ` Doug Anderson
2021-03-11  0:57     ` Linus Walleij
2021-03-11  0:57       ` Linus Walleij
2021-03-11  1:01       ` Doug Anderson
2021-03-11  1:01         ` Doug Anderson
2021-03-11 16:20         ` Linus Walleij
2021-03-11 16:20           ` Linus Walleij
2021-03-11 16:15 ` Linus Walleij
2021-03-11 16:15   ` Linus Walleij

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=161160651990.76967.1833069919954122114@swboyd.mtv.corp.google.com \
    --to=swboyd@chromium.org \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robdclark@chromium.org \
    --cc=sam@ravnborg.org \
    --cc=thierry.reding@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.