The ability to save the hardware context upon powering down the render
clock through PWRCTXA is only available on a couple of gen4 chipsets.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We disabled this a while ago as it was inexplicably broken. However, it
now appears to work...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The bulk of the change is to convert the growing list of rings into an
array so that the relationship between the rings and the semaphore sync
registers can be easily computed.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Let's see if we've successfully cleared up all the bugs from last
time...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Magic numbers from the specs. This is supposed to allow the PLL some
variance to improve jitter performance and VCO headroom across
manufacturing and environmental variations.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... it's because setting the Pixel Multiply bits only takes effect once
the PLL is enabled and stable.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Fixes the modesetting on the secondary panel of the Libretto W100 and
presumably many more Ironlake laptops with SDVO LVDS displays.
Reported-and-tested-by: NMatthew Willoughby <mattfredwill@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Use the hardware DDA to calculate the ratio with as much accuracy as is
possible.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

If we leave the registers in a conflicting state then when we attempt
to teardown the active mode, we will not disable the pipes and planes
in the correct order -- leaving a plane reading from a disabled pipe and
possibly leading to undefined behaviour.
Reported-and-tested-by: NAndy Whitcroft <apw@canonical.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32078Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

The pipe is always set to 8BPC, but here we were leaving whatever
previous bits were set by the BIOS in place.
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

With this change, every batchbuffer can use all available fences (save
pinned and scanout, of course) without ever stalling the gpu!

In theory. Currently the actual pipelined update of the register is
disabled due to some stability issues. However, just the deferred update
is a significant win.

Based on a series of patches by Daniel Vetter.

The premise is that before every access to a buffer through the GTT we
have to declare whether we need a register or not. If the access is by
the GPU, a pipelined update to the register is made via the ringbuffer,
and we track the last seqno of the batches that access it. If by the
CPU we wait for the last GPU access and update the register (either
to clear or to set it for the current buffer).

One advantage of being able to pipeline changes is that we can defer the
actual updating of the fence register until we first need to access the
object through the GTT, i.e. we can eliminate the stall on set_tiling.
This is important as the userspace bo cache does not track the tiling
status of active buffers which generate frequent stalls on gen3 when
enabling tiling for an already bound buffer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... otherwise the panel-fitter may be left enabled with random settings
and cause unintended filtering (i.e. blurring of native modes on external
panels).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31942Reported-and-tested-by: NBen Kohler <bkohler@gmail.com>
Tested-by: NCiprian Docan <docan@eden.rutgers.edu>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

A glorified s/obj_priv/obj/ with a net reduction of over a 100 lines and
many characters!
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>

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>

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>

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>

a00b10c3 "Only enforce fence limits inside the GTT" also
added a fenceable/mappable disdinction when binding/pinning buffers.
This only complicates the code with no pratical gain:

- In execbuffer this matters on for g33/pineview, as this is the only
  chip that needs fences and has an unmappable gtt area. But fences
  are only possible in the mappable part of the gtt, so need_fence
  implies need_mappable. And need_mappable is only set independantly
  with relocations which implies (for sane userspace) that the buffer
  is untiled.

- The overlay code is only really used on i8xx, which doesn't have
  unmappable gtt. And it doesn't support tiled buffers, currently.

- For all other buffers it's a bug to pass in a tiled bo.

In short, this disdinction doesn't have any practical gain.

I've also reverted mapping the overlay and context pages as possibly
unmappable. It's not worth being overtly clever here, all the big
gains from unmappable are for execbuf bos.

Also add a comment for a clever optimization that confused me
while reading the original patch by Chris Wilson.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In a00b10c3 "Only enforce fence limits inside the GTT"
Chris Wilson implemented an optimization to only pin framebuffers
as mappable for crtc_set_base (but not for pageflips). This breaks
the abi, eg: A double buffering mesa client might leave the last
framebuffer in unmappable space on close. A subsequent glReadPix
by a frontbuffer rendering client then goes boom. My pretty anal
mappable/unmappable consistency checking detected this, see

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

Chris Wilson tried to fix this in 085ce264 by pinning
tiled framebuffers into mappable space. This
a) renders the original optimization of not forcing framebuffers
   for pageflipping clients into mappable pointless because all our
   scanout buffers are tiled by default.
b) doesn't solve the problem for untiled framebuffers.

So kill this. Emperically it's no gain anyway because framebuffers are
being reused by the ddx and hence there's no chance for them to get
constanly bounced between mappable and unmappable.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
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>

When merging Daniel's full-gtt patches I had a set of tweaks which I
thought I had undone. I was half right...

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31286
Reported-by: jinjin.wang@intel.com
Reported-by: NAlexey Fisher <bug-track@fisher-privat.net>
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>

So long as we adhere to the fence registers rules for alignment and no
overlaps (including with unfenced accesses to linear memory) and account
for the tiled access in our size allocation, we do not have to allocate
the full fenced region for the object. This allows us to fight the bloat
tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside
the GTT we still suffer the additional alignment constraints, so it doesn't
magic allow us to render larger scenes without stalls -- we need the
expanded GTT and fence pipelining to overcome those...]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like before add a parameter mappable (also to gem_object_pin) and
set it depending upon the context. Only bos that are brought into
the gtt due to an execbuffer call can be put into the unmappable
part of the gtt, everything else (especially pinned objects) need
to be put into the mappable part of the gtt.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Preparing the ringbuffer for adding new commands can fail (a timeout
whilst waiting for the GPU to catch up and free some space). So check
for any potential error before overwriting HEAD with new commands, and
propagate that error back to the user where possible.
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>

FDI_PLL_BIOS_0 register is for Ironlake only, don't apply to
Sandybridge.
Original-patch-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The enter argument as implemented by commit 413d45d3 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.

There is no runtime behavior change as a result of this patch.
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Needed on Ibex Peak and Cougar Point or the panel won't always come on.

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

We do this later (and more properly) when we enable FDI, so we don't
need to do it here.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Wait for vblank after enabling a pipe, make the error messages more
informative, and wait for the pipe to turn off when we disable it.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As with other PCH DP connections.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

CPU eDP needs a different reference clock than PCH eDP, which uses the
standard PCH refclk of 120MHz.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Enable SSC on PCH eDP if possible.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: added a posting read of PCH_DREF_CONTROL before the udelay]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>