Ville Syrjälä [Wed, 26 Mar 2025 16:25:40 +0000 (18:25 +0200)]
drm/i915: Extract intel_bw_check_sagv_mask()
Move the bw_state->pipe_sagv_reject computation into intel_bw.c
where it belongs.
Previously we had a complicated dance between watermarks and
sagv which required this to be computed earlier, but that was
changed in commit 5e8146251f7b ("extract intel_bw_check_sagv_mask()")
which allows the whole thing to be cleaned up quite a bit.
Ville Syrjälä [Wed, 26 Mar 2025 16:25:39 +0000 (18:25 +0200)]
drm/i915: Extract intel_bw_modeset_checks()
Pull the new_bw_state->active_pipes computation out from
intel_compute_sagv_mask() and move it into the intel_bw.c
(which is arguably the correct place for it).
Ville Syrjälä [Wed, 26 Mar 2025 16:25:38 +0000 (18:25 +0200)]
drm/i915: Drop force_check_qgv
Remove the force_check_qgv flag and just fill the pipe_sagv_reject
bitmask properly during readout. This will cause the initial commit
to re-enable SAGV if possible.
Ville Syrjälä [Wed, 26 Mar 2025 16:25:37 +0000 (18:25 +0200)]
drm/i915: Flag even inactive crtcs as "inherited"
I want to use the crtc_state->inherited flag to clean up some
of the early SAGV handling. To make that work nicely I need to
flag even the inactive crtcs as "inherited".
Since we can't expect user space to perform any real commits
on inactive crtcs we'll clear the flag already during
initial_commit().
Ville Syrjälä [Wed, 26 Mar 2025 16:25:36 +0000 (18:25 +0200)]
drm/i915: Do more bw readout
Update a bunch of bw related stuff during readout:
- bw_state->dbuf_bw possible now that the wm readout
has given us access to the plane ddb data
- cdclk_state->bw_min_cdclk
Ville Syrjälä [Wed, 26 Mar 2025 16:25:35 +0000 (18:25 +0200)]
drm/i915: Avoid triggering unwanted cdclk changes due to dbuf bandwidth changes
Currently intel_bw_calc_min_cdclk() always adds the bw_state
to the atomic state. Not only does it result in potentially
redundant work later, it's also currently causing unwanted cdclk
changes during driver load.
Check if the dbuf bw is actually changing before we decide to
pull in the bw state.
Ville Syrjälä [Wed, 26 Mar 2025 16:25:31 +0000 (18:25 +0200)]
drm/i915: Drop the cached per-pipe min_cdclk[] from bw state
intel_bw_crtc_min_cdclk() only depends on the pipe data rate,
which we already have stashed in bw_state->data_rate[]. So
stashing the resulting min_cdclk[] as well is redundant. Get
rid of it.
Ville Syrjälä [Thu, 6 Mar 2025 21:07:40 +0000 (23:07 +0200)]
drm/i915/dp: Reject HBR3 when sink doesn't support TPS4
According to the DP spec TPS4 is mandatory for HBR3. We have
however seen some broken eDP sinks that violate this and
declare support for HBR3 without TPS4 support.
At least in the case of the icl Dell XPS 13 7390 this results
in an unstable output.
Reject HBR3 when TPS4 supports is unavailable on the sink.
v2: Leave breadcrumbs in dmesg to avoid head scratching (Jani)
Jouni Högander [Mon, 31 Mar 2025 09:07:47 +0000 (12:07 +0300)]
drm/i915/psr: Prevent DP Panel Replay as well when CRC is enable
We are seeing timeouts in opening CRC fd when testing on setup where DP
Panel Replay can be enabled. Fix these by checking if CRC is enabled for DP
Panel Replay as well.
Ville Syrjälä [Thu, 13 Mar 2025 14:08:36 +0000 (16:08 +0200)]
drm/i915: Lookup the memory region first in the BIOS FB takeover
When doing the BIOS FB takeover let's look up the appropriate
memory region first. If it doesn't exist there's not much point
in doing the PTE read/etc either.
Ville Syrjälä [Thu, 13 Mar 2025 14:08:34 +0000 (16:08 +0200)]
drm/i915: Verify the BIOS FB first PTE on non-LMEMBAR systems
Now that we have intel_ggtt_read_entry() we can easily read out the
first PTE of the BIOS FB and verify that it looks correct. We'll
also use the extracted dma address to figure out where in stolen
the FB lives (so far we've just assumed that it sits at offset 0,
and in practice that does seem to be true, but better safe than
sorry).
Ville Syrjälä [Thu, 13 Mar 2025 14:08:33 +0000 (16:08 +0200)]
drm/i915: Use intel_ggtt_read_entry() in the BIOS FB takeover
Use intel_ggtt_read_entry() instead of open coding the PTE
read/decode in the BIOS FB takeover code. So far this codepath
only covers platforms with LMEMBAR.
Ville Syrjälä [Thu, 13 Mar 2025 14:08:32 +0000 (16:08 +0200)]
drm/i915/ggtt: Add intel_ggtt_read_entry()
The BIOS FB takeover code wants to read out the PTEs (or at least
one of them) to figure out where the FB is located in memory.
Currently we only do that for systems with LMEMBAR, and we've
open coded the PTE decoding in the display code. Introduce a more
proper abstract interface (intel_ggtt_read_entry()) for this purpose,
and implement it for all platforms.
Ville Syrjälä [Thu, 13 Mar 2025 14:08:31 +0000 (16:08 +0200)]
agp/intel-gtt: Add intel_gmch_gtt_read_entry()
i915 wants to read out the PTE(s) populated by the BIOS/GOP
to verify that the framebuffer is in the correct location.
Introduce intel_gmch_gtt_read_entry() that reads out the
PTE and decodes it to a somewhat abstract form. For now
we just return the dma_addr, present bit, and local memory
bit. I didn't bother with the snoop bit/etc.
Ville Syrjälä [Thu, 13 Mar 2025 14:08:30 +0000 (16:08 +0200)]
drm/i915: Expose intel_memory_type_str()
Rename region_type_str() into intel_memory_type_str() and
expose it outside intel_memory_region.c. I'll have another
use for this in the BIOS FB takeover code.
Jani Nikula [Fri, 21 Mar 2025 12:51:14 +0000 (14:51 +0200)]
drm/i915/gvt: use hardcoded reference clocks
Usually I'd argue hardcoding values is the wrong thing to do, but in
this case, GVT looking deep into the guts of the DPLL manager for the
reference clocks is worse. This is done for BDW and BXT only, and there
shouldn't be any reason to try to be so dynamic about it.
This helps reduce the direct pokes at display guts from non-display
code.
Jani Nikula [Wed, 26 Mar 2025 11:54:52 +0000 (13:54 +0200)]
drm/i915: reduce intel_wakeref.h dependencies
Forward declare struct drm_printer instead of including drm/drm_print.h,
as we only need the pointer. Turns out quite a few places depend on this
include implicitly. Make them explicit.
Some of the includes are just stale and unnecessary. Group the forward
declarations together while at it.
Initializing const char opregion_signature[16] = OPREGION_SIGNATURE
(which is "IntelGraphicsMem") drops the NUL termination of the
string. This is intentional, but the compiler doesn't know this.
Switch to initializing header->signature directly from the string
litaral, with sizeof destination rather than source. We don't treat the
signature as a string other than for initialization; it's really just a
blob of binary data.
Add a static assert for good measure to cross-check the sizes.
Reported-by: Kees Cook <kees@kernel.org> Closes: https://lore.kernel.org/r/20250310222355.work.417-kees@kernel.org Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13934 Tested-by: Nicolas Chauvet <kwizart@gmail.com> Tested-by: Damian Tometzki <damian@riscv-rocks.de> Cc: stable@vger.kernel.org Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com> Link: https://lore.kernel.org/r/20250327124739.2609656-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Lucas De Marchi [Tue, 25 Mar 2025 02:28:42 +0000 (19:28 -0700)]
drm/i915/dram: Consolidate logging of DRAM type
Instead of logging the dram type in the per version/platform function,
do it in the generic one. This fixes a few discrepancies depending on
the platform:
- There was no DRAM type logging for graphics version 12 and
above
- For graphics version 11, it would log the DRAM type in
skl_get_dram_info(), but could possibly override it later
without any log in icl_pcode_read_mem_global_info()
For bxt_get_dram_info(), there's no need to log the type for each dimm,
as the drm_WARN_ON() already covers the case they are not all the same.
This maintains the behavior of skl_get_dram_info() that would log the
DRAM type even on failures.
Some new dram types were added without adding the corresponding string
conversion, probably because it's not being used by recent platforms.
Add them, together with a BUILD_BUG_ON() to ensure it keeps in sync, in
preparation to make use of them in recent platforms.
Ankit Nautiyal [Thu, 27 Mar 2025 14:46:29 +0000 (20:16 +0530)]
drm/i915/display: Avoid use of VTOTAL.Vtotal bits
For platforms that always use VRR Timing Generator, the VTOTAL.Vtotal
bits are not required. Since the support for these bits is going to
be deprecated in upcoming platforms, avoid writing these bits for the
platforms that do not use legacy Timing Generator.
Since for these platforms vrr.vmin is always filled with crtc_vtotal,
use TRAN_VRR_VMIN to get the vtotal for adjusted_mode.
v2: Avoid having a helper for manipulating VTOTAL register, and instead
just make the change where required. (Ville)
v3: Set crtc_vtotal instead of working with the bits directly (Ville).
Use intel_vrr_vmin_vtotal() to set the vtotal during readout. (Ville)
v4: Keep the reading part unchanged, and let it get overwritten for
cases where we use vrr.vmin. (Ville)
Jani Nikula [Tue, 25 Mar 2025 12:36:38 +0000 (14:36 +0200)]
drm/i915/display: drop some unnecessary intel_de_* compatibility wrappers
intel_de_wait_for_set(), intel_de_wait_for_clear(), intel_de_read_fw(),
and intel_de_write_fw() are only passed struct intel_display. Remove the
unnecessary compatibility wrappers.
Jani Nikula [Tue, 25 Mar 2025 12:36:37 +0000 (14:36 +0200)]
drm/i915/wa: convert intel_display_wa.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_display_wa.[ch] to struct
intel_display.
William Tseng [Tue, 11 Mar 2025 10:06:26 +0000 (18:06 +0800)]
drm/i915/dsi: let HW maintain the HS-TRAIL timing
This change is to avoid over-specification of the TEOT timing
parameter, which is derived from software in current design.
Supposed that THS-TRAIL and THS-EXIT have the minimum values,
i.e., 60 and 100 in ns. If SW is overriding the HW default,
the TEOT value becomes 150 ns, approximately calculated by
the following formula.
DIV_ROUND_UP(60/50)*50 + DIV_ROUND_UP(100/50))*50/2, where 50
is LP Escape Clock time in ns.
The TEOT value 150 ns is larger than the maximum value,
around 136 ns if UI is 1.8ns, (105 ns + 12*UI, defined by MIPI
DPHY specification).
However, the TEOT value will meet the specification if THS-TRAIL
is set to the HW default, instead of software overriding.
The timing change is made for both data lane and clock lane.
v1: initial version.
v2: change clock lane dphy timings.
v3: remove calculation of trail cnt.
v4: rebase.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13891 Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by: William Tseng <william.tseng@intel.com> Acked-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://lore.kernel.org/r/20250311100626.533888-1-william.tseng@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Mon, 10 Mar 2025 18:35:28 +0000 (20:35 +0200)]
drm/i915: Move intel_disable_shared_dpll() into ilk_pch_post_disable()
On ILK-IVB only PCH outputs use shared dplls. Move the relevant
intel_disable_shared_dpll() into ilk_pch_post_disable() to make
that clear (and if we extend the dpll mgr to cover all plls we need
different enable/disable points anyway for the PCH vs. CPU eDP cases).
The intel_enable_shared_dpll() counterpart was already in
ilk_pch_enable() anyway, so this is the more symmetric place for the
disable as well.
Ville Syrjälä [Mon, 10 Mar 2025 18:35:27 +0000 (20:35 +0200)]
drm/i915: Enable/disable shared dplls just the once for joined pipes
Currently we loop over all joined pipes and enable/disable the
shared dplls for each. We don't really have to do that since
all joined pipes will be using the same dpll. So let's just do
the enable/disable once for the whole set of joined pipes.
We can still keep tracking the dpll active set as pipes as long
as we remember to flip the bits for all the joined pipes on one go.
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:46 +0000 (19:02 +0530)]
drm/i915/vrr: Set trans_vrr_ctl in intel_vrr_set_transcoder_timings()
We now always set vrr.flipline, vmin, and vmax for all platforms that
support VRR. Therefore, we should set all TRANS_VRR_CTL bits except
VRR_ENABLE. Without this, the readback for these bits will fail because we
only read vrr.flipline, vmin, and vmax if TRANS_VRR_CTL has the
FLIPLINE_EN bit set.
For platforms that always have the VRR Timing Generator enabled,
the FLIPLINE_EN bit is always set in TRANS_VRR_CTL during
intel_transcoder_vrr_enable(). However, for the remaining platforms
(that do not always have the VRR Timing Generator enabled) if a full
modeset doesn't occur and VRR is not enabled, the bit is not set.
This results in a mismatch between the software state and hardware state
because the software state expects VRR timings like flipline, vmin, and
vmax to be set, but the readout for these doesn't happen since the
FLIPLINE_EN bit is not set in TRANS_VRR_CTL.
To avoid this mismatch, write trans_vrr_ctl in
intel_vrr_set_transcoder_timings() even when VRR is not enabled
for platforms that do not have the VRR Timing Generator always enabled.
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:45 +0000 (19:02 +0530)]
drm/i915/vrr: Always use VRR timing generator for PTL+
Currently, the VRR timing generator is used only when VRR is enabled by
userspace for sinks that support VRR. Starting with PTL+, gradually move
away from the legacy timing generator and use the VRR timing generator
for both variable and fixed timings.
Note: For platforms where we always enable the VRR timing generator,
the LRR fastset is not allowed to avoid live programming of vrr.guardband
with VRR TG enabled. This effectively breaks the LRR fastset functionality
for these platforms and needs to be addressed.
v2: Use this for PTL for now to avoid losing LRR fastset for older
platforms. (Ville)
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:44 +0000 (19:02 +0530)]
drm/i915/vrr: Allow fixed_rr with pipe joiner
VRR with joiner is currently disabled as it still needs some work to
correctly sequence the primary and secondary transcoders. However, we can
still use VRR Timing generator in fixed refresh rate for joiner and since
it just need to program vrr timings once and does not involve changing
timings on the fly. We still need to skip the VRR and LRR for joiner.
To achieve this set vrr.in_range to 0 for joiner case, so that we do not
try VRR and LRR for the joiner case.
v2: Avoid checks for secondary pipes, where not required. (Ville)
v3: Remove a redundant check and reset vrr.in_range to false. (Ville)
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:43 +0000 (19:02 +0530)]
drm/i915/display: Move vrr.guardband/pipeline_full out of !fastset block
Since the vrr.guardband can now change for platforms that always use the
VRR Timing Generator, and it is unsafe to reprogram the guardband on the
fly, move the guardband and pipeline_full checks from the pure !fastboot
path and add a check for intel_vrr_always_use_vrr_tg().
For older platforms the vrr.guardband change happens when VRR Timing
generator is off. For the platforms that always use the VRR Timing
Generator, this will prevent reprogramming the vrr.guardband without a
full modeset. However, this will disrupt LRR functionality for these
platforms.
v2: Modify the check to avoid breaking the LRR on older platform.
(Ville)
v3: Correct the oversight of not removing the lines from the original
location. (Ville)
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:41 +0000 (19:02 +0530)]
drm/i915/vrr: Use fixed timings for platforms that support VRR
For fixed refresh rate use fixed timings for all platforms that support
VRR. For this add checks to avoid computing and reading VRR for
platforms that do not support VRR.
v2: Avoid touching check for VRR_CTL_FLIP_LINE_EN. (Ville)
v3: Avoid redundant statements in vrr_{compute/get}_config. (Ville)
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:40 +0000 (19:02 +0530)]
drm/i915/display: Use fixed_rr timings in modeset sequence
During modeset enable sequence, program the fixed timings, and turn on the
VRR Timing Generator (VRR TG) for platforms that always use VRR TG.
For this intel_vrr_set_transcoder now always programs fixed timings.
Later if vrr timings are required, vrr_enable() will switch
to the real VRR timings.
For platforms that will always use VRR TG, the VRR_CTL Enable bit is set
and reset in the transcoder enable/disable path.
v2: Update intel_vrr_set_transcoder_timings for fixed_rr.
v3: Update intel_set_transcoder_timings_lrr for fixed_rr. (Ville)
v4: Have separate functions to enable/disable VRR CTL
v5:
-For platforms that do not always have VRRTG on, do write bits other
than enable bit and also use write the TRANS_VRR_PUSH register. (Ville)
-Avoid writing trans_ctl_vrr if !vrr_possible().
v6:
-Disable VRR just before intel_ddi_disable_transcoder_func(). (Ville)
-Correct the sequence of configuring PUSH and VRR Enable/Disable. (Ville)
v7: Reset trans_vrr_ctl to 0 unconditionally in
intel_vrr_transcoder_disable(). (Ville)
v8: Reset trans_vrr_ctl if flipline is not set. (Ville)
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:39 +0000 (19:02 +0530)]
drm/i915/vrr: Set vrr.enable for VRR TG with fixed_rr
For platforms that enable VRR TG only for variable timings, the
VRR_CTL.VRR_ENABLE bit indicates VRR is active. For platforms that
always have VRR TG enabled, the VRR_CTL.VRR_ENABLE bit indicates VRR
is active only when not in fixed refresh rate mode.
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:38 +0000 (19:02 +0530)]
drm/i915/vrr: Always set vrr vmax/vmin/flipline in vrr_{enable/disable}
For platforms for which vrr timing generator is always set, VRR_CTL
enable bit does not need to toggle, so modify the vrr_{enable/disable}
for this.
At the moment the helper intel_vrr_always_use_vrr_tg() return false for
all cases. This will be set later when all other bits are in place.
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:37 +0000 (19:02 +0530)]
drm/i915/vrr: Refactor condition for computing vmax and LRR
LRR and Vmax can be computed only if VRR is supported and vrr.in_range
is set. Currently we proceed with vrr timings only for VRR supporting
panels and return otherwise. For using VRR TG with fix timings, need to
continue even for panels that do not support VRR.
To achieve this, refactor the condition for computing vmax and
update_lrr so that we can continue for fixed timings for panels that do
not support VRR.
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:36 +0000 (19:02 +0530)]
drm/i915/display: Move intel_psr_post_plane_update() at the later
In intel_post_plane_update() there are things which might need to do
vblank waits, so enabling PSR as early as we do now is simply
counter-productive. Therefore move intel_psr_post_plane_update() at the
last of intel_post_plane_update().
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:34 +0000 (19:02 +0530)]
drm/i915/dp_mst: Use VRR Timing generator for DP MST for fixed_rr
Currently the variable timings are supported only for DP and eDP and not
for DP MST. Call intel_vrr_compute_config() for MST which will configure
fixed refresh rate timings irrespective of whether VRR is supported or
not. Since vrr_capable still doesn't have support for DP MST this will be
just treated as non VRR case and vrr.vmin/vmax/flipline will be all set
to adjusted_mode->crtc_vtotal.
This will help to move away from the legacy timing generator and
always use VRR timing generator by default.
With this change, we need to exclude MST in intel_vrr_is_capable for
now, to avoid having LRR with MST.
v2: Exclude MST in intel_vrr_is_capable() for now. (Ville)
Ankit Nautiyal [Mon, 24 Mar 2025 13:32:33 +0000 (19:02 +0530)]
drm/i915/hdmi: Use VRR Timing generator for HDMI for fixed_rr
Currently VRR is not supported with HDMI, but we can still leverage
the VRR Timing Generator to achieve a fixed refresh rate.
Call intel_vrr_compute_config() for HDMI which will handle the vrr
timings to have fixed refresh rate with VRR Timing Generator.
Ville Syrjälä [Fri, 7 Feb 2025 21:54:06 +0000 (23:54 +0200)]
drm/i915: Replace the HAS_DDI() in intel_crtc_scanline_offset() with specific platform checks
The HDMI vs. not scanline offset stuff no longer applies to the
latest platforms, so using HAS_DDI() is a bit confusing. Replace
with a more specific set of conditions.
Also let's just deal with the platform types in the if ladder
itself, and handle the HDMI vs. not within the specific branch
for those platforms.
Ville Syrjälä [Fri, 7 Feb 2025 21:54:04 +0000 (23:54 +0200)]
drm/i915: Fix scanline_offset for LNL+ and BMG+
Turns out LNL+ and BMG+ no longer have the weird extra scanline
offset for HDMI outputs. Fix intel_crtc_scanline_offset()
accordingly so that scanline evasion/etc. works correctly on
HDMI outputs on these new platforms.
Imre Deak [Mon, 24 Mar 2025 18:01:45 +0000 (20:01 +0200)]
drm/i915/dp_mst: Fix side-band message timeouts due to long PPS delays
The Panel Power Sequencer lock held on an eDP port (a) blocks a DP AUX
transfer on another port (b), since the PPS lock is device global, thus
shared by all ports. The PPS lock can be held on port (a) for a longer
period due to the various PPS delays (panel/backlight on/off,
power-cycle delays). This in turn can cause an MST down-message request
on port (b) time out, if the above PPS delay defers the handling of the
reply to the request by more than 100ms: the MST branch device sending
the reply (signaling this via the DP_DOWN_REP_MSG_RDY flag in the
DP_DEVICE_SERVICE_IRQ_VECTOR DPCD register) may cancel the reply
(clearing DP_DOWN_REP_MSG_RDY and the reply message buffer) after 110
ms, if the reply is not processed by that time.
Avoid MST down-message timeouts described above, by locking the PPS
state for AUX transfers only if this is actually required: on eDP ports,
where the VDD power depends on the PPS state and on all DP and eDP ports
on VLV/CHV, where the PPS is a pipe instance and hence a modeset on any
port possibly affecting the PPS state.
v2: Don't move PPS locking/VDD enabling to a separate function. (Jani)
Jani Nikula [Fri, 21 Mar 2025 10:52:56 +0000 (12:52 +0200)]
drm/i915/pch: convert intel_pch_refclk.c to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_pch_refclk.[ch] to struct
intel_display.
Jani Nikula [Fri, 21 Mar 2025 10:52:55 +0000 (12:52 +0200)]
drm/i915/pch: convert intel_pch_display.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_pch_display.[ch] to struct
intel_display.
Jani Nikula [Fri, 21 Mar 2025 10:52:48 +0000 (12:52 +0200)]
drm/i915/dsi: convert intel_dsi_vbt.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_dsi_vbt.[ch] to struct
intel_display.
Vivek Kasireddy [Mon, 24 Mar 2025 17:22:33 +0000 (10:22 -0700)]
drm/i915/xe2hpd: Identify the memory type for SKUs with GDDR + ECC
Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type
with ECC enabled. We need to identify this scenario and add a new
case in xelpdp_get_dram_info() to handle it. In addition, the
derating value needs to be adjusted accordingly to compensate for
the limited bandwidth.
Bspec: 64602 Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 3adcf970dc7e ("drm/xe/bmg: Drop force_probe requirement") Cc: stable@vger.kernel.org Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250324-tip-v2-1-38397de319f8@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
drm/i915/fbc: update the panel_replay dependency in fbc wa's
There are two panel_replay scenarios fbc wa need to be aware of,
panel replay with and without selective update capability.
Panel replay without selective update don't have any fbc wa.
So keep the fbc psr1 wa as it is.
The current fbc psr2 wa is mainly about selective fetch and we
need to apply the fbc wa if selective fetch is on - irrespective
of panel replay. Hence we can't exclude panel replay from the
fbc psr2 wa.
v1: keep panel_replay exclusion in PSR1 case (Jouni)
Patch description updated
drm/i915/fbc: keep FBC disabled if selective update is on in xe2lpd
FBC was disabled in case PSR2 selective update in display 12 to
14 as part of a wa. From xe2lpd onwards there is a logic to be
implemented to decide between FBC and selective update. Until
that logic is implemented keep FBC disabled in case selective
update is enabled.
v1: updated patch description and some explanation and todo
drm/i915/dmc: Create debugfs entry for dc6 counter
Starting from MTL we don't have a platform agnostic way to validate
DC6 state due to dc6 counter has been removed to validate DC state.
The goal is to validate that the display HW can reach the DC6 power
state. There is no HW DC6 residency counter (and there wasn't such
a counter earlier either), so an alternative way is required. According
to the HW team the display driver has programmed everything correctly in
order to allow the DC6 power state if the DC5 power state is reached
(indicated by the HW DC5 residency counter incrementing) and DC6 is
enabled by the driver.
Driver could take a snapshot of the DC5 residency counter right
after it enables DC6 (dc5_residency_start) and increment the SW
DC6 residency counter right before it disables DC6 or when user space
reads the DC6 counter. So the driver would update the counter at these
two points in the following way:
dc6_residency_counter += dc5_current_count - dc5_start_count
v2: Update the discription. (Imre)
Read dc5 count during dc6 enable and disable then and update
dc6 residency counter. (Imre)
Remove variable from dmc structure. (Jani)
Updated the subject title.
v3: Add i915_power_domains lock to updated dc6 count in debugfs. (Imre)
Use flags to check dc6 enable/disable states. (Imre)
Move the display version check and counter read/update to
a helper. (Imre)
Resize the variable length. (Rodrigo)
Use old dc6 debugfs entry for every platform. (Rodrigo)
v4: Remove superfluous whitespace. (Jani)
Read DMC registers in intel_dmc.c (Jani)
Rename dc6_en_dis to dc6_enabled and change its type to bool. (Jani)
Rename update_dc6_count and move it to intel_dmc.c (Jani)
Rename dc6_en_dis to start_tracking. (Imre)
Have lock for dc6 state read aswelll. (Imre)
Keep the existing way print 'DC5 -> DC6 count' along with
new 'DC6 Allowed Count' print. (Imre)
Add counters in intel_dmc struct. (Imre)
Have interface to return dc6 allowed count. (Imre)
Rename dc6_count to dc6_allowed_count. (Rodrigo)
v5: Rename counters and move in to dc6_allowed structure. (Imre)
Order declaration lines in decreasing line length. (Imre)
Update start_tacking logic. (Imre)
Move get couner inside lock and DISPLAY_VER code to helper. (Imre)
v6: Change intel_dmc_get_dc6_allowed_count return type to bool. (Imre)
Update debugfs print to better allien with old print. (Imre)
Remove braces at if/else for signle line statements. (Imre)
v7: Remove in line variable declaration. (Imre)
v8: Rebase the changes.
Ankit Nautiyal [Sat, 22 Mar 2025 04:43:45 +0000 (10:13 +0530)]
drm/i915/vrr: Avoid reading vrr.enable based on fixed_rr check
Currently, vrr.enable is intended only for variable refresh rate timings.
At this point, we do not set fixed refresh rate timings, but the GOP can,
which creates a problem during the readback of vrr.enable.
The GOP enables the VRR timing generator with fixed timings, while the
driver only recognizes the VRR timing generator as enabled with
variable timings. This discrepancy causes an issue due to the
fixed refresh rate check during readback. Since the VRR timing generator
is enabled and we do not support fixed timings, the readback should set
vrr.enable so that the driver can disable the VRR timing generator.
However, the current check does not allow this.
Therefore, remove the fixed refresh rate check during readback.
Fixes: 27217f9d1856 ("drm/i915/vrr: Track vrr.enable only for variable timing") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250322044345.3827137-3-ankit.k.nautiyal@intel.com
Suraj Kandpal [Fri, 28 Feb 2025 15:25:32 +0000 (20:55 +0530)]
drm/i915/vdsc: Use the DSC config tables for DSI panels
Some DSI panel vendors end up hardcoding PPS params because of which
it does not listen to the params sent from the source. We use the
default config tables for DSI panels when using DSC 1.1 rather than
calculate our own rc parameters.
--v2
-Use intel_crtc_has_type [Jani]
--v4
-Use a function to check Mipi dsi dsc 1.1 condition [Ankit]
-Add documentation for using this condition [Ankit]
-Rebase
--v5
-Pass only the crtc_state [Jani]
-Fixup the comment [Jani]
-Check for dsc major version [Jani]
-Use co-developed-by tag [Jani]
--v6
-Add more definition of the issue and solution in the comment [Ankit]
Jani Nikula [Thu, 20 Mar 2025 15:03:57 +0000 (17:03 +0200)]
drm/i915/display: use display runtime PM interfaces for for atomic state
Convert intel_atomic_commit() and intel_atomic_commit_tail() to use
display runtime PM interfaces. Also convert the wakeref member type to
struct ref_tracker *, which is the same as intel_wakeref_t, but without
the typedef.
Jani Nikula [Thu, 20 Mar 2025 15:03:55 +0000 (17:03 +0200)]
drm/i915/display: add display specific runtime PM wrappers
Add display specific wrappers around the i915 and xe dedicated runtime
PM interfaces. There are no conversions here, just the wrappers.
Implement with_intel_display_rpm() without needing to provide a local
variable, which neatly narrows the scope and hides the type of the
wakeref cookie.
Jani Nikula [Thu, 20 Mar 2025 14:46:04 +0000 (16:46 +0200)]
drm/i915/irq: convert rest of intel_display_irq.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_display_irq.[ch] to struct
intel_display.
Jani Nikula [Thu, 20 Mar 2025 14:46:03 +0000 (16:46 +0200)]
drm/i915/irq: convert intel_display_irq.[ch] interfaces to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the external interfaces of intel_display_irq.[ch] to
struct intel_display.
Jani Nikula [Thu, 20 Mar 2025 14:46:02 +0000 (16:46 +0200)]
drm/i915/hotplug: convert intel_hotplug_irq.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_hotplug_irq.[ch] to struct
intel_display.
Jani Nikula [Thu, 20 Mar 2025 14:45:59 +0000 (16:45 +0200)]
drm/i915/hotplug: convert intel_hotplug.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_hotplug.[ch] to struct
intel_display.
Jani Nikula [Thu, 20 Mar 2025 14:45:58 +0000 (16:45 +0200)]
drm/i915/connector: convert intel_connector.c to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_connector.c to struct
intel_display. i915_inject_probe_failure() remains the only call that
requires i915 pointer.
Yue Haibing [Sat, 15 Mar 2025 12:01:43 +0000 (20:01 +0800)]
drm/i915/display: Fix build error without DRM_FBDEV_EMULATION
In file included from <command-line>:
./drivers/gpu/drm/i915/display/intel_fbdev.h: In function ‘intel_fbdev_framebuffer’:
./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: error: ‘NULL’ undeclared (first use in this function)
32 | return NULL;
| ^~~~
./drivers/gpu/drm/i915/display/intel_fbdev.h:1:1: note: ‘NULL’ is defined in header ‘<stddef.h>’; did you forget to ‘#include <stddef.h>’?
+++ |+#include <stddef.h>
1 | /* SPDX-License-Identifier: MIT */
./drivers/gpu/drm/i915/display/intel_fbdev.h:32:16: note: each undeclared identifier is reported only once for each function it appears in
32 | return NULL;
| ^~~~
Build fails if CONFIG_DRM_FBDEV_EMULATION is n, add missing header file.
Fixes: 9fa154f40eb6 ("drm/{i915,xe}: Run DRM default client setup") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250315120143.2344958-1-yuehaibing@huawei.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
drm_dev_register() fails"), we return from i915_driver_register()
immediately if drm_dev_register() fails, skipping remaining registration
steps, and continue only with remaining probe steps. However, the
_unregister() counterpart called at driver remove knows nothing about that
skip and executes reverts of all those steps. As a consequence, a number
of kernel warnings that taint the kernel are triggered:
Moreover, that unexpected PM reference is left untouched (not released)
but overwritten, then that triggers another kernel warning at driver
release phase:
A call to intel_power_domains_disable() was already there. It triggers
the drm_WARN_ON() when it finds a reference to a wakeref taken on device
probe and not released after device registration failure. That wakeref is
then left held forever once its handle gets lost overwritten with another
wakeref, hence another WARN() is called from
intel_runtime_pm_driver_release().
The WARN() triggered by kernfs_remove_by_name_ns() from
i915_teardown_sysfs()->i915_gpu_error_sysfs_teardown(), formerly
i915_teardown_error_capture(), was also there when the return was added.
A call to intel_gt_sysfs_unregister() that triggers the WARN() from
kobject_put() was added to intel_gt_driver_unregister() with commit 69d6bf5c3754ff ("drm/i915/gt: Fix memory leaks in per-gt sysfs").
Fix the asymmetry by failing the driver probe on device registration
failure and going through rewind paths.
For that to work as expected, we apparently need to start the rewind path
of i915_driver_register() with drm_dev_unregister(), even if
drm_dev_register() returned an error.
v5: Drop unsigned keyword from ret variable declaration (Krzysztof),
- keep the "Failed to register driver for userspace access" error
message (Krzysztof),
- split PXP cleanup addition to rewind path out to a separate patch.
v4: Switch to taking an error rewind path on device registration failure
(Krzysztof, Lucas).
v3: Based on Andi's commitment on introducing a flag, try to address
Jani's "must find another way" by finding a better place and name for
the flag (in hope that's what Jani had on mind),
- split into a series of patches and limit the scope of the first (this)
one to a minimum of omitting conditionally only those unregister
(sub)steps that trigger kernel warnings when not registered.
v2: Check in _unregister whether the drm_dev_register has succeeded and
skip some of the _unregister() steps. (Andi)
Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10047 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10131 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10887 Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12817 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-8-janusz.krzysztofik@linux.intel.com
drm/i915: Fix PXP cleanup missing from probe error rewind
Commit f67986b0119c04 ("drm/i915/pxp: Promote pxp subsystem to top-level
of i915") added PXP initialization to driver probe path, but didn't add a
respective PXP cleanup on probe error. That lack of cleanup seems
harmless as long as PXP is still unused and idle when a probe failure
occurs and error rewind path is entered, but as soon as PXP starts
consuming device and driver resources keeping them busy, kernel warnings
may be triggered when cleaning up resources provided by memory regions,
GGTT, GEM and/or VMA cache from the probe error rewind and/or module
unload paths because of missing PXP cleanup. That scenario was observed
on attempts to fail the probe and enter the rewind path on injection of
now ignored error in device registration path.
Fix it.
Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250314205202.809563-7-janusz.krzysztofik@linux.intel.com
projects / thirdparty / linux.git / log
