- 09 Aug, 2019 21 commits
-
-
Chris Wilson authored
The filesystem reconfigure API is undergoing a transition, breaking our current code. As we only set the default options, we can simply remove the call to s_op->remount_fs(). In the future, when HW permits, we can try re-enabling huge page support, albeit as suggested with new per-file controls. Reported-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reported-by:
Sedat Dilek <sedat.dilek@gmail.com> Suggested-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Hugh Dickins <hughd@google.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190808172226.18306-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Move the timeline from being inside the intel_ring to intel_context itself. This saves much pointer dancing and makes the relations of the context to its timeline much clearer. Signed-off-by:
-
Chris Wilson authored
Push the ring creation flags from the outer GEM context to the inner intel_context to avoid an unsightly back-reference from inside the backend. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190809182518.20486-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Refactor the backends to handle the deferred context allocation in a consistent manner, and allow calling it as an explicit first step in pinning a context for the first time. This should make it easier for backends to keep track of partially constructed contexts from initialisation. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190809182518.20486-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we are phasing out using the GEM context for internal clients that need to manipulate logical context state directly, remove the constructor for the GVT context. We are not using it for anything other than default setup and allocation of an i915_ppgtt. Signed-off-by:
-
Chris Wilson authored
Since we have already stopped the ring, cleared the ring, disabled the ring (and verifying the ring is clear), a later debug message that the ring is no longer clear serves no function. It appears it restarts anyway, and we verify that the ring started correctly afterwards. Signed-off-by:
-
Chris Wilson authored
For the default I915_EXEC_BSD round robin selector, it may select any available VCS engine. Make it so. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190809091010.23281-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
We keep a global seed for the legacy BSD round-robin selector, but in our testing of multiple simultaneous client workloads, a random seed spreads the load more evenly. (As even as an initial round-robin selector can be!) Removing the global is one less variable we have to find a home for! We can simulate multi-client (both same and mixed workloads) using igt/gem_wsim to work out optimal strategies and then compare our simulation with the actual transcoder on multi-engine machines. This fixed round-robin turns out to be one of the worst methods. No user is advised to use this method; the current suggestion is to use a virtual engine for agnostic batches, randomised submission or using the busyness tracking to select the most idle engine at the time of dispatch. At the present time, intel-media is explicit, but libva still seems to use it, with the exception of batches that must execute on vcs0. Oh well. Signed-off-by:
-
Chris Wilson authored
To use the legacy BSD selector, you must have a second VCS engine, or else the ABI simply maps the request for another engine onto VCS0. However, we only checked a single VCS1 location and overlooking the possibility of a sparse VCS set being mapped to the dense ABI. v2: num_vcs_engines() turns out to be reusable and futureproof it so we never have to worry about this silly bit of ABI again! Signed-off-by:
-
Chris Wilson authored
After a preempt-to-busy, we may find an active request that is caught between execution states. Walk back along the timeline instead of the execution list to be safe. [ 106.417541] i915 0000:00:02.0: Resetting rcs0 for preemption time out [ 106.417659] ================================================================== [ 106.418041] BUG: KASAN: slab-out-of-bounds in __execlists_reset+0x2f2/0x440 [i915] [ 106.418123] Read of size 8 at addr ffff888703506b30 by task swapper/1/0 [ 106.418194] [ 106.418267] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G U 5.3.0-rc3+ #5 [ 106.418344] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 106.418434] Call Trace: [ 106.418508] <IRQ> [ 106.418585] dump_stack+0x5b/0x90 [ 106.418941] ? __execlists_reset+0x2f2/0x440 [i915] [ 106.419022] print_address_description+0x67/0x32d [ 106.419376] ? __execlists_reset+0x2f2/0x440 [i915] [ 106.419731] ? __execlists_reset+0x2f2/0x440 [i915] [ 106.419810] __kasan_report.cold.6+0x1a/0x3c [ 106.419888] ? __trace_bprintk+0xc0/0xd0 [ 106.420239] ? __execlists_reset+0x2f2/0x440 [i915] [ 106.420318] check_memory_region+0x144/0x1c0 [ 106.420671] __execlists_reset+0x2f2/0x440 [i915] [ 106.421029] execlists_reset+0x3d/0x50 [i915] [ 106.421387] intel_engine_reset+0x203/0x3a0 [i915] [ 106.421744] ? igt_reset_nop+0x2b0/0x2b0 [i915] [ 106.421825] ? _raw_spin_trylock_bh+0xe0/0xe0 [ 106.421901] ? rcu_core+0x1b9/0x6a0 [ 106.422251] preempt_reset+0x9a/0xf0 [i915] [ 106.422333] tasklet_action_common.isra.15+0xc0/0x1e0 [ 106.422685] ? execlists_submit_request+0x200/0x200 [i915] [ 106.422764] __do_softirq+0x106/0x3cf [ 106.422840] irq_exit+0xdc/0xf0 [ 106.422914] smp_apic_timer_interrupt+0x81/0x1c0 [ 106.422988] apic_timer_interrupt+0xf/0x20 [ 106.423059] </IRQ> [ 106.423144] RIP: 0010:cpuidle_enter_state+0xc3/0x620 [ 106.423222] Code: 24 0f 1f 44 00 00 31 ff e8 da 87 9c ff 80 7c 24 10 00 74 12 9c 58 f6 c4 02 0f 85 33 05 00 00 31 ff e8 c1 77 a3 ff fb 45 85 e4 <0f> 89 bf 02 00 00 48 8d 7d 10 e8 4e 45 b9 ff c7 45 10 00 00 00 00 [ 106.423311] RSP: 0018:ffff88881c30fda8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 [ 106.423390] RAX: 0000000000000000 RBX: ffffffff825b4c80 RCX: ffffffff810c8a00 [ 106.423465] RDX: dffffc0000000000 RSI: 0000000039f89620 RDI: ffff88881f6b00a8 [ 106.423540] RBP: ffff88881f6b5bf8 R08: 0000000000000002 R09: 000000000002ed80 [ 106.423616] R10: 0000003fdd956146 R11: ffff88881c2d1e47 R12: 0000000000000008 [ 106.423691] R13: 0000000000000008 R14: ffffffff825b4f80 R15: ffffffff825b4fc0 [ 106.423772] ? sched_idle_set_state+0x20/0x30 [ 106.423851] ? cpuidle_enter_state+0xa6/0x620 [ 106.423874] ? tick_nohz_idle_stop_tick+0x1d1/0x3f0 [ 106.423896] cpuidle_enter+0x37/0x60 [ 106.423919] do_idle+0x246/0x280 [ 106.423941] ? arch_cpu_idle_exit+0x30/0x30 [ 106.423964] ? __wake_up_common+0x46/0x240 [ 106.423986] cpu_startup_entry+0x14/0x20 [ 106.424009] start_secondary+0x1b0/0x200 [ 106.424031] ? set_cpu_sibling_map+0x990/0x990 [ 106.424054] secondary_startup_64+0xa4/0xb0 [ 106.424075] [ 106.424096] Allocated by task 626: [ 106.424119] save_stack+0x19/0x80 [ 106.424143] __kasan_kmalloc.constprop.7+0xc1/0xd0 [ 106.424165] kmem_cache_alloc+0xb2/0x1d0 [ 106.424277] i915_sched_lookup_priolist+0x1ab/0x320 [i915] [ 106.424385] execlists_submit_request+0x73/0x200 [i915] [ 106.424498] submit_notify+0x59/0x60 [i915] [ 106.424600] __i915_sw_fence_complete+0x9b/0x330 [i915] [ 106.424713] __i915_request_commit+0x4bf/0x570 [i915] [ 106.424818] intel_engine_pulse+0x213/0x310 [i915] [ 106.424925] context_close+0x22f/0x470 [i915] [ 106.425033] i915_gem_context_destroy_ioctl+0x7b/0xa0 [i915] [ 106.425058] drm_ioctl_kernel+0x131/0x170 [ 106.425081] drm_ioctl+0x2d9/0x4f1 [ 106.425104] do_vfs_ioctl+0x115/0x890 [ 106.425126] ksys_ioctl+0x35/0x70 [ 106.425147] __x64_sys_ioctl+0x38/0x40 [ 106.425169] do_syscall_64+0x66/0x220 [ 106.425191] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 106.425213] [ 106.425234] Freed by task 0: [ 106.425255] (stack is not available) [ 106.425276] [ 106.425297] The buggy address belongs to the object at ffff888703506a40 [ 106.425297] which belongs to the cache i915_priolist of size 104 [ 106.425321] The buggy address is located 136 bytes to the right of [ 106.425321] 104-byte region [ffff888703506a40, ffff888703506aa8) [ 106.425345] The buggy address belongs to the page: [ 106.425367] page:ffffea001c0d4180 refcount:1 mapcount:0 mapping:ffff88873e1cf740 index:0xffff888703506e40 compound_mapcount: 0 [ 106.425391] flags: 0x8000000000010200(slab|head) [ 106.425415] raw: 8000000000010200 ffffea0020192b88 ffff8888174b5450 ffff88873e1cf740 [ 106.425439] raw: ffff888703506e40 000000000010000e 00000001ffffffff 0000000000000000 [ 106.425464] page dumped because: kasan: bad access detected [ 106.425486] [ 106.425506] Memory state around the buggy address: [ 106.425528] ffff888703506a00: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 [ 106.425551] ffff888703506a80: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc [ 106.425573] >ffff888703506b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 106.425597] ^ [ 106.425619] ffff888703506b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 106.425642] ffff888703506c00: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00 [ 106.425664] ================================================================== Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Signed-off-by:
-
Chris Wilson authored
Matthew spotted that we lost the fput() for phys objects now that we are not relying on the core to cleanup the GEM object. (For the record, phys objects import the shmemfs from their original set of pages and keep it to provide swap space, but we never transform back into a shmem object.) Reported-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header from i915_drv.h to avoid sprinkling includes all over the place; this can be changed as a follow-up if necessary. No functional changes. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b8406f72ce5bfb8863a54003b756ebae8b17c9cb.1565271681.git.jani.nikula@intel.com
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header from i915_drv.h to avoid sprinkling includes all over the place; this can be changed as a follow-up if necessary. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
Seems like a better fit. Reduce clutter in i915_drv.[ch]. Reviewed-by:
-
Jani Nikula authored
It's for display. Seems like a better fit. Reduce clutter in i915_drv.h. Reviewed-by:
-
Jani Nikula authored
Seems like a better fit. Reduce clutter in i915_drv.h. Reviewed-by:
-
Jani Nikula authored
The last user of dev_priv->no_aux_handshake was removed in commit 3cf2efb1 ("Revert "drm/i915/dp: use VBT provided eDP params if available""). Finally remove the leftovers. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 08 Aug, 2019 16 commits
-
-
Chris Wilson authored
Currently we walk the entire list of obj->vma for each obj within a file to find the matching vma of this context. Since we know we are searching for a particular vma bound to a user context, we can use the rbtree to search for it rather than repeatedly walk everything. Signed-off-by:
-
Chris Wilson authored
Skip printing out idle engines that did not contribute to the GPU hang. As the number of engines gets ever larger, we have increasing noise in the error state where typically there is only one guilty request on one engine that we need to inspect. Signed-off-by:
-
Chris Wilson authored
As we need to acquire a mutex to serialise the final intel_wakeref_put, we need to ensure that we are in process context at that time. However, we want to allow operation on the intel_wakeref from inside timer and other hardirq context, which means that need to defer that final put to a workqueue. Inside the final wakeref puts, we are safe to operate in any context, as we are simply marking up the HW and state tracking for the potential sleep. It's only the serialisation with the potential sleeping getting that requires careful wait avoidance. This allows us to retain the immediate processing as before (we only need to sleep over the same races as the current mutex_lock). v2: Add a selftest to ensure we exercise the code while lockdep watches. v3: That test was extremely loud and complained about many things! v4: Not a whale! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111295 References: https://bugs.freedesktop.org/show_bug.cgi?id=111245 References: https://bugs.freedesktop.org/show_bug.cgi?id=111256 Fixes: 18398904 ("drm/i915: Only recover active engines") Fixes: 51fbd8de ("drm/i915/pmu: Atomically acquire the gt_pm wakeref") Signed-off-by:
-
Chris Wilson authored
Grr, missed one*. For using the legacy engine map, we should use engine->legacy_idx. Ideally, we should know the intel_context in the selftest and avoid all the fiddling around with unwanted GEM contexts. * In my defence, the conflict was added in another patch after it was tested by CI. v2: mock engines needs legacy love as well Fixes: f1c4d157 ("drm/i915: Fix up the inverse mapping for default ctx->engines[]") Signed-off-by:
-
José Roberto de Souza authored
On TGL this register do not map directly to port, it was already handled when setting it(TGL_TRANS_DDI_SELECT_PORT()) but not when reading it. To make it consisntent adding a macro for the older gens too. v2: Adding TGL_PORT_TRANS_DDI_SELECT() so all future users can reuse it (Lucas) v3: Missed parentheses arround val (Jose) v4: Renamed TGL_PORT_TRANS_DDI_SELECT to TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT (Lucas) Added TRANS_DDI_FUNC_CTL_VAL_TO_PORT (Lucas) Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190808004935.1787-2-jose.souza@intel.com
-
José Roberto de Souza authored
When getting the pipes attached to encoder if it is not a eDP encoder it iterates over all pipes and read a transcoder register. But it should not read a transcoder register before get its power domain. It was not a issue in gens older than 12 because if it only had port A connected it would be attached to EDP and it would skip all the transcoders readout, if it had more than one port connected, pipe B would cause PG3 to be on and it contains all other transcoders. But on gen 12 there is no EDP transcoder so it is always iterating over all pipes and if only one sink is connected, PG3 is kept off and reading other transcoders registers would cause a unclaimed read warning. So here getting the power domain of the transcoder only if it is enabled, otherwise it is not connected to the DDI. Reviewed-by:
-
Chris Wilson authored
The order in which we store the engines inside default_engines() for the legacy ctx->engines[] has to match the legacy I915_EXEC_RING selector mapping in execbuf::user_map. If we present VCS2 as being the second instance of the video engine, legacy userspace calls that I915_EXEC_BSD2 and so we need to insert it into the second video slot. v2: Record the legacy mapping (hopefully we can remove this need in the future) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111328 Fixes: 2edda80d ("drm/i915: Rename engines to match their user interface") Signed-off-by:
-
Chris Wilson authored
Ignore the central i915->kernel_context for allocating an engine, as that GEM context is being phased out. For internal clients, we just need the per-engine logical state, so allocate it at the point of use. Signed-off-by:
-
Chris Wilson authored
Modernise the mock_request factory to take intel_context not a (GEM context, intel_engine_cs) tuple. Signed-off-by:
-
Vandita Kulkarni authored
Blanking packet bit will control whether the transcoder allows the link to enter the LP state during BLLP regions (assuming there is enough time), or whether it will keep the link in the HS state with a Blanking Packet Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Vandita Kulkarni authored
Most of the functions and mipi dsi sequence remains same as of ICL for TGL. Hence extending the support to TGL. Signed-off-by:
-
Vandita Kulkarni authored
For TGL, there is no need to keep DDI clock on till IO enabling for mipi dsi. Signed-off-by:
-
Vandita Kulkarni authored
Do not override TA_SURE timing parameter to zero for DSI 8X frequency 800MHz or below on TGL. Signed-off-by:
-
Vandita Kulkarni authored
Latency programming remains same as that of ICL and setting latency otimization for PCS_DW1 lanes is same as that of EHL, hence extending it to TGL. Signed-off-by:
-
Vandita Kulkarni authored
Program vblank register for mipi dsi in video mode on TGL. Signed-off-by:
-
Jani Nikula authored
Abstract the rather self-contained piece of code from i915_drv.[ch]. No functional changes. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 07 Aug, 2019 3 commits
-
-
Michal Wajdeczko authored
Insert few more failure points into firmware fetch procedure to check use of the wrong blob name or use of the mismatched firmware versions. Also update some messages (remove ptr, duplicated infos) and stop treating all fetch errors as missing firmware case. v2: update log levels (Chris) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Michal Wajdeczko authored
WOPCM programming error might be due to inserted earlier probe failure that could affects HuC firmware loading and thus impacts result of WOPCM partitioning that would be now incompatible with previously programmed values. Signed-off-by:
-
Michal Wajdeczko authored
No need to define it globally as we're only using it in wopcm.c Signed-off-by:
-
