lkml.org 
[lkml]   [2024]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] dma-buf: add DMA_BUF_IOCTL_SYNC_PARTIAL support
From

在 2024/4/9 23:34, Christian König 写道:
> Am 09.04.24 um 09:32 schrieb Rong Qianfeng:
>>
>> 在 2024/4/8 15:58, Christian König 写道:
>>> Am 07.04.24 um 09:50 schrieb Rong Qianfeng:
>>>> [SNIP]
>>>>> Am 13.11.21 um 07:22 schrieb Jianqun Xu:
>>>>>> Add DMA_BUF_IOCTL_SYNC_PARTIAL support for user to sync dma-buf with
>>>>>> offset and len.
>>>>>
>>>>> You have not given an use case for this so it is a bit hard to
>>>>> review. And from the existing use cases I don't see why this
>>>>> should be necessary.
>>>>>
>>>>> Even worse from the existing backend implementation I don't even
>>>>> see how drivers should be able to fulfill this semantics.
>>>>>
>>>>> Please explain further,
>>>>> Christian.
>>>> Here is a practical case:
>>>> The user space can allocate a large chunk of dma-buf for
>>>> self-management, used as a shared memory pool.
>>>> Small dma-buf can be allocated from this shared memory pool and
>>>> released back to it after use, thus improving the speed of dma-buf
>>>> allocation and release.
>>>> Additionally, custom functionalities such as memory statistics and
>>>> boundary checking can be implemented in the user space.
>>>> Of course, the above-mentioned functionalities require the
>>>> implementation of a partial cache sync interface.
>>>
>>> Well that is obvious, but where is the code doing that?
>>>
>>> You can't send out code without an actual user of it. That will
>>> obviously be rejected.
>>>
>>> Regards,
>>> Christian.
>>
>> In fact, we have already used the user-level dma-buf memory pool in
>> the camera shooting scenario on the phone.
>>
>> From the test results, The execution time of the photo shooting
>> algorithm has been reduced from 3.8s to 3s.
>>
>> To be honest, I didn't understand your concern "...how drivers should
>> be able to fulfill this semantics." Can you please help explain it in
>> more detail?
>
> Well you don't give any upstream driver code which actually uses this
> interface.
>
> If you want to suggest some changes to the core Linux kernel your
> driver actually needs to be upstream.
>
> As long as that isn't the case this approach here is a completely no-go.

Ok, I get it now, thanks!

Regards,

Rong Qianfeng.

>
> Regards,
> Christian.
>
>>
>> Thanks,
>>
>> Rong Qianfeng.
>>
>>>
>>>>
>>>> Thanks
>>>> Rong Qianfeng.
>>>
>

\
 
 \ /
  Last update: 2024-04-10 09:10    [W:0.154 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site