[PATCH 0/4] RFC: drm: Allow driver-specific ioctls to be registered

[Daniel Vetter]

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 DRM core driver. If the
> blit
> feature is present/enabled, we can dynamically register the ioctls at
> run-time.
> 
> There are other means to mitigate this, but we thought this would
> beneficial
> to other drivers as well.
> 
> Other SoC drivers like Exynos (G2D) provide this feature by inventing it's
> own sub-driver
> system/layer and have all the sub-drivers built-in.

With all the desktop drivers we simply have a feature flag that describes
which engines are there, and use that to filter out invalid operations.

On arm-soc with it's love for a metric ton of DT tons for everything you
should be able to do the same, it's just a bit more work to get all the of
nodes you need.

If you want a separate driver, imo register a full separate drm_device
instance with everything. But imo the arm-soc design love for heavily
split up drivers really doesn't make much sense, at least for IP all
designed by the same company. Imo look at msm or etnaviv for what I think
are reasonable drm drivers for arm-soc platforms, don't look at exynos.
-Daniel

> 
> 
> On Mon, Sep 4, 2017 at 6:25 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> > On Mon, Sep 04, 2017 at 06:16:41PM +0300, Marius Vlad wrote:
> > > From: Marius Vlad <marius.vlad0 at gmail.com>
> > >
> > > 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, then each component of the
> > driver can
> > > then register its own specific ioctls using this interface.
> > >
> > > The driver must assign ioctl_register/ioctl_deregister in
> > > its drm_driver structure in order to make use of it.
> > >
> > > While SoC drivers benefit the most from this approach (by not polluting
> > DRM core
> > > driver and allowing sub drivers to implement and register driver-specific
> > > ioctls dynamically), further patches shows how easy is to convert
> > drm/i915 to
> > > this approach by registering GEM and perf ioctls separately.
> >
> > What exactly is the problem you're trying to solve?
> >
> > This awefully smells like some neat way to make loading driver modules for
> > blob userspace easy ... And I can't think of any other thing you could use
> > this for.
> >
> > And even for the blob userspace use case: Create a separate drm driver
> > instance, share buffers and fences with dma_buf and dma_fence, and you're
> > all good. I really have no idea what this is good for, but maybe I'm
> > missing something?
> > -Daniel
> >
> > >
> > > Marius Vlad (4):
> > >   drm/gpu: Support registering driver-specific ioctls dynamically
> > >   drm/i915: Convert i915 to use ioctl_register/ioctl_deregister.
> > >   drm/i915: Register perf_ ioctls directly in i915_perf file.
> > >   drm/i915: Register GEM ioctls directly in i915_gem file.
> > >
> > >  drivers/gpu/drm/drm_drv.c        |   1 +
> > >  drivers/gpu/drm/drm_ioctl.c      |  99 ++++++++++++++++++++++++++++++
> > ++++--
> > >  drivers/gpu/drm/i915/i915_drv.c  | 107 +++++++++++++++---------------
> > ---------
> > >  drivers/gpu/drm/i915/i915_gem.c  |  52 +++++++++++++++++++
> > >  drivers/gpu/drm/i915/i915_perf.c |  21 ++++++++
> > >  include/drm/drm_drv.h            |  34 +++++++++++++
> > >  include/drm/drm_ioctl.h          |   6 +++
> > >  7 files changed, 249 insertions(+), 71 deletions(-)
> > >
> > > --
> > > 2.9.3
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> >
> 
> 
> 
> -- 
> Marius Vlad

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch