All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Clark <robdclark@gmail.com>
To: Brian Masney <masneyb@onstation.org>
Cc: Rob Clark <robdclark@chromium.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Sean Paul <sean@poorly.run>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>
Subject: Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
Date: Wed, 6 Nov 2019 08:29:45 -0800	[thread overview]
Message-ID: <CAF6AEGuEO1jg6KhOFWEMUjq4ZQy5w61dWJk6uLWRzHnMZYZv=g@mail.gmail.com> (raw)
In-Reply-To: <20191106091335.GA16729@onstation.org>

On Wed, Nov 6, 2019 at 1:13 AM Brian Masney <masneyb@onstation.org> wrote:
>
> On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney <masneyb@onstation.org> wrote:
> > > The 'pp done time out' errors go away if I revert the following three
> > > commits:
> > >
> > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > 2d99ced787e3 ("drm/msm: async commit support")
> > >
> > > I reverted the first one to fix a compiler error, and the second one so
> > > that the last patch can be reverted without any merge conflicts.
> > >
> > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> > > crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> > > buffer dance around the screen like its out of sync. I renamed
> > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> > > declaration. Here's the relevant part of what I tried:
> > >
> > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state *st
> > >
> > >  static void mdp5_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
> > >  {
> > > -       /* TODO */
> > > +       struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> > > +       struct drm_crtc *crtc;
> > > +
> > > +       for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > > +               if (!crtc->state->active)
> > > +                       continue;
> > > +
> > > +               mdp5_crtc_flush_all(crtc);
> > > +       }
> > >  }
> > >
> > > Any tips would be appreciated.
> >
> >
> > I think this is along the lines of what we need to enable async commit
> > for mdp5 (but also removing the flush from the atomic-commit path)..
> > the principle behind the async commit is to do all the atomic state
> > commit normally, but defer writing the flush bits.  This way, if you
> > get another async update before the next vblank, you just apply it
> > immediately instead of waiting for vblank.
> >
> > But I guess you are on a command mode panel, if I remember?  Which is
> > a case I didn't have a way to test.  And I'm not entirely about how
> > kms_funcs->vsync_time() should be implemented for cmd mode panels.
>
> Yes, this is a command-mode panel and there's no hardware frame counter
> available. The key to getting the display working on this phone was this
> patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
>
> > That all said, I think we should first fix what is broken, before
> > worrying about extending async commit support to mdp5.. which
> > shouldn't hit the async==true path, due to not implementing
> > kms_funcs->vsync_time().
> >
> > What I think is going on is that, in the cmd mode case,
> > mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
> > which waits for a pp-done irq regardless of whether there is a flush
> > in progress.  Since there is no flush pending, the irq never comes.
> > But the expectation is that kms_funcs->wait_flush() returns
> > immediately if there is nothing to wait for.
>
> I don't think that's happening in this case. I added some pr_info()
> statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> Here's the first two sets of messages that appear in dmesg:
>
> [   14.018907] msm fd900000.mdss: pp done time out, lm=0
> [   14.018993] request_pp_done_pending: HERE
> [   14.074208] mdp5_crtc_pp_done_irq: HERE
> [   14.074368] Console: switching to colour frame buffer device 135x120
> [   14.138938] msm fd900000.mdss: pp done time out, lm=0
> [   14.139021] request_pp_done_pending: HERE
> [   14.158097] mdp5_crtc_pp_done_irq: HERE
>
> The messages go on like this with the same pattern.
>
> I tried two different changes:
>
> 1) I moved the request_pp_done_pending() and corresponding if statement
>    from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
>
> 2) I increased the timeout in wait_for_completion_timeout() by several
>    increments; all the way to 5 seconds.

increasing the timeout won't help, because the pp-done irq has already
come at the point where we wait for it..

maybe the easy thing is just add mdp5_crtc->needs_pp, set to true
before requesting, and false when we get the irq.. and then
mdp5_crtc_wait_for_pp_done() just returns if needs_pp==false..

BR,
-R

> I haven't dug into the new code anymore.
>
> Brian

WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Brian Masney <masneyb-1iNe0GrtECGEi8DpZVb4nw@public.gmane.org>
Cc: Rob Clark <robdclark-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	freedreno
	<freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	dri-devel
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	linux-arm-msm
	<linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Sean Paul <sean-p7yTbzM4H96eqtR555YLDQ@public.gmane.org>
Subject: Re: drm/msm: 'pp done time out' errors after async commit changes
Date: Wed, 6 Nov 2019 08:29:45 -0800	[thread overview]
Message-ID: <CAF6AEGuEO1jg6KhOFWEMUjq4ZQy5w61dWJk6uLWRzHnMZYZv=g@mail.gmail.com> (raw)
In-Reply-To: <20191106091335.GA16729-1iNe0GrtECGEi8DpZVb4nw@public.gmane.org>

On Wed, Nov 6, 2019 at 1:13 AM Brian Masney <masneyb@onstation.org> wrote:
>
> On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney <masneyb@onstation.org> wrote:
> > > The 'pp done time out' errors go away if I revert the following three
> > > commits:
> > >
> > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > 2d99ced787e3 ("drm/msm: async commit support")
> > >
> > > I reverted the first one to fix a compiler error, and the second one so
> > > that the last patch can be reverted without any merge conflicts.
> > >
> > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> > > crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> > > buffer dance around the screen like its out of sync. I renamed
> > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> > > declaration. Here's the relevant part of what I tried:
> > >
> > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state *st
> > >
> > >  static void mdp5_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
> > >  {
> > > -       /* TODO */
> > > +       struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> > > +       struct drm_crtc *crtc;
> > > +
> > > +       for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > > +               if (!crtc->state->active)
> > > +                       continue;
> > > +
> > > +               mdp5_crtc_flush_all(crtc);
> > > +       }
> > >  }
> > >
> > > Any tips would be appreciated.
> >
> >
> > I think this is along the lines of what we need to enable async commit
> > for mdp5 (but also removing the flush from the atomic-commit path)..
> > the principle behind the async commit is to do all the atomic state
> > commit normally, but defer writing the flush bits.  This way, if you
> > get another async update before the next vblank, you just apply it
> > immediately instead of waiting for vblank.
> >
> > But I guess you are on a command mode panel, if I remember?  Which is
> > a case I didn't have a way to test.  And I'm not entirely about how
> > kms_funcs->vsync_time() should be implemented for cmd mode panels.
>
> Yes, this is a command-mode panel and there's no hardware frame counter
> available. The key to getting the display working on this phone was this
> patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
>
> > That all said, I think we should first fix what is broken, before
> > worrying about extending async commit support to mdp5.. which
> > shouldn't hit the async==true path, due to not implementing
> > kms_funcs->vsync_time().
> >
> > What I think is going on is that, in the cmd mode case,
> > mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
> > which waits for a pp-done irq regardless of whether there is a flush
> > in progress.  Since there is no flush pending, the irq never comes.
> > But the expectation is that kms_funcs->wait_flush() returns
> > immediately if there is nothing to wait for.
>
> I don't think that's happening in this case. I added some pr_info()
> statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> Here's the first two sets of messages that appear in dmesg:
>
> [   14.018907] msm fd900000.mdss: pp done time out, lm=0
> [   14.018993] request_pp_done_pending: HERE
> [   14.074208] mdp5_crtc_pp_done_irq: HERE
> [   14.074368] Console: switching to colour frame buffer device 135x120
> [   14.138938] msm fd900000.mdss: pp done time out, lm=0
> [   14.139021] request_pp_done_pending: HERE
> [   14.158097] mdp5_crtc_pp_done_irq: HERE
>
> The messages go on like this with the same pattern.
>
> I tried two different changes:
>
> 1) I moved the request_pp_done_pending() and corresponding if statement
>    from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
>
> 2) I increased the timeout in wait_for_completion_timeout() by several
>    increments; all the way to 5 seconds.

increasing the timeout won't help, because the pp-done irq has already
come at the point where we wait for it..

maybe the easy thing is just add mdp5_crtc->needs_pp, set to true
before requesting, and false when we get the irq.. and then
mdp5_crtc_wait_for_pp_done() just returns if needs_pp==false..

BR,
-R

> I haven't dug into the new code anymore.
>
> Brian
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno

WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com>
To: Brian Masney <masneyb@onstation.org>
Cc: Rob Clark <robdclark@chromium.org>,
	freedreno <freedreno@lists.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Sean Paul <sean@poorly.run>
Subject: Re: [Freedreno] drm/msm: 'pp done time out' errors after async commit changes
Date: Wed, 6 Nov 2019 08:29:45 -0800	[thread overview]
Message-ID: <CAF6AEGuEO1jg6KhOFWEMUjq4ZQy5w61dWJk6uLWRzHnMZYZv=g@mail.gmail.com> (raw)
Message-ID: <20191106162945.oiZGlxPDgqp84zDjeP16RUeU2ujcw047OqKtU2boawE@z> (raw)
In-Reply-To: <20191106091335.GA16729@onstation.org>

On Wed, Nov 6, 2019 at 1:13 AM Brian Masney <masneyb@onstation.org> wrote:
>
> On Tue, Nov 05, 2019 at 08:23:27AM -0800, Rob Clark wrote:
> > On Tue, Nov 5, 2019 at 2:08 AM Brian Masney <masneyb@onstation.org> wrote:
> > > The 'pp done time out' errors go away if I revert the following three
> > > commits:
> > >
> > > cd6d923167b1 ("drm/msm/dpu: async commit support")
> > > d934a712c5e6 ("drm/msm: add atomic traces")
> > > 2d99ced787e3 ("drm/msm: async commit support")
> > >
> > > I reverted the first one to fix a compiler error, and the second one so
> > > that the last patch can be reverted without any merge conflicts.
> > >
> > > I see that crtc_flush() calls mdp5_ctl_commit(). I tried to use
> > > crtc_flush_all() in mdp5_flush_commit() and the contents of the frame
> > > buffer dance around the screen like its out of sync. I renamed
> > > crtc_flush_all() to mdp5_crtc_flush_all() and removed the static
> > > declaration. Here's the relevant part of what I tried:
> > >
> > > --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
> > > @@ -171,7 +171,15 @@ static void mdp5_prepare_commit(struct msm_kms *kms, struct drm_atomic_state *st
> > >
> > >  static void mdp5_flush_commit(struct msm_kms *kms, unsigned crtc_mask)
> > >  {
> > > -       /* TODO */
> > > +       struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
> > > +       struct drm_crtc *crtc;
> > > +
> > > +       for_each_crtc_mask(mdp5_kms->dev, crtc, crtc_mask) {
> > > +               if (!crtc->state->active)
> > > +                       continue;
> > > +
> > > +               mdp5_crtc_flush_all(crtc);
> > > +       }
> > >  }
> > >
> > > Any tips would be appreciated.
> >
> >
> > I think this is along the lines of what we need to enable async commit
> > for mdp5 (but also removing the flush from the atomic-commit path)..
> > the principle behind the async commit is to do all the atomic state
> > commit normally, but defer writing the flush bits.  This way, if you
> > get another async update before the next vblank, you just apply it
> > immediately instead of waiting for vblank.
> >
> > But I guess you are on a command mode panel, if I remember?  Which is
> > a case I didn't have a way to test.  And I'm not entirely about how
> > kms_funcs->vsync_time() should be implemented for cmd mode panels.
>
> Yes, this is a command-mode panel and there's no hardware frame counter
> available. The key to getting the display working on this phone was this
> patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2bab52af6fe68c43b327a57e5ce5fc10eefdfadf
>
> > That all said, I think we should first fix what is broken, before
> > worrying about extending async commit support to mdp5.. which
> > shouldn't hit the async==true path, due to not implementing
> > kms_funcs->vsync_time().
> >
> > What I think is going on is that, in the cmd mode case,
> > mdp5_wait_flush() (indirectly) calls mdp5_crtc_wait_for_pp_done(),
> > which waits for a pp-done irq regardless of whether there is a flush
> > in progress.  Since there is no flush pending, the irq never comes.
> > But the expectation is that kms_funcs->wait_flush() returns
> > immediately if there is nothing to wait for.
>
> I don't think that's happening in this case. I added some pr_info()
> statements to request_pp_done_pending() and mdp5_crtc_pp_done_irq().
> Here's the first two sets of messages that appear in dmesg:
>
> [   14.018907] msm fd900000.mdss: pp done time out, lm=0
> [   14.018993] request_pp_done_pending: HERE
> [   14.074208] mdp5_crtc_pp_done_irq: HERE
> [   14.074368] Console: switching to colour frame buffer device 135x120
> [   14.138938] msm fd900000.mdss: pp done time out, lm=0
> [   14.139021] request_pp_done_pending: HERE
> [   14.158097] mdp5_crtc_pp_done_irq: HERE
>
> The messages go on like this with the same pattern.
>
> I tried two different changes:
>
> 1) I moved the request_pp_done_pending() and corresponding if statement
>    from mdp5_crtc_atomic_flush() and into mdp5_crtc_atomic_begin().
>
> 2) I increased the timeout in wait_for_completion_timeout() by several
>    increments; all the way to 5 seconds.

increasing the timeout won't help, because the pp-done irq has already
come at the point where we wait for it..

maybe the easy thing is just add mdp5_crtc->needs_pp, set to true
before requesting, and false when we get the irq.. and then
mdp5_crtc_wait_for_pp_done() just returns if needs_pp==false..

BR,
-R

> I haven't dug into the new code anymore.
>
> Brian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-11-06 16:29 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05  0:01 drm/msm: 'pp done time out' errors after async commit changes Brian Masney
2019-11-05  0:01 ` Brian Masney
2019-11-05  0:19 ` [Freedreno] " Rob Clark
2019-11-05  0:19   ` Rob Clark
2019-11-05 10:08   ` Brian Masney
2019-11-05 10:08     ` Brian Masney
2019-11-05 16:23     ` Rob Clark
2019-11-05 16:23       ` Rob Clark
2019-11-06  9:13       ` Brian Masney
2019-11-06  9:13         ` Brian Masney
2019-11-06 16:29         ` Rob Clark [this message]
2019-11-06 16:29           ` Rob Clark
2019-11-06 16:29           ` Rob Clark
2019-11-06 16:47           ` [Freedreno] " Jeffrey Hugo
2019-11-06 16:47             ` Jeffrey Hugo
2019-11-06 16:58             ` Rob Clark
2019-11-06 16:58               ` Rob Clark
2019-11-06 16:58               ` Rob Clark
2019-11-07 11:10               ` [Freedreno] " Brian Masney
2019-11-07 11:10                 ` Brian Masney
2019-11-07 16:16                 ` Rob Clark
2019-11-07 16:16                   ` Rob Clark
2019-11-07 17:40                   ` Jeffrey Hugo
2019-11-07 17:40                     ` Jeffrey Hugo
2019-11-08  2:03                     ` Rob Clark
2019-11-08  2:03                       ` Rob Clark
2019-11-08  2:03                       ` Rob Clark
2019-11-08 14:56                       ` [Freedreno] " Jeffrey Hugo
2019-11-08 14:56                         ` Jeffrey Hugo
2019-11-08 14:56                         ` Jeffrey Hugo
2019-11-10 13:53                         ` [Freedreno] " Brian Masney
2019-11-10 13:53                           ` Brian Masney
2019-11-10 13:53                           ` Brian Masney
2019-11-10 17:37                           ` [Freedreno] " Jeffrey Hugo
2019-11-10 17:37                             ` Jeffrey Hugo
2019-11-10 17:37                             ` Jeffrey Hugo
2019-11-11 11:38                             ` [Freedreno] " Brian Masney
2019-11-11 11:38                               ` Brian Masney
2019-11-11 11:38                               ` Brian Masney
2019-11-11 14:51                               ` [Freedreno] " Jeffrey Hugo
2019-11-11 14:51                                 ` Jeffrey Hugo
2019-11-12 10:54                                 ` Brian Masney
2019-11-12 10:54                                   ` Brian Masney
2019-11-12 10:54                                   ` Brian Masney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF6AEGuEO1jg6KhOFWEMUjq4ZQy5w61dWJk6uLWRzHnMZYZv=g@mail.gmail.com' \
    --to=robdclark@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masneyb@onstation.org \
    --cc=robdclark@chromium.org \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.