[Intel-xe] [PATCH 3/4] drm/doc/rfc: Mark DRM_VM_BIND as complete.

[Danilo Krummrich]

Hi Rodrigo,

On 8/31/23 21:10, Rodrigo Vivi wrote:
> On Tue, Aug 29, 2023 at 12:30:03PM -0400, Rodrigo Vivi wrote:
>> The consensus is for individual drivers VM_BIND uapis with
>> the GPUVA helpers that are already implemented and merged
>> upstream.
>>
>> The merged GPUVA documentation also establish some overall
>> rules for the locking to be followed by the drivers.
> 
> Danilo, do you agree with this?
> if nothing is missing on that front, could you please ack this patch?

I agree with the above, hence:

Acked-by: Danilo Krummrich <dakr at redhat.com>

However, the documentation below seems to be more about a common DRM_VM_BIND IOCTL?
I guess your commit refers to the end where it talks about common VM_BIND helpers.

Otherwise the patch is moving the "DRM_VM_BIND" paragraph somewhere below the
"Dev_coredump"paragraph. Is there some kind of "Done-Section" I'm missing?

- Danilo

> 
>>
>> Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
>> ---
>>   Documentation/gpu/rfc/xe.rst | 34 +++++++++++++++++-----------------
>>   1 file changed, 17 insertions(+), 17 deletions(-)
>>
>> diff --git a/Documentation/gpu/rfc/xe.rst b/Documentation/gpu/rfc/xe.rst
>> index bf60c5c82d0e..a115526c03e0 100644
>> --- a/Documentation/gpu/rfc/xe.rst
>> +++ b/Documentation/gpu/rfc/xe.rst
>> @@ -106,23 +106,6 @@ our tree. Missing Nouveau patches should *not* block Xe and any needed GPUVA
>>   related patch should be independent and present on dri-devel or acked by
>>   maintainers to go along with the first Xe pull request towards drm-next.
>>   
>> -DRM_VM_BIND
>> ------------
>> -Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to
>> -fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the
>> -development of a common new drm_infrastructure. However, the Xe team needs to
>> -engage with the community to explore the options of a common API.
>> -
>> -As a key measurable result, the DRM_VM_BIND needs to be documented in this file
>> -below, or this entire block deleted if the consensus is for independent drivers
>> -vm_bind ioctls.
>> -
>> -Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
>> -Xe merged, it is mandatory to enforce the overall locking scheme for all major
>> -structs and list (so vm and vma). So, a consensus is needed, and possibly some
>> -common helpers. If helpers are needed, they should be also documented in this
>> -document.
>> -
>>   ASYNC VM_BIND
>>   -------------
>>   Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
>> @@ -230,3 +213,20 @@ Later, when we are in-tree, the goal is to collaborate with devcoredump
>>   infrastructure with overall possible improvements, like multiple file support
>>   for better organization of the dumps, snapshot support, dmesg extra print,
>>   and whatever may make sense and help the overall infrastructure.
>> +
>> +DRM_VM_BIND
>> +-----------
>> +Nouveau, and Xe are all implementing ‘VM_BIND’ and new ‘Exec’ uAPIs in order to
>> +fulfill the needs of the modern uAPI. Xe merge should *not* be blocked on the
>> +development of a common new drm_infrastructure. However, the Xe team needs to
>> +engage with the community to explore the options of a common API.
>> +
>> +As a key measurable result, the DRM_VM_BIND needs to be documented in this file
>> +below, or this entire block deleted if the consensus is for independent drivers
>> +vm_bind ioctls.
>> +
>> +Although having a common DRM level IOCTL for VM_BIND is not a requirement to get
>> +Xe merged, it is mandatory to enforce the overall locking scheme for all major
>> +structs and list (so vm and vma). So, a consensus is needed, and possibly some
>> +common helpers. If helpers are needed, they should be also documented in this
>> +document.
>> -- 
>> 2.41.0
>>
>