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

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

This check only appears to succeed when using GMBUS, so we need to skip
it if we have fallen back to using GPIO bit banging.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

There are several reported instances of GMBUS failing to successfully
read the EDID, so revert back to bit banging until the issue is
resolved.

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

Besides a couple of bugs when writing more than a single byte along the
GMBUS, SDVO was completely failing whilst trying to use GMBUS, so use
bit banging instead.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

With multiple rings generating requests independently, the outstanding
requests must also be track independently.
Reported-by: NWang Jinjin <jinjin.wang@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30380Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The IPS driver needs to know the current power consumption of the GMCH
in order to make decisions about when to increase or decrease the CPU
and/or GPU power envelope.  So fix up the divisions to save the results
so the numbers are actually correct (contrary to some earlier comments
and code, these functions do not modify the first argument and use it
for the result).
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Introduced by 48b956c5, I had thought I had already fixed this. Oh well.
Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

There is no equivalent to mutex_destroy() for spinlocks so just delete
the code.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Daniel Vetter pointed out that in this case is would be clearer and
cleaner to use a spinlock instead of a mutex to protect the per-file
request list manipulation. Make it so.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It's the same code, essentially, so kill all copies safe one unified
version.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

All functions are extremely similar, so fold them into one generic
implementation.

This function isn't used anyway, because there's not yet a bsd ring
error state dumper.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Two macros that use a base address for HWS_PGA were missing, add them.
Also switch the remaining users of *_ACTHD to the ring-base one.
Kill the other ring-specific macros because they're now unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[ickle: And silence checkpatch whilst in the vicinity]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This was mixed up in the following patch:

commit a6c45cf0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Sep 17 00:32:17 2010 +0100

    drm/i915: INTEL_INFO->gen supercedes i8xx, i9xx, i965g
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Everything is now handled in intel-gtt.h so these defines
are only confusing.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and combine it with the wedged completion handler.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Owain Ainsworth reported an issue between the interaction of the
hangcheck and userspace immediately (and permanently) falling back to
s/w rasterisation. In order to break the mutex and begin resetting the
GPU, we must abort the current operation (usually within the wait) and
climb sufficiently far back up the call chain to drop the mutex. In his
implementation, Owain has a loop within the ioctl handler to detect the
hang and then sleep until the error handler has run. I've chosen to
return to userspace and report an EAGAIN which should trigger the
userspace ioctl handler to repeat the call (simply because it felt less
invasive...). Before hitting a wedged GPU, we then wait upon completion
of the error handler.
Reported-by: NOwain G. Ainsworth <zerooa@googlemail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid cause latencies in other clients by not taking the global struct
mutex and moving the per-client request manipulation a local per-client
mutex. For example, this allows a compositor to schedule a page-flip
(through X) whilst an OpenGL application is monopolising the GPU.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This patch fixes the black screen bug on Dell e6510, by
adding two delays to give the eDP panel time to turn on before we
continue with the next write.

300ms is rather arbitray and a rather long sleep, we need to find a way
of refining this value.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29278Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In commit e517a5e9 the call to
map_page_into_agp() got removed from intel_i830_setup_flush(), but the
counterpart call from intel_i830_fini_flush() to unmap_page_from_agp()
was left in place.

Additionally, the page allocated here never gets its physical address
used for sending to hardware, so there's no need to allocate it with
GFP_DMA32. Nor is __GFP_ZERO really necessary, as the page is used
only to store data to force flushing of some internal processor state.
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

First step, lets have a look at the values for troublesome panels and
see if they may be used to improve our link training.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

We need to drain the pending flips prior to disabling the pipe during
modeset, and these need to be done in an uninterruptible fashion.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is now private to the DVO connector, remove it from the main device
private.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we presume space is signed when computing and looking for wrap along,
make it so.
Reported-by: NOwain G. Ainsworth <zerooa@googlemail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

These have served their purpose and are now just noise in the debug
stream.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Try to validate the panel's connection by writing to address 0xA0.

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

In the event that the external chipset doesn't implement the
GET_SUPPORTED_ENHANCEMENTS commands, gracefully treat it as having no
enhancments rather than bailing.
Reported-and-tested-by: NWoody Suwalski <terraluna977@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We weren't unlinking the freed connector from the drm lists, and so
hit some use-after-free if we failed to initialise the connector.
Reported-and-tested-by: NWoody Suwalski <terraluna977@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18342Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We need to wait for the PLLs to settle prior to detecting the state
changes. The BIOS writers guide suggests waiting for the next vblank.
Reported-by: NCarlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is already performed with the pipelined flush, so by the time we
schedule the flush in the page-flip, the ring is NULL and we OOPs
instead.
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

A minor typo caused a single fence register to be incorrectly
programmed, resulting in occassional tiling corruption.
Reported-and-tested-by: NHans de Bruin <bruinjm@xs4all.nl>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=18962Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

The BIOS writer's guide suggests that a VGA connection will ACK a write
to address 0xA0 and that this should be used before doing legacy
load-detection. Considering the extreme cost of load-detection,
performing an extra DDC seems a risk worth taking.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

We are not currently using it as intended, so remove the complication.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Previously when converting the GMBUS pin to the GPIO reg, we would
offset the pin by one and then use the look-up table. Now that we first
try to use the GMBUS pin, we no longer need the offset and can use the
value from the VBIOS directly.
Reported-by: NCarlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Otherwise we will hit a list handling assertion when moving the object
to the inactive list.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

During i915_gem_create_mmap_offset() if the subsystem reports an error
code, use it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>