All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATH 0/4] [RFC] Support virtual DRM
@ 2021-06-21  6:43 ` Tomohito Esaki
  0 siblings, 0 replies; 61+ messages in thread
From: Tomohito Esaki @ 2021-06-21  6:43 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter, Laurent Pinchart, Kieran Bingham
  Cc: dri-devel, linux-renesas-soc, linux-kernel, devicetree,
	linux-doc, Tomohito Esaki

Hello
Sorry, there was a typo in the dri-devel mail address, so I've resend it.
---

Virtual DRM splits the overlay planes of a display controller into multiple
virtual devices to allow each plane to be accessed by each process.

This makes it possible to overlay images output from multiple processes on a
display. For example, one process displays the camera image without compositor
while another process overlays the UI.

Virtual DRM driver doesn’t directly control the display hardware and has no
access to the physical bus. Instead, the virtual DRM driver issues requests to
the standard DRM device driver (parent) when the hardware needs to be
controlled. The parent is modified to notify the virtual DRM driver of
interruptevents from the display hardware. Therefore, in order to use virtual
DRM, each DRM device driver needs to add code to support virutal DRM.

The only driver supported in this patch series is rcar-du. This patch series
is divided into multiple. The first patch adds vDRM feature to DRM, and the
second patch support vDRM for the rcar-du driver. The other patches add
documentation.

In particular, I would appreciate your advice on the following points:
* virtual DRM generalization
  I've only tested with rcar-du, is there anything I should consider to make
  virtual DRM work with other drivers?

* Integration to upstream
  I think it is a good idea to add virtual DRM to the DRM core functionality,
  but I would appreciate any suggestions on what needs to be improved for
  integration to upstream.

* dumb_create and fb_create callback
  I think that the dumb_create and fb_create callbacks need to be done by the
  parent, and it is preferable to use the parent's callbacks as they are.
  However, since the dumb buffer needs to be registered in the parent and
  the fb handle needs to be registered in the drm_file of the vDRM, the
  dumb_create callbacks from the parent driver cannot be used as is.
  Therefore, the current implementation of the dumb_create callback is
  workarround.
  What do you think is the best way to deal with this issue?


Tomohito Esaki (4):
  Add Virtual DRM device driver
  rcar-du: Add support virtual DRM device
  dt-bindings: display: Add virtual DRM
  doc-rst: Add virtual DRM documentation

 .../devicetree/bindings/display/vdrm.yaml     |  67 ++
 Documentation/gpu/drivers.rst                 |   1 +
 Documentation/gpu/vdrm.rst                    |  51 ++
 drivers/gpu/drm/Kconfig                       |   7 +
 drivers/gpu/drm/Makefile                      |   1 +
 drivers/gpu/drm/rcar-du/Kconfig               |   4 +
 drivers/gpu/drm/rcar-du/Makefile              |   1 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c        |  42 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h        |  13 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c         |  13 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h         |   3 +
 drivers/gpu/drm/rcar-du/rcar_du_vdrm.c        | 191 ++++
 drivers/gpu/drm/rcar-du/rcar_du_vdrm.h        |  67 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c         |  22 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h         |   1 +
 drivers/gpu/drm/vdrm/vdrm_api.h               |  68 ++
 drivers/gpu/drm/vdrm/vdrm_drv.c               | 859 ++++++++++++++++++
 drivers/gpu/drm/vdrm/vdrm_drv.h               |  80 ++
 18 files changed, 1491 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/vdrm.yaml
 create mode 100644 Documentation/gpu/vdrm.rst
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vdrm.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vdrm.h
 create mode 100644 drivers/gpu/drm/vdrm/vdrm_api.h
 create mode 100644 drivers/gpu/drm/vdrm/vdrm_drv.c
 create mode 100644 drivers/gpu/drm/vdrm/vdrm_drv.h

-- 
2.25.1


^ permalink raw reply	[flat|nested] 61+ messages in thread
* [PATH 0/4] [RFC] Support virtual DRM
@ 2021-06-21  6:27 Tomohito Esaki
  2021-06-21  7:10 ` Thomas Zimmermann
  2021-06-21 16:05 ` Enrico Weigelt, metux IT consult
  0 siblings, 2 replies; 61+ messages in thread
From: Tomohito Esaki @ 2021-06-21  6:27 UTC (permalink / raw)
  To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	David Airlie, Daniel Vetter, Laurent Pinchart, Kieran Bingham
  Cc: dri-devlel, linux-renesas-soc, linux-kernel, devicetree,
	linux-doc, Tomohito Esaki

Virtual DRM splits the overlay planes of a display controller into multiple
virtual devices to allow each plane to be accessed by each process.

This makes it possible to overlay images output from multiple processes on a
display. For example, one process displays the camera image without compositor
while another process overlays the UI.

Virtual DRM driver doesn’t directly control the display hardware and has no
access to the physical bus. Instead, the virtual DRM driver issues requests to
the standard DRM device driver (parent) when the hardware needs to be
controlled. The parent is modified to notify the virtual DRM driver of
interruptevents from the display hardware. Therefore, in order to use virtual
DRM, each DRM device driver needs to add code to support virutal DRM.

The only driver supported in this patch series is rcar-du. This patch series
is divided into multiple. The first patch adds vDRM feature to DRM, and the
second patch support vDRM for the rcar-du driver. The other patches add
documentation.

In particular, I would appreciate your advice on the following points:
* virtual DRM generalization
  I've only tested with rcar-du, is there anything I should consider to make
  virtual DRM work with other drivers?

* Integration to upstream
  I think it is a good idea to add virtual DRM to the DRM core functionality,
  but I would appreciate any suggestions on what needs to be improved for
  integration to upstream.

* dumb_create and fb_create callback
  I think that the dumb_create and fb_create callbacks need to be done by the
  parent, and it is preferable to use the parent's callbacks as they are.
  However, since the dumb buffer needs to be registered in the parent and
  the fb handle needs to be registered in the drm_file of the vDRM, the
  dumb_create callbacks from the parent driver cannot be used as is.
  Therefore, the current implementation of the dumb_create callback is
  workarround.
  What do you think is the best way to deal with this issue?


Tomohito Esaki (4):
  Add Virtual DRM device driver
  rcar-du: Add support virtual DRM device
  dt-bindings: display: Add virtual DRM
  doc-rst: Add virtual DRM documentation

 .../devicetree/bindings/display/vdrm.yaml     |  67 ++
 Documentation/gpu/drivers.rst                 |   1 +
 Documentation/gpu/vdrm.rst                    |  51 ++
 drivers/gpu/drm/Kconfig                       |   7 +
 drivers/gpu/drm/Makefile                      |   1 +
 drivers/gpu/drm/rcar-du/Kconfig               |   4 +
 drivers/gpu/drm/rcar-du/Makefile              |   1 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c        |  42 +
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h        |  13 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.c         |  13 +
 drivers/gpu/drm/rcar-du/rcar_du_drv.h         |   3 +
 drivers/gpu/drm/rcar-du/rcar_du_vdrm.c        | 191 ++++
 drivers/gpu/drm/rcar-du/rcar_du_vdrm.h        |  67 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c         |  22 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h         |   1 +
 drivers/gpu/drm/vdrm/vdrm_api.h               |  68 ++
 drivers/gpu/drm/vdrm/vdrm_drv.c               | 859 ++++++++++++++++++
 drivers/gpu/drm/vdrm/vdrm_drv.h               |  80 ++
 18 files changed, 1491 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/vdrm.yaml
 create mode 100644 Documentation/gpu/vdrm.rst
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vdrm.c
 create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_vdrm.h
 create mode 100644 drivers/gpu/drm/vdrm/vdrm_api.h
 create mode 100644 drivers/gpu/drm/vdrm/vdrm_drv.c
 create mode 100644 drivers/gpu/drm/vdrm/vdrm_drv.h

-- 
2.25.1


^ permalink raw reply	[flat|nested] 61+ messages in thread

end of thread, other threads:[~2021-06-25  1:55 UTC | newest]

Thread overview: 61+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-21  6:43 [PATH 0/4] [RFC] Support virtual DRM Tomohito Esaki
2021-06-21  6:43 ` Tomohito Esaki
2021-06-21  6:44 ` [PATH 1/4] drm: Add Virtual DRM device driver Tomohito Esaki
2021-06-21  6:44   ` Tomohito Esaki
2021-06-21 13:55   ` kernel test robot
2021-06-21 13:55     ` kernel test robot
2021-06-21 13:55     ` kernel test robot
2021-06-21 15:55   ` Sam Ravnborg
2021-06-22  4:10     ` Esaki Tomohito
2021-06-22  4:10       ` Esaki Tomohito
2021-06-21  6:44 ` [PATH 2/4] rcar-du: Add support virtual DRM device Tomohito Esaki
2021-06-21  6:44   ` Tomohito Esaki
2021-06-21 11:25   ` kernel test robot
2021-06-21 11:25     ` kernel test robot
2021-06-21 11:25     ` kernel test robot
2021-06-21 15:57   ` Sam Ravnborg
2021-06-21  6:44 ` [PATH 3/4] dt-bindings: display: Add virtual DRM Tomohito Esaki
2021-06-21  6:44   ` Tomohito Esaki
2021-06-21 16:03   ` Sam Ravnborg
2021-06-21 17:40   ` Rob Herring
2021-06-21 17:40     ` Rob Herring
2021-06-22  4:17     ` Esaki Tomohito
2021-06-22  4:17       ` Esaki Tomohito
2021-06-22 16:54   ` Rob Herring
2021-06-22 16:54     ` Rob Herring
2021-06-21  6:44 ` [PATH 4/4] doc-rst: Add virtual DRM documentation Tomohito Esaki
2021-06-21  6:44   ` Tomohito Esaki
2021-06-22  8:04 ` [PATH 0/4] [RFC] Support virtual DRM Simon Ser
2021-06-22  8:04   ` Simon Ser
  -- strict thread matches above, loose matches on Subject: below --
2021-06-21  6:27 Tomohito Esaki
2021-06-21  7:10 ` Thomas Zimmermann
2021-06-21  9:24   ` Maxime Ripard
2021-06-22  4:36     ` Esaki Tomohito
2021-06-22  4:36       ` Esaki Tomohito
2021-06-23 14:39       ` Maxime Ripard
2021-06-23 14:39         ` Maxime Ripard
2021-06-22  4:02   ` Esaki Tomohito
2021-06-22  4:02     ` Esaki Tomohito
2021-06-22  7:57     ` Pekka Paalanen
2021-06-22  7:57       ` Pekka Paalanen
2021-06-23  8:04       ` Michel Dänzer
2021-06-23  8:21         ` Esaki Tomohito
2021-06-22  9:12     ` Thomas Zimmermann
2021-06-22  9:12       ` Thomas Zimmermann
2021-06-21 16:05 ` Enrico Weigelt, metux IT consult
2021-06-22  4:03   ` Esaki Tomohito
2021-06-22  4:03     ` Esaki Tomohito
2021-06-22  8:12     ` Pekka Paalanen
2021-06-22  8:12       ` Pekka Paalanen
2021-06-22 19:12       ` Daniel Vetter
2021-06-22 19:12         ` Daniel Vetter
2021-06-23  6:56       ` Esaki Tomohito
2021-06-23  6:56         ` Esaki Tomohito
2021-06-23  8:39         ` Pekka Paalanen
2021-06-23  8:39           ` Pekka Paalanen
2021-06-23  9:22           ` Esaki Tomohito
2021-06-23  9:22             ` Esaki Tomohito
2021-06-23 11:41             ` Pekka Paalanen
2021-06-23 11:41               ` Pekka Paalanen
2021-06-25  1:55               ` Esaki Tomohito
2021-06-25  1:55                 ` Esaki Tomohito

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.