Ville Syrjälä [Tue, 16 Jan 2024 20:49:27 +0000 (22:49 +0200)]
drm/i915: Perform vblank evasion around legacy cursor updates
Our legacy cursor updates are actually mailbox updates.
Ie. the hardware latches things once per frame on start of
vblank, but we issue an number of updates per frame,
withough any attempt to synchronize against the vblank
in software. So in theory only the last update issued
during the frame will latch, and the previous ones are
discarded.
However this can lead to problems with maintaining the
ggtt/iommu mappings as we have no idea which updates
will actually latch.
The problem is exacerbated by the hardware's annoying disarming
behaviour; any non-arming register write will disarm an already
armed update, only to be rearmed later by the arming register
(CURBASE in case of cursors). If a disarming write happens
just before the start of vblank, and the arming write happens
after start of vblank we have effectively prevented the hardware
from latching anything. And if we manage to straddle multiple
sequential vblank starts in this manner we effectively prevent
the hardware from latching any new registers for an arbitrary
amount of time. This provides more time for the (potentially
still in use by the hardware) gtt/iommu mappings to be torn
down.
A partial solution, of course, is to use vblank evasion to
avoid the register writes from spreading on both sides of
the start of vblank.
I've previously highlighted this problem as a general issue
affecting mailbox updates. I even added some notes to the
{i9xx,skl}_crtc_planes_update_arm() to remind us that the noarm
and arm phases both need to pulled into the vblank evasion
critical section if we actually decided to implement mailbox
updates in general. But as I never impelemented the noarm+arm
split for cursors we don't have to worry about that for the
moment.
We've been lucky enough so far that this hasn't really caused
problems. One thing that does help is that Xorg generally
sticks to the same cursor BO. But igt seems pretty good at
hitting this on MTL now, so apparently we have to start
thinking about this.
v2: Wait for PSR exit to avoid the vblank evasion timeout (1ms)
tripping due to PSR exit latency (~5ms typically)
Ville Syrjälä [Wed, 13 Dec 2023 10:25:16 +0000 (12:25 +0200)]
drm/i915: Move the min/max scanline sanity check into intel_vblank_evade()
There isn't really any reason to make the caller suffer through
checking the vblank evasion min/max scanlines. If we somehow
ended up with bogus values (which really shouldn't happen)
then just skip the actual vblank evasion loop but otherwise
plow ahead as normal.
The only "real" change is that we now get+put a vblank reference
even if the min/max values are bogus, previously we skipped
directly to the end.
Ville Syrjälä [Wed, 13 Dec 2023 10:25:13 +0000 (12:25 +0200)]
drm/i915: Introduce struct intel_vblank_evade_ctx
Collect the information needed for vblank evasions into
a structure that we can pass around more easily.
And let's rename intel_crtc_vblank_evade_scanlines() to just
intel_vblank_evade_init() so that better describes the intended
usage of initializing the context.
Ville Syrjälä [Wed, 13 Dec 2023 10:25:12 +0000 (12:25 +0200)]
drm/i915: Reorder drm_vblank_put() vs. need_vlv_dsi_wa
Drop the vblank reference only after we've done the hideous
need_vlv_dsi_wa stuff. This will make it easier to reuse the
the vblank evasion machinery elsewhere.
Keeping the vblank reference for a bit longer is not a
problem. In fact we might want to not drop it at all until
intel_pipe_update_end(), but we'll leave that idea for later.
Ville Syrjälä [Wed, 13 Dec 2023 10:25:11 +0000 (12:25 +0200)]
drm/i915: Decouple intel_crtc_vblank_evade_scanlines() from atomic commits
We'll be needing to do vblank evasion around legacy cursor updates,
which don't have the intel_atomic_state around. So let's remove
this dependency on a full commit and pass the crtc state in by hand.
Ville Syrjälä [Thu, 18 Jan 2024 21:21:31 +0000 (23:21 +0200)]
drm/i915/psr: Only allow PSR in LPSP mode on HSW non-ULT
On HSW non-ULT (or at least on Dell Latitude E6540) external displays
start to flicker when we enable PSR on the eDP. We observe a much higher
SR and PC6 residency than should be possible with an external display,
and indeen much higher than what we observe with eDP disabled and
only the external display enabled. Looks like the hardware is somehow
ignoring the fact that the external display is active during PSR.
I wasn't able to redproduce this on my HSW ULT machine, or BDW.
So either there's something specific about this particular laptop
(eg. some unknown firmware thing) or the issue is limited to just
non-ULT HSW systems. All known registers that could affect this
look perfectly reasonable on the affected machine.
As a workaround let's unmask the LPSP event to prevent PSR entry
except while in LPSP mode (only pipe A + eDP active). This
will prevent PSR entry entirely when multiple pipes are active.
The one slight downside is that we now also prevent PSR entry
when driving eDP with pipe B or C, but I think that's a reasonable
tradeoff to avoid having to implement a more complex workaround.
Lucas De Marchi [Fri, 12 Jan 2024 15:49:12 +0000 (07:49 -0800)]
drm/i915: Drop -Wstringop-overflow
-Wstringop-overflow is broken on GCC11. In future changes it will
be moved to the normal C flags in the top level Makefile (out of
Makefile.extrawarn), but accounting for the compiler support.
Just remove it out of i915's forced extra warnings, preparing for the
upcoming change and avoiding build warnings to show up.
Lenovo 82TQ is unhappy if we do the display on sequence this
late. The display output shows severe corruption.
It's unclear if this is a failure on our part (perhaps
something to do with sending commands in LP mode after HS
/video mode transmission has been started? Though the backlight
on command at least seems to work) or simply that there are
some commands in the sequence that are needed to be done
earlier (eg. could be some DSC init stuff?). If the latter
then I don't think the current Windows code would work
either, but maybe this was originally tested with an older
driver, who knows.
Root causing this fully would likely require a lot of
experimentation which isn't really feasible without direct
access to the machine, so let's just accept failure and
go back to the original sequence.
Dave Airlie [Wed, 10 Jan 2024 01:14:05 +0000 (11:14 +1000)]
nouveau/gsp: handle engines in runl without nonstall interrupts.
It appears on TU106 GPUs (2070), that some of the nvdec engines
are in the runlist but have no valid nonstall interrupt, nouveau
didn't handle that too well.
Dave Airlie [Sun, 14 Jan 2024 22:06:19 +0000 (08:06 +1000)]
Merge tag 'drm-intel-next-fixes-2024-01-11' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Fixes for kernel-doc warnings enforced in linux-next
- Another build warning fix for string formatting of intel_wakeref_t
- Display fixes for DP DSC BPC and C20 PLL state verification
Randy Dunlap [Tue, 26 Dec 2023 19:54:32 +0000 (11:54 -0800)]
drm/i915/perf: reconcile Excess struct member kernel-doc warnings
Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.
i915_perf_types.h:341: warning: Excess struct member 'ptr_lock' description in 'i915_perf_stream'
i915_perf_types.h:341: warning: Excess struct member 'head' description in 'i915_perf_stream'
i915_perf_types.h:341: warning: Excess struct member 'tail' description in 'i915_perf_stream'
3 warnings as Errors
Randy Dunlap [Tue, 26 Dec 2023 19:54:31 +0000 (11:54 -0800)]
drm/i915/guc: reconcile Excess struct member kernel-doc warnings
Document nested struct members with full names as described in
Documentation/doc-guide/kernel-doc.rst.
intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'num_guc_ids' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids_bitmap' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_id_list' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'guc_ids_in_use' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'destroyed_contexts' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'destroyed_worker' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'reset_fail_worker' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'reset_fail_mask' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'sched_disable_delay_ms' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'sched_disable_gucid_threshold' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'lock' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'gt_stamp' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'ping_delay' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'work' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'shift' description in 'intel_guc'
intel_guc.h:305: warning: Excess struct member 'last_stat_jiffies' description in 'intel_guc'
18 warnings as Errors
Jani Nikula [Thu, 4 Jan 2024 16:46:00 +0000 (18:46 +0200)]
drm/i915: don't make assumptions about intel_wakeref_t type
intel_wakeref_t is supposed to be a mostly opaque cookie to its
users. It should only be checked for being non-zero and set to
zero. Debug logging its actual value is meaningless. Switch to just
debug logging whether the async_put_wakeref is non-zero.
The issue dates back to much earlier than
commit b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker
with ref_tracker library"), but this is the one that brought about a
build failure due to the printf format.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20240102111222.2db11208@canb.auug.org.au Fixes: b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240104164600.783371-1-jani.nikula@intel.com
(cherry picked from commit de06b42edc5bf05aefbb7e2f59475d6022ed57e1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Imre Deak [Wed, 3 Jan 2024 15:26:09 +0000 (17:26 +0200)]
drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
MST connectors don't have a static attached encoder, as their encoder
can change depending on the pipe they use; so the encoder for an MST
connector can't be retrieved using intel_dp_attached_encoder() (which
may return NULL for MST). Most of the PSR debugfs entries depend on a
static connector -> encoder mapping which is only true for eDP and SST
DP connectors and not for MST. These debugfs entries were enabled for
MST connectors as well recently to provide PR information for them, but
handling MST connectors needs more changes.
Fix this by not adding for now the PSR entries on MST connectors. To
make things more uniform add the entries for SST connectors on all
platforms, not just on platforms supporting DP2.0.
v2:
- Keep adding the entries for SST connectors. (Jouni)
- Add a TODO: comment for MST support.
Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850 Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103152609.2434100-1-imre.deak@intel.com
(cherry picked from commit 9b0b61c5bc08e1aa55a0c1e7cda28f952b2d02cc) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Mika Kahola [Tue, 2 Jan 2024 11:57:39 +0000 (13:57 +0200)]
drm/i915/display: Fix C20 pll selection for state verification
Add pll selection check for C20 as well as
clock state verification0. We have been relying
on sw state to select A or B pll's. This is incorrect
as the hw might see this selection differently. This
patch fixes this shortcoming by reading pll selection
for both sw and hw states and compares if these two
selections match.
Fixes: 59be90248b42 ("drm/i915/mtl: C20 state verification")
v2: reword commit message and include fix to a
original commit (Imre)
Compare pll selection (Jani)
Maíra Canal [Tue, 9 Jan 2024 11:30:40 +0000 (08:30 -0300)]
drm/v3d: Fix support for register debugging on the RPi 4
RPi 4 uses V3D 4.2, which is currently not supported by the register
definition stated at `v3d_core_reg_defs`. We should be able to support
V3D 4.2, therefore, change the maximum version of the register
definition to 42, not 41.
Ankit Nautiyal [Wed, 13 Dec 2023 09:16:29 +0000 (14:46 +0530)]
drm/i915/dp: Fix the max DSC bpc supported by source
Use correct helper for getting max DSC bpc supported by the source.
Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Swati Sharma <swati2.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213091632.431557-3-ankit.k.nautiyal@intel.com
Gustavo Sousa [Fri, 5 Jan 2024 14:05:37 +0000 (11:05 -0300)]
drm/i915/cdclk: Reorder bxt_sanitize_cdclk()
Make the sequence of steps in bxt_sanitize_cdclk() more logical by
grouping things related to the check on the value of CDCLK_CTL into a
single "block". Also, this will make an upcoming change replacing that
block with a single function call easier to follow.
v2:
- Improve body of commit message to be more self-contained.
Gustavo Sousa [Fri, 5 Jan 2024 14:05:36 +0000 (11:05 -0300)]
drm/i915/cdclk: Extract bxt_cdclk_ctl()
Extract logic for deriving the value for CDCLK_CTL into bxt_cdclk_ctl().
This makes the code better readable and will be used later in
bxt_sanitize_cdclk().
v2:
- Improve body of commit message to be more self-contained.
Gustavo Sousa [Fri, 5 Jan 2024 14:05:35 +0000 (11:05 -0300)]
drm/i915/xe2lpd: Update bxt_sanitize_cdclk()
With Xe2_LPD, there were changes to the way CDCLK_CTL must be
programmed. Those were reflected on _bxt_set_cdclk() with commit 3d3696c0fed1 ("drm/i915/lnl: Start using CDCLK through PLL"), but
bxt_sanitize_cdclk() was left out.
This was causing some issues when loading the driver with a pre-existing
active display configuration: the driver would mistakenly take the
current value of CDCLK_CTL as wrong and the sanitization would be
triggered.
In a scenario where the display was already configured with a high
CDCLKC and had plane(s) enabled, FIFO underrun errors were reported,
because the current sanitization code selects the minimum possible
CDCLK.
Fix that by updating bxt_sanitize_cdclk() to match the changes made in
_bxt_set_cdclk(). Ideally, we would have a common function to derive the
value for CDCLK_CTL, but that can be done in a future change.
Imre Deak [Thu, 4 Jan 2024 08:30:08 +0000 (10:30 +0200)]
drm/i915/dp: Abort AUX on disconnected native DP ports
An AUX transfer on any disconnected DP port results in long
timeout/retry delays the same way as this is described for TypeC port in
commit a972cd3f0eb5 ("drm/i915/tc: Abort DP AUX transfer on a disconnected TC port")
Prevent the delay on non-TypeC ports as well by aborting the transfer if
the port is disconnected. For eDP keep the current behavior as the
support for HPD signaling is optional for it.
Imre Deak [Thu, 4 Jan 2024 08:30:07 +0000 (10:30 +0200)]
drm/i915: Filter out glitches on HPD lines during hotplug detection
Glitches deasserting the connector HPD line can lead to incorrectly
detecting a disconnect event (a glitch asserting the line will only
cause a redundant connect->disconnect transition). The source of such a
glitch can be noise on the line or a 0.5ms-1ms MST IRQ_HPD pulse. TypeC
ports in the DP-alt or TBT-alt mode filter out these glitches inernally,
but for others the driver has to do this. Make it so by polling the HPD
line on these connectors for 4 ms.
Add hooks to intel_digital_port to lock and unlock the port and add a
helper to check the connector's detect status while the port is locked
already. This simplifies checking the connector detect status in
intel_dp_aux_xfer() and intel_digital_port_connected() in the next two
patches aborting AUX transfers on all DP connectors (except eDP) and
filtering HPD glitches.
Imre Deak [Thu, 4 Jan 2024 08:30:05 +0000 (10:30 +0200)]
drm/i915: Disable hotplug detection handlers during driver init/shutdown
As described in the previous two patches an unexpected connector
detection can happen during the init/shutdown sequences. Prevent these
by returning the connector's current status from the detection handlers.
Imre Deak [Thu, 4 Jan 2024 08:30:04 +0000 (10:30 +0200)]
drm/i915: Disable hotplug detection works during driver init/shutdown
As described in the previous patch, an unexpected connector
detection/modeset started from the intel_hotplug::hotplug_work can
happen during the driver init/shutdown sequence. Prevent these by
disabling the queuing of and flushing all the intel_hotplug work that
can start them at the beginning of the init/shutdown sequence and allow
the queuing only while the display is in the initialized state.
Other work items - like the intel_connector::modeset_retry_work or the
MST probe works - are still enabled and can start a detection/modeset,
but after the previous patch these will be rejected. Disabling these
works as well is for a follow-up patchset.
Imre Deak [Thu, 4 Jan 2024 13:23:35 +0000 (15:23 +0200)]
drm/i915: Prevent modesets during driver init/shutdown
An unexpected modeset or connector detection by a user (user space or FB
console) during the initialization/shutdown sequence is possible either
via a hotplug IRQ handling work or via the connector sysfs
(status/detect) interface. These modesets/detections should be prevented
by disabling/flushing all related hotplug handling work and
unregistering the interfaces that can start them at the beginning of the
shutdown sequence. Some of this - disabling all related intel_hotplug
work - will be done by the next patch, but others - for instance
disabling the MST hotplug works - require a bigger rework.
It makes sense - for diagnostic purpose, even with all the above work and
interface disabled - to detect and reject any such user access. This
patch does that for modeset accesses and a follow-up patch for connector
detection.
During driver loading/unloading/system suspend/shutdown and during
system resume after calling intel_display_driver_disable_user_access()
or intel_display_driver_resume_access() correspondigly, the current
thread is allowed to modeset (as this thread requires to do an
initial/restoring modeset or a disabling modeset), other threads (the
user threads) are not allowed to modeset.
During driver loading/system resume after calling
intel_display_driver_enable_user_access() all threads are allowed to
modeset.
During driver unloading/system suspend/shutdown after calling
intel_display_driver_suspend_access() no threads are allowed to modeset
(as the HW got disabled and should stay in this state).
v2: Call intel_display_driver_suspend_access()/resume_access() only
for HAS_DISPLAY(). (CI)
v3: (Jouni)
- Add commit log comments explaining how the permission of modeset
changes during HW init/deinit wrt. to the current and other user
processes.
Imre Deak [Thu, 4 Jan 2024 08:30:02 +0000 (10:30 +0200)]
drm/i915: Suspend the framebuffer console earlier during system suspend
Suspend the FB console early during system suspend to prevent new FB
probe/modeset cycles interfering with the HW uninitialization steps in a
similar way as during driver shutdown as described in the previous
patch.
Imre Deak [Thu, 4 Jan 2024 08:30:01 +0000 (10:30 +0200)]
drm/i915: Suspend the framebuffer console during driver shutdown
Suspend the FB console during driver shutdown the same way this is done
during system resume. This should prevent any HPD event to trigger a new
FB probe/modeset cycle happening in parallel with the display HW
disable/uninitialize steps.
A preceding FB HPD event handling may be still pending, resulting in a
probe/modeset like the above, these will be prevented by a later change
in this patchset.
Imre Deak [Thu, 4 Jan 2024 08:30:00 +0000 (10:30 +0200)]
drm/i915: Disable intel HPD poll after DRM poll init/enable
The only purpose of intel_hpd_poll_disable() during driver loading and
system resume - at which point polling should be disabled anyway, except
for connectors in an IRQ storm, for which the polling will stay enabled -
is to force-detect all the connectors. However this detection in
i915_hpd_poll_init_work() depends on drm.mode_config.poll_enabled, which
will get set in drm_kms_helper_poll_init(), possibly after
i915_hpd_poll_init_work() is scheduled. Hence the initial detection of
connectors during driver loading may not happen.
Fix the above by moving intel_hpd_poll_disable() after
i915_hpd_poll_init_work(), the proper place anyway for doing the above
detection after all the HW initialization steps are complete. Change the
order the same way during system resume as well. The above race
condition shouldn't matter here - as drm.mode_config.poll_enabled will
be set - but the detection should happen here as well after the HW init
steps are done.
Imre Deak [Thu, 4 Jan 2024 08:29:59 +0000 (10:29 +0200)]
drm/i915: Move audio deinit after disabling polling
Deinitialize audio during driver unload after disabling polling. This is
in preparation to do all the display HW init/deinit steps at a point
where no HPD IRQ or polling initiated connector detection or modeset can
change the HW state. This may still happen here via an HPD IRQ ->
hotplug detection work or a connector sysfs (state/detect) access, but
these will be prevented by later changes in this patchset.
Imre Deak [Thu, 4 Jan 2024 08:29:58 +0000 (10:29 +0200)]
drm/i915: Keep the connector polled state disabled after storm
If an HPD IRQ storm is detected on a connector during driver loading or
system suspend/resume - disabling the IRQ and switching to polling - the
polling may get disabled too early - before the intended 2 minute
HPD_STORM_REENABLE_DELAY - with the HPD IRQ staying disabled for this
duration. One such sequence is:
To avoid the above 2 minute state without either polling or enabled HPD
IRQ, leave the connector's polling mode unchanged in
i915_hpd_poll_init_work() if its HPD IRQ got disabled after an IRQ storm
indicated by the connector's HPD_DISABLED pin state.
Imre Deak [Thu, 4 Jan 2024 08:29:57 +0000 (10:29 +0200)]
drm/i915: Init DRM connector polled field early
After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will
set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets
disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will
enable polling for these connectors, setting the pin state to
HPD_DISABLED, but only if the connector's base.polled field is set to
DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will
reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED.
The connectors will be created with their base.polled field set to 0,
which gets initialized only later in i915_hpd_poll_init_work() (using
intel_connector::polled). If a storm is detected on a connector after
it's created and IRQs are enabled on it - by intel_hpd_init() - and
before its bease.polled field is initialized in the above work, the
connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving
the IRQ disabled indefinitely - and polling will not get enabled on it as
intended.
I can't see a reason for initializing base.polled in a delayed manner,
so do this already when creating the connector, to prevent the above
race condition.
Charlene Liu [Sat, 16 Dec 2023 00:41:57 +0000 (19:41 -0500)]
drm/amd/display: Allow z8/z10 from driver
Copy StutterPeriod from DML2 into DML1 StutterPeriod parameter.
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Reviewed-by: Muhammad Ahmed <ahmed.ahmed@amd.com> Reviewed-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com> Signed-off-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Melissa Wen [Fri, 29 Dec 2023 16:25:00 +0000 (15:25 -0100)]
drm/amd/display: fix bandwidth validation failure on DCN 2.1
IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of
the test execution, during atomic check, because DC rejects the
bandwidth state for a fb sizing 64x64. The test was previously working
with the deprecated dc_commit_state(). Now using
dc_validate_with_context() approach, the atomic check needs to perform a
full state validation. Therefore, set fast_validation to false in the
dc_validate_global_state call for atomic check.
Cc: stable@vger.kernel.org Fixes: b8272241ff9d ("drm/amd/display: Drop dc_commit_state in favor of dc_commit_streams") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Wed, 3 Jan 2024 16:55:53 +0000 (11:55 -0500)]
drm/amdgpu: apply the RV2 system aperture fix to RN/CZN as well
These chips needs the same fix. This was previously not seen
on then since the AGP aperture expanded the system aperture,
but this showed up again when AGP was disabled.
Reviewed-and-tested-by: Jiadong Zhu <Jiadong.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Harry Wentland [Wed, 20 Dec 2023 21:25:48 +0000 (16:25 -0500)]
drm/amd/display: Move fixpt_from_s3132 to amdgpu_dm
Other environments don't like the unary minus operator on
an unsigned value.
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Harry Wentland [Wed, 20 Dec 2023 20:18:05 +0000 (15:18 -0500)]
drm/amd/display: Fix recent checkpatch errors in amdgpu_dm
- Use tabs, not spaces.
- Brace and parentheses placement
Signed-off-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kaibo Ma [Wed, 3 Jan 2024 04:29:56 +0000 (12:29 +0800)]
Revert "drm/amdkfd: Relocate TBA/TMA to opposite side of VM hole"
That commit causes NULL pointer dereferences in dmesgs when
running applications using ROCm, including clinfo, blender,
and PyTorch, since v6.6.1. Revert it to fix blender again.
Arnd Bergmann [Wed, 22 Nov 2023 22:13:36 +0000 (23:13 +0100)]
drm/amd/display: avoid stringop-overflow warnings for dp_decide_lane_settings()
gcc prints a warning about a possible array overflow for a couple of
callers of dp_decide_lane_settings() after commit 1b56c90018f0 ("Makefile:
Enable -Wstringop-overflow globally"):
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c: In function 'dp_perform_fixed_vs_pe_training_sequence_legacy':
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: error: 'dp_decide_lane_settings' accessing 4 bytes in a region of size 1 [-Werror=stringop-overflow=]
426 | dp_decide_lane_settings(lt_settings, dpcd_lane_adjust,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
427 | lt_settings->hw_lane_settings, lt_settings->dpcd_lane_settings);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training_fixed_vs_pe_retimer.c:426:25: note: referencing argument 4 of type 'union dpcd_training_lane[4]'
I'm not entirely sure what caused this, but changing the prototype to expect
a pointer instead of an array avoids the warnings.
Fixes: 7727e7b60f82 ("drm/amd/display: Improve robustness of FIXED_VS link training at DP1 rates") Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Zhipeng Lu [Sun, 24 Dec 2023 08:22:47 +0000 (16:22 +0800)]
drm/amd/pm/smu7: fix a memleak in smu7_hwmgr_backend_init
The hwmgr->backend, (i.e. data) allocated by kzalloc is not freed in
the error-handling paths of smu7_get_evv_voltages and
smu7_update_edc_leakage_table. However, it did be freed in the
error-handling of phm_initializa_dynamic_state_adjustment_rule_settings,
by smu7_hwmgr_backend_fini. So the lack of free in smu7_get_evv_voltages
and smu7_update_edc_leakage_table is considered a memleak in this patch.
Fixes: 599a7e9fe1b6 ("drm/amd/powerplay: implement smu7 hwmgr to manager asics with smu ip version 7.") Fixes: 8f0804c6b7d0 ("drm/amd/pm: add edc leakage controller setting") Signed-off-by: Zhipeng Lu <alexious@zju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Srinivasan Shanmugam [Fri, 29 Dec 2023 09:37:09 +0000 (15:07 +0530)]
drm/amdkfd: Fix iterator used outside loop in 'kfd_add_peer_prop()'
Fix the following about iterator use:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1456 kfd_add_peer_prop() warn: iterator used outside loop: 'iolink3'
Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Srinivasan Shanmugam [Wed, 27 Dec 2023 07:24:44 +0000 (12:54 +0530)]
drm/amdgpu: Drop 'fence' check in 'to_amdgpu_amdkfd_fence()'
Return value of container_of(...) can't be null, so null check is not
required for 'fence'. Hence drop its NULL check.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:93 to_amdgpu_amdkfd_fence() warn: can 'fence' even be NULL?
Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Srinivasan Shanmugam [Thu, 21 Dec 2023 01:46:23 +0000 (07:16 +0530)]
drm/amdkfd: Confirm list is non-empty before utilizing list_first_entry in kfd_topology.c
Before using list_first_entry, make sure to check that list is not
empty, if list is empty return -ENODATA.
Fixes the below:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1347 kfd_create_indirect_link_prop() warn: can 'gpu_link' even be NULL?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1428 kfd_add_peer_prop() warn: can 'iolink1' even be NULL?
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1433 kfd_add_peer_prop() warn: can 'iolink2' even be NULL?
Fixes: 0f28cca87e9a ("drm/amdkfd: Extend KFD device topology to surface peer-to-peer links") Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Suggested-by: Felix Kuehling <Felix.Kuehling@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Felix Kuehling <felix.kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Srinivasan Shanmugam [Wed, 3 Jan 2024 16:52:44 +0000 (22:22 +0530)]
drm/amdgpu: Fix '*fw' from request_firmware() not released in 'amdgpu_ucode_request()'
Fixes the below:
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:1404 amdgpu_ucode_request() warn: '*fw' from request_firmware() not released on lines: 1404.
Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Lijo Lazar <lijo.lazar@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Yang Wang <kevinyang.wang@amd.com> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Srinivasan Shanmugam [Thu, 28 Dec 2023 17:12:04 +0000 (22:42 +0530)]
drm/amdgpu: Remove unreachable code in 'atom_skip_src_int()'
Fixes the below:
drivers/gpu/drm/amd/amdgpu/atom.c:398 atom_skip_src_int() warn: ignoring unreachable code.
Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
José Roberto de Souza [Thu, 4 Jan 2024 16:24:09 +0000 (08:24 -0800)]
drm/i915: Disable DSB in Xe KMD
Often getting DSB overflows when starting Xorg or Wayland compositors
when running Xe KMD.
Issue was reported but nothing was done, so disabling DSB as whole
until properly fixed in Xe KMD.
v2:
- move check to HAS_DSB(Jani)
v3:
- use IS_ENABLED(I915) check in intel_dsb_prepare()
Dave Airlie [Fri, 5 Jan 2024 00:31:29 +0000 (10:31 +1000)]
Merge tag 'drm-misc-next-fixes-2024-01-04' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
One fix for drm/plane to avoid a use-after-free and some additional
warnings to prevent more of these occurences, a lock inversion
dependency fix and an indentation fix for drm/rockchip, and some doc
warning fixes for imagination and gpuvm.
Imre Deak [Wed, 3 Jan 2024 15:26:09 +0000 (17:26 +0200)]
drm/i915/dp: Fix the PSR debugfs entries wrt. MST connectors
MST connectors don't have a static attached encoder, as their encoder
can change depending on the pipe they use; so the encoder for an MST
connector can't be retrieved using intel_dp_attached_encoder() (which
may return NULL for MST). Most of the PSR debugfs entries depend on a
static connector -> encoder mapping which is only true for eDP and SST
DP connectors and not for MST. These debugfs entries were enabled for
MST connectors as well recently to provide PR information for them, but
handling MST connectors needs more changes.
Fix this by not adding for now the PSR entries on MST connectors. To
make things more uniform add the entries for SST connectors on all
platforms, not just on platforms supporting DP2.0.
v2:
- Keep adding the entries for SST connectors. (Jouni)
- Add a TODO: comment for MST support.
Fixes: ef75c25e8fed ("drm/i915/panelreplay: Debugfs support for panel replay") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9850 Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240103152609.2434100-1-imre.deak@intel.com
projects / users / jedix / linux-maple.git / log