This ensures that no register reads occur while the forcewake state of
the hardware is indeterminate during the reset operation.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No reason to have half of the reset split from the other half.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The problem this patch solves is that the forcewake accounting
necessary for register reads is protected by dev->struct_mutex. But the
hangcheck and error_capture code need to access registers without
grabbing this mutex because we hold it while waiting for the gpu.
So a new lock is required. Because currently the error_state capture
is called from the error irq handler and the hangcheck code runs from
a timer, it needs to be an irqsafe spinlock (note that the registers
used by the irq handler (neglecting the error handling part) only uses
registers that don't need the forcewake dance).

We could tune this down to a normal spinlock when we rework the
error_state capture and hangcheck code to run from a workqueue.  But
we don't have any read in a fastpath that needs forcewake, so I've
decided to not care much about overhead.

This prevents tests/gem_hangcheck_forcewake from i-g-t from killing my
snb on recent kernels - something must have slightly changed the
timings. On previous kernels it only trigger a WARN about the broken
locking.

v2: Drop the previous patch for the register writes.

v3: Improve the commit message per Chris Wilson's suggestions.
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This was forgotten in the original multi-threaded forcewake
conversion:

commit 8d715f00
Author: Keith Packard <keithp at keithp.com>
Date:   Fri Nov 18 20:39:01 2011 -0800

    drm/i915: add multi-threaded forcewake support

Signed-Off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We learned that the ECOBUS register was inside the GT power well, and
so *did* need force wake to be read, so it gets removed from the list
of 'doesn't need force wake' registers.

That means the code reading ECOBUS after forcing the mt_force_wake
function to be called needs to use I915_READ_NOTRACE; it doesn't need
to do more force wake fun as it's already done it manually.

This also adds a comment explaining why the MT forcewake testing code
only needs to call mt_forcewake_get/put and not disable RC6 manually
-- the ECOBUS read will return 0 if the device is in RC6 and isn't
using MT forcewake, causing the test to work correctly.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

This adds a default setting for semaphores parameter, and enables
semaphores by default on IVB.

For now, as semaphores interaction with VTd causes random issues on
SNB, we do not enable them by default. But they can still be enabled
via the semaphores=1 kernel parameter.

v2: enables semaphores on SNB when IO remapping is disabled, with base
on Keith Packard patch.

CC: Daniel Vetter <daniel.vetter@ffwll.ch>
CC: Ben Widawsky <ben@bwidawsk.net>
CC: Keith Packard <keithp@keithp.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42696
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40564
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38862Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. RC6 never works on Ironlake. Make the default
value for the parameter follow these guidelines. Setting the value
to either 0 or 1 will force the specified behavior.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Cc: Ted Phelps <phelps@gnusto.com>
Cc: Peter <pab1612@gmail.com>
Cc: Lukas Hejtmanek <xhejtman@fi.muni.cz>
Cc: Andrew Lutomirski <luto@mit.edu>

On IVB C0+ with newer BIOSes, the forcewake handshake has changed.  There's
now a bitfield for different driver components to keep the GT powered
on.  On Linux, we centralize forcewake handling in one place, so we
still just need a single bit, but we need to use the new registers if MT
forcewake is enabled.

This needs testing on affected machines.  Please reply with your
tested-by if you had problems after a BIOS upgrade and this patch fixes
them.

v2: force MT mode. shift by 16
v3: set MT force wake bits then check ECOBUS

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42923Tested-by: NManoj Iyer <manoj.iyer@canonical.com>
Tested-by: NRobert Hooker <robert.hooker@canonical.com>
Tested-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sun, 30 Oct 2011 19:06:07 -0700
Subject: [PATCH] drm: Make the per-driver file_operations struct const

The DRM layer keeps a copy of struct file_operations inside its
big driver struct... which prevents it from being consistent and static.
For consistency (and the general security objective of having such things
static), it's desirable to get this fixed.

This patch splits out the file_operations field to its own struct,
which is then "static const", and just stick a pointer to this into
the driver struct, making it more consistent with how the rest of the
kernel does this.
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Testing i915_panel_use_ssc for the default value was broken, so the
driver would never autodetect the correct value.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NMichel Alexandre Salim <salimma@fedoraproject.org>
Tested-by: NMichel Alexandre Salim <salimma@fedoraproject.org>
Cc: stable@kernel.org

So that we don't get build failures once the implicit module.h
presence is removed.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

... not DISPLAY_VGA, because we ignore the VGA subclass with our
class_mask.

It confused me until Chris Wilson clued me up.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

With the tracing code in there they are far too big to inline.

.text savings compared to a non force inline kernel:

i915_restore_display                        4393   12036   +7643
i915_save_display                           4295   11459   +7164
i915_handle_error                           2979    6666   +3687
i915_driver_irq_handler                     2923    5086   +2163
i915_ringbuffer_info                         458    1661   +1203
i915_save_vga                                  -    1200   +1200
i915_driver_irq_uninstall                    453    1624   +1171
i915_driver_irq_postinstall                  913    2078   +1165
ironlake_enable_drps                         719    1872   +1153
i915_restore_vga                               -    1142   +1142
intel_display_capture_error_state            784    2030   +1246
intel_init_emon                              719    2016   +1297

and more ...

[AK: these are older numbers, with the new SNB forcewake checks
it will be even worse]
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.

Also, re-initialize the refclk at resume time.
Signed-off-by: NKeith Packard <keithp@keithp.com>

Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for Ironlake and older where it has been seen to
cause trouble with screen updates.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Tested-by: NFrancis Moreau <francis.moro@gmail.com>

Various issues involved with the space character were generating
warnings in the checkpatch.pl file. This patch removes most of those
warnings.
Signed-off-by: NAkshay Joshi <me@akshayjoshi.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NMichael Witten <mfwitten@gmail.com>

This reverts commit 4e20fa65.

Francesco Allertsen still has a broken configuration.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Jesse Barnes and I found a couple of issues where incorrect mode
setting would cause problems with RC6 enabled. We're hopeful that
fixing those will resolve the outstanding issues with a few machines
that had trouble before 3.0 with rc6.

Cc: Pekka Enberg <penberg@kernel.org>
Cc: Francesco Allertsen <fallertsen@gmail.com>
Cc: Ted Phelps <phelps@gnusto.com>
Cc: Gu Rui <chaos.proton@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The read back of the available FIFO entries is vital for system
stability, but extremely costly. However, we only need a guide so as to
avoid eating into the reserved entries and since we are the only
consumer we can cache the read of the count from the last write.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This reverts commit a51f7a66.

We still have a few Ironlake and Sandybridge machines which fail when
RC6 is enabled. Better luck next release?
Signed-off-by: NKeith Packard <keithp@keithp.com>

We'll try again with the new fixes. Prepare to see this reverted when
we get regression reports...
Signed-off-by: NKeith Packard <keithp@keithp.com>

According to the hardware documentation, GDRST is exactly the same as on
Sandybridge.  So simply enable the existing code.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This lets us make the various IRQ functions static and helps avoid
problems like the one fixed in "drm/i915: Use chipset-specific irq
installers" where one of the exported functions was called rather than
the chipset specific version.

This also fixes a UMS-mode bug -- the correct irq functions for IRL
and later chips were only getting loaded in the KMS path.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Provide a parameter to disable hanghcheck. This is useful mostly for
developers trying to debug known problems, and probably should not be
touched by normal users.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

The failure is as follows:

1. Userspace gets forcewake lock, lock count >=1
2. GPU hang/reset occurs (forcewake bit is reset)
3. count is now incorrect

The failure can only occur when using the forcewake userspace lock.

This has the unfortunate consequence of messing up the driver as well as
userspace, unless userspace closes the debugfs file, the kernel will
never end up waking the GT since the refcount will be > 1.

The solution is to try to recover the correct forcewake state based on
the refcount. There is a period of time where userspace reads/writes may
occur after the reset, before the GT has been forcewaked. The interface
was never designed to be a perfect solution for userspace reads/writes,
and the kernel portion is fixed by this patch.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

With FBC disabled by default, it should be safe to enable RC6.  So let's
give it a try.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

FBC has too many corner cases that we don't currently deal with, so
disable it by default so we can enable more important features like RC6,
which conflicts in some configurations.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31742Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

My Q67 / i7-2600 box has rev09 Sandy Bridge graphics.  It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work.  Setting i915.semaphore=0 fixes it.

Semaphores were disabled in a1656b90
in 2.6.38 and were re-enabled by

commit 47ae63e0
Merge: c59a333f 467cffba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 7 12:32:44 2011 +0000

    Merge branch 'drm-intel-fixes' into drm-intel-next

    Apply the trivial conflicting regression fixes, but keep GPU semaphores
    enabled.

    Conflicts:
        drivers/gpu/drm/i915/i915_drv.h
        drivers/gpu/drm/i915/i915_gem_execbuffer.c

(It's worth noting that the offending change is i915_drv.c,
 which is not a conflict.)
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Acked-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a little less confusing than relying on the implicit zeroing of
the dev_priv.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

There are several variants, set feature bits appropriately for both
mobile and desktop parts.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

We can treat PantherPoint as CougarPoint as far as display goes.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

My Q67 / i7-2600 box has rev09 Sandy Bridge graphics.  It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work.  Setting i915.semaphore=0 fixes it.

Semaphores were disabled in a1656b90 ("drm/i915: Disable GPU
semaphores by default") in 2.6.38 but were then re-enabled (by mistake?)
by the merge 47ae63e0 ("Merge branch 'drm-intel-fixes' into
drm-intel-next").

(It's worth noting that the offending change is i915_drv.c, which was
not marked as a conflict - although a 'git show --cc' on the merge does
show that neither parent had it set to 1)
Signed-off-by: NAndy Lutomirski <luto@mit.edu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Provide a reference count to track the forcewake state of the GPU and
give a safe mechanism for userspace to wake the GT. This also potentially
saves a UC read if the GT is known to be awake already.

The reference count is atomic, but the register access and hardware wake
sequence is protected by struct_mutex.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)

However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.
Reported-by: NAndi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Whilst the GT is powered down (rc6), writes to MMADDR are placed in a
FIFO by the System Agent. This is a limited resource, only 64 entries, of
which 20 are reserved for Display and PCH writes, and so we must take
care not to queue up too many writes. To avoid this, there is counter
which we can poll to ensure there are sufficient free entries in the
fifo.

"Issuing a write to a full FIFO is not supported; at worst it could
result in corruption or a system hang."
Reported-and-Tested-by: NMatt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Seems like we are forever to be cursed with buggy firmware, so allow the
user to explicitly set the panel connection status.

Of secondary utility for cases where I run laptops with the lid closed,
but still want to configure the LVDS.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>