Messages in this thread | | | Date | Fri, 15 Apr 2022 03:51:00 +0300 | Subject | Re: [RFC PATCH 4/6] drm/panel-edp: Take advantage of is_hpd_asserted() in struct drm_dp_aux | From | Dmitry Baryshkov <> |
| |
On 09/04/2022 05:36, Douglas Anderson wrote: > Let's add support for being able to read the HPD pin even if it's > hooked directly to the controller. This will allow us to get more > accurate delays also lets us take away the waiting in the AUX transfer > functions of the eDP controller drivers. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > drivers/gpu/drm/panel/panel-edp.c | 37 ++++++++++++++++++++++++++----- > 1 file changed, 31 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c > index 1732b4f56e38..4a143eb9544b 100644 > --- a/drivers/gpu/drm/panel/panel-edp.c > +++ b/drivers/gpu/drm/panel/panel-edp.c > @@ -417,6 +417,19 @@ static int panel_edp_get_hpd_gpio(struct device *dev, struct panel_edp *p) > return 0; > } > > +static bool panel_edp_can_read_hpd(struct panel_edp *p) > +{ > + return !p->no_hpd && (p->hpd_gpio || (p->aux && p->aux->is_hpd_asserted)); > +} > + > +static bool panel_edp_read_hpd(struct panel_edp *p) > +{ > + if (p->hpd_gpio) > + return gpiod_get_value_cansleep(p->hpd_gpio); > + > + return p->aux->is_hpd_asserted(p->aux); > +} > + > static int panel_edp_prepare_once(struct panel_edp *p) > { > struct device *dev = p->base.dev; > @@ -441,13 +454,21 @@ static int panel_edp_prepare_once(struct panel_edp *p) > if (delay) > msleep(delay); > > - if (p->hpd_gpio) { > + if (panel_edp_can_read_hpd(p)) { > if (p->desc->delay.hpd_absent) > hpd_wait_us = p->desc->delay.hpd_absent * 1000UL; > else > hpd_wait_us = 2000000; > > - err = readx_poll_timeout(gpiod_get_value_cansleep, p->hpd_gpio, > + /* > + * Extra max delay, mostly to account for ps8640. ps8640 > + * is crazy and the bridge chip driver itself has over 200 ms > + * of delay if it needs to do the pm_runtime resume of the > + * bridge chip to read the HPD. > + */ > + hpd_wait_us += 3000000;
I think this should come in a separate commit and ideally this should be configurable somehow. Other hosts wouldn't need such 'additional' delay.
With this change removed:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> + > + err = readx_poll_timeout(panel_edp_read_hpd, p, > hpd_asserted, hpd_asserted, > 1000, hpd_wait_us); > if (hpd_asserted < 0) > @@ -532,18 +553,22 @@ static int panel_edp_enable(struct drm_panel *panel) > /* > * If there is a "prepare_to_enable" delay then that's supposed to be > * the delay from HPD going high until we can turn the backlight on. > - * However, we can only count this if HPD is handled by the panel > - * driver, not if it goes to a dedicated pin on the controller. > + * However, we can only count this if HPD is readable by the panel > + * driver. > + * > * If we aren't handling the HPD pin ourselves then the best we > * can do is assume that HPD went high immediately before we were > - * called (and link training took zero time). > + * called (and link training took zero time). Note that "no-hpd" > + * actually counts as handling HPD ourselves since we're doing the > + * worst case delay (in prepare) ourselves. > * > * NOTE: if we ever end up in this "if" statement then we're > * guaranteed that the panel_edp_wait() call below will do no delay. > * It already handles that case, though, so we don't need any special > * code for it. > */ > - if (p->desc->delay.prepare_to_enable && !p->hpd_gpio && !p->no_hpd) > + if (p->desc->delay.prepare_to_enable && > + !panel_edp_can_read_hpd(p) && !p->no_hpd) > delay = max(delay, p->desc->delay.prepare_to_enable); > > if (delay)
-- With best wishes Dmitry
| |