| Message ID | 20201120102545.4047-1-tzimmermann@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/fb-helper: Various fixes and cleanups | expand |
On Fri, Nov 20, 2020 at 11:25:35AM +0100, Thomas Zimmermann wrote: > Here's a number of fb-helper patches that have been piling up recently. > > Patches 1 to 3 fix bugs that I spotted while going through the code. > Because of the way the fbdev code works, they have been avoided so far. > > Patches 4 to 10 cleanup damage handling for fbdev's shadow buffer and > fix a few issues. > > Specifically, the final patch adds locking to the code that flushes the > shadow framebuffer into BO memory. During the conversion of radeon to > generic fbdev, the question came up about interference with concurrent > modesets. If fbdev has the BO pinned in system memory for flushing while > the modeset wants to pin it to VRAM for scanout, the modeset would > most likely fail. We haven't seen that so far, but it's possible at > least. Acquiring the fb-helper lock during the flush operation prevents > concurrent modesets from taking place. > > The code has been tested with SHMEM and TTM BOs; with atomic and non- > atomic modesetting. For the whole series Acked-by: Maxime Ripard <mripard@kernel.org> Maxime
Here's a number of fb-helper patches that have been piling up recently. Patches 1 to 3 fix bugs that I spotted while going through the code. Because of the way the fbdev code works, they have been avoided so far. Patches 4 to 10 cleanup damage handling for fbdev's shadow buffer and fix a few issues. Specifically, the final patch adds locking to the code that flushes the shadow framebuffer into BO memory. During the conversion of radeon to generic fbdev, the question came up about interference with concurrent modesets. If fbdev has the BO pinned in system memory for flushing while the modeset wants to pin it to VRAM for scanout, the modeset would most likely fail. We haven't seen that so far, but it's possible at least. Acquiring the fb-helper lock during the flush operation prevents concurrent modesets from taking place. The code has been tested with SHMEM and TTM BOs; with atomic and non- atomic modesetting. [1] https://patchwork.freedesktop.org/patch/400054/?series=83765&rev=1 Thomas Zimmermann (10): drm/fb-helper: Call dirty helper after writing to fbdev drm/fb-helper: Unmap client buffer during shutdown drm/client: Depend on GEM object kmap ref-counting drm/fb-helper: Rename dirty worker to damage worker drm/fb-helper: Return early in dirty worker drm/fb-helper: Separate shadow-buffer flushing and calling dirty callback drm/fb-helper: Move damage blit code and its setup into separate routine drm/fb-helper: Restore damage area upon errors drm/fb-helper: Copy dma-buf map before flushing shadow fb drm/fb-helper: Acquire modeset lock around shadow-buffer flushing drivers/gpu/drm/drm_client.c | 4 - drivers/gpu/drm/drm_fb_helper.c | 155 +++++++++++++++++++++----------- include/drm/drm_fb_helper.h | 14 +-- 3 files changed, 108 insertions(+), 65 deletions(-) -- 2.29.2