- 19 Sep, 2017 5 commits
-
-
Ville Syrjälä authored
All the values we put into the CNL buf_trans tables fit into 8 bits. So switch over to u8 from the u32 we use currently. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170918182604.9519-4-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
All the values we put into the BXT buf_trans tables fit into 8 bits. So switch over to u8 from the u32 we use currently. Signed-off-by:
-
Ville Syrjälä authored
Some comments in intel_ddi.c are indented with spaces instead of tabs. Fix that up. Signed-off-by:
-
Chris Wilson authored
A fence may be signaled from any context, including from inside a timer. One example is timer_i915_sw_fence_wake() which is used to provide a safety-net when waiting on an external fence. If the external fence is not signaled within a timely fashion, we signal our fence on its behalf, and so we then may process subsequent fences in the chain from within that timer context. Given that dma_i915_sw_fence_wake() may be from inside a timer, we cannot then use del_timer_sync() as that requires the timer lock for itself. To circumvent this, while trying to keep the signal propagation as low latency as possible, move the completion into a worker and use a bit of atomic switheroo to serialise the timer-callback and the dma-callback. Testcase: igt/gem_eio/in-flight-external Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
Chris Wilson authored
archdata.iommu only exists when CONFIG_IOMMU_API is enabled (and only applies to intel-iommu in our case) so conditionally compile it out when it doesn't exist. Fixes: b5891fb5 ("drm/i915/selftests: Disable iommu for the mock device") Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
- 18 Sep, 2017 16 commits
-
-
Rodrigo Vivi authored
Don't touch other bits. My bad. I haven't seen any case where those other bits appeard to be set before we touch it, but it is safe to avoid touching other bits we weren't told to touch. Fixes: 0a46ddd5 ("drm/i915/cnp: Wa 1181: Fix Backlight issue") Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170908234534.17986-1-rodrigo.vivi@intel.com
-
Radhakrishna Sripada authored
Some platforms do not support PSR and DRRS simultaneously. Visual artifacts and flickering were reported on BDW HP Spectre x360 Convertible. Deferring to PSR when both PSR and DRRS are supported by the panel. V2: Minor code-style changes suggested by Rodrigo V3: Add a WARN_ON during PSR init suggested by Dhinakaran Correct debug message,title suggested by Jani Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101111 Cc: Nicholas Stommel <nicholas.stommel@gmail.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Lionel Landwerlin authored
Add the test configuration & timestamp frequency for Coffeelake GT2. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
We're doing this on all Gen9 based platforms, let's just check the gen rather than listing every single platforms. Signed-off-by:
-
Chris Wilson authored
On some machines, the iommu cannot allocate a domain for the mock device causing the dma_map_sg() to fail, and the selftest to fail with -ENOMEM. For the mock selftests, we are using a fake device and do not care about iommu; so convince intel_iommu to treat us as a dummy device with an identity mapping (and no iommu domain). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101080Signed-off-by:
Elizabeth De La Torre Mena <elizabethx.de.la.torre.mena@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com
-
Zhi Wang authored
The cache attribute of the required entry has to be the same with the existing value. After this requirement is met, the futher comparison should be performed. After this fix, the refined test case can pass. v2: - Refine the tittle and comments. (Rodrigo) Fixes: 4395890a ("drm/i915: Introduce private PAT management") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Zhi Wang <zhi.a.wang@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1505741794-10593-1-git-send-email-zhi.a.wang@intel.comSigned-off-by:
-
Lionel Landwerlin authored
Document the expected length of buffers config pointers (tuple of u32 values). Signed-off-by:
-
Michał Winiarski authored
We can just operate on the wq_tail directly (in the process descriptor). This allows us to remove the duplicated tail from the client. While I'm here let's also remove the constants kept in the client and document our locking requirements. This causes a small change in one of GuC debugfs files. We're no longer reporting constant values (which I don't think is a problem), but we're also no longer reporting the tail (does anyone care?). v2: Update tail after wqi contents. (Chris) v3: Really update tail after wqi contents. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
-
Michał Winiarski authored
All we're really doing is incrementing a simple counter in a doorbell_info struct. We can do without extra variables and a separate counter kept in guc_client. Since it's gone, we're also removing its debugfs. The only functional change here, is that we're no longer treating 0 as a special value. GuC doesn't seem to care, why should we? v2: Restore desc->tail update. v3: Drop the retry loop, assert that doorbell cookie doesn't change behind our back. v4: WARN rather than BUG, use xchg. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Suggested-by:
-
Michał Winiarski authored
To create an upper bound on number of GuC workitems, we need to change the way that requests are being submitted. Rather than submitting each request as an individual workitem, we can do coalescing in a similar way we're handlig execlist submission ports. We also need to stop pretending that we're doing "lite-restore" in GuC submission (we would create a workitem each time we hit this condition). This allows us to completely remove the reservation, replacing it with a compile time check. v2: Also coalesce when replaying on reset (Daniele) v3: Consistent wq_resv - per-request (Daniele) v4: Squash removing wq_resv v5: Reflect i915_guc_submit argument changes in doc v6: Rebase on top of execlists reset/restart fix (Chris,Michał) References: https://bugs.freedesktop.org/show_bug.cgi?id=101873 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Michał Winiarski authored
Originally removed in: c1adab97 ("drm/i915/guc: Remove failed doorbell stat from debugfs") f1448a62 ("drm/i915/guc: Remove last submission result from debugfs") Were accidentally restored in: 925344cc ("BackMerge tag 'v4.12-rc5' into drm-next") We can also remove unused variable and replace it with a WARN. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Chris Wilson authored
Given the mechanism to unwind and replay requests (designed to support preemption), we have an alternative to the current method of resubmitting the ELSP upon reset. Resubmitting ELSP turns out to be more complicated than expected, due to having to handle lost context-switch interrupts and so guessing what ELSP we need to resubmit later. Instead, by unwinding the requests and clearing the ELSP tracking entirely, we can then just dequeue the first pair of ready requests after resetting, using the normal submission procedure. Currently, the unwound requests have maximum priority and so are guaranteed to be resubmitted upon resume. If we are lucky, we may be able to coalesce a new request on top! Suggested-by:
-
Chris Wilson authored
In the next patch we will want to reinsert a request not at the end of the priority queue, but at the front. Here we split insert_request() into two, the first function retrieves the priority list (for reuse for unsubmit later) and a wrapper function to insert at the end of that list and to schedule the tasklet if we were first. Signed-off-by:
-
Chris Wilson authored
Move insert_request() earlier to avoid a forward declaration in a later patch. Signed-off-by:
-
Chris Wilson authored
During a reset, we may skip over completed requests and lost context-switch interrupts. Following the reset, we may then may end up with no active requests in the ELSP (and so do not resubmit to restart the engine), but have a queue of requests ready for execution. This is unlikely, it requires the last request to complete after the hang is detected, but not impossible. The outcome of this is that the engine stalls, possibly leading to full ring and indefinite wait under struct_mutex, eventually leading to a full driver hang. Alternatively, we can solve this by unsubmitting the incomplete requests and just kickstarting the tasklet. Michał has patches for that, which I initially disliked due to the extra complexity, but the complexity of this "simple" restart is growing... Signed-off-by:
-
Chris Wilson authored
When wedging the hw, we want to mark all in-flight requests as -EIO. This is made slightly more complex by execlists who store the ready but not yet submitted-to-hw requests on a private queue (an rbtree priolist). Call into execlists to cancel not only the ELSP tracking for the submitted requests, but also the queue of unsubmitted requests. v2: Move the majority of engine_set_wedged to the backends (both legacy ringbuffer and execlists handling their own lists). Reported-by:
-
- 15 Sep, 2017 9 commits
-
-
Ville Syrjälä authored
Now that we're not using MSI anymore on gen4 we can start using GMBUS and AUX interrupts again. These were disabled on account of them causing the hardware to somehow generate legacy interrupts even when MSI was enabled. See commit c12aba5a ("drm/i915: stop using GMBUS IRQs on Gen4 chips") and commit 4e6b788c ("drm/i915: Disable dp aux irq on g4x") for more details. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Ville Syrjälä authored
All the irq_preinstall and irq_uninstall hooks are now identical. Let's just rename them all the irq_reset and remove the pointless duplicates. Reviewed-by:
-
Ville Syrjälä authored
Currently we're unmasking some random looking bits in HWSTAM on gen3/4/5. The two bits we apparently unmask are 0 and 12, and also bits 16-31 on gen4/5. What those bits do depends on the gen as follows: bit 0: Breakpoint (gen2), ASLE (gen3), reserved (gen4), render user interrupt (gen5) bit 12: Sync flush statusa (gen2-4), reserved (gen5) bit 16-31: The ones that can unmasked seem to be mostly some display stuff on gen4. Bit 18 is the PIPE_CONTROL notify, which might be the only intresting one. On gen5 all the bits are reserved. So I don't know whether we actually depend on that status page write somehow. Extra seqno coherency by accident perhaps? Except we don't even unmask the user interrupt bit in HWSTAM except on gen5, and sync flush isn't something we use normally, so seems unlikely. So let's just assume we don't need any of this and mask everything in HWSTAM. From gen6 onwards there's a separate HWSTAM for each engine, and so we deal with them during the engine setup. Signed-off-by: -
Ville Syrjälä authored
The execlist code already masks everything in the ring HWSTAM, but the ringbuffer code doesn't. Let's go ahead and do that. Pre-gen6 platforms setup HWSTAM during irq setup already since there's just the one register, and it also contains bits for non-ring interrupts. Signed-off-by:
-
Michal Wajdeczko authored
We're always specifying description of each module param in separate macro. Let's combine description into our main macro. Started with Coccinelle, followed by minor cleanup. @match1@ declarer name MODULE_PARM_DESC; identifier n; constant c; @@ ( - MODULE_PARM_DESC(n, c); ) @fix1 depends on match1@ declarer name i915_param_named; declarer name i915_param_named_unsafe; identifier match1.n; constant match1.c; @@ ( i915_param_named(n, ... + , c ); | i915_param_named_unsafe(n, ... + , c ); ) Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michal Wajdeczko authored
As we now use same name for public module param and its local representation we can simplify param definition macro. Changes done with Coccinelle: @@ declarer name module_param_named; declarer name module_param_named_unsafe; declarer name i915_param_named; declarer name i915_param_named_unsafe; identifier n; @@ ( -module_param_named(n, i915.n, +i915_module_param_named(n, ...); | -module_param_named_unsafe(n, i915.n, +i915_module_param_named_unsafe(n, ...); ) Suggested-by:
-
Michal Wajdeczko authored
This modparam affects not only LVDS but also eDP panels. Additionally with this rename we will keep modparam and i915_params field name in sync. This patch will unblock us with further improvements around params defs. Suggested-by:
Ville Syrjala <ville.syrjala@intel.com> Signed-off-by:
-
Chris Wilson authored
To silence the critcs: [56532.161115] workqueue: PF_MEMALLOC task 36(khugepaged) is flushing !WQ_MEM_RECLAIM i915-userptr-release: (null) [56532.161138] ------------[ cut here ]------------ [56532.161144] WARNING: CPU: 1 PID: 36 at kernel/workqueue.c:2418 check_flush_dependency+0xe8/0xf0 [56532.161145] Modules linked in: wmi_bmof [56532.161148] CPU: 1 PID: 36 Comm: khugepaged Not tainted 4.13.0-krejzi #1 [56532.161149] Hardware name: HP HP ProBook 470 G3/8102, BIOS N78 Ver. 01.17 06/08/2017 [56532.161150] task: ffff8802371ee200 task.stack: ffffc90000174000 [56532.161152] RIP: 0010:check_flush_dependency+0xe8/0xf0 [56532.161152] RSP: 0018:ffffc900001777b8 EFLAGS: 00010286 [56532.161153] RAX: 000000000000006c RBX: ffff88022fc5a000 RCX: 0000000000000001 [56532.161154] RDX: 0000000000000000 RSI: 0000000000000086 RDI: 00000000ffffffff [56532.161155] RBP: 0000000000000000 R08: 14f038bb55f6dae0 R09: 0000000000000516 [56532.161155] R10: ffffc900001778a0 R11: 000000006c756e28 R12: ffff8802371ee200 [56532.161156] R13: 0000000000000000 R14: 000000000000000b R15: ffffc90000177810 [56532.161157] FS: 0000000000000000(0000) GS:ffff880240480000(0000) knlGS:0000000000000000 [56532.161158] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56532.161158] CR2: 0000000004795ff8 CR3: 000000000220a000 CR4: 00000000003406e0 [56532.161159] Call Trace: [56532.161161] ? flush_workqueue+0x136/0x3e0 [56532.161178] ? _raw_spin_unlock_irqrestore+0xf/0x30 [56532.161179] ? try_to_wake_up+0x1ce/0x3b0 [56532.161183] ? i915_gem_userptr_mn_invalidate_range_start+0x13f/0x150 [56532.161184] ? _raw_spin_unlock+0xd/0x20 [56532.161186] ? i915_gem_userptr_mn_invalidate_range_start+0x13f/0x150 [56532.161189] ? __mmu_notifier_invalidate_range_start+0x4a/0x70 [56532.161191] ? try_to_unmap_one+0x5e5/0x660 [56532.161193] ? rmap_walk_file+0xe4/0x240 [56532.161195] ? __ClearPageMovable+0x10/0x10 [56532.161196] ? try_to_unmap+0x8c/0xe0 [56532.161197] ? page_remove_rmap+0x280/0x280 [56532.161199] ? page_not_mapped+0x10/0x10 [56532.161200] ? page_get_anon_vma+0x90/0x90 [56532.161202] ? migrate_pages+0x6a5/0x940 [56532.161203] ? isolate_freepages_block+0x330/0x330 [56532.161205] ? compact_zone+0x593/0x6a0 [56532.161206] ? enqueue_task_fair+0xc3/0x1180 [56532.161208] ? compact_zone_order+0x9b/0xc0 [56532.161210] ? get_page_from_freelist+0x24a/0x900 [56532.161212] ? try_to_compact_pages+0xc8/0x240 [56532.161213] ? try_to_compact_pages+0xc8/0x240 [56532.161215] ? __alloc_pages_direct_compact+0x45/0xe0 [56532.161216] ? __alloc_pages_slowpath+0x845/0xb90 [56532.161218] ? __alloc_pages_nodemask+0x176/0x1f0 [56532.161220] ? wait_woken+0x80/0x80 [56532.161222] ? khugepaged+0x29e/0x17d0 [56532.161223] ? wait_woken+0x80/0x80 [56532.161225] ? collapse_shmem.isra.39+0xa60/0xa60 [56532.161226] ? kthread+0x10d/0x130 [56532.161227] ? kthread_create_on_node+0x60/0x60 [56532.161228] ? ret_from_fork+0x22/0x30 [56532.161229] Code: 00 8b b0 10 05 00 00 48 8d 8b b0 00 00 00 48 8d 90 b8 06 00 00 49 89 e8 48 c7 c7 38 55 09 82 c6 05 f9 c6 1d 01 01 e8 0e a1 03 00 <0f> ff e9 6b ff ff ff 90 48 8b 37 40 f6 c6 04 75 1b 48 c1 ee 05 [56532.161251] ---[ end trace 2ce2b4f5f69b803b ]--- Signed-off-by:
-
Chris Wilson authored
Commit 1bf6ad62 ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos") removed the use of in_vbl, but did not remove the local variable. Do so now. Fixes: 1bf6ad62 ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos") Signed-off-by:
-
- 14 Sep, 2017 10 commits
-
-
Manasi Navare authored
No functional changes. Only change the macro from "DPLL_CFGCR0_DC0_FRAC_SHIFT to DPLL_CFGCR0_DCO_FRACTION_SHIFT to be consistent with DPLL_CFGCR0_DCO_FRACTION_MASK and DPLL_CFGCR0_DCO_FRACTION Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Bspec claims that HWSTAM is only 16 bits on gen3, but the other interrupts registers are 32 bits and there are 18 valid interrupt bits. Hence a 16 bit HWSTAM wouldn't be able to contain all the bits, so it seems the spec is incorrect about the size of the register. And indeed I can clear bits 16 and 17 just fine with a 32 bit write. So let's adjust the code to treat the register as 32 bits. Acked-by:
-
Ville Syrjälä authored
Eliminate the loops from the gen2-3 irq handlers. Since we don't use MSI anymore on these platforms, and thus the CPU interrupt will be level triggered, we shouldn't need to play any tricks with IER to induce edges from IIR. IIR itself still detects only edges from PIPESTAT & co. on gen4 but since IIR is double buffered and we only clear one bit per irq handler invocation we can use the normal "clear PIPESTAT & co. -> clear IIR" approach to ack the interrupts. On gen2 everything is level triggered, and gen3 presumably follows either the gen2 or gen4 approach since nothing else would really make sense. v2: Drop the IER tricks since we no longer use MSI Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ville Syrjälä authored
Extract the gen2-4 PIPESTAT irq handling into separate functions just like we already do on VLV/CHV. We can share valleyview_pipestat_irq_ack() on all gmch platforms to actually read and clear the PIPESTAT status bits, so let's rename it to i9xx_pipestat_irq_ack(). Reviewed-by:
-
Ville Syrjälä authored
There should be no way to land in irq_uninstall without a valid dev_priv. Let's kill off the remaining checks, which are probably some kind of UMS leftovers. Not all the irq_uninstall hooks even had them anymore. Reviewed-by:
-
Ville Syrjälä authored
Do the irq_mask/enable_mask setup in the same way on gen3/4, and also reorder the steps to make the code more uniform. Reviewed-by:
-
Ville Syrjälä authored
We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook so doing it again in the .irq_postinstall is pointless. Reviewed-by:
-
Ville Syrjälä authored
Unify the appaerance of the gen2-4 irq postinstall hooks a little bit by doing the EMR setup first on all the platforms. Reviewed-by:
-
Ville Syrjälä authored
Unify the appearance of the gen2 irq code with the gen3+ code by introducing the GEN2_IRQ_RESET/INIT macros. Reviewed-by:
-
Ville Syrjälä authored
Replace the manual IMR+IER+IIR write sequences with the appropriate GEN3_IRQ_RESET/INIT macro invocations in gen3/4. Signed-off-by:
-
