The graphics domains are listed as GRDOM in the documentation, and the
GDRST PCI config register (0xc0) is only valid on I965 and GM45.  Newer
chips (like Sandy Bridge) have a different GDRST.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Previously, it was only being set if passed GDRST_FULL - but the only
caller passed GDRST_RENDER.  So the hardware never actually reset.
The comments also did not match the code.

Instead, just set the reset bit regardless of what flags were passed.
The GPU now resets correctly on my GM45.
Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid confusion between i965g meaning broadwater and the gen4+ chipset
families.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We assume that the panel is permenantly connected and that the EDID data
is consistent from boot, so simply cache the whole EDID for the panel.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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>

Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-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>

Later initialisation of the encoder often requires that
drm_encoder_init() has already been called, for instance, initialiasing
the DDC buses.

Yet another recent regression, as 819f3fb7 depended upon these fixes
which I missed when cherry-picking.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

One problem with devices that share the DDC bus between the VGA and
DVI-I connectors is that with two devices attached we cannot know if
there is truly a monitor attached to the DVI connector. In this case, it
is preferrrable to mark the status as unknown, so that the user can
supply the known set of modes and continue to use the output.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We only need to use the analog encoder for rare devices which share the
DDC between the DVI-I and VGA connectors, so only create as needed.
Signed-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>

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

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

This can always be re-added should somebody find a use...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The SDVO proxy i2c adapter wants to be able to use information stored in
the encoder, so pass that through intel_i2c rather than iterate over all
known encoders every time.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we currently may need to acquire a fence register during a modeset,
we need to be able to do so in an uninterruptible manner. So expose that
parameter to the callers of the fence management code.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This ensures that we do wait upon the flushes to complete if necessary
and avoid the visual tears, whilst enabling pipelined page-flips.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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>

I pulled the wrong version of the patch from Daniel Vetter which was
missing the read barriers -- and the one that was causing all the trouble
was from i915_gem_object_put_fence_reg(), leading to GPU hangs on gen3.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

By reducing the hangcheck frequency we check less often, conserving
resources, and still detect a lock up quickly. On a fast machine with a
slow GPU (like a Core2 paired with a 945G) it is easy for the hangcheck to
misfire as we check too fast.

Also once hung and if we fail to completely reset the chip, we have a
nasty habit of proclaming a hang many times a second and generating a
strobe-like display.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

Fix a regression in the previous regression fix...

In order to turn off the pipes entirely upon the first modeset, we
pretend that BIOS (or earlier module incarnation) left them active.
The first task performed by setup_initial_configuration() is to disable
all pipes and so to avoid skipping that step and so to ensure a known
configuration we need to mark all the crtcs as active.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

When separating out the prepare/commit into its own separate functions
we overlooked that the intel_crtc->dpms_mode was being used elsewhere to
check on the actual status of the pipe.

Track that bit of logic separately from the actual dpms mode, so there
is no confusion should we be able to handle multiple dpms modes, nor
any semantic conflict between prepare/commit and dpms.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This closes a couple of corner cases where we introduced and forgot
about a couple of routines that need to be called when disabling the
crtc and then re-enabling it. The code needs to be moved again so that
the common bits are shared across generations.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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>

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