linux-kernel - Re: [PATCH 1/3] drm/panel-edp: Abstract out function to set conservative timings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJMQK-gcN06k2zFQoSYKZcxxoRvkXVqCFmFtQ0xUS=+1VG+92Q@mail.gmail.com>
Date: Mon, 25 Mar 2024 16:51:32 -0700
From: Hsin-Yi Wang <hsinyi@...omium.org>
To: Douglas Anderson <dianders@...omium.org>
Cc: dri-devel@...ts.freedesktop.org, Pin-yen Lin <treapking@...omium.org>, 
	Prahlad Kilambi <prahladk@...gle.com>, Daniel Vetter <daniel@...ll.ch>, David Airlie <airlied@...il.com>, 
	Jessica Zhang <quic_jesszhan@...cinc.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Sam Ravnborg <sam@...nborg.org>, 
	Thomas Zimmermann <tzimmermann@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] drm/panel-edp: Abstract out function to set
 conservative timings

On Mon, Mar 25, 2024 at 2:56 PM Douglas Anderson <dianders@...omiumorg> wrote:
>
> If we're using the generic "edp-panel" compatible string and we fail
> to detect an eDP panel then we fall back to conservative timings for
> powering up and powering down the panel. Abstract out the function for
> setting these timings so it can be used in future patches.
>
> No functional change expected--just code movement.
>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>

Reviewed-by: Hsin-Yi Wang <hsinyi@...omium.org>

> ---
>
>  drivers/gpu/drm/panel/panel-edp.c | 40 +++++++++++++++----------------
>  1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> index c4f851200aa2..8a19fea90ddf 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -760,6 +760,25 @@ static void panel_edp_parse_panel_timing_node(struct device *dev,
>
>  static const struct edp_panel_entry *find_edp_panel(u32 panel_id, const struct drm_edid *edid);
>
> +static void panel_edp_set_conservative_timings(struct panel_edp *panel, struct panel_desc *desc)
> +{
> +       /*
> +        * It's highly likely that the panel will work if we use very
> +        * conservative timings, so let's do that.
> +        *
> +        * Nearly all panels have a "unprepare" delay of 500 ms though
> +        * there are a few with 1000. Let's stick 2000 in just to be
> +        * super conservative.
> +        *
> +        * An "enable" delay of 80 ms seems the most common, but we'll
> +        * throw in 200 ms to be safe.
> +        */
> +       desc->delay.unprepare = 2000;
> +       desc->delay.enable = 200;
> +
> +       panel->detected_panel = ERR_PTR(-EINVAL);
> +}
> +
>  static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
>  {
>         struct panel_desc *desc;
> @@ -816,26 +835,7 @@ static int generic_edp_panel_probe(struct device *dev, struct panel_edp *panel)
>                 dev_warn(dev,
>                          "Unknown panel %s %#06x, using conservative timings\n",
>                          vend, product_id);
> -
> -               /*
> -                * It's highly likely that the panel will work if we use very
> -                * conservative timings, so let's do that. We already know that
> -                * the HPD-related delays must have worked since we got this
> -                * far, so we really just need the "unprepare" / "enable"
> -                * delays. We don't need "prepare_to_enable" since that
> -                * overlaps the "enable" delay anyway.
> -                *
> -                * Nearly all panels have a "unprepare" delay of 500 ms though
> -                * there are a few with 1000. Let's stick 2000 in just to be
> -                * super conservative.
> -                *
> -                * An "enable" delay of 80 ms seems the most common, but we'll
> -                * throw in 200 ms to be safe.
> -                */
> -               desc->delay.unprepare = 2000;
> -               desc->delay.enable = 200;
> -
> -               panel->detected_panel = ERR_PTR(-EINVAL);
> +               panel_edp_set_conservative_timings(panel, desc);
>         } else {
>                 dev_info(dev, "Detected %s %s (%#06x)\n",
>                          vend, panel->detected_panel->ident.name, product_id);
> --
> 2.44.0.396.g6e790dbe36-goog
>