summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_fb_helper.c
AgeCommit message (Collapse)Author
2017-11-23drm/fb: add support for not enabling fbcon on non-desktop displays [v2]Dave Airlie
We don't want fbcon to get used on non-desktop dislays, don't pass them as enabled connectors to the fb helper setup. This prevents my HMD from getting disorted fbcon, and from affecting other displays console. v2: Change description from non-standard to non-desktop Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-10-13drm: Replace kzalloc with kcallocHarsha Sharma
Prefer kcalloc over kzalloc to allocate an array. This patch fixes checkcpatch issue. Signed-off-by: Harsha Sharma <harshasharmaiitr@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20171013073747.29877-1-harshasharmaiitr@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20171013073747.29877-1-harshasharmaiitr@gmail.com
2017-09-02drm/fb-helper: Avoid NULL ptr dereference in fb_set_suspend()Noralf Trønnes
drm_fb_helper_resume_worker() uses fb_helper->fbdev to call fb_set_suspend() which dereferences the pointer. Move sync-canceling of the resume worker in drm_fb_helper_fini() before setting fb_helper->fbdev to NULL. Move dirty_work as well. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/1503940668-25883-2-git-send-email-noralf@tronnes.org
2017-08-07drm/fb-helper: pass physical dimensions to fbdevDavid Lechner
The fbdev subsystem has a place for physical dimensions (width and height in mm) that is readable by userspace. Since DRM also knows these dimensions, pass this information to the fbdev device. This has to be done in drm_setup_crtcs_fb() instead of drm_setup_crtcs() because fb_helper->fbdev may be NULL in drm_setup_crtcs(). Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501863924-7154-1-git-send-email-david@lechnology.com
2017-08-03drm/fb-helper: add new drm_setup_crtcs_fb() functionDavid Lechner
This adds a new drm_setup_crtcs_fb() function to handle the parts of drm_setup_crtcs() that touch fb_helper->fb and fb_helper->fbdev. When drm_setup_crtcs() is called during initialization, these fields are NULL because they have not been allocated yet. There is currently a hack at the end of drm_fb_helper_single_fb_probe() that sets fb_helper->fb, so it is moved to the new drm_setup_crtcs_fb() function. This is also done in preparation for addition setup that requires access to fb_helper->fbdev. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501777149-8310-2-git-send-email-david@lechnology.com
2017-08-03drm/fb: Fix pointer dereference before null check.David Lechner
fb_crtc is used before a null check, so move the use after the null check. This was just identified by inspection. I haven't actually observed a crash here, so it is possible that the null check could be unnecessary. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1501696813-8807-1-git-send-email-david@lechnology.com
2017-07-26drm/fb-helper: Support deferred setupDaniel Vetter
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 <liviu@dudau.co.uk> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Reviewed-by: Liviu Dudau <liviu@dudau.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-14drm/fb-helper: separate the fb_setcmap helper into atomic and legacy pathsPeter Rosin
The legacy path implements setcmap in terms of crtc .gamma_set. The atomic path implements setcmap by directly updating the crtc gamma_lut property. This has a couple of benefits: - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. They are now unused and subject for removal. - atomic drivers that support clut modes get fbdev support for those from the drm core. This includes atmel-hlcdc, but perhaps others as well? Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-4-peda@axentia.se
2017-07-06drm/fb-helper: remove drm_fb_helper_save_lut_atomicPeter Rosin
drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is now always kept up to date by drm_fb_helper_setcmap. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-4-git-send-email-peda@axentia.se
2017-07-06drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmapPeter Rosin
I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-3-git-send-email-peda@axentia.se
2017-07-06drm/fb-helper: factor out pseudo-palettePeter Rosin
The pseudo-palette has nothing to do with the crtc, so move it out of the crtc loop and update the palette once, then break out early. Signed-off-by: Peter Rosin <peda@axenita.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-peda@axentia.se
2017-07-06drm/fb-helper: Split dpms handling into legacy and atomic pathsDaniel Vetter
Like with panning and modesetting, and like with those, stick with simple drm_modeset_locking_all for the legacy path, and the full atomic dance for atomic drivers. This means a bit more boilerplate since setting up the atomic state machinery is rather verbose, but then this is shared code for 30+ drivers or so, so meh. After this patch there's only the LUT/cmap path which is still using drm_modeset_lock_all for an atomic driver. But Peter is already locking into reworking that, so I'll leave that code as-is for now. v2: Squash in patches from Maarten to unify all the various atomic paths into just one atomic update function for fbdev overall. On top do one s/restore_fbdev_mode/restore_fbdev_mode_atomic/ so that we have all-atomic callchains after the first check. Cc: Peter Rosin <peda@axentia.se> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-10-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Stop using mode_config.mutex for internalsDaniel Vetter
Those are now all protected using fb_helper->lock. v2: We still need to hold mode_config.mutex right around calling connector->fill_modes. v3: I forgot to hold mode_config.mutex while looking at connector->status and the mode list. Also, we need to patch up the i915 ->initial_config callback to grab the locks it needs to inspect the modeset state recovered from the fw. v4: Don't reorder the probe too much (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170705045629.31265-1-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacyDaniel Vetter
Same game as with the panning function, use drm_modeset_lock_all for legacy paths, and a proper acquire ctx w/w mutex dance for atomic. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-8-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Push locking into pan_display_atomic|legacyDaniel Vetter
For the legacy path we'll keep drm_modeset_lock_all, for the atomic one we drop the use of the magic implicit context and wire it up properly. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-7-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Drop locking from the vsync wait ioctl codeDaniel Vetter
Like with the drm-native vblank wait ioctl we can entirely rely on the spinlocks in drm_vblank.c, no need at all to take expensive mutexes. The only reason we had to take mode_config.mutex was to protect the fbdev helper's data-structures, but that's now done by fb_helper->lock. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-6-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Push locking in fb_is_boundDaniel Vetter
That function only needs to take the individual crtc locks, not all the kms locks. Push down the locking and then minimize it. Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-5-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Add top-level lockThierry Reding
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 <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-4-daniel.vetter@ffwll.ch
2017-07-06drm/fb-helper: Push down modeset lock into FB helpersThierry Reding
Move the modeset locking from drivers into FB helpers. v2: Also handle intel_connector_add_to_fbdev. v3: Prevent race in intel_dp_mst with ->detect (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-2-daniel.vetter@ffwll.ch
2017-07-04drm/fb-helper: Remove drm_mode_config_fb.Maarten Lankhorst
Remove drm_mode_config_fb, I don't see the point of it. To make it clear that it's ok to use plane->fb directly, move up drm_drv_uses_atomic_modeset so the code is skipped for atomic drivers that require plane_state->fb. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170703115106.18783-1-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-05-22drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPIRobert Foss
Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Changes since v3: - Switched away from past tense in comments - Add define name change to previously mis-spelled DRM_REFLECT_X comment - Improved the comment for the DRM_MODE_REFLECT_<axis> comment Changes since v2: - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_ - Fix compilation errors - Changed comment formatting - Deduplicated comment lines - Clarified DRM_MODE_PROP_REFLECT_ comment Changes since v1: - Moved defines from drm.h to drm_mode.h - Changed define prefix from DRM_ to DRM_MODE_PROP_ - Updated uses of the defines to the new prefix - Removed include from drm_rect.c - Stopped using the BIT() macro Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
2017-05-08format-security: move static strings to constKees Cook
While examining output from trial builds with -Wformat-security enabled, many strings were found that should be defined as "const", or as a char array instead of char pointer. This makes some static analysis easier, by producing fewer false positives. As these are all trivial changes, it seemed best to put them all in a single patch rather than chopping them up per maintainer. Link: http://lkml.kernel.org/r/20170405214711.GA5711@beast Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Jes Sorensen <jes@trained-monkey.org> [runner.c] Cc: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@armlinux.org.uk> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Cc: Salil Mehta <salil.mehta@huawei.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Jiri Slaby <jslaby@suse.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Jarod Wilson <jarod@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Antonio Quartulli <a@unstable.cc> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Kejian Yan <yankejian@huawei.com> Cc: Daode Huang <huangdaode@hisilicon.com> Cc: Qianqian Xie <xieqianqian@huawei.com> Cc: Philippe Reynes <tremyfr@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Christian Gromm <christian.gromm@microchip.com> Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de> Cc: Jason Litzinger <jlitzingerdev@gmail.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-06drm/fb-helper: Extract _legacy kms functionsDaniel Vetter
The goal is to push all the kms locking down into these separate _atomic and _legacy functions, so that we can correctly pass the acquire ctx into all atomic drivers. Instead of playing games with hidden ctx in mode_config.acquire_ctx. All the fbdev state will be protected by a new fbdev private lock that Thierry is working on. This here is just prep by creating a clean split between atomic and legacy paths, which also simplifies the control flow a bit. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-16-daniel.vetter@ffwll.ch
2017-04-06drm: Add acquire ctx to ->gamma_set hookDaniel Vetter
Atomic helpers really want this instead of the hacked-up legacy backoff trick, which unfortunately prevents drivers from using their own private drm_modeset_locks. Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which don't yet use the new atomic color mgmt/gamma table stuff. Would be nice if they could switch over and just hook up drm_atomic_helper_legacy_gamma_set() instead. Cc: Dave Airlie <airlied@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-13-daniel.vetter@ffwll.ch
2017-04-06drm/fb-helper: Give up on kgdb for atomic driversDaniel Vetter
It just doesn't work. It probably stopped working way, way before that (e.g. i915 grabbed random mutexes all over in modeset code at least since gen6), but with atomic and all the ww_mutex stuff it's indeed hopeless. Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and nouveau) that still had one (both had dummy implementations already anyway), and shunt atomic drivers in the helpers debug_enter/leave functions. I'll leave the code in for radeon and amdgpu, but I think as soon as amdgpu is atomic we should think about just ripping it out. Only having it around for radeon and pre-nv50 is rather pointless. This would also allow us to nuke all that code from fbdev. Funny part is that _all_ kms drivers set this hook, despite that no one else provides the required ->mode_set_base_atomic implementation. The reason I'm jumping on this is that I want to wire up a full acquire ctx for the benefit of atomic drivers, everywhere. And the debug_enter/leave implementations call ->gamma_set. And there's just no way ever we can create an acquire_ctx in the nmi context of kgdb. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-11-daniel.vetter@ffwll.ch
2017-04-04Merge airlied/drm-next into drm-misc-nextSean Paul
Backmerging in order to pull vmwgfx [1] and the new synopsys media format [2] reqs. [1]- http://patchwork.freedesktop.org/patch/msgid/20170331233255.GA38850@syeh-m02 [2]- http://patchwork.freedesktop.org/patch/msgid/20170403163544.kcw5kk52tgku5xua@art_vandelay Signed-off-by: Sean Paul <seanpaul@chromium.org>
2017-03-31drm/fb-helper: Improve code readabilityThierry Reding
Add a couple of temporary variables and use shorter names for existing variables in drm_fb_helper_add_one_connector() for better readability. Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-4-thierry.reding@gmail.com
2017-03-31drm/fb-helper: Reshuffle code for subsequent patchesThierry Reding
An unlocked version of the drm_fb_helper_add_one_connector() function will be added in a subsequent patch. Reshuffle the code separately to make the diff more readable later on. Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-3-thierry.reding@gmail.com
2017-03-31drm/fb-helper: Cleanup checkpatch warningsThierry Reding
Fix up a couple of checkpatch warnings, such as whitespace or coding style issues. Tested-by: John Stultz <john.stultz@linaro.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170329144401.1804-2-thierry.reding@gmail.com
2017-03-28Backmerge tag 'v4.11-rc4' into drm-nextDave Airlie
Linux 4.11-rc4 The i915 GVT team need the rc4 code to base some more code on.
2017-03-23drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height againMichel Dänzer
Otherwise this can also prevent modesets e.g. for switching VTs, when multiple monitors with different native resolutions are connected. The depths must match though, so keep the != test for that. Also update the DRM_DEBUG output to be slightly more accurate, this doesn't only affect requests from userspace. Bugzilla: https://bugs.freedesktop.org/99841 Fixes: 865afb11949e ("drm/fb-helper: reject any changes to the fbdev") Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170323085326.20185-1-michel@daenzer.net
2017-03-02drm/fb-helper: implement ioctl FBIO_WAITFORVSYNCMaxime Ripard
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 <maxime.ripard@free-electrons.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-02-28drm: Rename connector list iterator APIThierry Reding
Currently the functions that initialize and tear down a connector iterator use the _get() and _put() suffixes. However, these suffixes are typically used by reference counting functions. Make these function names a little more consistent by changing the suffixes to _begin() and _end(), which is a fairly common pattern in the rest of the Linux kernel. Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-8-thierry.reding@gmail.com
2017-02-28drm: Introduce drm_connector_{get,put}()Thierry Reding
For consistency with other reference counting APIs in the kernel, add drm_connector_get() and drm_connector_put() functions to reference count connectors. Compatibility aliases are added to keep existing code working. To help speed up the transition, all the instances of the old functions in the DRM core are already replaced in this commit. The existing semantic patch for mode object reference count conversion is extended for these new helpers. Reviewed-by: Sean Paul <seanpaul@chromium.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170228144643.5668-4-thierry.reding@gmail.com
2017-02-26drm/fb-helper: Add multi buffer support for cma fbdevXinliang Liu
This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> [s.christ@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ <s.christ@phytec.de> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Dave Airlie <airlied@gmail.com> Tested-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/075ffb50cc16ab055b5d47b30163401bb356ab51.1487175046.git-series.maxime.ripard@free-electrons.com
2017-02-26Merge airlied/drm-next into drm-misc-nextDaniel Vetter
Backmerge the main pull request to sync up with all the newly landed drivers. Otherwise we'll have chaos even before 4.12 started in earnest. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2017-02-08drm: Cancel drm_fb_helper_resume_work on unloadChris Wilson
We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: cfe63423d9be ("drm/fb-helper: Add drm_fb_helper_set_suspend_unlocked()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-2-chris@chris-wilson.co.uk
2017-02-08drm: Cancel drm_fb_helper_dirty_work on unloadChris Wilson
We can not allow the worker to run after its fbdev, or even the module, has been removed. Fixes: eaa434defaca ("drm/fb-helper: Add fb_deferred_io support") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.7+ Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170207124956.14954-1-chris@chris-wilson.co.uk
2017-02-07drm/fb-helper: Automatically clean up fb_infoDaniel Vetter
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 <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207161603.17611-1-daniel.vetter@ffwll.ch
2017-02-07drm/fb-helper: Explain unload sequence a bit betterDaniel Vetter
While reviewing Chris' patches to properly cancel our async workers I checked that this happens after the fbdev is already unregistered. That's the case, but I found a small gap in our docs, fill that in. Note that I don't explain what release_fbi does, because that function will disappear in the next patch ... Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170207141050.1129-1-daniel.vetter@ffwll.ch
2017-02-02drm: Rely on mode_config data for fb_helper initializationGabriel Krisman Bertazi
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. // <smpl> @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; ...> // </smpl> 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 <daniel.vetter@intel.com> Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170202162640.27261-1-krisman@collabora.co.uk
2017-01-25drm/kms-helpers: Use recommened kerneldoc for struct member refsDaniel Vetter
I just learned that &struct_name.member_name works and looks pretty even. It doesn't (yet) link to the member directly though, which would be really good for big structures or vfunc tables (where the per-member kerneldoc tends to be long). Also some minor drive-by polish where it makes sense, I read a lot of docs ... v2: Comments from Gustavo. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Rewiewed-by: Gustavo Padovan <gustavo.padovan@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-2-daniel.vetter@ffwll.ch
2017-01-09drm: remove useless parameters from drm_pick_cmdline_mode functionVincent Abriou
drm_pick_cmdline_mode width and height parameters are useless. Just remove them. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Vincent Abriou <vincent.abriou@st.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1483721084-20278-2-git-send-email-vincent.abriou@st.com
2016-12-27drm: Wrap the check for atomic_commit implementationDhinakaran Pandiyan
This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [danvet: Move back to drmP.h because include hell.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1482396643-32456-1-git-send-email-dhinakaran.pandiyan@intel.com
2016-12-18drm: Convert all helpers to drm_connector_list_iterDaniel Vetter
Mostly nothing special (except making sure that really all error paths and friends call iter_put). v2: Don't forget the raw connector_list walking in drm_helper_move_panel_connectors_to_head. That one unfortunately can't be converted to the iterator helpers, but since it's just some list splicing best to just wrap the entire thing up in one critical section. v3: Bail out after iter_put (Harry). Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161215155843.13408-1-daniel.vetter@ffwll.ch
2016-12-15drm: Nuke fb->bits_per_pixelVille Syrjälä
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8. Less duplicated information is a good thing. Note that I didn't put parens around the cpp*8 in the below cocci script, on account of not wanting spurious parens all over the place. Instead I did the unsafe way, and tried to look over the entire diff to spot if any dangerous expressions were produced. I didn't see any. There are some cases where previously the code did X*bpp/8, so the division happened after the multiplication. Those are now just X*cpp so the division effectively happens before the multiplication, but that is perfectly fine since bpp is always a multiple of 8. @@ struct drm_framebuffer *FB; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ i9xx_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ ironlake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ skylake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer FB; expression E; @@ ( - E * FB.bits_per_pixel / 8 + E * FB.format->cpp[0] | - FB.bits_per_pixel / 8 + FB.format->cpp[0] | - E * FB.bits_per_pixel >> 3 + E * FB.format->cpp[0] | - FB.bits_per_pixel >> 3 + FB.format->cpp[0] | - (FB.bits_per_pixel + 7) / 8 + FB.format->cpp[0] | - FB.bits_per_pixel + FB.format->cpp[0] * 8 | - FB.format->cpp[0] * 8 != 8 + FB.format->cpp[0] != 1 ) @@ struct drm_framebuffer *FB; expression E; @@ ( - E * FB->bits_per_pixel / 8 + E * FB->format->cpp[0] | - FB->bits_per_pixel / 8 + FB->format->cpp[0] | - E * FB->bits_per_pixel >> 3 + E * FB->format->cpp[0] | - FB->bits_per_pixel >> 3 + FB->format->cpp[0] | - (FB->bits_per_pixel + 7) / 8 + FB->format->cpp[0] | - FB->bits_per_pixel + FB->format->cpp[0] * 8 | - FB->format->cpp[0] * 8 != 8 + FB->format->cpp[0] != 1 ) @@ struct drm_plane_state *state; expression E; @@ ( - E * state->fb->bits_per_pixel / 8 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel / 8 + state->fb->format->cpp[0] | - E * state->fb->bits_per_pixel >> 3 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel >> 3 + state->fb->format->cpp[0] | - (state->fb->bits_per_pixel + 7) / 8 + state->fb->format->cpp[0] | - state->fb->bits_per_pixel + state->fb->format->cpp[0] * 8 | - state->fb->format->cpp[0] * 8 != 8 + state->fb->format->cpp[0] != 1 ) @@ @@ - (8 * 8) + 8 * 8 @@ struct drm_framebuffer FB; @@ - (FB.format->cpp[0]) + FB.format->cpp[0] @@ struct drm_framebuffer *FB; @@ - (FB->format->cpp[0]) + FB->format->cpp[0] @@ @@ struct drm_framebuffer { ... - int bits_per_pixel; ... }; v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent) v3: Adjusted the semantic patch a bit and regenerated due to code changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com
2016-12-15drm: Nuke fb->depthVille Syrjälä
Replace uses of fb->depth with fb->format->depth. Less duplicate information is a good thing. @@ struct drm_framebuffer *fb; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - fb->depth = E; ... } @@ struct nouveau_framebuffer *fb; @@ - fb->base.depth + fb->base.format->depth @@ struct drm_framebuffer fb; @@ - fb.depth + fb.format->depth @@ struct drm_framebuffer *fb; @@ - fb->depth + fb->format->depth @@ struct drm_framebuffer fb; @@ - (fb.format->depth) + fb.format->depth @@ struct drm_framebuffer *fb; @@ - (fb->format->depth) + fb->format->depth @@ @@ struct drm_framebuffer { ... - unsigned int depth; ... }; v2: Drop the vmw stuff (Daniel) Rerun spatch due to code changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1481751095-18249-1-git-send-email-ville.syrjala@linux.intel.com
2016-11-29drm: Protect fb_helper list manipulation with a mutexChris Wilson
Though we only walk the kernel_fb_helper_list inside a panic (or single thread debugging), we still need to protect the list manipulation on creating/removing a framebuffer device in order to prevent list corruption. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-3-chris@chris-wilson.co.uk
2016-11-29drm: Pull together probe + setup for drm_fb_helperChris Wilson
drm_fb_helper_probe_connector_modes() is always called before drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a small bit of code compaction. Note that register_framebuffer will do a modeset (when fbcon is enabled) and hence must be moved out of the critical section. A follow-up patch will add new locking for the fb list, hence move all the related registration code together. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-2-chris@chris-wilson.co.uk
2016-11-29drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcsChris Wilson
The fb_helper->connector_count is modified when a new connector is constructed following a hotplug event (e.g. DP-MST). This causes trouble for drm_setup_crtcs() and friends that assume that fb_helper is constant: [ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at addr ffff88074cdd2608 [ 1250.873020] Write of size 40 by task kworker/u8:3/480 [ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G U 4.9.0-rc6+ #285 [ 1250.873043] Hardware name: /NUC6i3SYB, BIOS SYSKLi35.86A.0024.2015.1027.2142 10/27/2015 [ 1250.873050] Workqueue: events_unbound async_run_entry_fn [ 1250.873056] ffff88070f9d78f0 ffffffff814b72aa ffff88074e40c5c0 ffff88074cdd2608 [ 1250.873067] ffff88070f9d7918 ffffffff8124ff3c ffff88070f9d79b0 ffff88074cdd2600 [ 1250.873079] ffff88074e40c5c0 ffff88070f9d79a0 ffffffff812501e4 0000000000000005 [ 1250.873090] Call Trace: [ 1250.873099] [<ffffffff814b72aa>] dump_stack+0x67/0x9d [ 1250.873106] [<ffffffff8124ff3c>] kasan_object_err+0x1c/0x70 [ 1250.873113] [<ffffffff812501e4>] kasan_report_error+0x204/0x4f0 [ 1250.873120] [<ffffffff81698df0>] ? drm_dev_printk+0x140/0x140 [ 1250.873127] [<ffffffff81250ac3>] kasan_report+0x53/0x60 [ 1250.873134] [<ffffffff81688b40>] ? drm_setup_crtcs+0x320/0xf80 [ 1250.873142] [<ffffffff8124f18e>] check_memory_region+0x13e/0x1a0 [ 1250.873147] [<ffffffff8124f5f3>] memset+0x23/0x40 [ 1250.873154] [<ffffffff81688b40>] drm_setup_crtcs+0x320/0xf80 [ 1250.873161] [<ffffffff810be7c5>] ? wake_up_q+0x45/0x80 [ 1250.873169] [<ffffffff81b0c180>] ? mutex_lock_nested+0x5a0/0x5a0 [ 1250.873176] [<ffffffff8168a0e6>] drm_fb_helper_initial_config+0x206/0x7a0 [ 1250.873183] [<ffffffff81689ee0>] ? drm_fb_helper_set_par+0x90/0x90 [ 1250.873303] [<ffffffffa0b68690>] ? intel_fbdev_fini+0x140/0x140 [i915] [ 1250.873387] [<ffffffffa0b686b2>] intel_fbdev_initial_config+0x22/0x40 [i915] [ 1250.873391] [<ffffffff810b50ff>] async_run_entry_fn+0x7f/0x270 [ 1250.873394] [<ffffffff810a64b0>] process_one_work+0x3d0/0x960 [ 1250.873398] [<ffffffff810a641d>] ? process_one_work+0x33d/0x960 [ 1250.873401] [<ffffffff810a60e0>] ? max_active_store+0xf0/0xf0 [ 1250.873406] [<ffffffff810f6f9d>] ? do_raw_spin_lock+0x10d/0x1a0 [ 1250.873413] [<ffffffff810a767d>] worker_thread+0x8d/0x840 [ 1250.873419] [<ffffffff810a75f0>] ? create_worker+0x2e0/0x2e0 [ 1250.873426] [<ffffffff810b0454>] kthread+0x194/0x1c0 [ 1250.873432] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60 [ 1250.873438] [<ffffffff810f095d>] ? trace_hardirqs_on+0xd/0x10 [ 1250.873446] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60 [ 1250.873453] [<ffffffff810b02c0>] ? kthread_park+0x60/0x60 [ 1250.873457] [<ffffffff81b12277>] ret_from_fork+0x27/0x40 [ 1250.873460] Object at ffff88074cdd2608, in cache kmalloc-32 size: 32 However, when holding the mode_config.lock around the fb_helper, we have to be careful of any callbacks that may reenter the fb_helper and so try to reacquire the mode_config.lock (e.g. register_framebuffer). To avoid the mutex recursion, we have to rearrange the sequence to move the registration into the caller outside of the mode_config.lock. v2: drop the 1; following the lockdep assertion inside the for(;;), I anticipated an error that doesn't happen! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20161129120217.7344-1-chris@chris-wilson.co.uk
generated by cgit (git 2.34.1) at 2024-05-27 11:21:46 +0000