aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2014-01-23drm/nve0/fb/gddr5: fixup delays a bitBen Skeggs1-2/+1
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/bios: timing 2.0 entries can have subentriesBen Skeggs6-23/+34
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: note another semi-unknownBen Skeggs1-14/+17
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/fb/gddr5: modify mr8 with high bits of CL/WRBen Skeggs1-0/+4
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: fix calculation of RDQS settingBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: switch off some other random bit at some pointBen Skeggs1-1/+1
As seen when comparing us vs nv on my GTX660 Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: punt all 10f910/914 accesses through ram_trainBen Skeggs1-12/+9
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: not all memory partitions are created equalBen Skeggs4-15/+76
As seen when comparing us vs nv on my GTX660. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb: typo in register nameBen Skeggs1-4/+4
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/bios: make common code to handle ramcfg strap etcBen Skeggs8-91/+86
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: fix an assumption of sane memory controller layoutBen Skeggs1-7/+10
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fb/gddr5: fix behaviour of lp3 settingBen Skeggs2-2/+5
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: recover from mmu faults on bar1/bar3Ben Skeggs2-12/+22
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: keep mmu fault interrupts enabled at all timesBen Skeggs1-1/+16
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: update human-readable mmu fault descriptionsBen Skeggs1-11/+87
Ordering from Android GK20A driver, names from binary driver strings. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: document more intr status bitsBen Skeggs1-5/+72
As per Android GK20A driver. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: populate PBDMA status bitfield with more definitionsBen Skeggs1-2/+30
As per Android GK20A driver. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: s/subfifo/PBDMA/Ben Skeggs1-15/+15
As per Android GK20A driver. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nve0/fifo: s/playlist/runlist/Ben Skeggs1-14/+20
As per Android GK20A driver. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nvf0/gr: enable acceleration with our chsw ucodeBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv108/gr: enable acceleration with our chsw ucodeBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nvc0-/gr: handle fwmthd interrupts in ucodeBen Skeggs7-294/+308
Compute code in mesa triggers one of these, hanging the engine. Let's at least ack the request for now to avoid the hang. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nvc0-/gr: fiddle some magic around strand initBen Skeggs7-1110/+1191
Fixes HUB_INIT timeout on GK110/GK208 when not using NVIDIA's ucode. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv108/gr: initial support (need external fuc)Ben Skeggs13-10/+3074
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv108/ce: enable copy enginesBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv108/fifo: initial supportBen Skeggs6-55/+115
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nvf0/gr: remove a copy+pasto in ctx reglistBen Skeggs1-1/+0
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nvc0-/gr: bring in some macros to abstract falcon isa differencesBen Skeggs12-3943/+4431
Need. A. Compiler... Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/falcon: use vmalloc to create firwmare copiesIlia Mirkin1-5/+15
Some firmware images may be large (64K), so using kmalloc memory is inappropriate for them. Use vmalloc instead, to avoid high-order allocation failures. Signed-off-by: Ilia Mirkin <[email protected]> Cc: [email protected]
2014-01-23drm/nouveau/gem: remove (now) unneeded pre-validate fence syncBen Skeggs1-6/+0
Now that nouveau_bo.c can handle sync when it actually needs to, we can remove this and avoid a double semaphore acquire when syncing in the command submission path. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/ttm: explicitly wait for bo idle before memcpy buffer moveBen Skeggs1-19/+18
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/ttm: explicity sync with kernel channel before moving bufferBen Skeggs1-28/+13
The GEM code handles this currently, but that'll be removed. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/ttm: tidy up creation of temporary buffer move vmasBen Skeggs1-20/+21
Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv04/plane: add support for nv04/nv05 video overlayIlia Mirkin1-10/+166
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv10/plane: add YUYV supportIlia Mirkin1-3/+4
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nv50-: map TTM_PL_SYSTEM through a BAR for CPU accessMaarten Lankhorst1-3/+17
Moves bo's to TTM_PL_TT for BAR mapping, to hide tiling from user. Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau: fix m2mf copy to tiled gartMaarten Lankhorst1-25/+8
Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <[email protected]> Cc: [email protected] #3.10+ Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/nouveau/vm: reduce number of entry-points to vm_map()Ben Skeggs5-44/+33
Pretty much everywhere had to make the decision which to use, so it makes a lot more sense to just have one entrypoint decide the path to take instead. Signed-off-by: Ben Skeggs <[email protected]>
2014-01-23drm/cirrus: correct register values for 16bppTakashi Iwai1-2/+2
When the mode is set with 16bpp on QEMU, the output gets totally broken. The culprit is the bogus register values set for 16bpp, which was likely copied from from a wrong place. Addresses https://bugzilla.novell.com/show_bug.cgi?id=799216 Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Cc: David Airlie <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2014-01-23drm/nouveau: make vga_switcheroo code depend on VGA_SWITCHEROOJeff Mahoney1-0/+6
Commit 8116188fdef594 ("nouveau/acpi: hook up to the MXM method for mux switching.") broke the build on non-x86 architectures due to the new dependency on MXM and MXM being an x86 platform driver. It built previously since the vga switcheroo registration routines were zereod out on !X86. The code was built in but unused. This patch makes all of the DSM code depend on CONFIG_VGA_SWITCHEROO, allowing it to build on non-x86 and shrinking the module size as well. [[email protected]: fix build eror when VGA_SWITCHEROO is not enabled] Signed-off-by: Jeff Mahoney <[email protected]> Signed-off-by: Jiri Slaby <[email protected]> Cc: David Airlie <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2014-01-23drm/mgag200: on cards with < 2MB VRAM default to 16-bitDave Airlie2-2/+10
This aligns with what the userspace -mga driver does in the same situation. Signed-off-by: Dave Airlie <[email protected]>
2014-01-22drm/i915: Allow reading the TIMESTAMP register on Gen8.Kenneth Graunke1-1/+1
Nothing's changed here; we just need to bump the generation check. Signed-off-by: Kenneth Graunke <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915: Repeat evictions whilst pageflip completions are outstandingChris Wilson1-7/+20
Since an old pageflip will keep its scanout buffer object pinned until it has executed its unpin task on the common workqueue, we can clog up our GGTT with stale pinned objects. As we cannot flush those workqueues without dropping our locks, we have to resort to falling back to userspace and telling them to repeat the operation in order to have a chance to run our workqueues and free up the required memory. If we fail, then we are forced to report ENOSPC back to userspace causing the operation to fail and best-case scenario is that it introduces temporary corruption. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915: Wait for completion of pending flips when starved of fencesChris Wilson3-4/+34
On older generations (gen2, gen3) the GPU requires fences for many operations, such as blits. The display hardware also requires fences for scanouts and this leads to a situation where an arbitrary number of fences may be pinned by old scanouts following a pageflip but before we have executed the unpin workqueue. This is unpredictable by userspace and leads to random EDEADLK when submitting an otherwise benign execbuffer. However, we can detect when we have an outstanding flip and so cause userspace to wait upon their completion before finally declaring that the system is starved of fences. This is really no worse than forcing the GPU to stall waiting for older execbuffer to retire and release their fences before we can reallocate them for the next execbuffer. v2: move the test for a pending fb unpin to a common routine for later reuse during eviction Reported-and-tested-by: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Jon Bloomfield <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915: don't disable DP port after a failed link trainingImre Deak1-1/+0
Atm after a failed link training we disable the DP port. This can happen during a modeset-enable or a DP link re-establishment. The latter can be a problem and we shouldn't disable the DP port, see the previous patch for the reasoning. In the former case the right thing would be to disable the DP port, but also the rest of the pipe. As a stop-gap solution leave the DP port enabled in both cases. It is an improvement on its own (avoiding HW lock ups) and the proper solution for the first case requires a bigger change, so let's keep that on the TODO list. v2: - fix explanation of change impact (Chris) Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915: don't disable the DP port if the link is lostImre Deak1-2/+0
Currently if the DP link is lost (either because of a hot unplug, or failed link status check) we disable the DP port, but leave the rest of the pipe running. This is incompatible with the modeset disabling sequence of some platforms/configurations. At least this is the case for DP ports on the CPU as opposed to PCH. Atm we'll also get a warning when we do a modeset disable after the above link lost event, since we expect the DP port to be enabled at this point (see the bugzilla ticket for the related dmesg). Note that with this patch we'll still end up disabling the port, thanks to the HPD uevent and subsequent modeset disable. See also the next patch fixing the other half of this issue. Solution suggested by Ville. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570 Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915: Eliminate lots of WARNs when there's no backlight presentVille Syrjälä2-11/+5
My 855gm doesn't register the intel backlight but it still ends up calling the backlight code to enable/disable the backlight via the LVDS code. This leads to some WARNs due to backlight.max being 0. Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight() check whether there's a backlight present or not. Also move the backlight.present check from asle_set_backlight() into intel_panel_set_backlight() for some extra symmetry. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915: g4x/vlv: fix dp aux interrupt maskImre Deak1-1/+2
Fix typo possibly leading to timed out DP aux transactions on ports C,D. Introduced in: Commmit 4aeebd7443e36b0a40032e518a9338f48bd27efc Author: Daniel Vetter <[email protected]> Date: Thu Oct 31 09:53:36 2013 +0100 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72210 Signed off-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22drm/i915/ppgtt: Defer request freeing on resetBen Widawsky1-10/+17
We need to defer the free request until the object/vma is capable of being freed - or else we have a problem when we try to destroy the context. The exact same issue is described and fixed here: commit e20780439b26ba95aeb29d3e27cd8cc32bc82a4c Author: Ben Widawsky <[email protected]> Date: Fri Dec 6 14:11:22 2013 -0800 drm/i915: Defer request freeing I had this fix previously, but decided not to keep it for some reason I can no longer remember. gem_reset_stats is a really good test at hitting the problem. For the inquisitive: [ 170.516392] ------------[ cut here ]------------ [ 170.517227] WARNING: CPU: 1 PID: 105 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]() [ 170.518064] Memory manager not clean during takedown. [ 170.518941] CPU: 1 PID: 105 Comm: kworker/1:1 Not tainted 3.13.0-rc4-BEN+ #28 [ 170.519787] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012 [ 170.520662] Call Trace: [ 170.521517] [<ffffffff814f0589>] dump_stack+0x4e/0x7a [ 170.522373] [<ffffffff81049e6d>] warn_slowpath_common+0x7d/0xa0 [ 170.523227] [<ffffffff81049edc>] warn_slowpath_fmt+0x4c/0x50 [ 170.524079] [<ffffffffa06c414e>] drm_mm_takedown+0x2e/0x30 [drm] [ 170.524934] [<ffffffffa07213f3>] gen6_ppgtt_cleanup+0x23/0x110 [i915] [ 170.525777] [<ffffffffa07837ed>] ppgtt_release.part.5+0x24/0x29 [i915] [ 170.526603] [<ffffffffa071aaa5>] i915_gem_context_free+0x195/0x1a0 [i915] [ 170.527423] [<ffffffffa071189d>] i915_gem_free_request+0x9d/0xb0 [i915] [ 170.528247] [<ffffffffa0718af9>] i915_gem_reset+0x1f9/0x3f0 [i915] [ 170.529065] [<ffffffffa0700cce>] i915_reset+0x4e/0x180 [i915] [ 170.529870] [<ffffffffa070829d>] i915_error_work_func+0xcd/0x120 [i915] [ 170.530666] [<ffffffff8106c13a>] process_one_work+0x1fa/0x6d0 [ 170.531453] [<ffffffff8106c0d8>] ? process_one_work+0x198/0x6d0 [ 170.532230] [<ffffffff8106c72b>] worker_thread+0x11b/0x3a0 [ 170.532996] [<ffffffff8106c610>] ? process_one_work+0x6d0/0x6d0 [ 170.533771] [<ffffffff810743ef>] kthread+0xff/0x120 [ 170.534548] [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80 [ 170.535322] [<ffffffff814f97ac>] ret_from_fork+0x7c/0xb0 [ 170.536089] [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80 [ 170.536847] ---[ end trace 3d4c12892e42d58f ]--- v2: Whitespace fix. (Chris) Note: This is a bug that only hits the ppgtt topic branch but I've figured that doing the request cleanup in this order is generally the right thing to do. Signed-off-by: Ben Widawsky <[email protected]> [danvet: Add a code comment to clarify what's actually going on since the lifetime rules aroung ppgtt cleanup are ... fuzzy a best atm. Also add a note about why we need this.] Signed-off-by: Daniel Vetter <[email protected]>
2014-01-22i915: send D1 opregion notificationKristen Carlson Accardi1-1/+9
The opregion notification for runtime suspend is currently D1, not D3. Signed-off-by: Kristen Carlson Accardi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.