Hi, Zack
On 3/11/21 10:07 PM, Zack Rusin wrote:
On Mar 11, 2021, at 05:46, Thomas Hellström (Intel) <thomas_os@xxxxxxxxxxxx> 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)?
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.
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() :)
/Thomas
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
