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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
