[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF6AEGuL0+3162jGb2YLsYoW-fmNsARuKcvE-+d5hRkCiicp4g@mail.gmail.com>
Date: Wed, 22 Jun 2022 10:33:33 -0700
From: Rob Clark <robdclark@...il.com>
To: Abhinav Kumar <quic_abhinavk@...cinc.com>
Cc: Stephen Boyd <swboyd@...omium.org>,
Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
patches@...ts.linux.dev, Sean Paul <sean@...rly.run>,
dri-devel <dri-devel@...ts.freedesktop.org>,
freedreno <freedreno@...ts.freedesktop.org>,
Mark Yacoub <markyacoub@...omium.org>,
Jessica Zhang <quic_jesszhan@...cinc.com>
Subject: Re: [PATCH] drm/msm/dpu: Increment vsync_cnt before waking up userspace
On Wed, Jun 22, 2022 at 10:24 AM Abhinav Kumar
<quic_abhinavk@...cinc.com> wrote:
>
>
>
> On 6/21/2022 7:38 PM, Stephen Boyd wrote:
> > The 'vsync_cnt' is used to count the number of frames for a crtc.
> > Unfortunately, we increment the count after waking up userspace via
> > dpu_crtc_vblank_callback() calling drm_crtc_handle_vblank().
> > drm_crtc_handle_vblank() wakes up userspace processes that have called
> > drm_wait_vblank_ioctl(), and if that ioctl is expecting the count to
> > increase it won't.
> >
> > Increment the count before calling into the drm APIs so that we don't
> > have to worry about ordering the increment with anything else in drm.
> > This fixes a software video decode test that fails to see frame counts
> > increase on Trogdor boards.
> >
> > Cc: Mark Yacoub <markyacoub@...omium.org>
> > Cc: Jessica Zhang <quic_jesszhan@...cinc.com>
> > Fixes: 885455d6bf82 ("drm/msm: Change dpu_crtc_get_vblank_counter to use vsync count.")
> > Signed-off-by: Stephen Boyd <swboyd@...omium.org>
>
> This is right, we should increment before drm_crtc_handle_vblank() as
> that will query the vblank counter. This also matches what we do
> downstream, hence
>
> Reviewed-by: Abhinav Kumar <quic_abhinavk@...cinc.com>
>
> One small nit though, shouldnt the fixes tag be
>
> 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
*Kinda*.. but the sw vblank counter wasn't used for reporting frame nr
to userspace until 885455d6bf82. You could possibly list both,
perhaps, but 885455d6bf82 is the important one for folks backporting
to stable kernels to be aware of
BR,
-R
>
> This code has been this way since that commit itself.
>
> > ---
> > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 3a462e327e0e..a1b8c4592943 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -1251,12 +1251,13 @@ static void dpu_encoder_vblank_callback(struct drm_encoder *drm_enc,
> > DPU_ATRACE_BEGIN("encoder_vblank_callback");
> > dpu_enc = to_dpu_encoder_virt(drm_enc);
> >
> > + atomic_inc(&phy_enc->vsync_cnt);
> > +
> > spin_lock_irqsave(&dpu_enc->enc_spinlock, lock_flags);
> > if (dpu_enc->crtc)
> > dpu_crtc_vblank_callback(dpu_enc->crtc);
> > spin_unlock_irqrestore(&dpu_enc->enc_spinlock, lock_flags);
> >
> > - atomic_inc(&phy_enc->vsync_cnt);
> > DPU_ATRACE_END("encoder_vblank_callback");
> > }
> >
> >
> > base-commit: f2906aa863381afb0015a9eb7fefad885d4e5a56
Powered by blists - more mailing lists