Commit 219adae1 cached the EDID found during LVDS init, but in the
process prevented the init routine from discovering the preferred
fixed-mode for the panel. This was causing us to guess the correct mode,
which sometimes is wide of the mark.
Reported-and-tested-by: NJon Masters <jonathan@jonmasters.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.

Cherry-picked from 6aa56062.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31404Tested-by: NZhao Jian <jian.j.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and so prevent a potential circular reference:

  [ INFO: possible circular locking dependency detected ]
  2.6.37-rc1-uwe1+ #4
  -------------------------------------------------------
  Xorg/1401 is trying to acquire lock:
   (&mm->mmap_sem){++++++}, at: [<c01e4ddb>] might_fault+0x4b/0xa0

  but task is already holding lock:
   (&dev->struct_mutex){+.+.+.}, at: [<f869c3ac>]
  i915_mutex_lock_interruptible+0x3c/0x60 [i915]

  which lock already depends on the new lock.

When the locking around the pwrite ioctl was simplified, I did not spot
that the phys path never took any locks and so we introduced this
potential circular reference.
Reported-by: NUwe Helm <uwe.helm@googlemail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NZhenyu Wang <zhenyu.z.wang@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We should enable FDI normal training on Sandybridge/CPT system
as well.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
[ickle: removed unrelated chunks]
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Fixes issue where i915_gfx_val was reporting values several
orders of magnitude higher than physically possible (without
leaving scorch marks on my thighs at least.)
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On some stepping of SNB cpu, the first command to be parsed in BLT
command streamer should be MI_BATCHBUFFER_START otherwise the GPU
may hang.

(cherry picked from commit 8d19215b)

Conflicts:

	drivers/gpu/drm/i915/intel_ringbuffer.c
	drivers/gpu/drm/i915/intel_ringbuffer.h
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Part of the issue here was that Eric slipped in a debug hack for
testing the i915 IPS code before the intel_ips.c driver had landed.
This caused the driver to always use the full range of frequencies,
which is only legal when IPS tells us we have the headroom.  Once that
hack was removed, there was confusion about the driver's frequency
clamping variables: max_delay is the driver's current limit on the
highest frequency the IPS driver wants us to use, while dev_priv->fmax
is the hardware-reported limit that the IPS driver can increase up to.

Tested with IPS driver loaded or not.  Note that on Ironlake systems
without the IPS driver loaded this will result in a performance
reduction, and the inital warmup of frequency limits can impact
benchmarking on systems with IPS loaded.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
[ickle: demoted a debugging printk]
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

2.6.36 appears to respect the 0400 mode we assigned to the parameter
preventing it from being adjusted after loading. However, this is safe
to adjust at runtime.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31311Reported-by: NFernando Lemos <fernandotcl@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

In case of an opregion signature mismatch in intel_opregion_setup(),
iounmap the correct address.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It is possible for the active list to only contain a read-only buffer so
that the ring->gpu_write_list remains entry. This leads to an
inconsistency between i915_gpu_is_active() and i915_gpu_idle() causing
an infinite spin during the shrinker and an assertion failure that
i915_gpu_idle() does indeed flush all buffers from the active lists.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

"depth" should be signed in case packed_depth_bytes() returns -EINVAL.

This probably doesn't make a difference at runtime.  In the original
code we would return -EINVAL later if (rec->offset_Y % 4294967274) is
non-zero.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Hi,

while I looked through your changes in drm-intel git tree (as I've got
a pressure for supporting DisplayPort audio), I stumbled on the
possible bug in the commit a9756bb5

	Author: Zhenyu Wang <zhenyuw@linux.intel.com>
	Date:   Sun Sep 19 13:09:06 2010 +0800
	drm/i915: Enable DisplayPort audio

In this commit, you changed the return value of g4x_dp_detect()
to "bit", but it should be "status", I suppose.

[ickle: mea culpa.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31094Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Keep the current interface but ignore the KM_type and use a stack based
approach.

The advantage is that we get rid of crappy code like:

	#define __KM_PTE			\
		(in_nmi() ? KM_NMI_PTE : 	\
		 in_irq() ? KM_IRQ_PTE :	\
		 KM_PTE0)

and in general can stop worrying about what context we're in and what kmap
slots might be appropriate for that.

The downside is that FRV kmap_atomic() gets more expensive.

For now we use a CPP trick suggested by Andrew:

  #define kmap_atomic(page, args...) __kmap_atomic(page)

to avoid having to touch all kmap_atomic() users in a single patch.

[ not compiled on:
  - mn10300: the arch doesn't actually build with highmem to begin with ]

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
Acked-by: NRik van Riel <riel@redhat.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NChris Metcalf <cmetcalf@tilera.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Miller <davem@davemloft.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Li Zefan <lizf@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

... to prevent flush processing of an idle (or even absent) ring.

This fixes a regression during suspend from 87acb0a5.
Reported-and-tested-by: NAlexey Fisher <bug-track@fisher-privat.net>
Tested-by: NPeter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When the object has been written to by the gpu it remains on the ring
until its flush has been retired. However, when the object is moving to
the ring and the associated cache needs to be invalidated, we need to
perform the flush on the target ring, not the one it came from (which is
NULL in the reported case and so the flush was entirely absent).
Reported-by: NPeter Clifton <pcjc2@cam.ac.uk>
Reported-and-tested-by: NAlexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This should fix the error along the reset path were we tried to clear the
tail register by setting it to 0, but were in fact setting it to the
current value and complaining when it did not reset to 0.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Whilst moving the code around in 9af90d19, I dropped the or'ing in of
new write domains which would zero out the write domain for a render
target if later reused as a source later in the batch. This meant that
we might drop a required flush before reading from the render target.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31043
Reported-by: xunx.fang@intel.com
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This block is only used when detecting whether the connector is HDMI and
never again, so scope the variable to the detection routine.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This patch enables the sending of AVI infoframes in
drivers/gpu/drm/i915/intel_hdmi.c.

My receiver currently loses sync when the HDMI output on my computer
(DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to
1920x1080 as part of the boot. Fixable by switching inputs on the receiver
a couple of times.

With this patch, my receiver has not lost sync yet (> 40 tries).

Fourth version, now based on drm-intel-next from:
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git

Two questions still remain:

I'm assuming that the sdvo hardware also stores a header ECC byte in
the MSB of the first dword - is this correct?

Does the SDVOB and SDVOC handling in intel_hdmi_set_avi_infoframe()
look correct?
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Block execbuffer for the fb to be flipped away, not the one that is to
be flipped in.

[ickle: rewritten for -next]
Signed-off-by: NChia-I Wu <olvaffe@gmail.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NKristian Høgsberg <krh@bitplanet.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

So remove the redundant bit in the capabilities block and
s/IS_IRONLAKE/IS_GEN5/.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Based on an original patch by Zhenyu Wang, this initializes the BLT ring for
SandyBridge and enables support for user execbuffers.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... before someone tries to use it. The code both calls
intel_ring_begin/advance() and open-codes the bookkeeping performed by
those two functions.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In commit 8187a2b7, the number of dwords used in the ringbuffer for
executing the batch buffer was erroneously changed from 2 to 4.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If the userspace driver is using a constant relocation array with a
static buffer, they will pass the same relocation array back to the
kernel. So we *do* need to update the presumed offset value in those
relocations to reflect the current object so that they remain correct
with future batchbuffers and we avoid the necessity of having to suspend
execution and perform redundant relocations.

Fixes the regression introduced by 12f889c for applications using
absolute addressing on trees of buffer (i.e. the current consumers of
libdrm_intel.so).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30996Reported-by: NWang, Jinjin <jinjin.wang@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

To handle retirements, we need per-ring tracking of active objects.
To handle evictions, we need global tracking of active objects.

As we enable more rings, rebuilding the global list from the individual
per-ring lists quickly grows tiresome and overly complicated. Tracking the
active objects in two lists is the lesser of two evils.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... by always initialising the empty ringbuffer it is always then safe
to check whether it is active.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The most frequent relocation within a batchbuffer is a contiguous sequence
of vertex buffer relocations, for which we can virtually eliminate the
drm_gem_object_lookup() overhead by caching the last handle to object
translation.

In doing so we refactor the pin and relocate retry loop out of
do_execbuffer into its own helper function and so improve the error
paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

One of the primarily consumers of the i915 driver is X, a large signal
driven application. Frequently when writing into the buffers, there is a
pending signal which causes us not to take the interruptible lock but
then we need to take that same lock around the object unreference. By
rearranging the code to do the interruptible lock as the first check, we
can avoid the frequent additional locking around the unreference.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

"userpace" -> "userspace"
Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... to avoid the double acquisition along fast[er] paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... to avoid reacquiring it to drop the object reference count on
exit. Note we have to make sure we now drop (and reacquire) the lock
around acquiring the mm semaphore on the slow paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... in the hope that it makes the atomic fast paths more likely.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

After allocation a handle for the fresh object, we know that we can
safely drop the refcnt without triggering a free so we do not need the
mutex. Strangely, this mutex acquisition is the one that appears on
driver profiles.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid an early eviction of the batch buffer into the uncached GTT
domain, and so do the relocation fixup in cacheable memory.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... perform an access validation check up front instead and copy them in
on-demand, during i915_gem_object_pin_and_relocate(). As around 20% of
the CPU overhead may be spent inside vmalloc for the relocation entries
when submitting an execbuffer [for x11perf -aa10text], the savings are
considerable and result in around a 10% throughput increase [for glyphs].
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>