summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2015-03-16[PATCH] drm/mm: Fix support 4 GiB and larger rangesKrzysztof Kolasa1-1/+1
bad argument if(tmp)... in check_free_hole fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305! [airlied: excellent, this was my task for today]. Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl> Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-13Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2-27/+47
into drm-fixes Some additional radeon fixes for 4.0 * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: drop setting UPLL to sleep mode drm/radeon: fix wait to actually occur after the signaling callback
2015-03-13Merge branch 'vmwgfx-fixes-4.0' of ↵Dave Airlie3-57/+53
git://people.freedesktop.org/~thomash/linux into drm-fixes A couple of fixes for vmwgfx. * 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Fix an issue with the device losing its irq line on module unload drm/vmwgfx: Correctly NULLify dma buffer pointer on failure drm/vmwgfx: Reorder device takedown somewhat drm/vmwgfx: Fix a couple of lock dependency violations
2015-03-13Merge tag 'drm-intel-fixes-2015-03-12' of ↵Dave Airlie3-7/+28
git://anongit.freedesktop.org/drm-intel into drm-fixes More i915 fixes, three out of four are fixes to old bugs, cc: stable. * tag 'drm-intel-fixes-2015-03-12' of git://anongit.freedesktop.org/drm-intel: drm/i915: Prevent TLB error on first execution on SNB drm/i915: Do both mt and gen6 style forcewake reset on ivb probe drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again drm/i915: use in_interrupt() not in_irq() to check context
2015-03-11drm/vmwgfx: Fix an issue with the device losing its irq line on module unloadThomas Hellstrom1-0/+1
Starting with commit b4b55cda5874 ("x86/PCI: Refine the way to release PCI IRQ resources") the device lost its irq resource on module unload. While that's ok and apparently intentional, the driver never got the resource back on module load The code apparently wants drivers to disable the pci device at pci device driver removal, so lets do that. That fixes the issue. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2015-03-11drm/vmwgfx: Correctly NULLify dma buffer pointer on failureColin Ian King1-4/+6
cppcheck on lines 917 and 977 show an ineffective assignment to the dma buffer pointer: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]: [drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]: (warning) Assignment of function parameter has no effect outside the function. Did you forget dereferencing it? On a successful DMA buffer lookup, the dma buffer pointer is assigned, however, on failure it currently is left in an undefined state. The original intention in the error exit path was to nullify the pointer on an error (which the original code failed to do properly). This patch fixes this also ensures all failure paths nullify the buffer pointer on the error return. Fortunately the callers to vmw_translate_mob_ptr and vmw_translate_guest_ptr are checking on a return status and not on the dma buffer pointer, so the original code worked. Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Colin Ian King <colin.king@canonical.com>
2015-03-11drm/vmwgfx: Reorder device takedown somewhatThomas Hellstrom1-37/+40
To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2015-03-11drm/vmwgfx: Fix a couple of lock dependency violationsThomas Hellstrom2-16/+6
Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Cc: <stable@vger.kernel.org> Acked-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2015-03-11drm/radeon: drop setting UPLL to sleep modeChristian König1-4/+2
Just keep it working, seems to fix some PLL problems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378 Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-11drm/radeon: fix wait to actually occur after the signaling callbackMaarten Lankhorst1-23/+45
A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com> Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com> Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Cc: stable@vger.kernel.org (v3.18+) Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-10drm/i915: Prevent TLB error on first execution on SNBChris Wilson1-2/+16
Long ago I found that I was getting sporadic errors when booting SNB, with the symptom being that the first batch died with IPEHR != *ACTHD, typically caused by the TLB being invalid. These magically disappeared if I held the forcewake during the entire ring initialisation sequence. (It can probably be shortened to a short critical section, but the whole initialisation is full of register writes and so we would be taking and releasing forcewake almost continually, and so holding it over the entire sequence will probably be a net win!) Note some of the kernels I encounted the issue already had the deferred forcewake release, so it is still relevant. I know that there have been a few other reports with similar failure conditions on SNB, I think such as References: https://bugs.freedesktop.org/show_bug.cgi?id=80913 v2: Wrap i915_gem_init_hw() with its own security blanket as we take that path following resume and reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-10drm/i915: Do both mt and gen6 style forcewake reset on ivb probeMika Kuoppala1-1/+7
commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code") failed to take into account that we have used to reset both the gen6 style and the multithreaded style forcewake registers. This is due to fact that ivb can use either, depending on how the bios has set up the machine. Mimic the old semantics before we have determined the correct variety and reset both before the ecobus probe. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Huang Ying <ying.huang@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-10drm/i915: Make WAIT_IOCTL negative timeouts be indefinite againChris Wilson1-3/+4
This fixes a regression from commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9 Author: Thomas Gleixner <tglx@linutronix.de> Date: Wed Jul 16 21:05:06 2014 +0000 drm: i915: Use nsec based interfaces that made a negative timeout return immediately rather than the previously defined behaviour of waiting indefinitely. Testcase: igt/gem_wait Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89494 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Kristian Høgsberg <krh@bitplanet.net> Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: fixed a checkpatch complaint about whitespace.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-10drm/i915: use in_interrupt() not in_irq() to check contextDave Gordon1-1/+1
The kernel in_irq() function tests for hard-IRQ context only, so if a system is run with the kernel 'threadirqs' option selected, the test in intel_check_page_flip() generates lots of warnings, because then it gets called in soft-IRQ context. We can instead use in_interrupt() which allows for either type of interrupt, while still detecting and complaining about misuse of the page flip code if it is ever called from non-interrupt context. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321 Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-10drm/mst: fix recursive sleep warning on qlockDaniel Vetter1-3/+8
With drm-next, we can get a backtrace from sleeping with mutex detection. this is due to the callback checking the txmsg state taking the mutex, which can cause a sleep inside a sleep, Daniel went over it and was happy we could drop this mutex in this case. Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-10drm: Don't assign fbs for universal cursor support to filesChris Wilson1-16/+19
The internal framebuffers we create to remap legacy cursor ioctls to plane operations for the universal plane support shouldn't be linke to the file like normal userspace framebuffers. This bug goes back to the original universal cursor plane support introduced in commit 161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Jun 10 08:28:10 2014 -0700 drm: Support legacy cursor ioctls via universal planes when possible (v4) The isn't too disastrous since fbs are small, we only create one when the cursor bo gets changed and ultimately they'll be reaped when the window server restarts. Conceptually we'd want to just pass NULL for file_priv when creating it, but the driver needs the file to lookup the underlying buffer object for cursor id. Instead let's move the file_priv linking out of add_framebuffer_internal() into the addfb ioctl implementation, which is the only place it is needed. And also rename the function for a more accurate since it only creates the fb, but doesn't add it anywhere. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-07Merge tag 'drm-intel-fixes-2015-03-05' of ↵Dave Airlie2-16/+32
git://anongit.freedesktop.org/drm-intel into drm-fixes two fixes, both cc'd stable. * tag 'drm-intel-fixes-2015-03-05' of git://anongit.freedesktop.org/drm-intel: drm/i915: gen4: work around hang during hibernation drm/i915: Check for driver readyness before handling an underrun interrupt
2015-03-07Merge tag 'v4.0-rc2' into drm-fixesDave Airlie1-0/+1
Linux 4.0-rc2 Merging this manually as the i915 change is in it, and intel fixes are on top of this
2015-03-05Merge branch 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux ↵Dave Airlie6-53/+81
into drm-fixes Fixup some fallout of the fallout of atomic dpms, few mdp5 cursor fixes, fix a leak in error path, and some fixes for kexec * 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux: drm/msm: kexec fixes drm/msm/mdp5: fix cursor blending drm/msm/mdp5: fix cursor ROI drm/msm/atomic: Don't leak atomic commit object when commit fails drm/msm/mdp5: Avoid flushing registers when CRTC is disabled drm/msm: update generated headers (add 6th lm.base entry) drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
2015-03-04drm/msm: kexec fixesRob Clark2-0/+10
In kexec environment, we are more likely to encounter irq's already enabled from previous environment. At which point we find that writes to disable/clear pending irq's are slightly less than useless without first enabling clocks. TODO: full blown state read-in so kexec'd kernel can inherit the mode already setup. Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fix cursor blendingRob Clark1-1/+0
Seems like we just want BLEND_EN and not BLEND_TRANSP_EN (setting the latter results in black pixels in the cursor image treated as transparent). Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fix cursor ROIRob Clark1-28/+40
If cursor is set near the edge of the screen, it is not valid to use the new cursor width/height as the ROI dimensions. Split out the ROI calc and use it both cursor_set and cursor_move. Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/atomic: Don't leak atomic commit object when commit failsLaurent Pinchart1-1/+3
If the atomic commit fails due to completion wait interruption the atomic commit object is not freed and is thus leaked. Free it. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: Avoid flushing registers when CRTC is disabledStephane Viau1-7/+19
When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL); in that case we should not try to FLUSH registers and do nothing instead. This can happen when we try to move a cursor but the CRTC's CTL (CONTROL) has not been allocated yet (inactive CRTC). It can also happens when we .atomic_check()/.atomic_flush() on a disabled CRTC. A CTL needs to be kept as long as the CRTC is alive. Releasing it after the last VBlank is safer than in .atomic_flush(). Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm: update generated headers (add 6th lm.base entry)Stephane Viau1-11/+4
Some target have up to 6 layer mixers (LM). Let the header file access the last LM's base address. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-04drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"Stephane Viau2-5/+5
Commit 0b776d457b94 ("drm/msm: fix fallout of atomic dpms changes") has a typo in both mdp5_encoder_helper_funcs and mdp5_crtc_helper_funcs definitions: .dpms entry should be replaced by .disable and .enable Also fixed a typo in mdp5_encoder_enable(). Note that these typos are only present for MDP5. MDP4 is fine. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2015-03-05Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie14-127/+122
into drm-fixes Radeon fixes for 4.0: - Fix some fallout from the audio rework - Fix a possible oops in the CS ioctl - Fix interlaced modes on DCE8 - Do a posting read in irq_set callbacks to make sure interrupts are properly flushed through the pci bridge * 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix interlaced modes on DCE8 drm/radeon: fix DRM_IOCTL_RADEON_CS oops drm/radeon: do a posting read in cik_set_irq drm/radeon: do a posting read in si_set_irq drm/radeon: do a posting read in evergreen_set_irq drm/radeon: do a posting read in r600_set_irq drm/radeon: do a posting read in rs600_set_irq drm/radeon: do a posting read in r100_set_irq radeon/audio: fix DP audio on DCE6 radeon/audio: fix whitespace drm/radeon: adjust audio callback order drm/radeon: properly set dto for dp on DCE4/5 drm/radeon/audio: update EDID derived fields in modeset drm/radeon: don't toggle audio state in modeset drm/radeon/audio: set mute around state setup drm/radeon: assign pin in detect drm/radeon: fix the audio dpms callbacks
2015-03-05drm/ttm: device address space != CPU address spaceAlex Deucher2-2/+2
We need to store device offsets in 64 bit as the device address space may be larger than the CPU's. Fixes GPU init failures on radeons with 4GB or more of vram on 32 bit kernels. We put vram at the start of the GPU's address space so the gart aperture starts at 4 GB causing all GPU addresses in the gart aperture to get truncated. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89072 [airlied: fix warning on nouveau build] Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: thellstrom@vmware.com Acked-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-05drm/mm: Support 4 GiB and larger rangesThierry Reding3-78/+84
The current implementation is limited by the number of addresses that fit into an unsigned long. This causes problems on 32-bit Tegra where unsigned long is 32-bit but drm_mm is used to manage an IOVA space of 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 (or 4 GiB - 4 KiB for page granularity). This commit changes the start and size of the range to be an unsigned 64-bit integer, thus allowing much larger ranges to be supported. [airlied: fix i915 warnings and coloring callback] Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com> fixupo
2015-03-04drm/i915: gen4: work around hang during hibernationImre Deak1-5/+25
Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak <imre.deak@intel.com> Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. v2: - Another GEN4 Lenovo laptop had the same issue, while platforms from other vendors (including mobile and desktop, GEN4 and non-GEN4) seem to work fine. Based on this apply the workaround on all GEN4 Lenovo platforms. - add code comment about failing platforms (Ville) Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork <bjorn@mork.no> Cc: stable@vger.kernel.org # v3.19 Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-04drm/i915: Check for driver readyness before handling an underrun interruptChris Wilson1-11/+7
When we takeover from the BIOS and install our interrupt handler, the BIOS may have left us a few surprises in the form of spontaneous interrupts. (This is especially likely on hardware like 965gm where display fifo underruns are continuous and the GMCH cannot filter that interrupt souce.) As we enable our IRQ early so that we can use it during hardware probing, our interrupt handler must be prepared to handle a few sources prior to being fully configured. As such, we need to add a simple is-ready check prior to dereferencing our KMS state for reporting underruns. Reported-by: Rob Clark <rclark@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org [Jani: dropped the extra !] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-03drm/radeon: fix interlaced modes on DCE8Alex Deucher1-0/+3
Need to double the viewport height. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: fix DRM_IOCTL_RADEON_CS oopsTommi Rantala1-1/+3
Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the following oops. Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort(). ---------------------------------- #include <stdint.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <drm/radeon_drm.h> static const struct drm_radeon_cs cs; int main(int argc, char **argv) { return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs); } ---------------------------------- [ttrantal@test2 ~]$ ./main /dev/dri/card0 [ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null) [ 46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0 [ 46.905022] Oops: 0002 [#1] SMP [ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58 [ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007 [ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000 [ 46.905022] RIP: 0010:[<ffffffff814d6df2>] [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246 [ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58 [ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000 [ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410 [ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0 [ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000 [ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0 [ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [ 46.905022] Stack: [ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] Call Trace: [ 46.905022] [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220 [ 46.905022] [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960 [ 46.905022] [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640 [ 46.905022] [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 46.905022] [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10 [ 46.905022] [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80 [ 46.905022] [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570 [ 46.905022] [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110 [ 46.905022] [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0 [ 46.905022] [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17 [ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85 [ 46.905022] RIP [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP <ffff880058e67998> [ 46.905022] CR2: 0000000000000000 [ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]--- Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in cik_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in si_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in evergreen_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in r600_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in rs600_set_irqAlex Deucher1-0/+4
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in r100_set_irqAlex Deucher1-0/+4
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03radeon/audio: fix DP audio on DCE6Slava Grigorev2-4/+12
Split DCE6 and DCE8 programming of DCCG_AUDIO_DTO1 registers to properly enable DP audio for both DCE revisions. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03radeon/audio: fix whitespaceSlava Grigorev1-16/+16
Use proper tabs. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: adjust audio callback orderAlex Deucher1-14/+16
- Move it out of the UNIPHY case to handle older DCE blocks. - set audio dpms before video dpms Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: properly set dto for dp on DCE4/5Alex Deucher2-3/+10
If DCPLL or ext PLL is used, use the disp clk. If PPLL is used, use the dp clock. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon/audio: update EDID derived fields in modesetAlex Deucher1-5/+6
We don't necessarily have an EDID at this point when audio detect gets called. Ideally we'd update these fields in detect, but that requires a larger rework of the display detect code. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: don't toggle audio state in modesetAlex Deucher1-12/+1
Should be done only at detect time to avoid spurious state changes on the audio side. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon/audio: set mute around state setupAlex Deucher1-1/+2
To avoid possible sound artifacts while setting up audio. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: assign pin in detectAlex Deucher1-3/+3
We need the pin from detect on, it's too late in dpms. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: fix the audio dpms callbacksAlex Deucher4-70/+32
Don't touch the audio enable bits as these are already handled in display detection. Enable the hdmi secondary streams in hdmi enable to match dp. Rename dp dpms callback to be consistent with hdmi. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89327 https://bugzilla.kernel.org/show_bug.cgi?id=93921 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/i915: Fix modeset state confusion in the load detect codeDaniel Vetter1-0/+1
This is a tricky story of the new atomic state handling and the legacy code fighting over each another. The bug at hand is an underrun of the framebuffer reference with subsequent hilarity caused by the load detect code. Which is peculiar since the the exact same code works fine as the implementation of the legacy setcrtc ioctl. Let's look at the ingredients: - Currently our code is a crazy mix of legacy modeset interfaces to set the parameters and half-baked atomic state tracking underneath. While this transition is going we're using the transitional plane helpers to update the atomic side (drm_plane_helper_disable/update and friends), i.e. plane->state->fb. Since the state structure owns the fb those functions take care of that themselves. The legacy state (specifically crtc->primary->fb) is still managed by the old code (and mostly by the drm core), with the fb reference counting done by callers (core drm for the ioctl or the i915 load detect code). The relevant commit is commit ea2c67bb4affa84080c616920f3899f123786e56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) - drm_plane_helper_disable has special code to handle multiple calls in a row - it checks plane->crtc == NULL and bails out. This is to match the proper atomic implementation which needs the crtc to get at the implied locking context atomic updates always need. See commit acf24a395c5a9290189b080383564437101d411c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 29 15:33:05 2014 +0200 drm/plane-helper: transitional atomic plane helpers - The universal plane code split out the implicit primary plane from the CRTC into it's own full-blown drm_plane object. As part of that the setcrtc ioctl (which updated both the crtc mode and primary plane) learned to set crtc->primary->crtc on modeset to make sure the plane->crtc assignments statate up to date in commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Apr 1 15:22:38 2014 -0700 drm: Add drm_crtc_init_with_planes() (v2) Unfortunately we've forgotten to update the load detect code. Which wasn't a problem since the load detect modeset is temporary and always undone before we drop the locks. - Finally there is a organically grown history (i.e. don't ask) around who sets the legacy plane->fb for the various driver entry points. Originally updating that was the drivers duty, but for almost all places we've moved that (plus updating the refcounts) into the core. Again the exception is the load detect code. Taking all together the following happens: - The load detect code doesn't set crtc->primary->crtc. This is only really an issue on crtcs never before used or when userspace explicitly disabled the primary plane. - The plane helper glue code short-circuits because of that and leaves a non-NULL fb behind in plane->state->fb and plane->fb. The state fb isn't a real problem (it's properly refcounted on its own), it's just the canary. - Load detect code drops the reference for that fb, but doesn't set plane->fb = NULL. This is ok since it's still living in that old world where drivers had to clear the pointer but the core/callers handled the refcounting. - On the next modeset the drm core notices plane->fb and takes care of refcounting it properly by doing another unref. This drops the refcount to zero, leaving state->plane now pointing at freed memory. - intel_plane_duplicate_state still assume it owns a reference to that very state->fb and bad things start to happen. Fix this all by applying the same duct-tape as for the legacy setcrtc ioctl code and set crtc->primary->crtc properly. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: Rob Clark <robdclark@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matt Roper <matthew.d.roper@intel.com> Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-03-03Revert "drm/rockchip: Flip select/depends in Kconfig"Dave Airlie1-1/+1
This reverts commit 9c58e8dbd3bfe7197323c88a784617afeffa9f87. This doesn't seem to fully fix this, Kbuild who knows. Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 11:29:57 +0000