23.06.2020 15:09, Mikko Perttunen пишет:
### DRM_TEGRA_CHANNEL_MAP
Make memory accessible by the engine while executing work on the channel.
#define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0) struct drm_tegra_channel_map { /* * [in] ID of the channel for which to map memory to. */ __u32 channel_id; /* * [in] GEM handle of the memory to map. */ __u32 handle; /* * [in] Offset in GEM handle of the memory area to map. * * Must be aligned by 4K. */ __u64 offset;
Could you please give a use-case example for this partial mapping?
I vaguely recalling that maybe it was me who suggested this in the past..
I kinda see that this could be useful for a case where userspace allocates a large chunk of memory and then performs sub-allocations in the userspace driver. But do we have a real-world example for this right now?
Please see more below.
/* * [in] Length of memory area to map in bytes. * * Must be aligned by 4K. */ __u64 length;
/* * [out] IOVA of mapped memory. Userspace can use this IOVA * directly to refer to the memory to skip using relocations. * Only available if hardware memory isolation is enabled. * * Will be set to 0xffff_ffff_ffff_ffff if unavailable. */ __u64 iova;
/* * [out] ID corresponding to the mapped memory to be used for * relocations or unmapping. */ __u32 mapping_id; /* * [in] Flags. */ __u32 flags;
__u32 reserved[6]; };
It looks to me that we actually need a bit different thing here.
This MAP IOCTL maps a portion of a GEM and then returns the mapping_id. And I think we need something more flexible that will allow us to use GEM handles for the relocation IDs, which should fit nicely with the DMA-reservations.
What about an IOCTL that wraps GEM into another GEM? We could wrap a portion of GEM_A into a GEM_B, and then map the GEM_B using the MAP IOCTL.
It could be something like this:
### DRM_TEGRA_BO_WRAP
struct drm_tegra_wrap_bo { __u32 bo_handle_wrapped; // out __u32 bo_handle; // in __u64 offset; __u64 length; };
### DRM_TEGRA_CHANNEL_MAP
struct drm_tegra_channel_map { __u32 channels_mask; __u32 mapping_id; __u32 bo_handle; __u32 flags; __u64 iova; };
===
This allows multiple mapping_ids to have the same backing GEM, so the mapping_id could be resolved into a BO during of job's submission for the DMA-reservations handling.
Also:
1. Maybe the WRAP IOCTL could be a generic GEM IOCTL?
2. I guess we could start easy without the WRAP IOCTL and add it later on once there will be a real-world need.