Am 12.03.21 um 00:02 schrieb Zack Rusin:
On Mar 11, 2021, at 17:35, Thomas Hellström (Intel) <thomas_os@xxxxxxxxxxxx> 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_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.
Mhm, crap. I hoped that you would have the same issue as radeon somehow
and could help with debugging.
Please make sure the patch is pushed to drm-misc-fixes so that it ends
up fixed in 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.
Yeah, I stumbled over that at well during one of the cleanups and
considered changing the implementation. But then it got lost in all the
rework.
Christian.
z
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
