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

[Nikita Travkin <nikita@trvn.ru>]

Doug Anderson писал(а) 13.04.2023 01:22:
> Hi,
> 
> On Sat, Apr 8, 2023 at 1:20 AM Nikita Travkin <nikita@trvn.ru> 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@trvn.ru>
>> ---
>> 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@mail.gmail.com/
>> ---
>>  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.
> 

This does sound reasonable indeed, I didn't think to add it
conditionally because, looking at the current users of
wait_hpd_asserted, they will first try the "no-hpd" paths
and will only call the bridge when they think it's on the
bridge to wait.

Thus, if DT is modeled properly - Panel has no-hpd or a gpio,
wait_hpd_asserted will never be called anyway. Other bridges
seem to also unconditionally enable the method.

For this to be a trouble, a panel driver has to be "broken"
with some form of calling wait_hpd_asserted despite knowing
the HPD line is not hooked up...

So I feel like guarding the wait_hpd_asserted for no-hpd
users should not actually change much, but if you think
I should add the check anyway, please let me know.

Thanks for taking a look!
Nikita

> -Doug