linux/drivers/staging/omapdrm, branch master

drm/omap: move out of staging

2013-02-16T22:38:06Z

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

staging/omapdrm: Use kmemdup rather than duplicating its implementation

2013-02-16T22:38:05Z

Found with coccicheck. The semantic patch that makes this change is available in scripts/coccinelle/api/memdup.cocci. Signed-off-by: Peter Huewe Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage

2013-02-16T22:38:05Z

There is a memory leakage in variable sg if it goes to error. Signed-off-by: Cong Ding Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

drm/omap: Add OMAP5 support

2013-02-16T22:38:04Z

Add support for OMAP5 processor. The main differences are that the OMAP5 has 2 containers, one for 1D and one for 2D. Each container is 128MiB in size. Signed-off-by: Andy Gross Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

drm/omap: Add PM capabilities

2013-02-16T22:38:04Z

Added power management capabilities into the omapdrm and DMM drivers. During suspend, we don't need to do anything to maintain the state of the LUT. We have all the necessary information to recreate the mappings of the GEM object list maintained by the omapdrm driver. On resume, the DMM resume handler will first reprogram the LUT to point to the dummy page. The subsequent resume handler in the omapdrm will call into the DMM and reprogram each of the buffer objects. This will ensure that all of the necessary objects will be pinned into the DMM properly. Order of suspend/resume handlers is done by device creation. We create the DMM device before the omapdrm, so the correct order is maintained. Signed-off-by: Andy Gross Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman

drm/: simplify ->fb_probe callback

2013-02-13T23:07:58Z

The fb helper lost its support for reallocating an fb completely, so no need to return special success values any more. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter

drm/fb-helper: don't disable everything in initial_config

2013-02-13T23:07:53Z

This should be done in the drivers for two reasons: - it gets in the way of fastboot efforts - it links the fb helpers with the crtc helpers instead of going through the real interface vfuncs, forcing i915 to fake all the ->disable callbacks used by the crtc helper to avoid ugly Oopsen v2: Resolve conflicts since drivers still call drm_fb_helper_single_add_all_connectors. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter

drm: revamp framebuffer cleanup interfaces

2013-01-20T21:17:00Z

We have two classes of framebuffer - Created by the driver (atm only for fbdev), and the driver holds onto the last reference count until destruction. - Created by userspace and associated with a given fd. These framebuffers will be reaped when their assoiciated fb is closed. Now these two cases are set up differently, the framebuffers are on different lists and hence destruction needs to clean up different things. Also, for userspace framebuffers we remove them from any current usage, whereas for internal framebuffers it is assumed that the driver has done this already. Long story short, we need two different ways to cleanup such drivers. Three functions are involved in total: - drm_framebuffer_remove: Convenience function which removes the fb from all active usage and then drops the passed-in reference. - drm_framebuffer_unregister_private: Will remove driver-private framebuffers from relevant lists and drop the corresponding references. Should be called for driver-private framebuffers before dropping the last reference (or like for a lot of the drivers where the fbdev is embedded someplace else, before doing the cleanup manually). - drm_framebuffer_cleanup: Final cleanup for both classes of fbs, should be called by the driver's ->destroy callback once the last reference is gone. This patch just rolls out the new interfaces and updates all drivers (by adding calls to drm_framebuffer_unregister_private at all the right places)- no functional changes yet. Follow-on patches will move drm core code around and update the lifetime management for framebuffers, so that we are no longer required to keep framebuffers alive by locking mode_config.mutex. I've also updated the kerneldoc already. vmwgfx seems to again be a bit special, at least I haven't figured out how the fbdev support in that driver works. It smells like it's external though. v2: The i915 driver creates another private framebuffer in the load-detect code. Adjust its cleanup code, too. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter

drm: revamp locking around fb creation/destruction

2013-01-20T21:16:58Z

Well, at least step 1. The goal here is that framebuffer objects can survive outside of the mode_config lock, with just a reference held as protection. The first step to get there is to introduce a special fb_lock which protects fb lookup, creation and destruction, to make them appear atomic. This new fb_lock can nest within the mode_config lock. But the idea is (once the reference counting part is completed) that we only quickly take that fb_lock to lookup a framebuffer and grab a reference, without any other locks involved. vmwgfx is the only driver which does framebuffer lookups itself, also wrap those calls to drm_mode_object_find with the new lock. Also protect the fb_list walking in i915 and omapdrm with the new lock. As a slight complication there's also the list of user-created fbs attached to the file private. The problem now is that at fclose() time we need to walk that list, eventually do a modeset call to remove the fb from active usage (and are required to be able to take the mode_config lock), but in the end we need to grab the new fb_lock to remove the fb from the list. The easiest solution is to add another mutex to protect this per-file list. Currently that new fbs_lock nests within the modeset locks and so appears redudant. But later patches will switch around this sequence so that taking the modeset locks in the fb destruction path is optional in the fastpath. Ultimately the goal is that addfb and rmfb do not require the mode_config lock, since otherwise they have the potential to introduce stalls in the pageflip sequence of a compositor (if the compositor e.g. switches to a fullscreen client or if it enables a plane). But that requires a few more steps and hoops to jump through. Note that framebuffer creation/destruction is now double-protected - once by the fb_lock and in parts by the idr_lock. The later would be unnecessariy if framebuffers would have their own idr allocator. But that's material for another patch (series). v2: Properly initialize the fb->filp_head list in _init, otherwise the newly added WARN to check whether the fb isn't on a fpriv list any more will fail for driver-private objects. v3: Fixup two error-case unlock bugs spotted by Richard Wilbur. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter

omapdrm: use modeset_lock_all

2013-01-20T21:16:53Z

I've left the locking in the debugfs code as-is, it's essentially just used to keep the framebuffer object alive (which won't be necessary any more later on). We don't need fb refcounting either, since the new mode_config.fb_lock ensures that the framebuffers can't disappear (once mode_config.mutex doesn't guarantee this any more later on in the series). The fbcon restore needs all modeset locks. The crtc callbacks seem to only need the crtc locks, but I've quickly discussed things with Rob Clark and he's fine with just using modeset_lock_all for those, too. He'll look into converting things over later. Reviewed-by: Rob Clark Signed-off-by: Daniel Vetter