Currently we compute the min_cdclk for each pipe during
intel_cdclk_atomic_check(). But that is too late for the
pipe prefill vs. vblank length checks (done during
intel_compute_global_watermarks).
We can't just reorder these things due to other dependencies,
so instead pull only the per-crtc minimum cdclk calculation
ahead. We should have enough information for that as soon
as we've computed the min cdclk for the planes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-8-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reorganize the IPS CDCLK handling such that the computed CDCLK
frequency will always satisfy the IPS requirements. The only
exceptional case is if IPS would push the CDCLK above the platform
max, but in that case we can simply disable IPS.
To make this 100% race free we must move the enable_ips modparam
check out from the min CDCLK computation path so that there is no
chance of hsw_min_cdclk() and hsw_ips_compute_config() observing
a different enable_ips value during the same commit.
This allows us to completely remove the cdclk_state stuff
from the IPS code. We only ever have to compare the IPS min
CDCLK against the platform max CDCLK. Thus we eliminate any ordering
requirements between intel_cdclk_atomic_check() and
hsw_ips_compute_config().
Additionally we reduce the three copies of the code doing the
95% calculation into just one.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-5-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
intel_bw_crtc_min_cdclk() (aka. the thing that deals with what bspec
calls "Maximum Pipe Read Bandwidth") doesn't really have anything to
do with the rest of intel_bw.c (which is all about SAGV/QGV and
memory bandwidth). Move it into intel_crtc.c (for the lack of a better
place).
And I don't really want to call intel_bw.c functions from intel_crtc.c,
so move out intel_bw_crtc_data_rate() as well. And when we move that we
pretty much have to move intel_bw_crtc_num_active_planes() as well since
the two are meant to be used as a pair (they both implement the same
"ignore the cursor" logic).
And in an effort to keep the namespaces at least semi-sensible we
flip the intel_bw_crtc_ prefix into intel_crtc_bw_.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251013201236.30084-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
amd-drm-fixes-6.18-2025-10-16:
amdgpu:
- Backlight fix
- SI fixes
- CIK fix
- Make CE support debug only
- IP discovery fix
- Ring reset fixes
- GPUVM fault memory barrier fix
- Drop unused structures in amdgpu_drm.h
- JPEG debugfs fix
- VRAM handling fixes for GPUs without VRAM
- GC 12 MES fixes
amdkfd:
- MES fix
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20251016132224.2534946-1-alexander.deucher@amd.com
In dw_hdmi_rk3228_setup_hpd(), the SCLIN mask incorrectly references
the RK3328 variant. This change updates it to the RK3228-specific mask
RK3228_HDMI_SCLIN_MSK using FIELD_PREP_WM16, ensuring proper HPD and
I2C pin configuration for RK3228.
Change: RK3328_HDMI_SCLIN_MSK -> RK3228_HDMI_SCLIN_MSK
Fixes: 63df37f3fc ("drm/rockchip: dw_hdmi: switch to FIELD_PREP_WM16* macros")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20251010173143.72733-1-alok.a.tiwari@oracle.com
Add a new helper thingy to deal with the pipe prefill latency.
We get three potentially useful thigns out of this:
- skl_prefill_vblank_too_short() used for checking the
actual vblank/guardband length
- skl_prefill_min_guardband() to calculate a suitable guardband
size based on some worst case scaling/etc. estimates
- skl_prefill_min_cdclk() used to calculate a minimum cdclk
frequency required for very small vblank lengths (in case the
otherwise computed minimum cdclk doesn't result in fast enough
prefill).
The internal arithmetic is done terms of scanlines using .16
binary fixed point representation.
v2: Add the missing <<16 for framestart_delay
Drop the cdclk_state stuff in favor of crtc_state->min_cdclk
Rename to skl_prefill since this is skl+ only
Use intel_crtc_vblank_length() instead of hand rolling it
memset(0) in prefill_init()
Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-9-ville.syrjala@linux.intel.com
Add helpers to compute the required prefill line count and
adjustment factors for the scalers.
The "1st" variants hand out numbers for the first scaler stage
in the pipeline (pipe scaler if no plane scalers are enabled,
or the max from all the plane scaler). The "2nd" variants deal
with second scaler stage (pipe scaler when plane scaling is also
enabled, otherwise there is no second stage).
The _worst() variants give out worst case estimates, meant for
guardband sizing. The other variants are meant for the actual
vblank/guardband length check vs. prefill+pkgc/sagv latency.
The returned numbers are in .16 binary fixed point.
TODO: pretty rough, should check the actual scaler max scaling
factors instead of just assuming 3x everywhere
TODO: Reorder scaler assignment vs. vblank length check to get
the actual scale factors
v2: Drop debugs
v3: Ignore scale factors for the vblank length check for now
since we don't have the scalers assigned yet
Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251015125645.11230-1-ville.syrjala@linux.intel.com
Add helpers to compute the CDCLKl adjustment factor for prefill
calculations. The adjustment factor is always <= 1.0. That is,
a faster CDCLK speeds up the pipe prefill.
intel_cdclk_prefill_adjustment_worst() gives out a worst case estimate,
meant to be used during guardband sizing. We can actually do better
than 1.0 here because the absolute minimum CDCLK is limited by the
dotclock. This will still allow planes, pfit, etc. to be changed any
which way without having to resize the guardband yet again.
intel_cdclk_prefill_adjustment() is supposed to give a more accurate
value based on the current min cdclk for the pipe, but currently that
is not yet available when this gets called. So for now use the same
worst case estimate here.
The returned numbers are in .16 binary fixed point.
TODO: the intel_cdclk_prefill_adjustment_worst() approach here
can result in guardband changes for DRRS. But I'm thinking
that is fine since M/N changes will always happen on the
legacy timing generator so guardband doesn't actually matter.
May need to think about this a bit more though...
v2: Use the worst case estimate always for now
Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-4-ville.syrjala@linux.intel.com
Reject modes whose linetime exceeds 64 usec.
First reason being that WM_LINETIME is limited to (nearly) 64 usec.
Additionally knowing the linetime is bounded will help with
determining whether overflows may be a concern during various
calculations.
I decided to round up, and accept the linetime==64 case. We use
various rounding directions for this in other parts of the code,
so I feel this provides the most consistent result all around.
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20251014191808.12326-3-ville.syrjala@linux.intel.com
Replace all dev_err(), dev_warn(), dev_info() and DRM_ERROR/WARN/INFO()
calls in drivers/gpu/drm/arm/display/komeda/komeda_crtc.c with the
corresponding drm_err(), drm_warn(), and drm_info() helpers.
The new drm_*() logging functions take a struct drm_device * as the
first argument. This allows the DRM core to prefix log messages with
the specific DRM device name and instance, which is essential for
distinguishing logs when multiple GPUs or display controllers are present.
This change aligns komeda with the DRM TODO item: "Convert logging to
drm_* functions with drm_device parameter".
Signed-off-by: Rahul Kumar <rk0006818@gmail.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://lore.kernel.org/r/20250926093008.1949131-1-rk0006818@gmail.com
As we move towards using a shorter, optimized guardband, we need to adjust
how the delayed vblank start is computed.
Adjust the crtc_vblank_start using Vmin Vtotal - guardband only when
intel_vrr_always_use_vrr_tg() is true. Also update the
pipe_mode->crtc_vblank_start which is derived from
adjusted_mode->crtc_vblank_start in intel_crtc_compute_pipe_mode().
To maintain consistency between the computed and readout paths, update
the readout logic in intel_vrr_get_config() to overwrite crtc_vblank_start
with the same value (vtotal - guardband) on platforms with always-on
VRR TG.
This also paves way for guardband optimization, by handling the movement of
the crtc_vblank_start for platforms that have VRR TG always active.
v2: Drop the helper and add the adjustment directly to
intel_vrr_compute_guardband(). (Ville)
v3: Use adjusted_mode.crtc_vtotal instead of vmin and include the readout
logic to keep the compute and readout paths in sync. (Ville)
v4: Also set pipe_mode->crtc_vblank_start as its derived from
adjusted_mode. (Ville)
v5: Add a comment about rationale behind updating
pipe_mode->crtc_vblank_start. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251016055415.2101347-10-ankit.k.nautiyal@intel.com
Currently, wake line latency checks rely on the vblank length,
which does not account for either the extra vblank delay for icl/tgl or for
the optimized guardband which will come into picture later at some point.
Validate whether the final vblank (with extra vblank delay) or guardband
is sufficient to support wake line latencies required by Panel Replay and
PSR2 selective update. Disable the PSR features if their wake requirements
cannot be accomodated.
v2: Add comments clarifying wake line checks and rationale for not
resetting SCL. (Jouni)
v3: Reset other psr flags based on features that are dropped. (Jouni)
v4: Update commit message.
v5: Remove early return and simplify the checking for wakelines. (Jouni)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251016055415.2101347-9-ankit.k.nautiyal@intel.com
Introduce intel_dp_compute_config_late() to handle late-stage
configuration checks for DP/eDP features. For now, it paves path for
psr_compute_config_late() to handle psr parameters that need to be
computed late.
Move the handling of psr_flag for Wa_18037818876 and setting of non-psr
pipes to intel_psr_compute_config_late() as these are the last things
to be configured for PSR features.
v2: Update dp_compute_config_late() to return int.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com> (#v1)
Link: https://lore.kernel.org/r/20251016055415.2101347-8-ankit.k.nautiyal@intel.com
Panel Replay and PSR2 selective update require sufficient vblank duration
to accommodate wake latencies. However, the current
wake_lines_fit_into_vblank() logic does not account for the minimum
Set Context Latency (SCL) lines.
Separate out _intel_psr_min_set_context_latency() to compute the minimum
SCL requirement based on platform and feature usage.
The alpm_config_valid() helper is updated to pass the necessary context for
determining whether Panel Replay or PSR2 selective update is enabled.
v2: While calling alpm_config_valid() for selective_update use false flag
instead of has_panel_replay. (Jouni)
v3: Correct ordering of the panel_replay, sel_update flags. (Jouni)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251016055415.2101347-6-ankit.k.nautiyal@intel.com
Currently crtc_vblank_start is assumed to be the vblank_start for the fixed
refresh rate case. That value can be different from the variable refresh
rate case whenever always_use_vrr_tg()==false. On icl/tgl it's always
different due to the extra vblank delay, and also on adl+ it could be
different if we were to use an optimized guardband.
So places where crtc_vblank_start is used to compute vblank length needs
change so as to account for cases where vrr is enabled. Specifically
with vrr.enable the effective vblank length is actually guardband.
Add a helper to get the correct vblank length for both vrr and fixed
refresh rate cases. Use this helper where vblank_start is used to
compute the vblank length.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251016055415.2101347-5-ankit.k.nautiyal@intel.com
The helper intel_vrr_compute_config_late() practically just computes the
guardband. Rename intel_vrr_compute_config_late() to
intel_vrr_compute_guardband().
Since we are going to compute the guardband and then move the
vblank_start for optmizing guardband move it to
intel_crtc_compute_config() which handles such changes.
v2: Move the function at the last after clocks, pipe_mode etc. are all
set. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20251016055415.2101347-4-ankit.k.nautiyal@intel.com
When adding dependencies with drm_sched_job_add_dependency(), that
function consumes the fence reference both on success and failure, so in
the latter case the dma_fence_put() on the error path (xarray failed to
expand) is a double free.
Interestingly this bug appears to have been present ever since
commit ebd5f74255 ("drm/sched: Add dependency tracking"), since the code
back then looked like this:
drm_sched_job_add_implicit_dependencies():
...
for (i = 0; i < fence_count; i++) {
ret = drm_sched_job_add_dependency(job, fences[i]);
if (ret)
break;
}
for (; i < fence_count; i++)
dma_fence_put(fences[i]);
Which means for the failing 'i' the dma_fence_put was already a double
free. Possibly there were no users at that time, or the test cases were
insufficient to hit it.
The bug was then only noticed and fixed after
commit 9c2ba26535 ("drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2")
landed, with its fixup of
commit 4eaf02d607 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies").
At that point it was a slightly different flavour of a double free, which
commit 963d0b3569 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")
noticed and attempted to fix.
But it only moved the double free from happening inside the
drm_sched_job_add_dependency(), when releasing the reference not yet
obtained, to the caller, when releasing the reference already released by
the former in the failure case.
As such it is not easy to identify the right target for the fixes tag so
lets keep it simple and just continue the chain.
While fixing we also improve the comment and explain the reason for taking
the reference and not dropping it.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Fixes: 963d0b3569 ("drm/scheduler: fix drm_sched_job_add_implicit_dependencies harder")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/dri-devel/aNFbXq8OeYl3QSdm@stanley.mountain/
Cc: Christian König <christian.koenig@amd.com>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Philipp Stanner <phasta@kernel.org>
Cc: Christian König <ckoenig.leichtzumerken@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Cc: stable@vger.kernel.org # v5.16+
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20251015084015.6273-1-tvrtko.ursulin@igalia.com
Separating the panic allocation from framebuffer allocation in commit
729c5f7ffa ("drm/{i915,xe}/panic: move framebuffer allocation where it
belongs") failed to deallocate the panic structure anywhere.
The fix is two-fold. First, free the panic structure in
intel_user_framebuffer_destroy() in the general case. Second, move the
panic allocation later to intel_framebuffer_init() to not leak the panic
structure in error paths (if any, now or later) between
intel_framebuffer_alloc() and intel_framebuffer_init().
v2: Rebase
Fixes: 729c5f7ffa ("drm/{i915,xe}/panic: move framebuffer allocation where it belongs")
Cc: Jocelyn Falempe <jfalempe@redhat.com>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Reported-by: Michał Grzelak <michal.grzelak@intel.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Michał Grzelak <michal.grzelak@intel.com> # v1
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20251015095135.2183415-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Make sure all the DP/HDMI/HDMI-FRL flags are programmed in all the modes
the PLL is configured.
Atm the DP mode flag is not programmed in case the PLL is configured for
HDMI mode for instance. This is incorrect after HW reset, since the DP
mode flag is asserted after reset, hence would need to be cleared for
HDMI, but also incorrect because of the same reason after configuring
the PLL to HDMI mode after it was used in DP mode (for instance on a
DP++ connector).
There is a similar issue with the HDMI-FRL flag, potentially remaining
set when configuring the PLL in DP mode.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20251015125446.3931198-6-mika.kahola@intel.com
Kunit's generate_params() was recently updated to take an additional
test context parameter. Xe's IP and platform parameter generators were
updated accordingly at the same time, but the new parameter was not
added to the functions' kerneldoc, resulting in the following warnings:
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:78 function parameter 'test' not described in 'xe_pci_fake_data_gen_params'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:254 function parameter 'test' not described in 'xe_pci_graphics_ip_gen_param'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:278 function parameter 'test' not described in 'xe_pci_media_ip_gen_param'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:302 function parameter 'test' not described in 'xe_pci_id_gen_param'
Warning: drivers/gpu/drm/xe/tests/xe_pci.c:390 function parameter 'test' not described in 'xe_pci_live_device_gen_param'
5 warnings as errors
Document the new parameter to eliminate the warnings and make CI happy.
Fixes: b9a214b5f6 ("kunit: Pass parameterized test context to generate_params()")
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://lore.kernel.org/r/20251013153014.2362879-2-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit 89e347f8a7)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
If the location madvise() is set to
DRM_XE_PREFERRED_LOC_DEFAULT_SYSTEM, the drm_pagemap in the
SVM gpu fault handler will be set to NULL. However there is nothing
that explicitly migrates the data to system if it is already present
in device memory.
In that case, set the device memory owner to NULL to ensure
data gets properly migrated to system on page-fault.
v2:
- Remove redundant dpagemap assignment (Himal Prasad Ghimiray)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v1
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Link: https://lore.kernel.org/r/20251010104149.72783-2-thomas.hellstrom@linux.intel.com
Fixes: 10aa5c8060 ("drm/gpusvm, drm/xe: Fix userptr to not allow device private pages")
(cherry picked from commit 2cfcea7a74)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Currently, the BiosImage type in vbios code is implemented as a
type-wrapping enum with the sole purpose of implementing a type that is
common to all specific image types. To make this work, macros were used
to overcome limitations of using enums. Ugly match statements were also
required to route methods from the enum type to the specific image type.
Simplify the code by just creating the common BiosImage type in the
iterator, and then converting it to specific image type after. This
works well since all the methods common to different BiosImage are
called only during the iteration and not later. Should we need to call
these common methods later, we can use AsRef and traits, but for now not
doing so gives us a nice ~50 negative line delta versus the existing
code and is a lot simpler.
Also remove the now obsolete BiosImage enum type.
Cc: Benno Lossin <lossin@kernel.org>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Message-ID: <20251009004732.2287050-1-joelagnelf@nvidia.com>
