drm/i915/xe3p_lpd: Enable display use of system cache for FBC
One of the FBC instances can utilize the reserved area of SoC
level cache for the fbc transactions to benefit reduced memory
system power especially in idle scenarios. Reserved area of the
system cache can be assigned to an fbc instance by configuring
the cacheability configuration register with offset of the
compressed frame buffer in stolen memoty of that fbc. There is
a limit to this reserved area which is programmable and for
xe3p_lpd the limit is defined as 2MB. The first FBC instance
enabled will utilize the system cache as of now.
v2: - better to track fbc sys cache usage from intel_display level,
sanitize the cacheability config register on probe (Matt)
- limit this for integrated graphics solutions, confirmed that
no default value set for cache range by hw (Gustavo)
v3: - changes related to the use of fbc substruct in intel_display
- use intel_de_write() instead of intel_rmw() by hardcoding the
default value fields
v4: - protect sys cache config accesses, sys cache usage status in
debugfs per fbc instance (Jani)
v5: - mutex_init and missing mutex_lock in sanitize call
v6: - changes to commit message and some obvious comments removed
drm/i915/display: Use a sub-struct for fbc operations in intel_display
As FBC can utilize the system cache in xe3p_lpd onwards, we need
a provision to track which fbc instance is utilizing this cache.
A sub-struct at intel_display level to group all the fbc ops will
make fbc handling much easier. Introduce a fbc sub-struct and move
the fbc instance array into that.
Gustavo Sousa [Tue, 2 Dec 2025 01:23:06 +0000 (17:23 -0800)]
drm/i915/display: Use HAS_LT_PHY() for LT PHY AUX power
Bspec states that the new AUX power enable/disable sequences are
associated with the LT PHY. As such, use HAS_LT_PHY() instead of IP
checks in those paths in the driver code.
While at it, also move the comment that we can't use the power status
flag to the "else" branch, since that comment is not applicable for the
LT PHY.
Bspec: 68967 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Suggested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251202012306.9315-9-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Tue, 2 Dec 2025 01:23:04 +0000 (17:23 -0800)]
drm/i915/display: Use platform check in HAS_LT_PHY()
NVL uses the Lake Tahoe PHY for display output and the driver recently
added the macro HAS_LT_PHY() to allow selecting code paths specific for
that type of PHY.
While NVL uses Xe3p_LPD as display IP, the type of PHY is actually
defined at the SoC level, so use a platform check instead of display
version.
Bspec: 74199 Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patch.msgid.link/20251202012306.9315-7-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Tue, 2 Dec 2025 01:23:02 +0000 (17:23 -0800)]
drm/i915/xe3p_lpd: Handle underrun debug bits
Xe3p_LPD added several bits containing information that can be relevant
to debugging FIFO underruns. Add the logic necessary to handle them
when reporting underruns.
This was adapted from the initial patch[1] from Sai Teja Pottumuttu.
v2:
- Handle FBC-related bits in intel_fbc.c. (Ville)
- Do not use intel_fbc_id_for_pipe (promoted from
skl_fbc_id_for_pipe), but use pipe's primary plane to get the FBC
instance. (Ville, Matt)
- Improve code readability by moving logic specific to logging fields
of UNDERRUN_DBG1 to a separate function. (Jani)
v3:
- Use crtc->base.primary instead of cycling through all crtcs
Bspec: 69111, 69561, 74411, 74412 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patch.msgid.link/20251202012306.9315-5-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Tue, 2 Dec 2025 01:23:01 +0000 (17:23 -0800)]
drm/i915/display: Handle dedicated external ports in intel_encoder_is_tc()
Starting with Xe3p_LPD, the VBT has a new field, called in the driver
"dedicated_external", which tells that a Type-C capable port is
physically connected to a PHY outside of the Type-C subsystem. When
that's the case, the driver must not do the extra Type-C programming for
that port. Update intel_encoder_is_tc() to check for that case.
While at it, add a note to intel_phy_is_tc() to remind us that it is
about whether the respective port is a Type-C capable port rather than
the PHY itself.
(Maybe it would be a nice idea to rename intel_phy_is_tc()?)
Note that this was handled with a new bool member added to struct
intel_digital_port instead of having querying the VBT directly because
VBT memory is freed (intel_bios_driver_remove) before encoder cleanup
(intel_ddi_encoder_destroy), which would cause an oops to happen when
the latter calls intel_encoder_is_tc(). This could be fixed by keeping
VBT data around longer, but that's left for a follow-up work, if deemed
necessary.
v2:
- Drop printing info about dedicated external, now that we are doing
it when parsing the VBT. (Jani)
- Add a FIXME comment on the code explaining why we need to store
dedicated_external in struct intel_digital_port. (Jani)
v3:
- Simplify the code by using NULL check for dig_port to avoid using
intel_encoder_is_dig_port(). (Imre)
Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251202012306.9315-4-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Tue, 2 Dec 2025 01:23:00 +0000 (17:23 -0800)]
drm/i915/power: Use intel_encoder_is_tc()
Starting with Xe3p_LPD, when intel_phy_is_tc() returns true, it does
not necessarily mean that the port is connected to a PHY in the Type-C
subsystem. The reason is that there is now a VBT field called
dedicated_external that will indicate that a Type-C capable port is
connected to a (most likely) combo/dedicated PHY. When that's the case,
we must not do the extra programming required for Type-C connections.
In an upcoming change, we will modify intel_encoder_is_tc() to take the
VBT field dedicated_external into consideration. Update
intel_display_power_well.c to use that function instead of
intel_phy_is_tc().
Note that, even though icl_aux_power_well_{enable,disable} are not part
of Xe3p_LPD's display paths, we modify them anyway for uniformity.
v2:
- Add and use icl_aux_pw_is_tc_phy() helper to avoid explicit encoder
lookup. (Imre)
Cc: Imre Deak <imre.deak@intel.com> Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v1 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251202012306.9315-3-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Tue, 2 Dec 2025 01:22:59 +0000 (17:22 -0800)]
drm/i915/vbt: Add fields dedicated_external and dyn_port_over_tc
VBT version 264 adds new fields associated to Xe3p_LPD's new ways of
configuring SoC for TC ports and PHYs. Update the code to match the
updates in VBT.
The new field dedicated_external is used to represent TC ports that are
connected to PHYs outside of the Type-C subsystem, meaning that they
behave like dedicated ports and don't require the extra Type-C
programming. In an upcoming change, we will update the driver to take
this field into consideration when detecting the type of port.
The new field dyn_port_over_tc is used to inform that the TC port can be
dynamically allocated for a legacy connector in the Type-C subsystem,
which is a new feature in Xe3p_LPD. In upcoming changes, we will use
that field in order to handle the IOM resource management programming
required for that.
Note that, when dedicated_external is set, the fields dp_usb_type_c and
tbt are tagged as "don't care" in the spec, so they should be ignored in
that case, so also add a sanitization function to take care of forcing
them to zero when dedicated_external is true.
v2:
- Use sanitization function to force dp_usb_type_c and tbt fields to
be zero instead of adding a
intel_bios_encoder_is_dedicated_external() check in each of their
respective accessor functions. (Jani)
- Print info about dedicated external ports in print_ddi_port().
(Jani)
v3:
- Also zero out field dyn_port_over_tc when dedicated_external is set.
(Imre)
- Use intel_bios_encoder_is_dedicated_external() directly instead of
storing return value into variable in print_ddi_port(). (Imre)
- Also print info for dyn_port_over_tc in print_ddi_port(). (Imre)
Bspec: 20124, 68954, 74304 Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20251202012306.9315-2-matthew.s.atwood@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
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.
projects / thirdparty / kernel / linux.git / log
