Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20191009213454.32891-1-jeffrey.l.hugo@gmail.com> <20191010184544.GK85762@art_vandelay>
In-Reply-To: <20191010184544.GK85762@art_vandelay>
From:   Sean Paul <sean@poorly.run>
Date:   Thu, 10 Oct 2019 14:48:57 -0400
Message-ID: <CAMavQKJ7iMD+4a0eftNre9xMvyoZy_=sAPRAuMctX5bueugk1g@mail.gmail.com>
Subject: Re: [PATCH] drm/msm/dsi: Implement reset correctly
To:     Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Cc:     Rob Clark <robdclark@gmail.com>, Dave Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        freedreno <freedreno@lists.freedesktop.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 10, 2019 at 2:45 PM Sean Paul <sean@poorly.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@gmail.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@poorly.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