Re: Questions about KMS flip

[Daniel Vetter <daniel@ffwll.ch>]

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.

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.
-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.
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch