On 5/18/26 16:15, Boris Brezillon wrote:
On Mon, 18 May 2026 14:18:41 +0200 Christian König christian.koenig@amd.com wrote:
On 5/18/26 11:14, Boris Brezillon wrote:
Hi Christian,
On Mon, 18 May 2026 09:10:23 +0200 Christian König christian.koenig@amd.com wrote:
On 5/13/26 18:58, Boris Brezillon wrote:
When used without a context, dma_resv are no different from regular locks. Define guards so we can use the guard-syntactic sugars for explicit/implicit scoped locks.
Signed-off-by: Boris Brezillon boris.brezillon@collabora.com
Reviewed-by: Christian König christian.koenig@amd.com
How do you want to upstream it? My preference would be drm-misc-next, but I think I can live with a panthor specific branch as well.
Everything Panthor related goes through drm-misc-next, so drm-misc-next also has my preference ;-). But I'd like to wait for more feedback on the other drm patches, and there are a few things I need to address in the panthor patches anyway, so it's likely to take a couple more weeks for this series to hit the drm-misc tree, unless you have a good reason to fast-track this specific patch.
Well the DMA-buf code itself uses dma_resv_lock/unlock
There's no use in dma-resv.c that can be converted to guards. I gave dma-buf.c a try, but just like for panthor, I don't really like the fact it's halfway through (other locks still use manual locking), so I'd be tempted to convert everything at once for consistency. If you're fine with that, I can give this a try.
Well depends on what everything means. I would only convert dma-buf.c in one patch and nothing else.
and obviously has test cases for all the different variants.
Looks like the test cases all validate that dma_resv_lock(x, NULL) returns 0. If I were to convert those to guard(dma_resv)(), these checks would be gone. Is that okay with you?
Ah, good point. No we need to check the return value here.
So keep the test cases as they are, they basically make sure that we can actually use the guards when there is no ticket.
Thanks, Christian.