Imre Deak [Mon, 8 Jul 2024 19:00:26 +0000 (22:00 +0300)]
drm/i915/dp: Reset cached LTTPR count if number of LTTPRs is unsupported
After detection the cached LTTPR count can be checked to determine if
LTTPRs in non-transparent mode were detected. Reset the cached LTTPR
count if the reported number of LTTPRs is invalid to ensure the above
checks work as expected.
Imre Deak [Mon, 8 Jul 2024 19:00:25 +0000 (22:00 +0300)]
drm/i915/dp: Don't switch the LTTPR mode on an active link
Switching to transparent mode leads to a loss of link synchronization,
so prevent doing this on an active link. This happened at least on an
Intel N100 system / DELL UD22 dock, the LTTPR residing either on the
host or the dock. To fix the issue, keep the current mode on an active
link, adjusting the LTTPR count accordingly (resetting it to 0 in
transparent mode).
v2: Adjust code comment during link training about reiniting the LTTPRs.
(Ville)
Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by: Gareth Yu <gareth.yu@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-3-imre.deak@intel.com
Imre Deak [Mon, 8 Jul 2024 19:00:24 +0000 (22:00 +0300)]
drm/i915/dp: Reset intel_dp->link_trained before retraining the link
Regularly retraining a link during an atomic commit happens with the
given pipe/link already disabled and hence intel_dp->link_trained being
false. Ensure this also for retraining a DP SST link via direct calls to
the link training functions (vs. an actual commit as for DP MST). So far
nothing depended on this, however the next patch will depend on
link_trained==false for changing the LTTPR mode to non-transparent.
drm/i915/display: WA for Re-initialize dispcnlunitt1 xosc clock
The dispcnlunit1_cp_xosc_clk should be de-asserted in display off
and only asserted in display on. As part of this workaround, Display
driver shall execute set-reset sequence at the end of the initialize
sequence to ensure clk does not remain active in display OFF.
--v2:
- Rebase.
--v3:
- Correct HSD number in commit message.
--v4:
- Reformat commit message.
- Use intel_de_rmw instead of intel_de_write
--v5:
- Build Fixes.
drm/i915/display: Cache adpative sync caps to use it later
Add new member to struct intel_dp to cache support of Adaptive Sync
SDP capabilities and use it whenever required to avoid HW access
to read capability during each atomic commit.
Gustavo Sousa [Tue, 25 Jun 2024 20:26:52 +0000 (17:26 -0300)]
drm/i915: Skip programming FIA link enable bits for MTL+
Starting with Xe_LPD+, although FIA is still used to readout Type-C pin
assignment, part of Type-C support is moved to PICA and programming
PORT_TX_DFLEXDPMLE1(*) registers is not applicable anymore like it was
for previous display IPs (e.g. see BSpec 49190).
v2:
- Mention Bspec 49190 as a reference of instructions for previous
IPs. (Shekhar Chauhan)
- s/Xe_LPDP/Xe_LPD+/ in the commit message. (Matt Roper)
- Update commit message to be more accurate to the changes in the IP.
(Imre Deak)
Imre Deak [Wed, 26 Jun 2024 17:08:13 +0000 (20:08 +0300)]
drm/i915/mtl: Skip PLL state verification in TBT mode
In TBT-alt mode the driver doesn't program the PHY's PLL, which is
handled instead by Thunderbolt driver/FW components, hence the PLL's HW
vs. SW state verification should be skipped. During HW readout set a flag
in the PLL state if the port was at the moment in TBT-alt mode and skip
the verification of PLL parameters in this case.
Fixes: 45fe957ae769 ("drm/i915/display: Add compare config for MTL+ platforms") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11258 Cc: 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://patchwork.freedesktop.org/patch/msgid/20240626170813.806470-1-imre.deak@intel.com
Ville Syrjälä [Tue, 11 Jun 2024 13:33:44 +0000 (16:33 +0300)]
drm/i915/dsb: Try to document that DSB_STATUS bit 16 is level triggered
DSB_STATUS bit 16 is supposed to be a sticky bit informing us whether
the DSB was idle or not when the pipe's delayed vblank (when double
buffered registers latch) occurred. Unfortunately it turns out this
is a level triggred signal, ie. the bit will be set whenever the
DSB is busy during the scanline window between start of delayed
vblank and vtotal. Try to document that fact by renaming the bit.
Sadly this also thwarts my plan to use this bit to sanity check
that the (to be introduced) DSB based vblank evasion did its job
correctly. That would require an edge triggered signal instead.
So looks like we'll have to rely mostly on luck instead :(
Jouni Högander [Wed, 19 Jun 2024 06:21:29 +0000 (09:21 +0300)]
drm/i915/psr: Perform scanline indication check for Panel Replay as well
Scanline indication needs to be checked and configure for both PSR2 and
Panel Replay Selective Update. Move this check to
intel_sel_update_config_valid.
Jouni Högander [Wed, 19 Jun 2024 06:21:28 +0000 (09:21 +0300)]
drm/i915/psr: Perform psr2 checks related to ALPM for Panel Replay
eDP1.5 support ALPM with Panel Replay as well. We need to check ALPM
related things for Panel Replay as well.
Bspec: 68920
v5:
- instead of using crtc_state->has_panel_replay provide aux_less flag
v4:
- do not move _compute_psr2_sdp_prior_scanline_indication
- move ALPM related checks to separate function
v3: move vblank check as well
v2: do not move Vblank >= PSR2_CTL Block Count Number maximum line count
check
Jouni Högander [Wed, 19 Jun 2024 06:21:23 +0000 (09:21 +0300)]
drm/i915/psr: enable sink for eDP1.5 Panel Replay
eDP1.5 allows Panel Replay on eDP as well. Take this into account when
enabling sink PSR/Panel Replay. Write also PANEL_REPLAY_CONFIG2 register
accordingly.
v3:
- set DP_PANEL_REPLAY_CRC_VERIFICATION in PANEL_REPLAY_CONFIG2
- PANEL_REPLAY_CONFIG2 is available in DP2.1 as well
v2: do not configure ALPM for DP2.0 Panel Replay
Maarten Lankhorst [Wed, 22 May 2024 05:33:41 +0000 (07:33 +0200)]
drm/i915: Use the same vblank worker for atomic unpin
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old commit that
wasn't cleaned up.
The only option remaining is to remove the plane from the atomic commit,
and use the same path as the legacy cursor update to clean the state
after vblank.
Changes since previous version:
- Call the memset for plane state immediately when scheduling vblank,
this prevents a use-after-free in cursor cleanup.
Ville Syrjälä [Wed, 22 May 2024 05:33:40 +0000 (07:33 +0200)]
drm/i915: Use vblank worker to unpin old legacy cursor fb safely
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased accessing it. The simplest approach is to just use a vblank
work here to do the delayed unpin.
Not 100% sure it's a good idea to put this onto the same high
priority vblank worker as eg. our timing critical gamma updates.
But let's keep it simple for now, and it we later discover that
this is causing problems we can think about adding a lower
priority worker for such things.
Ville Syrjälä [Wed, 12 Jun 2024 20:47:12 +0000 (23:47 +0300)]
drm/i915: Nuke the TGL+ chroma plane tile row alignment stuff
I don't think the display hardware really has such chroma
plane tile row alignment requirements as outlined in
commit d156135e6a54 ("drm/i915/tgl: Make sure a semiplanar
UV plane is tile row size aligned")
Bspec had the same exact thing to say about earlier hardware
as well, but we never cared and things work just fine.
The one thing mentioned in that commit that is definitely
true however is the fence alignment issue. But we don't
deal with that on earlier hardware either. We do have code
to deal with that issue for the first color plane, but not
the chroma planes. So I think if we did want to check this
more extensively we should do it in the same places where
we already check the first color plane (namely
convert_plane_offset_to_xy() and intel_fb_bo_framebuffer_init()).
Ville Syrjälä [Wed, 12 Jun 2024 20:47:11 +0000 (23:47 +0300)]
drm/i915: Update plane alignment requirements for TGL+
Currently we still use the SKL+ PLANE_SURF alignment even
for TGL+ even though the hardware no longer needs it.
Introduce a separate tgl_plane_min_alignment() and update
it to more accurately reflect the hardware requirements.
Ville Syrjälä [Wed, 12 Jun 2024 20:47:10 +0000 (23:47 +0300)]
drm/i915: Move intel_surf_alignment() into skl_univerals_plane.c
Now that all pre-skl platforms have their own .min_alignment()
functions the remainder of intel_surf_alignment() can be hoisted
into skl_univerals_plane.c (and renamed appropriately).
Ville Syrjälä [Wed, 12 Jun 2024 20:47:07 +0000 (23:47 +0300)]
drm/i915: Introduce fb->min_alignment
Different planes could have different alignment requirements
even for the same format/modifier. Collect the alignment
requirements across all planes capable of scanning out the
fb such that the alignment is satisfactory to all those
planes.
So far this was sort of handled by making sure intel_surf_alignment()
declares the superset of all planes' alignment requirements,
but maintaining that manually is annoying. So we're going to move
towards each plane declaring only its own requirements, and thus
we need code to generate the superset.
v2: Drop the borked per-plane vma optimization (Imre)
Assert that the plane's declared alignment is POT (Imre)
Ville Syrjälä [Wed, 12 Jun 2024 20:47:06 +0000 (23:47 +0300)]
drm/i915: Introduce the plane->min_alignment() vfunc
Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.
For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.
For fbdev we (temporarily) introduce intel_fbdev_min_alignment()
that simply queries the alignment from the primary plane of
the first crtc.
TODO: someone will need to fix xe's alignment handling
Ville Syrjälä [Wed, 19 Jun 2024 11:31:44 +0000 (14:31 +0300)]
drm: Export drm_plane_has_format()
Export drm_plane_has_format() so that drivers can use it.
v2: add kerneldoc
Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240619113144.1616-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Jouni Högander [Thu, 20 Jun 2024 10:33:12 +0000 (13:33 +0300)]
drm/i915/psr: Set DP_PSR_SU_REGION_SCANLINE_CAPTURE bit when needed
Setting DP_PSR_SU_REGION_SCANLINE_CAPTURE (Selective Update Region Scan
Line Capture Indication in spec) bit was dropped when psr_enable_sink was
split to _psr_enable_sink and _panel_replay_enable_sink. Add setting it
back.
Imre Deak [Tue, 18 Jun 2024 12:52:55 +0000 (15:52 +0300)]
drm/xe: Use the encoder suspend helper also used by the i915 driver
Use the suspend encoders helper which is also used by the i915 driver.
This fixes an issue in the xe driver where the encoder
suspend_complete() hook is not called and was an overlook when this hook
was added in commit b61fad5f7e5d ("drm/i915/tc: Call TypeC port
flush_work/cleanup without modeset locks held") for i915, but not added
to the xe driver (which was still in a separate source tree at the above
point).
Ville Syrjälä [Tue, 11 Jun 2024 13:33:43 +0000 (16:33 +0300)]
drm/i915/dsb: Document that the ATS fault bits are for mtl+
The ATS faults have something to do with some new iommu stuff
on mtl+. Document that the relevant DSB interrupt bits aren't
valid for earlier platforms.
As we extend the use of DSB for critical pipe/plane register
programming, it'll be nice to have an escape valve at hand,
in case things go very poorly. To that end, add a i915.enable_dsb
modparam by which we can force the driver to take the pure mmio
path instead.
v2: Use 0400 permissions for the actual modparam (Jani)
Ville Syrjälä [Tue, 11 Jun 2024 13:33:37 +0000 (16:33 +0300)]
drm/i915: Introduce intel_mode_vdisplay()
The DSB code will need to know the hardware's idea of vertical
active, as that is also what defines the start of undelayed
vblank. Introduce a helper that gives us that information,
in line with the other intel_mode_v*() functions.
Ville Syrjälä [Wed, 5 Jun 2024 11:18:30 +0000 (14:18 +0300)]
drm/i915: Nuke the intermediate pipe fault bitmasks
GEN8_DE_PIPE_IRQ_FAULT_ERRORS & co. don't really achieve anything.
Get rid of them and just declare all the bits directly in
gen8_de_pipe_fault_mask().
Ville Syrjälä [Wed, 5 Jun 2024 11:18:29 +0000 (14:18 +0300)]
drm/i915: Extend GEN9_PIPE_PLANE_FLIP_DONE() to cover all universal planes
GEN9_PIPE_PLANE_FLIP_DONE() only works for planes 1-4. Extend
it handle planes 5-7 as well. Somewhat annoyingly the bits are
spread around into two distinct clumps.
Currently this doesn't achieve anything, but if we ever extend
async flip support to more than just the first plane then we'll
need this.
Ville Syrjälä [Wed, 5 Jun 2024 11:18:28 +0000 (14:18 +0300)]
drm/i915: Sort bdw+ pipe interrupt bits
It's really hard to figure out which bdw+ pipe interrupt bits
we've defined and which we have not. Sort the defines to make
that a bit easier (still not super easy since the bits have
been shuffled a bit over the years).
We want to notice possible issues faced with PSR2 Region Early Transport as
early as possible -> let's revert patch disabling Region Early Transport by
default. Also eDP 1.5 Panel Replay requires Early Transport.
Jouni Högander [Tue, 18 Jun 2024 05:30:22 +0000 (08:30 +0300)]
drm/i915/psr: Disable PSR2 SU Region ET if enable_psr module parameter is set
Currently PSR2 SU Region Early Transport is enabled by default on Lunarlake
if panel supports it despite enable_psr module parameter value. This patch
makes it possible for user to limit used PSR mode and prevent SU Region
Early Transport by setting enable_psr as 2. With default (-1) PSR2 SU
Region Early Transport is allowed.
Jouni Högander [Tue, 18 Jun 2024 05:30:21 +0000 (08:30 +0300)]
drm/i915/psr: Disable Panel Replay if PSR mode is set via module parameter
If user is specifically limiting PSR mode to PSR1 or PSR2: disable Panel
Replay. With default value -1 all modes are allowed including Panel
Replay. Disabling PSR using value 0 disables Panel Replay as well.
Also own compute config helper is added for Panel Replay. This makes sense
because number of Panel Replay specific checks are increasing.
Vinod Govindapillai [Tue, 28 May 2024 11:48:26 +0000 (14:48 +0300)]
drm/i915/display: update handling of FBC when VT-d active workaround
Move the handling of the disabling FBC when VT-d is active wa
as part of the intel_fbc_check_plane(). As the hw is still there,
intel_fbc_sanitize should be able to handle the state properly.
v2: update the patch description (Jani Nikula)
v3: fix the return value in wa handling (Jani Nikula)
Jani Nikula [Fri, 14 Jun 2024 09:22:37 +0000 (12:22 +0300)]
drm/i915: use i9xx_fsb_freq() for GT clock frequency
Reuse i9xx_fsb_freq() for GT clock frequency initialization instead of
depending on rawclk_freq.
Note: If the init order was changed, we could use i915->fsb_freq
directly. However, GT clock initialization is done in
i915_driver_mmio_probe(), but intel_dram_detect() later in
i915_driver_hw_probe(), with a dependency on intel_pcode_init().
Jani Nikula [Fri, 14 Jun 2024 09:22:35 +0000 (12:22 +0300)]
drm/i915: convert fsb_freq and mem_freq to kHz
We'll want to use fsb frequency for deriving GT clock and rawclk
frequencies in the future. Increase the accuracy by converting to
kHz. Do the same for mem freq to be aligned.
Round the frequencies ending in 666 to 667.
v2: Also handle mem_freq in gen5_rps_init() (Ville)
Ville Syrjälä [Fri, 17 May 2024 14:53:53 +0000 (17:53 +0300)]
drm/i915: Use intel_dp_has_dsc() during .compute_config()
Reuse intel_dp_has_dsc() during .compute_config() instead of
repeating some of the checks again by hand. We'll be adding
more checks to intel_dp_has_dsc() and this will make sure
we cover both .mode_valid() and .compute_config() with them.
Ville Syrjälä [Fri, 17 May 2024 14:53:51 +0000 (17:53 +0300)]
drm/i915: Extract intel_dp_has_dsc()
Extract a helper to check whether the source+sink combo
supports DSC. That basic check is needed both during mode
validation and compute config. We'll also need to add extra
checks to both places, so having a single place for it is nicer.
Jani Nikula [Fri, 7 Jun 2024 15:25:36 +0000 (18:25 +0300)]
drm/i915/gvt: use proper i915_reg_t for calc_index() parameters
In order to be able to use the proper register macros instead of the
underscore prefixed ones, pass i915_reg_t for the calc_index()
parameters.
Side note: DSPSURF is really about planes, not pipes. Fixed stride
doesn't work for plane C for CHV (but that's okay for gvt). This doesn't
support planes beyond C either. But all that is unrelated to the change
at hand.
Imre Deak [Mon, 10 Jun 2024 16:49:32 +0000 (19:49 +0300)]
drm/i915/dp: Add debugfs entry to force link retrain
Add a connector debugfs entry to force retrain an active link. This can
be used to test both custom link parameters (previously forced via the
force_link_rate/lane_count entries) or link train failure scenarios
(previously forced via the force_link_training_failure entry). The entry
will autoreset after the link-retrain is complete.
v2: Add the entry from intel_dp_link_training.c (Jani)
v3: Lock connection_mutex only for the required intel_dp state. (Ville)
Imre Deak [Mon, 10 Jun 2024 16:49:31 +0000 (19:49 +0300)]
drm/i915/dp: Add debugfs entry to force link training failure
Add a connector debugfs entry to force a failure during the following
1-2 link training. The entry will auto-reset after the specified link
training events are complete.
v2: Add the entry from intel_dp_link_training.c (Jani)
v3: Lock connection_mutex only for the required intel_dp state. (Ville)
Imre Deak [Mon, 10 Jun 2024 16:49:29 +0000 (19:49 +0300)]
drm/i915/dp: Add debugfs entries to force the link rate/lane count
Add connector debugfs entries to force the link rate/lane count to be
used by a link training afterwards. These settings will be clamped to
the supported, i.e. the source's and sink's common rate/lane count.
After forcing the link rate/lane count reset the link training
parameters and for a non-auto setting disable reducing the link
parameters via the fallback logic. The former one can be used after
testing link training failure scenarios - via debugfs entries added
later - to reset the reduced link parameters after the test.
v2:
- Add the entries from intel_dp_link_training.c (Jani)
- Rename the entries to i915_dp_set_link_rate/lane_count.
v3: (Ville)
- Rename the entries/struct fields to force_link_rate/lane_count.
- Lock connection_mutex only for the required intel_dp state.
Imre Deak [Mon, 10 Jun 2024 16:49:28 +0000 (19:49 +0300)]
drm/i915/dp_mst: Enable link training fallback for MST
Reduce the link parameters after a link training failure for MST
outputs, similarly to how this is done for SST.
For now allow the reduction only by staying in the 8b/10b vs. 128b/132b
mode. Enabling the mode switch is left for a follow-up patchset, after
taking measures ensuring that the mode switch happens properly. In
particular a rediscovery of the whole MST topology may be required for
such a switch, see the References below.
Imre Deak [Mon, 10 Jun 2024 16:49:27 +0000 (19:49 +0300)]
drm/i915/dp_mst: Reset intel_dp->link_trained during disabling
Reset the flag indicating an active link after disabling an MST link,
similarly to how this is done for SST outputs. This avoids trying to
retrain an MST link while its disabled.
Imre Deak [Mon, 10 Jun 2024 16:49:26 +0000 (19:49 +0300)]
drm/i915/dp: Disable link retraining after the last fallback step
After a link training failure if the link parameters can't be further
reduced, there is no point in trying to retrain the link in the driver.
This avoids excessive retrain attempts after detecting a bad link, for
instance while handling MST HPD IRQs, which is likely redundant as the
link training failed already twice with the same minimum link
parameters. Userspace can still try to retrain the link with these
parameters via a modeset.
While at it make the error message more accurate.
v2: Move converting the error to a debug message to the relevant
follow-up patch. (Ville)
Imre Deak [Mon, 10 Jun 2024 16:49:25 +0000 (19:49 +0300)]
drm/i915/dp: Use check link state work in the HPD IRQ handler
Simplify things by retraining a DP link if a bad link is detected in the
HPD IRQ handler from the encoder's check link state work, similarly to
how this is done after a modeset link training failure.
projects / nvme.git / log