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)
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).
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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)
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.
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.
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)
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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")
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().
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>
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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]
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.
projects / users / jedix / linux-maple.git / log