Jani Nikula [Mon, 1 Dec 2025 17:10:50 +0000 (19:10 +0200)]
drm/xe/compat: remove unused i915_active.h and i915_active_types.h
Commit 965930962a41 ("drm/i915/frontbuffer: Fix intel_frontbuffer
lifetime handling") dropped the last xe display users of the
headers. They're still used in intel_overlay.c, but it's not built as
part of xe.
Jani Nikula [Tue, 25 Nov 2025 13:24:43 +0000 (15:24 +0200)]
drm/{i915,xe}/display: drop intel_wakeref.h usage
Drop the display dependency on intel_wakeref.h header. The contract in
the parent interface is that -ENOENT means there's no tracking. It
doesn't actually require us to use a shared macro for it. Duplicate the
macro in the few places that need this instead of inlining, primarily
for documentation reasons.
This allows us to remove the xe compat intel_wakeref.h header.
v2: Define INTEL_WAKEREF_DEF in intel_display_power.h
Jani Nikula [Tue, 25 Nov 2025 13:24:42 +0000 (15:24 +0200)]
drm/i915/power: convert intel_wakeref_t to struct ref_tracker *
Under the hood, intel_wakeref_t is just struct ref_tracker *. Use the
actual underlying type both for clarity (we *are* using intel_wakeref_t
as a pointer though it doesn't look like one) and to help i915, xe and
display coexistence without custom types.
Jani Nikula [Tue, 25 Nov 2025 13:24:41 +0000 (15:24 +0200)]
drm/i915/power: drop wakeref parameter from with_intel_display_power*()
Add another level of macro abstraction, and declare the wakeref within
the for loop using __UNIQUE_ID. This allows us to drop a bunch of
boilerplate declarations and parameter passing.
Jani Nikula [Tue, 25 Nov 2025 13:24:40 +0000 (15:24 +0200)]
drm/i915/pps: convert intel_wakeref_t to struct ref_tracker *
Under the hood, intel_wakeref_t is just struct ref_tracker *. Use the
actual underlying type both for clarity (we *are* using intel_wakeref_t
as a pointer though it doesn't look like one) and to help i915, xe and
display coexistence without custom types.
Jani Nikula [Tue, 25 Nov 2025 13:24:39 +0000 (15:24 +0200)]
drm/i915/pps: drop wakeref parameter from with_intel_pps_lock()
Add another level of macro abstraction, and declare the wakeref within
the for loop using __UNIQUE_ID. This allows us to drop a bunch of
boilerplate declarations and parameter passing.
Michał Grzelak [Mon, 17 Nov 2025 08:20:46 +0000 (09:20 +0100)]
i915/display/intel_ddi: Reduce severity of failed FEC enabling
During some IGT tests (e.g. xe_pm@s2idle-exec-after, xe_pm@s2idle-mocs)
sink disconnects across suspend/resume, reconnecting later during resume
at some point. Hence during resume, where the driver is restoring the
pre-suspend mode, all the AUX transfers to the sink are expected to
fail.
Switch error message to KMS debug message of failed FEC enabling.
Jani Nikula [Wed, 26 Nov 2025 11:11:23 +0000 (13:11 +0200)]
drm/xe/dsb: drop the unnecessary struct i915_vma
Now that struct intel_dsb_buffer is opaque, it can be made unique to
both drivers, and we can drop the unnecessary struct i915_vma part. Only
the struct xe_bo part is needed.
Jani Nikula [Wed, 26 Nov 2025 11:11:20 +0000 (13:11 +0200)]
drm/{i915, xe}/dsb: make {intel, xe}_dsb_buffer.c independent of display
The DSB buffer implementation is really independent of display. Pass
struct drm_device instead of struct intel_crtc to
intel_dsb_buffer_create(), and drop the intel_display_types.h include.
The switch from AUX interrupts to pollign was very hand-wavy.
Yes, there have been some situations in CI on a few platforms
where the AUX hardware seemingly forgets to signal the timeout,
but those have been happening after we switched to polling as
well. So I don't think we have any conclusive evidence that
polling actually helps here.
Someone really should root cause the actual problem, and see
if there is a proper workaround we could implemnt (eg. disabling
clock gating/etc.). In the meantime just go back to using the
interrupt for AUX completion.
If the hardware fails to signal the timeout we will just hit
the wait_event_timeout() software timeout instead. I suppose
we could try to tune the software timeout to more closely
match the expected hardware timeout. Might need to use
wait_event_hrtimeout() or something to avoid jiffies
granularity issues...
The AUX polling is also a hinderance towards using poll_timeout_us()
because we have a very long timeout, but would need a fairly short
polling interval to keep AUX transfer reasonably fast. Someone would
need to come up with good numbers in a somewhat scientific way.
Ville Syrjälä [Wed, 19 Nov 2025 18:53:09 +0000 (20:53 +0200)]
drm/i915: Enable DDI A/B AUX interrupts on LNL+
Apparently the DDI A/B AUX interrupts move onto the PICA side
on LNL. Unmask them properly so that we actually get the
interrupts. The interrupt handler was already trying to handle
them despite the interrupts remaining masked.
Ville Syrjälä [Wed, 12 Nov 2025 23:30:30 +0000 (01:30 +0200)]
drm/i915: Eliminate one more frequent drm_format_info()
Another (somewhat expensive) drm_format_info() call has
appeared in intel_plane_can_async_flip(). That one may get
called several times per commit so we need to get rid of
it.
Fortunately most callers already have the framebuffer at
hand, so we can just grab the format info from there.
The one exception is intel_plane_format_mod_supported_async()
where we have to do the lookup. But that only gets called
(a bunch of times) during driver init to build the
IN_FORMATS_ASYNC blob, and afterwards there is no runtime
cost.
Ville Syrjälä [Wed, 12 Nov 2025 23:30:29 +0000 (01:30 +0200)]
drm/i915: Expose the IN_FORMATS_ASYNC blob for all planes
Since old kernel versions wouldn't expose the IN_FORMATS_ASYNC blob,
userspace can't really use the absence of the blob to determine
that async flips aren't supported. Thus it seems better to always
expose the blob on all planes, whether they support async flips
or not. The blob will simply not indicate any format+modifier
combinations as supported on planes that aren't async flip capable.
Currently we expose the blob for all skl+ universal planes (even
though we implement async flips only for the first plane on each
pipe), and i9xx primary planes (for ilk+ we have async flips support,
for pre-ilk we do not). Complete the full set by also expsosing
the blob on pre-skl sprite planes, and cursors.
Ville Syrjälä [Wed, 19 Nov 2025 18:16:05 +0000 (20:16 +0200)]
drm/i915/panic: Get the crtc from the correct place
Use hw.crtc as opposed to uapi.crtc in the panic code. I suspect
this stuff doesn't handle joiner correctly in other ways either
but can't be bothered to dig deeper.
Ville Syrjälä [Wed, 19 Nov 2025 18:16:02 +0000 (20:16 +0200)]
drm/i915/psr: Use hw.crtc instead of uapi.crtc
uapi.crtc is not set for joiner secondary pipes, so generally
should not be used anywhere after the initial state copy. Switch
to hw.crtc which actually indicates that the plane is enabled.
Ville Syrjälä [Wed, 19 Nov 2025 18:16:01 +0000 (20:16 +0200)]
drm/i915: Use the proper (hw.crtc) for the cursor unpin vblank worker
uapi.crtc is NULL for joiner secondary pipes, so using that is
nonsense in most places. Switch to hw.crtc so that we use the
deferred cursor unpin also on joiner secondary pipes.
Jani Nikula [Fri, 21 Nov 2025 11:22:00 +0000 (13:22 +0200)]
drm/i915: use struct drm_device for clock gating funcs
While we want to refactor intel_clock_gating.[ch] and likely move a lot
of display related code to display, start off with a little intermediate
change to use struct drm_device in the interface instead of struct
drm_i915_private, to allow us to drop another dependency on i915_drv.h
and struct drm_i915_private.
Imre Deak [Thu, 20 Nov 2025 17:23:58 +0000 (19:23 +0200)]
drm/i915/cx0: Read out power-down state of both PHY lanes for reversed lanes
For a port used with lane reversal enabled the first two TX lanes will
be enabled in PHY lane#1 instead of PHY lane#0. At the moment the HW
readout will read out the power-down state for these two TX lanes from
PHY lane#0 incorrectly. The display HW lane reversal feature (vs. the
similar TCSS lane swap) is only used for TypeC legacy mode and for
non-TypeC PHYs. Since in both of these cases the display owns both PHY
lanes, both of these PHY lanes' state can be read out. Do that to fix
cases when lane reversal is used with 1 or 2 active TX lanes.
While at it add an assert to the PLL enable function about the above
assumption on when lane reversal can be used.
Cc: Mika Kahola <mika.kahola@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Fixes: 230d4c748113 ("drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL state") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-5-imre.deak@intel.com
Imre Deak [Thu, 20 Nov 2025 17:23:57 +0000 (19:23 +0200)]
drm/i915/cx0: Read out power-down state of both TXs in PHY lane 0
If the number of used lanes is 1 or 2 then the power-down state of both
TX lanes in PHY lane 0 should be read out. If 1 lane is used only 1 TX
lane will be checked, make sure both TXs are checked in this case.
Cc: Mika Kahola <mika.kahola@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Fixes: 230d4c748113 ("drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL state") Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251120172358.1282765-4-imre.deak@intel.com
Imre Deak [Thu, 20 Nov 2025 17:23:55 +0000 (19:23 +0200)]
drm/i915/tc: Add separate intel_tc_phy_port_to_tc() for TC DDI/PHY ports
intel_port_to_tc() returns the PORT_TC1..6 -> TC_PORT_1..6 mapping only
for DDI ports that are connected to a TypeC PHY. In some cases this
mapping is also required for TypeC DDI ports which are not connected to
a TypeC PHY. Such DDI ports are the PORT_TC1..4 ports on RKL/ADLS/BMG.
Add a separate intel_tc_phy_to_tc() helper to return the mapping for
ports connected to a TypeC PHY, and make all the current users - which
expect this semantic - call this helper. A follow-up change will need to
get the same mapping for TypeC DDI ports not connected to a TypeC PHY,
leave intel_port_to_tc() exported for that.
Imre Deak [Thu, 20 Nov 2025 17:23:54 +0000 (19:23 +0200)]
drm/i915/cx0: Fix port to PLL ID mapping on BMG
The intel_port_to_tc() call in mtl_port_to_pll_id() assumed that all
TypeC DDI ports are connected to a TypeC PHY. This is not true on BMG
where all the ports - including the PORT_TC1..4 TypeC DDI ports - are
connected to a non-TypeC PHY. For these ports intel_port_to_tc()
returns TC_PORT_NONE, which results in an incorrect port -> PLL ID
mapping. Fix this up by using the expected PORT_TC1..4 port ->
TC_PORT_1..4 tc_port mapping on BMG as well.
Ville Syrjälä [Wed, 5 Nov 2025 17:10:15 +0000 (19:10 +0200)]
drm/i915/psr: Reject async flips when selective fetch is enabled
The selective fetch code doesn't handle asycn flips correctly.
There is a nonsense check for async flips in
intel_psr2_sel_fetch_config_valid() but that only gets called
for modesets/fastsets and thus does nothing for async flips.
Currently intel_async_flip_check_hw() is very unhappy as the
selective fetch code pulls in planes that are not even async
flips capable.
Reject async flips when selective fetch is enabled, until
someone fixes this properly (ie. disable selective fetch while
async flips are being issued).
Jani Nikula [Wed, 19 Nov 2025 18:52:51 +0000 (20:52 +0200)]
drm/i915: merge soc/intel_gmch.[ch] to display/intel_vga.c
The sole user of the remaining functions in intel_gmch.[ch] is in
intel_vga.c. Move everything there.
Since intel_gmch.c hasn't been part of xe, use a dummy function
relocated from xe_display_misc.c, with #ifdef. This is purely to keep
this change non-functional.
This allows us to remove soc/intel_gmch.[ch] from i915, compat
soc/intel_gmch.h from xe, and xe_display_misc.c from xe.
Jani Nikula [Wed, 19 Nov 2025 18:52:50 +0000 (20:52 +0200)]
drm/i915/gmch: convert intel_gmch.c to struct intel_display
Convert intel_gmch.[ch] to struct intel_display. Remove the final
dependency on struct drm_i915_private and i915_drv.h. This is in
preparation of moving the code under display/.
intel_gmch_vga_set_state() is only used internally, make it static while
at it.
Jani Nikula [Wed, 19 Nov 2025 18:52:47 +0000 (20:52 +0200)]
drm/xe: remove remaining platform checks from compat i915_drv.h
With xe no longer building anything from soc/, we can remove the compat
platform checks from i915_drv.h, reducing the file to just the to_i915()
pointer conversion helper.
Jani Nikula [Thu, 20 Nov 2025 16:18:46 +0000 (18:18 +0200)]
drm/i915/dram: convert to struct intel_display
Convert everything except uncore access to struct
intel_display. Converting the graphics version checks to display version
checks needs a tweak for display version 13, which have graphics version
12.
Jani Nikula [Wed, 19 Nov 2025 18:52:41 +0000 (20:52 +0200)]
drm/i915: split out i915_freq.[ch]
The i915 core only needs three rather specific functions from
soc/intel_dram.[ch]: i9xx_fsb_freq(), ilk_fsb_freq(), and
ilk_mem_freq(). Add new i915_freq.[ch] and duplicate those functions for
i915 to reduce the dependency on soc/ code.
Wile duplication in general is bad, here it's a tradeoff to simplify the
i915, xe and display interactions.
Jani Nikula [Wed, 19 Nov 2025 18:52:40 +0000 (20:52 +0200)]
drm/i915/edram: extract i915_edram.[ch] for edram detection
While edram detection ostensibly belongs with the rest of the dram stuff
in soc/intel_dram.c, it's only required by i915 core, not
display. Extract it to a separate i915_edram.[ch] file.
This allows us to drop the edram_size_mb member from struct xe_device.
Jani Nikula [Mon, 17 Nov 2025 09:16:17 +0000 (11:16 +0200)]
drm/xe/rps: build RPS as part of xe
Reduce the conditional compilation in i915 by building
intel_display_rps.c as part of the xe module. This doesn't actually
enable RPS on xe, because there's no parent interface implementation on
xe side, but it's a step in the right direction.
Jani Nikula [Mon, 17 Nov 2025 09:16:10 +0000 (11:16 +0200)]
drm/{i915,xe}/display: move irq calls to parent interface
Add an irq parent driver interface for the .enabled and .synchronize
calls. This lets us drop the dependency on i915_drv.h and i915_irq.h in
multiple places, and subsequently remove the compat i915_irq.h and
i915_irq.c files along with the display/ext directory from xe
altogether.
Introduce new intel_parent.[ch] as the wrapper layer to chase the
function pointers and convert between generic and more specific display
types.
v2: Keep static wrappers in intel_display_irq.c (Ville)
v3: Full blown wrappers in intel_parent.[ch] (Ville)
Jani Nikula [Mon, 17 Nov 2025 09:16:08 +0000 (11:16 +0200)]
drm/{i915, xe}/display: duplicate gen2 irq/error init/reset in display irq
Duplicate gen2_irq_reset(), gen2_assert_iir_is_zero(), gen2_irq_init(),
gen2_error_reset(), and gen2_error_init() in intel_display_irq.c.
This allows us to drop the duplicates from xe, and prepares for future
cleanups. Although duplication is undesirable in general, in this case
the local duplicates lead to a cleaner end result.
There's a slight wrinkle in gen2_assert_iir_is_zero(). We need to use
non-device based logging until we pass in struct intel_display in a
separate change.
v2:
- Keep xe compat stuff due to series reorder and rebase
- Keep the WARN as regular WARN
- Rename the functions in the same go
Ville Syrjälä [Wed, 29 Oct 2025 20:42:15 +0000 (22:42 +0200)]
drm/i915/dram: Fix ICL DIMM_S decoding
Unfortunately the MAD_DIMM DIMM_S and DIMM_L bits on ICL are
not idential, so we are currently decoding DIMM_S incorrectly.
Fix the problem by defining the DIMM_S and DIMM_L bits separately.
And for consistency do that same for SKL, even though there the
bits do match between the two DIMMs. The result is rather
repetitive in places, but I didn't feel like obfuscatign things
with cpp macros/etc.
Broken decoding on Dell XPS 13 7390 2-in-1:
CH0 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH0 DIMM S size: 32 Gb, width: X32, ranks: 3, 16Gb+ DIMMs: no
CH0 ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM S size: 32 Gb, width: X32, ranks: 3, 16Gb+ DIMMs: no
CH1 ranks: 2, 16Gb+ DIMMs: no
Memory configuration is symmetric? no
Fixed decoding on Dell XPS 13 7390 2-in-1:
CH0 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH0 DIMM S size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH0 ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM L size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH1 DIMM S size: 32 Gb, width: X16, ranks: 2, 16Gb+ DIMMs: no
CH1 ranks: 2, 16Gb+ DIMMs: no
Memory configuration is symmetric? yes
Mika Kahola [Tue, 18 Nov 2025 13:28:59 +0000 (15:28 +0200)]
drm/i915/cx0: Enable dpll framework for MTL+
MTL+ platforms are supported by dpll framework remove a separate
check for hw comparison and rely solely on dpll framework
hw comparison.
Finally, all required hooks are now in place so initialize
PLL manager for MTL+ platforms and remove the redirections
to the legacy code paths from the following interfaces:
v2: Rebase on !HAS_LT_PHY check in intel_ddi_update_active_dpll()
v3: Rebase on !display->dpll.mgr check in intel_ddi_update_active_dpll()
Add check for NVL as the platform is not part of pll framework (Suraj)
Imre Deak [Mon, 17 Nov 2025 10:46:01 +0000 (12:46 +0200)]
drm/i915/cx0: Add MTL+ Thunderbolt PLL hooks
Add the PLL hooks for the TBT PLL on MTL+. These are simple stubs
similarly to the TBT PLL on earlier platforms, since this PLL is always
on from the display POV - so no PLL enable/disable programming is
required as opposed to the non-TBT PLLs - and the clocks for different
link rates are enabled/disabled at a different level, via the
intel_encoder::enable_clock()/disable_clock() interface.
Mika Kahola [Mon, 17 Nov 2025 10:46:00 +0000 (12:46 +0200)]
drm/i915/cx0: Get encoder configuration for C10 and C20 PHY PLLs
For DDI initialization get encoder configuration for C10 and C20
chips.
v2: Get configuration either for a C10 or on the PTL port B
eDP on TypeC PHY case for a C20 PHY PLL. Hence refer to this
case as "non_tc_phy" instead of "c10phy".
Mika Kahola [Mon, 17 Nov 2025 10:45:53 +0000 (12:45 +0200)]
drm/i915/cx0: Add MTL+ .dump_hw_state hook
Add .dump_hw_state function pointer for MTL+ platforms
to support dpll framework. While at it, switch to use
drm_printer structure to print hw state information.
v2: Keep debug messages on one line if they not
necessarily needed to split into two or more
lines (Suraj)
Mika Kahola [Mon, 17 Nov 2025 10:45:49 +0000 (12:45 +0200)]
drm/i915/cx0: Add MTL+ .get_dplls hook
Add .get_dplls function pointer for MTL+ platforms
to support dpll framework. Reuse the ICL function
pointer.
v2: Getting configuration either for a C10 or on the PTL port B
eDP on TypeC PHY case for a C20 PHY PLL. Hence refer to this
case as "non_tc_phy" instead of "c10phy".
v3: Fix comment to "eDP over TypeC" (Suraj)
Fix pll id as separate variable (Suraj)
Mika Kahola [Mon, 17 Nov 2025 10:45:48 +0000 (12:45 +0200)]
drm/i915/cx0: Compute plls for MTL+ platform
To bring MTL+ platform aligned call and calculate PLL state
from dpll framework.
v2: Rename mtl_compute_c10phy_dpll() to mtl_compute_non_tc_phy_dpll().
The state is computed either for a C10 or on the PTL port B eDP
over TypeC PHY case for a C20 PHY PLL. Hence refer to this case as
"non_tc_phy" instead of "c10phy".
Rename mtl_compute_c20phy_dplls() to mtl_compute_tc_phy_dplls() for
symmetry with mtl_compute_non_tc_phy_dpll().
v3: Reword commit message (Suraj)
Mika Kahola [Mon, 17 Nov 2025 10:45:47 +0000 (12:45 +0200)]
drm/i915/cx0: Update C10/C20 state calculation
Update several functions in intel_cx0_phy.c to make PLL state
management more explicit.
Changes include
* add 'const' qualifiers to intel_crtc_state parameter for
cx0 state calculation functions
* refactor C10/C20 PLL state calculations helpers to take
explicit hardware state pointers instead of directly modifying
'crtc_state->dpll_hw_state'
Imre Deak [Mon, 17 Nov 2025 10:45:43 +0000 (12:45 +0200)]
drm/i915/cx0: Zero Cx0 PLL state before compute and HW readout
Ensure Cx0 pll state is initialized to zero before any computation or HW
readouts, to prevent leaving some parameter in the state uninitialized
in the actual compute/HW readout functions later.
Imre Deak [Mon, 17 Nov 2025 10:45:42 +0000 (12:45 +0200)]
drm/i915/cx0: Determine Cx0 PLL port clock from PLL state
The port clock is tracked in the PLL state, so there is no need to pass
it separately to __intel_cx0pll_enable(). Drop the port clock function
param accordingly.
Imre Deak [Mon, 17 Nov 2025 10:45:41 +0000 (12:45 +0200)]
drm/i915/cx0: Determine Cx0 PLL DP mode from PLL state
The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI
mode. The PLL manager framework doesn't pass the CRTC state to the PLL's
enable hook, so prepare here for the conversion to use the PLL manager
for Cx0 PHY PLLs by determining the DP/HDMI mode from the PLL state.
For C10 PHYs use the fact that the HDMI divider value in the PLL
registers are set if and only if the PLL is in HDMI mode.
For C20 PHYs use the DP mode flag programmed to the VDR SERDES register,
which is set if and only if the PLL is in DP mode.
Assert that the above PLL/VDR SERDES register values match the DP/HDMI
mode being configured already during state computation.
This also allows dropping the is_dp param from the
__intel_cx0pll_enable() function, since it can retrieve this now from
the PLL state.
Imre Deak [Mon, 17 Nov 2025 10:45:40 +0000 (12:45 +0200)]
drm/i915/cx0: Read out the Cx0 PHY SSC enabled state
Read out the C10, C20 PHY PLLs SSC enabled state, so the PLL HW/SW state
verification can check this state as well.
C10 PHY PLLs program some PLL registers zeroed out for the non-SSC case,
while programming non-zero values to the same registers for the SSC
case, so check that these PLL registers being zero or non-zero matches
the PLL's overall SSC-enabled state (stored in the
intel_c10pll_state::ssc_enabled flag).
Imre Deak [Mon, 17 Nov 2025 10:45:38 +0000 (12:45 +0200)]
drm/i915/cx0: Track the Cx0 PHY enabled lane count in the PLL state
The Cx0 PLL enable programming requires the enabled lane count. The PLL
manager framework doesn't pass the CRTC state to the PLL's enable hook,
so prepare here for the conversion to use the PLL manager, by tracking
the enabled lane count in the PLL state as well. This has the advantage,
that the enabled lane count can be verified against the PHY/PLL's
enabled TX lanes.
This also allows dropping the lane count param from the
__intel_cx0pll_enable() function, since it can retrieve this now from
the PLL state.
Imre Deak [Mon, 17 Nov 2025 10:45:37 +0000 (12:45 +0200)]
drm/i915/cx0: Add macro to get DDI port width from a register value
A follow-up change will need to retrieve the DDI port field from the
register value, add a macro for this. Make things symmetric with setting
the field in the register.
Imre Deak [Mon, 17 Nov 2025 10:45:36 +0000 (12:45 +0200)]
drm/i915/cx0: Move definition of Cx0 PHY functions earlier
Move the definitions of the
intel_c10pll_calc_port_clock()
intel_c20_get_dp_rate()
intel_c20_get_hdmi_rate()
is_hdmi_frl()
is_dp2()
intel_get_c20_custom_width()
functions earlier to avoid the forward declarations.
Imre Deak [Mon, 17 Nov 2025 10:45:35 +0000 (12:45 +0200)]
drm/i915/cx0: Track the C20 PHY VDR state in the PLL state
The Cx0 PLL enable programming needs to know if the PLL is in DP or HDMI
mode. The PLL manager framework doesn't pass the CRTC state to the PLL's
enable hook, so prepare here for the conversion to use the PLL manager
for Cx0 PHY PLLs by tracking the DP/HDMI mode in the PLL state.
This change has the advantage, that the VDR HW/SW state can be verified
now.
A follow up change will convert the PLL enable function to retrieve the
DP/HDMI mode parameter from the PLL state.
This also allows dropping the is_dp and port clock params from the
intel_c20_pll_program() function, since it can retrieve these now from
the PLL state.
v2: Fix comment to under same multicomment line (Suraj)
Imre Deak [Mon, 17 Nov 2025 10:45:34 +0000 (12:45 +0200)]
drm/i915/cx0: Sanitize calculating C20 PLL state from tables
A follow up change adds a computation for the C20 PLL VDR state, which
is common to both the HDMI algorithmic and DP/HDMI table based method.
To prepare for that streamline the code. The C10 counterpart would
benefit from the same change, leave that for later adding a TODO
comment.
Imre Deak [Mon, 17 Nov 2025 10:45:33 +0000 (12:45 +0200)]
drm/i915/cx0: Sanitize setting the Cx0 PLL use_c10 flag
Sanitize setting the Cx0 PLL use_c10 flag during state computation and
HW readout, making sure they happen the same way in the
intel_c{10,20}pll_calc_state() and intel_c{10,20}pll_readout_hw_state()
functions.
Follow-up changes will add more state computation/HW readout, this
change prepares for those as well.
Jonathan Cavitt [Tue, 4 Nov 2025 16:41:51 +0000 (16:41 +0000)]
drm/i915/display: Add default case to mipi_exec_send_packet
Add a default case to the switch case statement in mipi_exec_send_packet
to prevent attempts to read an uninitialized ret value. It's unlikely
the default case will ever occur during regular exeuction, but if more
MIPI DSI Processor-to-Peripheral transaction types are ever added, then
having this in place will be a useful safety guard.
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Fixes: 23db1577ce2d ("drm/i915/dsi: log send packet sequence errors") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20251104164150.16795-2-jonathan.cavitt@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Fri, 7 Nov 2025 18:11:24 +0000 (20:11 +0200)]
drm/i915: Use mode_config->cursor_width for cursor DDB allocation
Replace the hardcoded 256 with mode_config->cursor_width
when doing the cursor DDB allocation. Currently 256 is correct
for all SKL+, but this might change in the future. One less place
to change should that happen.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:23 +0000 (20:11 +0200)]
drm/i915/wm: Use drm_get_format_info() in SKL+ cursor DDB allocation
Replace the technically inaccurate drm_format_info() with the
accurate drm_get_format_info() in the SKL+ cursor DDB
allocation code.
Since we're only interested in the linear modifier here, the two
functions do actually return the same information. But let's not
use drm_format_info() to avoid setting a bad example.
Ville Syrjälä [Fri, 7 Nov 2025 18:11:22 +0000 (20:11 +0200)]
drm/i915/fb: Init 'ret' in each error branch in intel_framebuffer_init()
Make the order of things a bit less fragile in
intel_framebuffer_init() by assigning 'ret' in each
error branch instead of depending on some earlier
assignment.
projects / thirdparty / kernel / linux.git / log
