Figuring out which pipe bpp to use is a bit painful.  It depends on both
the encoder and display configuration attached to a pipe.  For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering.  But driving that same
framebuffer to a DisplayPort output on another pipe means using 8bpc and
no dithering.

So split out and enhance the code to handle the various cases, returning
an appropriate pipe bpp as well as whether dithering should be enabled.

Save the resulting pipe bpp in the intel_crtc struct for use by encoders
in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This may not be the default value, so pull the bpc out of the pipe reg
and write it to the DP transcoder so proper dithering and signaling
occurs.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This prevents us from setting reserved or incorrect bits on CougarPoint.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

These bits are reserved on ILK+ (ILK+ provides this feature in the
transcoder and pipe configuration instead, which we already set).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

In an attempt to fix 38862 and 38863.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-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>

As pointed out by Dan Carpenter, it was seemingly possible to hit an error
whilst mapping the buffer for the regs (except the only likely error
returns should not happen during init) and so leak a pin count on the
bo. To handle this we would need to reacquire the struct mutex, so for
simplicity rearrange for the lock to be held for the entire function.
For extra pedagogy, test that we only call init once.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

They use the same register interfaces, so we can simply enable the
existing code on IVB.

v2:
  - resolve conflict with ring freq scaling, we can enable it too
v3:
  - resolve conflict again, this time on drm-intel-next
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Reported-by: NPavel Roskin <proski@gnu.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38777
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Lots of register access in these functions, some of which requires the
struct mutex.

These functions now hold the struct mutex across the calls to
i915_save_display and i915_restore_display, and so the internal mutex
calls in those functions have been removed. To ensure that no-one else
was calling them (and hence violating the new required locking
invarient), those functions have been made static.

gen6_enable_rps locks the struct mutex, and so i915_restore_state
unlocks the mutex around calls to that function.
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 ring frequency scaling table tells the PCU to treat certain GPU
frequencies as if they were a given CPU frequency for purposes of
scaling the ring frequency.  Normally the PCU will scale the ring
frequency based on the CPU P-state, but with the table present, it will
also take the GPU frequency into account.

The main downside of keeping the ring frequency high while the CPU is
at a low frequency (or asleep altogether) is increased power
consumption.  But then if you're keeping your GPU busy, you probably
want the extra performance.

v2:
  - add units to debug table header (from Eric)
  - use tsc_khz as a fallback if the cpufreq driver doesn't give us a freq
    (from Chris)
v3:
  - fix comments & debug output
  - remove unneeded force wake get/put
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Konstantin Belousov pointed out that 4697995b replaced the generic
i915_driver_irq_*install() functions with chipset specific routines
accessible only through driver->irq_*install(). So update the sanity
check in i915_request_wait() to match.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
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>

When auditing the locking in i915_gem.c (for a prospective change which
I then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it.

Since one is in initial setup and the other in driver unload, I'm
guessing the mutex is not required for either; but post a patch in case
it is.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The interface to ->truncate_range is changing very slightly: once "tmpfs:
take control of its truncate_range" has been applied, this can be applied.
 For now there is only a slight inefficiency while this remains unapplied,
but it will soon become essential for managing shmem's use of swap.

Change i915_gem_object_truncate() to use shmem_truncate_range() directly:
which should also spare i915 later change if we switch from
inode_operations->truncate_range to file_operations->fallocate.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Soon tmpfs will stop supporting ->readpage and read_cache_page_gfp(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.

Make i915_gem_object_get_pages_gtt() use shmem_read_mapping_page_gfp() in
the one place it's needed; elsewhere use shmem_read_mapping_page(), with
the mapping's gfp_mask properly initialized.

Forget about __GFP_COLD: since tmpfs initializes its pages with memset,
asking for a cold page is counter-productive.

Include linux/shmem_fs.h also in drm_gem.c: with shmem_file_setup() now
declared there too, we shall remove the prototype from linux/mm.h later.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Soon tmpfs will stop supporting ->readpage and read_mapping_page(): once
"tmpfs: add shmem_read_mapping_page_gfp" has been applied, this patch can
be applied to ease the transition.

ttm_tt_swapin() and ttm_tt_swapout() use shmem_read_mapping_page() in
place of read_mapping_page(), since their swap_space has been created with
shmem_file_setup().
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When auditing the locking in i915_gem.c (for a prospective change which I
then abandoned), I noticed two places where struct_mutex is not held
across GEM object manipulations that would usually require it.  Since one
is in initial setup and the other in driver unload, I'm guessing the mutex
is not required for either; but post a patch in case it is.
Signed-off-by: NHugh Dickins <hughd@google.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Use the blit ring for submitting flips since the render ring doesn't
generate flip complete interrupts.

Fixes bugs:

	https://bugs.freedesktop.org/show_bug.cgi?id=38362
	https://bugs.freedesktop.org/show_bug.cgi?id=38392
	https://bugs.freedesktop.org/show_bug.cgi?id=38393Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NJian J Zhao <jian.j.zhao@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This makes things a little clearer and prevents us from running old code
on a new chipset that may not be supported.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewied-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Even if the object is no longer in the GTT domain, there may still be
a user space mapping which needs to be released.

Without this fix, render-based text (mostly in firefox) would
occasionally get corrupted when the system was under load.
Signed-off-by: NKeith Packard <keithp@keithp.com>

A voltage value of 0xff01 requires that the driver
look up the max voltage for the board based using the
atom SetVoltage command table.

Setting the proper voltage should fix stability on
some newer asics.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The field is encoded:
0 = 4 banks
1 = 8 banks
2 = 16 banks
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The lock must be held for the saving and restoring of VGA state.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
CC: Alexander Zhaunerchyk <alex.vizor@gmail.com>
CC: Andrey Rahmatullin <wrar@wrar.name>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This reverts commit 4a684a41.
Userland has always been required to set the object's domain to GTT
before using it through a GTT mapping, it's not something that the
kernel is supposed to enforce.  (The pagefault support is so that we
can handle multiple mappings without userland having to pin across
them, not so that userland can use GTT after GPU domains without
telling the kernel).

Fixes 19.2% +/- 0.8% (n=6) performance regression in cairo-gl
firefox-talos-gfx on my T420 latop.
Signed-off-by: NKeith Packard <keithp@keithp.com>

...we need to apply exactly the same workaround for missing interrupts
from BSD as for the BLT ring, apparently.

See also commit 498e720b
(drm/i915: Fix gen6 (SNB) missed BLT ring interrupts).

Reported-and-tested-by: nkalkhof@web.de
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38529Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This change got placed in the ironlake path instead of the 9xx path
during a recent code shuffle.
Signed-off-by: NKeith Packard <keithp@keithp.com>

0xff01 is not an actual voltage value, but a flag
for the driver.  If the power state as that value,
skip setting the voltage.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this printk isn't really useful, just drop it for now.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since we were calling the wptr function before checking if the IH was
even enabled, or the GPU wasn't shutdown, we'd get spam in the logs when
the GPU readback 0xffffffff. This reorders things so we return early
in the no IH and GPU shutdown cases.

Reported-and-tested-by: ManDay on #radeon
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is used during phy init to set up the phy for DP.  This may
fix DP problems on DCE3.2 cards.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Certain revisions of the vbios on DCE3.2 cards have a bug
in the transmitter control table which prevents duallink from
being enabled properly on some cards.  The action switch statement
jumps to the wrong offset for the OUTPUT_ENABLE action.  The fix
is to use the ENABLE action rather than the OUTPUT_ENABLE action
on the affected cards.  In fixed version of the vbios, both
actions jump to the same offset, so the change should be safe.
Reported-and-tested-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DDX modifies DMA_SEMAPHORE on nv50 in order to implement sync-to-vblank,
things will go very wrong for cross-channel sync after this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

While parsing the perf table, there is no check if
the num of entries read from the vbios is less than
the currently allocated number.

In case of a buggy vbios this will cause overwriting
of kernel memory, causing aditional problems.

Add a simple check in order to prevent the case
Signed-off-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The failure appeared in dmesg as:

[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on 35064155, at 35064155], missed IRQ?

This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.

v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)

Cc: stable@kernel.org
Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1]
Tested-by: Eric Anholt <eric@anholt.net> [v1,v3]
	   (incidence of the bug with a testcase went from avg 2/1000 to
	   0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394Signed-off-by: NDave Airlie <airlied@redhat.com>

The existing code assumed scratch registers in a number
of places while in most cases we are be using writeback
and events rather than scratch registers.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DP clock and lanes were not set properly for DP bridges.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>