> On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) <thomas...@shipmail.org> > wrote: > > Hi, Zack > > On 3/11/21 10:07 PM, Zack Rusin wrote: >>> On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) >>> <thomas...@shipmail.org> wrote: >>> >>> Hi, >>> >>> I tried latest drm-fixes today and saw a lot of these: Fallout from ttm >>> rework? >> Yes, I fixed this in d1a73c641afd2617bd80bce8b71a096fc5b74b7e it was in >> drm-misc-next in the drm-misc tree for a while but hasn’t been merged for >> 5.12. >> >> z >> > Hmm, yes but doesn't that fix trip the ttm_bo_unpin() > dma_resv_assert_held(bo->base.resv)?
No, doesn’t seem to. TBH I’m not sure why myself, but it seems to be working fine. > Taking the reservation to unpin at TTM bo free has always been awkward and > that's why vmwgfx and I guess other TTM drivers have been sloppy doing that > as TTM never cared. Perhaps TTM could change the pin_count to an atomic and > allow unlocked unpinning? still requiring the reservation lock for pin_count > transition 0->1, though. Yea, that’d probably make sense. I think in general just making sure the requirements are consistent and well documented would be great. > Also, pinning at bo creation in vmwgfx has been to do the equivalent of > ttm_bo_init_reserved() (which api was added later). Creating pinned would > make the object isolated and allowing the reserve trylock that followed to > always succeed. With the introduction of the TTM pin_count, it seems > ttm_bo_init_reserved() is used to enable pinned creation which is used to > emulate ttm_bo_init_reserved() :) Yea, we should probably port the vmwgfx code to ttm_bo_init_reserved just to be match the newly established semantics. z _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
