Hi Am 03.07.19 um 21:27 schrieb Noralf Trønnes: > > > Den 03.07.2019 10.32, skrev Thomas Zimmermann: >> DRM client buffers are permanently mapped throughout their lifetime. This >> prevents us from using generic framebuffer emulation for devices with >> small dedicated video memory, such as ast or mgag200. With fb buffers >> permanently mapped, such devices often won't have enougth space left to >> display other content (e.g., X11). >> >> This patch set introduces unmappable DRM client buffers for framebuffer >> emulation with shadow buffers. While the shadow buffer remains in system >> memory permanently, the respective buffer object will only be mapped briefly >> during updates from the shadow buffer. Hence, the driver can relocate he >> buffer object among memory regions as needed. >> >> The default behoviour for DRM client buffers is still to be permanently >> mapped. >> >> The patch set converts ast and mgag200 to generic framebuffer emulation >> and removes a large amount of framebuffer code from these drivers. For >> bochs, a problem was reported where the driver could not display the console >> because it was pinned in system memory. [1] The patch set fixes this bug >> by converting bochs to use the shadow fb. >> >> The patch set has been tested on ast and mga200 HW. >> > > I've been thinking, this enables dirty tracking in DRM userspace for > these drivers since the dirty callback is now set on all framebuffers. > Is this OK? Should we add a drm_fbdev_generic_shadow_setup() that sets a > flag enabling the shadow buffer instead? Fbdev emulation is special wrt framebuffer setup and there's no way to distinguish a regular FB from the fbdev's FB. I've been trying drm_fbdev_generic_shadow_setup(), but ended up duplicating functionality. The problem was that we cannot get state-flag arguments into drm_fb_helper_generic_probe(). There already is struct mode_config.prefer_shadow. It signals shadow FB rendering to userspace. The easiest solution is to add prefer_shadow_fbdev as well. If either flag is true, fbdev emulation would enable shadow buffering. I'm not sure if we should check for the dirty() callback at all. Best regards Thomas > Really nice diffstat by the way :-) > > Noralf. > >> [1] https://lists.freedesktop.org/archives/dri-devel/2019-June/224423.html >> >> Thomas Zimmermann (5): >> drm/client: Support unmapping of DRM client buffers >> drm/fb-helper: Unmap BO for shadow-buffered framebuffer console >> drm/ast: Replace struct ast_fbdev with generic framebuffer emulation >> drm/bochs: Use shadow buffer for bochs framebuffer console >> drm/mgag200: Replace struct mga_fbdev with generic framebuffer >> emulation >> >> drivers/gpu/drm/ast/Makefile | 2 +- >> drivers/gpu/drm/ast/ast_drv.c | 22 +- >> drivers/gpu/drm/ast/ast_drv.h | 17 -- >> drivers/gpu/drm/ast/ast_fb.c | 341 ------------------------- >> drivers/gpu/drm/ast/ast_main.c | 30 ++- >> drivers/gpu/drm/ast/ast_mode.c | 21 -- >> drivers/gpu/drm/bochs/bochs_kms.c | 2 +- >> drivers/gpu/drm/drm_client.c | 71 ++++- >> drivers/gpu/drm/drm_fb_helper.c | 14 +- >> drivers/gpu/drm/mgag200/Makefile | 2 +- >> drivers/gpu/drm/mgag200/mgag200_drv.h | 19 -- >> drivers/gpu/drm/mgag200/mgag200_fb.c | 309 ---------------------- >> drivers/gpu/drm/mgag200/mgag200_main.c | 61 +++-- >> drivers/gpu/drm/mgag200/mgag200_mode.c | 27 -- >> include/drm/drm_client.h | 3 + >> 15 files changed, 154 insertions(+), 787 deletions(-) >> delete mode 100644 drivers/gpu/drm/ast/ast_fb.c >> delete mode 100644 drivers/gpu/drm/mgag200/mgag200_fb.c >> >> -- >> 2.21.0 >> > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel