From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Lang Yu <Lang.Yu@amd.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 09:09:11 +0100 [thread overview]
Message-ID: <52cc2823-35b3-0cb1-2119-82a3677e9b99@gmail.com> (raw)
In-Reply-To: <YZNlE9bZSJmTvS6d@lang-desktop>
Am 16.11.21 um 09:00 schrieb Lang Yu:
> 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.
I can't fully judge because I'm not that deep with my head in the old
display code, but from a ten mile high view it sounds sane to me. Michel
what do you think?
BTW: Nicholas are there any plans to get rid of all that stuff? It would
be a really nice cleanup of rather flaky code I think.
Thanks,
Christian.
>
> Regards,
> Lang
>
>> Thanks,
>> Christian.
>>
>>> Regards,
>>> Lang
>>>
next prev parent reply other threads:[~2021-11-16 8:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <579d0f44-bb85-11b2-d326-35a0b7c5d0de@amd.com>
[not found] ` <5c242319-ade3-5621-6429-f77b17c34de5@amd.com>
[not found] ` <YYV0W1CxT5torU7u@phenom.ffwll.local>
[not found] ` <64e70779-7c33-7849-aa29-aeaee4a89005@amd.com>
[not found] ` <YYk7SkflDx8ToqYG@phenom.ffwll.local>
[not found] ` <4ba7e3f8-7956-882a-6888-57e2448b907d@amd.com>
[not found] ` <YYvIfXy9bwPokiK9@phenom.ffwll.local>
2021-11-12 12:47 ` Questions about KMS flip 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 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
2021-11-16 8:09 ` Christian König [this message]
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=52cc2823-35b3-0cb1-2119-82a3677e9b99@gmail.com \
--to=ckoenig.leichtzumerken@gmail.com \
--cc=Lang.Yu@amd.com \
--cc=Nicholas.Kazlauskas@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox