All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shashank Sharma <shashank.sharma@amd.com>
To: "Felix Kuehling" <felix.kuehling@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Yadav, Arvind" <arvyadav@amd.com>,
	"Alex Deucher" <alexdeucher@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>,
	amd-gfx@lists.freedesktop.org, arvind.yadav@amd.com,
	arunpravin.paneerselvam@amd.com
Subject: Re: [RFC 3/7] drm/amdgpu: Create MQD for userspace queue
Date: Wed, 4 Jan 2023 15:41:30 +0100	[thread overview]
Message-ID: <38e4d463-9595-02f4-d79f-bb165e2eaa38@amd.com> (raw)
In-Reply-To: <b4a601d4-4d08-fea7-5eaa-772194fd6b1a@amd.com>


On 04/01/2023 15:35, Felix Kuehling wrote:
> Am 2023-01-04 um 04:23 schrieb Shashank Sharma:
>>
>> On 04/01/2023 10:17, Christian König wrote:
>>> Am 04.01.23 um 10:13 schrieb Shashank Sharma:
>>>>
>>>> On 04/01/2023 10:10, Christian König wrote:
>>>>> Am 04.01.23 um 07:21 schrieb Yadav, Arvind:
>>>>>>
>>>>>> On 1/4/2023 12:07 AM, Felix Kuehling wrote:
>>>>>>> Am 2023-01-03 um 04:36 schrieb Shashank Sharma:
>>>>>>>>>> /*MQD struct for usermode Queue*/
>>>>>>>>>> +struct amdgpu_usermode_queue_mqd
>>>>>>>>> This is specific to GC 11.  Every IP and version will have its 
>>>>>>>>> own MQD
>>>>>>>>> format.  That should live in the IP specific code, not the 
>>>>>>>>> generic
>>>>>>>>> code.  We already have the generic MQD parameters that we need 
>>>>>>>>> from
>>>>>>>>> the userq IOCTL.
>>>>>>>>
>>>>>>>> Noted, we can separate out the generic parameters from gen 
>>>>>>>> specific parameter, and will try to wrap it around the generic 
>>>>>>>> structure.
>>>>>>>>
>>>>>>>> - Shashank
>>>>>>>
>>>>>>> Is there a reason why you can't use "struct v11_compute_mqd" 
>>>>>>> from v11_structs.h?
>>>>>>
>>>>>> Hi Felix,
>>>>>>
>>>>>> Yes,  V11_compute_mqd does not have these below member which is 
>>>>>> needed for usermode queue.
>>>>>>
>>>>>>     uint32_t shadow_base_lo; // offset: 0  (0x0)
>>>>>>     uint32_t shadow_base_hi; // offset: 1  (0x1)
>>>>>>     uint32_t gds_bkup_base_lo ; // offset: 2  (0x2)
>>>>>>     uint32_t gds_bkup_base_hi ; // offset: 3  (0x3)
>>>>>>     uint32_t fw_work_area_base_lo; // offset: 4  (0x4)
>>>>>>     uint32_t fw_work_area_base_hi; // offset: 5  (0x5)
>>>>>>     uint32_t shadow_initialized; // offset: 6  (0x6)
>>>>>>     uint32_t ib_vmid; // offset: 7  (0x7)
>>>>>>
>>>>>> So we had to add new MQD structs.
>>>>>
>>>>> Would it make more sense to update the existing MQD structures 
>>>>> than adding new ones?
>>>>>
>>>> Imo, It might be a bit complicated in the bring-up state, but we 
>>>> can take a note of converting this structure into a union of two, 
>>>> or may be renaming it into a superset structure.
>>>
>>> Union? Does that mean we have stuff which is individual for both 
>>> versions of the struct?
>> So far it seems like Gfx MQD structure is a superset of two, but we 
>> have not compared them neck-to-neck yet, hence I feel like we can 
>> defer this task for sometime (but add into to-do list).
>
> v11_gfx_mqd has these fields reserved. Updating the definition with 
> the fields you need should not be a problem. v11_gfx_mqd is already 
> used in gfx_v11_0.c.
>
> The firmware shouldn't care much whether a queue is a kernel mode 
> queue or a user mode queue. The MQD layout should be the same. So 
> having two different structure definitions in two different places 
> doesn't make sense. I don't think it's wise to leave this for cleanup 
> later. That would only cause churn and ultimately more work than doing 
> the right thing in the first place.
>
> Regards,
>   Felix
>
Hey Felix, noted, we will try to reuse this same structure.

- Shashank

>
>
>>>
>>> BTW: Could we drop the "// offset:" stuff? This could cause problems 
>>> with automated checkers.
>>
>> Sure, we will do it.
>>
>> - Shashank
>>
>>>
>>> Christian.
>>>
>>>>
>>>> - Shashank
>>>>
>>>>> Regards,
>>>>> Christian.
>>>>>
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> ~arvind
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>   Felix
>>>>>>>
>>>>>
>>>

  parent reply	other threads:[~2023-01-04 14:41 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-23 19:36 [RFC 0/7] RFC: Usermode queue for AMDGPU driver Shashank Sharma
2022-12-23 19:36 ` [RFC 1/7] drm/amdgpu: UAPI for user queue management Shashank Sharma
2022-12-24 20:20   ` Bas Nieuwenhuizen
2022-12-27 16:58     ` Alex Deucher
2023-01-02 11:27       ` Christian König
2023-01-03 19:51         ` Alex Deucher
2023-01-02 13:26   ` Christian König
2023-01-03 14:23     ` Alex Deucher
2023-01-03 18:29   ` Felix Kuehling
2023-01-03 19:17     ` Liu, Shaoyun
2023-01-03 19:22       ` Alex Deucher
2023-01-03 19:25         ` Liu, Shaoyun
2023-01-03 19:52           ` Alex Deucher
2023-01-03 20:05             ` Felix Kuehling
2023-01-03 19:18     ` Alex Deucher
2022-12-23 19:36 ` [RFC 2/7] drm/amdgpu: Add usermode queue for gfx work Shashank Sharma
2022-12-24 18:19   ` Oded Gabbay
2022-12-26 10:34     ` Shashank Sharma
2022-12-25 15:44   ` Christian König
2022-12-26 10:41     ` Shashank Sharma
2023-01-02 12:39       ` Christian König
2023-01-03  9:12         ` Shashank Sharma
2023-01-03  9:15           ` Christian König
2023-01-03  9:22             ` Shashank Sharma
2023-01-03  9:35               ` Christian König
2023-01-03 14:34                 ` Alex Deucher
2023-01-03 14:50                   ` Christian König
2022-12-29 17:41   ` Alex Deucher
2023-01-02 13:53     ` Christian König
2023-01-03  9:32       ` Shashank Sharma
2023-01-03  9:16     ` Shashank Sharma
2023-01-04  8:55   ` Zhu, Jiadong
2023-01-04  8:58     ` Shashank Sharma
2022-12-23 19:36 ` [RFC 3/7] drm/amdgpu: Create MQD for userspace queue Shashank Sharma
2022-12-29 17:47   ` Alex Deucher
2023-01-03  9:36     ` Shashank Sharma
2023-01-03 18:37       ` Felix Kuehling
2023-01-04  6:21         ` Yadav, Arvind
2023-01-04  9:10           ` Christian König
2023-01-04  9:13             ` Shashank Sharma
2023-01-04  9:17               ` Christian König
2023-01-04  9:23                 ` Shashank Sharma
2023-01-04 14:35                   ` Felix Kuehling
2023-01-04 14:38                     ` Yadav, Arvind
2023-01-04 14:41                     ` Shashank Sharma [this message]
2023-01-04 14:28           ` Alex Deucher
2022-12-23 19:36 ` [RFC 4/7] drm/amdgpu: Allocate doorbell slot for user queue Shashank Sharma
2022-12-29 17:50   ` Alex Deucher
2023-01-03  9:37     ` Shashank Sharma
2022-12-23 19:36 ` [RFC 5/7] drm/amdgpu: Create context for usermode queue Shashank Sharma
2022-12-29 17:54   ` Alex Deucher
2023-01-03  9:40     ` Shashank Sharma
2023-01-03 14:48       ` Alex Deucher
2022-12-23 19:36 ` [RFC 6/7] drm/amdgpu: Map userqueue into HW Shashank Sharma
2022-12-29 17:51   ` Alex Deucher
2023-01-03  9:38     ` Shashank Sharma
2022-12-23 19:36 ` [RFC 7/7] drm/amdgpu: Secure semaphore for usermode queue Shashank Sharma
2022-12-25 10:07   ` Zhang, Yifan
2022-12-27  9:32     ` Arunpravin Paneer Selvam
2022-12-29 18:02 ` [RFC 0/7] RFC: Usermode queue for AMDGPU driver Alex Deucher
2023-01-03  9:43   ` Shashank Sharma
2023-01-03  9:47     ` Christian König
2023-01-03 10:00       ` Shashank Sharma
2023-01-03 10:02         ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38e4d463-9595-02f4-d79f-bb165e2eaa38@amd.com \
    --to=shashank.sharma@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=arunpravin.paneerselvam@amd.com \
    --cc=arvind.yadav@amd.com \
    --cc=arvyadav@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=felix.kuehling@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.