aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_dp.c (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2014-12-03drm/i915: Handle runtime pm in the CRC setup codeDaniel Vetter1-0/+5
The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in obscure unclaimed register write failures. Which is a pain to debug. So instead make sure we don't have the basic unclaimed register write failure by grabbing runtime pm references. And reject completely invalid requests with -EIO. This is still racy of course, but for a test library we don't really care - if userspace shuts down the pipe right afterwards the entire setup will be lost anyway. v2: Put instead of get, spotted by Damien. Also explain the runtime pm dance. v3: There's really no need for rpm get/put since power_is_enabled only checks software state (Damien). References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 Cc: Damien Lespiau <damien.lespiau@intel.com> (v2) Tested-by: lu hua <huax.lu@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-03drm/i915: Disable crtcs gracefully before GPU reset on gen3/4Ville Syrjälä2-2/+12
The GPU reset also resets the display on gen3/4. The g33 docs say we should disable all planes before flipping the reset switch. Just disable all the crtcs instead. That seems a nicer thing to do anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Grab modeset locks for GPU rest on pre-ctgVille Syrjälä4-37/+74
On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip coming in between these two steps should fail anyway due to reset_in_progress, so this should be safe. This fixes a lot of failed asserts in the modeset code when there's a modeset racing with the reset. Naturally the asserts aren't happy when the expected state has disappeared. v2: Drop UMS checks, complete pending flips after the reset (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Implement GPU reset for g33Ville Syrjälä2-3/+13
g33 seems to sit somewhere between the 915/945/965 style and the g4x style. The bits look like g4x, but we still need to do a full reset including display. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Implement GPU reset for 915/945Ville Syrjälä3-14/+15
915/945 have the same reset registers as 965, so share the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Restore the display config after a GPU reset on gen4Ville Syrjälä1-0/+18
On pre-ctg GPU reset also resets the display hardware. Force a mode restore after the GPU reset, and also re-init clock gating. v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating() in case more relevant stuff gets added there at some point Restore interrupts after the reset as well Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Fix gen4 GPU resetVille Syrjälä2-27/+15
On pre-ctg the reset bit directly controls the reset signal. We must assert it for >=20usec and then deassert it. Bit 1 is a RO status bit which should also go down when the reset is no longer asserted. Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Stop gathering error states for CS error interruptsDaniel Vetter1-18/+7
There's quite a few bug reports with error states where the error reasons makes just about no sense at all. Like dying on tlbs for a display plane that's not even there. Also users don't really report a lot of bad side effects generally, just the error states. Furthermore we don't even enable these interrupts any more on gen5+ (though the handling code is still there). So this mostly concerns old platforms. Given all that lets make our lives a bit easier and stop capturing error states, in the hopes that we can just ignore them. In case that's not true and the gpu indeed dies the hangcheck should eventually kick in. And I've left some debug log in to make this case noticeble. Referenced bug is just an example. v2: Fix missing \n Jani spotted. References: https://bugs.freedesktop.org/show_bug.cgi?id=82095 References: https://bugs.freedesktop.org/show_bug.cgi?id=85944 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Disallow pin ioctl completely for kms driversDaniel Vetter1-1/+4
The problem here is that SNA pins batchbuffers to etch out a bit more performance. Iirc it started out as a w/a for i830M (which we've implemented in the kernel since a long time already). The problem is that the pin ioctl wasn't added in commit d23db88c3ab233daed18709e3a24d6c95344117f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 23 08:48:08 2014 +0200 drm/i915: Prevent negative relocation deltas from wrapping Fix this by simply disallowing pinning from userspace so that the kernel is in full control of batch placement again. Especially since distros are moving towards running X as non-root, so most users won't even be able to see any benefits. UMS support is dead now, but we need this minimal patch for backporting. Follow-up patch will remove the pin ioctl code completely. Note to backporters: You must have both commit b45305fce5bb1abec263fcff9d81ebecd6306ede Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 which laned in 3.8 and commit c4d69da167fa967749aeb70bc0e94a457e5d00c1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Sep 8 14:25:41 2014 +0100 drm/i915: Evict CS TLBs between batches which is also marked cc: stable. Otherwise this could introduce a regression by disabling the userspace w/a without the kernel w/a being fully functional on i830/45. References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116 Cc: stable@vger.kernel.org # requires c4d69da167fa967749a and v3.8 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-03drm/i915: Only warn the first time we attempt to mmio whilst suspendedChris Wilson1-2/+2
In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915/chv: Enable AVI, SPD and HDMI infoframes for CHV.Clint Taylor1-0/+7
CHV infoframes were not being enabled. Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Don't clobber crtc->new_config when nothing changesVille Syrjälä1-3/+5
When doing a nop modeset we currently leave crtc->new_config point at the already freed temporary pipe_config. That will anger the sanity checks in intel_modeset_update_state() when the nop modeset gets followed by a GPU reset on gen3/4 where the display block gets fully reinitialized during the reset. So leave crtc->new_config alone until we know a modeset is actually required. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-02cxgb4: Fill in supported link mode for SFP modulesHariprasad Shenai1-2/+6
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-02xen-netfront: Remove BUGs on paged skb data which crosses a page boundarySeth Forshee1-5/+0
These BUGs can be erroneously triggered by frags which refer to tail pages within a compound page. The data in these pages may overrun the hardware page while still being contained within the compound page, but since compound_order() evaluates to 0 for tail pages the assertion fails. The code already iterates through subsequent pages correctly in this scenario, so the BUGs are unnecessary and can be removed. Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit") Cc: <stable@vger.kernel.org> # 3.7+ Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-12-02mm/vmpressure.c: fix race in vmpressure_work_fn()Andrew Morton1-3/+5
In some android devices, there will be a "divide by zero" exception. vmpr->scanned could be zero before spin_lock(&vmpr->sr_lock). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=88051 [akpm@linux-foundation.org: neaten] Reported-by: ji_ang <ji_ang@163.com> Cc: Anton Vorontsov <anton.vorontsov@linaro.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-02mm: frontswap: invalidate expired data on a dup-store failureWeijie Yang1-1/+3
If a frontswap dup-store failed, it should invalidate the expired page in the backend, or it could trigger some data corruption issue. Such as: 1. use zswap as the frontswap backend with writeback feature 2. store a swap page(version_1) to entry A, success 3. dup-store a newer page(version_2) to the same entry A, fail 4. use __swap_writepage() write version_2 page to swapfile, success 5. zswap do shrink, writeback version_1 page to swapfile 6. version_2 page is overwrited by version_1, data corrupt. This patch fixes this issue by invalidating expired data immediately when meet a dup-store failure. Signed-off-by: Weijie Yang <weijie.yang@samsung.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Seth Jennings <sjennings@variantweb.net> Cc: Dan Streetman <ddstreet@ieee.org> Cc: Minchan Kim <minchan@kernel.org> Cc: Bob Liu <bob.liu@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-02mm: do not overwrite reserved pages counter at show_mem()Rafael Aquini1-1/+1
Minor fixlet to perform the reserved pages counter aggregation for each node, at show_mem() Signed-off-by: Rafael Aquini <aquini@redhat.com> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Johannes Weiner <jweiner@redhat.com> Acked-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03drm: rcar-du: Fix NULL encoder pointer dereferenceLaurent Pinchart1-3/+6
The DRM connector's encoder pointer is managed internally by the DRM core and set to NULL when the DRM connector is disconnected from the CRTC it was attached to. This results in a NULL pointer dereference in the HDMI connector functions when trying to call the associated slave encoder's operations. Fix this by retrieving the slave encoder pointer from the R-Car connector structure instead of the DRM connector structure. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-02drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6Petr Mladek1-0/+2
I was unable too boot 3.18.0-rc6 because of the following kernel panic in drm_calc_vbltimestamp_from_scanoutpos(): [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). [drm] register mmio base: 0xC8400000 [drm] register mmio size: 65536 radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 16bits DDR [TTM] Zone kernel: Available graphics memory: 3829346 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 16M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] PCI GART of 512M enabled (table at 0x0000000037880000). radeon 0000:0b:01.0: WB disabled radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. [drm] radeon: irq initialized. [drm] Loading R100 Microcode radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2 radeon_cp: Failed to load firmware "radeon/R100_cp.bin" [drm:r100_cp_init] *ERROR* Failed to load firmware! radeon 0000:0b:01.0: failed initializing CP (-2). radeon 0000:0b:01.0: Disabling GPU acceleration [drm] radeon: cp finalized BUG: unable to handle kernel NULL pointer dereference at 000000000000025c IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 PGD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649 Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006 task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000 RIP: 0010:[<ffffffff8150423b>] [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP: 0000:ffff880234da7918 EFLAGS: 00010086 RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48 RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000 RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0 R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000 FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0 Stack: ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480 ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58 Call Trace: [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110 [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60 [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180 [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70 [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0 [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70 [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0 [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70 [<ffffffff8156c07e>] r100_init+0x26e/0x410 [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50 [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210 [<ffffffff81506965>] drm_dev_register+0xb5/0x110 [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200 [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0 [<ffffffff8141a365>] local_pci_probe+0x45/0xa0 [<ffffffff8141b741>] pci_device_probe+0xd1/0x130 [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0 [<ffffffff8163413b>] __driver_attach+0x9b/0xa0 [<ffffffff816340a0>] ? __device_attach+0x40/0x40 [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0 [<ffffffff8163378e>] driver_attach+0x1e/0x20 [<ffffffff81633390>] bus_add_driver+0x180/0x240 [<ffffffff81634914>] driver_register+0x64/0xf0 [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50 [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120 [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a [<ffffffff821dc908>] radeon_init+0x97/0xb5 [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0 [<ffffffff810e3278>] ? __wake_up+0x48/0x60 [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215 [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0 [<ffffffff818a78f0>] ? rest_init+0x80/0x80 [<ffffffff818a78fe>] kernel_init+0xe/0xf0 [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0 [<ffffffff818a78f0>] ? rest_init+0x80/0x80 Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60 RIP [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 RSP <ffff880234da7918> CR2: 000000000000025c ---[ end trace ad2c0aadf48e2032 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 It has helped me to add a NULL pointer check that was suggested at http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html I am not familiar with the code. But the change looks sane and we need something fast at this stage of 3.18 development. Suggested-by: Helge Deller <deller@gmx.de> Signed-off-by: Petr Mladek <pmladek@suse.cz> Tested-by: Petr Mladek <pmladek@suse.cz> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-12-02drm/radeon: Ignore RADEON_GEM_GTT_WC on 32-bit x86Michel Dänzer1-0/+7
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84627 Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-12-02drm/radeon: sync all BOs involved in a CS v2Christian König1-10/+7
Not just the userspace relocs, otherwise we won't wait for a swapped out page tables to be swapped in again. v2: rebased on Alex current drm-fixes-3.18 Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-02sata_fsl: fix error handling of irq_of_parse_and_mapDmitry Torokhov1-1/+1
irq_of_parse_and_map() returns 0 on error (the result is unsigned int), so testing for negative result never works. Signed-off-by: Dmitry Torokhov <dtor@chromium.org> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
2014-12-02AHCI: Add DeviceIDs for Sunrise Point-LP SATA controllerDevin Ryles1-0/+3
This patch adds DeviceIDs for Sunrise Point-LP. Signed-off-by: Devin Ryles <devin.ryles@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org
2014-12-02block: fix regression where bio_integrity_process uses wrong bio_vec iteratorDarrick J. Wong1-6/+7
bio integrity handling is broken on a system with LVM layered atop a DIF/DIX SCSI drive because device mapper clones the bio, modifies the clone, and sends the clone to the lower layers for processing. However, the clone bio has bi_vcnt == 0, which means that when the sd driver calls bio_integrity_process to attach DIX data, the for_each_segment_all() call (which uses bi_vcnt) returns immediately and random garbage is sent to the disk on a disk write. The disk of course returns an error. Therefore, teach bio_integrity_process() to use bio_for_each_segment() to iterate the bio_vecs, since the per-bio iterator tracks which bio_vecs are associated with that particular bio. The integrity handling code is effectively part of the "driver" (it's not the bio owner), so it must use the correct iterator function. v2: Fix a compiler warning about abandoned local variables. This patch supersedes "block: bio_integrity_process uses wrong bio_vec iterator". Patch applies against 3.18-rc6. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Jens Axboe <axboe@fb.com>
2014-12-02drm/i915: Don't pin LRC in GGTT when dumping in debugfsThomas Daniel1-31/+47
LRC object does not need to be mapped into the GGTT when dumping. A side-effect of this patch is that a compiler warning goes away (not checking return value of i915_gem_obj_ggtt_pin). v2: Broke out individual context dumping into a new function as the indentation was getting a bit crazy. Added notification of contexts with no gem object for debugging purposes. Removed unnecessary pin_pages and unpin_pages, replaced with explicit get_pages for the context object as there may be no backing store allocated at this time (Comment for get_pages says "Ensure that the associated pages are gathered from the backing storage and pinned into our object"). Improved error checking - get_pages and get_page are checked for failure. Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> [danvet: Align paramter continuation lines properly. Also add some braces to the nested loops again for readability.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-02drm/i915: Unlock panel even when LVDS is disabledDaniel Vetter1-11/+11
Otherwise we'll have backtraces in assert_panel_unlocked because the BIOS locks the register. In the reporter's case this regression was introduced in commit c31407a3672aaebb4acddf90944a114fa5c8af7b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 18 21:07:01 2012 +0100 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H Reported-by: Alexey Orishko <alexey.orishko@gmail.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Francois Tigeot <ftigeot@wolfpond.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>