Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

["Christian König" <christian.koenig@amd.com>]

Am 16.10.24 um 18:43 schrieb Adrián Larumbe:
> On 16.10.2024 15:12, Christian König wrote:
>> Am 15.10.24 um 01:31 schrieb Adrián Larumbe:
>>> Doesn't make any functional difference because generic dma_fence is the
>>> first panfrost_fence structure member, but I guess it doesn't hurt either.
>> As discussed with Sima we want to push into the exactly opposite direction
>> because that requires that the panfrost module stays loaded as long as fences
>> are around.
> Does that mean in future commits the struct dma_fence_ops' .release pointer will be
> done with altogether?

Yes, exactly that's the idea.

As a first step I'm preparing patches right now to enforce using kmalloc 
instead of driver brewed approaches for dma_fence handling.

Regards,
Christian.

>
>> So clearly a NAK to this one here. Rather document on the structure that the
>> dma_fence structure must be the first member.
>>
>> Regards,
>> Christian.
>>
>>> Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
>>> ---
>>>    drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++
>>>    1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c
>>> index 5d83c6a148ec..fa219f719bdc 100644
>>> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
>>> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
>>> @@ -85,9 +85,15 @@ static const char *panfrost_fence_get_timeline_name(struct dma_fence *fence)
>>>    	}
>>>    }
>>> +static void panfrost_fence_release(struct dma_fence *fence)
>>> +{
>>> +	kfree(to_panfrost_fence(fence));
>>> +}
>>> +
>>>    static const struct dma_fence_ops panfrost_fence_ops = {
>>>    	.get_driver_name = panfrost_fence_get_driver_name,
>>>    	.get_timeline_name = panfrost_fence_get_timeline_name,
>>> +	.release = panfrost_fence_release,
>>>    };
>>>    static struct dma_fence *panfrost_fence_create(struct panfrost_device *pfdev, int js_num)