* 'intel/drm-intel-next' of ../drm-next: (266 commits)
drm/i915: Avoid circular locking from intel_fbdev_fini()
drm/i915: mark display port DPMS state as 'ON' when enabling output
drm/i915: Skip pread/pwrite if size to copy is 0.
drm/i915: avoid struct mutex output_poll mutex lock loop on unload
drm/i915: Rephrase pwrite bounds checking to avoid any potential overflow
drm/i915: Sanity check pread/pwrite
drm/i915: Use pipe state to tell when pipe is off
drm/i915: vblank status not valid while training display port
drivers/gpu/drm/i915/i915_gem.c: Add missing error handling code
drm/i915: Don't mask the return code whilst relocating.
drm/i915: If the GPU hangs twice within 5 seconds, declare it wedged.
drm/i915: Only print 'generating error event' if we actually are
drm/i915: Try to reset gen2 devices.
drm/i915: Clear fence registers on GPU reset
drm/i915: Force the domain to CPU on unbinding whilst wedged.
drm: Move the GTT accounting to i915
drm/i915: Fix refleak during eviction.
i915: Added function to initialize VBT settings
drm/i915: Remove redundant deletion of obj->gpu_write_list
drm/i915: Make get/put pages static
...
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>
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 <chris@chris-wilson.co.uk>
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: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
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 <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
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: Chris Wilson <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
When the GPU is reset, the fence registers are invalidated, so release
the objects and clear them out.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
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: Chris Wilson <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
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 <chris@chris-wilson.co.uk>
