linux-kernel - Re: [PATCH] drm/msm/dsi: Implement reset correctly

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 10 Oct 2019 14:48:57 -0400
From:   Sean Paul <sean@...rly.run>
To:     Jeffrey Hugo <jeffrey.l.hugo@...il.com>
Cc:     Rob Clark <robdclark@...il.com>, Dave Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        freedreno <freedreno@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/msm/dsi: Implement reset correctly

On Thu, Oct 10, 2019 at 2:45 PM Sean Paul <sean@...rly.run> wrote:
>
> On Wed, Oct 09, 2019 at 02:34:54PM -0700, Jeffrey Hugo wrote:
> > On msm8998, vblank timeouts are observed because the DSI controller is not
> > reset properly, which ends up stalling the MDP.  This is because the reset
> > logic is not correct per the hardware documentation.
> >
> > The documentation states that after asserting reset, software should wait
> > some time (no indication of how long), or poll the status register until it
> > returns 0 before deasserting reset.
> >
> > wmb() is insufficient for this purpose since it just ensures ordering, not
> > timing between writes.  Since asserting and deasserting reset occurs on the
> > same register, ordering is already guaranteed by the architecture, making
> > the wmb extraneous.
> >
> > Since we would define a timeout for polling the status register to avoid a
> > possible infinite loop, lets just use a static delay of 20 ms, since 16.666
> > ms is the time available to process one frame at 60 fps.
> >
> > Fixes: a689554ba6ed (drm/msm: Initial add DSI connector support)
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@...il.com>
> > ---
> >
> > Rob et al, is it possible for this to go into a 5.4-rc?

Sorry, I missed this on the first go-around, I'm Ok with this getting
into 5.4. Rob, if you're Ok with this, I can send it through -misc
unless you're planning an msm-fixes PR.

> >
> >  drivers/gpu/drm/msm/dsi/dsi_host.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > index 663ff9f4fac9..68ded9b4735d 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -986,7 +986,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
> >       wmb(); /* clocks need to be enabled before reset */
> >
> >       dsi_write(msm_host, REG_DSI_RESET, 1);
> > -     wmb(); /* make sure reset happen */
> > +     msleep(20); /* make sure reset happen */
>
> Could you please pull this out into a #define used for both in case we decide to
> tweak it? I don't want these 2 values to drift.
>

oh yeah, and with that fixed,

Reviewed-by: Sean Paul <sean@...rly.run>

> Thanks,
> Sean
>
> >       dsi_write(msm_host, REG_DSI_RESET, 0);
> >  }
> >
> > @@ -1396,7 +1396,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host *msm_host)
> >
> >       /* dsi controller can only be reset while clocks are running */
> >       dsi_write(msm_host, REG_DSI_RESET, 1);
> > -     wmb();  /* make sure reset happen */
> > +     msleep(20);     /* make sure reset happen */
> >       dsi_write(msm_host, REG_DSI_RESET, 0);
> >       wmb();  /* controller out of reset */
> >       dsi_write(msm_host, REG_DSI_CTRL, data0);
> > --
> > 2.17.1
> >
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS