[PATCH 1/3] drm/panel-edp: Abstract out function to set conservative timings
Hsin-Yi Wang
hsinyi at chromium.org
Mon Mar 25 23:51:32 UTC 2024
On Mon, Mar 25, 2024 at 2:56 PM Douglas Anderson <dianders at chromium.org> 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 at chromium.org>
Reviewed-by: Hsin-Yi Wang <hsinyi at chromium.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
>
More information about the dri-devel
mailing list