This change enables the use of displays where the vbt table just
contains inappropriate values, but either the vesa defaults or
the video=... modes do something sensible with the attached display.

The problem happens with an embedded board that contains vbt bios
tables that do not match the attached display.  Using this change and
the appropriate kernel boot command line they are able to use an
otherwise completely unusable secondary display on that embedded
board.
Reviewed-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NMathias Froehlich <Mathias.Froehlich@web.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we don't have a sufficient number of free entries in the FIFO, we
proceed to do a write anyway. With this check we should have a clue if
that write actually failed or not.

After some discussion with Daniel Vetter regarding his original
complaint, we agreed upon this.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is similar to a patch I wrote several months ago. It's been updated
for the new FORCEWAKE_MT. As recommended by Chris Wilson, use WARN()
instead of DRM_ERROR, so we can get a backtrace.

This shouldn't impact performance too much as the extra register read
can replace the POSTING_READ we had previously.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to unconditionally enable ppgtt for two reasons:
- Windows uses this on snb and later.
- We need the basic hw support to work before we can think about real
  per-process address spaces and other cool features we want.

But Chris Wilson was complaining all over irc and intel-gfx that this
will blow up if we don't have a module option to disable it. Hence add
one, to prevent this.

ppgtt support seems to slightly change the timings and make crashy
things slightly more or less crashy. Now in my testing and the testing
this got on troublesome snb machines, it seems to have improved things
only. But on ivb it makes quite a few crashes happen much more often,
see

https://bugs.freedesktop.org/show_bug.cgi?id=41353

Luckily Eugeni Dodonov seems to have a set of workarounds that fix
this issue.

v2: Don't try to enable ppgtt on pre-snb.

v3: Pimp commit message and make Chris Wilson less grumpy by adding a
module option.

v4: New try at making Chris Wilson happy.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have to do this manually. Somebody had a Great Idea.

I've measured speed-ups just a few percent above the noise level
(below 5% for the best case), but no slowdows. Chris Wilson measured
quite a bit more (10-20% above the usual snb variance) on a more
recent and better tuned version of sna, but also recorded a few
slow-downs on benchmarks know for uglier amounts of snb-induced
variance.

v2: Incorporate Ben Widawsky's preliminary review comments and
elaborate a bit about the performance impact in the changelog.

v3: Add a comment as to why we don't need to check the 3rd memory
channel.

v4: Fixup whitespace.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Along with the previous patch to make the reset operation protected by
the gt_lock as well, this ensures that all register read operations
will occur with the forcewake hardware enabled. As an added bonus,
this makes read operations more efficient by taking the spinlock only
once per read instead of twice.
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

LLC is not SNB/IVB-specific, so we should check for it in a more generic
way.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fix function name in comments, a left-over from when i965_reset was
renamed to i915_reset.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After checking the specs and discussing with Jesse, turns out CxSR is not
available on Ironlake and gen5, and its advertisement on the device
description is misleading.
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>