All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lang Yu <Lang.Yu@amd.com>
To: Christian Koenig <ckoenig.leichtzumerken@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Michel DDDnzer <michel@daenzer.net>,
	"Kazlauskas, Nicholas" <Nicholas.Kazlauskas@amd.com>,
	amd-gfx list <amd-gfx@lists.freedesktop.org>,
	Christian KKKnig <christian.koenig@amd.com>
Subject: Re: Questions about KMS flip
Date: Tue, 16 Nov 2021 16:00:19 +0800	[thread overview]
Message-ID: <YZNlE9bZSJmTvS6d@lang-desktop> (raw)
In-Reply-To: <391ee32e-f1b1-d92b-c9f3-17dbc0a9d690@gmail.com>

On Tue, Nov 16, 2021 at 08:14:08AM +0100, Christian KKKnig wrote:
> Am 16.11.21 um 04:27 schrieb Lang Yu:
> > On Mon, Nov 15, 2021 at 01:04:15PM +0100, Michel DDDnzer wrote:
> > > [SNIP]
> > > > Though a single call to dce_v*_0_crtc_do_set_base() will
> > > > only pin the BO, I found it will be unpinned in next call to
> > > > dce_v*_0_crtc_do_set_base().
> > > Yeah, that's the normal case when the new BO is different from the old one.
> > > 
> > > To catch the case I described, try something like
> > > 
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > > 
> > > index 18a7b3bd633b..5726bd87a355 100644
> > > 
> > > --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > > 
> > > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> > > 
> > > @@ -1926,6 +1926,7 @@ static int dce_v11_0_crtc_do_set_base(struct drm_crtc *crtc,
> > > 
> > >                  return r;
> > > 
> > > 
> > > 
> > >          if (!atomic) {
> > > 
> > > +               WARN_ON_ONCE(target_fb == fb);
> > > 
> > >                  r = amdgpu_bo_pin(abo, AMDGPU_GEM_DOMAIN_VRAM);
> > > 
> > >                  if (unlikely(r != 0)) {
> > > 
> > >                          amdgpu_bo_unreserve(abo);
> > > 
> > I did some tests, the warning can be triggered.
> > 
> > pin/unpin operations in *_crtc_do_set_base() and
> > amdgpu_display_crtc_page_flip_target() are mixed.
> 
> Ok sounds like we narrowed down the root cause pretty well.
> 
> Question is now how can we fix this? Just not pin the BO when target_fb ==
> fb?

That worked. I did a few simple tests and didn't observe ttm_bo_release warnings 
any more.

The pin/unpin logic,

1, fist crtc_mode_set, dce_v*_0_crtc_do_set_base() pins crtc->primary->fb(new),
old_fb is NULL.

2, second crtc_mode_set, dce_v*_0_crtc_do_set_base() pins crtc->primary->fb(new),
unpins old fb.

3, amdgpu_display_crtc_page_flip_target() pin/unpin operations.

4, third crtc_mode_set, dce_v*_0_crtc_do_set_base() pins crtc->primary->fb(new),
unpins old fb (it is pinned in last call to amdgpu_display_crtc_page_flip_target)

5, amdgpu_display_crtc_page_flip_target() pin/unpin operations.

.....

x, reboot, amdgpu_display_suspend_helper() is called, the last pinned fb was unpinned.

And I didn't observe amdgpu_bo_unpin() in dce_v*_0_crtc_disable() is called.

If the logic is wrong, please correct me.

Regards,
Lang

> Thanks,
> Christian.
> 
> > 
> > Regards,
> > Lang
> > 
> 

  reply	other threads:[~2021-11-16  8:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 12:51 Questions about KMS flip Christian König
2021-11-04 16:44 ` Harry Wentland
2021-11-05 12:20   ` Ville Syrjälä
2021-11-05 18:13   ` Daniel Vetter
2021-11-08  7:44     ` Christian König
2021-11-08 14:59       ` Daniel Vetter
2021-11-10 10:18         ` Christian König
2021-11-10 13:26           ` Daniel Vetter
2021-11-12 12:47             ` Christian König
2021-11-12 12:47               ` Christian König
2021-11-12 14:29               ` Michel Dänzer
2021-11-12 14:30                 ` Michel Dänzer
2021-11-12 15:03                   ` Christian König
2021-11-12 16:10                     ` Michel Dänzer
2021-11-15  6:41                       ` Lang Yu
2021-11-15  6:41                         ` Lang Yu
2021-11-15  8:38                         ` Michel Dänzer
2021-11-15  9:04                           ` Lang Yu
2021-11-15  9:49                             ` Michel Dänzer
2021-11-15 11:31                               ` Lang Yu
2021-11-15 12:04                                 ` Michel Dänzer
2021-11-16  3:27                                   ` Lang Yu
2021-11-16  7:14                                     ` Christian König
2021-11-16  8:00                                       ` Lang Yu [this message]
2021-11-16  8:09                                         ` Christian König
2021-11-16 14:10                                           ` Alex Deucher
2021-11-16 14:50                                             ` Michel Dänzer
2021-11-15  7:25                       ` Christian König

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=YZNlE9bZSJmTvS6d@lang-desktop \
    --to=lang.yu@amd.com \
    --cc=Nicholas.Kazlauskas@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michel@daenzer.net \
    /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.