My rv515 card is very flaky with msi enabled. Every so often it loses a rearm
and never comes back, manually banging the rearm brings it back.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a resume regression introduced in

commit 7dd49065
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Mar 21 10:48:18 2012 +0000

    drm/i915: Mark untiled BLT commands as fenced on gen2/3

which fixed fencing tracking for untiled blt commands.

A side effect of that patch was that now also untiled objects have a
non-zero obj->last_fenced_seqno to track when a fence can be set up
after a pipelined tiling change. Unfortunately this was only cleared
by the fence setup and teardown code, resulting in tons of untiled but
inactive objects with non-zero last_fenced_seqno.

Now after resume we completely reset the seqno tracking, both on the
driver side (by setting dev_priv->next_seqno = 1) and on the hw side
(by allocating a new hws page, which contains the seqnos). Hilarity
and indefinite waits ensued from the stale seqnos in
obj->last_fenced_seqno from before the suspend.

The fix is to properly clear the fencing tracking state like we
already do for the normal gpu rendering while moving objects off the
active list.
Reported-and-tested-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The struct exynos_drm_manager has to exist for exynos drm sub driver
using encoder and connector. If it isn't NULL to member of struct
exynos_drm_subdrv, will create encoder and connector else will not. And
the is_local member also doesn't need.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The mixer driver and hdmi driver have each operation callback functions
and they is registered to hdmi common driver. Their struct names in hdmi
common driver include display, manager and overlay. It confuses to
appear whose operation and two driver cannot register same operation
callback functions at the same time. Use their struct names to driver
name.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The default_win member in struct mixer_context isn't change its value
after initialized to 0, so it's better using to define.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

HDMI_OVERLAY_NUMBER is specific of mixer driver and be used "windows
layer" term in exynos user manaual, so rename it.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Some members in struct mixer_context aren't used and the define
HDMI_OVERLAY_NUMBER is unused in hdmi driver, remove them.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

When the void pointer type variable is assigned to the specific pointer
type variable, don't need to do type conversion.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

People have been getting confused and thinking this is a runtime control.

Cc: stable@vger.kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

According to an internal workaround master list, we need to set bit 5
of register 9400 to avoid issues with color blits.

Testing shows that this seems to fix the blitter hangs when fbc is
enabled on snb, thanks to Chris Wilson for figuring this out.
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NMichael "brot" Groh <michael.groh@minad.de>
Acked-by: NBen Widawsky <ben@bwidawsk.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The 845g shares the errata with i830 whereby executing a command
within 2 cachelines of the end of the ringbuffer may cause a GPU hang.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This reverts commit c3dfefa0.

gmbus in 3.4 has simply too many known issues:
- gmbus is too noisy, we need to rework the logging:
  https://bugs.freedesktop.org/show_bug.cgi?id=48248
- zero-length writes cause an OOPS, and they are
  userspace-triggerable:
  https://lkml.org/lkml/2012/3/30/176
- same for zero-length reads:
  https://bugs.freedesktop.org/show_bug.cgi?id=48269

We can try again for 3.5.
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It seems it can corrupt the monitor EDID in certain cases on certain
boards when running sensors detect.  It's rarely used anyway outside
of AIW boards.

http://lists.lm-sensors.org/pipermail/lm-sensors/2012-April/035847.html
http://lists.freedesktop.org/archives/xorg/2011-January/052239.htmlSigned-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We've only computed whether we need to fall back to 6bpc due to dp
link bandwidth constrains in mode_valid, but not mode_fixup. Under
various circumstances X likes to create new modes which then lack
proper 6bpc flags (if required), resulting in mode_fixup failures and
ultimately black screens.

Chris Wilson pointed out that we still get things wrong for bpp > 24,
but that should be fixed in another patch (and it'll be easier because
this patch consolidates the logic).

The likely culprit for this regression is

commit 3d794f87238f74d80e78a7611c7fbde8a54c85c2
Author: Keith Packard <keithp@keithp.com>
Date:   Wed Jan 25 08:16:25 2012 -0800

    drm/i915: Force explicit bpp selection for intel_dp_link_required

v2: Fix indentation and tune down the too bold claim that this should
fix the world. Both noticed by Chris Wilson.

v3: Try to really git add things.
Reported-and-tested-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48170
Cc: stable@kernel.org
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some r4xx chips have the wrong frev in the
DVOEncoderControl table.  It should always be 1
on r4xx.  Fixes modesetting on DVO on r4xx chips
with the bad frev.

Reported by twied on #radeon.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since cmdbuf->size and cmdbuf->nbox are from userspace, a large value
would overflow the allocation size, leading to out-of-bounds access.
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some architectures require that delays longer than a few
miliseconds are called through mdelay. This was triggered
on ARM randconfig builds.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Similar to the case where we are changing from one framebuffer to
another, we need to be sure that there are no pending WAIT_FOR_EVENTs on
the pipe for the current framebuffer before switching. If we disable the
pipe, and then try to execute a WAIT_FOR_EVENT it will block
indefinitely and cause a GPU hang.

We attempted to fix this in commit 85345517
(drm/i915: Retire any pending operations on the old scanout when switching)
for the case of mode switching, but this leaves the condition where we
are switching off the pipe vulnerable.

There still remains the race condition were a display may be unplugged,
switched off by the core, a uevent sent to notify the DDX and the DDX
may issue a WAIT_FOR_EVENT before it processes the uevent. This window
does not exist if the pipe is only switched off in response to the
uevent. Time to make sure that is so...
Reported-by: NFrancis Leblanc <Francis.Leblanc-Lebeau@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fixup spelling in comment, noticed by Eugeni.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The destination color key is always enabled for IVB.  Removed
the line that does this.
Signed-off-by: NArmin Reese <armin.c.reese@intel.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Many users of debugfs copy the implementation of default_open() when
they want to support a custom read/write function op.  This leads to a
proliferation of the default_open() implementation across the entire
tree.

Now that the common implementation has been consolidated into libfs we
can replace all the users of this function with simple_open().

This replacement was done with the following semantic patch:

<smpl>
@ open @
identifier open_f != simple_open;
identifier i, f;
@@
-int open_f(struct inode *i, struct file *f)
-{
(
-if (i->i_private)
-f->private_data = i->i_private;
|
-f->private_data = i->i_private;
)
-return 0;
-}

@ has_open depends on open @
identifier fops;
identifier open.open_f;
@@
struct file_operations fops = {
...
-.open = open_f,
+.open = simple_open,
...
};
</smpl>

[akpm@linux-foundation.org: checkpatch fixes]
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

NV12, NV12M and NV12MT are added to format list of plane to use these
formats for hdmi vp layer.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

This reverts commit d06221c0.

It turns out to trigger the "BUG_ON(!PageCompound(page))" in kfree(),
apparently because the code ends up trying to free somethng that was
never kmalloced in the first place.

BenH points out that the patch was untested and wasn't meant to go into
the upstream kernel that quickly in the first place.

Backtrace:
  bios_shadow
  bios_shadow_prom
  nv_mask
  init_io
  bios_shadow
  nouveau_bios_init
  NVReadVgaCrtc
  NVSetOwner
  nouveau_card_init
  nouveau_load
Reported-by: NMeelis Roos <mroos@linux.ee>
Requested-by: NDave Airlie <airlied@gmail.com>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

this patch fixes that buf->pages is allocated two times when it allocates
physically continuous memory region and removes unnecessary codes.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

1M section, 64k page count also should be rounded up so this patch
rounds up them and caculates page count of them properly and also
checks memory flags from user.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

mplayer -vo fbdev tries to create a screen that is twice as tall as the
allocated framebuffer for "doublebuffering". By default, and all in-tree
users, only sufficient memory is allocated and mapped to satisfy the
smallest framebuffer and the virtual size is no larger than the actual.
For these users, we should therefore reject any userspace request to
create a screen that requires a buffer larger than the framebuffer
originally allocated.

References: https://bugs.freedesktop.org/show_bug.cgi?id=38138Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This was missed when we converted the source values to 16.16 fixed point.

Cc: stable@vger.kernel.org
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.

Cc: stable@kernel.org
Signed-off-by: NAnisse Astier <anisse@astier.eu>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i915_drm_thaw was not locking the mode_config lock when calling
drm_helper_resume_force_mode. When there were multiple wake sources,
this caused FDI training failure on SNB which in turn corrupted the
display.
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reported-by: NKonstantin Belousov <kostikbel@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Totally unexpected that this regressed. Luckily it sounds like we just
need to have dmar disable on the igfx, not the entire system. At least
that's what a few days of testing between Tony Vroon and me indicates.
Reported-by: NTony Vroon <tony@linx.net>
Cc: Tony Vroon <tony@linx.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds PCI ID for IVB GT2 server variant which we were missing.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fix up conflict because the patch has been diffed against next. tsk.]
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There should be VM_MIXEDMAP, not VM_PFNMAP, because udl_gem_fault() inserts
pages via vm_insert_page(). Other drm/gem drivers already do this.
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Dave Airlie <airlied@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

On pre-R600 asics, the SpeedFanControl table is not
executed as part of ASIC_Init as it is on newer asics.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29412Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

The code tries various methods for retreiving the BIOS data. However
it doesn't clear the bios->data pointer between the iterations.

In some cases, the shadow() method will fail and not update bios->data
at all, which will cause us to "score" the old data and incorrectly
attribute that score to the new method. This can cause double frees
later when disposing of the unused data.

Additionally, we were not freeing the data for methods that fail the
score test (we only freed when a "best" is superseeded, not when the
new method has a lower score than the exising "best"). Fix that as well.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

From b15b244d6e6e20964bd4b85306722cb60c3c0809 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon, 2 Apr 2012 13:28:18 +1000
Subject:

Under some circumstances, pci_map_rom() can return a valid mapping
but a size of 0 (if it cannot find an image in the header).

This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Ben H. reported that building nouveau into the kernel and power supply
as a module was broken.

Just have nouveau select it, like radeon does.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Noticed by staring at intel_reg_dumper diffs. Unfortunately it does
not seem to completely fix the bug.

Still, it's good to get this right, and maybe it helps someplace else.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47117Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ben Widawsky reported missed IRQ issues and this patch here helps.

We have one other missed IRQ report still left on snb, reported by QA:

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

This is _not_ a regression due to the forcewake voodoo though, it
started showing up before that was applied and has been on-and-off for
the past few weeks. According to QA this patch does not help. But the
missed IRQ is always from the blt ring (despite running piglit, so
also render activity expected), so I'm hopefully that this is an issue
with the blt ring itself.
Tested-by: NBen Widawsky <ben@bwidawsk.net>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Somehow the BIOS manages to screw things up when copying the VBT
around, because the one we scrap from the VBIOS rom actually works.

Cc: stable@kernel.org
Tested-by: NMarkus Heinz <markus.heinz@uni-dortmund.de>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28812Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>