summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-12Revert "drm/i915/tgl: Add extra hdc flush workaround"Caz Yokoyama
This reverts commit 36a6b5d964d995b536b1925ec42052ee40ba92c4. The commit takes care Wa_1604544889 which was fixed on a0 stepping based on a0 replan. So no SW workaround is required on any stepping now. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Fixes: 36a6b5d964d9 ("drm/i915/tgl: Add extra hdc flush workaround") Link: https://patchwork.freedesktop.org/patch/msgid/1c751032ce79c80c5485cae315f1a9904ce07cac.1583359940.git.caz.yokoyama@intel.com
2020-03-12drm/i915/gt: Wait for RCUs frees before asserting idle on unloadChris Wilson
During driver unload, we have many asserts that we have released our bookkeeping structs and are idle. In some cases, these struct are protected by RCU and we do not release them until after an RCU grace period. Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312115307.16460-1-chris@chris-wilson.co.uk
2020-03-12drm/i915/selftests: Use igt_random_offset()Chris Wilson
Switch igt_vm_isolation() to using igt_random_offset(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312154708.1720-1-chris@chris-wilson.co.uk
2020-03-12drm/i915/gem: Drop relocation slowpathChris Wilson
Since the relocations are no longer performed under a global struct_mutex, or any other lock, that is also held by pagefault handlers, we can relax and allow our fast path to take a fault. As we no longer need to abort the fast path for lock avoidance, we no longer need the slow path handling at all. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200311160310.26711-1-chris@chris-wilson.co.uk
2020-03-12drm/vmwgfx: Remove a few unused functionsSebastian Andrzej Siewior
I noticed that there is a prototype for vmw_fifo_ping_host_locked() but no function. Then I looked further and noticed more functions which are not used anymore or functions protoypes which remained after the function was removed. Remove unused function (prototypes). Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2020-03-12drm/vmwgfx: Drop preempt_disable() in vmw_fifo_ping_host()Sebastian Andrzej Siewior
vmw_fifo_ping_host() disables preemption around a test and a register write via vmw_write(). The write function acquires a spinlock_t typed lock which is not allowed in a preempt_disable()ed section on PREEMPT_RT. This has been reported in the bugzilla. It has been explained by Thomas Hellstrom that this preempt_disable()ed section is not required for correctness. Remove the preempt_disable() section. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206591 Link: https://lkml.kernel.org/r/0b5e1c65d89951de993deab06d1d197b40fd67aa.camel@vmware.com Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2020-03-12drm/i915/gen12: Disable preemption timeoutTvrtko Ursulin
Allow super long OpenCL workloads which cannot be preempted within the default timeout to run out of the box. v2: * Make it stick out more and apply only to RCS. (Chris) v3: * Mention platform override in kconfig. (Joonas) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Michal Mrozek <Michal.mrozek@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200312115748.29970-1-tvrtko.ursulin@linux.intel.com
2020-03-12drm/vmwgfx: Refuse DMA operation when SEV encryption is activeThomas Hellstrom
TTM doesn't yet fully support mapping of DMA memory when SEV is active, so in that case, refuse DMA operation. For guest-backed object operation this means 3D acceleration will be disabled. For host-backed, VRAM will be used for data transfer between the guest and the device. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2020-03-12drm/vmwgfx: Fix the refuse_dma mode when using guest-backed objectsThomas Hellstrom
When we refuse DMA from system pages for whatever reason, we don't handle that correctly when guest-backed objects was enabled. Since guest-backed objects by definition require DMA to and from system pages, disable all functionality that relies on them. That basically amounts to 3D acceleration and screen targets. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com>
2020-03-12drm/tegra: dc: Release PM and RGB output when client's registration failsDmitry Osipenko
Runtime PM and RGB output need to be released when host1x client registration fails. The releasing is missed in the code, let's correct it. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-12drm/tegra: dc: Use devm_platform_ioremap_resourceDmitry Osipenko
The devm_platform_ioremap_resource() helper replaces few lines of a boilerplate code with a single line, making code to look cleaner a tad. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-03-12Merge tag 'drm-misc-next-2020-03-09' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.7: UAPI Changes: Cross-subsystem Changes: Core Changes: Driver Changes: - fb-helper: Remove drm_fb_helper_{add,add_all,remove}_one_connector - fbdev: some cleanups and dead-code removal - Conversions to simple-encoder - zero-length array removal - Panel: panel-dpi support in panel-simple, Novatek NT35510, Elida KD35T133, Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200309135439.dicfnbo4ikj4tkz7@gilmour
2020-03-11drm/i915/gem: Take a copy of the engines for context_barrier_taskChris Wilson
When applying the context-barrier, we only care about the current engines, as the next set of engines will be naturally after the barrier. So we can skip holding the ctx->engines_mutex while constructing the request by taking a sneaky reference to the i915_gem_engines instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200311221739.30375-2-chris@chris-wilson.co.uk
2020-03-11drm/i915/gem: Mark up sw-fence notify functionChris Wilson
The sw-fence notify function requires to be at least 4-byte aligned so that we can use the low bits in the function pointer for internal fence flags. Make it so. References: https://gitlab.freedesktop.org/drm/intel/issues/1433 Fixes: 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing engines") 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/20200311221739.30375-1-chris@chris-wilson.co.uk
2020-03-11drm: Remove drm dp mst destroy_connector callbacksPankaj Bharadiya
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector((drm_connector_unregister()/drm_connector_put())) except for amdgpu_dm driver where some amdgpu_dm specific code in there. This connector cleaning up is now being handled in the drm core so driver destroy_connector callbacks are not needed (except for amdgpu_dm) hence remove them. Removal is done with below sementic patch: @r1@ identifier func, E; @@ struct drm_dp_mst_topology_cbs E = { ..., - .destroy_connector = func }; @delete depends on r1@ identifier r1.func; @@ - static void func(...){...} Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-6-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-03-11drm: Add drm_dp_destroy_connector helper and use itPankaj Bharadiya
drm_dp_mst_topology_mgr_cbs.destroy_connector callbacks are identical amongst every driver and don't do anything other than cleaning up the connector (drm_connector_unregister()/drm_connector_put()) except for amdgpu_dm driver where some amdgpu_dm specific code in there which I an not sure if it should stay or not. Create and use a helper which calls driver's destroy_connector hook if available otherwise does cleanup internally. This is the step towards removing identical hooks from every driver. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-5-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-03-11drm/dp_mst: Remove register_connector callbackPankaj Bharadiya
Now drm_dp_mst_topology_cbs.register_connector callback is not getting used anymore hence remove it. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-4-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-03-11drm: Remove dp mst register connector callbacksPankaj Bharadiya
drm_dp_mst_port_add_connector() directly calls the drm_connector_register() now and drm_dp_mst_topology_mgr_cbs.register_connector callback is not getting called anymore. Hence remove all drm_dp_mst_topology_mgr_cbs.register_connector callbacks. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. The removal is done with below sementic patch: @r1@ identifier func, E; @@ struct drm_dp_mst_topology_cbs E = { ..., - .register_connector = func }; @delete depends on r1@ identifier r1.func; @@ - static void func(...){...} Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-3-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-03-11drm: Register connector instead of calling register_connector callbackPankaj Bharadiya
drm_dp_mst_topology_mgr_cbs.register_connector callbacks are literally identical amongst every driver and don't do anything other than calling drm_connector_register(). Hence call drm_connector_register() directly instead of a callback. This is the preparatory step for removing the drm_dp_mst_topology_mgr_cbs.register_connector callback hook. Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Suggested-by: Emil Velikov <emil.velikov@collabora.com> Suggested-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200307083023.76498-2-pankaj.laxminarayan.bharadiya@intel.com Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-03-11drm/edid: Add function to parse EDID descriptors for monitor rangeManasi Navare
Adaptive Sync is a VESA feature so add a DRM core helper to parse the EDID's detailed descritors to obtain the adaptive sync monitor range. Store this info as part fo drm_display_info so it can be used across all drivers. This part of the code is stripped out of amdgpu's function amdgpu_dm_update_freesync_caps() to make it generic and be used across all DRM drivers v6: * Call it monitor_range (Ville) v5: * Use the renamed flags v4: * Use is_display_descriptor() (Ville) * Name the monitor range flags (Ville) v3: * Remove the edid parsing restriction for just DP (Nicholas) * Use drm_for_each_detailed_block (Ville) * Make the drm_get_adaptive_sync_range function static (Harry, Jani) v2: * Change vmin and vmax to use u8 (Ville) * Dont store pixel clock since that is just a max dotclock and not related to VRR mode (Manasi) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-2-manasi.d.navare@intel.com
2020-03-11drm/edid: Name the detailed monitor range flagsManasi Navare
This patch adds defines for the detailed monitor range flags as per the EDID specification. v2: * Rename the flags with DRM_EDID_ (Jani N) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Clinton A Taylor <clinton.a.taylor@intel.com> Cc: Kazlauskas Nicholas <Nicholas.Kazlauskas@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310231651.13841-1-manasi.d.navare@intel.com
2020-03-11drm/i915: Add missing HDMI audio pixel clocks for gen12Kai Vehmanen
Gen12 hardware supports HDMI audio pixel clocks of 296.7/297Mhz and 593.4/594Mhz. Add the missing rates and add logic to ignore them if running on older hardware. Bspec: 49333 Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310162338.9387-1-kai.vehmanen@linux.intel.com
2020-03-11drm/panel-simple: Fix dotclock for Logic PD Type 28Ville Syrjälä
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Adam Ford <aford173@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-22-ville.syrjala@linux.intel.com Reviewed-by: Adam Ford <aford173@gmail.com>
2020-03-11drm/panel-sony-acx424akp: Fix dotclocksVille Syrjälä
The currently listed dotclocks disagree with the currently listed vrefresh rates. Change the dotclocks to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-9-ville.syrjala@linux.intel.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-11drm/panel-lg-lg4573: Fix dotclockVille Syrjälä
The currently listed dotclock disagrees with the currently listed vrefresh rate. Change the dotclock to match the vrefresh. Someone tell me which (if either) of the dotclock or vreresh is correct? Cc: Heiko Schocher <hs@denx.de> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302203452.17977-7-ville.syrjala@linux.intel.com Reviewed-by: Heiko Schocher <hs@denx.de>
2020-03-11drm/panel-ilitek-ili9322: Fix dotclocksVille Syrjälä
The listed dotclocks are two orders of mangnitude out. Fix them. v2: Just divide everything by 100 (Linus) Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200309133809.32585-1-ville.syrjala@linux.intel.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-11drm/panel-novatek-nt35510: Fix dotclockVille Syrjälä
The dotclock is three orders of magnitude out. Fix it. v2: Just set it to 20MHz (Linus) Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200309133644.32385-1-ville.syrjala@linux.intel.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2020-03-11drm: sysfs: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200311073540.7108-1-tiwai@suse.de
2020-03-11drm/i915/gem: Mark up the racy read of the mmap_singletonChris Wilson
[11057.642683] BUG: KCSAN: data-race in i915_gem_mmap [i915] / singleton_release [i915] [11057.642717] [11057.642740] write (marked) to 0xffff8881f24471a0 of 8 bytes by task 44668 on cpu 2: [11057.643162] singleton_release+0x38/0x60 [i915] [11057.643192] __fput+0x160/0x3c0 [11057.643217] ____fput+0x16/0x20 [11057.643241] task_work_run+0xba/0x100 [11057.643263] exit_to_usermode_loop+0xe4/0xf0 [11057.643286] do_syscall_64+0x27e/0x2c0 [11057.643314] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [11057.643339] [11057.643359] read to 0xffff8881f24471a0 of 8 bytes by task 44667 on cpu 3: [11057.643774] i915_gem_mmap+0x295/0x670 [i915] [11057.643802] mmap_region+0x62b/0xac0 [11057.643825] do_mmap+0x414/0x6b0 [11057.643848] vm_mmap_pgoff+0xa9/0xf0 [11057.643875] ksys_mmap_pgoff+0x1ac/0x2f0 [11057.643900] do_syscall_64+0x6e/0x2c0 [11057.643924] entry_SYSCALL_64_after_hwframe+0x44/0xa9 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/20200311092624.10012-3-chris@chris-wilson.co.uk
2020-03-11drm/i915/execlists: Track active elements during dequeueChris Wilson
Record the initial active element we use when building the next ELSP submission, so that we can compare against it latter to see if there's no change. Fixes: 44d0a9c05bc0 ("drm/i915/execlists: Skip redundant resubmission") 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/20200311092624.10012-2-chris@chris-wilson.co.uk
2020-03-11drm/i915/gt: Pull checking rps->pm_events under the irq_lockChris Wilson
Avoid angering kcsan by serialising the read of the pm_events with the write in rps_disable_interrupts. [ 6268.713419] BUG: KCSAN: data-race in intel_rps_park [i915] / rps_work [i915] [ 6268.713437] [ 6268.713449] write to 0xffff8881eda8efac of 4 bytes by task 1127 on cpu 3: [ 6268.713680] intel_rps_park+0x136/0x260 [i915] [ 6268.713905] __gt_park+0x61/0xa0 [i915] [ 6268.714128] ____intel_wakeref_put_last+0x42/0x90 [i915] [ 6268.714352] __intel_wakeref_put_work+0xd3/0xf0 [i915] [ 6268.714369] process_one_work+0x3b1/0x690 [ 6268.714384] worker_thread+0x80/0x670 [ 6268.714398] kthread+0x19a/0x1e0 [ 6268.714412] ret_from_fork+0x1f/0x30 [ 6268.714423] [ 6268.714435] read to 0xffff8881eda8efac of 4 bytes by task 950 on cpu 2: [ 6268.714664] rps_work+0xc2/0x680 [i915] [ 6268.714679] process_one_work+0x3b1/0x690 [ 6268.714693] worker_thread+0x80/0x670 [ 6268.714707] kthread+0x19a/0x1e0 [ 6268.714720] ret_from_fork+0x1f/0x30 v2: Mark all reads and writes of rpm->pm_events. The flow of enabling/disabling rps is stronly ordered, so the writes and interrupt generation are also strongly ordered -- just this may not be visible to the compiler, so provide annotations. 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/20200311092624.10012-1-chris@chris-wilson.co.uk
2020-03-11drm/ttm: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/357174/ Signed-off-by: Christian König <christian.koenig@amd.com>
2020-03-11drm/i915: Extend i915_request_await_active to use all timelinesChris Wilson
Extend i915_request_await_active() to be able to asynchronously wait on all the tracked timelines simultaneously. 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/20200311092044.16353-1-chris@chris-wilson.co.uk
2020-03-11drm/i915/gt: Use scnprintf() for avoiding potential buffer overflowTakashi Iwai
Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai <tiwai@suse.de> 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/20200311073256.6535-1-tiwai@suse.de
2020-03-11drm/i915/overlay: convert to drm_device based logging.Wambui Karuga
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_overlay.c. This transformation was achieved using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Note that this converts DRM_DEBUG to drm_dbg(). Checkpatch warnings were addressed manually. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ca3c14de13e308419caf33eb4bbf274f5387f1e0.1583766715.git.jani.nikula@intel.com
2020-03-11drm/i915/lvds: convert to drm_device based logging macros.Wambui Karuga
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_lvds.c. This transformation was done by the following coccinelle script that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were fixed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e622ebd2ce07291f2db56174a0a0b31cc2df67df.1583766715.git.jani.nikula@intel.com
2020-03-11drm/i915/lpe_audio: convert to drm_device based logging macros.Wambui Karuga
Convert various uses of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_lpe_audio.c. Note that this converts DRM_DEBUG to drm_dbg(). References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/98588d757a3729d7c8a4b1aaa0b5e7d160398b89.1583766715.git.jani.nikula@intel.com
2020-03-11drm/i915/hotplug: convert to drm_device based logging.Wambui Karuga
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_hotplug.c. In some cases, this involves extracting the drm_i915_private pointer from the drm_device struct to be used in the logging macros. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3dfda89ab4a234f299ada77abd14163cef3f8bd4.1583766715.git.jani.nikula@intel.com
2020-03-11drm/i915/gmbus: convert to drm_device based logging,Wambui Karuga
Conversion instances of printk based drm logging macros to use the struct drm_device based logging macros in i915/display/intel_gmbus.c. This was done using the following coccinelle semantic patch that transforms based on the existence of an existing drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5964ce0a603e2ec0e6110c927a11234e66891258.1583766715.git.jani.nikula@intel.com
2020-03-11drm/i915/fifo_underrun: convert to drm_device based logging.Wambui Karuga
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_fifo_underrun.c. This was done using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } New checkpatch warnings were addressed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3e8e74494c8aa662ab3fb4de1dac63fedef35c47.1583766715.git.jani.nikula@intel.com
2020-03-11drm/i915/dsb: convert to drm_device based logging macros.Wambui Karuga
This converts uses of the printk based drm logging macros to the struct drm_device logging macros in i915/display/intel_dsb.c. This was done using the following coccinelle script: @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2e049c74146f5430ea95653a4f745224d36f960.1583766715.git.jani.nikula@intel.com
2020-03-11drm/ttm: fix false positive assertChristian König
The assert sometimes incorrectly triggers when pinned BOs are destroyed. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Link: https://patchwork.freedesktop.org/patch/356737/
2020-03-11drm/i915: Remove debugfs i915_drpc_info and i915_forcewake_domainsTvrtko Ursulin
The two files have been duplicated under the gt/ subdir and since there are not apparent users looking for them at the old location lets simply remove them and duplicated code. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310164733.26487-1-tvrtko.ursulin@linux.intel.com
2020-03-11drm/rockchip: rgb: don't count non-existent devices when determining subdriversHeiko Stuebner
rockchip_drm_endpoint_is_subdriver() may also return error codes. For example if the target-node is in the disabled state, so no platform-device is getting created for it. In that case current code would count that as external rgb device, which in turn would make probing the rockchip-drm device fail. So only count the target as rgb device if the function actually returns 0. Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121224828.4070067-1-heiko@sntech.de
2020-03-10drm/i915/execlists: Mark up data-races in virtual enginesChris Wilson
The virtual engine passes tokens back and forth to its backing physical engines. [ 57.372993] BUG: KCSAN: data-race in execlists_dequeue [i915] / virtual_submission_tasklet [i915] [ 57.373012] [ 57.373023] write to 0xffff8881f47324c0 of 4 bytes by interrupt on cpu 2: [ 57.373241] execlists_dequeue+0x6fa/0x2150 [i915] [ 57.373458] __execlists_submission_tasklet+0x48/0x60 [i915] [ 57.373677] execlists_submission_tasklet+0xd3/0x170 [i915] [ 57.373694] tasklet_action_common.isra.0+0x42/0xa0 [ 57.373709] __do_softirq+0xd7/0x2cd [ 57.373723] irq_exit+0xbe/0xe0 [ 57.373735] do_IRQ+0x51/0x100 [ 57.373748] ret_from_intr+0x0/0x1c [ 57.373963] engine_retire+0x89/0xe0 [i915] [ 57.373977] process_one_work+0x3b1/0x690 [ 57.373990] worker_thread+0x80/0x670 [ 57.374004] kthread+0x19a/0x1e0 [ 57.374017] ret_from_fork+0x1f/0x30 [ 57.374027] [ 57.374038] read to 0xffff8881f47324c0 of 4 bytes by interrupt on cpu 3: [ 57.374256] virtual_submission_tasklet+0x27/0x5a0 [i915] [ 57.374273] tasklet_action_common.isra.0+0x42/0xa0 [ 57.374288] __do_softirq+0xd7/0x2cd [ 57.374302] run_ksoftirqd+0x15/0x20 [ 57.374315] smpboot_thread_fn+0x1ab/0x300 [ 57.374329] kthread+0x19a/0x1e0 [ 57.374342] ret_from_fork+0x1f/0x30 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/20200310141320.24149-3-chris@chris-wilson.co.uk
2020-03-10drm/i915: Mark up racy read of active rq->engineChris Wilson
As a virtual engine may change the rq->engine to point to the active request in flight, we need to warn the compiler that an active request's engine is volatile. [ 95.017686] write (marked) to 0xffff8881e8386b10 of 8 bytes by interrupt on cpu 2: [ 95.018123] execlists_dequeue+0x762/0x2150 [i915] [ 95.018539] __execlists_submission_tasklet+0x48/0x60 [i915] [ 95.018955] execlists_submission_tasklet+0xd3/0x170 [i915] [ 95.018986] tasklet_action_common.isra.0+0x42/0xa0 [ 95.019016] __do_softirq+0xd7/0x2cd [ 95.019043] irq_exit+0xbe/0xe0 [ 95.019068] irq_work_interrupt+0xf/0x20 [ 95.019491] i915_request_retire+0x2c5/0x670 [i915] [ 95.019937] retire_requests+0xa1/0xf0 [i915] [ 95.020348] engine_retire+0xa1/0xe0 [i915] [ 95.020376] process_one_work+0x3b1/0x690 [ 95.020403] worker_thread+0x80/0x670 [ 95.020429] kthread+0x19a/0x1e0 [ 95.020454] ret_from_fork+0x1f/0x30 [ 95.020476] [ 95.020498] read to 0xffff8881e8386b10 of 8 bytes by task 8909 on cpu 3: [ 95.020918] __i915_request_commit+0x177/0x220 [i915] [ 95.021329] i915_gem_do_execbuffer+0x38c4/0x4e50 [i915] [ 95.021750] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 95.021784] drm_ioctl_kernel+0xe4/0x120 [ 95.021809] drm_ioctl+0x297/0x4c7 [ 95.021832] ksys_ioctl+0x89/0xb0 [ 95.021865] __x64_sys_ioctl+0x42/0x60 [ 95.021901] do_syscall_64+0x6e/0x2c0 [ 95.021927] entry_SYSCALL_64_after_hwframe+0x44/0xa9 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/20200310142403.5953-1-chris@chris-wilson.co.uk
2020-03-10drm/i915/gt: Mark up racy reads for intel_context.inflightChris Wilson
When being used across multiple real engines inside a virtual engine, the intel_context.inflight is updated atomically, and so we must annotate the racy read from outside the owning context. [11142.482846] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] / __execlists_submission_tasklet [i915] [11142.482867] [11142.482878] write (marked) to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 2: [11142.483107] __execlists_submission_tasklet+0x1d33/0x2120 [i915] [11142.483336] execlists_submission_tasklet+0xd3/0x170 [i915] [11142.483355] tasklet_action_common.isra.0+0x42/0xa0 [11142.483371] __do_softirq+0xd7/0x2cd [11142.483384] irq_exit+0xbe/0xe0 [11142.483401] do_IRQ+0x51/0x100 [11142.483424] ret_from_intr+0x0/0x1c [11142.483446] do_idle+0x133/0x1f0 [11142.483465] cpu_startup_entry+0x14/0x16 [11142.483483] start_secondary+0x120/0x180 [11142.483498] secondary_startup_64+0xa4/0xb0 [11142.483512] [11142.483528] read to 0xffff8881f257b5e0 of 8 bytes by interrupt on cpu 1: [11142.483755] __execlists_submission_tasklet+0x14e/0x2120 [i915] [11142.483981] execlists_submission_tasklet+0xd3/0x170 [i915] [11142.483999] tasklet_action_common.isra.0+0x42/0xa0 [11142.484014] __do_softirq+0xd7/0x2cd [11142.484028] do_softirq_own_stack+0x2a/0x40 [11142.484046] do_softirq.part.0+0x26/0x30 [11142.484071] __local_bh_enable_ip+0x46/0x50 [11142.484299] i915_gem_do_execbuffer+0x39c1/0x4e50 [i915] [11142.484528] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [11142.484546] drm_ioctl_kernel+0xe4/0x120 [11142.484559] drm_ioctl+0x297/0x4c7 [11142.484572] ksys_ioctl+0x89/0xb0 [11142.484586] __x64_sys_ioctl+0x42/0x60 [11142.484610] do_syscall_64+0x6e/0x2c0 [11142.484627] entry_SYSCALL_64_after_hwframe+0x44/0xa9 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/20200310141320.24149-1-chris@chris-wilson.co.uk
2020-03-10drm/i915: Tweak scheduler's kick_submission()Chris Wilson
Skip useless priority bumping on adding a new dependency by making sure that we do update the priority if we would have rescheduled the active cotnext. 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/20200310115947.6482-1-chris@chris-wilson.co.uk
2020-03-10drm/i915: Defer semaphore priority bumping to a workqueueChris Wilson
Since the semaphore fence may be signaled from inside an interrupt handler from inside a request holding its request->lock, we cannot then enter into the engine->active.lock for processing the semaphore priority bump as we may traverse our call tree and end up on another held request. CPU 0: [ 2243.218864] _raw_spin_lock_irqsave+0x9a/0xb0 [ 2243.218867] i915_schedule_bump_priority+0x49/0x80 [i915] [ 2243.218869] semaphore_notify+0x6d/0x98 [i915] [ 2243.218871] __i915_sw_fence_complete+0x61/0x420 [i915] [ 2243.218874] ? kmem_cache_free+0x211/0x290 [ 2243.218876] i915_sw_fence_complete+0x58/0x80 [i915] [ 2243.218879] dma_i915_sw_fence_wake+0x3e/0x80 [i915] [ 2243.218881] signal_irq_work+0x571/0x690 [i915] [ 2243.218883] irq_work_run_list+0xd7/0x120 [ 2243.218885] irq_work_run+0x1d/0x50 [ 2243.218887] smp_irq_work_interrupt+0x21/0x30 [ 2243.218889] irq_work_interrupt+0xf/0x20 CPU 1: [ 2242.173107] _raw_spin_lock+0x8f/0xa0 [ 2242.173110] __i915_request_submit+0x64/0x4a0 [i915] [ 2242.173112] __execlists_submission_tasklet+0x8ee/0x2120 [i915] [ 2242.173114] ? i915_sched_lookup_priolist+0x1e3/0x2b0 [i915] [ 2242.173117] execlists_submit_request+0x2e8/0x2f0 [i915] [ 2242.173119] submit_notify+0x8f/0xc0 [i915] [ 2242.173121] __i915_sw_fence_complete+0x61/0x420 [i915] [ 2242.173124] ? _raw_spin_unlock_irqrestore+0x39/0x40 [ 2242.173137] i915_sw_fence_complete+0x58/0x80 [i915] [ 2242.173140] i915_sw_fence_commit+0x16/0x20 [i915] Closes: https://gitlab.freedesktop.org/drm/intel/issues/1318 Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310101720.9944-1-chris@chris-wilson.co.uk
2020-03-10Merge tag 'gvt-next-2020-03-10' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi
drm-intel-next-queued gvt-next-2020-03-10 - Fix CFL dmabuf display after vfio edid enabling (Tina) - Clean up scan non-priv batch debugfs entry (Chris) - Use intel engines initialized in gvt, cleanup previous ring id (Chris) - Use intel_gt instead (Chris) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310081928.GG28483@zhen-hp.sh.intel.com
generated by cgit (git 2.34.1) at 2025-09-12 21:56:52 +0000