- 04 Oct, 2010 5 commits
-
-
Chris Wilson authored
lockdep spots that the fb_info->lock takes the dev->struct_mutex during init (due to the device probing) and so we can not hold dev->struct_mutex when unregistering the framebuffer. Simply reverse the order of initialisation during cleanup and so do the intel_fbdev_fini() before the intel_modeset_cleanup. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk>
-
Keith Packard authored
The display port DPMS state is tracked internally in the display port driver so that when a hotplug event comes along, the driver can know whether to try retraining the link. This doesn't work well if the driver never sets the DPMS state to ON when the output is enabled. Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
-
Keith Packard authored
Cancel the output polling work proc before acquiring the struct mutex to avoid acquiring the work proc mutex with the struct mutex held. This avoids inverting the lock order seen when the work proc runs. Signed-off-by:
-
- 03 Oct, 2010 5 commits
-
-
Chris Wilson authored
... and do the same for pread. Signed-off-by: -
Chris Wilson authored
Move the access control up from the fast paths, which are no longer universally taken first, up into the caller. This then duplicates some sanity checking along the slow paths, but is much simpler. Tracked as CVE-2010-2962. Reported-by:
Kees Cook <kees@ubuntu.com> Signed-off-by:
-
Chris Wilson authored
Conflicts: drivers/gpu/drm/i915/i915_gem_evict.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c
-
Keith Packard authored
Instead of waiting for the display line value to settle, we can simply wait for the pipe configuration register 'state' bit to turn off. Contrarywise, disabling the plane will not cause the display line value to stop changing, so instead we wait for the vblank interrupt bit to get set. And, we only do this when we're not about to wait for the pipe to turn off. Signed-off-by:
-
Keith Packard authored
While the display port is in training mode, vblank interrupts don't occur. Because we have to wait for the display port output to turn on before starting the training sequence, enable the output in 'normal' mode so that we can tell when a vblank has occurred, then start the training sequence. Signed-off-by:
-
- 02 Oct, 2010 2 commits
-
-
Julia Lawall authored
Extend the error handling code with operations found in other nearby error handling code A simplified version of the sematic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ @r@ statement S1,S2,S3; constant C1,C2,C3; @@ *if (...) {... S1 return -C1;} ... *if (...) {... when != S1 return -C2;} ... *if (...) {... S1 return -C3;} // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
-
Chris Wilson authored
The return from move_to_gtt_domain() may indicate a pending signal which needs to handled as opposed to an actual error, for instance, so report the original return value rather than forcing an EINVAL. Signed-off-by:
-
- 01 Oct, 2010 7 commits
-
-
Chris Wilson authored
The issue is that we may become stuck executing a long running shader and continually attempt to reset the GPU. (Or maybe we tickle some bug and need to break the vicious cycle.) So if we are detect a second hang within 5 seconds, give up trying to programme the GPU and report it wedged. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
So far only found registers for i830, i845, i865 and one of those has no effect on i865! At this moment in time, attempting to reset i8xx is a little optimistic... Signed-off-by: -
Chris Wilson authored
When the GPU is reset, the fence registers are invalidated, so release the objects and clear them out. Signed-off-by: -
Chris Wilson authored
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30083Reported-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
-
Chris Wilson authored
Only drm/i915 does the bookkeeping that makes the information useful, and the information maintained is driver specific, so move it out of the core and into its single user. Signed-off-by: -
Chris Wilson authored
Now that we hold onto a reference whilst evicting objects, we need to be sure that we drop all the references taken -- even on the error paths. Signed-off-by:
-
- 30 Sep, 2010 6 commits
-
-
Simon Que authored
Added a function that sets the LVDS values to default settings. This will be called by intel_init_bios before checking for the VBT (video BIOS table). The default values are thus loaded regardless of whether a VBT is found. The default settings in each parse function have been moved to the new function. This consolidates all the default settings into one place. The default dither bit value has been changed from 0 to 1. We can assume that display devices will want dithering enabled. Signed-off-by:
Simon Que <sque@chromium.org> Acked-by:
Olof Johansson <olof@lixom.net> [ickle: fixup for -next] Signed-off-by:
-
Chris Wilson authored
At that point as the object is no longer in any GPU write domain it must not be on the list, so the list_del() is redundant. Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
... and check more regularly. Signed-off-by:
-
- 29 Sep, 2010 3 commits
-
-
Chris Wilson authored
Just reschedule the retire requests again if the device is currently busy. The request list will be pruned along other paths so will never grow unbounded and so we can afford to miss the occasional pruning. Signed-off-by: -
Chris Wilson authored
Replaced by tracepoints. Signed-off-by: -
Chris Wilson authored
This has bitrotted through inuse and superseded by tracing and debugfs. Signed-off-by:
-
- 28 Sep, 2010 8 commits
-
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
This check only appears to succeed when using GMBUS, so we need to skip it if we have fallen back to using GPIO bit banging. Signed-off-by: -
Chris Wilson authored
-
Chris Wilson authored
Signed-off-by: -
Chris Wilson authored
There are several reported instances of GMBUS failing to successfully read the EDID, so revert back to bit banging until the issue is resolved. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30371Signed-off-by:
-
Chris Wilson authored
Besides a couple of bugs when writing more than a single byte along the GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use bit banging instead. Signed-off-by: -
Chris Wilson authored
With multiple rings generating requests independently, the outstanding requests must also be track independently. Reported-by:
Wang Jinjin <jinjin.wang@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30380Signed-off-by:
-
- 27 Sep, 2010 1 commit
-
-
Jesse Barnes authored
The IPS driver needs to know the current power consumption of the GMCH in order to make decisions about when to increase or decrease the CPU and/or GPU power envelope. So fix up the divisions to save the results so the numbers are actually correct (contrary to some earlier comments and code, these functions do not modify the first argument and use it for the result). Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 26 Sep, 2010 3 commits
-
-
Chris Wilson authored
Introduced by 48b956c5, I had thought I had already fixed this. Oh well. Reported-by:
-
Chris Wilson authored
There is no equivalent to mutex_destroy() for spinlocks so just delete the code. Signed-off-by: -
Chris Wilson authored
Daniel Vetter pointed out that in this case is would be clearer and cleaner to use a spinlock instead of a mutex to protect the per-file request list manipulation. Make it so. Signed-off-by:
-
