- Mar 14, 2025
-
-
Dave Airlie authored
-
Dave Airlie authored
# Conflicts: # drivers/gpu/drm/xe/xe_pci.c
-
Dave Airlie authored
-
Dave Airlie authored
# Conflicts: # drivers/gpu/drm/xe/xe_rtp.c
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
Dave Airlie authored
-
- Mar 13, 2025
-
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-6.14-2025-03-12' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.14-2025-03-12: amdgpu: - GC 12.x DCC fix - DC DCE 6.x fix - Hibernation fix - HPD fix - Backlight fixes - Color depth fix - UAF fix in hdcp_work - VCE 2.x fix - GC 12.x PTE fix amdkfd: - Queue eviction fix Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250312190931.216506-1-alexander.deucher@amd.com
-
Maíra Canal authoredSimilar to commit e4b5ccd3 ("drm/v3d: Ensure job pointer is set to NULL after job completion"), ensure the job pointer is set to `NULL` when a job's fence has an error. Failing to do so can trigger kernel warnings in specific scenarios, such as: 1. v3d_csd_job_run() assigns `v3d->csd_job = job` 2. CSD job exceeds hang limit, causing a timeout → v3d_gpu_reset_for_timeout() 3. GPU reset 4. drm_sched_resubmit_jobs() sets the job's fence to `-ECANCELED`. 5. v3d_csd_job_run() detects the fence error and returns NULL, not submitting the job to the GPU 6. User-space runs `modprobe -r v3d` 7. v3d_gem_destroy() v3d_gem_destroy() triggers a warning indicating that the CSD job never ended, as we didn't set `v3d->csd_job` to NULL after the timeout. The same can also happen to BIN, RENDER, and TFU jobs. Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Signed-off-by:
Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250313-v3d-gpu-reset-fixes-v4-2-c1e780d8e096@igalia.com
-
Maíra Canal authored
The V3D driver still relies on `drm_sched_increase_karma()` and `drm_sched_resubmit_jobs()` for resubmissions when a timeout occurs. The function `drm_sched_increase_karma()` marks the job as guilty, while `drm_sched_resubmit_jobs()` sets an error (-ECANCELED) in the DMA fence of that guilty job. Because of this, we must check whether the job’s DMA fence has been flagged with an error before executing the job. Otherwise, the same guilty job may be resubmitted indefinitely, causing repeated GPU resets. This patch adds a check for an error on the job's fence to prevent running a guilty job that was previously flagged when the GPU timed out. Note that the CPU and CACHE_CLEAN queues do not require this check, as their jobs are executed synchronously once the DRM scheduler starts them. Cc: stable@vger.kernel.org Fixes: d223f98f ("drm/v3d: Add support for compute shader dispatch.") Fixes: 1584f16c ("drm/v3d: Add support for submitting jobs to the TFU.") Reviewed-by:
-
If devm_add_action_or_reset() isn't successful, xe_eu_stall_fini() is invoked. So, unsuccessful return from devm_add_action_or_reset() shouldn't dereference gt->eu_stall as xe_eu_stall_fini() already frees it. Fix this issue. Fixes: 9a0b11d4 ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling") Signed-off-by:
Harish Chegondi <harish.chegondi@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Replace the 'unsigned int i' footguns with plain old signed int. Avoids accidents if/when someone decides they need to iterate backwards. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250228211454.8138-9-ville.syrjala@linux.intel.com Reviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Bunch of variables are only needed inside loops and whatnot. Move them to a tighter scope to make the code less confusing. Signed-off-by:
-
Ville Syrjälä authored
Rename the 'new_crtc' variable to just 'crtc' in drm_client_firmware_config(). We don't call any of the other stuff in here new or old so this feels out of place. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
crtc->mode is legacy junk and shouldn't really be used with atomic drivers. Most (all?) atomic drivers do end up still calling drm_atomic_helper_update_legacy_modeset_state() at some point, so crtc->mode does still get populated, and this does work for now. But now that the modes[] lifetime issues have been sorted out we can just switch over to the proper crtc->state->mode. v2: Rebase Signed-off-by:
-
Ville Syrjälä authored
drm_client_firmware_config() is currently picking up the current mode of the crtc via the legacy crtc->mode, which is not supposed to be used by atomic drivers at all. We can't simply switch over to the proper crtc->state->mode because we drop the crtc->mutex (which protects crtc->state) before the mode gets used. The most straightforward solution to extend the lifetime of modes[] seem to be to make full copies of the modes. And with this we can undo also commit 3eadd887 ("drm/client:Fully protect modes[] with dev->mode_config.mutex") as the lifetime of modes[] no longer has anything to do with that lock. v2: Don't try to copy NULL modes v3: Keep storing pointers and use drm_mode_{duplicate,destroy}() Signed-off-by:
-
Ville Syrjälä authored
Get rid of all the redundant debugs and just wait until the end to print which mode (and of which type) we picked. Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
Ville Syrjälä authored
Use the array notation rather that the pointer notation for function arguments. This makes it clear to the reader that we are in fact dealing with an array rather than a single pointer. Functionally the two are equivalent. Reviewed-by:
-
Ville Syrjälä authored
The modes used by the client code live on the connectors' mode lists, which are not owned by the client code, and thus it has no business modifying the modes. Mark the modes const to make that fact abundantly clear. v2: Fix up the kunit test Reviewed-by:
-
Gustavo Sousa authored
Bandwidth parameters for Xe3_LPD have been updated with respect to previous display releases. Encode them into xe3lpd_sa_info and use that new struct. Bspec: 68859 Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311-xe3lpd-bandwidth-update-v5-3-a95a9d90ad71@intel.com Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com>
-
Gustavo Sousa authored
We already have internal interface for intel_bw.c converted to use intel_display. Now convert the external interface as well. Reviewed-by:
-
Gustavo Sousa authored
Update intel_bw.c internally use intel_display. Conversion of the public interface will come as a follow-up. v2: - Prefer intel_uncore_read() for MCHBAR registers. (Ville) v3: - Remove the unnecessary inclusion of intel_de.h after changes from v2. (Ville) Reviewed-by: -
Ankit Nautiyal authored
MSA Ignore Timing PAR enable is set in the DP sink when we enable variable refresh rate. Currently for link training we depend on flipline to decide whether we want to ignore the msa timings. With fixed refresh rate we will still fill the flipline in all cases whether panel supports VRR or not. Change the condition for link training to ignore the msa timings if vrr.in_range. v2: Add more documentation and a #TODO for readout of vrr.in_range. (Ville) Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Ankit Nautiyal authored
Currently we always compute the timings as if vrr is enabled. With this approach the state checker becomes complicated when we introduce fixed refresh rate mode with vrr timing generator. To avoid the complications, instead of always computing vrr timings, we compute vrr timings based on uapi.vrr_enable knob. So when the knob is disabled we always compute vmin=flipline=vmax. v2: Use actual timings without any adjustments while preparing for fixed timings in compute_config. (Ville) v3: Avoid setting fixed timings if !vrr_possible(). v4: Move vmin adjustement after all other timings are complete. (Ville) Signed-off-by:
-
Ankit Nautiyal authored
To have fixed refresh rate with VRR timing generator the guardband/pipeline full can't be programmed on the fly. So we need to ensure that the values satisfy both the fixed and variable refresh rates. Since we compute these value based on vmin, lets set the vmin to crtc_vtotal for both fixed and variable timings instead of using the current refresh rate based approach. This way the guardband remains sufficient for both cases. v2: Avoid using vblank delay while computing vtotal, as this comes into the picture later. (Ville) Signed-off-by:
-
Ankit Nautiyal authored
Since CMRR is now disabled, use the flag vrr.enable to tracks if vrr timing generator is used with variable timings. Avoid setting vrr.enable for CMRR and adjust readout to not set vrr.enable when vmax == vmin == flipline (fixed refresh rate timing). v2: Use intel_vrr_vmin_flipline() to account for adjustments required for icl/tgl. (Ville) v3: Add a #TODO for handling I915_MODE_FLAG_VRR better for CMRR. (Ville) Signed-off-by:
-
Ankit Nautiyal authored
Switching between variable and fixed timings is possible as for that we just need to flip between VRR timings. However for CMRR along with the timings, few other bits also need to be changed on the fly, which might cause issues. So disable CMRR for now, till we have variable and fixed timings sorted out. Signed-off-by:
-
Ankit Nautiyal authored
Separate out functions for computing cmrr and vrr timings. Signed-off-by:
-
Ankit Nautiyal authored
Make helpers to compute vmin and vmax. v2: Make the adjusted mode const (Ville) Use reverse xmas tree order of declarations. (Ville) Signed-off-by:
-
Ankit Nautiyal authored
The comment about fixed average vtotal is incorrect. Remove it. Signed-off-by:
-
Ankit Nautiyal authored
Currently, during the computation of global watermarks, the latency for each scaler user is calculated to compute the DSC prefill latency. At this point, the number of scaler users can exceed the number of supported scalers, which is checked later in intel_atomic_setup_scalers(). This can cause issues when the number of scaler users exceeds the number of supported scalers. While checking for DSC prefill, ensure that the number of scaler users does not exceed the number of supported scalers. Closes: drm/xe/kernel#4341 Fixes: a9b14af9 ("drm/i915/dsc: Check if vblank is sufficient for dsc prefill") Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227034106.1638203-1-ankit.k.nautiyal@intel.com
-
Francois Dugast authored
Add a new entry in stats to for svm page faults. If CONFIG_DEBUG_FS is enabled, the count can be viewed with per GT stat debugfs file. This is similar to what is already in place for vma page faults. Example output: cat /sys/kernel/debug/dri/0/gt0/stats svm_pagefault_count: 6 tlb_inval_count: 78 vma_pagefault_count: 0 vma_pagefault_kb: 0 v2: Fix build with CONFIG_DRM_GPUSVM disabled v3: Update argument in kernel doc Reviewed-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250312092749.164232-1-francois.dugast@intel.com Signed-off-by:
Francois Dugast <francois.dugast@intel.com>
-
qianyi liu authored
The last_scheduled fence leaks when an entity is being killed and adding the cleanup callback fails. Decrement the reference count of prev when dma_fence_add_callback() fails, ensuring proper balance. Cc: stable@vger.kernel.org # v6.2+ [phasta: add git tag info for stable kernel] Fixes: 2fdb8a8f ("drm/scheduler: rework entity flush, kill and fini") Signed-off-by:
qianyi liu <liuqianyi125@gmail.com> Signed-off-by:
Philipp Stanner <phasta@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250311060251.4041101-1-liuqianyi125@gmail.com
-
Plane->min_alignment returns an unsigned int so lets use that in the whole relevant call chain. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com>
-
