There are two messages in the ISR of nouveau which might be printed out
hundred times in a second. Ratelimit them. (We need to move
nouveau_ratelimit to the top of the file.)
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Reviewed-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Call destroy() on _all_ ttm_bo_init() failures, and make sure that
behavior is documented in the function description.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If ttm_bo_init() returns failure, it already destroyed the BO, so we need to
retry from scratch.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Temperature is not shifted as on newer asics.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a follow on to:
2b5b1d7da9583484b3a9e7e375a90ca0e8ca07c2
(drm/radeon/kms: add support for clock/data path routers)

That patch completed mux support for ddc and cd line routing
between connectors.  This patch fixes an indexing typo that was
resulting in the atom bios router objects not always being walked,
ensures the validity entries for the reused router structure are
reset for every connector object walked, and corrects the masking
operations used to update the mux control bits.

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

This is a follow on to:
26b5bc98
(drm/radeon/kms: add support for router objects)

That patch added support for systems that use a mux to control
the ddc line routing between the connectors.  This patch adds
support for systems that use a mux to control the encoder
clock and data path routing to the connectors.

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

Structure drm_vmw_fence_rep is copied to userland with field "pad64"
uninitialized.  It leads to leaking of contents of kernel stack memory.
Signed-off-by: NVasiliy Kulikov <segooon@gmail.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When bo pin failed during modesetting,
vmwgfx would try to unref a non-existing buffer object.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This breaks vmwgfx non-root EGL clients and is a remnant from the
TTM user-space interface. This test should be done in the driver.
Replace the remaining placement test with a BUG_ON, since triggering
it is a driver bug.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The sync object may disappear as soon as we release the bo::lock, so
take a reference on it while we use it.
One option would be to call sync_object_flush() before releasing the bo::lock,
but that would put an atomic requirement on that function.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The A/B links aren't independantly useable on these blocks so when
we disable the encoders, make sure to only disable the encoder when
there is no connector using it.

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

Coalesce long formats.
Align arguments.
Add missing newlines.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJoe Perches <joe@perches.com>
Reviewed-by: NMatt Turner <mattst88@gmail.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently an invalid EDID extension will cause the whole EDID to be considered invalid. Instead just drop the invalid extensions, and return the valid ones. The base block is modified to claim to have the number valid extensions, and the check sum is updated.

For my EIZO S2242W the base block is fine, but the extension block is all zeros. Without this patch I get no X and no VTs.
Signed-off-by: NSam Tygier <samtygier@yahoo.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make more of the connector code debug only to avoid
spamming the kernel logs with detect and add modes
messages.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The driver (for example vmwgfx) may want to silently deal with the
error itself.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since we're doing this outside of a spinlock to provide the necessary
barriers, add an explicit barrier.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Replace with BUG_ON(). These error messages remained from the time
when TTM was initialized from user-space. Nowadays hitting one of those
is really a kernel bug.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Searching for a free block in the range manager may in some situations be a
lenghty operation, and we want to avoid holding the global lru lock
during that time. Instead use a per-manager spinlock.

This leaves the global lru lock for quick lru list and swap list manipulation
only, including list manipulation associated with reserving buffer objects.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Remove an obsolete comment about mm nodes.
Document the new bo range manager interface.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Should fix dynpm problems on evergreen boards
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* Dave Airlie <airlied@linux.ie> wrote:

> > Lee, Chun-Yi (1):
> >       gpu: Add Intel GMA500(Poulsbo) Stub Driver

Today's -tip fails to build due to upstream commit e26fd119 ("gpu: Add Intel
GMA500(Poulsbo) Stub Driver"), committed two days ago and merged yesterday, on
x86 allmodconfig with BACKLIGHT_CLASS_DEVICE disabled:

 drivers/built-in.o: In function `acpi_video_bus_put_one_device':
 video.c:(.text+0x7d26f): undefined reference to `backlight_device_unregister'
 drivers/built-in.o: In function `acpi_video_switch_brightness':
 video.c:(.text+0x7d6f5): undefined reference to `backlight_force_update'
 drivers/built-in.o: In function `acpi_video_device_find_cap':
 video.c:(.text+0x7dfdb): undefined reference to `backlight_device_register'

drivers/gpu/stub/Kconfig selects ACPI_VIDEO, but ACPI_VIDEO is a complex interactive
Kconfig option with a lot of dependencies:

 config ACPI_VIDEO
	tristate "Video"
	depends on X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL
	depends on INPUT
	select THERMAL
	help
	  This driver implements the ACPI Extensions For Display Adapters

and if any of its dependencies are not met, we get a build failure. This problem was
apparently realized in the driver at a certain stage:

 config STUB_POULSBO
        tristate "Intel GMA500 Stub Driver"
        depends on PCI
        # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
        # but for select to work, need to select ACPI_VIDEO's dependencies, ick
        select ACPI_VIDEO if ACPI

but not fully understood and not fully fixed.

As a quick fix select these secondary dependencies, like drivers/gpu/drm/Kconfig
does:

 config DRM_I915
	tristate "i915 driver"
	depends on AGP_INTEL
	select SHMEM
	select DRM_KMS_HELPER
	select FB_CFB_FILLRECT
	select FB_CFB_COPYAREA
	select FB_CFB_IMAGEBLIT
	# i915 depends on ACPI_VIDEO when ACPI is enabled
	# but for select to work, need to select ACPI_VIDEO's dependencies, ick
	select VIDEO_OUTPUT_CONTROL if ACPI
	select BACKLIGHT_CLASS_DEVICE if ACPI
	select INPUT if ACPI
	select ACPI_VIDEO if ACPI
	select ACPI_BUTTON if ACPI
	help
	  Choose this option if you have a system that has Intel 830M, 845G,
	  852GM, 855GM 865G or 915G integrated graphics.  If M is selected, the

But it's arguably not particularly nice looking, so maybe this area of code is ripe
for a Kconfig restructuring/cleanup.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 219adae1 cached the EDID found during LVDS init, but in the
process prevented the init routine from discovering the preferred
fixed-mode for the panel. This was causing us to guess the correct mode,
which sometimes is wide of the mark.
Reported-and-tested-by: NJon Masters <jonathan@jonmasters.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.

Cherry-picked from 6aa56062.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31404Tested-by: NZhao Jian <jian.j.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and so prevent a potential circular reference:

  [ INFO: possible circular locking dependency detected ]
  2.6.37-rc1-uwe1+ #4
  -------------------------------------------------------
  Xorg/1401 is trying to acquire lock:
   (&mm->mmap_sem){++++++}, at: [<c01e4ddb>] might_fault+0x4b/0xa0

  but task is already holding lock:
   (&dev->struct_mutex){+.+.+.}, at: [<f869c3ac>]
  i915_mutex_lock_interruptible+0x3c/0x60 [i915]

  which lock already depends on the new lock.

When the locking around the pwrite ioctl was simplified, I did not spot
that the phys path never took any locks and so we introduced this
potential circular reference.
Reported-by: NUwe Helm <uwe.helm@googlemail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NZhenyu Wang <zhenyu.z.wang@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We should enable FDI normal training on Sandybridge/CPT system
as well.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
[ickle: removed unrelated chunks]
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Fixes issue where i915_gfx_val was reporting values several
orders of magnitude higher than physically possible (without
leaving scorch marks on my thighs at least.)
Signed-off-by: NKyle McMartin <kyle@redhat.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On some stepping of SNB cpu, the first command to be parsed in BLT
command streamer should be MI_BATCHBUFFER_START otherwise the GPU
may hang.

(cherry picked from commit 8d19215b)

Conflicts:

	drivers/gpu/drm/i915/intel_ringbuffer.c
	drivers/gpu/drm/i915/intel_ringbuffer.h
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Part of the issue here was that Eric slipped in a debug hack for
testing the i915 IPS code before the intel_ips.c driver had landed.
This caused the driver to always use the full range of frequencies,
which is only legal when IPS tells us we have the headroom.  Once that
hack was removed, there was confusion about the driver's frequency
clamping variables: max_delay is the driver's current limit on the
highest frequency the IPS driver wants us to use, while dev_priv->fmax
is the hardware-reported limit that the IPS driver can increase up to.

Tested with IPS driver loaded or not.  Note that on Ironlake systems
without the IPS driver loaded this will result in a performance
reduction, and the inital warmup of frequency limits can impact
benchmarking on systems with IPS loaded.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
[ickle: demoted a debugging printk]
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

2.6.36 appears to respect the 0400 mode we assigned to the parameter
preventing it from being adjusted after loading. However, this is safe
to adjust at runtime.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31311Reported-by: NFernando Lemos <fernandotcl@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

In case of an opregion signature mismatch in intel_opregion_setup(),
iounmap the correct address.
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It is possible for the active list to only contain a read-only buffer so
that the ring->gpu_write_list remains entry. This leads to an
inconsistency between i915_gpu_is_active() and i915_gpu_idle() causing
an infinite spin during the shrinker and an assertion failure that
i915_gpu_idle() does indeed flush all buffers from the active lists.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Evergreen now has blit support, but unmappable vram support
was disabled in c919b371
(drm/radeon/kms: avoid corner case issue with unmappable vram V2)
due to merge ordering.  This re-enables unmappable vram on
evergreen.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Calculate height based on the slice bitfield rather than the size.
Same as Dave's CB fix.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are cases when multiple texture units have to be enabled,
but not actually used to sample.  This patch checks to see if
the lookup_disable bit is set and if so, skips the texture check.

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

"depth" should be signed in case packed_depth_bytes() returns -EINVAL.

This probably doesn't make a difference at runtime.  In the original
code we would return -EINVAL later if (rec->offset_Y % 4294967274) is
non-zero.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>