The GATT is a write-only set of registers, reading from them in the
manner of i915_gtt_to_phys() is supposed to be undefined. However a
simple solution exists as we allocate linear memory from the stolen
area, we can simply add the block offset to the base register. As a
side-effect we recover all the unused stolen GTT entries and so enlarge
our aperture.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

After a GPU reset, the backlight controller registers may be also reset
to 0. In that case we should restore those to the original values
programmed by the BIOS. Note that we still lack the code to handle the
case where the BIOS failed to program those registers at all...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We were reading our 64-bit value in I915_READ64 and returning 32 bits
of it.  The restoration of fence regs at resume then had a zero end
value, and the fence had no effect.

Version 2: Split register access functions into per-size versions

Sharing code between different sizes seemed reasonable when we only
needed a single copy, but as 64-bit access requires its own version,
it makes sense to just split them out for each size.
Reported-by: NPeter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>
[ickle: use a macro to create the various read/write routines]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This has proven sufficient to recover from a hang of the GPU using the
gem_bad_blit test while at the KMS console then starting X.  When
attempting the same during an X session, the timer doesn't appear to
trigger.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It isn't used for the hangcheck, which does its work right from the
timer trigger, but hangcheck can lead to error state recording, which
is run off of the workqueue.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When trying to diagnose mysterious errors on resume, capture the
display register contents as well.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The pinned buffers are useful for diagnosing errors in setting up state
for the chipset, which may not necessarily be 'active' at the time of
the error, e.g. the cursor buffer object.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Under KMS, restoring the cursor is handled upon modeswitch in order to
avoid enabling an undefined set of registers. At the moment, the cursor
is restored before the aperture and modes are fully setup causing some
invalid access during resume, such as:

  PGTBL_ER: 0x00040000
    Invalid GTT entry during Cursor Fetch

Fix this by only performing cursor register save/restore under UMS where
it is done in the correct sequence.
Reported-by: NArkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Commit 2549d6c2 removed the vmalloc used for temporary storage of the
relocation lists used during execbuffer. However, our use of vmalloc was
being protected by an integer overflow check which we do want to
preserve!
Reported-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Frame buffer compression is broken on Ironlake due to buggy hardware.
Currently it is disabled through chicken bits, but it still consumes
over 1W more than if we simply never attempt to enable the FBC code
paths.
Signed-off-by: NAlex Shi <alex.shi@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Both IBX and CPT have an automatic hotplug detection mode which appears to work reliably enough
that we can dispense with the manual force hotplug trigger stuff. This means that
hotplug detection is as simple as reading the current hotplug register values.

The first time the hotplug detection is activated, the code synchronously waits for a hotplug
sequence in case the hardware hasn't bothered to do a detection cycle since being initialized.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We will use this structure in future patches to store CRT specific
information on the encoder.

Split out and tweaked from a patch by Keith Packard.
Signed-off-by: NKeith Packard <keithp@kithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Linus Torvalds found that it was rather trivial to trigger a system
freeze:

  In fact, with lockdep, I don't even need to do the sysrq-d thing: it
  shows the bug as it happens. It's the X server taking the same lock
  recursively.

  Here's the problem:

    =============================================
    [ INFO: possible recursive locking detected ]
    2.6.37-rc2-00012-gbdbd01ac #7
    ---------------------------------------------
    Xorg/2816 is trying to acquire lock:
     (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c626c>] i915_gem_fault+0x50/0x17e

    but task is already holding lock:
     (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a

    other info that might help us debug this:
    2 locks held by Xorg/2816:
     #0:  (&dev->struct_mutex){+.+.+.}, at: [<ffffffff812c403b>] i915_mutex_lock_interruptible+0x28/0x4a
     #1:  (&mm->mmap_sem){++++++}, at: [<ffffffff81022d4f>] page_fault+0x156/0x37b

This recursion was introduced by rearranging the locking to avoid the
double locking on the fast path (4f27b5d and fbd5a26d) and the
introduction of the prefault to encourage the fast paths (b5e4f2b). In
order to undo the problem, we rearrange the code to perform the access
validation upfront, attempt to prefault and then fight for control of the
mutex.  the best case scenario where the mutex is uncontended the
prefaulting is not wasted.
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Both IBX and CPT have an automatic hotplug detection mode which appears to work reliably enough
that we can dispense with the manual force hotplug trigger stuff. This means that
hotplug detection is as simple as reading the current hotplug register values.

The first time the hotplug detection is activated, the code synchronously waits for a hotplug
sequence in case the hardware hasn't bothered to do a detection cycle since being initialized.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We will use this structure in future patches to store CRT specific
information on the encoder.

Split out and tweaked from a patch by Keith Packard.
Signed-off-by: NKeith Packard <keithp@kithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and so hide the flushes from tracing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we may bind an object with the correct alignment, but with an invalid
size, it may pass the current checks on whether the object may be reused
with a fence.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

g33/pineview doesn't have any alignment constrains for unfenced tiled
buffers. But older chips have. Fix this.

Problem introduced in a00b10c3.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

An old and oft reported bug, is that of the GPU hanging on a
MI_WAIT_FOR_EVENT following a mode switch. The cause is that the GPU is
waiting on a scanline counter on an inactive pipe, and so waits for a
very long time until eventually the user reboots his machine.

We can prevent this either by moving the WAIT into the kernel and
thereby incurring considerable cost on every swapbuffers, or by waiting
for the GPU to retire the last batch that accesses the framebuffer
before installing a new one. As mode switches are much rarer than swap
buffers, this looks like an easy choice.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28964
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29252Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

We only ever used the PRB0, neglecting the secondary ring buffers, and
now with the advent of multiple engines with separate ring buffers we
need to excise the anachronisms from our code (and be explicit about
which ring we mean where). This is doubly important in light of the
FORCEWAKE required to read ring buffer registers on SandyBridge.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit 629e8941.

Before reading ring register, set FORCE_WAKE bit to prevent GT core
power down to low power state, otherwise we may read stale values.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
[ickle: added a udelay which seemed to do the trick on my SNB]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... as it has been replaced by per-ring waiters.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We use i915_gem_object_get_fence_reg() to do LRU tracking of the fence
registers, so stop trying to be too clever when pinning the fb->obj.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Fix many small bugs in I2C adapter registration:
* Properly reject unsupported GPIO pin.
* Fix improper use of I2C_NAME_SIZE (which is the size of
  i2c_client.name, not i2c_adapter.name.)
* Prefix adapter names with "i915" so that the user knows what the
  I2C channel is connected to.
* Fix swapped characters in the string used to name the GPIO-based
  adapter.
* Add missing comma in gmbus name table.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Coalesce long formats.
Align arguments.
Add missing newlines.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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>

If modeset init failed we attempted to unload the module, before we
finished setting it up and so triggered various oopses.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we use POSTING_READ to flush the write to the register before
proceeding, we do not care what the return value is and similar we do
not care for the read to be recorded whilst tracing register
read/writes.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

These registers are written very frequently, are timing sensitive, and
not particularly relevant to any debugging, so remove the tracepoints
from these.
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This will be used later to hide the frequently written registers
from debug traces in order to increase the signal-to-noise.
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Add two tracepoints at I915_WRITE/READ for tracing down all the
register write and read.
Signed-off-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
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>

Not known to fix any current bugs.
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is not known to fix any particular bugs we have, but the spec
says to do it, and the BIOS hadn't already set it up on my system.
Signed-off-by: NEric Anholt <eric@anholt.net>
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>

The ring buffer registers return 0 whilst idle (for some values of idle)
on early Sandybridge hw. Persevere even when all appears hopeless...
Fortunately the head auto-reporting prevents most hangs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31370Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>