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@ffwll.ch wrote:
On Mon, Sep 04, 2017 at 06:16:41PM +0300, Marius Vlad wrote:
From: Marius Vlad marius.vlad0@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