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
