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

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

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

Hopefully this one will be better able to cope with moving tiled buffers
around without getting them all scrambled as a result.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nv2x CRTC FIFOs are as large as in nv3x (4kB it seems), and the FIFO
control registers have the same layout: we can make them share the
same implementation.

Previously we were using the nv1x code, but the calculated FIFO
watermarks are usually too low for nv2x and they cause horrible
scanout artifacts. They've gone unnoticed until now because we've been
leaving one of the bandwidth regs uninitialized (CRE 47, which
contains the most significant bits of FFLWM), so everything seemed to
work fine except in some cases after a cold boot, depending on the
memory bandwidth and pixel clocks used.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On some nv4x cards (specifically, the ones that use an internal
PCIE->AGP bridge) the AGP controller state isn't preserved after a
suspend/resume cycle, and the AGP control registers have moved from
0x18xx to 0x100xx, so the FW check in nouveau_mem_reset_agp() doesn't
quite work. Check "dev->agp->mode" instead.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

During heavy aperture thrashing we may be forced to wait upon several active
objects during eviction. The active list may be the last reference to
these objects and so the action of waiting upon one of them may cause
another to be freed (and itself unbound). To prevent the object
disappearing underneath us, we need to acquire and hold a reference
whilst unbinding.

This should fix the reported page refcount OOPS:

kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1444!
...
RIP: 0010:[<ffffffffa0093026>]  [<ffffffffa0093026>] i915_gem_object_put_pages+0x25/0xf5 [i915]
Call Trace:
 [<ffffffffa009481d>] i915_gem_object_unbind+0xc5/0x1a7 [i915]
 [<ffffffffa0098ab2>] i915_gem_evict_something+0x3bd/0x409 [i915]
 [<ffffffffa0027923>] ? drm_gem_object_lookup+0x27/0x57 [drm]
 [<ffffffffa0093bc3>] i915_gem_object_bind_to_gtt+0x1d3/0x279 [i915]
 [<ffffffffa0095b30>] i915_gem_object_pin+0xa3/0x146 [i915]
 [<ffffffffa0027948>] ? drm_gem_object_lookup+0x4c/0x57 [drm]
 [<ffffffffa00961bc>] i915_gem_do_execbuffer+0x50d/0xe32 [i915]
Reported-by: NShawn Starr <shawn.starr@rogers.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18902Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

There is a second revision of B43 (a desktop gen4 part) floating around,
functionally equivalent to the original B43, so simply add the new
PCI-IDs.

Bugzilla: https://bugs.freedesktop.org/show_bugs.cgi?id=30221Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

With 5 places to update when adding handling for fence registers, it is
easy to overlook one or two. Correct that oversight, but fence
management should be improved before a new set of registers is added.

Bugzilla: https://bugs.freedesktop.org/show_bug?id=30199
Original patch by: Yuanhan Liu <yuanhan.liu@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

These are not fatal errors, so do not alarm the user by filling the
logs with *** ERROR ***. Especially as we know that g4x CRT detection
is a little sticky.

On the one hand the errors are valid since they are warning us of a
stall -- we poll the register whilst holding the mode lock so not even
the mouse will update. On the other hand, those stalls were already present
yet nobody complained.
Reported-by: NAndi Kleen <andi@firstfloor.org>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18332Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The texture base address registers are in units of 256 bytes.
The original CS checker treated these offsets as bytes, so the
original check was wrong.  I fixed the units in a patch during
the 2.6.36 cycle, but this ended up breaking some existing
userspace (probably due to a bug in either userspace texture allocation
or the drm texture mipmap checker).  So for now, until we come
up with a better fix, just warn if the mipmap size it too large.
This will keep existing userspace working and it should be just
as safe as before when we were checking the wrong units.  These
are GPU MC addresses, so if they fall outside of the VRAM or
GART apertures, they end up at the GPU default page, so this should
be safe from a security perspective.

v2: Just disable the warning.  It just spams the log and there's
nothing the user can do about it.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <glisse@freedesktop.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There has been periodic evidence that LVDS, on at least some
panels, prefers the dividers selected by the legacy pll algo.
This patch forces the use of the legacy pll algo on RV620
LVDS panels.  The old behavior (new pll algo) can be selected
by setting the new_pll module parameter to 1.

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

Not 100% sure this is due to BKL removal, its most likely a combination
of that + userspace timing changes in udev/plymouth. The drm adds the sysfs
device before the driver has completed internal loading, this causes udev
to make the node and plymouth to open it before we've completed loading.

The proper solution is to delay the sysfs manipulation until later in loading
however this causes knock on issues with sysfs connector nodes, so we can use
the global mutex to serialise loading and userspace opens.

Reported-by: Toni Spets (hifi on #radeon)
Signed-off-by: NDave Airlie <airlied@redhat.com>

v2: Julien Cristau pointed out that @nondestructive results in
double-negatives and confusion when trying to interpret the parameter,
so use @force instead. Much easier to type as well. ;-)

And fix the miscompilation of vmgfx reported by Sedat Dilek.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This commit fixes bogus CS rejection if it contains a sequence
of the following operations:

- Set the color buffer 0. track->cb[i].robj becomes non-NULL.
- Render.
- Set a larger zbuffer than the previously-set color buffer.
- Set a larger scissor area as well.
- Set the color channel mask to 0 to do depth-only rendering.
- Render. --> rejected, because track->cb[i].robj remained non-NULL,
  therefore the conditional checking for the color channel mask and
  friends is not performed, and the larger scissor area causes
  the rejection.

This fixes bugs:
- https://bugs.freedesktop.org/show_bug.cgi?id=29762
- https://bugs.freedesktop.org/show_bug.cgi?id=28869
And maybe some others which seem to look the same.

If possible, this commit should go to stable as well.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

One subtest of mesa/demos/gltestperf takes 9 seconds to complete,
so to prevent an unnecessary gpu reset followed by a hardlock, I am
increasing the interval to 10 seconds after which a GPU is considered
in a locked-up state. This is on RV530. However, with a little slower GPU,
we would surpass the interval easily, so this is not a good fix
for gltestperf.

Nevertheless, this commit also fixes hardlocks in the applications which
render at speed of less than 1 frame per second, where the whole frame
consists of only one command stream. The game Tiny & Big is an example.
This bar is now lowered to 0.1 fps.

Now the question comes down to whether we should (often unsuccessfully)
reset the GPU at all? Once we have stable enough drivers, we won't have to.
Has the time come already?

If possible, this commit should go to stable as well.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch fixes rendering errors on some evergreen boards.
Hardcoding the backend map is not an optimal solution, but
a better fix is being worked on.

Similar to the fix for rv740
(6271901d).

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

Destructive load-detection is very expensive and due to failings
elsewhere can trigger system wide stalls of up to 600ms. A simple
first step to correcting this is not to invoke such an expensive
and destructive load-detection operation automatically.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29536
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16265Reported-by: NBruno Prémont <bonbons@linux-vserver.org>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Noticed while adding evergreen blit support.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Otherwise when disabling the output we switch to the new fb (which is
likely NULL) and skip the call to mode_set -- leaking driver private
state on the old_fb.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

They aren't compatible.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

caused by d65d65b1

need to update the radeon crtc priv native mode before using it.

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

v2: integrate v/h copy paste typo
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I broke out my trusty i845 and found a new boot failure, which upon
inspection turned out to be a recursion within:

drm_helper_probe_single_connector_modes() -> drm_helper_hpd_irq_event()
-> intel_crt_detect() -> drm_helper_probe_single_connector_modes()

Calling drm_kms_helper_poll_enable() instead performs the desired
re-initialisation of the polling should the user have toggled the
parameter, without the recursive side-effect.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This should fix the mysterious mode setting failures reported during
boot up and after resume, generally for i8xx class machines.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16478Reported-and-tested-by: NXavier Chantry <chantry.xavier@gmail.com>
Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29413Tested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

We don't know how to enable it safely, especially as outputs turn on and
off.  When disabling LP1 we also need to make sure LP2 and 3 are already
disabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29173
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29082Reported-by: NChris Lord <chris@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If we are busy, then we may have woken up the wait_request handler but
not yet serviced it before the hang check fires. So in hang check,
double check that the i915_gem_do_wait_request() is still pending the
wake-up before declaring all hope lost.

Fixes regression with e78d73b1.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30073Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit b9421ae8.

This warning was so prelevant, even for apparently working machines,
that it was just causing fear, anxiety and panic.

The root cause still remains, so we will add some better debugging when
we focus on fixing it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=17021Reported-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit 0f3ee801.

Enabling LVDS on pipe A was causing excessive wakeups on otherwise idle
systems due to i915 interrupts. So restrict the LVDS to pipe B once more,
whilst the issue is properly diagnosed.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307Reported-and-tested-by: NEnrico Bandiello <enban@postal.uv.es>
Poked-by: NFlorian Mickler <florian@mickler.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Adam Jackson <ajax@redhat.com>
Cc: stable@kernel.org

This reverts commit ce171780.

This commit has been independently bisected a few times as being the cause
of a s2ram failure.
Reported-and-tested-by: NKyle McMartin <kyle@mcmartin.ca>
Reported-and-tested-by: NAndy Isaacson <adi@hexapodia.org>
Cc: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

New pci ids for GT2 and GT2+ on desktop and mobile sandybridge,
and graphics device ids for server sandybridge. Also rename original
ids string to reflect GT1 version.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

MI_FLUSH is being deprecated, but still available on Sandybridge.
Make sure it's enabled as userspace still uses MI_FLUSH.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Sandybridge GTT has new cache control bits in PTE, which controls
graphics page cache in LLC or LLC/MLC, so we need to extend the mask
function to respect the new bits.

And set cache control to always LLC only by default on Gen6.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Arguably this is a bug in drm-core in that we should not be called twice
in succession with DPMS_ON, however this is still occuring and we see
FDI link training failures on the second call leading to the occassional
blank display. For the time being ignore the repeated call.

Original patch by Dave Airlie <airlied@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

We were passing garbage values into the panel-fitter control register
when disabling it on Ironlake - those values (filter modes and reserved
MBZ bits) would have then be re-used the next time panel-fitting was
enabled.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When we miss the flip prepare interrupt, we never get into the
software state needed to restart userspace, resulting in a freeze of a
full-screen OpenGL application (such as a compositor).

Work around this by checking DSPxSURF/DSPxBASE to see if the page flip
has actually happened. If it has, do the work we would have done when
the flip prepare interrupt comes in.

Also, add debugfs information to tell us what's going on (based on the
patch from Chris Wilson attached to bugs.fdo bug #29798).
Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We reset intel_encoder for every matching encoder whilst iterating over
the encoders attached to this crtc when changing mode. As such in a
cloned configuration intel_encoder may not correspond to the correct
is_edp encoder.

By scoping intel_encoder to the loop, not only is the compiler able to
spot this mistake, we also improve readiability for ourselves.
[It might not be a mistake, within this function it is unclear as to
whether it is permissable for eDP to be cloned...]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We were failing when trying to allocate the resource for MMIO of the
MCHBAR because we forgot to specify what type of resource we wanted.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Only stop trying if the aux channel sucessfully reports that the
transmission was completed, otherwise try again. On the 5th failure,
bail and report that something is amiss.

This fixes a sporadic failure in reading the EDID for my external panel
over DP.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

If the VBIOS tells us the mapping of the SDVO device onto the DDC bus,
use it. However, if there is no VBIOS available that mapping is
uninitialised and we should fallback to our earlier guess.

Fix regression introduced in b1083333 (which in turn is a fix for the
regression caused by the introduction of this guess, 14571b4c).

References:

  Bug 29499 - [945GM] Screen disconnected because of missing VBIOS
  https://bugs.freedesktop.org/show_bug.cgi?id=29499

  Bug 15109 - i945GM fails to detect EDID on DVI port
  https://bugzilla.kernel.org/show_bug.cgi?id=15109Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: NPaul Neumann <paul104x@yahoo.de>
Cc: Adam Jackson <ajax@redhat.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org