summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/omapdrm/omap_debugfs.c
Commit message (Collapse)AuthorAgeFilesLines
* omapdrm: simplify locking in the fb debugfs fileDaniel Vetter2013-02-161-14/+0
| | | | | | | | | | | | | | | | | | We don't need to hold onto mode_config.mutex any more to keep the fb objects around. And locking dev->struct_mutex is also not required, since omap_gem_describe only reads data anyway. And for a debug interface it's better to grab fewer locks in case the driver is deadlocked already ... The only thing we need is to hold onto mode_config.fb_lock to ensure the user-created fbs don't disappear. The fbcon fb doesn't need any protection, since it lives as long as the driver (and so the debugfs files) itself. And if the teardown/setup isn't following the right sequence grabbing locks won't prevent a NULL deref on priv->fbdev if the fb is not yet (or no longer) there. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/omap: move out of stagingRob Clark2013-02-161-0/+139
Now that the omapdss interface has been reworked so that omapdrm can use dispc directly, we have been able to fix the remaining functional kms issues with omapdrm. And in the mean time the PM sequencing and many other of that open issues have been solved. So I think it makes sense to finally move omapdrm out of staging. Signed-off-by: Rob Clark <robdclark@gmail.com>
OpenPOWER on IntegriCloud