user/sven/linux.git/drivers/gpu/drm/drm_framebuffer.c, branch v4.14.151

drm: silence variable 'conn' set but not used

2019-08-16T08:13:52Z

[ Upstream commit bbb6fc43f131f77fcb7ae8081f6d7c51396a2120 ] The "struct drm_connector" iteration cursor from "for_each_new_connector_in_state" is never used in atomic_remove_fb() which generates a compilation warning, drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb': drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set but not used [-Wunused-but-set-variable] Silence it by marking "conn" __maybe_unused. Signed-off-by: Qian Cai Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-cai@lca.pw Signed-off-by: Sasha Levin

drm: Reject getfb for multi-plane framebuffers

2018-03-28T16:24:40Z

commit b24791fe00f8b089d5b10cb7bcc4e1ae88b4831b upstream. getfb can only return a single plane, so reject attempts to use it with multi-plane framebuffers. Signed-off-by: Daniel Stone Reported-by: Daniel van Vugt Reviewed-by: Rob Clark Reviewed-by: Daniel Vetter Fixes: 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel format v5") Cc: stable@vger.kernel.org # v3.3+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105518 Link: https://patchwork.freedesktop.org/patch/msgid/20180320225839.30905-1-daniels@collabora.com Signed-off-by: Greg Kroah-Hartman

drm/nouveau: prefer XBGR2101010 for addfb ioctl

2018-03-15T09:54:30Z

commit c20bb155c2c5acb775f68be5d84fe679687c3c1e upstream. Nouveau only exposes support for XBGR2101010. Prior to the atomic conversion, drm would pass in the wrong format in the framebuffer, but it was always ignored -- both userspace (xf86-video-nouveau) and the kernel driver agreed on the layout, so the fact that the format was wrong didn't matter. With the atomic conversion, nouveau all of a sudden started caring about the exact format, and so the previously-working code in xf86-video-nouveau no longer functioned since the (internally-assigned) format from the addfb ioctl was wrong. This change adds infrastructure to allow a drm driver to specify that it prefers the XBGR format variant for the addfb ioctl, and makes nouveau's nv50 display driver set it. (Prior gens had no support for 30bpp at all.) Signed-off-by: Ilia Mirkin Cc: stable@vger.kernel.org # v4.10+ Acked-by: Ben Skeggs Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180203191123.31507-1-imirkin@alum.mit.edu Signed-off-by: Greg Kroah-Hartman

Merge airlied/drm-next into drm-misc-next

2017-07-26T11:43:33Z

I need this to be able to apply the deferred fbdev setup patches, I need the relevant prep work that landed through the drm-intel tree. Also squash in conflict fixup from Laurent Pinchart. Signed-off-by: Daniel Vetter

drm/atomic: Use the correct iterator macro in atomic_remove_fb

2017-07-13T07:44:58Z

for_each_obj_in_state will be removed, so use the new state here. Signed-off-by: Maarten Lankhorst Cc: Daniel Vetter Cc: Jani Nikula Cc: Sean Paul Cc: David Airlie Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-3-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter

drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb

2017-07-03T08:31:37Z

All atomic state should be cleared when drm_modeset_backoff() is called, because it drops all locks and the state becomes invalid. The call to drm_atomic_state_clear was missing in atomic_remove_fb, so add the missing call there. Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/20170629115954.26029-1-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter Fixes: db8f6403e88a ("drm: Convert drm_framebuffer_remove to atomic, v4.") Cc: stable@vger.kernel.org # v4.12-rc1+

drm: extract legacy framebuffer remove

2017-04-06T08:22:43Z

I got confused every time I audited what that lock_all is doing in there until realizing it's for legacy kms only. Make that a notch more obvious by having 2 entirely different paths. While at it also move the atomic version of this into drm_framebuffer.c, there's no reason it needs to be in drm_atomic.c. That way it becomes a simple static function. Reviewed-by: Maarten Lankhorst Acked-by: Alex Deucher Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-15-daniel.vetter@ffwll.ch

drm: Add mode_config .get_format_info() hook

2017-03-22T17:45:00Z

Allow drivers to return a custom drm_format_info structure for special fb layouts. We'll use this for the compression control surface in i915. v2: Fix drm_get_format_info() kernel doc (Laurent) Don't pass 'dev' to the new hook (Laurent) v3: s/compresssion/compression/ (Ben) Cc: Laurent Pinchart Cc: Ben Widawsky Cc: Jason Ekstrand Signed-off-by: Ville Syrjälä Reviewed-by: Ben Widawsky Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-4-ville.syrjala@linux.intel.com

drm: Remove fb hsub/vsub alignment requirement

2017-03-22T17:44:15Z

Allow framebuffers dimesions to be misaligned w.r.t. the subsampling factors. No real reason the core should have to enforce this, and it definitely starts to cause us issues with the i915 CCS support. So let's just lift the restriction. Let's start to round up when computing the color plane dimesions so that we'll not end up with too low an estimate for the memory requirements and whatnot. Cc: Ben Widawsky Cc: Jason Ekstrand Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-3-ville.syrjala@linux.intel.com Reviewed-by: Ben Widawsky

drm: Share the code to compute color plane dimesions

2017-03-22T17:37:17Z

framebuffer_check() has some hand rolled code to compute the color plane dimensions based on the subsampled information. Let's share the code between framebuffer_check() and drm_framebuffer_plane_{width,height}(). Cc: Ben Widawsky Cc: Jason Ekstrand Signed-off-by: Ville Syrjälä Link: http://patchwork.freedesktop.org/patch/msgid/20170321181218.10042-2-ville.syrjala@linux.intel.com Reviewed-by: Ben Widawsky