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.
Imre Deak [Mon, 22 Dec 2025 15:35:33 +0000 (17:35 +0200)]
drm/i915/dp: Align min/max compressed BPPs when calculating BPP limits
Align the minimum/maximum DSC compressed BPPs to the corresponding
source compressed BPP limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Imre Deak [Mon, 22 Dec 2025 15:35:32 +0000 (17:35 +0200)]
drm/i915/dp: Align min/max DSC input BPPs to sink caps
Align the minimum/maximum DSC input BPPs to the corresponding sink DSC
input BPP capability limits already when computing the BPP limits. This
alignment is also performed later during state computation, however
there is no reason to initialize the limits to an unaligned/incorrect
value.
Ben Dooks [Thu, 8 Jan 2026 20:12:03 +0000 (15:12 -0500)]
drm/i915/guc: make 'guc_hw_reg_state' static as it isn't exported
The guc_hw_reg_state array is not exported, so make it static.
Fixes the following sparse warning:
drivers/gpu/drm/i915/i915_gpu_error.c:692:3: warning: symbol 'guc_hw_reg_state' was not declared. Should it be static?
Fixes: ba391a102ec11 ("drm/i915/guc: Include the GuC registers in the error state") Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260108201202.59250-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Gustavo Sousa [Tue, 6 Jan 2026 21:40:21 +0000 (18:40 -0300)]
drm/i915/cdclk: Incorporate Xe3_LPD changes for CD2X divider
On Xe3_LPD, there is no instruction to program the CD2X divider anymore
and the hardware is expected to always use the default value of 0b00,
meaning "divide by 1".
With that, the CDCLK_CTL register was changed so that:
(1) The field "CD2X Divider Select" became a debug-only field.
Because we are programming CDCLK_CTL with a direct write instead
of read-modify-write operation, we still need to program "CD2X
Divider Select" in order to keep the field from deviating from its
default value. Let's, however, throw a warning if we encounter a
CDCLK value that would result in an unexpected value for that
field.
(2) The field "CD2X Pipe Select" has been removed. In fact, some
debugging in a PTL machine showed that such field comes back as
zero after writing a non-zero value to it. As such, do not
program it starting with Xe3_LPD.
Fix kernel-doc warnings on struct intel_lb_component_ops:
Warning: include/drm/intel/intel_lb_mei_interface.h:55 Incorrect use of
kernel-doc format: * push_payload - Sends a payload to the
authentication firmware
And a bunch more. There isn't really support for documenting function
pointer struct members in kernel-doc, but at least reference the member
properly.
Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver") Cc: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260107160226.2381388-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Suraj Kandpal [Mon, 5 Jan 2026 05:59:37 +0000 (11:29 +0530)]
drm/i915/ltphy: Provide protection against unsupported modes
We need to make sure we return some port clock in case we have
unsupported LT PHY modes or if we were not able to read the LT PHY state
for whatever reason and the mode ends up being 0.
projects / thirdparty / kernel / linux.git / log
