Re: [RFC] Host1x/TegraDRM UAPI (drm_tegra_submit_relocation)

From: Mikko Perttunen <cyndis@kapsi.fi>
To: Dmitry Osipenko <digetx@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Jon Hunter <jonathanh@nvidia.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	sumit.semwal@linaro.org, gustavo@padovan.org
Cc: "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	talho@nvidia.com, bhuntsman@nvidia.com,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC] Host1x/TegraDRM UAPI (drm_tegra_submit_relocation)
Date: Fri, 26 Jun 2020 12:01:00 +0300	[thread overview]
Message-ID: <9486b5c7-7588-34fd-bb60-a3b0f252f113@kapsi.fi> (raw)
In-Reply-To: <eb3cac23-cd8c-732b-684c-c2d531de00a2@gmail.com>

On 6/26/20 1:50 AM, Dmitry Osipenko wrote:
> 25.06.2020 12:27, Mikko Perttunen пишет:
>> On 6/25/20 1:33 AM, Dmitry Osipenko wrote:
>>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>>> struct drm_tegra_submit_relocation {
>>>>           /* [in] Index of GATHER or GATHER_UPTR command in commands. */
>>>>           __u32 gather_command_index;
>>>>
>>>>           /*
>>>>            * [in] Mapping handle (obtained through CHANNEL_MAP) of the
>>>> memory
>>>>            *   the address of which will be patched in.
>>>>            */
>>>>           __u32 mapping_id;
>>>>
>>>>           /*
>>>>            * [in] Offset in the gather that will be patched.
>>>>            */
>>>>           __u64 gather_offset;
>>>>
>>>>           /*
>>>>            * [in] Offset in target buffer whose paddr/IOVA will be
>>>> written
>>>>            *   to the gather.
>>>>            */
>>>>           __u64 target_offset;
>>>>
>>>>           /*
>>>>            * [in] Number of bits the resulting address will be logically
>>>>            *   shifted right before writing to gather.
>>>>            */
>>>>           __u32 shift;
>>>>
>>>>           __u32 reserved[1];
>>>> };
>>>
>>> We will also need read/write direction flag here for the
>>> DMA-reservations set up, it will be used for the implicit BO fencing by
>>> the job's scheduler.
>>>
>>
>> Ideally on newer chips with context isolation, we no longer know what
>> DMA-BUFs are being used by the job at submit time - they would just be
>> pointers after being MAPped.
> 
> The DMA-BUFs themselves shouldn't be needed, but GEMs should.

Yes, I meant to say GEM instead of DMA-BUF.

> 
>> Do you know how other GPUs deal with DMA reservations - I expect
>> separate MAP and SUBMIT steps would be pretty common?
> 
> I can't instantly recall what other drivers do, could be worthwhile to
> take a closer look.

I'll see if I can find some similar situations in other drivers.

Mikko

> 
>> Do you have to
>> pass the DMA-BUF to both steps (i.e. do IOMMU mapping during MAP, and
>> manage reservations at SUBMIT)?
> 
> Yes, this sounds good to me if DMA-BUF part is replaced with a GEM.
> 
> Please see my other reply regarding the MAP IOCTL where I'm suggesting
> to back mapping IDs with a GEM.
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel