Ankit Nautiyal [Mon, 2 Feb 2026 10:37:18 +0000 (16:07 +0530)]
drm/i915/dp: Rework pipe joiner logic in mode_valid
Currently in intel_dp_mode_valid(), we compute the number of joined pipes
required before deciding whether DSC is needed. This ordering prevents us
from accounting for DSC-related overhead when determining pipe
requirements.
It is not possible to first decide whether DSC is needed and then compute
the required number of joined pipes, because the two depend on each other:
- DSC need is a function of the pipe count (e.g., 4‑pipe always requires
DSC; 2‑pipe may require it if uncompressed joiner is unavailable).
- Whether a given pipe‑join configuration is sufficient depends on
effective bandwidth, which itself changes when DSC is used.
As a result, the only correct approach is to iterate candidate pipe counts.
So, refactor the logic to start with a single pipe and incrementally try
additional pipes only if needed. While DSC overhead is not yet computed
here, this restructuring prepares the code to support that in a follow-up
changes.
If a forced joiner configuration is present, we just check for that
configuration. If it fails, we bailout and return instead of trying with
other joiner configurations.
v2:
- Iterate over number of pipes to be joined instead of joiner
candidates. (Jani)
- Document the rationale of iterating over number of joined pipes.
(Imre)
v3:
- In case the force joiner configuration doesn't work, do not fallback
to the normal routine, bailout instead of trying other joiner
configurations. (Imre)
v4:
- Use num_joined_pipes instead of num_pipes. (Imre)
- Inititialize status before the loops starts. (Imre)
v5:
- Fix status handling by setting MODE_CLOCK_HIGH on DSC/rate failures.
(Imre)
Ankit Nautiyal [Mon, 2 Feb 2026 10:37:16 +0000 (16:07 +0530)]
drm/i915/dp: Move num_joined_pipes and related checks together
Move the calculation of `num_joined_pipes` and other constraints that
depend on it, into a single block.
This groups all joiner-dependent logic together, preparing the code for a
future loop-based evaluation of multiple joiner configurations.
Suraj Kandpal [Mon, 2 Feb 2026 08:18:02 +0000 (13:48 +0530)]
drm/i915/dp: Add a meaningful return to intel_dp_read_dsc_dpcd
Add a meaningful return to intel_dp_read_dsc_dpcd. This is to avoid
unwanted DPCD reads which are not needed once we know DSC DPCD
read fails. To do this convert drm_dp_dpcd_read to drm_dp_dpcd_read_data
which returns a meaningful error which can be propogated up when all
bits are not read.
While we are at it convert the drm_err in intel_dp_read_dsc_dpcd to
drm_dbg_kms. This is because we do not want a hard ERROR when we
call this function, during the intel_dp_detect phase since AUX may not
be up, it is expected to fail but we do not expect a failure in read
when we call intel_dp_dsc_get_sink_cap so we move the drm_err there.
drm/i915/display: fix the pixel normalization handling for xe3p_lpd
Pixel normalizer is enabled with normalization factor as 1.0 for
FP16 formats in order to support FBC for those formats in xe3p_lpd.
Previously pixel normalizer gets disabled during the plane disable
routine. But there could be plane format settings without explicitly
calling the plane disable in-between and we could endup keeping the
pixel normalizer enabled for formats which we don't require that.
This is causing crc mismatches in yuv formats and FIFO underruns in
planar formats like NV12. Fix this by updating the pixel normalizer
configuration based on the pixel formats explicitly during the plane
settings arm calls itself - enable it for FP16 and disable it for
other formats in HDR capable planes.
Jouni Högander [Tue, 27 Jan 2026 12:41:20 +0000 (14:41 +0200)]
drm/i915/psr: Use TRANS_PUSH to trigger frame change event
Now we have everything in place for triggering PSR "frame change" event
using TRANS_PUSH: use TRANS_PUSH for LunarLake and onwards.
v4:
- Added call to intel_vrr_psr_frame_change_enable call
- added setting LNL_TRANS_PUSH_PSR_PR_EN into intel_vrr_send_push
v3: use HAS_PSR_FRAME_CHANGE macro
v2: use AND instead of OR in intel_psr_use_trans_push
Jouni Högander [Tue, 27 Jan 2026 12:41:18 +0000 (14:41 +0200)]
drm/i915/psr: Do PSR exit on frontbuffer flush on LunarLake and onwards
We need to use intel_psr_exit in frontbuffer flush on LunarLake and
onwards if we want to move using trans push mechanism to trigger Frame
Change event.
Keep PSR1 and PSR2 HW tracking as it is for older platforms as this was
seen causing problems there.
Jouni Högander [Tue, 27 Jan 2026 12:41:17 +0000 (14:41 +0200)]
drm/i915/psr: Wait for idle only after possible send push
We are planning to move using trans push mechanism to trigger the Frame
Change event. In that case we can't wait PSR to idle before send push
happens. Due to this move wait for idle to be done after possible send push
is done.
This should be ok for Frame Change event triggered by register write as
well. Wait for idle is needed only for corner case where PSR is
transitioning into DEEP_SLEEP when Frame Change event is triggered. It just
has to be before wait for vblank. Otherwise we may have vblank before PSR
enters DEEP_SLEEP and still using old frame buffers for first frame after
wake up.
Jouni Högander [Tue, 27 Jan 2026 12:41:16 +0000 (14:41 +0200)]
drm/i915/display: Wait for vblank in case of PSR is using trans push
In case PSR uses trans push as a "frame change" event and we need to wait
vblank after triggering PSR "frame change" event. Otherwise we may miss
selective updates.
DSB skips all waits while PSR is active. Check push send is skipped as well
because trans push send bit is not reset by the HW if VRR is not enabled ->
we may start configuring new selective update while previous is not
complete. Avoid this by waiting for vblank after sending trans push.
Jouni Högander [Tue, 27 Jan 2026 12:41:15 +0000 (14:41 +0200)]
drm/i915/dsb: Set DSB_SKIP_WAITS_EN chicken bit for LunarLake and onwards
On LunarLake we are using TRANS_PUSH mechanism to trigger "Frame Change"
event. This way we have more control on when PSR HW is woken up. I.e. not
every display register write is triggering sending update. This allows us
setting DSB_SKIP_WAITS_EN chicken bit as well.
Jouni Högander [Tue, 27 Jan 2026 12:41:14 +0000 (14:41 +0200)]
drm/i915/vrr: Prepare to Use TRANS_PUSH mechanism for PSR frame change
On Lunarlake and onward it is possible to generate PSR Frame Change
event using TRANS_PUSH mechanism:
Ensure push is performed on flip if needed by PSR.
Don't use intel_psr_trigger_frame_change_event if PSR uses trans push as
Frame Change event: When not using trans push to generate Frame Change
event plane/pipe register writes are triggering the event. This is causing
problems when transiting to PSR active/idle and the event is coming in. To
tackle this we are waiting PSR to idle and using
intel_psr_trigger_frame_change_event to ensure PSR exit. If the Frame
change event is triggered after everything is configured (on trans push) we
don't need to worry about all this.
Ensure possible intel_vrr_tg_disable call is not overwriting
LNL_TRANS_PUSH_PSR_PR_EN.
v8:
- split adding intel_vrr_psr_frame_change_enable as a separate change
- update commit message
v7:
- HAS_PSR_FRAME_CHANGE macro moved to separate patch and renamed as
HAS_PSR_TRANS_PUSH_FRAME_CHANGE
- use intel_psr_use_trans_push instead of HAS_PSR_FRAME_CHANGE in
intel_psr_trigger_frame_change
- moved calling intel_vrr_psr_frame_change_enable away from this patch
v6:
- add HAS_PSR_FRAME_CHANGE macro
- use TRANS_PUSH in instead of TRAN_VRR_CTL
v5: use intel_psr_use_trans_push for intel_vrr_psr_frame_change_enable
v4:
- use rmw when enabling/disabling transcoder
- set TRANS_PUSH_EN conditionally in intel_vrr_send_push
- do not call intel_vrr_send_push from intel_psr_trigger_frame_change
- do not enable using TRANS_PUSH mechanism for PSR "Frame Change"
v3:
- use rmw when enabling/disabling
- keep LNL_TRANS_PUSH_PSR_PR_EN set always on LunarLake and onwards
v2: use intel_vrr_trans_push_enabled_set_clear instead of rmw
Jouni Högander [Tue, 27 Jan 2026 12:41:12 +0000 (14:41 +0200)]
drm/i915/vrr: Add helper for parsing value to be written into TRANS_PUSH
On Lunarlake and onwards it is possible to generate PSR "frame change"
event using TRANS_PUSH mechanism. As a preparation add new helper to parse
value to be written into TRANS_PUSH register. Setting
LNL_TRANS_PUSH_PSR_PR_EN is done in upcoming change.
Jouni Högander [Tue, 27 Jan 2026 12:41:11 +0000 (14:41 +0200)]
drm/i915/psr: Add intel_psr_use_trans_push to query if TRANS_PUSH is used
This is a preparation to start using trans push as a PSR "Frame Change"
event. It adds intel_psr_use_trans_push placeholder which return false for
now until we have everything in place.
Michał Grzelak [Thu, 29 Jan 2026 09:01:29 +0000 (10:01 +0100)]
drm/i915: move intel_gvt_init() level higher
Both initialisation and removal of GVT happen at different abstraction
levels. Hence caller of i915_driver_hw_probe() has no way of knowing
status of intel_gvt_init(). This can lead to an unbalanced number of
calls of intel_gvt_init() and intel_gvt_driver_remove() since GVT error
path is currently handled in i915_driver_probe(). One such scenario has
been seen with i915_driver_hw_probe() fault injection, which caused
double entry deletion and list corruption.
Move intel_gvt_init() up to i915_driver_probe(). Add out_cleanup_gvt
error path for removing gvt. Trigger it only after intel_gvt_init()
succeeded.
In case intel_gvt_init() failed, theoretically we should follow err_msi
error path. That is actually impossible since call to intel_gvt_init()
unconditionally returns 0, although it claims to return negative error
code on failure. Thus follow standard out_cleanup_hw error path on a
hypothetical future intel_gvt_init() failure. Remove err_msi label from
i915_driver_hw_probe() since intel_gvt_init() was the only user of it.
Jani Nikula [Wed, 28 Jan 2026 14:59:09 +0000 (16:59 +0200)]
drm/i915/gvt: drop dependency on intel_display_types.h
Avoid even accidental use of display details by dropping the include of
intel_display_types.h. We'll still have to include intel_dpll_mgr.h for
the DPLL IDs, but at least the surface is smaller.
Add duplicate defines of pipe_name() and port_name() to avoid depending
on display. They're trivial enough to be acceptable.
Jani Nikula [Wed, 28 Jan 2026 14:59:07 +0000 (16:59 +0200)]
drm/i915/display: move enum aux_ch to intel_display_limits.h
Move enum aux_ch from intel_display.h to intel_display_limits.h to avoid
having to include the former from gvt. This currently happens via
intel_display_types.h, which we can also drop in favour of
intel_display_limits.h in intel_gvt_mmio_table.c.
Jonathan Cavitt [Fri, 23 Jan 2026 17:09:15 +0000 (17:09 +0000)]
drm/i915/display: vcpi is always greater than zero
Static analysis issue:
intel_conn_to_vcpi currently checks and asserts vcpi >= 0, as grabbed
from payload->vcpi. But payload->vcpi is a u8, so this is always true.
Remove this unnecessary check.
While we're here, the jump statements in this function are largely
defunct now, so remove those as well.
Jani Nikula [Mon, 26 Jan 2026 11:29:25 +0000 (13:29 +0200)]
drm/{i915, xe}/pcode: move display pcode calls to parent interface
Call the parent driver pcode functions through the parent interface
function pointers instead of expecting both to have functions of the
same name.
In i915, add the interface to existing intel_pcode.[ch], while in xe
move them to new display/xe_display_pcode.[ch] and build it only for
CONFIG_DRM_XE_DISPLAY=y.
Do not add separate write and write_timeout calls in the
interface. Instead, handle the default 1 ms timeout in the
intel_parent.c glue layer.
This drops the last intel_pcode.h includes from display, and allows us
to remove the corresponding xe compat header.
Suraj Kandpal [Thu, 22 Jan 2026 04:48:59 +0000 (10:18 +0530)]
drm/i915/cx0: Rename intel_clear_response_ready flag
Rename the non static intel_clear_response_ready_flag to
intel_cx0_clear_response_ready_flag so that we follow the
naming standards of non static function.
Suraj Kandpal [Thu, 22 Jan 2026 04:48:58 +0000 (10:18 +0530)]
drm/i915/cx0: Clear response ready & error bit
Clear the response ready and error bit of PORT_P2M_MESSAGE_BUS_STATUS
before writing the transaction pending bit of
PORT_M2P_MSGBUS_CTL as that is a hard requirement. If not done
we find that the PHY hangs since it ends up in a weird state if left
idle for more than 1 hour.
Jani Nikula [Tue, 20 Jan 2026 15:45:41 +0000 (17:45 +0200)]
drm/{i915, xe}/dsb: move DSB buffer to parent interface
Move the DSB buffer handling to the display parent interface, making
display more independent of i915 and xe driver implementations.
Since the DSB parent interface is only called from intel_dsb.c, add the
wrappers there with smaller visibility instead of the usual
intel_parent.[ch], and using struct intel_dsb as the context parameter
for convenience.
Unfortunately, memset() being a macro in linux/fortify-string.h, we
can't use that as the function pointer name. dsb->memset() would be
using the macro and leading to build failures. Therefore, use .fill()
for the memset() functionality.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:36 +0000 (20:26 +0200)]
drm/i915: Clean up PCI config space reg defines
The PCI config space register defines in i915_drm.h are
a bit of a mess; Whitespace is all over the place, register
masks and values are defined in inconsistent ways.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:33 +0000 (20:26 +0200)]
drm/i915/crt: Use IS0_R instead of VGA_MIS_W
Use the proper IS0_R name for the VGA input status register 0, instead
of using the VGA_MIS_W alias which is meant for write accesses to the
same address. Yes, VGA registers are weird.
Ville Syrjälä [Tue, 9 Dec 2025 07:55:49 +0000 (09:55 +0200)]
video/vga: Add VGA_IS0_R
Add a proper name for the "Input status register 0" IO address.
Currently we have some code that does reads using the aliasing
VGA_MSR_W define, making it unclear what register we're
actually reading.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:30 +0000 (20:26 +0200)]
drm/i915/vga: Introduce intel_vga_{read,write}()
VGA register are rather special since they either get accessed
via the global IO addresses, or possibly through MMIO on
pre-g4x platforms. Wrap all VGA register accesses in
intel_vga_{read,write}() to make it obvious where they get
accessed.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:28 +0000 (20:26 +0200)]
drm/i915/de: Simplify intel_de_read8()
intel_de_read8() is only needed for VGA register MMIO access
by the CRT code on gen2/3. Remove the redundant wakelock stuff,
and add a platform check to make sure this won't get used on
any platform where MMIO VGA register accesses don't work.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:26 +0000 (20:26 +0200)]
drm/i915/vga: Stop trying to use GMCH_CTRL for VGA decode control
intel_gmch_vga_set_state() is a complete lie on ILK+ because
the GMCH_CTRL register is locked and can't actually be written.
But we still need to remove the iGPU from the VGA arbitration
on iGPU+dGPU systems, or else Xorg performance will tank due
to the constant VGA arbiter accesses.
For VGA memory decode we can't turn off the PCI_COMMAND
memory deocde as that would disable even normal MMIO.
Instead we can disable just the VGA memory decode via
the VGA MSR register. And we can do that just once
when disabling the VGA plane. That way we don't have
to touch VGA registers anywhere else.
We can also inform the arbiter that we're no longer decoding
VGA memory. This will stop the arbiter from disabling all
memory decode for the iGPU via PCI_COMMAND (and thus breaking
everything) whenever some other GPU wants to own the VGA memory
accesses.
For IO we can disable all IO decode via the PCI_COMMAND
register, except around the few VGA register accesses that
we need to do in intel_vga_disable(). Unfortunately we can't
disable IO decode permanently as it makes some laptops (eg.
Dell Latitude E5400) hang during reboot/shutdown. One option
would be to re-enable IO decode from the poweroff hooks, but
that won't help the sysrq emergency reboot/shutdown since it
won't call said hooks. So let's try to keep IO decode in its
original setting unless we really need to disable it to
exclude the GPU from VGA arbitration.
I suppose we could keep frobbing GMCH_CTRL on pre-ILK, but
it seems better to not do it since it has other side effects
such as changing the class code of the PCI device.
For discrete GPUs we'll rely on the bridge control instead.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:25 +0000 (20:26 +0200)]
drm/i915/vga: Avoid VGA arbiter during intel_vga_disable() for iGPUs
Avoid using the VGA arbiter during intel_vga_get() for iGPUs because
that will clobber the VGA routing for whatever external GPU is the
current VGA device. That will cause all reads from VGA memory to
come back as 0xff/white, and thus we get a white rectangle on screen
when the external GPU switches from vgacon to fbcon.
The iGPU has the highest VGA decode priority so it will steal all
VGA register accesses whenever its IO decoding is enabled. We'll only
keep the IO decode enabled for a short time so hopefully we don't
end up eating too many unrelated VGA register accesses.
For discrete GPUs we need all the bridges to have their VGA forwarding
bits correctly configured so we can't really avoid the VGA arbiter
there. Although we only do this stuff on dGPUs when the VGA plane was
actaully enabled, so the dGPU should be the current VGA device
and thus have VGA routed to it already anyway.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:24 +0000 (20:26 +0200)]
drm/i915/vga: Clean up VGA registers even if VGA plane is disabled
Turns out at least some systems (eg. HSW Lenovo ThinkCentre E73)
configure the VGA registers even when booting in UEFI mode. So
in order to avoid any issues with the MSR register we should
clean up the VGA registers anyway.
For now this mostly avoids the potential for unclaimed register
accesses due to the power well vs. MDA/CGA selection. But this
will become more important soon as we'll start to rely on the
MSR register to control VGA memory decode as well.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:23 +0000 (20:26 +0200)]
drm/i915/vga: Don't touch VGA registers if VGA decode is fully disabled
On some systems the BIOS will disable the VGA decode logic in the
iGPU (via GMCH_CTRL) when an external GPU is used as the primary
VGA device. In that case the iGPU will never claim any VGA register
accesses, and any access we do will in fact end up on the external
GPU. Don't go poking around in the other GPUs' registers.
Note that (at least on the g4x board where I tested this) the BIOS
forgets to set the VGACNTR VGA_DISP_DISABLE bit, and the reset
value for said bit is 0. That apparently prevents the pipes from
running, so we must still remember to set the bit, despite the VGA
plane was never actually enabled. On more modern platforms (hsw+
maybe?) the reset value for VGACNTR was changed to have
VGA_DISP_DISABLE already set.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:20 +0000 (20:26 +0200)]
drm/i915/vga: Get rid of intel_vga_reset_io_mem()
Remove the MSR VGA register access from the power well hook, and
just do it once in intel_vga_disable().
Turns out that the hardware has two levels of MDA vs. CGA decode
logic: GPU level and display engine level. When we write the MSR
register MDA/CGA mode selection bit both decode logics are updated
accordingly, so that whichever register accessed the GPU claims
will also be claimed by the display engine on the RMbus. If the
two get out of sync the GPU will claim the register accesses but
the display engine will not, leading to RMbus NoClaim errors.
The way to get the two decode logics out of sync is by resetting
the power well housing the VGA stuff, while we are in CGA mode.
At that point only the display engine level decode logic will be
updated with the new MSR register reset value (which selects MDA
mode), and the GPU level decode logic will retain its previous
state (GGA mode). To avoid the mismatch we just have to switch
to MDA mode with an explicit MSR register write.
Currently this is being done in a somewhat dodgy manner whenever
the power well gets enabled. But doing if from the power well
hook is not actually necessary since the GPU level decode logic
will retain its state even when the power well is disabled. Ie.
doing it just the one time is sufficient, and that can be done
when we're anyway writing other VGA registers while disabling
the VGA plane.
See commit f9dcb0dfee98 ("drm/i915: touch VGA MSR after we
enable the power well") for the original details.
Ville Syrjälä [Mon, 8 Dec 2025 18:26:19 +0000 (20:26 +0200)]
drm/i915/vga: Register vgaarb client later
Currently we register to vgaarb way too early. Thus it is
possible that the entire VGA decode logic gets nuked via
GMCH_CTRL before intel_vga_disable() has even disabled the
VGA plane. This could even cause a system hang because
we'll be unable to turn off the VGA plane gracefully.
Move the vgaarb registration into intel_display_driver_register().
I suppose we could do it a bit earlier (after intel_vga_disable()),
but not convinced there's any point.
Also the error handling here is pointless since the
registration can't fail (unless the device isn't a VGA class
in which case all VGA decode logic should aleady be disabled
by the BIOS via GMCH_CTRL). But let's toss in a WARN to catch
any future breakage of vga_client_register().
Ankit Nautiyal [Wed, 14 Jan 2026 02:54:56 +0000 (08:24 +0530)]
drm/i915/gvt_mmio_table: Use the gvt versions of the display macros
Include gvt/display_helpers.h so that the display register macros in
intel_gvt_mmio_table.c expand through the exported display functions.
This lets us keep the existing macro calls while avoiding direct
access to display internals, helping the display modularization work.
Jonathan Cavitt [Wed, 7 Jan 2026 16:29:36 +0000 (16:29 +0000)]
drm/i915/display: Prevent u64 underflow in intel_fbc_stolen_end
Static analysis reveals a potential integer underflow in
intel_fbc_stolen_end. This can apparently occur if
intel_parent_stolen_area_size returns zero (or, theoretically, any value
less than 2^23), as 2^23 is subtracted from the return value and stored
in a u64. While this doesn't appear to cause any issues due to the use
of the min() function to clamp the return values from the
intel_fbc_stolen_end function, it would be best practice to avoid
undeflowing values like this on principle. So, rework the function to
prevent the underflow from occurring. Note that the underflow at
present would result in the value of intel_fbc_cfb_base_max being
returned at the end of intel_fbc_stolen_end, so just return that if the
value of intel_parent_stolen_area_size is too small.
While we're here, fix the other comments here and modify the execution
path for readability.
v2: (Jani)
- Fix the comments in intel_fbc_stolen_end
- Use check_sub_overflow
- Remove macro that mirrors SZ_8M, as it is now only referenced once
- Misc. formatting fixes
Fixes: a9da512b3ed7 ("drm/i915: avoid the last 8mb of stolen on BDW/SKL") Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260107162935.8123-2-jonathan.cavitt@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Mika Kahola [Mon, 19 Jan 2026 09:37:56 +0000 (09:37 +0000)]
drm/i915/display: Remove .clock member from eDP/DP/HDMI pll tables
PLL state structure has a member .clock. This is not needed as
the port clock is possible to calculate from the pll dividers.
Remove the encoder from being passed to the port clock calculation
function.
v2: Keep the pll_state->clock assignment in
intel_snps_hdmi_pll_compute_mpllb().
Mika Kahola [Mon, 19 Jan 2026 09:37:55 +0000 (09:37 +0000)]
drm/i915/lt_phy: Drop 27.2 MHz rate
Drop 27.2 MHz PLL table as with these PLL dividers
the port clock will be incorrectly calculated to 27.0 MHz.
For 27.2 MHz rate the PLl dividers are calculated
algorithmically making PLL table for this rate redundant.
Mika Kahola [Mon, 19 Jan 2026 09:37:54 +0000 (09:37 +0000)]
drm/i915/cx0: Drop C20 25.175 MHz rate
Drop C20 25.175 MHz PLL table as with these
PLL dividers the port clock will be incorrectly
calculated to 25.2 MHz. For 25.175 MHz rate the
PLl dividers are calculated algorithmically making
PLL table for this rate redundant.
Mika Kahola [Mon, 19 Jan 2026 09:37:53 +0000 (09:37 +0000)]
drm/i915/lt_phy: Add verification for lt phy pll dividers
Add verification for lt phy pll dividers during boot. The port clock
is calculated from pll dividers and compared against the requested
port clock value. If there are a difference exceeding +-1 kHz an
drm_warn() is thrown out to indicate possible pll divider mismatch.
v2:
- Move the LT_PHY_PLL_PARAMS -> LT_PHY_PLL_DP/HDMI_PARAMS change
earlier.
- Use tables[i].name != NULL as a terminating condition.
- Use state vs. params term consistently in intel_c10pll_verify_clock()
and intel_c20pll_verify_clock().
Mika Kahola [Mon, 19 Jan 2026 09:37:52 +0000 (09:37 +0000)]
drm/i915/cx0: Verify C10/C20 pll dividers
Add verification for pll table dividers. The port clock
is computed based on pll tables and, for hdmi case, the
algorithmic model is applied to calculate pll dividers.
If port clock differs more than +-1 kHz from expected value
an drm_warn() is thrown and pll divider differences are
printed out for debugging purposes.
v2:
- Move clock derivation from dividers in intel_cx0pll_enable()
earlier in the patchset.
- Keep intel_cx0_pll_power_save_wa() in intel_dpll_sanitize_state()
- Use tables[i].name != NULL as a terminating condition.
- Drop duplicate intel_cx0pll_clock_matches() declaration in header.
- Use state vs. params term consistently in intel_c10pll_verify_clock()
and intel_c20pll_verify_clock().
Mika Kahola [Mon, 19 Jan 2026 09:37:49 +0000 (09:37 +0000)]
drm/i915/display: Add helper function for fuzzy clock check
The hard coded clock rate stored in the PLL state will be removed by
a follow-up change. The clock is calculated instead of
using clock from the PLL divider values. Since this calculated clock
may vary due to fixed point rounding issues, a +-1 kHz variation is
allowed with the request clock rate against the calculated clock rate.
v2:
- Use the stricter +-1 kHz allowed difference.
- Derive the clock from PLL dividers in intel_cx0pll_enable().
- Move corresponding fuzzy check for LT PHY PLLs to this patch.
v3: Reword commit message (Suraj)
Move clock check to intel_dpll and rename it (Suraj)
Mika Kahola [Mon, 19 Jan 2026 09:37:46 +0000 (09:37 +0000)]
drm/i915/cx0: Drop encoder from port clock calculation
For C10 and C20 we have unused encoder parameter passed
to port clock calculation function. Remove the encoder from
being passed to the port clock calculation function.
Mika Kahola [Mon, 19 Jan 2026 09:37:45 +0000 (09:37 +0000)]
drm/i915/lt_phy: Drop LT PHY crtc_state for port calculation
Drop crtc_state from intel_lt_phy_calc_port_clock() function call
and replace it with pll state instead. Follow-up changes will
call these functions without a crtc_state available.
Mika Kahola [Mon, 19 Jan 2026 09:37:44 +0000 (09:37 +0000)]
drm/i915/cx0: Drop Cx0 crtc_state from HDMI TMDS pll divider calculation
Drop crtc_state from HDMI TMDS calculation and replace with the
parameters that are only required. Follow-up changes will call
these functions without a crtc_state available.
v2: Keep required crtc_state param for intel_c20_pll_tables_get()
and other functions calling this one.
Ankit Nautiyal [Thu, 8 Jan 2026 12:41:41 +0000 (18:11 +0530)]
drm/i915/dp: Avoid joiner for eDP if not enabled in VBT
For eDP, enable the Pipe Joiner feature only if VBT explicitly allows it.
If VBT disables the feature, skip joiner for eDP, even if the hardware
supports it.
Add VBT support to enable/disable eDP Pipe Joiner feature.
The OEMs can choose to enable/disable the feature from VBT.
ARL - VBTs default this field to disabled.
PTL+ - VBTs default this field to enabled.
Jouni Högander [Thu, 15 Jan 2026 07:00:39 +0000 (09:00 +0200)]
drm/i915/psr: Don't enable Panel Replay on sink if globally disabled
With some panels informing support for Panel Replay we are observing
problems if having Panel Replay enable bit set on sink when forced to use
PSR instead of Panel Replay. Avoid these problems by not setting Panel
Replay enable bit in sink when Panel Replay is globally disabled during
link training. I.e. disabled by module parameter.
The enable bit is still set when disabling Panel Replay via debugfs
interface. Added note comment about this.
Fixes: 68f3a505b367 ("drm/i915/psr: Enable Panel Replay on sink always when it's supported") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.15+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260115070039.368965-1-jouni.hogander@intel.com
Imre Deak [Wed, 14 Jan 2026 16:22:32 +0000 (18:22 +0200)]
drm/i915/dp: Use intel_dp_dsc_get_slice_config()
Simplify things by computing the detailed slice configuration using
intel_dp_dsc_get_slice_config(), instead of open-coding the same.
While at it add a TODO comment to intel_dp_dsc_compute_config() to
explore if it's worth increasing the number of VDSC stream engines used,
in order to reduce the minimum CDCLK required.
v2: Add a TODO comment to intel_dp_dsc_compute_config() to explore if
it's worth increasing the number of slices in order to use a lower
CDCLK. (Jouni)
Imre Deak [Wed, 14 Jan 2026 16:22:31 +0000 (18:22 +0200)]
drm/i915/dp: Add intel_dp_dsc_get_slice_config()
Add intel_dp_dsc_get_slice_config() to compute the detailed slice
configuration and determine the slices-per-line value (returned by
intel_dp_dsc_get_slice_count()) using this function.
v2: Fix incorrectly returning false from intel_dp_dsc_min_slice_count()
due to rebase fail. (Jouni)
Imre Deak [Wed, 14 Jan 2026 16:22:30 +0000 (18:22 +0200)]
drm/i915/dp: Unify DP and eDP slice count computation
Unify the DP and eDP slices-per-line computation. Atm eDP simply returns
the maximum slices-per-line value supported by the sink, but using the
same helper function for both cases still makes sense, since a follow-up
change will compute the detailed slice config for both cases.
Imre Deak [Wed, 14 Jan 2026 16:22:29 +0000 (18:22 +0200)]
drm/i915/dsi: Use intel_dsc_get_slice_config()
Use intel_dsc_get_slice_config() for DSI to compute the slice
configuration based on the slices-per-line sink capability, instead of
open-coding the same.
Imre Deak [Wed, 14 Jan 2026 16:22:28 +0000 (18:22 +0200)]
drm/i915/dsc: Add intel_dsc_get_slice_config()
Add intel_dsc_get_slice_config() and move the logic to select a given
slice configuration to that function from the configuration loop in
intel_dp_dsc_get_slice_count(). The same functionality can be used by
other outputs like DSI as well, done as a follow-up.
Imre Deak [Wed, 14 Jan 2026 16:22:27 +0000 (18:22 +0200)]
drm/i915/dp: Simplify the DSC slice config loop's slices-per-pipe iteration
Simplify the slice config loop in intel_dp_dsc_get_slice_count(), using
the loop iterator as the slices-per-pipe value directly, instead of
looking up the same value from an array.
While at it move the code comment about the slice configuration closer
to where the configuration is determined and clarify it a bit.
Imre Deak [Wed, 14 Jan 2026 16:22:24 +0000 (18:22 +0200)]
drm/i915/dp: Factor out intel_dp_dsc_min_slice_count()
Factor out intel_dp_dsc_min_slice_count() for making
intel_dp_dsc_get_slice_count() more readable and also to prepare for a
follow-up change unifying the eDP and DP slice count/config computation.
Imre Deak [Wed, 14 Jan 2026 16:22:23 +0000 (18:22 +0200)]
drm/i915/dsc: Switch to using intel_dsc_line_slice_count()
By now all the places are updated to track the DSC slice configuration
in intel_crtc_state::dsc.slice_config, so calculate the slices-per-line
value using that config, instead of using
intel_crtc_state::dsc.slice_count caching the same value and remove
the cached slice_count.
v2: Rebase on latest drm-tip, converting another user of dsc.slice_count
in intel_vdsc_min_cdclk().
Imre Deak [Wed, 14 Jan 2026 16:22:22 +0000 (18:22 +0200)]
drm/i915/dp: Track the detailed DSC slice configuration
Add tracking for the DP DSC pipes-per-line and slices-per-stream value
in the slice config state and compute the current slices-per-line
(slice_count) value using this slice config. The slices-per-line value
used atm will be removed by a follow-up change after converting all the
places using it to use the slice config instead.
For now the slices-per-stream value is calculated based on the
slices-per-line value (slice_count) calculated by the
drm_dp_dsc_sink_max_slice_count() / intel_dp_dsc_get_slice_count()
functions. In a follow-up change these functions will be converted to
calculate the slices-per-stream value directly, along with the detailed
slice configuration.
Imre Deak [Wed, 14 Jan 2026 16:22:21 +0000 (18:22 +0200)]
drm/i915/dsi: Track the detailed DSC slice configuration
Add tracking for the DSI DSC pipes-per-line and slices-per-stream value
in the slice config state and compute the current slices-per-line value
using this slice config state. The slices-per-line value used atm will
be removed by a follow-up change after converting all the places using
it to use the detailed slice config instead.
Imre Deak [Wed, 14 Jan 2026 16:22:20 +0000 (18:22 +0200)]
drm/i915/dsi: Move initialization of DSI DSC streams-per-pipe to fill_dsc()
Move the initialization of the DSI DSC streams-per-pipe value to
fill_dsc() next to where the corresponding (per-line) slice_count value
is initialized. This allows converting the initialization to use the
detailed slice configuration state in follow-up changes.
Imre Deak [Wed, 14 Jan 2026 16:22:18 +0000 (18:22 +0200)]
drm/i915/dsc: Track the detaild DSC slice configuration
Add a way to track the detailed DSC pipes-per-line, streams-per-pipe,
slices-per-stream configuration instead of the current streams-per-pipe
and slices-per-line value. This way describes the slice configuration in
a clearer way, for instance providing a
2 pipes-per-line x 2 streams-per-pipe x 2 slices-per-stream = 8 slices-per-line
view, instead of the current, coarser
2 streams-per-pipe, 8 slices-per-line
view, the former better reflecting that each DSC stream engine has 2
slices. This also let's optimizing the configuration in a
simpler/clearer way, for instance using 1 stream x 2 slices, or 1 stream
x 4 slices instead of the current 2 stream x 1 slice, or 2 streams x 2
slices configuration (so that 1 DSC stream engine can be powered off in
each pipe).
Follow-up changes will convert the current slices-per-line computation
logic to compute instead the above detailed slice configuration.
Imre Deak [Mon, 22 Dec 2025 15:35:47 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing the DSC compressed BPP for DP-MST
The minimum/maximum DSC input (i.e. pipe) and compressed (i.e. link) BPP
limits are computed already in intel_dp_compute_config_limits(), so
there is no need to do this again in
mst_stream_dsc_compute_link_config() called later. Remove the
corresponding alignments from the latter function and use the
precomputed (aligned and within bounds) maximum pipe BPP and the min/max
compressed BPP values instead as-is.
Imre Deak [Mon, 22 Dec 2025 15:35:44 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing forced DSC BPP for DP-SST
If dsc_compute_compressed_bpp() failed with a forced pipe BPP value
(where the forced pipe BPP value itself is valid within the min/max pipe
BPP limits), the function will also fail when called with the maximum
pipe BPP value: dsc_compute_compressed_bpp() will try all compressed
BPPs below the passed in pipe BPP value and if the function failed with
a given (low) compressed BPP value it will also fail with a compressed
BPP value higher than the one which failed already.
Based on the above remove the logic to retry computing a compressed BPP
value with the maximum pipe BPP value if computing the compressed BPP
failed already with the (lower) forced pipe BPP value.
Imre Deak [Mon, 22 Dec 2025 15:35:43 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing DSC BPPs for DP-SST
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_dp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Also, there is no point in trying pipe BPP values lower than the
maximum: this would only make dsc_compute_compressed_bpp() start with a
lower _compressed_ BPP value, but this lower compressed BPP value has
been tried already when dsc_compute_compressed_bpp() was called with the
higher pipe BPP value (i.e. the first dsc_compute_compressed_bpp() call
tries already all the possible compressed BPP values which are all below
the pipe BPP value passed to it). Simplify the function accordingly
trying only the maximum pipe BPP value.
Imre Deak [Mon, 22 Dec 2025 15:35:42 +0000 (17:35 +0200)]
drm/i915/dp: Simplify computing DSC BPPs for eDP
The maximum pipe BPP value (used as the DSC input BPP) has been aligned
already to the corresponding source/sink input BPP capabilities in
intel_dp_compute_config_limits(). So it isn't needed to perform the same
alignment again in intel_edp_dsc_compute_pipe_bpp() called later, this
function can simply use the already aligned maximum pipe BPP value, do
that.
Imre Deak [Mon, 22 Dec 2025 15:35:41 +0000 (17:35 +0200)]
drm/i915/dp: Use helpers to align min/max compressed BPPs
The minimum/maximum compressed BPP values are aligned/bounded in
intel_dp_compute_link_bpp_limits() to the corresponding source limits.
The minimum compressed BPP value doesn't change afterwards, so no need
to align it again, remove that.
The maximum compressed BPP, which depends on the pipe BPP value still
needs to be aligned, since the pipe BPP value could change after the
above limits were computed, via intel_dp_force_dsc_pipe_bpp(). Use the
corresponding helper for this alignment instead of open-coding the same.
Imre Deak [Mon, 22 Dec 2025 15:35:40 +0000 (17:35 +0200)]
drm/i915/dp: Unify detect and compute time DSC mode BW validation
Atm, a DP DSC video mode's required BW vs. the available BW is
determined by calculating the maximum compressed BPP value allowed by
the available BW. Doing that using a closed-form formula as it's done
atm (vs. an iterative way) is problematic, since the overhead of the
required BW itself depends on the BPP value being calculated. Instead of
that calculate the required BW for the minimum compressed BPP value
supported both by the source and the sink and check this BW against the
available BW. This change also aligns the BW calculation during mode
validation with how this is done during state computation, calculating
the required effective data rate with the corresponding BW overhead.
Imre Deak [Mon, 22 Dec 2025 15:35:39 +0000 (17:35 +0200)]
drm/i915/dp: Add intel_dp_mode_valid_with_dsc()
Add intel_dp_mode_valid_with_dsc() and call this for an SST/MST mode
validation to prepare for a follow-up change using a way to verify the
mode's required BW the same way this is done elsewhere during state
computation (which in turn depends on the mode's effective data rate
with the corresponding BW overhead).
Imre Deak [Mon, 22 Dec 2025 15:35:35 +0000 (17:35 +0200)]
drm/i915/dp: Pass intel_output_format to intel_dp_dsc_sink_{min_max}_compressed_bpp()
Prepare for follow-up changes also calling
intel_dp_dsc_min_sink_compressed_bpp() /
intel_dp_dsc_max_sink_compressed_bpp_x16()
without an intel_crtc_state.
While at it remove the stale function declarations from the header file.
Imre Deak [Mon, 22 Dec 2025 15:35:34 +0000 (17:35 +0200)]
drm/i915/dp: Drop intel_dp parameter from intel_dp_compute_config_link_bpp_limits()
The intel_dp pointer can be deducted from the connector pointer, so it's
enough to pass only connector to
intel_dp_compute_config_link_bpp_limits(), do so.
projects / thirdparty / kernel / linux.git / log
