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

[Dmitry Osipenko <digetx@gmail.com>]

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