Some DRM helpers assume that all potential color planes of a framebuffer are available; even if the color format didn't specify them. Non-existing planes are silently ignored. This behavior is inconsistent with other helpers and apparently leads to subtle bugs with uninitialized GEM buffer mappings. [1] Change all affected code to look at the framebuffer format's number of color planes and only process these planes. The update has been discussed in [2] before. Tested with GEM SHMEM helpers on simpledrm and with GEM VRAM helpers on ast. v2: * refactor GEM VRAM code before fixing it (Javier) * print more error information in #1 (Javier) * commit-message fixes (Javier) [1] https://lore.kernel.org/dri-devel/20210730183511.20080-1-tzimmermann@xxxxxxx/T/#md0172b10bb588d8f20f4f456e304f08d2a4505f7 [2] https://lore.kernel.org/dri-devel/877dc0d9-c6c6-022c-20d8-14b33e863934@xxxxxxx/ Thomas Zimmermann (5): drm/gem: Share code between drm_gem_fb_{begin,end}_cpu_access() drm/gem: Ignore color planes that are unused by framebuffer format drm/gem-vram: Share code between GEM VRAM's _{prepare,cleanup}_fb() drm/gem-vram: Ignore planes that are unused by framebuffer format drm/gem: Warn on trying to use a non-existing framebuffer plane drivers/gpu/drm/drm_gem_atomic_helper.c | 6 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 104 +++++++++---------- drivers/gpu/drm/drm_gem_vram_helper.c | 54 ++++++---- include/drm/drm_gem_framebuffer_helper.h | 10 +- 4 files changed, 92 insertions(+), 82 deletions(-) -- 2.36.1
