The main idea behind DRM_CAP_RELEASE_FENCE is to add an additional
signaling mechanism for a pageflip completion in addition to out_fence
or DRM_EVENT_FLIP_COMPLETE event. This allows a compositor to start
a new repaint cycle with a new buffer instead of waiting for the
old buffer to be free.
Why?
So, an atomic pageflip completion indicates two things to a compositor:
- that it can repaint again and
- that the old fb is free and can be reused (that was submitted in
the previous repaint …
[View More]cycle)
Essentially, DRM_CAP_RELEASE_FENCE is about separating out the above
two assumptions. DRM_EVENT_FLIP_COMPLETE event or out_fence would
serve as a signal to repaint and newly added release_fence would
provide a way to determine when old fbs can be re-used again.
This separation is really needed when the fb(s) associated with a
pageflip are shared outside of the OS -- which is indeed the
case with Virtio-gpu, a Virtual KMS driver. The Virtio-gpu driver
runs in a Virtual Machine and can share the fb with the Host --
via Wayland UI -- in a zero-copy way. And, in this particular
environment where the Host and Guest/VM are running Wayland based
compositors, it would be desirable to have the Guest compositor's
scanout fb be placed directly on a hardware plane on the Host --
to improve performance when there are multiple Guests running.
To ensure 60 FPS and to prevent Guest and Host compositors from
using an fb at the same time, the signaling of Guest's release_fence
is tied to Host's wl_buffer_release event and DRM_EVENT_FLIP_COMPLETE/
out_fence signaling is tied to Host compositor's frame callback event.
Implementation:
Since release_fence is almost identical to out_fence, it is implemented
by making use of the existing out_fence machinery. And, although, the
drm core creates the release_fence, the Virtio-gpu driver takes care
of signaling it when it gets notified by the Host that the fb is free.
This work is based on the idea/suggestion from Simon and Pekka.
And, this patch series provides a solution for this Weston issue:
https://gitlab.freedesktop.org/wayland/weston/-/issues/514
Tested with:
Weston MR:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/668
and
Qemu patches:
https://lists.nongnu.org/archive/html/qemu-devel/2021-09/msg03463.html
Earlier version/discussion of this patch series can be found at:
https://lists.freedesktop.org/archives/dri-devel/2021-July/317672.html
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Gerd Hoffmann <kraxel(a)redhat.com>
Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com>
Cc: Simon Ser <contact(a)emersion.fr>
Cc: Michel Dänzer <michel(a)daenzer.net>
Cc: Tina Zhang <tina.zhang(a)intel.com>
Cc: Dongwon Kim <dongwon.kim(a)intel.com>
Cc: Satyeshwar Singh <satyeshwar.singh(a)intel.com>
Vivek Kasireddy (6):
drm/atomic: Move out_fence creation/setup into a separate function
drm/atomic: Add support for release_fence and its associated property
drm: Add a capability flag to support additional flip completion
signalling
drm/virtio: Probe and implement VIRTIO_GPU_F_RELEASE_FENCE feature
drm/virtio: Prepare set_scanout_blob to accept a fence
drm/virtio: Add a fence to set_scanout_blob
drivers/gpu/drm/drm_atomic_uapi.c | 100 ++++++++++++++++++-----
drivers/gpu/drm/drm_crtc.c | 2 +
drivers/gpu/drm/drm_ioctl.c | 3 +
drivers/gpu/drm/drm_mode_config.c | 6 ++
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 5 +-
drivers/gpu/drm/virtio/virtgpu_fence.c | 9 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 9 +-
drivers/gpu/drm/virtio/virtgpu_plane.c | 63 ++++++++++++--
drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +-
include/drm/drm_atomic.h | 1 +
include/drm/drm_file.h | 9 ++
include/drm/drm_mode_config.h | 15 ++++
include/uapi/drm/drm.h | 1 +
include/uapi/linux/virtio_gpu.h | 2 +
16 files changed, 200 insertions(+), 34 deletions(-)
--
2.30.2
[View Less]
The Rockchip DSI driver has had a number of bugs over time and has
usually only worked by chance. A number of users have noticed that
things regressed with commit 43c2de1002d2 ("drm/rockchip: dsi: move all
lane config except LCDC mux to bind()"), although it was fixing several
real issues of its own that had been present forever in the upstream
driver (but notably, not in the downstream/BSP driver).
Patch 1 and 2 are the most important fixes here. See their description
for more info.
While I'…
[View More]m at it, fix a few error handling and cleanup issues too.
Changes in v3:
- New patch, to fix related PM issue discovered after patch 1
Changes in v2:
- Clean up pm-runtime state in error cases.
- Correct git hash for Fixes.
Brian Norris (4):
drm/rockchip: dsi: Hold pm-runtime across bind/unbind
drm/rockchip: dsi: Reconfigure hardware on resume()
drm/rockchip: dsi: Fix unbalanced clock on probe error
drm/rockchip: dsi: Disable PLL clock on bind error
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 82 +++++++++++++------
1 file changed, 59 insertions(+), 23 deletions(-)
--
2.33.0.685.g46640cef36-goog
[View Less]
If hardware is malfunctioning (e.g., misconfigured clocks?), we can get
stuck here forever, holding various DRM locks and eventually locking up
the entire system. It's better to complain loudly and move on, than to
lock up the system.
In local tests, this operation takes less than 20ms.
Signed-off-by: Brian Norris <briannorris(a)chromium.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/…
[View More]rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ba9e14da41b4..b28ea5d6a3e2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -726,7 +726,9 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
spin_unlock(&vop->reg_lock);
- wait_for_completion(&vop->dsp_hold_completion);
+ if (!wait_for_completion_timeout(&vop->dsp_hold_completion,
+ msecs_to_jiffies(200)))
+ WARN(1, "%s: timed out waiting for DSP hold", crtc->name);
vop_dsp_hold_valid_irq_disable(vop);
--
2.33.0.882.g93a45727a2-goog
[View Less]
It adds driver for Sony Tulip Truly NT35521 5.24" 1280x720 DSI panel,
which can be found on Sony Xperia M4 Aqua phone.
Changes for v2:
- Add `port` node into bindings.
- Re-create the driver using linux-mdss-dsi-panel-driver-generator[1].
- Rename the driver to include Sony Tulip.
- Model 5V control GPIOs with regulators.
- Rename Backlight GPIO as "backlight-gpios".
[1] https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator
Shawn Guo (2):
dt-bindings: display: Add Sony …
[View More]Tulip Truly NT35521 panel support
drm/panel: Add Sony Tulip Truly NT35521 driver
.../panel/sony,tulip-truly-nt35521.yaml | 72 +++
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile | 1 +
.../panel/panel-sony-tulip-truly-nt35521.c | 552 ++++++++++++++++++
4 files changed, 635 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sony,tulip-truly-nt35521.yaml
create mode 100644 drivers/gpu/drm/panel/panel-sony-tulip-truly-nt35521.c
--
2.17.1
[View Less]