- 21 Nov, 2012 14 commits
-
-
Paulo Zanoni authored
This is a full revert of 59c859d6: drm/i915: account for only one PCH receiver on Haswell Now that the PCH code is fixed to be able use the only PCH transcoder independently of the pipe and CPU transcoder, we can revert this. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> [danvet: Resolve conflict due to the rebasing of dinq on top of drm-next.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
If we accumulate unpin tasks because we are pageflipping faster than the system can schedule its workers, we can effectively create a pin-leak. The solution taken here is to limit the number of unpin tasks we have per-crtc and to flush those outstanding tasks if we accumulate too many. This should prevent any jitter in the normal case, and also prevent the hang if we should run too fast. Note: It is important that we switch from the system workqueue to our own dev_priv->wq since all work items on that queue are guaranteed to only need the dev->struct_mutex and not any modeset resources. For otherwise if we have a work item ahead in the queue which needs the modeset lock (like the output detect work used by both polling or hpd), this work and so the unpin work will never execute since the pageflip code already holds that lock. Unfortunately there's no lockdep support for this scenario in the workqueue code. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991Reported-and-tested-by:
Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Added note about workqueu deadlock.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56337Signed-off-by:
-
Daniel Vetter authored
But disabled by default. This essentially reverts commit bcd5023c Author: Dave Airlie <airlied@redhat.com> Date: Mon Mar 14 14:17:55 2011 +1000 drm/i915: disable opregion lid detection for now but leaves the autodetect mode disabled. There's also the explicit lid status option added in commit fca87409 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 17 13:44:48 2011 +0000 drm/i915: Add a module parameter to ignore lid status Which overloaded the meaning for the panel_ignore_lid parameter even more. To fix up this mess, give the non-negative numbers 0,1 the original meaning back and use negative numbers to force a given state. So now we have 1 - disable autodetect, return unknown 0 - enable autodetect -1 - force to disconnected/lid closed -2 - force to connected/lid open v2: My C programmer license has been revoked ... v3: Beautify the code a bit, as suggested by Chris Wilson. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27622Tested-by:
Andreas Sturmlechner <andreas.sturmlechner@gmail.com> Reviewed-by:
-
Takashi Iwai authored
This patch adds the missing code to send ELD for Haswell DisplayPort, based on Xingchao's original patch. A test was performed with HSW-D machine and NEC EA232Wmi DP monitor. Cc: Xingchao Wang <xingchao.wang@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Chris Wilson authored
In order to prevent reaping of the object whilst setting it up to handle the pagefault, we need to mark it as pinned. This has the nice side-effect of eliminating some special cases from the pagefault handler as well! Signed-off-by:
-
Chris Wilson authored
In the circumstances that the shrinker is allowed to steal the mutex in order to reap pages, we need to be careful to prevent it operating on the current object and shooting ourselves in the foot. Signed-off-by:
-
Chris Wilson authored
The intention of checking obj->gtt_offset!=0 is to verify that the target object was listed in the execbuffer and had been bound into the GTT. This is guarranteed by the earlier rearrangement to split the execbuffer operation into reserve and relocation phases and then verified by the check that the target handle had been processed during the reservation phase. However, the actual checking of obj->gtt_offset==0 is bogus as we can indeed reference an object at offset 0. For instance, the framebuffer installed by the BIOS often resides at offset 0 - causing EINVAL as we legimately try to render using the stolen fb. Signed-off-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Chris Wilson authored
Now that we always restore the HWS registers (both physical and GTT virtual addresses) when re-initialising the rings, we can eliminate the superfluous save/restore of the register across suspend and resume. Signed-off-by:
-
Ben Widawsky authored
drivers/gpu/drm/i915/i915_drv.h:1545:2: warning: '______f' is static but declared in inline function 'i915_gem_chipset_flush' which is not static Reported-by:
kbuild test robot <fengguang.wu@intel.com> dri-devel-Reference: <50a4d41c.586VhmwghPuKZbkB%fengguang.wu@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Damien Lespiau authored
ILK+ have this register on the PCH. This check was triggering unclaimed writes. Signed-off-by:
-
Daniel Vetter authored
Jani Nikula noticed that the parentheses are wrong and we & the bit with the register address instead of the read-back value. He sent a patch to correct that. On second look, we write the same register in the previous line, and the w/a seems to be to set FDI_RX_PHASE_SYNC_POINTER_OVR to enable the logic, then keep always set FDI_RX_PHASE_SYNC_POINTER_OVR and toggle FDI_RX_PHASE_SYNC_POINTER_EN before/after enabling the pc transcoder. So the right things seems to be to simply kill the 2nd write. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Chris Wilson authored
The bspec was recently updated to remove the ability to update the semaphore using the MI_SEMAPHORE_BOX command, the ability to wait upon the semaphore value remained. Instead the advice is to update the register using the MI_LOAD_REGISTER_IMM command. In cursory testing, semaphores continue to function - the question is whether this fixes some of the deadlocks where the semaphore registers contained stale values? Signed-off-by:
-
Wei Shun Chang authored
[pzanoni: rebase, print it's an LP PCH] Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Signed-off-by:
-
Jean Delvare authored
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. This optimization rips 32 bytes of binary code on x86_64. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Signed-off-by:
-
- 20 Nov, 2012 26 commits
-
-
Thomas Hellstrom authored
Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Brian Paul <brianp@vmware.com> Reviewed-by:
Dmitry Torokhov <dtor@vmware.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
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:
-
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:
-
