Hi, On Thu, Apr 13, 2023 at 12:10 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Wed, Apr 12, 2023 at 9:19 PM Nikita Travkin <nikita@xxxxxxx> wrote: > > > > Doug Anderson писал(а) 13.04.2023 01:22: > > > 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. > > > > > > > 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. > > Ah, true, it shouldn't actually matter. I guess I still like it > slightly better with the extra check but not enough that I'll insist > on it. Thus: > > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > > I can commit this to drm-misc-next, but I'll plan to wait ~1 week to > see if anyone else has any comments about it. Landed to drm-misc-next: 34c1aeb579dd drm/bridge: ti-sn65dsi86: Implement wait_hpd_asserted
