linux-kernel - Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement wait_hpd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=V3+i51BQ3pE60-e=wU0ehTFx6C6qU7-7ghbyvon7=pCQ@mail.gmail.com>
Date:   Thu, 20 Apr 2023 12:23:56 -0700
From:   Doug Anderson <dianders@...omium.org>
To:     Nikita Travkin <nikita@...n.ru>
Cc:     andrzej.hajda@...el.com, neil.armstrong@...aro.org,
        rfoss@...nel.org, airlied@...il.com, daniel@...ll.ch,
        Laurent.pinchart@...asonboard.com, jonas@...boo.se,
        jernej.skrabec@...il.com, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/bridge: ti-sn65dsi86: Implement wait_hpd_asserted

Hi,

On Thu, Apr 13, 2023 at 12:10 PM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Wed, Apr 12, 2023 at 9:19 PM Nikita Travkin <nikita@...n.ru> wrote:
> >
> > Doug Anderson писал(а) 13.04.2023 01:22:
> > > Hi,
> > >
> > > On Sat, Apr 8, 2023 at 1:20 AM Nikita Travkin <nikita@...n.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@...n.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.
>
> 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@...omium.org>
>
> 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