Without this change, blits to the front buffer won't invalidate FBC
state, causing us to scan out stale data.  Make sure we update these
bits on every FBC enable, since they may get clobbered if we shut off
the display.

References: https://bugzilla.kernel.org/show_bug.cgi?id=26932Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Add a couple of missing workaround bits for ILK & SNB.  These disable
clock gating on a couple of units that would otherwise prevent FBC from
working.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

First, we were calling mc_stop() at the top of the function
which turns off all MC (memory controller) clients,
then checking if the GPU is idle.  If it was idle we
returned without re-enabling the MC clients which would
lead to a blank screen, etc.  This patch checks if the
GPU is idle before calling mc_stop().

Second, if the reset failed, we were returning without
re-enabling the MC clients.  This patch re-enables
the MC clients before returning regardless of whether
the reset was successful or not.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use the common one for all asics.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Switching to pcie gen2 causes problems on some
boards.  Add a module option to turn it on/off.

There are gen2 compatability issues with some
motherboards it seems.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=33027Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The switch to separate BAR and channel address spaces made the fbcon memory
address calculation incorrect on NV50+ boards, this commit fixes that.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reviewed-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Somehow missed this in the original merge of the nvc0 code.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

This reverts commit dfe63bb0.

This commit was causing nouveau not to work properly, for -rc1 I'd
prefer it worked and we can look if this is useful for 2.6.39.

Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NKnut Petersen <knut_petersen@t-online.de>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Hopefully, this is a temporary measure whilst the root cause is
understood. At the moment, we experience a hard hang whilst looping
urbanterror that has been identified as a result of the use of
semaphores, but so far only on SNB mobile.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32752
Tested-by: mengmeng.meng@intel.com
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

After reordering the sequence of relocating objects, commit 6fe4f140,
we can no longer rely on seeing all reloc targets prior to performing
the relocation. As a result we were ignoring the need to flush objects
from the render cache and invalidate the sampler caches, resulting in
rendering glitches. So we need to clear the relocation domains earlier.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On the fault path, commit 6fe4f140 introduction a regression whereby it
changed the sequence of the objects but continued to use the original
ordering of relocation entries. The result was that incorrect GTT offsets
were being fed into the execbuffer causing lots of misrendering and
potential hangs.
Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Whilst we had no older batches on the active list, everything was fine.
However, if the GPU is free running and the requests are only being
reaped by the periodic retirer, than the current seqno may not be at the
start of the list. In this case we need to select the first batch after
the last seqno written by the gpu and not inclusive of the seqno.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In order to workaround the issue with LVDS not working on the Lenovo
U160 apparently due to using the wrong SSC frequency, add an option to
disable SSC.
Suggested-by: NLukács, Árpád <lukacs.arpad@gmail.com>
Bugzillla: https://bugs.freedesktop.org/show_bug.cgi?id=32748Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

... and not if the maximum is non-zero. This fixes the typo introduced
in 47356eb6 and preserves the backlight value from boot.

[ickle: My thanks also to Indan Zupancic for diagnosing the original
        regression and suggesting the appropriate fix.]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org # after 47356eb6

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

As the mappable portion of the aperture is always a small subset at the
start of the GTT, it is allocated preferentially by drm_mm. This is
useful in case we ever need to map an object later. However, if you have
a large object that can consume the entire mappable region of the
GTT this prevents the batchbuffer from fitting and so causing an error.
Instead allocate all those that require a mapping up front in order to
improve the likelihood of finding sufficient space to bind them.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Rather than evicting an object at random, which is unlikely to alleviate
the memory pressure sufficient to allow us to continue, zap the entire
aperture. That should give the system long enough to recover and reap
some pages from the evicted objects, forestalling the allocation error
for the new object.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and not leave the objects in a inconsistent state.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Before releasing the lock in order to copy the relocation list from user
pages, we need to drop all the object references as another thread may
usurp and execute another batchbuffer before we reacquire the lock.
However, the code was buggy and failed to clear the list...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Useful for determining the layout.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

In order to retire active buffers whilst no client is active, we need to
insert our own flush requests onto the ring.

This is useful for servers that queue up some rendering and then go to
sleep as it allows us to the complete processing of those requests,
potentially making that memory available again much earlier.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Dave Airlie spotted that his ILK laptop with DMAR enabled was generating
the occasional DMAR warning.

"The ordering in the previous code was to rewrite the GTT table before
unmapping the pages and that makes sense to me."

This is his stable patch ported to d-i-n.
Reported-by: NDave Airlie <airlied@redhat.com>
Original-patch-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

The docs recommend that if 8 display lines fit inside the FIFO buffer,
then the number of watermark entries should be increased to hide the
latency of filling the rest of the FIFO buffer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... in order to avoid a BUG() and potential unbounded waits.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

FDI and the transcoders can fail for various reasons, so detect those
conditions and report on them.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Cleanup several aspects of the rc6 code:
  - misnamed intel_disable_clock_gating function (was only about rc6)
  - remove commented call to intel_disable_clock_gating
  - rc6 enabling code belongs in its own function (allows us to move the
    actual clock gating enable call back into restore_state)
  - allocate power & render contexts up front, only free on unload
    (avoids ugly lazy init at rc6 enable time)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: checkpatch cleanup]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Enabling RC6 implies setting a graphics context.  Make sure we do that
only after the ring has been enabled, otherwise our ring commands will
hang.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Re-enable rc6 support on Ironlake for power savings.  Adds a debugfs
file to check current RC state, adds a missing workaround for Ironlake
MI_SET_CONTEXT instructions, and renames MCHBAR_RENDER_STANDBY to
RSTDBYCTL to match the docs.

Keep RC6 and the power context disabled on pre-ILK.  It only seems to
hang and doesn't save any power.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As the IMR for the USER interrupts are not modified elsewhere, we can
separate the spinlock used for these from that of hpd and pipestats.
Those two IMR are manipulated under an IRQ and so need heavier locking.
Reported-and-tested-by: NAlexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and move it under the spinlock to gain the appropriate memory
barriers.

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

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

Otherwise we may consume 20% of the CPU just handling IRQs whilst
rendering. Ouch.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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