amdgpu pr conconflicts due to patches cherry-picked to -fixes, I might
as well catch up with a backmerge and handle them all. Plus both misc
and intel maintainers asked for a backmerge anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We are checking cp_irq_count from the wrong hdcp structure which
ends up giving timed out errors. We only increment the cp_irq_count
of the primary connector's hdcp structure but here in case of
multidisplay setup we end up checking the secondary connector's hdcp
structure, which will not have its cp_irq_count incremented. This leads
to a timed out at CP_IRQ error even though a CP_IRQ was raised. Extract
it from the correct intel_hdcp structure.
--v2
-Explain why it was the wrong hdcp structure [Jani]
Fixes: 8c9e4f68b8 ("drm/i915/hdcp: Use per-device debugs")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240809114127.3940699-2-suraj.kandpal@intel.com
(cherry picked from commit dd92590263)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
drm-xe-next for 6.12
UAPI Changes:
- Rename xe perf layer as xe observation layer, but was
also made available via fixes to previous verison (Ashutosh)
- Use write-back caching mode for system memory on DGFX,
but was also mad available via fixes to previous version (Thomas)
- Expose SIMD16 EU mask in topology query for userspace to know
the type of EU, as available in PVC, Lunar Lake and Battlemage
(Lucas)
- Return ENOBUFS instead of ENOMEM in vm_bind if failure is tied
to an array of binds (Matthew Brost)
Driver Changes:
- Log cleanup moving messages to debug priority (Michal Wajdeczko)
- Add timeout to fences to adhere to dma_buf rules (Matthew Brost)
- Rename old engine nomenclature to exec_queue (Matthew Brost)
- Convert multiple bind ops to 1 job (Matthew Brost)
- Add error injection for vm bind to help testing error path
(Matthew Brost)
- Fix error handling in page table to propagate correctly
to userspace (Matthew Brost)
- Re-organize and cleanup SR-IOV related registers (Michal Wajdeczko)
- Make the device write barrier compatible with VF (Michal Wajdeczko)
- New display workarounds for Battlemage (Matthew Auld)
- New media workarounds for Lunar Lake and Battlemage (Ngai-Mint Kwan)
- New graphics workarounds for Lunar Lake (Bommu Krishnaiah)
- Tracepoint updates (Matthew Brost, Nirmoy Das)
- Cleanup the header generation for OOB workarounds (Lucas De Marchi)
- Fix leaking HDCP-related object (Nirmoy Das)
- Serialize L2 flushes to avoid races (Tejas Upadhyay)
- Log pid and comm on job timeout (José Roberto de Souza)
- Simplify boilerplate code for live kunit (Michal Wajdeczko)
- Improve kunit skips for live kunit (Michal Wajdeczko)
- Fix xe_sync cleanup when handling xe_exec ioctl (Ashutosh Dixit)
- Limit fair VF LMEM provisioning (Michal Wajdeczko)
- New workaround to fence mmio writes in Lunar Lake (Tejas Upadhyay)
- Warn on writes inaccessible register in VF (Michal Wajdeczko)
- Fix register lookup in VF (Michal Wajdeczko)
- Add GSC support for Battlemage (Alexander Usyskin)
- Fix wedging only the GT in which timeout occurred (Matthew Brost)
- Block device suspend when wedging (Matthew Brost)
- Handle compression and migration changes for Battlemage
(Akshata Jahagirdar)
- Limit access of stolen memory for Lunar Lake (Uma Shankar)
- Fail invalid addresses during user fence creation (Matthew Brost)
- Refcount xe_file to safely and accurately store fdinfo stats
(Umesh Nerlige Ramappa)
- Cleanup and fix PM reference for TLB invalidation code
(Matthew Brost)
- Fix PM reference handling when communicating with GuC (Matthew Brost)
- Add new BO flag for 2 MiB alignement and use in VF (Michal Wajdeczko)
- Simplify MMIO setup for multi-tile platforms (Lucas De Marchi)
- Add check for uninitialized access to OOB workarounds
(Lucas De Marchi)
- New GSC and HuC firmware blobs for Lunar Lake and Battlemage
(Daniele Ceraolo Spurio)
- Unify mmio wait logic (Gustavo Sousa)
- Fix off-by-one when processing RTP rules (Lucas De Marchi)
- Future-proof migrate logic with compressed PAT flag (Matt Roper)
- Add WA kunit tests for Battlemage (Lucas De Marchi)
- Test active tracking for workaorunds with kunit (Lucas De Marchi)
- Add kunit tests for RTP with no actions (Lucas De Marchi)
- Unify parse of OR rules in RTP (Lucas De Marchi)
- Add performance tuning for Battlemage (Sai Teja Pottumuttu)
- Make bit masks unsigned (Geert Uytterhoeven)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/k7xuktfav4zmtxxjr77glu2hszypvzgmzghoumh757nqfnk7kn@ccfi4ts3ytbk
As explained in the previous patch, the MST link BW reported by branch
devices during topology probing/path resources enumeration depends on
the link parameters programmed to DPCD to be up-to-date. After a sink is
plugged this is not ensured, as those DPCD values start out zeroed. The
target link parameters (for a subsequent modeset) are the maximum that
is supported, so make sure these maximum values are programmed before the
topology probing.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-14-imre.deak@intel.com
The MST link BW reported by branch devices via the ENUM_PATH_RESOURCES
message depends on the channel coding and link rate/lane count
parameters programmed to DPCD. This is the case at least for some branch
devices, while for others the reported BW is independent of the link
parameters. In any case the DP standard requires the branch device to
adjust the returned value to both account for the different way the BW
for FEC is accounted for (included in the returned value for non-UHBR
and not included for UHBR rates) and to limit the returned value to the
(trained) link BW between the source and first downstream branch
device, see DP v2.0/v2.1 Figure 2-94, DP v2.1 5.9.7. Presumedly this is
also the reason why the standard requires the DPCD link rate/lane count
values being up-to-date before sending the ENUM_PATH_RESOURCES message,
see DP v2.1 2.14.9.4.
Based on the above reprobe the MST topology after the link is retrained
with new link parameters to make sure that the MST link BW tracked in
the MST topology state (via each topology port's full_pbn value) is
up-to-date.
The next patch will make sure that the MST link BW is also kept
up-to-date if the link is disabled.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-13-imre.deak@intel.com
On MST links - at least for some MST branch devices - the list of modes
returned to users on an enabled link depends on the current link
rate/lane count parameters (besides the DPRX link capabilities, any MST
branch BW limit and the maximum link parameters reduced after LT
failures). In particular the MST branch BW limit may depend on the link
rate/lane count parameters programmed to DPCD. After an LT failure and
limiting the maximum link parameters accordingly, users should see a
mode list reflecting these new limits. However with the current fallback
order this isn't ensured, as the new limit could allow for modes
requiring a higher link BW, but these modes will be filtered out due to
the enabled link's lower link BW.
Ensure that the mode list changes in a consistent way after a link
training failure and reducing the link parameters by changing the
fallback order on MST links to happen in BW order.
v2:
- s/INTEL_DP_MAX_SUPPORTED_LANE_COUNTS/INTEL_DP_MAX_SUPPORTED_LANE_CONFIGS
and s/num_common_lane_counts/num_common_lane_configs to make the
difference wrt. max lane counts clearer. (Suraj)
- Add a TODO comment to make the SST fallback logic work the same way as
MST. (Arun)
- Use sort_r()'s default swap function instead of a custom one.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240729144458.2763667-1-imre.deak@intel.com
There are multiple failure cases a modeset-retry uevent can be sent for
a link (TBT tunnel BW allocation failure, unrecoverable link training
failure), a follow-up patch adding the handling for a new case where the
DP MST payload allocation fails. The uevent is the same in all cases,
sent to all the connectors on the link, so in case of multiple failures
there is no point in sending a separate uevent for each failure; prevent
this, sending only a single modeset-retry uevent for a commit.
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-7-imre.deak@intel.com
Initialize the DP link parameters during HW readout. These need to be
up-to-date at least for the MST topology probing, which depends on the
link rate and lane count programmed in DPCD. A follow-up patch will
program the DPCD values to reflect the maximum link parameters before
the first MST topology probing, but should do so only if the link is
disabled (link_trained==false).
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240722165503.2084999-6-imre.deak@intel.com
On the off chance that clock value ends up being too high (by means
of skl_ddi_calculate_wrpll() having been called with big enough
value of crtc_state->port_clock * 1000), one possible consequence
may be that the result will not be able to fit into signed int.
Fix this issue by moving conversion of clock parameter from kHz to Hz
into the body of skl_ddi_calculate_wrpll(), as well as casting the
same parameter to u64 type while calculating the value for AFE clock.
This both mitigates the overflow problem and avoids possible erroneous
integer promotion mishaps.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 82d3543701 ("drm/i915/skl: Implementation of SKL DPLL programming")
Cc: stable@vger.kernel.org
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240729174035.25727-1-n.zhandarovich@fintech.ru
(cherry picked from commit 833cf12846)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
On the off chance that clock value ends up being too high (by means
of skl_ddi_calculate_wrpll() having been called with big enough
value of crtc_state->port_clock * 1000), one possible consequence
may be that the result will not be able to fit into signed int.
Fix this issue by moving conversion of clock parameter from kHz to Hz
into the body of skl_ddi_calculate_wrpll(), as well as casting the
same parameter to u64 type while calculating the value for AFE clock.
This both mitigates the overflow problem and avoids possible erroneous
integer promotion mishaps.
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: 82d3543701 ("drm/i915/skl: Implementation of SKL DPLL programming")
Cc: stable@vger.kernel.org
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240729174035.25727-1-n.zhandarovich@fintech.ru
Clear VSC SDP if intel_dp_set_infoframes is called from post ddi disable
routine i.e with the variable of enable as false. This is to avoid
an infoframes.enable mismatch issue which is caused when pipe is
connected to eDp which has psr then connected to DPMST. In this case
eDp's post ddi disable routine does not clear infoframes.enable VSC
for the given pipe and DPMST does not recompute VSC SDP and write
infoframes.enable which causes a mismatch.
--v2
-Make the comment match the code [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240724163743.3668407-1-suraj.kandpal@intel.com
After a bad link state is detected, the sink capabilities with which the
link was originally trained could have changed: for instance another
sink got connected or the retraining was forced after the rate/lane count
got decreased (as a fallback). In these cases the retraining modeset
fails as expected also printing a debug message, so don't WARN on it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240712135724.660399-3-imre.deak@intel.com
Instead of direct calls of the link training functions, use a modeset
commit to retrain a DP link in SST mode, similarly to how this is done
in DP-MST mode. Originally the current way was chosen presumedly,
because there wasn't a well-established way in place for the driver to
do an internal (vs. userspace/kernel client) commit. Since then such
internal commits became a common place (initial-, HDMI/TC link reset
commit), so there is no reason to handle the DP-SST link-retraining case
differently.
At the end of the current sequence the HW reported a FIFO underrun -
without other issues visible to users - because during retraining the
link's encoder/port was disabled/re-enabled without also
disabling/re-enabling the corresponding pipe/transcoder (as required by
the spec); the corresponding underrun error message was suppressed as a
known issue. Based on Ankit's test on DG2 the underrun error was still
reported as it got detected with some (vblank) delay wrt. other
platforms. Switching to a modeset commit resolves these underrun related
issues.
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240712135724.660399-1-imre.deak@intel.com
