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.
