Questions about KMS flip

[Christian König]

Am 08.11.21 um 15:59 schrieb Daniel Vetter:
> On Mon, Nov 08, 2021 at 08:44:24AM +0100, Christian König wrote:
>> Am 05.11.21 um 19:13 schrieb Daniel Vetter:
>>> On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
>>>> +Nick
>>>>
>>>> It looks to be the old drm_plane_state->fb holds that reference. See dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
>>> Yup plane state holds reference for its entire existing (well this holds
>>> in general as design principle for atomic state structs, just makes life
>>> easier). And the plane state is guaranteed to exist from when we first pin
>>> (prepare_fb plane hook) to when it's getting unpinned (cleanup_fb plane
>>> hook).
>>>
>>> Out of curiosity, what's blowing up?
>> The TTM pin count warning. What happens is that we try to free up a BO while
>> it is still being pinned.
>>
>> My best guess is that some DMA-buf client is doing something wrong, but it
>> could of course also be that the BO was pinned for scanout.
> We check in dma_buf_release whether there's anything left over, so I think
> the dma-buf scenario is rather unlikely.

That was unfortunately only added quite recently and is currently 
backported to older kernels.

> I guess worst case we could add a cookie struct to dma_buf_pin that you
> need to pass to dma_buf_unpin, and wherein we can capture a backtrace. Or
> maybe implement that in ttm even. Otherwise I don't have good ideas.

I was thinking about something similar for ttm_bo_pin().

BTW: How would I do that? I know that dump_stack() prints the current 
stack trace into the system log, but how would I get this as string?

Thanks,
Christian.

> -Daniel
>
>> Christian.
>>
>>> -Daniel
>>>
>>>> Harry
>>>>
>>>> On 2021-11-04 08:51, Christian König wrote:
>>>>> Hi guys,
>>>>>
>>>>> adding the usual suspects which might know that of hand: When we do a KMS page flip, who keeps the reference to the BO while it is scanned out?
>>>>>
>>>>> We are running into warning backtraces from TTM which look more than odd.
>>>>>
>>>>> Thanks,
>>>>> Christian.