Age | Commit message (Collapse) | Author |
|
commit 0ce99f749b3834edeb500e17d6ad17e86b60ff83 upstream.
Apparently Bspec is wrong in this case here even for gm45. Note that
Bspec is horribly misguided on i965g/gm, so we don't have any other
data points besides that it seems to make machines work better.
With this changes all the bits in PORT_HOTPLUG_STAT for the digital
ports are ordered the same way. This seems to agree with what register
dumps from the hpd storm handling code shows, where the LIVE bit and
the short/long pulse STATUS bits light up at the same time with this
enumeration (but no with the one from Bspec).
Also tested on my gm45 which has two DP+ ports, and everything seems
to still work as expected.
References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg23054.html
Cc: Egbert Eich <eich@suse.com>
Cc: Jan Niggemann <jn@hz6.de>
Tested-by: Jan Niggemann <jn@hz6.de>
[danvet: Add a big warning that Bspec seems to be wrong for these
bits, suggested by Jani.]
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 58d327da9721f7a0f6e46c8dfa5cc5546fd7078a upstream.
These asics seem to use a mix of the DCE2.x and
DCE3.2 audio interfaces despite what the register spec
says.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
https://bugs.freedesktop.org/show_bug.cgi?id=69671
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 99d79aa2f3b7729e7290e8bda5d0dd8b0240ec62 upstream.
When dpm was merged, I added a new asic struct for
rv6xx, but it never got properly updated when the
hdmi callbacks were added due to the two patch sets
being developed in parallel.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=69729
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream.
The tests are only usable if the acceleration engines have
been successfully initialized.
Based on an initial patch from: Alex Ivanov <gnidorah@p0n4ik.tk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0eb3448aa6b31fbf24c31756aba7940cac5ad6b8 upstream.
Prevent NULL pointer dereference in case when radeon_ring_fini() did it's job.
Reading of r100_cp_ring_info and radeon_ring_gfx debugfs entries will lead to a KP if ring buffer was deallocated, e.g. on failed ring test.
Seen on PA-RISC machine having "radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)" issue.
v2: agd5f: add some parens around ring->ready check
Signed-off-by: Alex Ivanov <gnidorah@p0n4ik.tk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4ca5a6cba53e13b8fd153b0762b4128fab6a3cfb upstream.
If the user has forced the driver to use the internal GPU gart
rather than AGP on an AGP card, force the buffers to vram
as well.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream.
There is no clear cut rules or specs for the retry interval, as there
are many factors that affect overall response time. Increase the
interval, and even more so on branch devices which may have limited i2c
bit rates.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263
Tested-by: Nicolas Suzor <nic@suzor.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 67c72a12254101d4e8d9b9f3a02646ba0be84a2d upstream.
This regression has been introduced in
commit 9f11a9e4e50006b615ba94722dfc33ced89664cf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jun 13 00:54:58 2013 +0200
drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms
Ville brough up the idea that this is just the pipe A quirk gone
wrong.
Note that after resume the bios might or might not have enabled pipe A
already. We have a bit of magic to make sure that on resume we set up
a decent mode for pipe A, but I fear if I just smash pipe A to always
on we'd enable it in a bogus state and hang the hw. Hence the
readback.
v2: Clarify the logic a bit as suggested by Chris. Also amend the
commit message to clarify why we don't unconditionally enable the
pipe.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462
References: https://lkml.org/lkml/2013/8/26/238
Cc: Meelis Roos <mroos@ut.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use |= instead of = as suggested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1062b81598bc00e2f6620e6f3788f8f8df2f01e7 upstream.
The native TV encoder has it's own flags to adjust sync modes and
enabled interlaced modes which are totally irrelevant for the adjusted
mode. This worked out nicely since the input modes used by both the
load detect code and reported in the ->get_modes callbacks all have no
flags set, and we also don't fill out any of them in the ->get_config
callback.
This changed with the additional sanitation done with
commit 2960bc9cceecb5d556ce1c07656a6609e2f7e8b0
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Jul 30 13:36:32 2013 +0300
drm/i915: make user mode sync polarity setting explicit
sinc now the "no flags at all" state wouldn't fit through core code
any more. So fix this up again by explicitly clearing the flags in the
->compute_config callback.
Aside: We have zero checking in place to make sure that the requested
mode is indeed the right input mode we want for the selected TV mode.
So we'll happily fall over if userspace tries to pull us. But that's
definitely work for a different patch series. So just add a FIXME
comment for now.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Knut Petersen <Knut_Petersen@t-online.de>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4f66c59922cbcda14c9e103e6c7f4ee616360d43 upstream.
Putting everything into VRAM seems to help.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 855f5f1d882a34e4e9dd27b299737cd3508a5624 upstream.
We were using the wrong set_properly callback so we always
ended up with Full scaling even if something else (Center or
Full aspect) was selected.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream.
The OUTPUT_ENABLE action jumps past the point in the coder where
the data_offset is set on certain rs780 cards. This worked
previously because the OUTPUT_ENABLE action is always called
immediately after the ENABLE action so the data_offset remained
set. In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
(drm/radeon/atom: initialize more atom interpretor elements to 0),
we explictly reset data_offset to 0 between atom calls which then
caused this to fail. The fix is to just skip calling the
OUTPUT_ENABLE action on the problematic chipsets. The ENABLE
action does the same thing and more. Ultimately, we could
probably drop the OUTPUT_ENABLE action all together on DCE3
asics.
fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791
v2: only rs880 seems to be affected
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream.
The table has the following format:
typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset pointing to this structure
{
UCHAR ucNumberOfSrc;
USHORT usSrcObjectID[1];
UCHAR ucNumberOfDst;
USHORT usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;
usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly. Use pointers and update the offset
appropriately when accessing the Dst members.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream.
Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on
some boards on resume. The systems seem to work fine
without touching this bit so leave it as is.
v2: read-modify-write the GART_INDEX_REG_EN bit.
I suspect the problem is that we are losing the other
settings in the register.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=52952
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Tested-by: Daniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 290d24576ccf1aa0373d2185cedfe262d0d4952a upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce6 asics.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=64850
Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream.
We need to allocate line buffer to each display when
setting up the watermarks. Failure to do so can lead
to a blank screen. This fixes blank screen problems
on dce4.1/5 asics.
Based on an initial fix from:
Jay Cornwall <jay.cornwall@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e5b9e7503eb1f4884efa3b321d3cc47806779202 upstream.
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
CP DMA has been supported since the 3.8 kernel, but due to an oversight
we forgot to teach the CS checker that the CP DMA packet was legal for
the compute ring on Southern Islands GPUs.
This patch fixes a bug where the radeon driver will incorrectly reject a legal
CP DMA packet from user space. I would like to have the patch
backported to stable so that we don't have to require Mesa users to use a
bleeding edge kernel in order to take advantage of this feature which
is already present in the stable kernels (3.8 and newer).
v2:
- Don't bump kms version, so this patch can be backported to stable
kernels.
Signed-off-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream.
Need to swap the data fetched over i2c properly. This
is the same fix as the endian fix for aux channel
transactions.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream.
If the LCD table contains an EDID record, properly account
for the edid size when walking through the records.
This should fix error messages about unknown LCD records.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5087f51da805f53cba7366f70d596e7bde2a5486 upstream.
Commit ea9197cc323839ef3d5280c0453b2c622caa6bc7 effectively enabled the
use of an improved DAC detection code, but introduced a regression on
the original nv50 chipset, causing a ghost monitor to be detected.
v2 (Ben Skeggs): the offending line was likely a thinko, removed it for
all chipsets (tested nv50 and nve6 to cover entire range) and added
some additional debugging.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67382
Tested-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 182b17c8dc4e83aab000ce86587b6810e515da87 upstream.
After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.
On nouveau, the first issue to be hit because of this is that
dma_address[] may be a NULL pointer. After working around this,
ttm_pool_unpopulate() may potentially hit the same issue with
the pages[] array.
It seems to make more sense to avoid calling unpopulate on already
unpopulated TTMs than to add checks to all the implementations.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2e8378136f28bea960cec643d3fa5d843c9049ec upstream.
When porting from UMS I mistyped this from the wrong place, AST noticed
and pointed it out, so we should fix it to be like the X.org driver.
Reported-by: Y.C. Chen <yc_chen@aspeedtech.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 101b96f32956ee99bf1468afaf572b88cda9f88b upstream.
DRM_IOCTL_MODE_GETFB is used to retrieve information about a given
framebuffer ID. It is a read-only helper and was thus declassified for
unprivileged access in:
commit a14b1b42477c5ef089fcda88cbaae50d979eb8f9
Author: Mandeep Singh Baines <mandeep.baines@gmail.com>
Date: Fri Jan 20 12:11:16 2012 -0800
drm: remove master fd restriction on mode setting getters
However, alongside width, height and stride information,
DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of
the framebuffer. This handle allows users to mmap() it and read or write
into it. Obviously, this should be restricted to DRM-Master.
With the current setup, *any* process with access to /dev/dri/card0 (which
means any process with access to hardware-accelerated rendering) can
access the current screen framebuffer and modify it ad libitum.
For backwards-compatibility reasons we want to keep the
DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful
information regarding screen setup. So we simply test whether the caller
is the current DRM-Master and if not, we return 0 as handle, which is
always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail
with EINVAL, but we accept this. Users shouldn't test for errors during
GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call.
v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 17e1df07df0fbc77696a1e1b6ccf9f2e5af70e40 upstream.
My g33 here seems to be shockingly good at hitting them all. This time
around kms_flip/flip-vs-panning-vs-hang blows up:
intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and
if a gpu hang is pending aborts the wait for outstanding flips so that
the setcrtc call will succeed and release the crtc mutex. And the gpu
hang handler needs that lock in intel_display_handle_reset to be able
to complete outstanding flips.
The problem is that we can race in two ways:
- Waiters on the dev_priv->pending_flip_queue aren't woken up after
we've the reset as pending, but before we actually start the reset
work. This means that the waiter doesn't notice the pending reset
and hence will keep on hogging the locks.
Like with dev->struct_mutex and the ring->irq_queue wait queues we
there need to wake up everyone that potentially holds a lock which
the reset handler needs.
- intel_display_handle_reset was called _after_ we've already
signalled the completion of the reset work. Which means a waiter
could sneak in, grab the lock and never release it (since the
pageflips won't ever get released).
Similar to resetting the gem state all the reset work must complete
before we update the reset counter. Contrary to the gem reset we
don't need to have a second explicit wake up call since that will
have happened already when completing the pageflips. We also don't
have any issues that the completion happens while the reset state is
still pending - wait_for_pending_flips is only there to ensure we
display the right frame. After a gpu hang&reset events such
guarantees are out the window anyway. This is in contrast to the gem
code where too-early wake-up would result in unnecessary restarting
of ioctls.
Also, since we've gotten these various deadlocks and ordering
constraints wrong so often throw copious amounts of comments at the
code.
This deadlock regression has been introduced in the commit which added
the pageflip reset logic to the gpu hang work:
commit 96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Feb 18 19:08:49 2013 +0200
drm/i915: Finish page flips and update primary planes after a GPU reset
v2:
- Add comments to explain how the wake_up serves as memory barriers
for the atomic_t reset counter.
- Improve the comments a bit as suggested by Chris Wilson.
- Extract the wake_up calls before/after the reset into a little
i915_error_wake_up and unconditionally wake up the
pending_flip_queue waiters, again as suggested by Chris Wilson.
v3: Throw copious amounts of comments at i915_error_wake_up as
suggested by Chris Wilson.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 122f46badaafbe651f05c2c0f24cadee692f761b upstream.
Since we've started to clean up pending flips when the gpu hangs in
commit 96a02917a0131e52efefde49c2784c0421d6c439
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Feb 18 19:08:49 2013 +0200
drm/i915: Finish page flips and update primary planes after a GPU reset
the gpu reset work now also grabs modeset locks. But since work items
on our private work queue are not allowed to do that due to the
flush_workqueue from the pageflip code this results in a neat
deadlock:
INFO: task kms_flip:14676 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kms_flip D ffff88019283a5c0 0 14676 13344 0x00000004
ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8
ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000
ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898
Call Trace:
[<ffffffff8138ee7b>] schedule+0x60/0x62
[<ffffffffa046c0dd>] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915]
[<ffffffff81050ff4>] ? finish_wait+0x60/0x60
[<ffffffffa0478041>] intel_crtc_set_config+0x7f3/0x81e [i915]
[<ffffffffa031780a>] drm_mode_set_config_internal+0x4f/0xc6 [drm]
[<ffffffffa0319cf3>] drm_mode_setcrtc+0x44d/0x4f9 [drm]
[<ffffffff810e44da>] ? might_fault+0x38/0x86
[<ffffffffa030d51f>] drm_ioctl+0x2f9/0x447 [drm]
[<ffffffff8107a722>] ? trace_hardirqs_off+0xd/0xf
[<ffffffffa03198a6>] ? drm_mode_setplane+0x343/0x343 [drm]
[<ffffffff8112222f>] ? mntput_no_expire+0x3e/0x13d
[<ffffffff81117f33>] vfs_ioctl+0x18/0x34
[<ffffffff81118776>] do_vfs_ioctl+0x396/0x454
[<ffffffff81396b37>] ? sysret_check+0x1b/0x56
[<ffffffff81118886>] SyS_ioctl+0x52/0x7d
[<ffffffff81396b12>] system_call_fastpath+0x16/0x1b
2 locks held by kms_flip/14676:
#0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa0316545>] drm_modeset_lock_all+0x22/0x59 [drm]
#1: (&crtc->mutex){+.+.+.}, at: [<ffffffffa031656b>] drm_modeset_lock_all+0x48/0x59 [drm]
INFO: task kworker/u8:4:175 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u8:4 D ffff88018de9a5c0 0 175 2 0x00000000
Workqueue: i915 i915_error_work_func [i915]
ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8
ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018
0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0
Call Trace:
[<ffffffff8138ee7b>] schedule+0x60/0x62
[<ffffffff8138f23d>] schedule_preempt_disabled+0x9/0xb
[<ffffffff8138d0cd>] mutex_lock_nested+0x205/0x3b1
[<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915]
[<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915]
[<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915]
[<ffffffffa044e0a2>] i915_error_work_func+0x128/0x147 [i915]
[<ffffffff8104a89a>] process_one_work+0x1d4/0x35a
[<ffffffff8104a821>] ? process_one_work+0x15b/0x35a
[<ffffffff8104b4a5>] worker_thread+0x144/0x1f0
[<ffffffff8104b361>] ? rescuer_thread+0x275/0x275
[<ffffffff8105076d>] kthread+0xac/0xb4
[<ffffffff81059d30>] ? finish_task_switch+0x3b/0xc0
[<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60
[<ffffffff81396a6c>] ret_from_fork+0x7c/0xb0
[<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60
3 locks held by kworker/u8:4/175:
#0: (i915){.+.+.+}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a
#1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a
#2: (&crtc->mutex){+.+.+.}, at: [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915]
This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible
on one of my older machines.
Unfortunately (despite the proper lockdep annotations for
flush_workqueue) lockdep still doesn't detect this correctly, so we
need to rely on chance to discover these bugs.
Apply the usual bugfix and schedule the reset work on the system
workqueue to keep our own driver workqueue free of any modeset lock
grabbing.
Note that this is not a terribly serious regression since before the
offending commit we'd simply have stalled userspace forever due to
failing to abort all outstanding pageflips.
v2: Add a comment as requested by Chris.
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 118bdbd86b39dbb843155054021d2c59058f1e05 upstream.
This LCD monitor (1280x1024 native) has a completely
bogus detailed timing (640x350@70hz). User reports that
1280x1024@60 has waves so prefer 1280x1024@75.
Manufacturer: MED Model: 7b8 Serial#: 99188
Year: 2005 Week: 5
EDID Version: 1.3
Analog Display Input, Input Voltage Level: 0.700/0.700 V
Sync: Separate
Max Image Size [cm]: horiz.: 34 vert.: 27
Gamma: 2.50
DPMS capabilities: Off; RGB/Color Display
First detailed timing is preferred mode
redX: 0.645 redY: 0.348 greenX: 0.280 greenY: 0.605
blueX: 0.142 blueY: 0.071 whiteX: 0.313 whiteY: 0.329
Supported established timings:
720x400@70Hz
640x480@60Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
Manufacturer's mask: 0
Supported standard timings:
Supported detailed timing:
clock: 25.2 MHz Image Size: 337 x 270 mm
h_active: 640 h_sync: 688 h_sync_end 784 h_blank_end 800 h_border: 0
v_active: 350 v_sync: 350 v_sync_end 352 v_blanking: 449 v_border: 0
Monitor name: MD30217PG
Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
Serial No: 501099188
EDID (in hex):
00ffffffffffff0034a4b80774830100
050f010368221b962a0c55a559479b24
125054afcf00310a0101010101018180
000000000000d60980a0205e63103060
0200510e1100001e000000fc004d4433
3032313750470a202020000000fd0038
4c1e530e000a202020202020000000ff
003530313039393138380a2020200078
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: friedrich@mailstation.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 77fa4cbd5fa389e28419bbe8ac491b5fdd54840d upstream.
Fix the typo introduced in
commit 1a2eb4604b85c5efb343da8a4dcf41288fcfca85
Author: Keith Packard <keithp@keithp.com>
Date: Wed Nov 16 16:26:07 2011 -0800
drm/i915: Hook up Ivybridge eDP
This fixes eDP link-training failures and cases where all voltage swing
/pre-emphasis levels were tried and failed during clock recovery and -
as a fallback - we go on to do channel equalization with the last voltage
swing/pre-emphasis level which will succeed. Both issues can lead to a
blank screen.
v2:
- improve commit message
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64880
Tested-by: Jeremy Moles <cubicool@gmail.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f upstream.
This fixes the piglit test texturing/max-texture-size
causing the VM to die due to a too large SVGA command.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Biran Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6ff8c76a566f823d796359a6c1d76b7668f1e34d upstream.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream.
After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.
Based on a patch by naresh kumar kachhi <naresh.kumar.kacchi@intel.com>
Reported-by: Thiago Macieira <thiago@kde.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thiago Macieira <thiago@kde.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d43a93c8d9bc4e0dc0293b6458c077c3c797594f upstream.
This bug (introduced in 3.10) in WREG32_OR made
commit d3418eacad403033e95e49dc14afa37c2112c134
"drm/radeon/evergreen: setup HDMI before enabling it"
cause a regression. Sometimes audio over HDMI wasn't working, sometimes
display was corrupted.
This fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60687
https://bugzilla.kernel.org/show_bug.cgi?id=60709
https://bugs.freedesktop.org/show_bug.cgi?id=67767
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 112a6d0c071808f6d48354fc8834a574e5dcefc0 upstream.
When the message buffer is currently moving block until it is idle again.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 022374c02e357ac82e98dd2689fb2efe05723d69 upstream.
Uses the wrong array size for some asics which can lead
to garbage getting written to registers.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60674
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6fab3febf6d949b0a12b1e4e73db38e4a177a79e upstream.
For r6xx+ asics. This mirrors the behavior of pre-r6xx
asics. We need to program the MC even if something
else in startup() fails. Failure to do so results in
an unusable GPU.
Based on a fix from: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[ rebased for 3.10 and dropped the drivers/gpu/drm/radeon/cik.c
bit as it's 3.11 specific code / tmb ]
Signed-off-by: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4ad9c1c774c2af152283f510062094e768876f55 upstream.
Otherwise just reinitialize from scratch on resume,
and so make it more likely to succeed.
v2: rebased for 3.10-stable tree
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2858c00d2823c83acce2a1175dbabb2cebee8678 upstream.
Removing the clock/power or resetting the VCPU can cause
hangs if that happens in the middle of a register write.
Stall the memory and register bus before putting the VCPU
into reset. Keep it in reset when unloading the module or
suspending.
v2: rebased on 3.10-stable tree
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 14c5cec5d0cd73e7e9d4fbea2bbfeea8f3ade871 upstream.
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jul 21 13:16:24 2013 +0200
drm/i915: fix up gt init sequence fallout
moved dev_priv->gt_lock initialization after use. Do the initialization
much earlier with other spin lock initializations.
Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Zhouping Liu <zliu@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 641a00593f7d07eab778fbabf546fb68fff3d5ce upstream.
We also need to check the handle.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e1accbf0543eecfdb161131208c3dfefee22d61f upstream.
There are two audio dtos on radeon asics that you can
select between. Normally, dto0 is used for hdmi and
dto1 for DP, but it seems that the dto is somehow
tied to the encoders on DCE3 asics.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=67435
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e91abf80a0998f326107874c88d549f94839f13c upstream.
It takes an unsigned value. This happens not to blow up on 64-bit
architectures, but it does on 32-bit, causing
drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus
timestamps for vblank events. Which in turn causes e.g. gnome-shell to
hang after a DPMS off cycle with current xf86-video-ati Git.
[airlied: regression introduced in drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59339
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59836
Tested-by: shui yangwei <yangweix.shui@intel.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3ac65259328324de323dc006b52ff7c1a5b18d19 upstream.
same fix as cirrus and mgag200.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ecaac1c866bcda4780a963b3d18cd310d971aea3 upstream.
When a BO gets pinned the placement may get changed. If the memory is
mapped into user space and user space has already accessed the mapped
range the page tables are set up but now point to the wrong memory.
Set bo.mdev->dev_mapping in mgag200_bo_create() to make sure that
ttm_bo_unmap_virtual() called from ttm_bo_handle_move_mem() will take
care of this.
v2: Don't call ttm_bo_unmap_virtual() in mgag200_bo_pin(), fix comment.
Signed-off-by: Egbert Eich <eich@suse.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 109a51598869a39fdcec2d49672a9a39b6d89481 upstream.
This is a cirrus version of Egbert Eich's patch for mgag200.
Without bo.bdev->dev_mapping set, the ttm_bo_unmap_virtual_locked
called from ttm_bo_handle_move_mem returns with no effect. If any
application accessed the memory before it was moved, it will
access wrong memory next time. This causes crashes when changing
resolution down.
Signed-off-by: Michal Srb <msrb@suse.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 09ede5414f0215461c933032630bf9c3a61a8ba3 upstream.
We need to track this correctly. While at it shovel the boolean
to track whether the sdvo is in tv mode or not into pipe_config.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997
Tested-by: Pierre Assal <pierre.assal@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63609
Tested-by: cancan,feng <cancan.feng@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9cc2e0e9f13315559c85c9f99f141e420967c955 upstream.
Changing the UVD BOs offset on suspend/resume doesn't work because the VCPU
internally keeps pointers to it. Just keep it always pinned and save the
content manually.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=66425
v2: fix compiler warning
v3: fix CIK support
v4: rebased for 3.10-stable tree
Note: a version of this patch needs to go to stable.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bcf53de4e60d9000b82f541d654529e2902a4c2c upstream.
Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes
on eDP. This fixes eDP on hsw with > 2 lanes.
Also s/port_reversal/saved_port_bits/ since the current name is
confusing.
Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Zhouping Liu <zliu@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit aeea40cbf9388fc829e66fa049f64d97fd72e118 upstream.
They still seem to cause instability on some r6xx parts.
As a follow up, we can switch to using CP DMA for bo
moves on r6xx as a lighter weight alternative to using
the 3D engine.
A version of this patch should also go to stable kernels.
Tested-by: J.N. <golden.fleeced@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 067556084a0e412013af6b0250a3143ae5afde6d upstream.
obj->mm_list link to dev_priv->mm.inactive_list/active_list
obj->global_list link to dev_priv->mm.unbound_list/bound_list
This regression has been introduced in
commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 10 18:03:00 2013 +0100
drm/i915: Revert shrinker changes from "Track unbound pages"
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Add regression notice.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zhouping Liu <zliu@redhat.com>
|
|
commit a01c34f72e7cd2624570818f579b5ab464f93de2 upstream.
Fix a warning from lockdep caused by calling flush_work() for
uninitialized hotplug work. Initialize hotplug_work, audio_work
and reset_work upon successful radeon_irq_kms_init() completion
and thus perform hotplug flush_work only when rdev->irq.installed
is true.
[ 4.790019] [drm] Loading CEDAR Microcode
[ 4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
[ 4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[ 4.791330] radeon 0000:01:00.0: disabling GPU acceleration
[ 4.792633] INFO: trying to register non-static key.
[ 4.792792] the code is fine but needs lockdep annotation.
[ 4.792953] turning off the locking correctness validator.
[ 4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
[ 4.793314] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011
[ 4.793507] ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
[ 4.794155] ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
[ 4.794789] ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
[ 4.795418] Call Trace:
[ 4.795573] [<ffffffff8160434e>] dump_stack+0x4e/0x82
[ 4.795731] [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30
[ 4.795893] [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60
[ 4.796034] [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200
[ 4.796216] [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[ 4.796375] [<ffffffff8106cdad>] flush_work+0x3d/0x280
[ 4.796520] [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[ 4.796682] [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 4.796862] [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0
[ 4.797024] [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70
[ 4.797186] [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0
[ 4.797347] [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700
[ 4.797511] [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50
[ 4.797672] [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150
[ 4.797843] [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280
[ 4.798007] [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0
[ 4.798168] [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0
[ 4.798329] [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0
[ 4.798489] [<ffffffff81339404>] pci_device_probe+0x84/0xe0
[ 4.798644] [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240
[ 4.798805] [<ffffffff814aca73>] __driver_attach+0x93/0xa0
[ 4.798948] [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40
[ 4.799126] [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0
[ 4.799272] [<ffffffff814ac2be>] driver_attach+0x1e/0x20
[ 4.799434] [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280
[ 4.799596] [<ffffffff814ad0e4>] driver_register+0x74/0x150
[ 4.799758] [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60
[ 4.799936] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[ 4.800081] [<ffffffff813ce655>] drm_pci_init+0x115/0x130
[ 4.800243] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[ 4.800405] [<ffffffff81d16f98>] radeon_init+0x9c/0xba
[ 4.800586] [<ffffffff810002ca>] do_one_initcall+0xfa/0x150
[ 4.800746] [<ffffffff81073f60>] ? parse_args+0x120/0x330
[ 4.800909] [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191
[ 4.801052] [<ffffffff81cda87a>] ? do_early_param+0x88/0x88
[ 4.801233] [<ffffffff815fb670>] ? rest_init+0x140/0x140
[ 4.801393] [<ffffffff815fb67e>] kernel_init+0xe/0x180
[ 4.801556] [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0
[ 4.801718] [<ffffffff815fb670>] ? rest_init+0x140/0x140
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.
The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base. While here initialize all the
atom interpretor elements to 0.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60639
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|