- 28 Nov, 2012 2 commits
-
-
Thomas Hellstrom authored
Document how kref_get_unless_zero should be used and how it helps solve a typical kref / locking problem. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Thomas Hellstrom authored
While hashtab should now be RCU-safe, Add a drm_ht_xxx_api for consumers to use to make it obvious what locking mechanism is used. Document the way the rcu-safe interface should be used. Don't use rcu-safe list traversal in modify operations where we should use a spinlock / mutex anyway. Signed-off-by:
-
- 20 Nov, 2012 38 commits
-
-
Thomas Hellstrom authored
Signed-off-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
-
Thomas Hellstrom authored
Add a resource-private header for common resource definitions Signed-off-by:
-
Thomas Hellstrom authored
Refactor resource management to make it easy to hook up resources that are backed up by buffers. In particular, resources and their backing buffers can be evicted and rebound, if supported by the device. To avoid query deadlocks, the query code is also modified somewhat. Signed-off-by:
-
Thomas Hellstrom authored
Signed-off-by:
-
Thomas Hellstrom authored
This also fixes a bug where the fence manager was left without irq enabled when waiting for fences, causing various errors at module load time Signed-off-by:
-
Thomas Hellstrom authored
Signed-off-by:
-
Thomas Hellstrom authored
Signed-off-by:
-
Thomas Hellstrom authored
Hiding SVGA seems to trigger a VGA screen clear, and with no traces dirty it doesn't seem to repaint Signed-off-by:
-
Maarten Lankhorst authored
This is similar to other platforms that don't allow command submission to buffers locked on the cpu. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by:
-
Thomas Hellstrom authored
Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus cycle on successful reserve. Note that thit commit may be obsoleted by the cross-device reservation work. Signed-off-by:
-
Thomas Hellstrom authored
The mostly used lookup+get put+potential_destroy path of TTM objects is converted to use RCU locks. This will substantially decrease the amount of locked bus cycles during normal operation. Since we use kfree_rcu to free the objects, no rcu synchronization is needed at module unload time. v2: Don't touch include/linux/kref.h v3: Adapt to kref_get_unless_zero return value change Signed-off-by:
-
Thomas Hellstrom authored
This function is intended to simplify locking around refcounting for objects that can be looked up from a lookup structure, and which are removed from that lookup structure in the object destructor. Operations on such objects require at least a read lock around lookup + kref_get, and a write lock around kref_put + remove from lookup structure. Furthermore, RCU implementations become extremely tricky. With a lookup followed by a kref_get_unless_zero *with return value check* locking in the kref_put path can be deferred to the actual removal from the lookup structure and RCU lookups become trivial. v2: Formatting fixes. v3: Invert the return value. Signed-off-by:
-
Thomas Hellstrom authored
TTM base objects will be the first consumer. Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
vmwgfx was its only user and always sets it to the same.. Signed-off-by:
-
Maarten Lankhorst authored
It's always hardcoded to the same value. Signed-off-by:
-
Egbert Eich authored
When trying to obtain an accurate timestamp for the last vsync interrupt in vblank_disable_and_save() we loop until the vsync counter after reading the time stamp is identical to the one before. In the case where no hardware timestamp can be obtained there is probably no point in trying to make sure we remain within the same vsync during the time we obtain the counter. Furthermore we should make sure there's an 'emergency exit' so that we don't end up in an endless loop when the driver get_vblank_timestamp() function doesn't manage to return within the same vsync. This may happen when this function prints out debugging information over a slow (ie serial) line. Signed-off-by:
Egbert Eich <eich@suse.de> Signed-off-by:
-
Daniel Vetter authored
... by properly checking connector->polled. This doesn't matter too much because the polling work itself gets this slightly more right and doesn't set repoll if there's nothing to do. But we can do better. v2: Chris Wilson noticed that I broke polling, since repoll will never ever be set true. Fix this up, and simplify the logic a bit while at it. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Igor Murzov authored
Signed-off-by:
Igor Murzov <e-mail@date.by> Signed-off-by:
-
Tommi Rantala authored
Fix a memory leak by deallocating the memory we got from alloc_apertures(). Signed-off-by:
Tommi Rantala <tt.rantala@gmail.com> Signed-off-by:
-
Tommi Rantala authored
Check for alloc_apertures() memory allocation failure, and propagate an error code in case the allocation failed. Signed-off-by:
-
Tommi Rantala authored
alloc_apertures() already does the assignment for us, so assigning the count member after the alloc_apertures() call is not needed. Signed-off-by:
-
Tommi Rantala authored
Fix a memory leak by deallocating the memory we got from alloc_apertures(). Signed-off-by:
-
Tommi Rantala authored
Check for alloc_apertures() memory allocation failure, and propagate an error code in case the allocation failed. Signed-off-by:
-
Tommi Rantala authored
Check for alloc_apertures() memory allocation failure, and propagate an error code in case the allocation failed. Signed-off-by:
-
Marcin Slusarz authored
It's unused. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Reviewed-by:
-
Marcin Slusarz authored
It's unused. Signed-off-by:
-
Marcin Slusarz authored
All drivers set it to 0 and nothing uses it. Signed-off-by:
-
Akinobu Mita authored
Use hweight32 instead of counting for each bit Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Akinobu Mita authored
Use memchr_inv() to check the specified memory region is filled with zero. Signed-off-by:
-
Imre Deak authored
Jumps in the vblank and page flip event timestamps cause trouble for clients, so we should avoid them. The timestamp we get currently with gettimeofday can jump, so use instead monotonic timestamps. For backward compatibility use a module flag to revert back to using gettimeofday timestamps. Add also a DRM_CAP_TIMESTAMP_MONOTONIC flag that is simply a read only version of the module flag, so that clients can query this without depending on sysfs. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Imre Deak authored
For measuring duration we want to avoid that our start/end timestamps jump, so use monotonic instead of real time for that. Signed-off-by:
-
Daniel Vetter authored
Otherwise if the detect callback reports a different state than what the user forced (rather likely), we continously annoy userspace about a hotplug uevent. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
Actually there's a reason this stuff is there, and it's called commit e58f637b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 20 09:13:36 2010 +0100 drm/kms: Add a module parameter to disable polling The idea has been that users can enable/disable polling at runtime. So the quick hack has been to just re-enable the output polling if xrandr asks for the latest state of the connectors. The problem with that hack is that when we force connectors to another state than what would be detected, we nicely ping-pong: - Userspace calls probe, gets the forced state, but polling starts again. - Polling notices that the state is actually different, wakes up userspace. - Repeat. As that commit already explains, the right fix would be to make the locking more fine-grained, so that hotplug detection on one output does not interfere with cursor updates on another crtc. But that is way too much work. So let's just safe this gross hack by caching the last-seen state of drm_kms_helper_poll for that driver, and only fire up the poll engine again if it changed from off to on. v2: Fixup the edge detection of drm_kms_helper_poll. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49907Tested-by:
Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> Signed-off-by:
-
Daniel Vetter authored
This can help drivers to make somewhat intelligent decisions in their ->detect callback: If the connector is hpd capable and in the unknown state, the driver needs to force a full detect cycle. Otherwise it could just (if it chooses so) to update the connector state from it's hpd handler directly, and always return that in the ->detect callback. Atm only drm/i915 calls drm_mode_config_reset at resume time, so other drivers would need to add that call first before using this facility. Signed-off-by:
-
Daniel Vetter authored
All drivers already have a work item to run the hpd code, so we don't need to launch a new one in the helper code. Dave Airlie mentioned that the cancel+re-queue might paper over DP related hpd ping-pongs, hence why this is split out. Signed-off-by:
-
Daniel Vetter authored
Instead of reusing the polling code for hpd handling, split them up. This has a few consequences: - Don't touch HPD capable connectors in the poll loop. - Only touch HPD capable connectors in drm_helper_hpd_irq_event. - We could run the HPD handling directly (because all callers already use their own work item), but for easier bisect that happens in it's own patch. The ultimate goal is that drivers grow some smarts about which connectors have received a hotplug event and only call the detect code of that connector. But that's a second step. v2: s/hdp/hpd/, noticed by Adam Jackson. I can't type. v3: Split out the work item removal as requested by Dave Airlie. This results in a temporary mode_config.hpd_irq_work item to keep things the same. v4: In the hpd_irq_event handler don't bail out if other bits than HPD are set. This is useful where e.g. hpd is unreliably, but mostly works. Drivers can then set both HPD and POLL flags, and users get the best of both worlds: Quick hotplug feedback if the hpd works, but still reliable detection with the polling. The poll loop already works the same, and doesn't bail if HPD is set. Signed-off-by:
-
