summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2014-11-21drm/radeon: add locking around atombios scratch space usageDave Airlie
commit 1c9498425453bb65ef339a57705c5ef59fe1541d upstream. While developing MST support I noticed I often got the wrong data back from a transaction, in a racy fashion. I noticed the scratch space wasn't locked against concurrent users. Based on a patch by Alex, but I've made it a bit more obvious when things are locked. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/radeon: add missing crtc unlock when setting up the MCAlex Deucher
commit f0d7bfb9407fccb6499ec01c33afe43512a439a2 upstream. Need to unlock the crtc after updating the blanking state. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/radeon: use gart for DMA IB testsAlex Deucher
commit 0b021c5802fbe5addf6f89f5030f684adf04f7b7 upstream. Use gart rather than vram to avoid having to deal with the HDP cache. Port of adfed2b0587289013f8143c54913ddfd44ac1fd3 (drm/radeon: use gart memory for DMA ring tests) to the IB tests. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/radeon: make sure mode init is complete in bandwidth_updateAlex Deucher
commit 8efe82ca908400785253c8f0dfcf301e6bd93488 upstream. The power management code calls into the display code for certain things. If certain power management sysfs attributes are called before the driver has finished initializing all of the hardware we can run into problems with uninitialized modesetting state. Add a check to make sure modesetting init has completed to the bandwidth update callbacks to fix this. Can be triggered by the tlp and laptop start up scripts depending on the timing. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=83611 https://bugs.freedesktop.org/show_bug.cgi?id=85771 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/radeon: set correct CE ram size for CIKJammy Zhou
commit dc4edad6530a9b7b66c3d905e2bc06021a05dcad upstream. CE ram size is 32k/0k/0k for GFX/CS0/CS1 with CIK Ported from amdgpu driver. Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/i915/dp: only use training pattern 3 on platforms that support itJani Nikula
commit 7809a61176b385ebb3299ea43c58b1bb31ffb8c0 upstream. Ivybridge + 30" monitor prints a drm error on every modeset, since IVB doesn't support DP3 we should even bother trying to use it. This regression has been introduced in commit 06ea66b6bb445043dc25a9626254d5c130093199 Author: Todd Previte <tprevite@gmail.com> Date: Mon Jan 20 10:19:39 2014 -0700 drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices Reported-by: Dave Airlie <airlied@redhat.com> Reference: http://mid.gmane.org/1414566170-9868-1-git-send-email-airlied@gmail.com Cc: Todd Previte <tprevite@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/i915: Disable caches for Global GTT.Rodrigo Vivi
commit d6a8b72edc92471283925ceb4ba12799b67c3ff8 upstream. Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000; So the only way to avoid screen corruptions is setting PAT 0 to Uncached. MOCS can still be used though. But if userspace is trusting PTE for cache selection the safest thing to do is to let caches disabled. BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry, so RTL will always use the value corresponding to pat_sel = 000" - System agent ggtt writes (i.e. cpu gtt mmaps) already work before this patch, i.e. the same uncached + snooping access like on gen6/7 seems to be in effect. - So this just fixes blitter/render access. Again it looks like it's not just uncached access, but uncached + snooping. So we can still hold onto all our assumptions wrt cpu clflushing on LLC machines. v2: Cleaner patch as suggested by Chris. v3: Add Daniel's comment Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: James Ausmus <james.ausmus@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: James Ausmus <james.ausmus@intel.com> Reviewed-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-21drm/i915: safeguard against too high minimum brightnessJani Nikula
commit e1c412e75754ab7b7002f3e18a2652d999c40d4b upstream. Never trust (your interpretation of) the VBT. Regression from commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness causing div by zero if VBT minimum brightness equals maximum brightness. Despite my attempts I've failed in my detective work to figure out what the root cause is. This is not the real fix, but we have to do something. Reported-by: Mike Auty <mike.auty@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86551 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: Ignore VBT backlight check on Macbook 2, 1jens stein
commit b2a9601c587dbc5536546aa54009d1130adedd72 upstream. commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT check so backlight is set up properly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438 Signed-off-by: Jens Stein Jørgensen <jens.s.stein@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: Fix GMBUSFREQ on vlv/chvVille Syrjälä
commit 6be1e3d3ea29354d7c834a3936e796e185d5c73b upstream. vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider. This is a regression from: commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Jun 13 13:37:54 2014 +0300 drm/i915: Kill duplicated cdclk readout code from i2c Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: Do a dummy DPCD read before the actual readVille Syrjälä
commit f6a1906674005377b64ee5431c1418077c1b2425 upstream. Sometimes we seem to get utter garbage from DPCD reads. The resulting buffer is filled with the same byte, and the operation completed without errors. My HP ZR24w monitor seems particularly susceptible to this problem once it's gone into a sleep mode. The issue seems to happen only for the first AUX message that wakes the sink up. But as the first AUX read we often do is the DPCD receiver cap it does wreak a bit of havoc with subsequent link training etc. when the receiver cap bw/lane/etc. information is garbage. A sufficient workaround seems to be to perform a single byte dummy read before reading the actual data. I suppose that just wakes up the sink sufficiently and we can just throw away the returned data in case it's crap. DP_DPCD_REV seems like a sufficiently safe location to read here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/radeon: dpm fixes for asrock systemsAlex Deucher
commit 72b3f9183ed57e4a2f0601a1c25ae2fd39855952 upstream. - bapm seems to cause CPU stuck messages so disable it. - nb dpm seems to prevent GPU dpm from getting enabled, so disable it. bug: https://bugs.freedesktop.org/show_bug.cgi?id=85107 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/radeon: Use drm_malloc_ab instead of kmalloc_arrayMichel Dänzer
commit e5a5fd4df21b9c4acb67e815ec949cce594860f8 upstream. Should avoid kmalloc failures due to large number of array entries. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81991 Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/radeon/dpm: disable ulv support on SIAlex Deucher
commit 6fa455935ab956248b165f150ec6ae9106210077 upstream. Causes problems on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=82889 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/vmwgfx: Filter out modes those cannot be supported by the current VRAM size.Sinclair Yeh
commit 9a72384d86b26cb8a2b25106677e1197f606668f upstream. When screen objects are enabled, the bpp is assumed to be 32, otherwise it is set to 16. v2: * Use u32 instead of u64 for assumed_bpp. * Fixed mechanism to check for screen objects * Limit the back buffer size to VRAM. Signed-off-by: Sinclair Yeh <syeh@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/radeon: fix vm page table block size calculationAlex Deucher
commit 8e66e134e20b936179ea1535dd4ed19ec4f99dba upstream. The page offset is 12 bits. For example if we have an 8 GB VM, we'd need 33 bits. The number of bits needed for PD + PT is 21 (33 - 12 or log2(8) + 18), not 20 (log2(8) + 17). Noticed by Alexey during code review. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/radeon: use gart memory for DMA ring testsAlex Deucher
commit adfed2b0587289013f8143c54913ddfd44ac1fd3 upstream. Avoids HDP cache flush issues when using vram which can cause ring test failures on certain boards. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Alexander Fyodorov <halcy@yandex.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/radeon: fix speaker allocation setupAlex Deucher
commit 4910403836ded89803fab201d4b5caaa85de3a89 upstream. If the sad_count is 0, set the hw to stereo and change the error message to a warn. A lot of monitors don't set the speaker allocation block. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: properly reenable gen8 pipe IRQsPaulo Zanoni
commit 1180e20606fd7c5d76dc5b2a1594fa51ba5a0f31 upstream. We were missing the pipe B/C vblank bits! Take a look at gen8_de_irq_postinstall for a comparison. This should fix a bunch of IGT tests. There are a few more things we could improve on this code, but this should be the minimal fix to unblock us. v2: s/extra_iir/extra_ier/ because IIR doesn't make sense (Ville) Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=83640 Testcase: igt/* Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: intel_backlight scale() math WAU. Artie Eoff
commit 673e7bbdb3920b62cfc6c710bea626b0a9b0f43a upstream. Improper truncated integer division in the scale() function causes actual_brightness != brightness. This (partial) work-around should be sufficient for a majority of use-cases, but it is by no means a complete solution. TODO: Determine how best to scale "user" values to "hw" values, and vice-versa, when the ranges are of different sizes. That would be a buggy scenario even with this work-around. The issue was introduced in the following (v3.17-rc1) commit: 6dda730 drm/i915: respect the VBT minimum backlight brightness Note that for easier backporting this commit adds a duplicated macro. A follow-up cleanup patch rectifies this for 3.18+ v2: (thanks to Chris Wilson) clarify commit message, use rounded division macro v3: -DIV_ROUND_CLOSEST() fails to build with CONFIG_X86_32=y. (Jani) -Use DIV_ROUND_CLOSEST_ULL() instead. (Damien) -v1 and v2 originally authored by Joe Konno. Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com> Reviewed-By: Joe Konno <joe.konno@intel.com> [danvet: Add backporting note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/nouveau: fix regression on agp boardsBen Skeggs
commit 67e26e41ff8aa514826dae79f0b10169b5ba93b4 upstream. Extends the fix in f2f9a2cbaf019481feefe231f996d3602612fa99 to also workaround permission issues noticed by people using AGP systems. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14qxl: don't create too large primary surfaceMarc-André Lureau
commit c572aaf46f71f63ae5914d4e194a955e0ba1b519 upstream. Limit primary to qemu vgamem size, to avoid reaching qemu guest bug "requested primary larger than framebuffer" on resizing screen too large to fit. Remove unneeded and misleading variables. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1127552 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/gt214-/kms: fix hda eld regressionBen Skeggs
commit d889c52427d48c05f163f2f39b2cfc12e17e5266 upstream. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/nouveau/bios: memset dcb struct to zero before parsingBen Skeggs
commit 595d373f1e9c9ce0fc946457fdb488e8a58972cd upstream. Fixes type/mask calculation being based on uninitialised data for VGA outputs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/tilcdc: Fix the error path in tilcdc_load()Ezequiel Garcia
commit b478e336b3e75505707a11e78ef8b964ef0a03af upstream. The current error path calls tilcdc_unload() in case of an error to release the resources. However, this is wrong because not all resources have been allocated by the time an error occurs in tilcdc_load(). To fix it, this commit adds proper labels to bail out at the different stages in the load function, and release only the resources actually allocated. Tested-by: Darren Etheridge <detheridge@ti.com> Tested-by: Johannes Pointner <johannes.pointner@br-automation.com> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Dave Airlie <airlied@redhat.com> Fixes: 3a49012224ca ("drm/tilcdc: panel: fix leak when unloading the module") Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: Do not leak pages when freeing userptr objectsTvrtko Ursulin
commit c479f4383ea8940dd6f88da61798ad31feb33e51 upstream. sg_alloc_table_from_pages() can build us a table with coalesced ranges which means we need to iterate over pages and not sg table entries when releasing page references. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Barbalho, Rafael" <rafael.barbalho@intel.com> Tested-by: Rafael Barbalho <rafael.barbalho@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Remove unused local variable sg.] Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/i915: Do not store the error pointer for a failed userptr registrationChris Wilson
commit e9681366ea9e76ab8f75e84351f2f3ca63ee542c upstream. If we fail to create our mmu notification, we report the error back and currently store the error inside the i915_mm_struct. This not only causes subsequent registerations of the same mm to fail (an issue if the first was interrupted by a signal and needed to be restarted) but also causes us to eventually try and free the error pointer. [ 73.419599] BUG: unable to handle kernel NULL pointer dereference at 000000000000004c [ 73.419831] IP: [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130 [ 73.420065] PGD 8650c067 PUD 870bb067 PMD 0 [ 73.420319] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC [ 73.420580] CPU: 0 PID: 42 Comm: kworker/0:1 Tainted: G W 3.17.0-rc6+ #1561 [ 73.420837] Hardware name: Intel Corporation SandyBridge Platform/LosLunas CRB, BIOS ASNBCPT1.86C.0075.P00.1106281639 06/28/2011 [ 73.421405] Workqueue: events __i915_mm_struct_free__worker [ 73.421724] task: ffff880088a81220 ti: ffff880088168000 task.ti: ffff880088168000 [ 73.422051] RIP: 0010:[<ffffffff8114af33>] [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130 [ 73.422410] RSP: 0018:ffff88008816bd50 EFLAGS: 00010286 [ 73.422765] RAX: 0000000000000003 RBX: ffff880086485400 RCX: 0000000000000000 [ 73.423137] RDX: ffff88016d80ee90 RSI: ffff880086485400 RDI: 0000000000000044 [ 73.423513] RBP: ffff88008816bd70 R08: 0000000000000001 R09: 0000000000000000 [ 73.423895] R10: 0000000000000320 R11: 0000000000000001 R12: 0000000000000044 [ 73.424282] R13: ffff880166e5f008 R14: ffff88016d815200 R15: ffff880166e5f040 [ 73.424682] FS: 0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000 [ 73.425099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.425537] CR2: 000000000000004c CR3: 0000000087f5f000 CR4: 00000000000407f0 [ 73.426157] Stack: [ 73.426597] ffff880088a81248 ffff880166e5f038 fffffffffffffffc ffff880166e5f008 [ 73.427096] ffff88008816bd98 ffffffff814a75f2 ffff880166e5f038 ffff8800880f8a28 [ 73.427603] ffff88016d812ac0 ffff88008816be00 ffffffff8106321a ffffffff810631af [ 73.428119] Call Trace: [ 73.428606] [<ffffffff814a75f2>] __i915_mm_struct_free__worker+0x42/0x80 [ 73.429116] [<ffffffff8106321a>] process_one_work+0x1ba/0x610 [ 73.429632] [<ffffffff810631af>] ? process_one_work+0x14f/0x610 [ 73.430153] [<ffffffff810636db>] worker_thread+0x6b/0x4a0 [ 73.430671] [<ffffffff8108d67d>] ? trace_hardirqs_on+0xd/0x10 [ 73.431501] [<ffffffff81063670>] ? process_one_work+0x610/0x610 [ 73.432030] [<ffffffff8106a206>] kthread+0xf6/0x110 [ 73.432561] [<ffffffff8106a110>] ? __kthread_parkme+0x80/0x80 [ 73.433100] [<ffffffff8169c22c>] ret_from_fork+0x7c/0xb0 [ 73.433644] [<ffffffff8106a110>] ? __kthread_parkme+0x80/0x80 [ 73.434194] Code: 0f 1f 84 00 00 00 00 00 66 66 66 66 90 8b 46 4c 85 c0 0f 8e 10 01 00 00 55 48 89 e5 41 55 41 54 53 48 89 f3 49 89 fc 48 83 ec 08 <48> 83 7f 08 00 0f 84 b1 00 00 00 48 c7 c7 40 e6 ac 82 e8 26 65 [ 73.435942] RIP [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130 [ 73.437017] RSP <ffff88008816bd50> [ 73.437704] CR2: 000000000000004c Fixes regression from commit ad46cb533d586fdb256855437af876617c6cf609 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Aug 7 14:20:40 2014 +0100 drm/i915: Prevent recursive deadlock on releasing a busy userptr Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84207 Testcase: igt/gem_render_copy_redux Testcase: igt/gem_userptr_blits/create-destroy-sync Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jacek Danecki <jacek.danecki@intel.com> Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com> Cc: Jacek Danecki <jacek.danecki@intel.com> Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/nouveau/gpio: rename g92 class to g94Emil Velikov
commit b485a7005faba38286bc02ab1d80e2cbf61c1002 upstream. nv92 hardware has only 16 interrupt lines, while nv94 and later has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect PDISP setup. This is a regression introduced with commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3 Author: Ben Skeggs <bskeggs@redhat.com> Date: Mon May 12 15:22:42 2014 +1000 gpio: split g92 class from nv50 Reported-by: estece on #nouveau 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>
2014-11-14drm/ast: Fix HW cursor imageBenjamin Herrenschmidt
commit 1e99cfa8de0f0879091e33cd65fd60418d006ad9 upstream. The translation from the X driver to the KMS one typo'ed a couple of array indices, causing the HW cursor to look weird (blocky with leaking edge colors). This fixes it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-11-14drm/cirrus: bind also to qemu-xen-traditionalOlaf Hering
commit c0c3e735fa7bae29c6623511127fd021b2d6d849 upstream. qemu as used by xend/xm toolstack uses a different subvendor id. Bind the drm driver also to this emulated card. Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-03Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm fixes from Dave Airlie: "Nothing too major or scary. One i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: make sure display hardware is reinitialised on runtime resume drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: fix regression on original nv50 board drm/nv50/disp: fix dpms regression on certain boards drm/i915: Flush the PTEs after updating them before suspend
2014-10-03Merge tag 'drm-intel-fixes-2014-10-02' of ↵Dave Airlie
git://anongit.freedesktop.org/drm-intel into drm-fixes final regression fix for 3.17. * tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: Flush the PTEs after updating them before suspend
2014-10-02drm/nouveau: make sure display hardware is reinitialised on runtime resumeBen Skeggs
Linus commit 05c63c2ff23a80b654d6c088ac3ba21628db0173 modified the runtime suspend/resume paths to skip over display-related tasks to avoid locking issues on resume. Unfortunately, this resulted in the display hardware being left in a partially initialised state, preventing subsequent modesets from completing. This commit unifies the (many) suspend/resume paths, bringing back display (and fbcon) handling in the runtime paths. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02drm/nouveau: punt fbcon resume out to a workqueueBen Skeggs
Preparation for some runtime pm fixes. Currently we skip over fbcon suspend/resume in the runtime path, which causes issues on resume if fbcon tries to write to the framebuffer before the BAR subdev has been resumed to restore the BAR1 VM setup. As we might be woken up via a sysfs connector, we are unable to call fb_set_suspend() in the resume path as it could make its way down to a modeset and cause all sorts of locking hilarity. To solve this, we'll just delay the fbcon resume to a workqueue. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02drm/nouveau: fix regression on original nv50 boardBen Skeggs
Xorg (and any non-DRM client really) doesn't have permission to directly touch VRAM on nv50 and up, which the fence code prior to g84 depends on. It's less invasive to temporarily grant it premission to do so, as it previously did, than it is to rework fencenv50 to use the VM. That will come later on. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-10-02drm/nv50/disp: fix dpms regression on certain boardsBen Skeggs
Reported in fdo#82527 comment #2. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2014-09-30ACPI / i915: Update the condition to ignore firmware backlight change requestAaron Lu
Some of the Thinkpads' firmware will issue a backlight change request through i915 operation region unconditionally on AC plug/unplug, the backlight level used is arbitrary and thus should be ignored. This is handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change). Then there is a Dell laptop whose vendor backlight interface also makes use of operation region to change backlight level and with the above commit, that interface no long works. The condition used to ignore the backlight change request from firmware is thus changed to: if the vendor backlight interface is not in use and the ACPI backlight interface is broken, we ignore the requests; oterwise, we keep processing them. Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854 Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-29drm/i915: Flush the PTEs after updating them before suspendChris Wilson
As we use WC updates of the PTE, we are responsible for notifying the hardware when to flush its TLBs. Do so after we zap all the PTEs before suspend (and the BIOS tries to read our GTT). Fixes a regression from commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend that survived and continue to cause harm even after commit e568af1c626031925465a5caaab7cca1303d55c7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 26 20:08:20 2014 +0100 drm/i915: Undo gtt scratch pte unmapping again v2: Trivial rebase. v3: Fixes requires pointer dances. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82340 Tested-by: ming.yao@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Todd Previte <tprevite@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-25Merge branch 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes - fix a backlight regression resulting in dark screen - add a PX quirk to avoid a hang with runtime pm - fix an init issue on the CIK compute rings - fix IH ring buffer overflows gracefully * 'drm-fixes-3.17' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/cik: use a separate counter for CP init timeout drm/radeon: add PX quirk for asus K53TK drm/radeon: add a backlight quirk for Amilo Xi 2550 drm/radeon: add a module parameter for backlight control (v2) drm/radeon: Update IH_RB_RPTR register after each processed interrupt drm/radeon: Make IH ring overflow debugging output more useful drm/radeon: Clear RB_OVERFLOW bit earlier
2014-09-23drm/radeon/cik: use a separate counter for CP init timeoutAlex Deucher
Otherwise we may fail to init the second compute ring. Noticed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-09-23drm/i915/hdmi: fix hdmi audio state readoutJani Nikula
Check the correct bit for audio. Seems like a copy-paste error from the start: commit 9ed109a7b445e3f073d8ea72f888ec80c0532465 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:52 2014 +0200 drm/i915: Track has_audio in the pipe config Reported-by: Martin Andersen <martin.x.andersen@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756 Cc: stable@vger.kernel.org # 3.16+ Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-23drm/i915: Don't leak command parser tables on suspend/resumeBrad Volkin
Ring init and cleanup are not balanced because we re-init the rings on resume without having cleaned them up on suspend. This leads to the driver leaking the parser's hash tables with a kmemleak signature such as this: unreferenced object 0xffff880405960980 (size 32): comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s) hex dump (first 32 bytes): d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..F............. 98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00 .`(............. backtrace: [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0 [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915] [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915] [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915] [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915] [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915] [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915] [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm] [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm] [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915] [<ffffffff81436725>] local_pci_probe+0x45/0xa0 [<ffffffff81437a69>] pci_device_probe+0xd9/0x130 [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0 [<ffffffff815252d3>] __driver_attach+0x93/0xa0 [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0 This patch extends the current convention of checking whether a resource is already allocated before allocating it during ring init. Longer term it might make sense to only init the rings once. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794 Tested-by: Kari Suvanto <kari.tj.suvanto@gmail.com> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-22drm/radeon: add PX quirk for asus K53TKAlex Deucher
Seems to have problems turning the dGPU on/off. bug: https://bugzilla.kernel.org/show_bug.cgi?id=51381 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-22drm/radeon: add a backlight quirk for Amilo Xi 2550Alex Deucher
Only the acpi backlight seems to work. Using the radeon backlight controller causes the backlight to go off. bug: https://bugs.freedesktop.org/show_bug.cgi?id=81382 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-22drm/radeon: add a module parameter for backlight control (v2)Alex Deucher
Add a module parameter to disable the radeon GPU backlight controller to override the automatic detection. Some laptops seems to indicate that they use the integrated controller, but appear to actually use an external controller. bug: https://bugs.freedesktop.org/show_bug.cgi?id=81382 v2: fix module parameter description Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-22drm/radeon: Update IH_RB_RPTR register after each processed interruptMichel Dänzer
This might decrease the chance of IH ring buffer overflows. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-22drm/radeon: Make IH ring overflow debugging output more usefulMichel Dänzer
Use the same format for all ring indices, and fix the calculation of the post-overflow RPTR. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-22drm/radeon: Clear RB_OVERFLOW bit earlierMichel Dänzer
Otherwise the bit remains set in rdev->ih.rptr, so the wptr can never match that and we still have an infinite loop. This fix allows me to successfully recover from an IH ring buffer overflow. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-09-20Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm fixes from Dave Airlie: "A bunch of radeon fixes for oops on module unload, and problems with resetting the dma engine, one nouveau fix for black boxes in rendering on my mbp retina, one sti fix, and a couple of intel fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: ltc/gf100-: fix cbc issues on certain boards drm/bochs: add missing drm_connector_register call drm/cirrus: add missing drm_connector_register call drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page drm/nouveau/runpm: fix module unload drm/radeon/px: fix module unload vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops drm/radeon: don't reset dma on r6xx-evergreen init drm/radeon: don't reset sdma on CIK init drm/radeon: don't reset dma on NI/SI init drm/radeon/dpm: fix resume on mullins drm/radeon: Disable HDP flush before every CS again for < r600 drm/radeon: delete unused PTE_* defines drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv drm: sti: do not iterate over the info frame array drm/i915: Fix SRC_COPY width on 830/845g
2014-09-20drm/nouveau: ltc/gf100-: fix cbc issues on certain boardsBen Skeggs
A mismatch between FB and LTC's idea of how big a large page is causes issues such as black "holes" in rendering to occur on some boards (those where LTC is configured for 64KiB large pages) when compression is used. Confirmed to fix at least the GK107 MBP. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>