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)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-24-mika.kahola@intel.com
Add .update_dpll_ref_clks function pointer to MTL+
platforms to support dpll framework. Reuse ICL
function pointer.
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-23-mika.kahola@intel.com
Add .update_active_dpll function pointer to support
dpll framework. Reuse ICL function pointer.
v2: Add check for !HAS_LT_PHY (Suraj)
v3: Remove the incorrect !HAS_LT_PHY condition and
check for existing dpll_mgr
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v1
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251118132830.2584422-1-mika.kahola@intel.com
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)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-20-mika.kahola@intel.com
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)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-19-mika.kahola@intel.com
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'
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-18-mika.kahola@intel.com
Start bringing MTL+ platforms as part of PLL framework.
The work is started by adding PLL information and related
function hooks.
BSpec: 55726
v2: Revise commit message and add BSpec ID (Suraj)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-17-mika.kahola@intel.com
When pll's are moved to dpll framework we no longer
need Cx0 specific state verification as we can rely
on dpll state verification instead.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-16-mika.kahola@intel.com
Print all the Cx0 PLL state in the PLL state dumper.
v2: Use BUILD_BUG_ON() instead of WARN_ON() (Jani)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-15-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-14-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-13-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-12-mika.kahola@intel.com
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).
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-11-mika.kahola@intel.com
Define the C10 PLL SSC register range via macros, so the HW/SW state of
these register can be verified by a follow-up change, reusing these
macros.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-10-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-9-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-8-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-7-mika.kahola@intel.com
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)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-6-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-5-mika.kahola@intel.com
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.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-4-mika.kahola@intel.com
Factor out functions to begin and complete C10 PHY programming
sequences to make the code more concise.
v2: Rename msgbus_update_config() to more descriptive
msg_bus_access_commit() (Jani)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20251117104602.2363671-3-mika.kahola@intel.com
During fbdev probe, the xe driver allocates and pins a framebuffer
BO (via xe_bo_create_pin_map_novm() → xe_ggtt_insert_bo()).
Without a runtime PM reference, xe_pm_runtime_get_noresume() warns about
missing outer PM protection as below:
xe 0000:03:00.0: [drm] Missing outer runtime PM protection
Acquire a runtime PM reference before framebuffer allocation to ensure
xe_ggtt_insert_bo() executes under active runtime PM context.
Changes in v2:
- Update commit message to add Fixes tag (Jani Nikula)
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6350
Fixes: 44e694958b ("drm/xe/display: Implement display support")
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20251111135403.3415947-1-dibin.moolakadan.subrahmanian@intel.com
Disable FBC in bmg as per the wa recommendation.
v2: use the bmg platform instead of a specific stepping
v3: wa to Wa
Bspec: 74212
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20251111124606.402380-1-vinod.govindapillai@intel.com
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
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: 23db1577ce ("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>
The if+ternary combo used for the max cursor width initialization
on 845/865 is rather cumbersome. Just split this into a straight
up if ladder.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move the max cursor size initialization into intel_cursor.c
so that all the platform specific details about cursors are
concentrated in one file.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Use intel_fb_modifier_to_tiling() to convert the modifier into
the fence tiling mode during BIOS FB readout, rather than hand
rolling it. With this we can also stop tracking the tiling mode
in the intel_plane_config.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Use drm_get_format_info() instead of drm_format_info() to populate
fb->format during the BIOS FB readout. The difference being that
drm_get_format_info() knows about compressed formats whereas
drm_format_info() doesn't.
This doesn't actually matter in practice since the BIOS FB should
never be compressed, but no reason we shouldn't use the more accurate
function here anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pass the format info into plane->max_stride() from the
caller instead of doing yet another drm_format_info()
lookup on the spot.
drm_format_info() is both rather expensive, and technically
incorrect since it doesn't return the correct format info
for compressed formats (though that doesn't actually matter
for the current .max_stride() implementations since they
are just interested in the cpp value).
Most callers already have the format info available. The
only exception is intel_dumb_fb_max_stride() where we shall
use the actually correct drm_get_format_info() variant.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Wrap intel_plane_fb_max_stride() in intel_dumb_fb_max_stride()
for the purposes of dumb fb creation. I want to change
intel_plane_fb_max_stride() to take a 'struct drm_format_info'
instead of the 'u32 pixel_format' so we need an excplicit format
info lookup in the dumb fb path and I don't really want to have
that in i915_gem_dumb_create() directly.
This makes intel_plane_fb_max_stride() internal to the display
code again, and thus we can pass in struct intel_display instead
of struct drm_device.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251107181126.5743-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Utilize the 'out_value' output parameter of intel_de_wait_ms()
instead of re-reading the DPLL/DPIO_PHY_STATUS register after
polling has finished.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-17-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Utilize the 'out_value' output parameter of intel_de_wait_ms()
instead of re-reading the PHY_CONTROL register after polling
has finished.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-16-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Nuke the remaining _nowl() stuff from the wakelock code in the
form of __intel_de_wait_for_register_nowl(), and replace it with
intel_de_wait_fw_us_atomic() that uses the low level _fw() register
accessors in line with the rest of the code.
No change in behaviour since wakelocks are only supported on xe,
and xe doesn't have uncore.lock nor unclaimed register detection
stuff.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-15-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
The low level _fw() register accessors aren't supposed to
grab the wakelock. Stop doing so in intel_de_wait_fw_ms().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-14-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
We already have the lower level intel_de_*_fw() stuff, so use
that instead of hand rolling something custom for the DMC
wakelock stuff.
As the wakelock stuff exists only on platforms supported
by the xe driver this doesn't even result in any functional
changes since xe doesn't have uncore.lock nor unclaimed
register access detection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-13-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
_bxt_dpio_phy_init() doesn't us the _fw() register accessors
for anything else, so stop using them for the register polling
as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-12-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Add intel_de_wait_for_set_us() and intel_de_wait_for_clear_us()
as the microsecond counterparts to intel_de_wait_for_set_ms()
and intel_de_wait_for_clear_ms().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-9-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
intel_de_wait_custom() is finally unused. Get rid of it
before people start abusing it more.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20251110172756.2132-8-ville.syrjala@linux.intel.com
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
