kernel/include/drm/drm_fb_helper.h, branch linux-4.15.y

drm: remove unused and redundant callbacks

2017-08-07T09:20:36Z

Drivers no longer have any need for these callbacks, and there are no users. Zap. Zap-zap-zzzap-p-pp-p. Acked-by: Daniel Vetter Signed-off-by: Peter Rosin Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-15-peda@axentia.se

drm/fb-helper: Support deferred setup

2017-07-26T11:45:07Z

FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place because VGA connectors can happen to report an unknown connection status even when they are in fact connected. Some drivers have custom solutions in place to defer FB helper setup until at least one output is connected. But the logic behind these solutions is always the same and there is nothing driver-specific about it, so a better alterative is to fix the FB helper core and add support for all drivers automatically. This patch adds support for deferred FB helper setup. It checks all the connectors for their connection status, and if all of them report to be disconnected marks the FB helper as needing deferred setup. Whet setup is deferred, the FB helper core will automatically retry setup after a hotplug event, and it will keep trying until it succeeds. v2: Rebase onto my entirely reworked fbdev helper locking. One big difference is that this version again drops&reacquires the fbdev lock (which is now fb_helper->lock, but before this patch series it was mode_config->mutex), because register_framebuffer must be able to recurse back into fbdev helper code for the initial screen setup. v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon return, I've fumbled that in the deferred setup case (Liviu). v4: I was blind, redo this all. __drm_fb_helper_initial_config shouldn't need to reacquire fb_helper->lock, that just confuses callers. I myself got confused by kernel_fb_helper_lock and somehow thought it's the same as fb_helper->lock. Tsk. Also simplify the logic a bit (we don't need two functions to probe connectors), we can stick much closer to the existing code. And update some comments I've spotted that are outdated. v5: Don't pass -EAGAIN to drivers, it's just an internal error code (Liviu). v6: Add _and_unlock suffix to clarify locking (Maarten) Cc: Liviu Dudau Cc: John Stultz Cc: Thierry Reding Cc: Maarten Lankhorst Tested-by: John Stultz Signed-off-by: Thierry Reding (v1) Reviewed-by: Maarten Lankhorst Reviewed-by: Liviu Dudau Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter

drm/fb-helper: Add top-level lock

2017-07-06T08:00:42Z

Introduce a new top-level lock for the FB helper code. This will allow better locking granularity and avoid the need to abuse modeset locking for this purpose instead. This patch just adds the new lock everywhere we currently grab mode_config->mutex (explicitly, or through drm_modeset_lock_all). Follow-up patches will push the kms locking down into only the places that need it. v2: - use lockdep_assert_held - use drm_fb_helper_for_each_connector where possible - use the new top-level lock consistently, i.e. in all the places we're currently acquiring mode_config.mutex. - small polish to the kerneldoc Tested-by: John Stultz Signed-off-by: Thierry Reding (v1) Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-4-daniel.vetter@ffwll.ch

drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC

2017-03-02T07:12:15Z

Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic framebuffer emulation driver. Legacy framebuffer users like non kms/drm based OpenGL(ES)/EGL implementations may require the ioctl to synchronize drawing or buffer flip for double buffering. It is tested on the i.MX6. Signed-off-by: Maxime Ripard Tested-by: Neil Armstrong Signed-off-by: Daniel Vetter

drm/fb-helper: Automatically clean up fb_info

2017-02-07T20:36:28Z

Noticed that everyone duplicates the same logic here and we could safe a few lines per driver. Yay for lots of drivers to make such tiny refactors worth-while! v2: Forgot to git add everything :( v3: Actually remove release_fbi (Sean, Emil, Chris) ... Cc: Chris Wilson Cc: Sean Paul Cc: Noralf Trønnes Cc: Emil Velikov Reviewed-by: Sean Paul Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170207161603.17611-1-daniel.vetter@ffwll.ch

drm: Fix build when FBDEV_EMULATION is disabled

2017-02-02T19:40:32Z

Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is disabled because it didn't update the prototype for drm_fb_helper_init in that case. Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper initialization") Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170202193900.22075-1-krisman@collabora.co.uk

drm: Rely on mode_config data for fb_helper initialization

2017-02-02T18:12:00Z

Instead of receiving the num_crts as a parameter, we can read it directly from the mode_config structure. I audited the drivers that invoke this helper and I believe all of them initialize the mode_config struct accordingly, prior to calling the fb_helper. I used the following coccinelle hack to make this transformation, except for the function headers and comment updates. The first and second rules are split because I couldn't find a way to remove the unused temporary variables at the same time I removed the parameter. // @r@ expression A,B,D,E; identifier C; @@ ( - drm_fb_helper_init(A,B,C,D) + drm_fb_helper_init(A,B,D) | - drm_fbdev_cma_init_with_funcs(A,B,C,D,E) + drm_fbdev_cma_init_with_funcs(A,B,D,E) | - drm_fbdev_cma_init(A,B,C,D) + drm_fbdev_cma_init(A,B,D) ) @@ expression A,B,C,D,E; @@ ( - drm_fb_helper_init(A,B,C,D) + drm_fb_helper_init(A,B,D) | - drm_fbdev_cma_init_with_funcs(A,B,C,D,E) + drm_fbdev_cma_init_with_funcs(A,B,D,E) | - drm_fbdev_cma_init(A,B,C,D) + drm_fbdev_cma_init(A,B,D) ) @@ identifier r.C; type T; expression V; @@ - T C; <... when != C - C = V; ...> // Changes since v1: - Rebased on top of the tip of drm-misc-next. - Remove mention to sti since a proper fix got merged. Suggested-by: Daniel Vetter Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Eric Anholt Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk

drm: remove useless parameters from drm_pick_cmdline_mode function

2017-01-09T10:18:41Z

drm_pick_cmdline_mode width and height parameters are useless. Just remove them. Cc: Daniel Vetter Cc: Jani Nikula Signed-off-by: Vincent Abriou Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483721084-20278-2-git-send-email-vincent.abriou@st.com

drm/doc: use preferred struct reference in kernel-doc

2016-12-30T12:34:59Z

sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i Originally I wasnt a friend of this style because I thought a line-break between the "&struct" and "foo" part would break it. But a quick test shows that " * &struct \n * foo\n" works pefectly well with current kernel-doc. So time to mass-apply these changes! Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: David Herrmann Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1483044517-5770-6-git-send-email-daniel.vetter@ffwll.ch

drm/fb-helper: add fb_debug_* to DRM_FB_HELPER_DEFAULT_OPS

2016-11-14T06:47:46Z

Add additional members fb_debug_enter and fb_debug_leave to helper define. They are shared by all fb_ops implementations. Suggested-by: Daniel Vetter Signed-off-by: Stefan Christ Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/1479078208-25221-3-git-send-email-contact@stefanchrist.eu