Ville Syrjälä [Thu, 16 Jan 2025 20:16:37 +0000 (22:16 +0200)]
drm/i915/dsb: Allow DSB to perform commits when VRR is enabled
Now that we know how to issue the push with the DSB we can
allow the DSB to drive the commits even when VRR is active.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-9-ville.syrjala@linux.intel.com
Ville Syrjälä [Thu, 16 Jan 2025 20:16:36 +0000 (22:16 +0200)]
drm/i915/dsb: Add support for triggering VRR push with DSB
We have at least two options for how to do the
TRANS_PUSH_SEND + commit completion signalling
with the DSB:
Option A)
1. trigger TRANS_PUSH_SEND
2. wait for "safe window"
3. signal the interrupt
In this cases step 2 should not do anything if we were already
between vmin and vmax decision boundaries. Otherwise we'll wait
until the next start of the vblank period.
Option B)
1. wait for "safe window"
2. trigger TRANS_PUSH_SEND
3. signal the interrupt
This option is perhaps a bit less racy, but if we do somehow
screw up and the wait is a nop but the push gets deferred
until the next frame then we'll end up completing the commit
a frame too early.
So for now I'm leaning towards option A since losing the race
won't have any drastic consequences. To deal with the race we
can give the DSB a bit more time to start step 2 before the
hardware has started the vblank termination properly. Often
times it seems to be fast enough to make it in time even without
any extra vblank delay (the push is issued somewhere within a
scanline and it latches on the next scanline).
v2: Use intel_vrr_possible() to determine if we need some
vblank delay (also avoids adding it for DSI which doens't
actually program the transcoder registers correctly for it)
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-8-ville.syrjala@linux.intel.com
Ville Syrjälä [Thu, 16 Jan 2025 20:16:35 +0000 (22:16 +0200)]
drm/i915: Allow fastboot to fix up the vblank delay
GOP might not agree with our idea of what the vblank delay should be.
Reuse the LRR codepaths to fix that up via a fastset.
The relevant registers aren't actually double buffered so this is a
little bit dodgy. While I've not seen any real issues from frobbing
these live, let's limit this to just the fastboot case (by only
allowing it when old_crtc_state->inherited==true).
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 16 Jan 2025 20:16:34 +0000 (22:16 +0200)]
drm/i915: Extract lrr_params_changed()
Pull the "do we actually need a LRR update?" checks into a small
helper for clarity.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 16 Jan 2025 20:16:33 +0000 (22:16 +0200)]
drm/i915: Warn if someone tries to use intel_set_transcoder_timings*() on DSI outputs
intel_set_transcoder_timings*() aren't currently suitable for DSI.
Warn if someone accidentally calls them in such cases.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 16 Jan 2025 20:16:32 +0000 (22:16 +0200)]
drm/i915: Update TRANS_SET_CONTEXT_LATENCY during LRR updates
Update TRANS_SET_CONTEXT_LATENCY in intel_set_transcoder_timings_lrr()
as well. While for actual LRR updates this should not change, I want
to reuse this code to also sanitize the vblank delay during boot,
and in that case we do need to update this.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 16 Jan 2025 20:16:31 +0000 (22:16 +0200)]
drm/i915: Handle interlaced modes in intel_set_transcoder_timings_lrr()
I want to start using intel_set_transcoder_timings_lrr() also for
fixing up the vblank delay during boot. To that end make sure it
can cope with interlaced modes as well.
Note that we have soft-defeatured interlaced modes on tgl+ so
technically this is dead code, but if we ever have the need to
bring interlaced support back it seems better to handle this.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 16 Jan 2025 20:16:30 +0000 (22:16 +0200)]
drm/i915: Keep TRANS_VBLANK.vblank_start==0 on ADL+ even when doing LRR updates
intel_set_transcoder_timings() will set TRANS_VBLANK.vblank_start to 0
for clarity on ADL+ (non-DSI) because the hardware no longer uses that
value. Do the same in intel_set_transcoder_timings_lrr() to make sure
the registers stay consistent even when doing LRR timing updates.
Cc: Paz Zcharya <pazz@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250116201637.22486-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Imre Deak [Fri, 17 Jan 2025 15:38:43 +0000 (17:38 +0200)]
drm/xe/dp: Fix non-display builds with DP tunnelling incorrectly enabled
Code for the DP tunnelling functionality in the xe driver can be
built only if the display code is also built, adjust the kconfig
dependency accordingly.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Fixes:
73900dce57e4 ("drm/xe/dp: Enable DP tunneling")
Reported-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117153843.1312303-1-imre.deak@intel.com
Maarten Lankhorst [Tue, 10 Dec 2024 08:31:02 +0000 (09:31 +0100)]
drm/xe: Remove double pageflip
This is already handled below in the code by fixup_initial_plane_config.
Fixes:
a8153627520a ("drm/i915: Try to relocate the BIOS fb to the start of ggtt")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210083111.230484-3-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Jouni Högander [Thu, 9 Jan 2025 10:35:32 +0000 (12:35 +0200)]
drm/i915/psr: Allow changing Panel Replay mode without full modeset
Currently we are forcing full modeset if Panel Replay mode is changed. This
is not necessary as long as we are not changing sink PANEL REPLAY ENABLE
bit in PANEL REPLAY ENABLE AND CONFIGURATION 1 register. This can be
achieved by entering Panel Replay inactive mode (Live Frame mode) when
Panel Replay is disabled and keep PANEL REPLAY ENABLE bit in PANEL REPLAY
ENABLE AND CONFIGURATION 1 enabled always if panel is just supporting Panel
Replay.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-5-jouni.hogander@intel.com
Jouni Högander [Thu, 9 Jan 2025 10:35:31 +0000 (12:35 +0200)]
drm/i915/psr: Make intel_psr_enable_sink as local static function
Intel_psr_enable_sink is not used outside intel_psr.c. Convert it as local
static function.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-4-jouni.hogander@intel.com
Jouni Högander [Thu, 9 Jan 2025 10:35:30 +0000 (12:35 +0200)]
drm/i915/psr: Enable Panel Replay on sink always when it's supported
Currently we are configuring Panel Replay on sink when it get's
enabled. This means we need to do full modeset when enabling Panel
Replay. This is required as DP specification is saying sink Panel Replay
needs to be configured before link training. Avoid full modeset by enabling
Panel Replay on sink always when it's supported by the sink and the
source.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-3-jouni.hogander@intel.com
Jouni Högander [Thu, 9 Jan 2025 10:35:29 +0000 (12:35 +0200)]
drm/i915/psr: Add new function for writing sink panel replay enable bit
According to DP/eDP specification only DP_PANEL_REPLAY_ENABLE has to be set
prior link training. For this purpose add a new function which sets this
bit on sink side if Panel Replay is supported by the sink and the source.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250109103532.2093356-2-jouni.hogander@intel.com
Maarten Lankhorst [Fri, 6 Dec 2024 18:20:32 +0000 (19:20 +0100)]
drm/xe/display: Re-use display vmas when possible
i915 has this really nice, infrastructure where everything becomes
complicated, GGTT needs eviction, etc..
Lets not do that, and make the dumbest possible interface instead.
Try to retrieve the VMA from old_plane_state, or intel_fbdev if kernel
fb.
Link: https://patchwork.freedesktop.org/patch/msgid/20241206182032.196307-1-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Tested-by: Jani Saarinen <jani.saarinen@intel.com>
Suraj Kandpal [Fri, 17 Jan 2025 04:12:48 +0000 (09:42 +0530)]
drm/i915/hdcp: Use correct function to check if encoder is HDMI
Use intel_encoder_is_hdmi function which was recently introduced to
see if encoder is HDMI or not.
--v2
-Add Fixes tag [Jani]
Fixes:
6a3691ca4799 ("drm/i915/hdcp: Disable HDCP Line Rekeying for HDCP2.2 on HDMI")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250117041247.1084381-1-suraj.kandpal@intel.com
Ville Syrjälä [Thu, 10 Oct 2024 16:46:17 +0000 (19:46 +0300)]
drm/i915: Carve up skl_get_plane_caps()
Split skl_get_plane_caps() into four variants:
skl_plane_caps(), glk_plane_caps(), icl_plane_caps(),
tgl_plane_caps().
Makes it easier to figure out what is actually going on there.
v2: skl_plane_caps() should return u8 not bool
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241010164617.10280-1-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:06 +0000 (21:22 +0300)]
drm/i915: Relocate xe AUX hack
Move the xe AUX neutering out from skl_get_plane_caps() into the
caller so that it'll be easier to refactor skl_get_plane_caps()
into a more readable shape. This isn't really hardware specific
anyway, and just some kind of bug/misfeature of xe.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-9-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:05 +0000 (21:22 +0300)]
drm/i915: Nuke ADL pre-production Wa_22011186057
Wa_22011186057 (some CCS problem) only affected ADL A-stepping,
which I presume is pre-production hw. Drop the dead code.
Bspec: 54369
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-8-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:04 +0000 (21:22 +0300)]
drm/i915: Disable scanout VT-d workaround for TGL+
TGL+ should no longer need any VT-d scanout workarounds.
Don't apply any.
Not 100% sure whether pre-SNB might also suffer from this. The
workaround did originate on SNB but who knows if it was just
never caught before that. Not that I ever managed to enable
VT-d any older hardware. Last time I tried on my ILK it ate
the disk!
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-7-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:03 +0000 (21:22 +0300)]
drm/i915: Reuse vlv_primary_min_alignment() for sprites as well
Rename vlv_primary_min_alignment() to vlv_plane_min_alignment()
and use it to replace vlv_sprite_min_alignment() since the
behaviour is now identical when the plane init doesn't set up
any async flips stuff.
Technically VLV/CHV sprites do support async flips, so this
also makes us a bit more future proof if/when we extend async
flip support to more than one plane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-6-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:02 +0000 (21:22 +0300)]
drm/i915: Use plane->can_async_flip() for alignment exceptions
Async flips often require bigger alignment that sync flips.
Currently we have HAS_ASYNC_FLIPS() checks strewn about to
inidcate that async flips are generally supported and thus
we want more alignment. Switch that over to using
intel_plane_can_async_flip() so that we can handle these
in a slightly less messy way. Currently we don't have cases
where async flips would require different alignment for
different modifiers on the same plane.
We'll also move the HAS_ASYNC_FLIPS() check to the plane init
code so that we can still use that as a quick way to disable
the async flips workarounds for testing purposes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-5-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:01 +0000 (21:22 +0300)]
drm/i915: Introduce plane->can_async_flip()
Move the "does this modifier support async flips?" check
to be handled by the platform specific plane code instead
of having a big mess in common code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-4-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:22:00 +0000 (21:22 +0300)]
drm/i915: Allow async flips with compression on ICL
Apparently ICL can do async flips with CCS. In fact it already
seems to work on GLK, but apparently can lead to underruns there
so we'll only enable it for ICL.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-3-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Ville Syrjälä [Wed, 9 Oct 2024 18:21:59 +0000 (21:21 +0300)]
drm/i915: Allow async flips with render compression on TGL+
Looks like CCS + async flips has been a thing for a while now.
Enable this for TGL+ render compression modifiers.
Note that we can't update AUX_DIST during async flips we must
check to make sure it remains unchanged.
We also can't do clear color. Supposedly there was some attempt
to make it work, but apparently the issues only got ironed out
in MTL. For now we'll not worry about it and refuse async flips
with clear color modifiers.
Bspec claims that media compression doesn't support async flips.
Based on a quick test it does seem to work to some degree, but
perhaps it has issues as well. Let's trust the spec here and
continue to refuse async flips + media compression.
Bspec: 49250,49251,49252,49253
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241009182207.22900-2-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Gustavo Sousa [Mon, 13 Jan 2025 20:38:58 +0000 (17:38 -0300)]
drm/i915/dmc_wl: Track pipe interrupt registers
Pipe interrupt registers live in their respective pipes' power wells,
which are below PG0. That means that they must also be tracked as
registers that are powered-off during dynamic DC states.
There are probably more ranges that we need to track down and add to the
powered_off_ranges. However, let's make this change only about pipe
interrupt registers to fix some vblank timeouts observed due to the DMC
wakelock not being taken for those registers.
In the future, we might want to replace powered_off_ranges with a new
table to represent registers in PG0, which should be probably easier to
maintain. Any register not belonging to that table should be considered
powered off during dynamic DC states and, as such, requiring the DMC
wakelock for access.
Bspec: 72519, 71583
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-4-gustavo.sousa@intel.com
Gustavo Sousa [Mon, 13 Jan 2025 20:38:57 +0000 (17:38 -0300)]
drm/i915/display: Wrap IRQ-specific uncore functions
The current display IRQ code calls some IRQ-specific helpers that use
intel_uncore_*() MMIO functions instead of the display-specific ones.
Wrap those helpers to ensure that the proper display-specific hooks
(currently only DMC wakelock handling) are called.
v2:
- Move functions to intel_display_irq.c instead of having them in
intel_de.h. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-3-gustavo.sousa@intel.com
Gustavo Sousa [Mon, 13 Jan 2025 20:38:56 +0000 (17:38 -0300)]
drm/i915/display: Use display MMIO functions in intel_display_irq.c
Most of MMIO accesses from intel_display_irq.c are currently done via
uncore_*() functions instead of the display-specific ones, namely
intel_de_*(). Because of that, DMC wakelock ends up being ignored and
some invalid MMIO accesses are performed while display is in dynamic DC
states. Thus, update the display IRQ code to use the intel_de_*() MMIO
functions.
After this change, we are left with some IRQ-specific functions that
still use the unwrapped uncore_*() functions (i.e. gen2_irq_init,
gen3_irq_reset and gen2_assert_iir_is_zero). We will deal with them in
an upcoming change.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-2-gustavo.sousa@intel.com
Ankit Nautiyal [Fri, 10 Jan 2025 04:41:31 +0000 (10:11 +0530)]
drm/i915/dsc: Remove old comment about DSC 444 support
DSC with YCbCr420 is now supported, so remove the comment mentioning
support for only 444 format.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250110044131.3162682-3-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Fri, 10 Jan 2025 04:41:30 +0000 (10:11 +0530)]
drm/i915/dsc: Use helper to calculate range_bpg_offset
We get range_bpg_offset for different bpps based on
linear-interpolation from values given for nearby bpps.
Use a helper to get these values.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250110044131.3162682-2-ankit.k.nautiyal@intel.com
Suraj Kandpal [Tue, 17 Dec 2024 08:37:23 +0000 (14:07 +0530)]
drm/i915/hdcp: Fix Repeater authentication during topology change
When topology changes, before beginning a new HDCP authentication by
sending AKE_init message we need to first authenticate only the
repeater. Only after repeater authentication failure, it makes sense
to start a new HDCP authentication. Even though it made sense to not
enable HDCP directly from check_link and schedule it for later, repeater
authentication needs to be done immediately.
--v2
-Fix comment grammatical errors [Ankit]
Fixes:
47ef55a8b784 ("drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217083723.2883317-1-suraj.kandpal@intel.com
Dnyaneshwar Bhadane [Tue, 17 Dec 2024 20:13:01 +0000 (01:43 +0530)]
drm/i915/cx0_phy: Update HDMI TMDS C20 algorithm value
In the C20 algorithm for HDMI TMDS, certain fields have been updated
in the BSpec to set values for SRAM_GENERIC_<A/B>_TX_CNTX_CFG_1,
such as tx_misc and dac_ctrl_range for Xe2LPD, Xe2HPD and MTL/ARL.
This patch covers fields that need to be set based on the platform type.
Some ARLs SoCs cannot be directly distinguished by their GMD version Id,
Specifically to set value of tx_misc, so PCI Host Bridge IDs are used
for differentiation.
v2:
- Relocate defines and Restructure the code(Jani)
v3:
- Replace conditions with display.platform.<platform> (jani)
- Move host bridge check to new function (Jani)
v4:
- Identify/Replace arrowlake_u as meteorlake_u(Jani)
Bspec:74165,74491
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217201301.3593054-3-dnyaneshwar.bhadane@intel.com
Dnyaneshwar Bhadane [Tue, 17 Dec 2024 20:13:00 +0000 (01:43 +0530)]
drm/i915/display: Add MTL subplatforms definition
Separate MTL-U platform PCI ids in one define macro.
Add the MTL U/ARL U as subplatform member in MTL platform description
structure to use display.platform.<platform> from intel_display
structure instead of IS_<PLATFORM>() in display code path.
v2:
- Club ARL-u in MTL and identify ARL-u as MTL-u subplatform(Jani)
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241217201301.3593054-2-dnyaneshwar.bhadane@intel.com
Imre Deak [Tue, 14 Jan 2025 12:28:57 +0000 (14:28 +0200)]
drm/xe/dp: Enable DP tunneling
Enable the DP tunneling functionality in the xe driver.
v2: Keep using IS_ENABLED() for kconfig options. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250114122857.1050090-1-imre.deak@intel.com
Ville Syrjälä [Tue, 10 Dec 2024 21:10:05 +0000 (23:10 +0200)]
drm/i915/vrr: Plumb the DSB into intel_vrr_send_push()
Plumb the DSB down into intel_vrr_send_push() so that we can
perform the opration on the DSB.
TRANS_PUSH, being a transcoder register, needs non-posted writes
to make it through.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-17-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:10:04 +0000 (23:10 +0200)]
drm/i915/vrr: Add extra vblank delay to estimates
On ICL/TGL the VRR hardware injects an extra scanline just after
vactive. This essentically behaves the same as an extra line of
vblank delay, except it only appears in this one specific spot.
Consider our DSB interrupt signalling scheme:
1. arm the update
2. wait for undelayed vblank (or rather safe window with VRR)
3. wait for enough usecs to get past the delayed vblank
4. signal interrupt to indicate that arming has latched
If step 2 waits for end of vactive step 3 needs to account for
the extra one scanline, or else we risk signalling the interrupt
before the delayed vblank has actually elapsed. So include the
extra scanline in our vblank delay estimates.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-16-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:10:03 +0000 (23:10 +0200)]
drm/i915/vrr: Fix vmin/vmax/flipline on TGL when using vblank delay
Turns out that TGL needs its vmin/vmax/flipline adjusted based
on the vblank delay, otherwise the hardware pushes the vtotals
further out. Make it so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-15-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:10:02 +0000 (23:10 +0200)]
drm/i915/vrr: Drop the extra vmin adjustment for ADL+
Apparently only ICL/TGL need the annoying vmin adjustment.
On ADL+ we can program flipline==vmin and the hardware
actually respects that properly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-14-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:10:01 +0000 (23:10 +0200)]
drm/i915/vrr: Introduce intel_vrr_vblank_delay()
Introduce a VRR specific function for determining the current
vblank delay. Currently thus will give the same answer as
intel_mode_vblank_delay() but that will change later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-13-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:10:00 +0000 (23:10 +0200)]
drm/i915: Extract intel_crtc_active_timings()
Declutter intel_crtc_update_active_timings() a bit by
moving the code that determines the timings into a separate
function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-12-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:59 +0000 (23:09 +0200)]
drm/i915: Consolidate intel_pre_commit_crtc_state()
We have approximately two copies of pre_commit_crtc_state(),
one in the DSB code, the other in the vblank evasion code.
Combine them into one. The slight difference between the two
is that vblank evasion doesn't have a full atomic state (when
called from the legacy cursor code), so it gets the old and
new crtc state passed in by hand.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-11-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:58 +0000 (23:09 +0200)]
drm/i915: Extract intel_mode_vblank_delay()
Extract the code that computes the hardware centric view
of the vblank delay into a helper. We'll need a slightly
different variant for VRR soon.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-10-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:57 +0000 (23:09 +0200)]
drm/i915: Include the scanline offset in the state dump
When looking at raw hardware scanline numbers it's helpful to
remember what the offset between the hardware values and our
more human readable numbers should be. Include that in the state dump.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-9-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:56 +0000 (23:09 +0200)]
drm/i915/vrr: Improve VRR state dump
Dump the calculated vmin/vmax vtotal values in addition to the
raw vmin/vmax/flipline values. Makes it much easier to see what
kind of scanline values we should be expecting from the hardware.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-8-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:55 +0000 (23:09 +0200)]
drm/i915: Include the vblank delay in the state dump
While one can look at the crtc timings to determine the actual
vblank dealy, it seems nicer to provide a more human readable
dump of it to ease our lives.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-7-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:54 +0000 (23:09 +0200)]
drm/i915: Move framestart/etc. state dump to a better spot
Try to dump all the important stuff relating to the display timings
in one spot.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:53 +0000 (23:09 +0200)]
drm/i915: Introduce intel_vrr_{vmin,vmax}_vtotal()
On ICL/TGL vmin/vmax/flipline won't actually match the
vtotal values (currently they do, but that is wrong and
needs to be fixed). Add a few helpers that will compute the
actual vtotal values for us.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-5-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:52 +0000 (23:09 +0200)]
drm/i915: Fix include order
Include the headers in the correct alphabetical order.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:51 +0000 (23:09 +0200)]
drm/i915: Check vblank delay validity
Make sure we have enough vblank for the computed vblank delay.
Supposedly we'd reject things anyway later if this gets violated,
but it seems nicer to do some basic sanity checks early just
so we can be sure the basic relationship vblank_end > vblank_start
always holds.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Ville Syrjälä [Tue, 10 Dec 2024 21:09:50 +0000 (23:09 +0200)]
drm/i915: Extract intel_crtc_vblank_delay()
Pull the vblank delay computation into a separate function.
We'll need more logic here soon and we don't want to pollute
intel_crtc_compute_config() with low level details.
We'll use HAS_DSB() to determine if any delay might be required
or not because delayed vblank only really exists for the
purposes of the DSB. It also doesn't event exists on any pre-tgl
platforms, which also don't have DSB. I was midly tempted
to check for the enable_dsb modparam here actually, but as
that can be changed dynamically via debugfs we'd need to either
reconfigure it on the fly or force a modeset. Neither will happen
currently, so we'll just assume DSB may be used of the platform
supports it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241210211007.5976-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Jani Nikula [Wed, 8 Jan 2025 14:04:15 +0000 (16:04 +0200)]
drm/i915/audio: rename function prefixes from i915 to intel
The intel prefix is more accurate for display stuff. Rename.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5e67f6fc5a441a9512d7855d86ce7868cc992212.1736345025.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Wed, 8 Jan 2025 14:04:14 +0000 (16:04 +0200)]
drm/i915/audio: convert LPE audio to struct intel_display
Going forward, struct intel_display will be the main display device
structure. Convert intel_lpe_audio.[ch] to it. Do some minor checkpatch
fixes while at it.
TODO: Not sure if irq_set_chip_data(irq, dev_priv); is used.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f04dd028cd8869cdfb9ab9eb6aceed8ff8e7ddcd.1736345025.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Wed, 8 Jan 2025 14:04:13 +0000 (16:04 +0200)]
drm/i915/audio: convert to struct intel_display
Going forward, struct intel_display will be the main display device
structure. Convert intel_audio.[ch] to it, as much as possible
anyway. Do some minor checkpatch fixes while at it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4ddcc2e704fc6b1592a878c80e15fadd82c63550.1736345025.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Fri, 29 Nov 2024 06:50:13 +0000 (08:50 +0200)]
drm/i915/fb: Check that the clear color fits within the BO
Make sure the user supplied offset[] for the clear color plane
fits within the actual BO. Note that we use tile units to track
the size here. All the other color/aux planes are already
being checked correctly.
Cc: Sagar Ghuge <sagar.ghuge@intel.com>
Cc: Nanley Chery <nanley.g.chery@intel.com>
Cc: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241129065014.8363-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 29 Nov 2024 06:50:12 +0000 (08:50 +0200)]
drm/i915/fb: Add debug spew for misaligned CC plane
We're currently failing to provide any debug output when the
user passes in a misaligned offset for the clear color plane.
Add some debugs prints to make debugging actually possible.
Cc: Sagar Ghuge <sagar.ghuge@intel.com>
Cc: Nanley Chery <nanley.g.chery@intel.com>
Cc: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241129065014.8363-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 29 Nov 2024 06:50:11 +0000 (08:50 +0200)]
drm/i915/fb: Relax clear color alignment to 64 bytes
Mesa changed its clear color alignment from 4k to 64 bytes
without informing the kernel side about the change. This
is now likely to cause framebuffer creation to fail.
The only thing we do with the clear color buffer in i915 is:
1. map a single page
2. read out bytes 16-23 from said page
3. unmap the page
So the only requirement we really have is that those 8 bytes
are all contained within one page. Thus we can deal with the
Mesa regression by reducing the alignment requiment from 4k
to the same 64 bytes in the kernel. We could even go as low as
32 bytes, but IIRC 64 bytes is the hardware requirement on
the 3D engine side so matching that seems sensible.
Note that the Mesa alignment chages were partially undone
so the regression itself was already fixed on userspace
side.
Cc: stable@vger.kernel.org
Cc: Sagar Ghuge <sagar.ghuge@intel.com>
Cc: Nanley Chery <nanley.g.chery@intel.com>
Reported-by: Xi Ruoyao <xry111@xry111.site>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13057
Closes: https://lore.kernel.org/all/
45a5bba8de009347262d86a4acb27169d9ae0d9f.camel@xry111.site/
Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/17f97a69c13832a6c1b0b3aad45b06f07d4b852f
Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/888f63cf1baf34bc95e847a30a041dc7798edddb
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241129065014.8363-2-ville.syrjala@linux.intel.com
Tested-by: Xi Ruoyao <xry111@xry111.site>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Rodrigo Vivi [Fri, 10 Jan 2025 14:46:40 +0000 (09:46 -0500)]
drm/i915/guc/slpc: Print more SLPC debug status information
Let's peek on the Balancer and DCC status, now that we
are using the default strategies.
v2: fix identation
v3: fix typo (Vinay)
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250110144640.1032250-2-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Fri, 10 Jan 2025 14:46:39 +0000 (09:46 -0500)]
drm/i915/guc/slpc: Allow GuC SLPC default strategies on MTL+
The Balancer and DCC strategies were left off on a fear that
these strategies would conflict with the i915's waitboost.
However, on MTL and Beyond these strategies are only active in
certain conditions where the system is TDP limited.
So, they don't conflict, but help the
waitboost by guaranteeing a bit more of GT frequency.
Without these strategies we were likely leaving some performance
behind on some scenarios.
With this change in place, the enabling/disabling of DCC and Balancer
will now be chosen by GuC, on a platform/GT basis.
v2: - Fix typos and be clear on GuC decision on platform basis (Vinay)
- Limit change to MTL and beyond, where GuC started to take
TDP limit into consideration.
v3: Fix compilation. Actually amend the changes...
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250110144640.1032250-1-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Dr. David Alan Gilbert [Sun, 22 Dec 2024 00:20:43 +0000 (00:20 +0000)]
drm/i915/gvt: Remove unused intel_gvt_in_force_nonpriv_whitelist
The last use of intel_gvt_in_force_nonpriv_whitelist() was
removed in 2020 by
commit
02dd2b12a685 ("drm/i915/gvt: unify lri cmd handler and mmio
handlers")
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241222002043.173080-4-linux@treblig.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Dr. David Alan Gilbert [Sun, 22 Dec 2024 00:20:42 +0000 (00:20 +0000)]
drm/i915/gvt: Remove unused intel_vgpu_decode_sprite_plane
intel_vgpu_decode_sprite_plane() was added in 2017 by
commit
9f31d1063b43 ("drm/i915/gvt: Add framebuffer decoder support")
but has remained unused.
Remove it.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241222002043.173080-3-linux@treblig.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Dr. David Alan Gilbert [Sun, 22 Dec 2024 00:20:41 +0000 (00:20 +0000)]
drm/i915/gvt: Remove intel_gvt_ggtt_h2g<->index
intel_gvt_ggtt_h2g_index() and intel_gvt_ggtt_index_g2h() were
added in 2016 by
commit
2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization")
but haven't been used.
Remove them.
They were the only users of intel_gvt_ggtt_gmadr_g2h() and
intel_gvt_ggtt_gmadr_h2g().
Remove them.
Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>
Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241222002043.173080-2-linux@treblig.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Zhenyu Wang [Wed, 13 Nov 2024 06:37:00 +0000 (14:37 +0800)]
MAINTAINERS: switch my mail address for GVT driver
I won't be able to use intel account, so this switches address to my
gmail account.
Cc: Zhi Wang <zhi.wang.linux@gmail.com>
Cc: Zhiyuan Lv <zhiyuan.lv@intel.com>
Cc: James Wu <james.y.wu@intel.com>
Cc: Zhenyu Wang <zhenyuw.linux@gmail.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Zhi Wang <zhiwang@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20241113063700.4460-1-zhenyuw@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:27 +0000 (15:08 +0200)]
drm/i915/scaler: Add scaler tracepoints
Add some tracpoints around skl+ scaler programming to help with
debugging.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-9-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:26 +0000 (15:08 +0200)]
drm/i915/scaler: s/excdeed/exceed/
Fix typo s/excdeed/exceed/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-8-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:25 +0000 (15:08 +0200)]
drm/i915/scaler: Pimp scaler debugs
Include the standard "[CRTC:...]" information in the scaler debugs
to make life easier.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-7-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:24 +0000 (15:08 +0200)]
drm/i915/scaler: Nuke redundant code
The tgl+ and mtl+ numbers in skl_scaler_max_dst_size() are
identical. Combine them to a single piece of code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-6-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:23 +0000 (15:08 +0200)]
drm/i915/scaler: Extract skl_scaler_max_dst_size()
The SKL_MAX_DST_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-5-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:22 +0000 (15:08 +0200)]
drm/i915/scaler: Extract skl_scaler_min_dst_size()
The SKL_MIN_DST_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-4-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:21 +0000 (15:08 +0200)]
drm/i915/scaler: Extract skl_scaler_max_src_size()
The SKL_MAX_SRC_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-3-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ville Syrjälä [Thu, 19 Dec 2024 13:08:20 +0000 (15:08 +0200)]
drm/i915/scaler: Extract skl_scaler_min_src_size()
The SKL_MIN_*SRC_* defines just make things hard to read.
Get rid of them and introduce an easy to read function
in their place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219130827.22830-2-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Ravi Kumar Vodapalli [Wed, 8 Jan 2025 20:02:10 +0000 (01:32 +0530)]
drm/i915/display: Update DBUF_TRACKER_STATE_SERVICE only on appropriate platforms
The bspec only asks the driver to reprogram the DBUF_CTL's
DBUF_TRACKER_STATE_SERVICE field to 0x8 on DG2 and platforms with
display version 12. All other platforms should avoid reprogramming
this register at driver init.
Although we've been accidentally reprogramming DBUF_CTL on platforms
where the spec does not ask us to, that mistake has been harmless so
far because the value being programmed by the driver happened to
match the hardware's default settings.
So, update DBUF_TRACKER_STATE_SERVICE field to 0x8 only for
1. display version 12
2. DG2.
Other platforms unless stated should use their default value.
Bspec: 49213
Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250108200210.1815229-1-ravi.kumar.vodapalli@intel.com
[mattrope: Tweaked patch subject to accurately reflect content]
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Jani Nikula [Tue, 7 Jan 2025 18:22:40 +0000 (20:22 +0200)]
drm/i915/gvt: store virtual_dp_monitor_edid in rodata
The virtual DP EDID isn't modified. Add const modifier to store it in
rodata.
Reviewed-by: Nemesa Garg <nemesa.garg@intel.com>
Reviewed-by: Zhi Wang <zhiwang@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250107182240.1765311-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Gustavo Sousa [Thu, 19 Dec 2024 22:14:16 +0000 (19:14 -0300)]
drm/i915/dmc_wl: Allow enable_dmc_wl=3 to mean "always locked"
When debugging issues that might be related to the DMC wakelock code, it
might be useful to compare runs with the lock acquired while DC states
are enabled vs the regular case. If issues disappear with the former, it
might be a symptom of something wrong in our code. Support having this
"always locked" behavior with enable_dmc_wl=3.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-5-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Thu, 19 Dec 2024 22:14:15 +0000 (19:14 -0300)]
drm/i915/dmc_wl: Allow enable_dmc_wl=2 to mean "match any register"
When debugging issues that might be related to the DMC wakelock code, it
is sometimes useful to compare runs when we match any register offset vs
the regular case. If issues disappear when we take the wakelock for any
register, it might indicate that we are missing some offset to be
tracked. Support matching any register offset with enable_dmc_wl=2.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-4-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Thu, 19 Dec 2024 22:14:14 +0000 (19:14 -0300)]
drm/i915/dmc_wl: Show description string for enable_dmc_wl
We already provide the value resulting from sanitization of
enable_dmc_wl in dmesg, however the reader will need to either have the
meanings memorized or look them up in the parameter's documentation.
Let's make things easier by providing a short human-readable name for
the parameter in dmesg.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-3-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Gustavo Sousa [Thu, 19 Dec 2024 22:14:13 +0000 (19:14 -0300)]
drm/i915/dmc_wl: Use enum values for enable_dmc_wl
Currently, after sanitization, enable_dmc_wl will behave like a boolean
parameter (enabled vs disabled). However, in upcoming changes, we will
allow more values for debugging purposes. For that, let's make the
sanitized value an enumeration.
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241219221429.109668-2-gustavo.sousa@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Jani Nikula [Tue, 31 Dec 2024 16:27:40 +0000 (18:27 +0200)]
drm/i915/display: convert global state to struct intel_display
Going forward, struct intel_display is the main display device
structure. Convert intel_global_state.[ch] to it.
This allows us to make intel_pmdemand.c completely independent of
i915_drv.h.
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2b5e743b285a86a59ee87085727847c758c8d552.1735662324.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Tue, 31 Dec 2024 16:27:39 +0000 (18:27 +0200)]
drm/i915/pmdemand: convert to struct intel_display
Going forward, struct intel_display is the main display device
structure. Convert pmdemand to it.
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c1d92e9490013d5aba50fc1d1ebc0ee18e82cf7e.1735662324.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Tue, 31 Dec 2024 16:27:38 +0000 (18:27 +0200)]
drm/i915/pmdemand: make struct intel_pmdemand_state opaque
Only intel_pmdemand.c should look inside the struct
intel_pmdemand_state. Indeed, this is already the case. Finish the job
and make struct intel_pmdemand_state opaque, preventing any direct pokes
at the guts of it in the future.
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bc5f418785ecd51454761e9a55f21340470a92e3.1735662324.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Tue, 31 Dec 2024 16:27:37 +0000 (18:27 +0200)]
drm/i915/pmdemand: convert to_intel_pmdemand_state() to a function
In preparation for making struct intel_pmdemand_state an opaque type,
convert to_intel_pmdemand_state() to a function.
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/10324781f9f7eae5a92506aaa7a40403efd345dd.1735662324.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Fri, 3 Jan 2025 13:52:39 +0000 (15:52 +0200)]
drm/i915/dp: compute config for 128b/132b SST w/o DSC
Enable basic 128b/132b SST functionality without compression. Reuse
intel_dp_mtp_tu_compute_config() to figure out the TU after we've
determined we need to use an UHBR rate.
It's slightly complicated as the M/N computation is done in different
places in MST and SST paths, so we need to avoid trashing the values
later for UHBR.
If uncompressed UHBR fails, we drop to compressed non-UHBR, which is
quite likely to fail as well. We still lack 128b/132b SST+DSC.
We need mst_master_transcoder also for 128b/132b SST. Use cpu_transcoder
directly. Enhanced framing is "don't care" for 128b/132b link.
v2: mst_master_transcoder, enhanced framing (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/084e4e05bf25a5dd396dd391014943d42b11c88d.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:38 +0000 (15:52 +0200)]
drm/i915/ddi: disable trancoder port select for 128b/132b SST
128b/1232b SST will have mst_master_transcoder set and matching
cpu_transcoder. Ensure disable also for 128b/132b SST.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Co-developed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/eaf705b3490d828ba33e85f40a7794d58de7c5ad.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:37 +0000 (15:52 +0200)]
drm/i915/ddi: handle 128b/132b SST in intel_ddi_read_func_ctl()
We'll only ever get here in MST mode from MST stream encoders; the
primary encoder's ->get_config() won't be called when we've detected
it's MST.
v2: Read mst_master_transcoder in 128b/132b SST path (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/436854c0bb6ab5c14c3d3837694ea60ac2fbaba2.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:36 +0000 (15:52 +0200)]
drm/i915/ddi: start distinguishing 128b/132b SST and MST at state readout
We'll want to distinguish 128b/132b SST and MST modes at state
readout. There's a catch, though. From the hardware perspective,
128b/132b SST and MST programming are pretty much the same. And we can't
really ask the sink at this point.
If we have more than one transcoder in 128b/132b mode associated with
the port, we can safely assume it's MST. But for MST with only a single
stream enabled, we are pretty much out of luck. Let's fall back to
looking at the software state, i.e. intel_dp->is_mst. It should be fine
for the state checker, but for hardware takeover at probe, we'll have to
trust the GOP has only enabled SST.
TODO: Not sure how this *or* our current code handles 128b/132b enabled
by GOP.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/119a773a0d4d74ad204435e462f8d12cb0ea4128.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:35 +0000 (15:52 +0200)]
drm/i915/ddi: enable ACT handling for 128b/132b SST
Add ACT handling for 128b/132b SST enable/disable.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
v2:
- Check for !is_hdmi (Imre)
- Add disable sequence (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b0226471f9445d988917cee49dbbd93a1493f3c7.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:34 +0000 (15:52 +0200)]
drm/i915/ddi: initialize 128b/132b SST DP2 VFREQ registers
Write the DP2 specific VFREQ registers.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
v2: Check for !is_hdmi (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7d90547e9ce01642b722efca0bf81cadb754e790.1735912293.git.jani.nikula@intel.com
Jani Nikula [Tue, 7 Jan 2025 09:54:14 +0000 (11:54 +0200)]
drm/i915/ddi: write payload for 128b/132b SST
Write the payload allocation table for 128b/132b SST. Use VCPID 1 and
start from slot 0, with dp_m_n.tu slots.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet. Indeed, we don't yet compute TU for 128b/132b SST.
v2: Handle drm_dp_dpcd_write_payload() failures (Imre)
v3: Include drm_dp_helper.h (kernel test robot)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250107095414.1244286-1-jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:32 +0000 (15:52 +0200)]
drm/i915/ddi: 128b/132b SST also needs DP_TP_CTL_MODE_MST
It's not very clearly specified, and the hardware bit is ill-named, but
128b/132b SST also needs the MST mode set in the DP_TP_CTL register.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b29fbba8c979a8bab2bf03088610fe408faaf704.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:31 +0000 (15:52 +0200)]
drm/i915/ddi: enable 128b/132b TRANS_DDI_FUNC_CTL mode for UHBR SST
128b/132b SST needs 128b/132b mode enabled in the TRANS_DDI_FUNC_CTL
register.
This is preparation for enabling 128b/132b SST. This path is not
reachable yet.
v2: Use the MST path instead of SST to also set transport select (Imre)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/122ebeadf4bf0870fc26b7d12abdff88f4be8799.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:30 +0000 (15:52 +0200)]
drm/i915/mst: adapt intel_dp_mtp_tu_compute_config() for 128b/132b SST
Handle 128b/132b SST in intel_dp_mtp_tu_compute_config(). The remote
bandwidth overhead and time slot allocation are only relevant for MST;
SST only needs the local bandwidth and a check that 64 slots isn't
exceeded.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b59c94b0aac2c073b0306c0a0040b26330f94260.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:29 +0000 (15:52 +0200)]
drm/i915/mst: split out a helper for figuring out the TU
Extract intel_dp_mtp_tu_compute_config() for figuring out the TU. Move
the link configuration and mst state access to the callers. This will be
easier to adapt to 128b/132b SST.
v2: Don't add SST stuff here yet
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c3ea8370c9bd3cdc579159e68a63f4ed2fadc66a.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:28 +0000 (15:52 +0200)]
drm/i915/mst: remove crtc_state->pbn
The crtc_state->pbn member is only used as a temporary variable within
mst_stream_find_vcpi_slots_for_bpp(). Remove it as unnecessary.
Suggested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/726aaadbd425057dfd854e42417bcf8d69b769d3.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:27 +0000 (15:52 +0200)]
drm/i915/mst: change return value of mst_stream_find_vcpi_slots_for_bpp()
The callers of mst_stream_find_vcpi_slots_for_bpp() don't need the
returned slots for anything. On the contrary, they need to jump through
hoops to just distinguish between success and failure. Just return 0
instead of slots from mst_stream_find_vcpi_slots_for_bpp() for success,
and simplify the callers.
There's a pointless ret local variable that we can drop in the process.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7b3671a548c893b1bb62151d41f90bb8ce842ccc.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:26 +0000 (15:52 +0200)]
drm/i915/mst: drop connector parameter from intel_dp_mst_compute_m_n()
intel_dp_mst_compute_m_n() doesn't need the connector. Remove the
parameter.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/eec2e9a2e2dc3d166ac94bb9de691246a14d3945.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:25 +0000 (15:52 +0200)]
drm/i915/mst: drop connector parameter from intel_dp_mst_bw_overhead()
intel_dp_mst_bw_overhead() doesn't need the connector. Remove the
parameter.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e1379aca0748e392d8a232135b823deec783e829.1735912293.git.jani.nikula@intel.com
Jani Nikula [Fri, 3 Jan 2025 13:52:24 +0000 (15:52 +0200)]
drm/mst: remove mgr parameter and debug logging from drm_dp_get_vc_payload_bw()
The struct drm_dp_mst_topology_mgr *mgr parameter is only used for debug
logging in case the passed in link rate or lane count are zero. There's
no further error checking as such, and the function returns 0.
There should be no case where the parameters are zero. The returned
value is generally used as a divisor, and if we were hitting this, we'd
be seeing division by zero.
Just remove the debug logging altogether, along with the mgr parameter,
so that the function can be used in non-MST contexts without the
topology manager.
v2: Also remove drm_dp_mst_helper_tests_init as unnecessary (Imre)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/72d77e7a7fe69c784e9df048b7e6f250fd7599e4.1735912293.git.jani.nikula@intel.com
Jani Nikula [Tue, 7 Jan 2025 16:07:54 +0000 (18:07 +0200)]
Merge drm/drm-next into drm-intel-next
Backmerge to get the DRM DP payload and ACT helpers to drm-intel-next.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Animesh Manna [Mon, 6 Jan 2025 09:44:08 +0000 (15:14 +0530)]
drm/i915/display: Adjust Added Wake Time with PKG_C_LATENCY
Increase the PKG_C_LATENCY Pkg C Latency field by the added wake time.
v1: Initial version.
v2: Rebase and cosmetic changes.
v3:
- Place latency adjustment early to accommodate round-up. [Suraj]
- Modify commit description and cosmetic change. [Suraj]
WA:
22020432604
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250106094408.1011063-1-animesh.manna@intel.com
Ankit Nautiyal [Fri, 3 Jan 2025 03:14:24 +0000 (08:44 +0530)]
drm/i915/dp: Return early if dsc is required but not supported
Currently, when bandwidth is insufficient for a given mode, we attempt
to use DSC. This is indicated by a debug print, followed by a check for
DSC support.
The debug message states that we are trying DSC, but DSC might not be
supported, which can give an incorrect picture in the logs if we bail
out later.
Correct the order for both DP and DP MST to:
- Check if DSC is required and supported, and return early if DSC is
not supported.
- Print a debug message to indicate that DSC will be tried next.
Suggested-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250103031424.1732774-1-ankit.k.nautiyal@intel.com
Suraj Kandpal [Fri, 3 Jan 2025 05:17:05 +0000 (10:47 +0530)]
drm/i915/ddi: Optimize mtl_port_buf_ctl_program
A small optimization and cleanup for mtl_port_buf_ctl_program function
which lets use intel_de_rmw instead of a intel_de_read and
intel_de_write.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250103051705.145161-3-suraj.kandpal@intel.com