Imre Deak [Mon, 12 May 2025 14:26:00 +0000 (17:26 +0300)]
drm/i915/ptl: Use everywhere the correct DDI port clock select mask
The PTL XELPDP_PORT_CLOCK_CTL register XELPDP_DDI_CLOCK_SELECT field's
size is 5 bits vs. the earlier platforms where its size is 4 bits. Make
sure the field is read-out/programmed everywhere correctly, according to
the above.
Cc: Mika Kahola <mika.kahola@intel.com> Cc: stable@vger.kernel.org # v6.13+ Tested-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250512142600.824347-1-imre.deak@intel.com
Jani Nikula [Tue, 13 May 2025 09:28:41 +0000 (12:28 +0300)]
drm/i915/pps: drop dependency on intel_display_conversion.h
All the PPS register users have been converted to struct
intel_display. The backward compat conversion to struct drm_i915_private
is no longer needed. Drop it, along with the include, and convert the
dev_priv macro parameter names to display while at it.
Jani Nikula [Mon, 12 May 2025 14:56:57 +0000 (17:56 +0300)]
drm/i915: convert VLV IOSF SB interface to struct drm_device
With users both in i915 core and display, struct drm_device is the
common denominator for the VLV IOSF SB users. Also use drm_device for
the helpers on the display side to keep the static inlines as simple as
possible.
We can drop a number of dependencies on i915_drv.h with this.
Jani Nikula [Mon, 12 May 2025 14:56:56 +0000 (17:56 +0300)]
drm/i915: move VLV IOSF SB unit specific helpers under display
Now that all the VLV IOSF SB unit specific helper users are under
display, relocate the helpers themselves under display as
well. Resurrect the vlv_sideband.[ch] name for this. Make everything
except DPIO helpers static inlines, as their implementations are
trivial.
All of this considerably simplifies the xe compat header.
Jani Nikula [Mon, 12 May 2025 14:56:55 +0000 (17:56 +0300)]
drm/i915: switch i915 core to generic VLV IOSF SB functions
We'll want to relocate the unit specific functions to display, making
them inaccessible to i915 core. As there aren't that many users in i915
core, we can just convert them to the generic VLV IOSF SB read/write
functions.
Imre Deak [Fri, 9 May 2025 18:03:39 +0000 (21:03 +0300)]
drm/i915/dp_mst: Enable fractional link bpps on MST if the bpp is forced
Enable using a fractional (compressed) link bpp on MST links, if this is
supported and the link bpp is forced. Fractional link bpps will be
enabled by default as a follow-up change after testing this
functionality within a set of commonly used MST monitors and docks/hubs
which support it.
Imre Deak [Fri, 9 May 2025 18:03:38 +0000 (21:03 +0300)]
drm/i915: Add support for forcing the link bpp on a connector
Add support for forcing the link bpp on a connector via a connector
debugfs entry. During reducing link bpps due to a link BW limit, keep
bpps close to their forced value.
Add the debugfs entry to all relevant connectors: all DP connectors and
on an FDI link CRT/SDVO/LVDS/HDMI connectors.
v2:
- Move adding the debugfs entries to this patch.
- Rename i915_force_link_bpp to intel_force_link_bpp. (Jani)
- Select the relevant connectors via platform checks. (Jani)
- Use for_each_new_intel_connector_in_state(). (Jani)
- Fix 64 bit division vs. 32 bit build when converting str to q4. (lkp)
- Avoid division and addition overflow when converting str to q4.
v3:
- Add TODO: to make the non-DSC min bpp value connector specific. (Ankit)
Imre Deak [Fri, 9 May 2025 18:03:35 +0000 (21:03 +0300)]
drm/i915/dp_mst: Add support for fractional compressed link bpps on MST
Add support for a fractional compressed link bpp on an MST link. Leave
the actual enabling of fractional bpps to a follow-up change.
While at it add an assert before the bpp loop, that the min and max bpps
are aligned to the bpp step. This should hold regardless of the non-DSC/DSC
or MST/UHBR-SST modes.
This keeps the mode validation and DSC->DPT BW specific maximum link
bpps as rounded-down integer values still, changing those to a
fractional value is left for later, add here TODO comments for them.
v2:
- Align the min/max bpp value to the bpp step.
- Assert that the min/max bpp values are aligned to the bpp step.
Imre Deak [Fri, 9 May 2025 18:03:33 +0000 (21:03 +0300)]
drm/i915/dp_mst: Simplify computing the min/max compressed bpp limits
Adjusting the compressed bpp range min/max limits in
intel_dp_dsc_nearest_valid_bpp() is unnecessary:
- The source/sink min/max values are enforced already by the
link_config_limits::min_bpp_x16/max_bpp_x16 values computed early in
intel_dp_compute_config_link_bpp_limits().
- The fixed set of valid bpps are enforced already - for all bpps in the
min .. max range by intel_dp_dsc_valid_compressed_bpp() called from
intel_dp_mtp_tu_compute_config().
The only thing needed is limiting max compressed bpp below the
uncompressed pipe bpp, do that one thing only instead of calling
intel_dp_dsc_nearest_valid_bpp().
Imre Deak [Fri, 9 May 2025 18:03:32 +0000 (21:03 +0300)]
drm/i915/dp_mst: Check BW limit on the local MST link early
Check the BW requirement of a selected compressed bpp against the total
MST link BW early. This didn't cause a problem, since all the BW limits
within the MST topology are checked during the later MST topology BW
check. However it doesn't make sense to defer the total link BW check,
since for resolving a BW limit issue due to this later also (a) requires
selecting a pipe to reduce its bpp, ending up reducing the bpp for
another pipe, which is not ideal (b) requires recomputing the state for
all CRTC/stream's in the topology which may slow down the commit
considerably (especially when using fractional bpps).
Based on the above, check a stream bpp's BW requirement against the MST
link's total BW early.
Ideally drm_dp_atomic_find_time_slots() should check internally the
corresponding PBN/TU slot BW against the total link BW, returning an
error if the check fails, however that change would also affect other
drivers, so leaving this for a follow-up.
v2: Rephrase description of pipe selection/bpp reduction in commit
message. (Ankit)
Imre Deak [Fri, 9 May 2025 18:03:31 +0000 (21:03 +0300)]
drm/i915/dp_mst: Update the total link slot count early
A follow up change will check a selected bpp's BW requirement in
intel_dp_mtp_tu_compute_config(), however that requires the total link
slot count to be up-to-date. The latter in turn depends on the channel
encoding and hence the link rate used, so it can be set after the
link rate used is selected.
This also allows simplifying mst_stream_update_slots(), do that as well,
moving the function definition before its use.
Imre Deak [Fri, 9 May 2025 18:03:30 +0000 (21:03 +0300)]
drm/i915/dp_mst: Validate compressed bpp vs. platform restrictions
Atm TGL supports only a fixed set of valid DSC compressed bpps
(6,8,10,12,15), but this is not taken into account while looking for a
bpp in the minimum..maximum compressed bpp range.
This happened to work only by chance since atm from the above min..max
range it's always the maximum bpp that is selected, which is one of the
above valid bpps (see mst_stream_dsc_compute_link_config() ->
intel_dp_dsc_nearest_valid_bpp()). Before selecting a bpp however, the
bpp's BW requirement should be checked wrt. to the MST total link BW;
after doing that - in a follow-up change - the validity of any bpp in
the min..max range must be ensured before the bpp is selected, do that
here.
Imre Deak [Fri, 9 May 2025 18:03:29 +0000 (21:03 +0300)]
drm/i915/dp_mst: Simplify handling the single-bpp case during state computation
A follow-up change wants to skip invalid bpps in the bpp select loop of
a stream state computation. To allow for that, using the usual
'continue' statement in the loop, change the way the single-bpp range is
handled.
Imre Deak [Fri, 9 May 2025 18:03:28 +0000 (21:03 +0300)]
drm/i915/dp_mst: Use the correct connector while computing the link BPP limit on MST
Atm, on an MST link in DSC mode
intel_dp_compute_config_link_bpp_limits() calculates the maximum link
bpp limit using the MST root connector's DSC capabilities. That's not
correct in general: the decompression could be performed by a branch
device downstream of the root branch device or the sink itself.
Fix the above by passing to intel_dp_compute_config_link_bpp_limits()
the actual connector being modeset, containing the correct DSC
capabilities.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Fixes: 1c5b72daff46 ("drm/i915/dp: Set the DSC link limits in intel_dp_compute_config_link_bpp_limits") Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250509180340.554867-2-imre.deak@intel.com
Jani Nikula [Fri, 2 May 2025 12:07:25 +0000 (15:07 +0300)]
drm/i915/irq: stop using HAS_GMCH()
Right or wrong, HAS_GMCH() has become a display only thing. The last
three users outside of display are in irq code. Reorder the if ladders
to stop using HAS_GMCH().
Imre Deak [Wed, 7 May 2025 15:19:53 +0000 (18:19 +0300)]
drm/i915/dp: Fix determining SST/MST mode during MTP TU state computation
Determining the SST/MST mode during state computation must be done based
on the output type stored in the CRTC state, which in turn is set once
based on the modeset connector's SST vs. MST type and will not change as
long as the connector is using the CRTC. OTOH the MST mode indicated by
the given connector's intel_dp::is_mst flag can change independently of
the above output type, based on what sink is at any moment plugged to
the connector.
Fix the state computation accordingly.
Cc: Jani Nikula <jani.nikula@intel.com> Fixes: f6971d7427c2 ("drm/i915/mst: adapt intel_dp_mtp_tu_compute_config() for 128b/132b SST") Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4607 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250507151953.251846-1-imre.deak@intel.com
Jani Nikula [Wed, 7 May 2025 08:31:36 +0000 (11:31 +0300)]
drm/i915/rps: fix stale reference to i915->irq_lock
The RPS code has been switched from using i915->irq_lock to gt->irq_lock
years ago in commit d762043f7ab1 ("drm/i915: Extract GT powermanagement
interrupt handling"). Fix the stale comment referencing i915->irq_lock,
which has also ceased to exist.
Jani Nikula [Tue, 6 May 2025 13:06:50 +0000 (16:06 +0300)]
drm/i915/irq: move i915->irq_lock to display->irq.lock
Observe that i915->irq_lock is no longer used to protect anything
outside of display. Make it a display thing.
This allows us to remove the ugly #define irq_lock irq.lock hack from xe
compat header.
Note that this is slightly more subtle than it first looks. For i915,
there's no functional change here. The lock is moved. However, for xe,
we'll now have *two* locks, xe->irq.lock and display->irq.lock. These
should protect different things, though. Indeed, nesting in the past
would've lead to a deadlock because they were the same lock.
With the i915 references gone, we can make a handful more files
independent of i915_drv.h.
Jani Nikula [Tue, 6 May 2025 13:06:49 +0000 (16:06 +0300)]
drm/i915/rps: refactor display rps support
Make the gt rps code and display irq code interact via
intel_display_rps.[ch], instead of direct access. Add no-op static
inline stubs for xe instead of having a separate build unit doing
nothing. All of this clarifies the interfaces between i915 core and
display.
All users of vlv_display_irq_postinstall() outside of
intel_display_irq.c have a lock/unlock pair. Move the locking inside the
function. Add an unlocked variant for internal use, similar to the
_vlv_display_irq_reset() and vlv_display_irq_reset() functions.
As per the WA, fbc stride need to be programmed always for bmg.
Display driver handles the need to program the fbc stride using
the override stride. So ensure that we always get the override
stride in case of bmg
Jani Nikula [Thu, 24 Apr 2025 20:01:41 +0000 (23:01 +0300)]
drm/i915/hdcp: pass struct drm_device to driver specific HDCP GSC code
The driver specific HDCP GSC code will eventually be part of the driver
cores rather than display. Remove the struct intel_display references
from them, and pass struct drm_device instead.
Jani Nikula [Thu, 24 Apr 2025 20:01:38 +0000 (23:01 +0300)]
drm/i915/hdcp: pass the context to the HDCP GSC message interface
The opaque HDCP GSC context nicely abstracts the differences between
drivers. Pass that instead of struct drm_i915_private or struct
xe_device to intel_hdcp_gsc_msg_send(). We can store the driver specific
data in the context.
This lets us drop the dependency on i915_drv.h from
intel_hdcp_gsc_message.c.
Allocate and initialize the HDCP GSC message in
intel_hdcp_gsc_hdcp2_init() as before, but store the pointer to
display->hdcp.hdcp_message in the caller. Similarly, pass in the pointer
to intel_hdcp_gsc_free_message().
Jani Nikula [Thu, 24 Apr 2025 20:01:34 +0000 (23:01 +0300)]
drm/i915/hdcp: deduplicate and refactor HDCP GSC ops initialization
The gsc_hdcp_ops is duplicated and initialized exactly the same way in
two different places (for i915 and xe), and requires forward
declarations for all the hooks. Deduplicate, and make the functions
static.
There are slight differences in the i915 and xe implementations of
intel_hdcp_gsc_init() and intel_hdcp_gsc_fini(). Take the best of both,
and improve.
We need to expose intel_hdcp_gsc_hdcp2_init() and
intel_hdcp_gsc_free_message() for this, and create the latter for xe.
Jani Nikula [Tue, 29 Apr 2025 11:50:55 +0000 (14:50 +0300)]
drm/i915/error: drop dmesg suggestion to file bugs on GPU hangs
We haven't updated the DRIVER_TIMESTAMP since commit 3570bd989acc
("drm/i915: Update DRIVER_DATE to 20230929") 1½ years ago. Before then,
the previous update was commit 139caf7ca286 ("drm/i915: Update
DRIVER_DATE to 20201103") 4+ years ago. The DRIVER_DATE has also been
removed altogether.
We've used the DRIVER_TIMESTAMP to log suggestions to file bugs on GPU
hangs when they happen on a driver less than six months old. Combined
with the sporadic DRIVER_TIMESTAMP updates, we really haven't logged the
suggestions for years.
Just stop logging the suggestion to file bugs altogether, and remove
DRIVER_TIMESTAMP. This doesn't really change anything wrt to logging GPU
errors or how we handle bugs. And effectively we already stopped logging
the message a year ago when we stopped updating DRIVER_TIMESTAMP.
Instead, add an unconditional message about the GPU error state
location.
Jani Nikula [Tue, 29 Apr 2025 11:25:34 +0000 (14:25 +0300)]
drm/i915/backlight: drop dmesg suggestion to file bugs
Drop the FDO_BUG_URL from the source, and stop suggesting to file bugs
on DPCD backlight issues. We don't do this anywhere else in display,
this isn't a special snowflake.
As a consequence, also drop the dependency on i915_utils.h from
intel_dp_aux_backlight.c.
drm/i915/display: move min_hblank from dp_mst.c to dp.c
Minimum HBlank is programmed to address jitter for high resolutions with
high refresh rates that have small Hblank, specifically where Hblank is
smaller than one MTP.
TODO: Add the min_hblank calculation for hdmi as well.
v2: move from intel_audio.c to intel_dp.c
some correction in link_bpp_x16 (Imre)
v3: min_hblank for 8b/10b MST and 128b/132b SST/MST
handle error for intel_dp_mst_dsc_get_slice_count
reset min_hblank before disabling transcoder (Imre)
v4: compute link_bpp_x16 within compute_min_hblank,
return error in case of compute failure
call compute_min_hblank() before vrr_compute_config (Imre)
v5: readout MIN_HBLAN reg for Xe3+
drm/display/dp: Export fn to calculate link symbol cycles
Unify the function to calculate the link symbol cycles for both dsc and
non-dsc case and export the function so that it can be used in the
respective platform display drivers for other calculations.
v2: unify the fn for both dsc and non-dsc case (Imre)
v3: rename drm_dp_link_symbol_cycles to drm_dp_link_data_symbol_cycles
retain slice_eoc_cycles as is (Imre)
v4: Expose only drm_dp_link_symbol_cycles() (Imre)
v6: Add slice pixels which was removed unknowingly (Vinod)
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://lore.kernel.org/r/20250424-hblank-v7-1-8b002f1506cc@intel.com
Jiajia Liu [Wed, 23 Apr 2025 07:37:30 +0000 (15:37 +0800)]
drm/i915/pch: fix warning for coffeelake on SunrisePoint PCH
i915/pch reports a warning on a mini PC which has a CoffeeLake-S GT2
[UHD Graphics 630] [8086:3e92] and an ISA bridge - H110 LPC Controller
[8086:a143].
[5.608723] i915 0000:00:02.0: [drm] Found coffeelake (device ID 3e92) integrated display version 9.00 stepping N/A
[5.608969] ------------[ cut here ]------------
[5.608972] i915 0000:00:02.0: [drm] drm_WARN_ON(!display->platform.skylake && !display->platform.kabylake)
[5.608995] WARNING: CPU: 3 PID: 440 at drivers/gpu/drm/i915/display/intel_pch.c:126 intel_pch_type+0x1af/0xae0 [i915]
[5.609317] CPU: 3 UID: 0 PID: 440 Comm: (udev-worker) Not tainted 6.15.0-rc3-drm-tip-2fa6469c618d #3 PREEMPT(voluntary)
Imre Deak [Mon, 28 Apr 2025 13:47:16 +0000 (16:47 +0300)]
drm/i915/hdmi: Use an intel_connector pointer everywhere
Following the convention, convert intel_hdmi.c to use an intel_connector
pointer everywhere, calling this pointer connector. If the intel
connector must be casted from a drm_connector, call this pointer
_connector and use this pointer only for the casting.
v2: Use for_each_new_intel_connector_in_state(). (Jani)
Imre Deak [Mon, 28 Apr 2025 13:47:15 +0000 (16:47 +0300)]
drm/i915/dp: Use an intel_connector pointer everywhere
Following the convention, convert intel_dp.c to use an intel_connector
pointer everywhere, calling this pointer connector. If the intel
connector must be casted from a drm_connector, call this pointer
_connector and use this pointer only for the casting.
drm/i915/display: Ensure enough lines between delayed VBlank and VBlank
To deterministically capture the transition of the state machine going from
SRDOFFACK to IDLE, the delayed V. Blank should be at least one line after
the non-delayed V. Blank.
Ensure this by adding new interface into intel_psr to query number of lines
needed for vblank delay and call it from intel_crtc_vblank_delay.
v3: use existing intel_crtc_vblank_delay mechanism
v2: apply limits only when needed (VRR TG vs. Legacy TG)
Animesh Manna [Fri, 25 Apr 2025 13:21:07 +0000 (18:51 +0530)]
drm/i915/alpm: Check for alpm support before accessing alpm register
Currently, only EDP supports alpm. So, check for alpm support and prevent
the DP connector from accessing the alpm register if doing so is unsupported.
Currently we disable the VGA plane from various places, sometimes
multiple times in the same init/resume sequence. Get rid of all this
mess and do it just once. The most correct place seems to be just
after intel_early_display_was() as that one applies various workarounds
that need to be in place before we touch any planes (including the
VGA plane).
Actually, we do still have a second caller in
vlv_display_power_well_init(). I think we still need that as the reset
value of VGACNTR is 0x0 and thus technically the VGA plane will be
(at least partially) enabled after the power well has been toggled.
In both cases we have the necessary power reference already held
(INIT power domain for load/resume case, and the display power well
itself being what we need for vlv_display_power_well_init()).
Ville Syrjälä [Thu, 17 Apr 2025 11:44:52 +0000 (14:44 +0300)]
drm/i915/vga: Include the current pipe in the VGA disable debug message
Add some debugs to the VGA plane disable so that we can at least
see from the logs when it happens (and on which pipe). I was curious
about this at some point when I was seeing some random underruns
near the time when we disable the VGA plane, but I think in the end
that turned out to be a red herring.
Ville Syrjälä [Thu, 17 Apr 2025 11:44:50 +0000 (14:44 +0300)]
drm/i915/vga: Add more VGACNTRL bits
Define a pile of extra VGACNTRL bits. We don't really have
any real use for most of these but nicer to have them all
in one place rather than trawling the specs when one wants
to know what's in there.
I will have some real use for the CHV pipe select bits later.
Animesh Manna [Wed, 23 Apr 2025 09:23:30 +0000 (14:53 +0530)]
drm/i915/lobf: Add debug interface for lobf
Add an interface in debugfs which will help in debugging LOBF
feature.
v1: Initial version.
v2:
- Remove FORCE_EN flag. [Jouni]
- Change prefix from I915 to INTEL. [Jani]
- Use u8 instead of bool for lobf-debug flag. [Jani]
v3:
- Use intel_connector instead of display. [Jani]
- Remove edp connector check as it was already present
in caller function. [Jani]
- Remove loop of searching edp encoder which is directly
accessible from intel_connector. [Jani]
v4:
- Simplify alpm debug to bool instead of bit-mask. [Jani]
v5:
- Remove READ_ONCE(). [Jani]
- Modify variable name to *_disable_*. [Jouni]
v6: Improved debug print. [Jouni]
Animesh Manna [Wed, 23 Apr 2025 09:23:29 +0000 (14:53 +0530)]
drm/i915/lobf: Update lobf if any change in dependent parameters
For every commit the dependent condition for LOBF is checked
and accordingly update has_lobf flag which will be used
to update the ALPM_CTL register during commit.
v1: Initial version.
v2: Avoid reading h/w register without has_lobf check. [Jani]
v3: Update LOBF in post plane update instead of separate function. [Jouni]
v4:
- Add lobf disable print. [Jouni]
- Simplify condition check for enabling/disabling lobf. [Jouni]
v5: Disable LOBF in pre_plane_update(). [Jouni]
v6: use lobf flag of old_crtc_state and write 0 into ALPM_CTL. [Jouni]
Animesh Manna [Wed, 23 Apr 2025 09:23:27 +0000 (14:53 +0530)]
drm/i915/lobf: Disintegrate alpm_disable from psr_disable
Currently clearing of alpm registers is done through psr_disable()
which is always not correct, without psr also alpm can exist. So
dis-integrate alpm_disable() from psr_disable().
Animesh Manna [Wed, 23 Apr 2025 09:23:26 +0000 (14:53 +0530)]
drm/i915/lobf: Add debug print for LOBF
Lobf is enabled part of ALPM configuration and if has_lobf
is set to true respective bit for LOBF will be set. Add debug
print while setting the bitfield of LOBF.
Animesh Manna [Wed, 23 Apr 2025 09:23:25 +0000 (14:53 +0530)]
drm/i915/lobf: Add lobf enablement in post plane update
Enablement of LOBF is added in post plane update whenever
has_lobf flag is set. As LOBF can be enabled in non-psr
case as well so adding in post plane update. There is no
change of configuring alpm with psr path.
v1: Initial version.
v2: Use encoder-mask to find the associated encoder from
crtc-state. [Jani]
v3: Remove alpm_configure from intel_psr.c. [Jouni]
drm/i915/alpm: use variable from intel_crtc_state instead of intel_psr
Currently code is making assumption that PSR is enabled when
intel_alpm_configure is called. This doesn't work if alpm is configured
before PSR is enabled.
Jani Nikula [Wed, 23 Apr 2025 10:02:13 +0000 (13:02 +0300)]
drm/i915/reg: Add/remove some extra blank lines
Add/remove some blank lines to/from i915_reg.h primarily to help the
scripted refactoring coming up, separating unrelated registers and
keeping the comments together.
Jani Nikula [Wed, 23 Apr 2025 10:02:12 +0000 (13:02 +0300)]
drm/i915/reg: use REG_BIT and friends to define DP registers
Define the DP register contents using the REG_BIT, REG_GENMASK,
etc. macros. Ditch the unhelpful comments. Rename eDP related register
content macros to have EDP_ prefix.
Scope of intel_psr_needs_block_dc_vblank has changed now. Rename it as
intel_psr_needs_vblank_notification. Also rename
intel_crtc::block_dc_for_vblank as intel_crtc:vblank_psr_notify
drm/i915/psr: Apply underrun on PSR idle workaround
This patch is applying workaround for underrun on idle PSR HW issue
(Wa_16025596647) when PSR is getting enabled. It uses vblank enable/disable
status, DC5/6 enabled disabled and enabled pipes count information made
available.
This patch is also adding calls to dc5/dc6, vblank enable/disable and pipe
enable/disable notification functions as needed.
intel_psr_needs_block_dc_vblank is modified to get vblank enable/disable
notification on PSR capable system.
v2: use intel_dmc interface instead of directly writing dmc register
drm/i915/dmc: Add interface to control start of PKG C-state exit
Add interface to control if package C exit starts at the start of the
undelayed vblank. This is needed to implement workaround for underrun on
idle PSR HW issue (Wa_16025596647).
drm/i915/psr: Add mechanism to notify PSR of DC5/6 enable disable
We need to apply/remove workaround for underrun on idle PSR HW issue
(Wa_16025596647) when DC5/6 is enabled/disabled. This patch implements
mechanism to notify PSR about DC5/6 enable/disable and applies/removes the
workaround using this notification.
drm/i915/psr: Add mechanism to notify PSR of pipe enable/disable
We need to apply/remove workaround for underrun on idle PSR HW issue
(Wa_16025596647) when new pipe is enabled or pipe is getting disabled. This
patch implements mechanism to notify PSR about pipe enable/disable and
applies/removes the workaround using this notification.
We need PIPEDMC_BLOCK_PKGC_SW definitions to implement workaround for
underrun on idle PSR HW issue (Wa_16025596647). Add PIPEDMC_BLOCK_PKGC_SW
register definitions.
To implement workaround for underrun on idle PSR HW issue (Wa_16025596647)
we need PIPEDMC_EVT_CTL_4 register. Add PIPEDMC_EVT_CTL_4 register
definitions.
drm/i915/psr: Store enabled non-psr pipes into intel_crtc_state
To implement workaround for underrun on idle PSR HW issue (Wa_16025596647)
we need to know enabled. Figure out which non-PSR pipes we will have active
and store it into intel_crtc_state->active_non_psr_pipes. This is currently
assuming only one eDP on a time. I.e. possible secondary eDP with PSR
capable panel is not considered.
drm/i915/display: Add new interface for getting dc_state
To implement workaround for underrun on idle PSR HW issue (Wa_16025596647)
we need to have current configured DC state available. Add new interface
for this purpose.
projects / users / jedix / linux-maple.git / log