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.
Suraj Kandpal [Fri, 3 Jan 2025 08:45:17 +0000 (14:15 +0530)]
Revert "drm/i915/hdcp: Don't enable HDCP1.4 directly from check_link"
This reverts commit 483f7d94a0453564ad9295288c0242136c5f36a0.
This needs to be reverted since HDCP even after updating the connector
state HDCP property we don't reenable HDCP until the next commit
in which the CP Property is set causing compliance to fail.
Jani Nikula [Mon, 30 Dec 2024 14:14:45 +0000 (16:14 +0200)]
drm/i915/ddi: only call shutdown hooks for valid encoders
DDI might be HDMI or DP only, leaving the other encoder
uninitialized. Calling the shutdown hook on an uninitialized encoder may
lead to a NULL pointer dereference. Check the encoder types (and thus
validity via the DP output_reg or HDMI hdmi_reg checks) before calling
the hooks.
Jani Nikula [Mon, 30 Dec 2024 14:14:43 +0000 (16:14 +0200)]
drm/i915/ddi: gracefully handle errors from intel_ddi_init_hdmi_connector()
Errors from intel_ddi_init_hdmi_connector() can just mean "there's no
HDMI" while we'll still want to continue with DP only. Handle the errors
gracefully, but don't propagate. Clear the hdmi_reg which is used as a
proxy to indicate the HDMI is initialized.
Jani Nikula [Mon, 30 Dec 2024 14:14:40 +0000 (16:14 +0200)]
drm/i915/ddi: change intel_ddi_init_{dp, hdmi}_connector() return type
The caller doesn't actually need the returned struct intel_connector;
it's stored in the ->attached_connector of intel_dp and
intel_hdmi. Switch to returning an int with 0 for success and negative
errors codes to be able to indicate success even when we don't have a
connector.
Ankit Nautiyal [Tue, 17 Dec 2024 09:32:43 +0000 (15:02 +0530)]
drm/i915/dp: Set the DSC link limits in intel_dp_compute_config_link_bpp_limits
The helper intel_dp_compute_config_link_bpp_limits is the correct place
to set the DSC link limits. Move the code to this function and remove
the #TODO item.
v2: Add argument intel_connector to the helper to get correct connector
for DP MST. (Imre)
v3: Remove redundant calls to intel_dp_dsc_sink_max_compressed_bpp as
its already accounted while setting link bpp limits.
Ankit Nautiyal [Tue, 17 Dec 2024 09:32:42 +0000 (15:02 +0530)]
drm/i915/dp: Make dsc helpers accept const crtc_state pointers
Modify the dsc helpers to get max/min compressed bpp to accept
`const struct intel_crtc_state *` pointers instead of
`struct intel_crtc_state *`.
These helpers are not supposed to modify `crtc_state`.
Accepting const pointers will allow these helpers to be called from
functions that have const pointer to crtc_state.
Ankit Nautiyal [Tue, 17 Dec 2024 09:32:41 +0000 (15:02 +0530)]
drm/i915/dp: Use clamp for pipe_bpp limits with DSC
Currently to get the max pipe_bpp with dsc we take the min of
limits->pipe.max_bpp and dsc max bpp (dsc max bpc * 3). This can result
in problems when limits->pipe.max_bpp is less than the computed dsc min bpp
(dsc min bpc * 3).
Replace the min/max functions with clamp while computing
limits->pipe.max/min_bpp to ensure that the pipe_bpp limits are constrained
within the DSC-defined minimum and maximum values.
Ankit Nautiyal [Tue, 17 Dec 2024 09:32:39 +0000 (15:02 +0530)]
drm/i915/dp: Refactor pipe_bpp limits with dsc
With DSC there are additional limits for pipe_bpp. Currently these are
scattered in different places.
Instead set the limits->pipe.max/min_bpp in one place and use them
wherever required.
Ankit Nautiyal [Tue, 17 Dec 2024 09:32:38 +0000 (15:02 +0530)]
drm/i915/dp: Drop max_requested_bpc for dsc pipe_min/max bpp
Currently we are including both max_requested_bpc and
limits->pipe.bpp_max while computing maximum possible pipe bpp with dsc.
However, while setting limits->pipe.max_bpp, the max_requested_bpc is
already taken into account.
Drop the redundant check for max_requested_bpc and use only
limits->pipe.bpp_max. This will also result in dropping conn_state
argument in functions where it was used only to get max_requested_bpc.
projects / users / jedix / linux-maple.git / log