- 02 Aug, 2019 2 commits
-
-
Daniel Vetter authored
Merge tag 'drm-intel-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes drm/i915 fixes for v5.3-rc3: - GVT fixes - Fix TBT aux powerwell - Fix PSR2 training pattern duration - Fix memory leak in runtime wakeref tracking - Fix ICL memory bandwidth issue preventing planes from being enabled - Fix OA mux configuration delays for accurate performance data - Fix VLV/CHV DP audio cdclk frequency requirements - Fix register whitelisting to fix a number of GL & Vulkan CTS tests - Fix ICL perf register offsets - Fix Gen11 Sampler Prefetch workaround, impacting dEQP tests - Fix various gen2 tracepoints - A number of GEM locking fixes addressing lockdep issues - Fix idle engine reset, recover only active engines - Fix incorrect MCR programming Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87d0hnncgo.fsf@intel.com
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
- Fix the dma_sync calls applied last week (Rob) - Fix mdp5 dsi command mode (Brian) - Squash fall through warnings (Jordan) - Don't add disabled gpu nodes to the of device list (Jeffrey) Cc: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Rob Clark <robdclark@chromium.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> # gpg: Signature made Fri 02 Aug 2019 05:54:27 AM AEST # gpg: using RSA key 96F70DFDA84A070A # gpg: Can't check signature: public key not found From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190801200439.GV104440@art_vandelay
-
- 01 Aug, 2019 8 commits
-
-
Lyude Paul authored
Looks like a regression got introduced into nv50_mstc_atomic_check() that somehow didn't get found until now. If userspace changes crtc_state->active to false but leaves the CRTC enabled, we end up calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in asyh->dp.pbn. However, if the display is inactive we end up calculating a PBN of 0, which inadvertently causes us to have an allocation of 0. >From there, if userspace then disables the CRTC afterwards we end up accidentally attempting to free the VCPI twice: WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] Call Trace: drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper] ? drm_atomic_check_only+0x43/0x780 [drm] drm_atomic_helper_check+0x15/0x90 [drm_kms_helper] nv50_disp_atomic_check+0x83/0x1d0 [nouveau] drm_atomic_check_only+0x54d/0x780 [drm] ? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm] drm_atomic_commit+0x13/0x50 [drm] drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper] drm_mode_setcrtc+0x194/0x6a0 [drm] ? vprintk_emit+0x16a/0x230 ? drm_ioctl+0x163/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0xaa/0xf0 [drm] drm_ioctl+0x208/0x390 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] nouveau_drm_ioctl+0x63/0xb0 [nouveau] do_vfs_ioctl+0x405/0x660 ? recalc_sigpending+0x17/0x50 ? _copy_from_user+0x37/0x60 ksys_ioctl+0x5e/0x90 ? exit_to_usermode_loop+0x92/0xe0 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x59/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] ---[ end trace 4c395c0c51b1f88d ]--- [drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for [MST PORT:00000000e288eb7d] found in mst state 000000008e642070 So, fix this by doing what we probably should have done from the start: only call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so that VCPI allocations remain for as long as the CRTC is enabled. Signed-off-by:
Lyude Paul <lyude@redhat.com> Fixes: 232c9eec ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <stable@vger.kernel.org> # v5.1+ Acked-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
drm-fixes-5.3-2019-07-31: amdgpu: - Fix temperature granularity for navi - Fix stable pstate setting for navi - Fix VCN DPM enablement on navi - Fix error handling on CS ioctl when processing dependencies - Fix possible information leak in debugfs amdkfd: - fix memory alignment for VegaM Signed-off-by:
-
Jeffrey Hugo authored
add_gpu_components() adds found GPU nodes from the DT to the match list, regardless of the status of the nodes. This is a problem, because if the nodes are disabled, they should not be on the match list because they will not be matched. This prevents display from initing if a GPU node is defined, but it's status is disabled. Fix this by checking the node's status before adding it to the match list. Fixes: dc3ea265 (drm/msm: Drop the gpu binding) Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190626180015.45242-1-jeffrey.l.hugo@gmail.com
-
Jordan Crouse authored
Explicitly mark intentional fall throughs in switch statements to keep -Wimplicit-fallthrough from complaining. Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Brian Masney authored
The mdp5 drm/kms driver currently does not work on command-mode DSI panels due to 'vblank wait timed out' errors. This causes a latency of seconds, or tens of seconds in some cases, before content is shown on the panel. This hardware does not have the something that we can use as a frame counter available when running in command mode, so we need to fall back to using timestamps by setting the max_vblank_count to zero. This can be done on a per-CRTC basis, so the convert mdp5 to use drm_crtc_set_max_vblank_count(). This change was tested on a LG Nexus 5 (hammerhead) phone. Suggested-by:
Brian Masney <masneyb@onstation.org> Signed-off-by:
-
Chris Wilson authored
If we issue a reset to a currently idle engine, leave it idle afterwards. This is useful to excise a linkage between reset and the shrinker. When waking the engine, we need to pin the default context image which we use for overwriting a guilty context -- if the engine is idle we do not need this pinned image! However, this pinning means that waking the engine acquires the FS_RECLAIM, and so may trigger the shrinker. The shrinker itself may need to wait upon the GPU to unbind and object and so may require services of reset; ergo we should avoid the engine wake up path. The danger in skipping the recovery for idle engines is that we leave the engine with no context defined, which may interfere with the operation of the power context on some older platforms. In practice, we should only be resetting an active GPU but it something to look out for on Ironlake (if memory serves). Fixes: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-2-chris@chris-wilson.co.uk (cherry picked from commit 18398904) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Chris Wilson authored
For use in the next patch, we want to acquire a wakeref without having to wake the device up -- i.e. only acquire the engine wakeref if the engine is already active. Signed-off-by:
-
Chris Wilson authored
Since the reset path wants to recover the engines itself, it only wants to reinitialise the hardware using i915_gem_init_hw(). Pull the call to intel_engines_resume() to the module init/resume path so we can avoid it during reset. Fixes: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
-
- 31 Jul, 2019 14 commits
-
-
Rob Clark authored
[subject was: drm/msm: shake fist angrily at dma-mapping] So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but it falls appart with dma direct ops. The problem is that, depending on display generation, we can have either set of dma ops (mdp4 and dpu have iommu wired to mdss node, which maps to toplevel drm device, but mdp5 has iommu wired up to the mdp sub-node within mdss). Fixes this splat on mdp5 devices: Unable to handle kernel paging request at virtual address ffffffff80000000 Mem abort info: ESR = 0x96000144 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000144 CM = 1, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000810e4000 [ffffffff80000000] pgd=0000000000000000 Internal error: Oops: 96000144 [#1] SMP Modules linked in: btqcomsmd btqca bluetooth cfg80211 ecdh_generic ecc rfkill libarc4 panel_simple msm wcnss_ctrl qrtr_smd drm_kms_helper venus_enc venus_dec videobuf2_dma_sg videobuf2_memops drm venus_core ipv6 qrtr qcom_wcnss_pil v4l2_mem2mem qcom_sysmon videobuf2_v4l2 qmi_helpers videobuf2_common crct10dif_ce mdt_loader qcom_common videodev qcom_glink_smem remoteproc bmc150_accel_i2c bmc150_magn_i2c bmc150_accel_core bmc150_magn snd_soc_lpass_apq8016 snd_soc_msm8916_analog mms114 mc nf_defrag_ipv6 snd_soc_lpass_cpu snd_soc_apq8016_sbc industrialio_triggered_buffer kfifo_buf snd_soc_lpass_platform snd_soc_msm8916_digital drm_panel_orientation_quirks CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted 5.3.0-rc2 #1 Hardware name: Samsung Galaxy A5U (EUR) (DT) Workqueue: events deferred_probe_work_func pstate: 80000005 (Nzcv daif -PAN -UAO) pc : __clean_dcache_area_poc+0x20/0x38 lr : arch_sync_dma_for_device+0x28/0x30 sp : ffff0000115736a0 x29: ffff0000115736a0 x28: 0000000000000001 x27: ffff800074830800 x26: ffff000011478000 x25: 0000000000000000 x24: 0000000000000001 x23: ffff000011478a98 x22: ffff800009fd1c10 x21: 0000000000000001 x20: ffff800075ad0a00 x19: 0000000000000000 x18: ffff0000112b2000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000fffffff0 x14: ffff000011455d70 x13: 0000000000000000 x12: 0000000000000028 x11: 0000000000000001 x10: ffff00001106c000 x9 : ffff7e0001d6b380 x8 : 0000000000001000 x7 : ffff7e0001d6b380 x6 : ffff7e0001d6b382 x5 : 0000000000000000 x4 : 0000000000001000 x3 : 000000000000003f x2 : 0000000000000040 x1 : ffffffff80001000 x0 : ffffffff80000000 Call trace: __clean_dcache_area_poc+0x20/0x38 dma_direct_sync_sg_for_device+0xb8/0xe8 get_pages+0x22c/0x250 [msm] msm_gem_get_and_pin_iova+0xdc/0x168 [msm] ... Fixes the combination of two patches: Fixes: 0036bc73 (drm/msm: stop abusing dma_map/unmap for cache) Fixes: 449fa54d (dma-direct: correct the physical addr in dma_direct_sync_sg_for_cpu/device) Tested-by:Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
Rob Clark <robdclark@chromium.org> [seanpaul changed subject to something more desriptive] Signed-off-by:
-
Evan Quan authored
VCN should be used for Vega20 later ASICs while UVD and VCE are for previous ASICs. Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
Kenneth Feng <kenneth.feng@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Evan Quan authored
No VCN DPM bit check as that's different from VCN PG. Also no extra check for possible double enablement/disablement as that's already done by VCN. v2: check return value of smu_feature_set_enabled Signed-off-by:
-
Evan Quan authored
Commonly used for VCN powergate status retrieval for SW SMU. Signed-off-by:
-
Evan Quan authored
Enable VCN powergate status report on Raven. Signed-off-by:
-
Evan Quan authored
VCN is widely used in new ASICs and different from tranditional UVD and VCE. Signed-off-by:
-
Wang Xiayang authored
Coccinelle reports a path that the array "data" is never initialized. The path skips the checks in the conditional branches when either of callback functions, read_wave_vgprs and read_wave_sgprs, is not registered. Later, the uninitialized "data" array is read in the while-loop below and passed to put_user(). Fix the path by allocating the array with kcalloc(). The patch is simplier than adding a fall-back branch that explicitly calls memset(data, 0, ...). Also it does not need the multiplication 1024*sizeof(*data) as the size parameter for memset() though there is no risk of integer overflow. Signed-off-by:
Wang Xiayang <xywang.sjtu@sjtu.edu.cn> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Christian König authored
We always need to drop the ctx reference and should check for errors first and then dereference the fence pointer. Signed-off-by:
-
Evan Quan authored
Move SMU irq handler register to sw_init as that's totally software related. Otherwise, it will prevent SMU reset working. Signed-off-by:
-
Evan Quan authored
DPM state relates are not supported on the new SW SMU ASICs. But still it's not OK to trigger null pointer dereference on accessing them. Signed-off-by:
-
Alex Deucher authored
The PCI revision id determines the sku. Reviewed-by:
Feifei Xu <Feifei.Xu@amd.com> Reviewed-by:
Kevin Wang <kevin1.wang@amd.com> Reviewed-by:
-
Kevin Wang authored
in this patch, drm/amd/powerplay: add callback function of get_thermal_temperature_range the driver missed temperature granularity change on other temperature. Signed-off-by:
-
Kevin Wang authored
1. the thermal temperature is asic related data, move the code logic to xxx_ppt.c. 2. replace data structure PP_TemperatureRange with smu_temperature_range. 3. change temperature uint from temp*1000 to temp (temperature uint). Signed-off-by:
Huang Rui <ray.huang@amd.com> Signed-off-by:
-
Kent Russell authored
This was missed during the addition of VegaM support Reviewed-by:
Kent Russell <kent.russell@amd.com> Signed-off-by:
-
- 30 Jul, 2019 8 commits
-
-
https://github.com/intel/gvt-linuxJani Nikula authored
gvt-fixes-2019-07-30 - Guard against potential ggtt access error (Xiong) - Fix includecheck (Zhenyu) - Fix cache entry for guest page mapping found by 2M ppgtt guest (Xiaolin) - Fix runtime pm warning (Xiaolin) - Fix shadow mm settlement for Windows guest reset failure (Colin) Signed-off-by:
-
Colin Xu authored
Windows guest can't run after force-TDR with host log: ... gvt: vgpu 1: workload shadow ppgtt isn't ready gvt: vgpu 1: fail to dispatch workload, skip ... The error is raised by set_context_ppgtt_from_shadow(), when it checks and found the shadow_mm isn't marked as shadowed. In work thread before each submission, a shadow_mm is set to shadowed in: shadow_ppgtt_mm() <-intel_vgpu_pin_mm() <-prepare_workload() <-dispatch_workload() <-workload_thread() However checking whether or not shadow_mm is shadowed is prior to it: set_context_ppgtt_from_shadow() <-dispatch_workload() <-workload_thread() In normal case, create workload will check the existence of shadow_mm, if not it will create a new one and marked as shadowed. If already exist it will reuse the old one. Since shadow_mm is reused, checking of shadowed in set_context_ppgtt_from_shadow() actually always see the state set in creation, but not the state set in intel_vgpu_pin_mm(). When force-TDR, all engines are reset, since it's not dmlr level, all ppgtt_mm are invalidated but not destroyed. Invalidation will mark all reused shadow_mm as not shadowed but still keeps in ppgtt_mm_list_head. If workload submission phase those shadow_mm are reused with shadowed not set, then set_context_ppgtt_from_shadow() will report error. Pin for context after shadow_mm pinned and shadow pdps settled. v2: Move set_context_ppgtt_from_shadow() after prepare_workload(). (zhenyu) v3: Move set_context_ppgtt_from_shadow() after shadow pdps updated.(zhenyu) Fixes: 4f15665c ("drm/i915: Add ppgtt to GVT GEM context") Cc: stable@vger.kernel.org Signed-off-by:
Colin Xu <colin.xu@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com>
-
Xiaolin Zhang authored
in workload_thread, it should grab runtime pm wakelock and later uncore forcewake get will check rpm wakelock held successfully. otherwise, sometimes, rpm wakelock not hold and print call trace below: Call Trace: intel_uncore_forcewake_get+0x15/0x20 [i915] workload_thread+0x5f9/0x16f0 [i915] ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 ? __switch_to_asm+0x34/0x70 ? __switch_to+0x85/0x3f0 ? __switch_to_asm+0x40/0x70 ? do_wait_intr_irq+0x90/0x90 kthread+0x121/0x140 ? intel_vgpu_clean_workloads+0x100/0x100 [i915] ? kthread_park+0x90/0x90 ret_from_fork+0x35/0x40 --[ end trace 86525f742a02e12c ]-- v2: adapted to use rpm structure. Fixes: 251d46b0 ("drm/i915/gvt: Pin the per-engine GVT shadow contexts") Reviewed-by:
Xiaolin Zhang <xiaolin.zhang@intel.com> Signed-off-by:
-
Xiaolin Zhang authored
GPU hang observed during the guest OCL conformance test which is caused by THP GTT feature used durning the test. It was observed the same GFN with different size (4K and 2M) requested from the guest in GVT. So during the guest page dma map stage, it is required to unmap first with orginal size and then remap again with requested size. Fixes: b901b252 ("drm/i915/gvt: Add 2M huge gtt support") Cc: stable@vger.kernel.org Reviewed-by:
-
Xiong Zhang authored
Workload contains RB and WA_CTX which are in ggtt space, if they aren't in valid ggtt space, the workload shouldn't be shadowed and scanned. So checking them earlier to avoid shadow them. Reviewed-by:
Xiong Zhang <xiong.y.zhang@intel.com> Signed-off-by:
-
Xiong Zhang authored
Use vgpu_gmadr_is_valid() directly instead. Reviewed-by:
-
Xiong Zhang authored
Instead of silently return virtual ggtt entries that guest is allowed to access, this patch add extra range check. If guest read out of range, it will print a warning and return 0. If guest write out of range, the write will be dropped without any message. Reviewed-by:
-
Zhenyu Wang authored
This removes duplicate include of trace.h. Found by Hariprasad Kelam with includecheck. Reported-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Reviewed-by:
Yan Zhao <yan.y.zhao@intel.com> Signed-off-by:
-
- 29 Jul, 2019 8 commits
-
-
Imre Deak authored
Fix the mapping from a TBT AUX power well index to the DP_AUX_CH_CTL register. Fixes: c7375d95 ("drm/i915: Configure AUX_CH_CTL when enabling the AUX power domain") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190628143635.22066-7-imre.deak@intel.com (cherry picked from commit 29ae36ab) Signed-off-by:
-
Tvrtko Ursulin authored
fls returns bit positions starting from one for the lsb and the MCR register expects zero based (sub)slice addressing. Incorrent MCR programming can have the effect of directing MMIO reads of registers in the 0xb100-0xb3ff range to invalid subslice returning zeroes instead of actual content. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 1e40d4ae ("drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads") Reviewed-by:
-
Dhinakaran Pandiyan authored
A single 32-bit PSR2 training pattern field follows the sixteen element array of PSR table entries in the VBT spec. But, we incorrectly define this PSR2 field for each of the PSR table entries. As a result, the PSR1 training pattern duration for any panel_type != 0 will be parsed incorrectly. Secondly, PSR2 training pattern durations for VBTs with bdb version >= 226 will also be wrong. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: stable@vger.kernel.org Cc: stable@vger.kernel.org #v5.2 Fixes: 88a0d960 ("drm/i915/vbt: Parse and use the new field with PSR2 TP2/3 wakeup time") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111088 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204183Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by:
François Guerraz <kubrick@fgv6.net> Signed-off-by:
-
Ville Syrjälä authored
On VLV/CHV there is some kind of linkage between the cdclk frequency and the DP link frequency. The spec says: "For DP audio configuration, cdclk frequency shall be set to meet the following requirements: DP Link Frequency(MHz) | Cdclk frequency(MHz) 270 | 320 or higher 162 | 200 or higher" I suspect that would more accurately be expressed as "cdclk >= DP link clock", and in any case we can express it like that in the code because of the limited set of cdclk (200, 266, 320, 400 MHz) and link frequencies (162 and 270 MHz) we support. Without this we can end up in a situation where the cdclk is too low and enabling DP audio will kill the pipe. Happens eg. with 2560x1440 modes where the 266MHz cdclk is sufficient to pump the pixels (241.5 MHz dotclock) but is too low for the DP audio due to the link frequency being 270 MHz. v2: Spell out the cdclk and link frequencies we actually support Cc: stable@vger.kernel.org Tested-by:
Stefan Gottwald <gottwald@igel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111149Signed-off-by:
-
Chris Wilson authored
We cannot let the request be retired and freed while we are trying to dump it during error capture. It is not sufficient just to grab a reference to the request, as during retirement we may free the ring which we are also dumping. So take the engine lock to prevent retiring and freeing of the request. Reported-by:
Alex Shumsky <alexthreed@gmail.com> Fixes: 83c31783 ("drm/i915: Dump the ringbuffer of the active request for debugging") Signed-off-by:
-
Lionel Landwerlin authored
This was dropped from the original patch series, we weren't sure whether it was needed at the time. More recent tests show it's definitely needed to have acurate performance data. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 19f81df2 ("drm/i915/perf: Add OA unit support for Gen 8+") Acked-by:
-
Lionel Landwerlin authored
The i915 perf stream has its own file descriptor and is tied to reference of the driver. We haven't taken care of keep the driver alive. Signed-off-by:
-
Chris Wilson authored
set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: 6dcc693b ("ext4: warn when page is dirtied without buffers") Signed-off-by:
-
