Greetings everyone,
Food for thought: Would it make sense to have the madvise ioctl as
generic DRM one?
Looking around - i915, msm & panfrost already have one and the virtio
implementation [below] seems as generic as it gets.
On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
<[email protected]> wrote:
> +#define VIRTGPU_MADV_WILLNEED 0
> +#define VIRTGPU_MADV_DONTNEED 1
> +struct drm_virtgpu_madvise {
> + __u32 bo_handle;
> + __u32 retained; /* out, non-zero if BO can be used */
> + __u32 madv;
> + __u32 pad;
This seems to be based on panfrost/msm yet names (bo_handle vs
handle), layout and documentation varies.
Why is that - copy/paste is cheap :-P
HTH
-Emil
On 3/15/22 15:43, Emil Velikov wrote:
> Greetings everyone,
>
> Food for thought: Would it make sense to have the madvise ioctl as
> generic DRM one?
> Looking around - i915, msm & panfrost already have one and the virtio
> implementation [below] seems as generic as it gets.
>
> On Mon, 14 Mar 2022 at 22:44, Dmitry Osipenko
> <[email protected]> wrote:
>
>> +#define VIRTGPU_MADV_WILLNEED 0
>> +#define VIRTGPU_MADV_DONTNEED 1
>> +struct drm_virtgpu_madvise {
>> + __u32 bo_handle;
>> + __u32 retained; /* out, non-zero if BO can be used */
>> + __u32 madv;
>> + __u32 pad;
>
> This seems to be based on panfrost/msm yet names (bo_handle vs
> handle), layout and documentation varies.
> Why is that - copy/paste is cheap :-P
Indeed, there is copy/pasting among drivers. But I'm doubtful about
making madvise a generic ioctl because some drivers already have own
ioctl for that and h/w capabilities vary, so some drivers may want to
have extra features later on and then this doesn't feel like a common
thing anymore.