Whilst moving the code around in 9af90d19, I dropped the or'ing in of
new write domains which would zero out the write domain for a render
target if later reused as a source later in the batch. This meant that
we might drop a required flush before reading from the render target.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31043
Reported-by: xunx.fang@intel.com
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This block is only used when detecting whether the connector is HDMI and
never again, so scope the variable to the detection routine.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This patch enables the sending of AVI infoframes in
drivers/gpu/drm/i915/intel_hdmi.c.

My receiver currently loses sync when the HDMI output on my computer
(DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to
1920x1080 as part of the boot. Fixable by switching inputs on the receiver
a couple of times.

With this patch, my receiver has not lost sync yet (> 40 tries).

Fourth version, now based on drm-intel-next from:
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git

Two questions still remain:

I'm assuming that the sdvo hardware also stores a header ECC byte in
the MSB of the first dword - is this correct?

Does the SDVOB and SDVOC handling in intel_hdmi_set_avi_infoframe()
look correct?
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
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>

Based on an original patch by Zhenyu Wang, this initializes the BLT ring for
SandyBridge and enables support for user execbuffers.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... before someone tries to use it. The code both calls
intel_ring_begin/advance() and open-codes the bookkeeping performed by
those two functions.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In commit 8187a2b7, the number of dwords used in the ringbuffer for
executing the batch buffer was erroneously changed from 2 to 4.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If the userspace driver is using a constant relocation array with a
static buffer, they will pass the same relocation array back to the
kernel. So we *do* need to update the presumed offset value in those
relocations to reflect the current object so that they remain correct
with future batchbuffers and we avoid the necessity of having to suspend
execution and perform redundant relocations.

Fixes the regression introduced by 12f889c for applications using
absolute addressing on trees of buffer (i.e. the current consumers of
libdrm_intel.so).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30996Reported-by: NWang, Jinjin <jinjin.wang@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

To handle retirements, we need per-ring tracking of active objects.
To handle evictions, we need global tracking of active objects.

As we enable more rings, rebuilding the global list from the individual
per-ring lists quickly grows tiresome and overly complicated. Tracking the
active objects in two lists is the lesser of two evils.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... by always initialising the empty ringbuffer it is always then safe
to check whether it is active.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The most frequent relocation within a batchbuffer is a contiguous sequence
of vertex buffer relocations, for which we can virtually eliminate the
drm_gem_object_lookup() overhead by caching the last handle to object
translation.

In doing so we refactor the pin and relocate retry loop out of
do_execbuffer into its own helper function and so improve the error
paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

One of the primarily consumers of the i915 driver is X, a large signal
driven application. Frequently when writing into the buffers, there is a
pending signal which causes us not to take the interruptible lock but
then we need to take that same lock around the object unreference. By
rearranging the code to do the interruptible lock as the first check, we
can avoid the frequent additional locking around the unreference.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

"userpace" -> "userspace"
Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This was a missing piece from 41a51428 that dropped recognition of the
AGP module for the second B43 variant.
Reported-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

... to avoid the double acquisition along fast[er] paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... to avoid reacquiring it to drop the object reference count on
exit. Note we have to make sure we now drop (and reacquire) the lock
around acquiring the mm semaphore on the slow paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... in the hope that it makes the atomic fast paths more likely.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

After allocation a handle for the fresh object, we know that we can
safely drop the refcnt without triggering a free so we do not need the
mutex. Strangely, this mutex acquisition is the one that appears on
driver profiles.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid an early eviction of the batch buffer into the uncached GTT
domain, and so do the relocation fixup in cacheable memory.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... perform an access validation check up front instead and copy them in
on-demand, during i915_gem_object_pin_and_relocate(). As around 20% of
the CPU overhead may be spent inside vmalloc for the relocation entries
when submitting an execbuffer [for x11perf -aa10text], the savings are
considerable and result in around a 10% throughput increase [for glyphs].
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Allow the user to override the detection of the sink's audio capabilities
from EDID. Not all sinks support the required EDID level to specify
whether they handle audio over the display connection, so allow the user
to enable it manually.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Rely on monitor's audio capability to turn on audio output for HDMI.
Tested-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This will turn on DP audio output by checking monitor's audio
capability.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
[ickle: rebase onto recent changes and rearranged for clarity]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The time between start of the pixel clock and backlight enable is a basic
panel timing constraint.  If the Panel Power On/Off registers are found
to be 0, assume we are booting without VBIOS initialization and set these
registers to something reasonable.

Change-Id: Ibed6cc10d46bf52fd92e0beb25ae3525b5eef99d
Signed-off-by: NBryan Freed <bfreed@chromium.org>
[ickle: rearranged into a separate function to distinguish its role from
simply parsing the VBIOS tables.]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If userspace is submitting so many long running batches that the ring
becomes full, throttle by sleeping for a 1ms before checking for free
space. Simply yielding was causing excessive scheduler overhead whilst
making no progress.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In i2c GPIO fallback, index 6 is reserved for nothing.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
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>

Since the PLL may still be on, and the training pattern may not be
correct.  Fixes suspend/resume on my PCH eDP test system.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: minor merge conflict and silence the compiler]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Freeing the Hardware Status Page was writing to the HWS register in
order to disable the GPU writing to the HWS page. Unfortunately, we were
writing to the mmio register after unmapping the register space, hence
the oops.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

This reverts commit 6939a5ac.

Daniel Vetter supplied a set of fixes for all the module unload bugs he
could trigger on his machines, so let the fun recommence!

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>

When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call.  When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.

There is a short cut used by this patch where gamma_store is used as
the save space.  If this turns out to be a problem in the future a
pre-allocated chunk of memory will be required for each crtc to save
and restore the LUT information.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit ff773714.

A generic solution is needed to save and retore the LUT information.

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: dri-devel@lists.freedesktop.org
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TTM-based DRM drivers need to be able to bind user memory to the AGP
aperture. This patch fixes the "[TTM] AGP Bind memory failed." errors
and the subsequent fallout seen with the nouveau driver.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Tested-by: NGrzesiek Sójka <pld@pfu.pl>
Signed-off-by: NDave Airlie <airlied@redhat.com>