Ville Syrjälä [Tue, 15 Mar 2022 13:27:52 +0000 (15:27 +0200)]
drm/i915: s/enable/active/ for DRRS
Rename the DRRS functiosn to say "(de)activate" rather than
"enable/disable". This let's us differentiate between the
logically enabled vs. actually currently active cases.
Ville Syrjälä [Thu, 3 Mar 2022 19:12:06 +0000 (21:12 +0200)]
drm/i915: Fix DBUF bandwidth vs. cdclk handling
Make the dbuf bandwidth min cdclk calculations match the spec
more closely. Supposedly the arbiter can only guarantee an equal
share of the total bandwidth of the slice to each active plane
on that slice. So we take the max bandwidth of any of the planes
on each slice and multiply that by the number of active planes
on the slice to get a worst case estimate on how much bandwidth
we require.
Ville Syrjälä [Thu, 3 Mar 2022 19:12:05 +0000 (21:12 +0200)]
drm/i915: Properly write lock bw_state when it changes
The current code also forgets to call intel_atomic_lock_global_state()
when other stuff besides the final min_cdlck changes in the state.
That means we may throw away data which actually has changed, and
thus we can't be at all sure what the code ends up doing during
subsequent commits. Do the write lock properly.
Ville Syrjälä [Thu, 3 Mar 2022 19:12:03 +0000 (21:12 +0200)]
drm/i915: Nuke intel_bw_calc_min_cdclk()
intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
(at least documented) dbuf min cdclk limit on pre-skl so let's just get
rid of all this confusion.
Ville Syrjälä [Thu, 3 Mar 2022 19:12:02 +0000 (21:12 +0200)]
drm/i915: Remove total[] and uv_total[] from ddb allocation
There's really no need to maintain these total[] arrays to
track the size of each plane's ddb allocation. We just stick
the results straight into the crtc_state ddb tracking structures.
The main annoyance with all this is the mismatch between
wm_uv vs. ddb_y on pre-icl. If only the hw was consistent in
what it considers the primary source of information we could
avoid some of the uglyness. But since that is not the case
we need a bit of special casing for planar formats.
v2: Keep the ddb entry zeroed when the plane is disabled
Ville Syrjälä [Thu, 3 Mar 2022 19:12:01 +0000 (21:12 +0200)]
drm/i915: Pre-calculate plane relative data rate
Handle the plane relative data rate in exactly the same
way as we already handle the real data rate. Ie. pre-calculate
it during intel_plane_atomic_check_with_state(), and assign/clear
it for the Y plane as needed. This should guarantee that the
tracking is 100% consistent, and makes me have to think less
when the same apporach is used by both types of data rate.
We might even want to consider replacing the relative
data rate with the real data rate entirely, but it's not
clear if that will produce less optimal plane ddb
allocations. So for now lets keep using the current approach.
Ville Syrjälä [Thu, 3 Mar 2022 19:12:00 +0000 (21:12 +0200)]
drm/i915: Split plane data_rate into data_rate+data_rate_y
Split the currently combined plane data_rate into the proper
Y vs. CbCr components. This matches how we now track the
plane dbuf allocations, and thus will make the dbuf bandwidth
calculations actually produce the correct numbers for each
dbuf slice.
Ville Syrjälä [Thu, 3 Mar 2022 19:11:59 +0000 (21:11 +0200)]
drm/i915: Tweak plane ddb allocation tracking
Let's store the plane allocation in a manner which more closely
matches how the hw operates. That is, we store the packed/CbCr
ddb in one struct, and the Y ddb in another. Currently we're
storing packed/Y in one struct, CbCr in the other.
This also works pretty well for icl+ where the UV plane is
the main plane and the Y plane is subservient to it. Although
in this case we do not even use ddb_y as we do the ddb allocation
in terms of hw planes.
drm/i915/display/adlp: More voltage swing table updates
A few more updates in the alderlake-P voltage swing tables.
eDP HBR3 table was the same as icelake one but now it has changes for
voltage 0 and pre-emphasis 2 line.
And DP tables also had one line change in each.
Ville Syrjälä [Wed, 9 Mar 2022 16:49:46 +0000 (18:49 +0200)]
drm/i915: Fix PSF GV point mask when SAGV is not possible
Don't just mask off all the PSF GV points when SAGV gets disabled.
This should in fact cause the Pcode to reject the request since
at least one PSF point must remain enabled at all times.
Give the pre-icl SAGV control functions a skl_ prefix instead
of the intel_ prefix to make it a bit more clear that they
are not some kind of universal things that can be called on
any platform. Also make the functions void since we never
use the return value anyway.
Ville Syrjälä [Wed, 9 Mar 2022 16:49:44 +0000 (18:49 +0200)]
drm/i915: Reject excessive SAGV block time
If the mailbox returns an exceesively large SAGV block time let's just
reject it. This avoids having to worry about overflows when we add the
SAGV block time to the wm0 latency.
We shall put the limit arbitrarily at U16_MAX. >65msec latency
doesn't really make sense to me in any case.
Ville Syrjälä [Wed, 9 Mar 2022 16:49:43 +0000 (18:49 +0200)]
drm/i915: Probe whether SAGV works on pre-icl
Instead of leaving the SAGV enable/disable to the first commit
let's try to disable it first thing to see if we can do it or
not (disabling SAGV is a safe thing to at any time). This avoids
running the code in this funny intermediate state where we don't
know if SAGV is available or not.
Ville Syrjälä [Wed, 9 Mar 2022 16:49:41 +0000 (18:49 +0200)]
drm/i915: Treat SAGV block time 0 as SAGV disabled
For modern platforms the spec explicitly states that a
SAGV block time of zero means that SAGV is not supported.
Let's extend that to all platforms. Supposedly there should
be no systems where this isn't true, and it'll allow us to:
- use the same code regardless of older vs. newer platform
- wm latencies already treat 0 as disabled, so this fits well
with other related code
- make it a bit more clear when SAGV is used vs. not
- avoid overflows from adding U32_MAX with a u16 wm0 latency value
which could cause us to miscalculate the SAGV watermarks on tgl+
Jani Nikula [Fri, 11 Mar 2022 10:06:39 +0000 (12:06 +0200)]
drm/i915: include uapi/drm/i915_drm.h directly where needed
Remove the uapi/drm/i915_drm.h include from drm/i915_drm.h, and stop
being a proxy for uapi/drm/i915_drm.h. Include uapi/drm/i915_drm.h and
drm/i915_drm.h only where needed.
Jani Nikula [Wed, 16 Mar 2022 09:50:18 +0000 (11:50 +0200)]
drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch]
Move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] as a
i915_gem_object function related to tiling. Also un-inline while at it;
does not seem like this is a function needed in hot paths.
v2: i915_gem_tiling.[ch] instead of intel_ggtt_fencing.[ch] (Chris)
Ville Syrjälä [Fri, 11 Mar 2022 21:28:45 +0000 (23:28 +0200)]
drm/i915: Reject unsupported TMDS rates on ICL+
ICL+ PLLs can't genenerate certain frequencies. Running the PLL
algorithms through for all frequencies 25-594MHz we see a gap just
above 500 MHz. Specifically 500-522.8MHZ for TC PLLs, and 500-533.2
MHz for combo PHY PLLs. Reject those frequencies hdmi_port_clock_valid()
so that we properly filter out unsupported modes and/or color depths
for HDMI.
Ville Syrjälä [Tue, 15 Mar 2022 13:27:51 +0000 (15:27 +0200)]
drm/i915: Deal with bigjoiner vs. DRRS
DRRS operates on transcoder level, so we should only poke at it from
the master crtc rather than letting every joined pipe give it
potentially conflicting input.
Ville Syrjälä [Tue, 15 Mar 2022 21:39:44 +0000 (23:39 +0200)]
drm/i915: Do DRRS disable/enable during pre/post_plane_update()
Let's just do a full DRRS disable/enable across all pipe updates.
This guarantees that the DRRS work doesn't interfere with anything
while the atomic commit is busy reprogramming the pipe.
Needed so that we can start reprogramming M/N seamlessly during
fastsets whenever possible. Also avoids the pre-bdw DRRS PIPECONF
rmw racing with the potential PIPECONF write from the atomic
commit (eg. due to GAMMA_MODE changes).
Ville Syrjälä [Tue, 15 Mar 2022 13:27:46 +0000 (15:27 +0200)]
drm/i915: Fix DRRS frontbuffer_bits handling
Now that DRRS can operate on multiple pipes we need to make sure
one pipe doesn't throw away the other pipe's frontbuffer_bits before
said pipe can handle them.
Ville Syrjälä [Tue, 15 Mar 2022 13:27:44 +0000 (15:27 +0200)]
drm/i915: Put the downclock_mode check back into can_enable_drrs()
With static DRRS the user might ask for the lowest possible refresh
rate of the panel, in which case we're not going to find a suitable
downclock mode for it and we should not try to enable seamless DRRS.
This will in fact oops.
We used to check for the presence of the downclock mode here, but
that got removed in commit f0a57798fb5c ("drm/i915: Introduce
intel_panel_drrs_type()") as redundant (which it was at the time).
But we do need the check again now that static DRRS is a thing.
I must have not re-tested static DRRS fully after introducing
intel_panel_drrs_type() :/
Ville Syrjälä [Fri, 18 Feb 2022 10:04:00 +0000 (12:04 +0200)]
drm/i915: Use drm_mode_copy()
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.
Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.
@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}
@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, &E)
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)
@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(&mode, &E)
|
- memcpy(&mode, E, S)
+ drm_mode_copy(&mode, E)
)
drm/i915/display: Do not re-enable PSR after it was marked as not reliable
If a error happens and sink_not_reliable is set, PSR should be disabled
for good but that is not happening.
It would be disabled by the function handling the PSR error but then
on the next fastset it would be enabled again in
_intel_psr_post_plane_update().
It would only be disabled for good in the next modeset where has_psr
will be set false.
v2:
- release psr lock before continue
Fixes: 9ce5884e5139 ("drm/i915/display: Only keep PSR enabled if there is active planes") Reported-by: Khaled Almahallawy <khaled.almahallawy@intel.com> Reported-by: Charlton Lin <charlton.lin@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311185149.110527-2-jose.souza@intel.com
drm/i915/display: Fix HPD short pulse handling for eDP
Commit 13ea6db2cf24 ("drm/i915/edp: Ignore short pulse when panel
powered off") completely broke short pulse handling for eDP as it is
usually generated by sink when it is displaying image and there is
some error or status that source needs to handle.
When power panel is enabled, this state is enough to power aux
transactions and VDD override is disabled, so intel_pps_have_power()
is always returning false causing short pulses to be ignored.
So here better naming this function that intends to check if aux
lines are powered to avoid the endless cycle mentioned in the commit
being fixed and fixing the check for what it is intended.
v2:
- renamed to intel_pps_have_panel_power_or_vdd()
- fixed indentation
Fixes: 13ea6db2cf24 ("drm/i915/edp: Ignore short pulse when panel powered off") Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311185149.110527-1-jose.souza@intel.com
Ville Syrjälä [Fri, 11 Mar 2022 17:24:27 +0000 (19:24 +0200)]
drm/i915: Implement static DRRS
Let's start supporting static DRRS by trying to match the refresh
rate the user has requested, assuming the panel supports suitable
timings.
For now we stick to just our current two timings:
- fixed_mode: the panel's preferred mode
- downclock_mode: the lowest refresh rate mode we found
Some panels may support more timings than that, but we'll
have to convert our fixed_mode/downclock_mode pointers
into a full list before we can handle that.
Ville Syrjälä [Fri, 11 Mar 2022 17:24:25 +0000 (19:24 +0200)]
drm/i915: Move DRRS enable/disable higher up
No reason to keep the DRRS enable/disable hidden insider the encoder
hooks. Let's just move them all the way up into platform independent
code so that all platforms get to use them. These are nops when
the state computation doesn't think DRRS is possible.
Ville Syrjälä [Fri, 11 Mar 2022 17:24:24 +0000 (19:24 +0200)]
drm/i915: Stash DRRS state under intel_crtc
Ger rid of one more ugly crtc->config usage by storing the DRRS
state under intel_crtc. intel_drrs_enable() copies what it needs
from the crtc state, after which DRRS can be blissfully ignorant
of anything going on around it.
This also lets multiple pipes do DRRS simultanously and entirely
independently.
There are a couple of cases where we essentially just want to
get/check the preferred fixed mode of the panel. Add a small
helper for that to abstract away the direct pointer lookup.
Abstract away the details on where we store the fixed/downclock
modes, and also how we select them. Will be useful for static
DRRS (aka. allowing the user to select the refresh rate for the
panel).
We pass in the user requested mode to intel_panel_fixed_mode()
so that in the future it may try to match the refresh rate.
And intel_panel_downclock_mode() gets passed the adjusted_mode
we actually chose to use so that it may find a suitable lower
resresh rate variant.
v2: Hook it up for all encoders
s/fixed_mode/adjusted_mode/ in intel_panel_downclock_mode() (Jani)
Elaborate on the choice or arguments for the functions (Jani)
Ville Syrjälä [Fri, 11 Mar 2022 17:24:17 +0000 (19:24 +0200)]
drm/i915: Nuke dev_priv->drrs.type
When we found a downclock mode dev_priv->drrs.type is just a
straight copy of dev_priv->vbt.drrs_type. And in case we
couldn't find a downclock mode can_enable_drrs() won't let
us enable DRRS anyway so the minor distinction between the
two is irrelevant. So let's just nuke dev_priv->drrs.type
and consult the VBT version directly.
Ville Syrjälä [Fri, 11 Mar 2022 17:24:15 +0000 (19:24 +0200)]
drm/i915/lvds: Pass fixed_mode to compute_is_dual_link_lvds()
We want to eventually get rid of the connector->panel.fixed_mode
pointer so avoid using it during LVDS setup. Since this all
happens during the encoder init we already have the fixed_mode
around, just pass that in.
Ville Syrjälä [Fri, 11 Mar 2022 17:24:14 +0000 (19:24 +0200)]
drm/i915/sdvo: Pass the requesed mode to intel_sdvo_create_preferred_input_timing()
We want to stop using connector->panel.fixed_mode directtly.
In order to look it up in the future we'll need to have the
requested mode around, so pass that in fully (instead of just
passing bits of it).
Ville Syrjälä [Fri, 11 Mar 2022 17:24:13 +0000 (19:24 +0200)]
drm/i915/dsi: Pass fixed_mode to *_dsi_add_properties()
We want to eventually get rid of the connector->panel.fixed_mode
pointer so avoid using it during DSI property setup. Since this
all happens during the encoder init we already have the fixed_mode
around, just pass that in.
Ville Syrjälä [Thu, 10 Mar 2022 00:47:57 +0000 (02:47 +0200)]
drm/i915: Rename PIPECONF refresh select bits
Rename the PIPECONF refresh rate select bits to be
less cryptic. Also nothing eDP specific about these as they
also select between FP0 vs. FP1 for the DPLL and thus can be
used to change the refresh rate on other output types as well.
Ville Syrjälä [Thu, 10 Mar 2022 00:47:50 +0000 (02:47 +0200)]
drm/i915: Fix up some DRRS type checks
Only seamless DRRS needs the frontbuffer tracking, so check for that.
Also use != consistently instead of randomly picking < as the comparison
operator.
Ville Syrjälä [Mon, 7 Mar 2022 23:39:39 +0000 (01:39 +0200)]
drm/i915: Populate bxt/glk DPLL clock limits a bit more
Set the bxt/glk DPLL min dotclock to 25MHz (HDMI minimum)
and the max to 594 MHz (HDMI max). The supported DP frequencies
(162MHz-540MHz) fit within the same range.
Ville Syrjälä [Mon, 7 Mar 2022 23:39:34 +0000 (01:39 +0200)]
drm/i915: Remove redundant/wrong comments
Remove the comment specifying the exact formulat for calculating
the DPLL frequency from the *_find_best_dpll() functions. Each
platform variant has its own way to calculate these and we have
the code already to do that. These comments are entirely redundant
and often even wrong so just get rid of them.
Ville Syrjälä [Wed, 9 Mar 2022 21:43:01 +0000 (23:43 +0200)]
drm/i915: Store the /5 target clock in struct dpll on vlv/chv
Unify vlv/chv with earlier platforms so that the sturct dpll::dot
represents the /5 clock frequency (ie. DP symbol rate or HDMI
TMDS rate) rather than the *5 fast clock (/2 of the bitrate).
Makes life a little less confusing to get the same number back
in .dot which we fed into the DPLL algorithm.
v2: Actually just include the 5x in the final P divider
Do the same change to the hand rolled gvt code
v3: Missed a few *5 in *_find_best_dpll()
Ville Syrjälä [Wed, 23 Feb 2022 13:13:15 +0000 (15:13 +0200)]
drm/i915: Make the PIPESRC rect relative to the entire bigjoiner area
When using bigjoiner it's useful to know the offset of each
individual pipe in the whole set of joined pipes. Let's include
that information in our PIPESRC rectangle. With this we can make
the plane clipping code blissfully unaware of bigjoiner usage, as
all we have to do is remove the pipe's offset from the final plane
destination coordinates.
Ville Syrjälä [Wed, 23 Feb 2022 13:13:14 +0000 (15:13 +0200)]
drm/i915: Use bigjoiner_pipes more
Replace the hardcoded 2 pipe assumptions when we're massaging
pipe_mode and the pipe_src rect to be suitable for bigjoiner.
Instead we can just count the number of pipes in the bitmask.
Ville Syrjälä [Wed, 23 Feb 2022 13:13:13 +0000 (15:13 +0200)]
drm/i915: Eliminate bigjoiner boolean
Since we now have the bigjoiner_pipes bitmask the boolean
is redundant. Get rid of it.
Also, populating bigjoiner_pipes already during
encoder->compute_config() allows us to use it much earlier
during the state calculation as well. The initial aim is
to use it in intel_crtc_compute_config().
v2: Move the hweight(bigjoiner_pipes) stuff to a later patch
Ville Syrjälä [Mon, 21 Feb 2022 11:03:54 +0000 (13:03 +0200)]
drm/i915: Remove framestart_delay sanitation
Now that we track framestart_delay in the crtc state with readout
and state checker support we can remove the explicit framestart_delay
sanitation code.
Also I'm not convinced reprogramming this while the pipe is running
is even valid. CHICKEN_TRANS (hsw+) and TRANS_CHICKEN2 (cpt+) docs
at least make no mention of double buffering which seems to imply
that live reprogramming is not supported. On older platforms
PIPECONF and PCH_TRANSCONF (ibx) are double buffered though, so
might be that we could do this on the older platforms. But doesn't
really make sense to special case old platforms for this.
So from now on if the BIOS has misprogrammed this we shall simply do
a full modeset at boot to fix it up. Such systems will of course lose
fastboot, but I think less code (and less uncertainty what
reprogramming this on a running pipe will even do) outweighs that.
Ville Syrjälä [Mon, 21 Feb 2022 11:03:53 +0000 (13:03 +0200)]
drm/i915: Move framestart_delay to crtc_state
We need to make framestart_delay dynamic for DRRS on PCH
ports. To that end move it into the crtc state. As a bonus
we get state check+dump for it. Will also allow us to get
rid of the somewhat questionable framestart_delay sanitation
code.
Changes since v2.14:
- Release Notes for v2.15
Fix for corruption issue when DC States are enabled.
- Release Notes for v2.16
Fix for cases with flip queue and DC6v are enabled.
Jani Nikula [Thu, 3 Mar 2022 18:19:31 +0000 (20:19 +0200)]
drm/i915: include linux/highmem.h and linux/swap.h where needed
Include linux/highmem.h and linux/swap.h explicitly where needed so we
can drop the linux/i2c.h include from i915_drv.h where it pulled in the
dependencies implicitly.
Jani Nikula [Thu, 3 Mar 2022 18:19:30 +0000 (20:19 +0200)]
drm/i915/gmbus: alloc intel_gmbus dynamically
Allocate the individual intel_gmbus structs dynamically. This lets us
hide struct intel_gmbus inside intel_gmbus.c completely. Also use the
cleanup function on the error path to avoid duplication.
Leave #include <linux/i2c.h> in i915_drv.h for now, as it pulls in a
bunch of implicit dependencies.
Jani Nikula [Thu, 3 Mar 2022 18:19:27 +0000 (20:19 +0200)]
drm/i915/gmbus: combine gmbus pin lookups to one function
Combine the platform specific if ladders for array lookup and size
checks into one. This is cleaner and avoids duplication, but hopefully
also helps any static analyzers that seem to have trouble with the
bounds checks.
Ville Syrjälä [Mon, 14 Feb 2022 10:55:31 +0000 (12:55 +0200)]
drm/i915: Fix the async flip wm0/ddb optimization
The current implementation of the async flip wm0/ddb optimization
does not work at all. The biggest problem is that we skip the
whole intel_pipe_update_{start,end}() dance and thus never actually
complete the commit that is trying to do the wm/ddb change.
To fix this we need to move the do_async_flip flag to the crtc
state since we handle commits per-pipe, not per-plane.
Also since all planes can now be included in the first/last
"async flip" (which gets converted to a sync flip to do the
wm/ddb mangling) we need to be more careful when checking if
the plane state is async flip comptatible. Only planes doing
the async flip should be checked and other planes are perfectly
fine not adhereing to any async flip related limitations.
However for subsequent commits which are actually going do the
async flip in hardware we want to make sure no other planes
are in the state. That should never happen assuming we did our
job correctly, so we'll toss in a WARN to make sure we catch
any bugs here.
Ville Syrjälä [Mon, 14 Feb 2022 10:55:30 +0000 (12:55 +0200)]
drm/i915: Check async flip capability early on
Since the async flip state check is done very late and
thus it can see potentially all the planes in the state
(due to the wm/ddb optimization) we need to move the
"can the requested plane do async flips at all?" check
much earlier. For this purpose we introduce
intel_async_flip_check_uapi() that gets called early during
the atomic check.
And for good measure we'll throw in a couple of basic checks:
- is the crtc active?
- was a modeset flagged?
- is+was the plane enabled?
Though atm all of those should be guaranteed by the fact
that the async flip can only be requested through the legacy
page flip ioctl.
Ville Syrjälä [Mon, 14 Feb 2022 10:55:29 +0000 (12:55 +0200)]
drm/i915: Don't skip ddb allocation if data_rate==0
data_rate==0 no longer means a plane is disabled, it could
also mean we want to use the minimum ddb allocation for it.
Hence we can't bail out early during ddb allocation or
else we'll simply forget to allocate any ddb for such planes.
Some users are suffering with PSR2 issues that are under debug or
issues that were root caused to panel firmware bugs, to make life of
those users easier here adding a option to disable PSR2 with kernel
parameters so they can still benefit from PSR1 power savings.
Using the same enable_psr that is current used to turn the whole
feature on or off and allowing user to select up to what PSR version
it should enable.
Right now users only set this parameter to 0 when they want to disable
PSR1 and PSR2 or don't add it at all leaving it to per-chip behavior
so it should not cause a bad impact on users.
v2:
- changing enable_psr values (Ville and Rodrigo)
Jouni Högander [Fri, 25 Feb 2022 07:02:28 +0000 (09:02 +0200)]
drm/i915/psr: Set "SF Partial Frame Enable" also on full update
Currently we are observing occasional screen flickering when
PSR2 selective fetch is enabled. More specifically glitch seems
to happen on full frame update when cursor moves to coords
x = -1 or y = -1.
According to Bspec SF Single full frame should not be set if
SF Partial Frame Enable is not set. This happened to be true for
ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADL_P it's
actually "SF Partial Frame Enable" (Bit 31).
Setting "SF Partial Frame Enable" bit also on full update seems to
fix screen flickering.
Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
only if not on ADL_P. Bit 31 has different meaning in ADL_P.
Bspec: 49274
v2: Fix Mihai Harpau email address
v3: Modify commit message and remove unnecessary comment
Tested-by: Lyude Paul <lyude@redhat.com> Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by default") Reported-by: Lyude Paul <lyude@redhat.com> Cc: Mihai Harpau <mharpau@gmail.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225070228.855138-1-jouni.hogander@intel.com
projects / thirdparty / linux.git / log
