summaryrefslogtreecommitdiffstats
path: root/drivers/dio (unfollow)
Commit message (Collapse)AuthorFilesLines
2019-11-19drm/i915: Wait until the intel_wakeref idle callback is completeChris Wilson2-2/+26
When waiting for idle, serialise with any ongoing callback so that it will have completed before completing the wait. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-12-chris@chris-wilson.co.uk
2019-11-19drm/i915/gem: Manually dump the debug trace on GEM_BUG_ONChris Wilson1-0/+3
Since igt now defaults to not enabling ftrace-on-oops, we need to manually invoke GEM_TRACE_DUMP() to see the debug log prior to a GEM_BUG_ON panicking. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-1-chris@chris-wilson.co.uk
2019-11-19drm/i915/gt: Flush the requests after wedging on suspendChris Wilson1-0/+1
Retire all requests if we resort to wedged the driver on suspend. They will now be idle, so we might as we free them before shutting down. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-16-chris@chris-wilson.co.uk
2019-11-19drm/i915/gt: Schedule next retirement worker firstChris Wilson1-1/+1
As we may park the gt during request retirement, we may cancel the retirement worker only to then program the delayed worker once more. If we schedule the next delayed retirement worker first, if we then park the gt, the work will remain cancelled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-2-chris@chris-wilson.co.uk
2019-11-19drm/i915/gt: Move new timelines to the end of active_listChris Wilson1-1/+1
When adding a new active timeline, place it at the end of the list. This allows for intel_gt_retire_requests() to pick up the newcomer more quickly and hopefully complete the retirement sooner. A miniscule optimisation. References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119162559.3313003-1-chris@chris-wilson.co.uk
2019-11-19drm/i915: make pool objects read-onlyMatthew Auld1-0/+2
For our current users we don't expect pool objects to be writable from the gpu. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191119150154.18249-1-matthew.auld@intel.com
2019-11-19drm/i915/tgl: Add DKL PHY vswing table for HDMIMatt Roper1-5/+24
The bspec initially provided a single DKL PHY vswing table for both HDMI and DP, but was recently updated to include an independent table for HDMI. Bspec: 49292 Fixes: 978c3e539be2 ("drm/i915/tgl: Add dkl phy programming sequences") Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118180219.9309-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2019-11-19drm/i915/dsi: Do not read the transcoder register.Vandita Kulkarni1-6/+11
As per the Bspec, port mapping is fixed for mipi dsi. v2: Reuse the existing function (Jani) Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119072004.4093-1-vandita.kulkarni@intel.com
2019-11-19drm/i915/gem: Protect the obj->vma.list during iterationChris Wilson1-0/+2
Take the obj->vma.lock to prevent modifications to the list as we iterate, to avoid the dreaded NULL pointer. <1>[ 347.820823] BUG: kernel NULL pointer dereference, address: 0000000000000150 <1>[ 347.820856] #PF: supervisor read access in kernel mode <1>[ 347.820874] #PF: error_code(0x0000) - not-present page <6>[ 347.820892] PGD 0 P4D 0 <4>[ 347.820908] Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 347.820926] CPU: 3 PID: 1303 Comm: gem_persistent_ Tainted: G U 5.4.0-rc7-CI-CI_DRM_7352+ #1 <4>[ 347.820956] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018 <4>[ 347.821132] RIP: 0010:i915_gem_object_flush_write_domain+0xd9/0x1d0 [i915] <4>[ 347.821157] Code: 0f 84 e9 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 75 11 e9 ed 00 00 00 48 8b 80 e0 fd ff ff f6 c4 40 74 26 48 8b 83 b0 00 00 00 <48> 8b b8 50 01 00 00 e8 fb 20 fb ff 48 8b 83 30 03 00 00 49 39 c4 <4>[ 347.821210] RSP: 0018:ffffc90000a1f8f8 EFLAGS: 00010202 <4>[ 347.821229] RAX: 0000000000000000 RBX: ffffc900008479a0 RCX: 0000000000000018 <4>[ 347.821252] RDX: 0000000000000000 RSI: 000000000000000d RDI: ffff888275a090b0 <4>[ 347.821274] RBP: ffff8882673c8040 R08: ffff88825991b8d0 R09: 0000000000000000 <4>[ 347.821297] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8882673c8280 <4>[ 347.821319] R13: ffff8882673c8368 R14: 0000000000000000 R15: ffff888266a54000 <4>[ 347.821343] FS: 00007f75865f4240(0000) GS:ffff888277b80000(0000) knlGS:0000000000000000 <4>[ 347.821368] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 347.821389] CR2: 0000000000000150 CR3: 000000025aee0000 CR4: 00000000003406e0 <4>[ 347.821411] Call Trace: <4>[ 347.821555] i915_gem_object_prepare_read+0xea/0x2a0 [i915] <4>[ 347.821706] intel_engine_cmd_parser+0x5ce/0xe90 [i915] <4>[ 347.821834] ? __i915_sw_fence_complete+0x1a0/0x250 [i915] <4>[ 347.821990] i915_gem_do_execbuffer+0xb4c/0x2550 [i915] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-8-chris@chris-wilson.co.uk
2019-11-19drm/i915/gem: Merge GGTT vma flush into a single loopChris Wilson1-9/+3
We only need the one loop to find the dirty vma flush them and their chipset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119100929.2628356-6-chris@chris-wilson.co.uk
2019-11-19drm/i915/gem: Track ggtt writes from userspace on the bound vmaChris Wilson1-0/+8
When userspace writes into the GTT itself, it is supposed to call set-domain to let the kernel keep track and so manage the CPU/GPU caches. As we track writes on the individual i915_vma, we should also be sure to mark them as dirty. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191119112515.2766748-1-chris@chris-wilson.co.uk
2019-11-19drm/i915/gt: Make intel_ring_unpin() safe for concurrent pintChris Wilson1-9/+4
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active") allowed the intel_ring unpinning to be run concurrently with the next context pinning it. Thus each step in intel_ring_unpin() needed to be atomic and ordered in a nice onion with intel_ring_pin() so that the lifetimes overlapped and were always safe. Sadly, a few steps in intel_ring_unpin() were overlooked, such as closing the read/write pointers of the ring and discarding the intel_ring.vaddr, as these steps were not serialised with intel_ring_pin() and so could leave the ring in disarray. Fixes: 09c5ab384f6f ("drm/i915: Keep rings pinned while the context is active") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118230254.2615942-6-chris@chris-wilson.co.uk
2019-11-19drm/i915/gt: Only wait for register chipset flush if activeChris Wilson1-1/+1
Only serialise with the chipset using an mmio if the chipset is currently active. We expect that any writes into the chipset range will simply be forgotten until it wakes up. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118184943.2593048-8-chris@chris-wilson.co.uk
2019-11-19drm/i915/ehl: Update voltage level checksMatt Roper1-1/+3
The bspec was recently updated with new cdclk -> voltage level tables to accommodate the new 324/326.4 cdclk values. Bspec: 21809 Fixes: 63c9dae71dc5 ("drm/i915/ehl: Add voltage level requirement table") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118164412.26216-1-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
2019-11-18drm/i915/dsb: fix extra warning on error path handlingLucas De Marchi1-7/+14
When we call intel_dsb_get(), the dsb initialization may fail for various reasons. We already log the error message in that path, making it unnecessary to trigger a warning that refcount == 0 when calling intel_dsb_put(). So here we simplify the logic and do lazy shutdown: leaving the extra refcount alive so when we call intel_dsb_put() we end up calling i915_vma_unpin_and_release(). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-3-lucas.demarchi@intel.com
2019-11-18drm/i915/dsb: remove atomic operationsLucas De Marchi2-6/+6
The current dsb API is not really prepared to handle multithread access. I was debugging an issue that ended up fixed by commit a096883dda2c ("drm/i915/dsb: Remove PIN_MAPPABLE from the DSB object VMA") and was puzzled how these atomic operations were guaranteeing atomicity. if (atomic_add_return(1, &dsb->refcount) != 1) return dsb; Thread A could still be initializing dsb struct (and even fail in the middle) while thread B would take a reference and use it (even derefencing a NULL cmd_buf). I don't think the atomic operations here will help much if this were to support multithreaded scenario in future, so just remove them to avoid confusion. v2: Use refcount++ != 0 instead of ++refcount != 1 (from Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111205024.22853-2-lucas.demarchi@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20191116011539.18230-1-lucas.demarchi@intel.com
2019-11-18drm/i915/mst: Check uapi enable not intel one during mst atomic checkJosé Roberto de Souza1-1/+1
When the connector has VCPI allocated and is being moved to another pipe it causes drm_dp_atomic_release_vcpi_slots() and drm_dp_atomic_find_vcpi_slots() to be called in the same atomic check causing the error bellow. This happens because at this point Intel's hw.enable(and all other flags in the same struct) is not set but checking to on the uapi one it have the expected value. [ 580.804430] ------------[ cut here ]------------ [ 580.804436] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180 [ 580.804439] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers] [ 580.804462] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G W 5.4.0-rc7-zeh+ #1226 [ 580.804465] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.1909250226 09/25/2019 [ 580.804470] Workqueue: events output_poll_execute [ 580.804476] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180 [ 580.804481] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02 [ 580.804484] RSP: 0018:ffffc900009b7ab8 EFLAGS: 00010246 [ 580.804488] RAX: ffff88848c04ef50 RBX: ffff88848c04ef40 RCX: 0000000000000214 [ 580.804492] RDX: ffff88848c04f5e0 RSI: ffff888486eb2c68 RDI: ffff88848e518800 [ 580.804495] RBP: ffff88849d339000 R08: 00000000bc4e1092 R09: 0000000000000000 [ 580.804498] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848c04e728 [ 580.804501] R13: 0000000000000214 R14: ffff88848c04e720 R15: ffff888486eb2c68 [ 580.804504] FS: 0000000000000000(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000 [ 580.804507] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 580.804510] CR2: 00007ff6bf1ba680 CR3: 0000000005210003 CR4: 0000000000760ef0 [ 580.804512] PKRU: 55555554 [ 580.804515] Call Trace: [ 580.804574] intel_dp_mst_compute_config+0x193/0x2b0 [i915] [ 580.804636] intel_atomic_check+0x10cc/0x20b0 [i915] [ 580.804644] ? drm_atomic_print_old_state+0xf1/0x130 [ 580.804655] drm_atomic_check_only+0x56a/0x810 [ 580.804663] drm_atomic_commit+0xe/0x50 [ 580.804668] drm_client_modeset_commit_atomic+0x18b/0x220 [ 580.804680] drm_client_modeset_commit_force+0x4d/0x180 [ 580.804685] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 580.804689] drm_fb_helper_set_par+0x27/0x50 [ 580.804692] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0 [ 580.804696] drm_kms_helper_hotplug_event+0x21/0x30 [ 580.804699] output_poll_execute+0x1a4/0x1c0 [ 580.804706] process_one_work+0x25b/0x5b0 [ 580.804713] worker_thread+0x4b/0x3b0 [ 580.804720] kthread+0x100/0x140 [ 580.804723] ? process_one_work+0x5b0/0x5b0 [ 580.804725] ? kthread_park+0x80/0x80 [ 580.804730] ret_from_fork+0x24/0x50 [ 580.804740] irq event stamp: 40988 [ 580.804743] hardirqs last enabled at (40987): [<ffffffff81128567>] console_unlock+0x437/0x590 [ 580.804746] hardirqs last disabled at (40988): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20 [ 580.804749] softirqs last enabled at (40972): [<ffffffff81c00389>] __do_softirq+0x389/0x47f [ 580.804752] softirqs last disabled at (40959): [<ffffffff810b6f19>] irq_exit+0xa9/0xc0 [ 580.804754] ---[ end trace 80052e0c60463c67 ]--- [ 580.804758] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:000000007880692e] in the same state [ 580.811370] [drm:intel_dp_hpd_pulse [i915]] got esi2 02 00 00 [ 580.817239] [drm:intel_dp_hpd_pulse [i915]] got esi 02 00 00 [ 580.817313] ------------[ cut here ]------------ [ 580.817318] WARNING: CPU: 0 PID: 1221 at drivers/gpu/drm/drm_dp_mst_topology.c:4094 drm_dp_atomic_find_vcpi_slots+0x157/0x180 [ 580.817321] Modules linked in: cdc_ether r8152 i915 prime_numbers snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep asix snd_hda_core x86_pkg_temp_thermal [ 580.817412] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on [ENCODER:306:DDI E] - short [ 580.817413] usbnet mei_hdcp coretemp mii mei_me crct10dif_pclmul snd_pcm crc32_pclmul [ 580.817490] [drm:intel_dp_hpd_pulse [i915]] is_mst [ 580.817491] mei ghash_clmulni_intel i2c_i801 [last unloaded: prime_numbers] [ 580.817498] CPU: 0 PID: 1221 Comm: kworker/0:0 Tainted: G W 5.4.0-rc7-zeh+ #1226 [ 580.817503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.D00.2321.A09.1909250226 09/25/2019 [ 580.817506] Workqueue: events output_poll_execute [ 580.817511] RIP: 0010:drm_dp_atomic_find_vcpi_slots+0x157/0x180 [ 580.817514] Code: 6a ff ff ff 49 89 6d 08 4c 89 6b 10 4c 89 63 18 49 89 6e 08 e9 55 ff ff ff 41 89 c7 5b 5d 44 89 f8 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b 48 c7 c7 08 73 11 82 48 89 ee 41 bf ea ff ff ff e8 b2 e3 02 [ 580.817516] RSP: 0018:ffffc900009b7ab8 EFLAGS: 00010246 [ 580.817519] RAX: ffff88848c04ef50 RBX: ffff88848c04ef40 RCX: 000000000000018f [ 580.817521] RDX: ffff88848c04f5e0 RSI: ffff888486eb2c68 RDI: ffff88848e518800 [ 580.817523] RBP: ffff88849d339000 R08: 00000000bc4e1092 R09: 0000000000000000 [ 580.817525] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848c04e728 [ 580.817528] R13: 000000000000018f R14: ffff88848c04e720 R15: ffff888486eb2c68 [ 580.817532] FS: 0000000000000000(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000 [ 580.817534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 580.817535] CR2: 00007ff6bf1ba680 CR3: 0000000005210003 CR4: 0000000000760ef0 [ 580.817537] PKRU: 55555554 [ 580.817538] Call Trace: [ 580.817620] intel_dp_mst_compute_config+0x193/0x2b0 [i915] [ 580.817690] intel_atomic_check+0x10cc/0x20b0 [i915] [ 580.817697] ? drm_atomic_print_old_state+0xf1/0x130 [ 580.817711] drm_atomic_check_only+0x56a/0x810 [ 580.817721] drm_atomic_commit+0xe/0x50 [ 580.817726] drm_client_modeset_commit_atomic+0x18b/0x220 [ 580.817744] drm_client_modeset_commit_force+0x4d/0x180 [ 580.817751] drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0 [ 580.817756] drm_fb_helper_set_par+0x27/0x50 [ 580.817762] drm_fb_helper_hotplug_event.part.0+0xa7/0xc0 [ 580.817767] drm_kms_helper_hotplug_event+0x21/0x30 [ 580.817771] output_poll_execute+0x1a4/0x1c0 [ 580.817780] process_one_work+0x25b/0x5b0 [ 580.817791] worker_thread+0x4b/0x3b0 [ 580.817800] kthread+0x100/0x140 [ 580.817804] ? process_one_work+0x5b0/0x5b0 [ 580.817807] ? kthread_park+0x80/0x80 [ 580.817813] ret_from_fork+0x24/0x50 [ 580.817832] irq event stamp: 41028 [ 580.817838] hardirqs last enabled at (41027): [<ffffffff81128567>] console_unlock+0x437/0x590 [ 580.817841] hardirqs last disabled at (41028): [<ffffffff81001cfa>] trace_hardirqs_off_thunk+0x1a/0x20 [ 580.817846] softirqs last enabled at (41022): [<ffffffff81c00389>] __do_softirq+0x389/0x47f [ 580.817851] softirqs last disabled at (41013): [<ffffffff810b6f19>] irq_exit+0xa9/0xc0 [ 580.817854] ---[ end trace 80052e0c60463c68 ]--- [ 580.817858] [drm:drm_dp_atomic_find_vcpi_slots] *ERROR* cannot allocate and release VCPI on [MST PORT:000000007880692e] in the same state [ 580.830767] [drm:intel_dp_mst_compute_config [i915]] failed finding vcpi slots:-22 [ 580.830821] [drm:intel_atomic_check [i915]] Encoder config failure: -22 Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115200430.53146-1-jose.souza@intel.com
2019-11-18drm/i915/vbt: Handle generic DTD blockMatt Roper2-2/+125
VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the old LFP panel mode data in block 42. Let's start parsing this block to fill in the panel fixed mode on devices with a >=229 VBT. v2: * Update according to the recent updates: - DTD size is now 16 bits instead of 24 - polarity is now just a single bit for hsync and vsync and is properly documented * Minor checkpatch fix v3: * Now that panel options are parsed separately from the previous patch, move generic DTD parsing into a function parallel to parse_lfp_panel_dtd. We'll still fall back to looking at the legacy LVDS timing block if the generic DTD fails. (Jani) * Don't forget to actually set lfp_lvds_vbt_mode! (Jani) * Drop "bdb_" prefix from dtd entry structure. (Jani) * Follow C99 standard for structure's flexible array member. (Jani) v4: * Add "positive" to polarity field names for clarity. (Jani) * Move VBT version check and fallback to legacy DTD parsing logic to a helper to keep top-level VBT parsing uncluttered. (Jani) * Restructure reserved bit packing at end of generic_dtd_entry from "u32 rsvd:24" to "u8 rsvd[3]" to prevent copy/paste mistakes in the future. (Jani) Bspec: 54751 Bspec: 20148 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-3-matthew.d.roper@intel.com
2019-11-18drm/i915/vbt: Parse panel options separately from timing dataMatt Roper1-9/+18
Newer VBT versions will add an alternate way to read panel DTD information, so let's split parsing of the general panel information from the timing data in preparation. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jesse Barnes <jsbarnes@google.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115165132.9472-2-matthew.d.roper@intel.com
2019-11-18drm/i915/selftests: Add intel_gt_driver_late_release for mock deviceChris Wilson1-0/+2
Having called intel_gt_init_early() to setup the mock intel_gt, we need to call the corresponding intel_gt_driver_late_release() to clean up. References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on unload") References: 24635c5152af ("drm/i915: Move intel_gt initialization to a separate file") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191118094342.2193485-1-chris@chris-wilson.co.uk
2019-11-18drm/i915: fix accidental static variable useJani Nikula1-1/+1
It's supposed to be just a const pointer. Fixes: 074c77e3ec63 ("drm/i915/tgl: Gen-12 display loses Yf tiling and legacy CCS support") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115120440.17883-1-jani.nikula@intel.com
2019-11-16drm/i915/guc: Skip suspend/resume GuC action on platforms w/o GuC submissionDon Hiatt2-0/+21
On some platforms (e.g. KBL) that do not support GuC submission, but the user enabled the GuC communication (e.g for HuC authentication) calling the GuC EXIT_S_STATE action results in lose of ability to enter RC6. We can remove the GuC suspend/resume entirely as we do not need to save the GuC submission status. Add intel_guc_submission_is_enabled() function to determine if GuC submission is active. v2: Do not suspend/resume the GuC on platforms that do not support Guc Submission. v3: Fix typo, move suspend logic to remove goto. v4: Use intel_guc_submission_is_enabled() to check GuC submission status. v5: No need to look at engine to determine if submission is enabled. Squash fix + intel_guc_submission_is_enabled() patch into one. v6: Move resume check into intel_guc_resume() for symmetry. Fix commit Fixes tag. Reported-by: KiteStramuort <kitestramuort@autistici.org> Reported-by: S. Zharkoff <s.zharkoff@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111594 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111623 Fixes: ffd5ce22faa4 ("drm/i915/guc: Updates for GuC 32.0.3 firmware") Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceralo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Tomas Janousek <tomi@nomi.cz> Signed-off-by: Don Hiatt <don.hiatt@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191115231538.1249-1-don.hiatt@intel.com
2019-11-15drm/i915/gem: Purge the sudden reappearance of i915_gem_object_pin()Chris Wilson3-46/+36
This died many years ago as we now use i915_vma first and foremost. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115170835.1367869-1-chris@chris-wilson.co.uk
2019-11-15drm/i915/gt: Mention which device failedChris Wilson1-1/+2
When telling the user that device power management is disabled, it is helpful to say which device that was. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115122343.821331-1-chris@chris-wilson.co.uk
2019-11-15drm/i915: Fix frame start delay programmingVille Syrjälä3-19/+95
Currently we're blindly poking at the frame start delay bits in PIPECONF when trying to sanitize the hardware state. Those bits decided to move elsewhere on HSW, so on many platforms we're not doing anything at all here. Also we're forgetting about the PCH transcoder entirely. Add all the bit definitions for the various homes these bits have had throughout the years, and reset them all to zero. However I'm not entirely sure this is a safe thing to do. If not I guess we'd want full readout+statecheck for this stuff. For now let's stick to the current logic and hope for the best. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191024122138.25065-3-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2019-11-15drm/i915/selftests: Disable heartbeat around context barrier testsChris Wilson1-6/+38
As the heartbeat has the effect of flushing context barriers, this interferes with the context barrier tests that are trying to observe them directly. Disable the heartbeat so that the barriers are as predictable as the test demands. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115150841.880349-2-chris@chris-wilson.co.uk
2019-11-15drm/i915/selftests: Exercise long preemption chainsChris Wilson1-0/+196
Verify that we can execute a long chain of dependent requests from userspace, each one slightly more important than the last. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-4-chris@chris-wilson.co.uk
2019-11-15drm/i915/perf: Add preemption check while waiting for OALionel Landwerlin1-0/+2
While we're waiting for the OA configuration to apply, let's give a chance to other contexts that might need to run other workloads. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191114140224.21818-1-lionel.g.landwerlin@intel.com
2019-11-15drm/i915/gt: Flush retire.work timer object on unloadChris Wilson3-0/+8
We need to wait until the timer object is marked as deactivated before unloading, so follow up our gentle cancel_delayed_work() with the synchronous variant to ensure it is flushed off a remote cpu before we mark the memory as freed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111994 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115150841.880349-1-chris@chris-wilson.co.uk
2019-11-15drm/i915/gt: Use gt locals for accessing rc6Chris Wilson1-3/+3
RC6 is tracked underneath the intel_gt, so use our local pointers. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115114800.725061-1-chris@chris-wilson.co.uk
2019-11-15drm/i915: Simplify NEEDS_WaRsDisableCoarsePowerGatingChris Wilson1-1/+1
It applies to all gen9 and gen10 now, so we can use a single test against the gen bitmask. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191115122755.830355-1-chris@chris-wilson.co.uk
2019-11-15drm/i915/gem: Silence sparse for RCU protection inside the constructorChris Wilson1-2/+4
Inside the constructor, while cloning, we need to replace the dst->engines. Having forgotten that dst->engines is marked as RCU protected, we need to add the appropriate annotations to make sparse happy. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-5-chris@chris-wilson.co.uk
2019-11-15drm/i915/gt: Wait for new requests in intel_gt_retire_requests()Chris Wilson1-8/+3
Our callers fall into two categories, those passing timeout=0 who just want to flush request retirements and those passing a timeout that need to wait for submission completion (e.g. intel_gt_wait_for_idle()). Currently, we only wait for a snapshot of timelines at the start of the wait (but there was an expectation that new requests would cause timelines to appear at the end). However, our callers, such as intel_gt_wait_for_idle() before suspend, do require us to wait for the power management requests emitted by retirement as well. If we don't, then it takes an extra second or two for the background worker to flush the queue and mark the GT as idle. Fixes: 7e8057626640 ("drm/i915: Drop struct_mutex from around i915_retire_requests()") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191114225736.616885-1-chris@chris-wilson.co.uk
2019-11-15drm/i915/guc: Properly capture & release GuC interrupts on Gen11+Daniele Ceraolo Spurio2-60/+14
With the new interrupt re-partitioning in Gen11, GuC controls by itself the interrupts it receives, so steering bits and registers have been defeatured. Being this the case, when the GuC is in control of submissions we won't know what to do with the ctx switch interrupt in the driver, so disable it. v2 (Daniele): replace the gen9 paths instead of keeping gen9 and gen11 functions since we won't support guc submission on any pre-gen11 platform. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191105225321.26642-1-daniele.ceraolospurio@intel.com
2019-11-14drm/i915: Restore GT coarse power gating workaroundImre Deak1-2/+7
The workaround to disable coarse power gating is still needed on SKL GT3/GT4 machines and since the RC6 context corruption was discovered by the hardware team also on all GEN9 machines. Restore applying the workaround. Fixes: c113236718e8 ("drm/i915: Extract GT render sleep (rc6) management") Testcase: igt/intel_gt_pm_late_selftests/live_rc6_ctx Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191114152621.7235-1-imre.deak@intel.com
2019-11-14drm/i915: Drop redundant aspec ratio prop value initializationVille Syrjälä2-2/+0
HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d so no need to initialize conn_state->picture_aspect_ratio with it. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-6-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2019-11-14drm/i915: Do not override mode's aspect ratio with the prop value NONEVille Syrjälä2-5/+6
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that selected we should keep whatever aspect ratio the mode already has. Also no point in checking for connector->is_hdmi in the SDVO code since we only attach the property to HDMI connectors. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-5-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2019-11-14drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtreeChris Wilson3-31/+31
As we want to be able to run inside atomic context for retiring the i915_active, and we are no longer allowed to abuse mutex_trylock, split the tree management portion of i915_active.mutex into an irq-safe spinlock. References: a0855d24fc22d ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") References: https://bugs.freedesktop.org/show_bug.cgi?id=111626 Fixes: 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191114172535.1116-1-chris@chris-wilson.co.uk
2019-11-14drm/i915/selftests: Add coverage of mocs registersChris Wilson3-0/+424
Probe the mocs registers for new contexts and across GPU resets. Similar to intel_workarounds, we have tables of what register values we expect to see, so verify that user contexts are affected by them. In the future, we should add tests similar to intel_sseu to cover dynamic reconfigurations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-4-chris@chris-wilson.co.uk
2019-11-14drm/i915/gt: Refactor mocs loops into single control macroChris Wilson2-88/+64
We repeatedly (and more so in future) use the same looping construct over the mocs definition table to setup the register state. Refactor the loop construct into a reusable macro. add/remove: 2/1 grow/shrink: 1/2 up/down: 113/-330 (-217) Function old new delta intel_mocs_init_engine.cold - 71 +71 offset - 28 +28 __func__ 17273 17287 +14 intel_mocs_init 143 113 -30 mocs_register.isra 91 - -91 intel_mocs_init_engine 503 294 -209 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-3-chris@chris-wilson.co.uk
2019-11-14drm/i915/gt: Tidy up debug-warns for the mocs control tableChris Wilson1-19/+11
As we always run new platforms through CI, we only need the debug code compiled in during CI runs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-2-chris@chris-wilson.co.uk
2019-11-14drm/i915/gt: Set unused mocs entry to follow PTE on tgl as on all othersChris Wilson1-1/+1
Be consistent in our mocs setup on Tigerlake and set the unused control value to follow the PTE entry as we previously have done. The unused values are beyond the defines of the ABI, the consistency simplifies our checking. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-1-chris@chris-wilson.co.uk
2019-11-14drm/i915/fbdev: Restore physical addresses for fb_mmap()Chris Wilson1-4/+5
fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by: Neil MacLeod <freedesktop@nmacleod.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a61dd ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: Neil MacLeod <freedesktop@nmacleod.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113180633.3947-1-chris@chris-wilson.co.uk
2019-11-14drm/vmwgfx: remove set but not used variable 'srf'YueHaibing1-2/+0
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:339:22: warning: variable srf set but not used [-Wunused-but-set-variable] 'srf' is never used, so can be removed. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-11-14drm/ttm, drm/vmwgfx: Use a configuration option for the TTM dma page poolThomas Hellstrom5-8/+11
Drivers like vmwgfx may want to test whether the dma page pool is present or not. Since it's activated by default by TTM if compiled-in, define a hidden configuration option that the driver can test for. Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2019-11-14drm/i915/perf: don't forget noa wait after oa configLionel Landwerlin1-2/+7
I'm observing incoherence metric values, changing from run to run. It appears the patches introducing noa wait & reconfiguration from command stream switched places in the series multiple times during the review. This lead to the dependency of one onto the order to go missing... Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191113154639.27144-1-lionel.g.landwerlin@intel.com
2019-11-14drm/i915/gen8+: Add RC6 CTX corruption WAImre Deak7-2/+86
In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: - Rebased on latest upstream gt_pm refactoring. v6: - s/i915_rc6_/intel_rc6_/ - Don't return a value from i915_rc6_ctx_wa_check(). v7: - Rebased on latest gt rc6 refactoring. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> [airlied: pull this later version of this patch into drm-next to make resolving the conflict mess easier.] Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-11-14drm/i915/tgl: Wa_1606679103Radhakrishna Sripada1-0/+8
Extend disabling SAMPLER_STATE prefetch workaround to gen12. v2: Limit the WA to TGL A0 and update the WA no(Chris) BSpec: 52890 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191113231953.24853-1-radhakrishna.sripada@intel.com
2019-11-14drm/i915: Avoid atomic context for error captureBruce Chang1-4/+4
io_mapping_map_atomic/kmap_atomic are occasionally taken in error capture (if there is no aperture preallocated for the use of error capture), but the error capture and compression routines are now run in normal context: <3> [113.316247] BUG: sleeping function called from invalid context at mm/page_alloc.c:4653 <3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: debugfs_test <4> [113.319900] no locks held by debugfs_test/678. <3> [113.321002] Preemption disabled at: <4> [113.321130] [<ffffffffa02506d4>] i915_error_object_create+0x494/0x610 [i915] <4> [113.327259] Call Trace: <4> [113.327871] dump_stack+0x67/0x9b <4> [113.328683] ___might_sleep+0x167/0x250 <4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110 <4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915] <4> [113.335951] compress_page+0x7c/0x100 [i915] <4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915] <4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915] However, it is not a good idea to run the slow compression inside atomic context, so we choose not to. Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot") Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by: Brian Welty <brian.welty@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191113231104.24208-1-yu.bruce.chang@intel.com
2019-11-13drm/i915/tgl: allow DVI/HDMI on port ALucas De Marchi2-2/+2
Tiger Lake supports HDMI on port A. For other platforms we ignore what the VBT says regarding HDMI to workaround broken VBTs, see commit 2ba7d7e04371 ("drm/i915/bios: ignore HDMI on port A"). Make this apply gen12+ so they inherit the TGL behavior. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com