On Mon, Sep 04, 2017 at 07:06:54PM +0300, marius vlad wrote:
> There isn't any dark plot behind it.
>
> For instance, in our use case, a DPU (Display Process Unit) which has a
> blit feature (using DRM_RENDER_ALLOW) can be implemented cleanly
> in a separate driver and not being dependent on the D
From: Marius Vlad
Currently driver-specific ioctls have to be declared static and are confined to
DRM core driver. This patch series provides the means to remove those constrains
and allow to register driver-specific ioctls dynamically by keeping a list of
registered ioctls in struct drm_driver,
Indeed, we argued at first to let the driver handle the ioctls directly,
but we would like to use the DRM interface if possible.
On Mon, Sep 4, 2017 at 6:26 PM, Chris Wilson
wrote:
> Quoting Marius Vlad (2017-09-04 16:16:41)
> > From: Marius Vlad
> >
> > Currently driver-specific ioctls have to
There isn't any dark plot behind it.
For instance, in our use case, a DPU (Display Process Unit) which has a
blit feature (using DRM_RENDER_ALLOW) can be implemented cleanly
in a separate driver and not being dependent on the DRM core driver. If the
blit
feature is present/enabled, we can dynamica
Quoting Marius Vlad (2017-09-04 16:16:41)
> From: Marius Vlad
>
> Currently driver-specific ioctls have to be declared static and are confined
> to
> DRM core driver. This patch series provides the means to remove those
> constrains
> and allow to register driver-specific ioctls dynamically by
On Mon, Sep 04, 2017 at 06:16:41PM +0300, Marius Vlad wrote:
> From: Marius Vlad
>
> Currently driver-specific ioctls have to be declared static and are confined
> to
> DRM core driver. This patch series provides the means to remove those
> constrains
> and allow to register driver-specific ioc
