aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorPrathyush <prathyush.k@samsung.com>2012-04-14 07:52:13 -0400
committerDave Airlie <airlied@redhat.com>2012-04-19 09:40:41 -0400
commit4e47e02d1ac47b6eb591b2a632a6c059ce3e5002 (patch)
treee9f67b84304f3fbe4dc54c16251ea21646c0db76
parent5799d9e2eab20ef694fb92a7636f451e1b0e456c (diff)
drm: Releasing FBs before releasing GEM objects during drm_release
During DRM release, all the FBs and gem objects are released. If a gem object is being used as a FB and set to a crtc, it must not be freed before releasing the framebuffer first. If FBs are released first, the crtc using the FB is disabled first so now the GEM object can be freed safely. The CRTC will be enabled again when the driver restores fbdev mode. Signed-off-by: Prathyush K <prathyush.k@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-rw-r--r--drivers/gpu/drm/drm_fops.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index cdfbf27b2b3c..123de28f94ef 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -507,12 +507,12 @@ int drm_release(struct inode *inode, struct file *filp)
507 507
508 drm_events_release(file_priv); 508 drm_events_release(file_priv);
509 509
510 if (dev->driver->driver_features & DRIVER_GEM)
511 drm_gem_release(dev, file_priv);
512
513 if (dev->driver->driver_features & DRIVER_MODESET) 510 if (dev->driver->driver_features & DRIVER_MODESET)
514 drm_fb_release(file_priv); 511 drm_fb_release(file_priv);
515 512
513 if (dev->driver->driver_features & DRIVER_GEM)
514 drm_gem_release(dev, file_priv);
515
516 mutex_lock(&dev->ctxlist_mutex); 516 mutex_lock(&dev->ctxlist_mutex);
517 if (!list_empty(&dev->ctxlist)) { 517 if (!list_empty(&dev->ctxlist)) {
518 struct drm_ctx_list *pos, *n; 518 struct drm_ctx_list *pos, *n;
r driver and you can find it by loading a half of the modules you normally use and binary searching in accordance with the algorithm: - if there are n modules loaded and the attempt to suspend and resume fails, unload n/2 of the modules and try again (that would probably involve rebooting the system), - if there are n modules loaded and the attempt to suspend and resume succeeds, load n/2 modules more and try again. Again, if you find the offending module(s), it(they) must be unloaded every time before hibernation, and please report the problem with it(them). c) Advanced debugging In case that hibernation does not work on your system even in the minimal configuration and compiling more drivers as modules is not practical or some modules cannot be unloaded, you can use one of the more advanced debugging techniques to find the problem. First, if there is a serial port in your box, you can boot the kernel with the 'no_console_suspend' parameter and try to log kernel messages using the serial console. This may provide you with some information about the reasons of the suspend (resume) failure. Alternatively, it may be possible to use a FireWire port for debugging with firescope (ftp://ftp.firstfloor.org/pub/ak/firescope/). On x86 it is also possible to use the PM_TRACE mechanism documented in Documentation/s2ram.txt . 2. Testing suspend to RAM (STR) To verify that the STR works, it is generally more convenient to use the s2ram tool available from http://suspend.sf.net and documented at http://en.opensuse.org/SDB:Suspend_to_RAM. Namely, after writing "freezer", "devices", "platform", "processors", or "core" into /sys/power/pm_test (available if the kernel is compiled with CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding to given string. The STR test modes are defined in the same way as for hibernation, so please refer to Section 1 for more information about them. In particular, the "core" test allows you to test everything except for the actual invocation of the platform firmware in order to put the system into the sleep state. Among other things, the testing with the help of /sys/power/pm_test may allow you to identify drivers that fail to suspend or resume their devices. They should be unloaded every time before an STR transition. Next, you can follow the instructions at http://en.opensuse.org/s2ram to test the system, but if it does not work "out of the box", you may need to boot it with "init=/bin/bash" and test s2ram in the minimal configuration. In that case, you may be able to search for failing drivers by following the procedure analogous to the one described in section 1. If you find some failing drivers, you will have to unload them every time before an STR transition (ie. before you run s2ram), and please report the problems with them.