Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement wait_hpd_asserted

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sat, Apr 8, 2023 at 1:20 AM Nikita Travkin <nikita@xxxxxxx> wrote:
>
> This bridge doesn't actually implement HPD due to it being way too slow
> but instead expects the panel driver to wait enough to assume HPD is
> asserted. However some panels (such as the generic 'edp-panel') expect
> the bridge to deal with the delay and pass maximum delay to the aux
> instead.
>
> In order to support such panels, add a dummy implementation of wait
> that would just sleep the maximum delay and assume no failure has
> happened.
>
> Signed-off-by: Nikita Travkin <nikita@xxxxxxx>
> ---
> This was suggested in [1] to make sure DT users can be semantically
> correct (not adding no-hpd when the line is actually there) while
> still using a hard delay to be faster than waiting the long debounce
> time.
>
> [1] - https://lore.kernel.org/all/CAD=FV=VR7sKsquE25eF7joc7gPApu-vqwduZzjE=wFCoXjMYnQ@xxxxxxxxxxxxxx/
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 7a748785c545..260cad1fd1da 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -618,6 +618,24 @@ static ssize_t ti_sn_aux_transfer(struct drm_dp_aux *aux,
>         return len;
>  }
>
> +static int ti_sn_aux_wait_hpd_asserted(struct drm_dp_aux *aux, unsigned long wait_us)
> +{
> +       /*
> +        * The HPD in this chip is a bit useless (See comment in
> +        * ti_sn65dsi86_enable_comms) so if our driver is expected to wait
> +        * for HPD, we just assume it's asserted after the wait_us delay.
> +        *
> +        * In case we are asked to wait forever (wait_us=0) take conservative
> +        * 500ms delay.
> +        */
> +       if (wait_us == 0)
> +               wait_us = 500000;
> +
> +       usleep_range(wait_us, wait_us + 1000);
> +
> +       return 0;
> +}
> +
>  static int ti_sn_aux_probe(struct auxiliary_device *adev,
>                            const struct auxiliary_device_id *id)
>  {
> @@ -627,6 +645,7 @@ static int ti_sn_aux_probe(struct auxiliary_device *adev,
>         pdata->aux.name = "ti-sn65dsi86-aux";
>         pdata->aux.dev = &adev->dev;
>         pdata->aux.transfer = ti_sn_aux_transfer;
> +       pdata->aux.wait_hpd_asserted = ti_sn_aux_wait_hpd_asserted;

This looks reasonable to me, but I think you only want this
implementation if the "no-hpd" property _isn't_ present. In other
words:

if (!of_property_read_bool(np, "no-hpd"))
  pdata->aux.wait_hpd_asserted = ti_sn_aux_wait_hpd_asserted;

Essentially:

* If "no-hpd" is present in ti-sn65dsi86 then we'll assume that HPD is
handled by the panel driver via a GPIO or a "no-hpd" there (which will
cause the panel driver to wait the maximum duration).

* If "no-hpd" isn't present in ti-sn65dsi86 then HPD is actually
hooked up and thus the panel driver _won't_ handle it.

Does that seem right? Presumably this should be explained by comments.

-Doug




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux