Rob Clark [Tue, 15 Oct 2024 22:13:34 +0000 (15:13 -0700)]
drm/msm/a6xx+: Insert a fence wait before SMMU table update
The CP_SMMU_TABLE_UPDATE _should_ be waiting for idle, but on some
devices (x1-85, possibly others), it seems to pass that barrier while
there are still things in the event completion FIFO waiting to be
written back to memory.
Work around that by adding a fence wait before context switch. The
CP_EVENT_WRITE that writes the fence is the last write from a submit,
so seeing this value hit memory is a reliable indication that it is
safe to proceed with the context switch.
v2: Only emit CP_WAIT_TIMESTAMP on a7xx, as it is not supported on a6xx.
Conversely, I've not been able to reproduce this issue on a6xx, so
hopefully it is limited to a7xx, or perhaps just certain a7xx
devices.
Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/63 Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Jessica Zhang [Thu, 10 Oct 2024 03:41:13 +0000 (20:41 -0700)]
drm/msm/dpu: Don't always set merge_3d pending flush
Don't set the merge_3d pending flush bits if the mode_3d is
BLEND_3D_NONE.
Always flushing merge_3d can cause timeout issues when there are
multiple commits with concurrent writeback enabled.
This is because the video phys enc waits for the hw_ctl flush register
to be completely cleared [1] in its wait_for_commit_done(), but the WB
encoder always sets the merge_3d pending flush during each commit
regardless of if the merge_3d is actually active.
This means that the hw_ctl flush register will never be 0 when there are
multiple CWB commits and the video phys enc will hit vblank timeout
errors after the first CWB commit.
[1] commit fe9df3f50c39 ("drm/msm/dpu: add real wait_for_commit_done()")
Fixes: 3e79527a33a8 ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250") Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Signed-off-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/619092/ Link: https://lore.kernel.org/r/20241009-mode3d-fix-v1-1-c0258354fadc@quicinc.com Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Douglas Anderson [Mon, 14 Oct 2024 16:36:09 +0000 (09:36 -0700)]
drm/msm: Allocate memory for disp snapshot with kvzalloc()
With the "drm/msm: add a display mmu fault handler" series [1] we saw
issues in the field where memory allocation was failing when
allocating space for registers in msm_disp_state_dump_regs().
Specifically we were seeing an order 5 allocation fail. It's not
surprising that order 5 allocations will sometimes fail after the
system has been up and running for a while.
There's no need here for contiguous memory. Change the allocation to
kvzalloc() which should make it much less likely to fail.
Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/619658/ Link: https://lore.kernel.org/r/20241014093605.2.I72441365ffe91f3dceb17db0a8ec976af8139590@changeid Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Douglas Anderson [Mon, 14 Oct 2024 16:36:08 +0000 (09:36 -0700)]
drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()
If the allocation in msm_disp_state_dump_regs() failed then
`block->state` can be NULL. The msm_disp_state_print_regs() function
_does_ have code to try to handle it with:
if (*reg)
dump_addr = *reg;
...but since "dump_addr" is initialized to NULL the above is actually
a noop. The code then goes on to dereference `dump_addr`.
Make the function print "Registers not stored" when it sees a NULL to
solve this. Since we're touching the code, fix
msm_disp_state_print_regs() not to pointlessly take a double-pointer
and properly mark the pointer as `const`.
Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/619657/ Link: https://lore.kernel.org/r/20241014093605.1.Ia1217cecec9ef09eb3c6d125360cc6c8574b0e73@changeid Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Jonathan Marek [Mon, 7 Oct 2024 05:01:49 +0000 (01:01 -0400)]
drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation
When (mode->clock * 1000) is larger than (1<<31), int to unsigned long
conversion will sign extend the int to 64 bits and the pclk_rate value
will be incorrect.
Fix this by making the result of the multiplication unsigned.
Note that above (1<<32) would still be broken and require more changes, but
its unlikely anyone will need that anytime soon.
Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/618434/ Link: https://lore.kernel.org/r/20241007050157.26855-2-jonathan@marek.ca Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check
Historically CRTC resources (LMs and CTLs) were assigned in
dpu_crtc_atomic_begin(). The commit 9222cdd27e82 ("drm/msm/dpu: move hw
resource tracking to crtc state") simply moved resources to
struct dpu_crtc_state, without changing the code sequence. Later on the
commit b107603b4ad0 ("drm/msm/dpu: map mixer/ctl hw blocks in encoder
modeset") rearanged the code, but still kept the cstate->num_mixers
assignment to happen during commit phase. This makes dpu_crtc_state
inconsistent between consequent atomic_check() calls.
Move CRTC resource assignment to happen at the end of
dpu_encoder_virt_atomic_check().
drm/msm/dpu: make sure phys resources are properly initialized
The commit b954fa6baaca ("drm/msm/dpu: Refactor rm iterator") removed
zero-init of the hw_ctl array, but didn't change the error condition,
that checked for hw_ctl[i] being NULL. At the same time because of the
early returns in case of an error dpu_encoder_phys might be left with
the resources assigned in the previous state. Rework assigning of hw_pp
/ hw_ctl to the dpu_encoder_phys in order to make sure they are always
set correctly.
Dmitry Baryshkov [Sun, 4 Aug 2024 05:40:07 +0000 (08:40 +0300)]
drm/msm/dsi: correct programming sequence for SM8350 / SM8450
According to the display-drivers, 5nm DSI PLL (v4.2, v4.3) have
different boundaries for pll_clock_inverters programming. Follow the
vendor code and use correct values.
Fixes: 2f9ae4e395ed ("drm/msm/dsi: add support for DSI-PHY on SM8350 and SM8450") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/606947/ Link: https://lore.kernel.org/r/20240804-sm8350-fixes-v1-3-1149dd8399fe@linaro.org
Add support for the HDMI PHY as present on the Qualcomm MSM8998 SoC.
This code is mostly copy & paste of the vendor code from msm-4.4
kernel.lnx.4.4.r38-rel.
Signed-off-by: Arnaud Vrac <avrac@freebox.fr> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Patchwork: https://patchwork.freedesktop.org/patch/605631/ Link: https://lore.kernel.org/r/20240724-hdmi-tx-v7-4-e44a20553464@freebox.fr
[DB: replaced division with do_div64 to fix build issues on ARM32] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Dmitry Baryshkov [Sat, 31 Aug 2024 10:10:44 +0000 (13:10 +0300)]
drm/msm/dpu: Configure DP INTF/PHY selector
Some platforms provides a mechanism for configuring the mapping between
(one or two) DisplayPort intfs and their PHYs.
In particular SC8180X requires this to be configured, since on this
platform there are fewer controllers than PHYs.
The change implements the logic for optionally configuring which PHY
each of the DP INTFs should be connected to and marks the SC8180X DPU to
program 2 entries.
For now the request is simply to program the mapping 1:1, any support
for alternative mappings is left until the use case arrise.
Note that e.g. msm-4.14 unconditionally maps INTF 0 to PHY 0 on all
platforms, so perhaps this is needed in order to get DisplayPort working
on some other platforms as well.
Otto Pflüger [Mon, 22 Jul 2024 14:58:19 +0000 (16:58 +0200)]
drm/msm/adreno: Add A306A support
Add support for Adreno 306A GPU what is found in MSM8917 SoC.
This GPU marketing name is Adreno 308.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
[use internal name of the GPU, reword the commit message] Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Barnabás Czémán <trabarni@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/605403/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Wed, 28 Aug 2024 15:06:59 +0000 (17:06 +0200)]
drm/msm/a6xx: Add A621 support
A621 is a clear A662 derivative (same lineage as A650), no explosions
or sick features, other than a NoC bug which can stall the GPU..
Add support for it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/611100/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Wed, 28 Aug 2024 15:06:58 +0000 (17:06 +0200)]
drm/msm/a6xx: Set GMU CGC properties on a6xx too
This was apparently never done before.. Program the expected values.
This also gets rid of sneakily setting that register through the HWCG
reg list on A690.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/611098/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Wed, 28 Aug 2024 15:06:57 +0000 (17:06 +0200)]
drm/msm/a6xx: Use the per-GPU value for gmu_cgc_mode
This register's magic value differs wildly between different GPUs, use
the hardcoded data instead of trying to make some logic out of it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/611096/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Wed, 28 Aug 2024 15:06:56 +0000 (17:06 +0200)]
drm/msm/a6xx: Store correct gmu_cgc_mode in struct a6xx_info
Store the correct values that we happen to have for some A7xx SKUs in
the GPU info struct and fill out the missing information for A6xx GPUs
based on downstream kernel information.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/611094/
[add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Wed, 28 Aug 2024 15:06:55 +0000 (17:06 +0200)]
drm/msm/a6xx: Store primFifoThreshold in struct a6xx_info
The if-else monster is so unmaintainable that one case is repeated
twice. Get rid of it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/611092/
[add missing entry to a615 catalog to resolve conflict] Signed-off-by: Rob Clark <robdclark@chromium.org>
Konrad Dybcio [Fri, 19 Jul 2024 10:03:26 +0000 (12:03 +0200)]
drm/msm/a6xx: Evaluate adreno_is_a650_family in pdc_in_aop check
A650 family includes A660 family (they've got a big family), A650
itself, and some more A6XX_GEN3 SKUs, all of which should fall into
the same branch of the if-condition. Simplify that.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/605206/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Vladimir Lypak [Sun, 1 Sep 2024 13:54:03 +0000 (13:54 +0000)]
drm/msm/a5xx: workaround early ring-buffer emptiness check
There is another cause for soft lock-up of GPU in empty ring-buffer:
race between GPU executing last commands and CPU checking ring for
emptiness. On GPU side IRQ for retire is triggered by CACHE_FLUSH_TS
event and RPTR shadow (which is used to check ring emptiness) is updated
a bit later from CP_CONTEXT_SWITCH_YIELD. Thus if GPU is executing its
last commands slow enough or we check that ring too fast we will miss a
chance to trigger switch to lower priority ring because current ring isn't
empty just yet. This can escalate to lock-up situation described in
previous patch.
To work-around this issue we keep track of last submit sequence number
for each ring and compare it with one written to memptrs from GPU during
execution of CACHE_FLUSH_TS event.
Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/612047/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Vladimir Lypak [Sun, 1 Sep 2024 13:54:02 +0000 (13:54 +0000)]
drm/msm/a5xx: fix races in preemption evaluation stage
On A5XX GPUs when preemption is used it's invietable to enter a soft
lock-up state in which GPU is stuck at empty ring-buffer doing nothing.
This appears as full UI lockup and not detected as GPU hang (because
it's not). This happens due to not triggering preemption when it was
needed. Sometimes this state can be recovered by some new submit but
generally it won't happen because applications are waiting for old
submits to retire.
One of the reasons why this happens is a race between a5xx_submit and
a5xx_preempt_trigger called from IRQ during submit retire. Former thread
updates ring->cur of previously empty and not current ring right after
latter checks it for emptiness. Then both threads can just exit because
for first one preempt_state wasn't NONE yet and for second one all rings
appeared to be empty.
To prevent such situations from happening we need to establish guarantee
for preempt_trigger to make decision after each submit or retire. To
implement this we serialize preemption initiation using spinlock. If
switch is already in progress we need to re-trigger preemption when it
finishes.
Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/612045/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Vladimir Lypak [Sun, 1 Sep 2024 13:54:01 +0000 (13:54 +0000)]
drm/msm/a5xx: properly clear preemption records on resume
Two fields of preempt_record which are used by CP aren't reset on
resume: "data" and "info". This is the reason behind faults which happen
when we try to switch to the ring that was active last before suspend.
In addition those faults can't be recovered from because we use suspend
and resume to do so (keeping values of those fields again).
Fixes: b1fc2839d2f9 ("drm/msm: Implement preemption for A5XX targets") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/612043/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Vladimir Lypak [Sun, 1 Sep 2024 13:54:00 +0000 (13:54 +0000)]
drm/msm/a5xx: disable preemption in submits by default
Fine grain preemption (switching from/to points within submits)
requires extra handling in command stream of those submits, especially
when rendering with tiling (using GMEM). However this handling is
missing at this point in mesa (and always was). For this reason we get
random GPU faults and hangs if more than one priority level is used
because local preemption is enabled prior to executing command stream
from submit.
With that said it was ahead of time to enable local preemption by
default considering the fact that even on downstream kernel it is only
enabled if requested via UAPI.
Fixes: a7a4c19c36de ("drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register") Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/612041/ Signed-off-by: Rob Clark <robdclark@chromium.org>
is called on gpu->pdev == NULL, as the GPU device has not been fully
initialized yet.
Turns out that there's more than just the aforementioned path that
causes this to happen (e.g. the case when there's speedbin data in the
catalog, but opp-supported-hw is missing in DT).
Assigning msm_gpu->pdev earlier seems like the least painful solution
to this, therefore do so.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/602742/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Aleksandr Mishin [Fri, 5 Jul 2024 09:13:12 +0000 (12:13 +0300)]
drm/msm: Fix incorrect file name output in adreno_request_fw()
In adreno_request_fw() when debugging information is printed to the log
after firmware load, an incorrect filename is printed. 'newname' is used
instead of 'fwname', so prefix "qcom/" is being added to filename.
Looks like "copy-paste" mistake.
Fix this mistake by replacing 'newname' with 'fwname'.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 2c41ef1b6f7d ("drm/msm/adreno: deal with linux-firmware fw paths") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/602382/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 13:04:59 +0000 (14:04 +0100)]
drm/msm: Fix UBWC macrotile_mode for a680
Make it match the MDSS settings for sc8180x and downstream.
Note that without the previous commit that exposes the value of
macrotile_mode to mesa, this will break mesa which expects the legacy
default value of 0. Therefore we do *not* want to backport it.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607398/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 13:04:58 +0000 (14:04 +0100)]
drm/msm: Expose expanded UBWC config uapi
This adds extra parameters that affect UBWC tiling that will be used by
the Mesa implementation of VK_EXT_host_image_copy.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607401/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 13:04:57 +0000 (14:04 +0100)]
drm/msm: Expand UBWC config setting
According to downstream we should be setting RBBM_NC_MODE_CNTL to a
non-default value on a663 and a680, we don't support a663 and on a680
we're leaving it at the wrong (suboptimal) value. Just set it on all
GPUs. Similarly, plumb through level2_swizzling_dis which will be
necessary on a663.
ubwc_mode is expanded and renamed to ubwc_swizzle to match the name on
the display side. Similarly macrotile_mode should match the display
side.
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607397/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 13:04:56 +0000 (14:04 +0100)]
drm/msm: Update a6xx register XML
Update to Mesa commit 36a13d2b3b0 ("freedreno: fix a7xx perfcntr
countables").
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607395/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 12:34:29 +0000 (13:34 +0100)]
drm/msm: Fix CP_BV_DRAW_STATE_ADDR name
This was missed because we weren't using the a750-specific indexed regs.
Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <cwabbott0@gmail.com> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/607394/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 12:34:28 +0000 (13:34 +0100)]
drm/msm: Dump correct dbgahb clusters on a750
This was missed thanks to the family mixup fixed in the previous commit.
Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607393/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Connor Abbott [Wed, 7 Aug 2024 12:34:27 +0000 (13:34 +0100)]
drm/msm: Use a7xx family directly in gpu_state
With a7xx, we need to import a new header for each new generation and
switch to a different list of registers, instead of making
backwards-compatible changes. Using the helpers inadvertently made a750
use the a740 list of registers, instead use the family directly to fix
this.
Fixes: f3f8207d8aed ("drm/msm: Add devcoredump support for a750") Signed-off-by: Connor Abbott <cwabbott0@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607392/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Richard Acayan [Tue, 6 Aug 2024 21:44:56 +0000 (17:44 -0400)]
drm/msm/adreno: add a615 support
The Adreno A615 is used in SDM670. Add an entry to support it.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Patchwork: https://patchwork.freedesktop.org/patch/607238/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Fri, 9 Aug 2024 18:37:52 +0000 (11:37 -0700)]
drm/msm: Remove unused pm_state
This was added in commit ec446d09366c ("drm/msm: call
drm_atomic_helper_suspend() and drm_atomic_helper_resume()"), but unused
since commit ca8199f13498 ("drm/msm/dpu: ensure device suspend happens
during PM sleep") which switched to drm_mode_config_helper_suspend()/
drm_mode_config_helper_resume()..
Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/607746/
Li Zetao [Wed, 21 Aug 2024 01:21:34 +0000 (09:21 +0800)]
drm/msm/adreno: Use kvmemdup to simplify the code
Use kvmemdup instead of kvmalloc() + memcpy() to simplify the code.
No functional change intended.
Signed-off-by: Li Zetao <lizetao1@huawei.com> Reviewed-by: Akhil P Oommen <quic_akhilpo@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/609596/ Signed-off-by: Rob Clark <robdclark@chromium.org>
Dave Airlie [Fri, 30 Aug 2024 03:41:26 +0000 (13:41 +1000)]
Merge tag 'drm-intel-next-2024-08-29' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Cross-driver (xe-core) Changes:
- Require BMG scanout buffers to be 64k physically aligned (Maarten)
Core (drm) Changes:
- Introducing Xe2 ccs modifiers for integrated and discrete graphics (Juha-Pekka)
Driver Changes:
- General cleanup and more work moving towards intel_display isolation (Jani)
- New display workaround (Suraj)
- Use correct cp_irq_count on HDCP (Suraj)
- eDP PSR fix when CRC is enabled (Jouni)
- Fix DP MST state after a sink reset (Imre)
- Fix Arrow Lake GSC firmware version (John)
- Use chained DSBs for LUT programming (Ville)
Dave Airlie [Fri, 30 Aug 2024 03:41:05 +0000 (13:41 +1000)]
Merge tag 'drm-xe-next-2024-08-28' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
UAPI Changes:
- Fix OA format masks which were breaking build with gcc-5
Cross-subsystem Changes:
Driver Changes:
- Use dma_fence_chain_free in chain fence unused as a sync (Matthew Brost)
- Refactor hw engine lookup and mmio access to be used in more places
(Dominik, Matt Auld, Mika Kuoppala)
- Enable priority mem read for Xe2 and later (Pallavi Mishra)
- Fix PL1 disable flow in xe_hwmon_power_max_write (Karthik)
- Fix refcount and speedup devcoredump (Matthew Brost)
- Add performance tuning changes to Xe2 (Akshata, Shekhar)
- Fix OA sysfs entry (Ashutosh)
- Add first GuC firmware support for BMG (Julia)
- Bump minimum GuC firmware for platforms under force_probe to match LNL
and BMG (Julia)
- Fix access check on user fence creation (Nirmoy)
- Add/document workarounds for Xe2 (Julia, Daniele, John, Tejas)
- Document workaround and use proper WA infra (Matt Roper)
- Fix VF configuration on media GT (Michal Wajdeczko)
- Fix VM dma-resv lock (Matthew Brost)
- Allow suspend/resume exec queue backend op to be called multiple times
(Matthew Brost)
- Add GT stats to debugfs (Nirmoy)
- Add hwconfig to debugfs (Matt Roper)
- Compile out all debugfs code with ONFIG_DEUBG_FS=n (Lucas)
- Remove dead kunit code (Jani Nikula)
- Refactor drvdata storing to help display (Jani Nikula)
- Cleanup unsused xe parameter in pte handling (Himal)
- Rename s/enable_display/probe_display/ for clarity (Lucas)
- Fix missing MCR annotation in couple of registers (Tejas)
- Fix DGFX display suspend/resume (Maarten)
- Prepare exec_queue_kill for PXP handling (Daniele)
- Fix devm/drmm issues (Daniele, Matthew Brost)
- Fix tile and ggtt fini sequences (Matthew Brost)
- Fix crashes when probing without firmware in place (Daniele, Matthew Brost)
- Use xe_managed for kernel BOs (Daniele, Matthew Brost)
- Future-proof dss_per_group calculation by using hwconfig (Matt Roper)
- Use reserved copy engine for user binds on faulting devices
(Matthew Brost)
- Allow mixing dma-fence jobs and long-running faulting jobs (Francois)
- Cleanup redundant arg when creating use BO (Nirmoy)
- Prevent UAF around preempt fence (Auld)
- Fix display suspend/resume (Maarten)
- Use vma_pages() helper (Thorsten)
- Calculate pagefault queue size (Stuart, Matthew Auld)
- Fix missing pagefault wq destroy (Stuart)
- Fix lifetime handling of HW fence ctx (Matthew Brost)
- Fix order destroy order for jobs (Matthew Brost)
- Fix TLB invalidation for media GT (Matthew Brost)
- Document GGTT (Rodrigo Vivi)
- Refactor GGTT layering and fix runtime outer protection (Rodrigo Vivi)
- Handle HPD polling on display pm runtime suspend/resume (Imre, Vinod)
- Drop unrequired NULL checks (Apoorva, Himal)
- Use separate rpm lockdep map for non-d3cold-capable devices (Thomas Hellström)
- Support "nomodeset" kernel command-line option (Thomas Zimmermann)
- Drop force_probe requirement for LNL and BMG (Lucas, Balasubramani)
host1x:
- fix syncpoint IRQ during resume
- use iommu_paging_domain_alloc()
imx:
- ipuv3: convert to struct drm_edid
omapdrm:
- improve error handling
panel:
- add support for BOE TV101WUM-LL2 plus DT bindings
- novatek-nt35950: improve error handling
- nv3051d: improve error handling
- panel-edp: add support for BOE NE140WUM-N6G; revert support for
SDC ATNA45AF01
- visionox-vtdr6130: improve error handling; use
devm_regulator_bulk_get_const()
renesas:
- rz-du: add support for RZ/G2UL plus DT bindings
Ville Syrjälä [Mon, 24 Jun 2024 19:10:32 +0000 (22:10 +0300)]
drm/i915/dsb: Use chained DSBs for LUT programming
In order to better handle the necessary DSB DEwake tricks let's
switch over to using a chained DSB for the actual LUT programming.
The CPU will start 'dsb_color_commit', which in turn will start the
chained 'dsb_color_vblank'.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:31 +0000 (22:10 +0300)]
drm/i915/dsb: s/dsb/dsb_color_vblank/
We'll soon utilize several DSBs during the commit. To that end
rename the current crtc_state->dsb to crtc_state->dsb_color_vblank
to better reflect its role (color managemnent stuff programmed during
vblank).
Ville Syrjälä [Mon, 24 Jun 2024 19:10:30 +0000 (22:10 +0300)]
drm/i915/dsb: Clear DSB_ENABLE_DEWAKE once the DSB is done
In order to avoid the DSB keeping the DEwake permanently
asserted we must clear DSB_PMCTRL_2.DSB_FORCE_DEWAKE once
we are done. For good measure do the same for
DSB_PMCTRL.DSB_ENABLE_DEWAKE.
Experimentally this doens't seem to be actually necessary
(unlike with DSB_FORCE_DEWAKE). That is, the DSB_ENABLE_DEWAKE
doesn't seem to do anything whenever the DSB is not active.
But I'd hate to waste a ton of power in case there I'm wrong
and there is some way DEwake could remaing asserted. One extra
register write is a small price to pay for some peace of mind.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:29 +0000 (22:10 +0300)]
drm/i915/dsb: Allow intel_dsb_chain() to use DSB_WAIT_FOR_VBLANK
Allow intel_dsb_chain() to start the chained DSB
at start of the undelaye vblank. This is slightly
more involved than simply setting the bit as we
must use the DEwake mechanism to eliminate pkgC
latency.
And DSB_ENABLE_DEWAKE itself is problematic in that
it allows us to configure just a single scanline,
and if the current scanline is already past that
DSB_ENABLE_DEWAKE won't do anything, rendering the
whole thing moot.
The current workaround involves checking the pipe's current
scanline with the CPU, and if it looks like we're about to
miss the configured DEwake scanline we set DSB_FORCE_DEWAKE
to immediately assert DEwake. This is somewhat racy since the
hardware is making progress all the while we're checking it on
the CPU.
We can make things less racy by chaining two DSBs and handling
the DSB_FORCE_DEWAKE stuff entirely without CPU involvement:
1. CPU starts the first DSB immediately
2. First DSB configures the second DSB, including its dewake_scanline
3. First DSB starts the second w/ DSB_WAIT_FOR_VBLANK
4. First DSB asserts DSB_FORCE_DEWAKE
5. First DSB waits until we're outside the dewake_scanline-vblank_start
window
6. First DSB deasserts DSB_FORCE_DEWAKE
That will guarantee that the we are fully awake when the second
DSB starts to actually execute.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:28 +0000 (22:10 +0300)]
drm/i915/dsb: Introduce intel_dsb_chain()
In order to handle the DEwake tricks without involving
the CPU we need a mechanism by which one DSB can start
another one. Add a basic function to do so. We'll extend
it later with additional code to actually deal with
DEwake.
Add functions to emit a DSB scanline window wait instructions.
We can either wait for the scanline to be IN the window
or OUT of the window.
The hardware doesn't handle wraparound so we must manually
deal with it by swapping the IN range to the inverse OUT
range, or vice versa.
Also add a bit of paranoia to catch the edge case of waiting
for the entire frame. That doesn't make sense since an IN
wait would be a nop, and an OUT wait would imply waiting
forever. Most of the time this also results in both scanline
ranges (original and inverted) to have lower=upper+1
which is nonsense from the hw POV.
For now we are only handling the case where the scanline wait
happens prior to latching the double buffered registers during
the commit (which might change the timings due to LRR/VRR/etc.)
Ville Syrjälä [Mon, 24 Jun 2024 19:10:26 +0000 (22:10 +0300)]
drm/i915/dsb: Precompute DSB_CHICKEN
Adjust the code that determines the correct DSB_CHICKEN value
to be usable for use within DSB commands themselves. Ie.
precompute it based on our knowledge of what the hardware state
(VRR vs. not mainly) will be at the time of the commit.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:25 +0000 (22:10 +0300)]
drm/i915/dsb: Account for VRR properly in DSB scanline stuff
When determining various scanlines for DSB use we should take into
account whether VRR is active at the time when the DSB uses said
scanline information. For now all DSB scanline usage occurs prior
to the actual commit, so we only need to care about the state of
VRR at that time.
I've decided to move intel_crtc_scanline_to_hw() in its entirety
to the DSB code as it will also need to know the actual state
of VRR in order to do its job 100% correctly.
TODO: figure out how much of this could be moved to some
more generic place and perhaps be shared with the CPU
vblank evasion code/etc...
Ville Syrjälä [Mon, 24 Jun 2024 19:10:24 +0000 (22:10 +0300)]
drm/i915/dsb: Fix dewake scanline
Currently we calculate the DEwake scanline based on
the delayed vblank start, while in reality it should be computed
based on the undelayed vblank start (as that is where the DSB
actually starts). Currently it doesn't really matter as we
don't have any vblank delay configured, but that may change
in the future so let's be accurate in what we do.
We can also remove the max() as intel_crtc_scanline_to_hw()
can deal with negative numbers, which there really shouldn't
be anyway.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:23 +0000 (22:10 +0300)]
drm/i915/dsb: Shuffle code around
Relocate intel_dsb_dewake_scanline() and dsb_chicken() upwards
in the file. I need to reuse these while emitting DSB
commands, and I'd like to keep the DSB command emission
stuff more or less grouped together in the file.
Also drop the intel_ prefix from intel_dsb_dewake_scanline() since
it's all internal stuff and thus doesn't need so much namespacing.
Ville Syrjälä [Mon, 24 Jun 2024 19:10:22 +0000 (22:10 +0300)]
drm/i915/dsb: Convert dewake_scanline to a hw scanline number earlier
Currently we switch from out software idea of a scanline
to the hw's idea of a scanline during the commit phase in
_intel_dsb_commit(). While that is slightly easier due to
fastsets fiddling with the timings, we'll also need to
generate proper hw scanline numbers already when emitting
DSB scanline wait instructions. So this approach won't
do in the future. Switch to hw scanline numbers earlier.
Also intel_dsb_dewake_scanline() itself already makes
some assumptions about VRR that don't take into account
VRR toggling during fastsets, so technically delaying
the sw->hw conversion doesn't even help us.
The other reason for delaying the conversion was that we
are using intel_get_crtc_scanline() during intel_dsb_commit()
which gives us the current sw scanline. But this is pretty
low level stuff anyway so just using raw PIPEDSL reads seems
fine here, and that of course gives us the hw scanline
directly, reducing the need to do so many conversions.
v2: Return the non-hw scanline from intel_dsb_dewake_scanline()
Ville Syrjälä [Wed, 10 Jul 2024 12:41:37 +0000 (15:41 +0300)]
drm/i915: Fix readout degamma_lut mismatch on ilk/snb
On ilk/snb the pipe may be configured to place the LUT before or
after the CSC depending on various factors, but as there is only
one LUT (no split mode like on IVB+) we only advertise a gamma_lut
and no degamma_lut in the uapi to avoid confusing userspace.
This can cause a problem during readout if the VBIOS/GOP enabled
the LUT in the pre CSC configuration. The current code blindly
assigns the results of the readout to the degamma_lut, which will
cause a failure during the next atomic_check() as we aren't expecting
anything to be in degamma_lut since it's not visible to userspace.
Fix the problem by assigning whatever LUT we read out from the
hardware into gamma_lut.
Cc: stable@vger.kernel.org Fixes: d2559299d339 ("drm/i915: Make ilk_read_luts() capable of degamma readout") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11608 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240710124137.16773-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Neil Armstrong [Wed, 28 Aug 2024 16:03:39 +0000 (18:03 +0200)]
drm/panel: visionox-vtdr6130: switch to mipi_dsi wrapped functions
Make usage of the new _multi() mipi_dsi functions instead of the
deprecated macros, improving error handling and printing.
bloat-o-meter gives a 12% gain on arm64:
Function old new delta
visionox_vtdr6130_unprepare 208 204 -4
visionox_vtdr6130_prepare 1192 896 -296
Total: Before=2348, After=2048, chg -12.78%
Balasubramani Vivekanandan [Wed, 28 Aug 2024 08:21:52 +0000 (13:51 +0530)]
drm/xe/bmg: Drop force_probe requirement
Battlemage platform is sufficiently tested and found stable. CI is also
pretty stable. Remove the force_probe requirement to enable the platform
support by default.
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240828082152.3194814-1-balasubramani.vivekanandan@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Make sure that ggtt_node_remove() is invoked only if both node and ggtt
are not null. Move the null checks to the caller function
xe_ggtt_node_remove().
drm/tegra: hub: Use fn parameter directly to fix Coccinelle warning
The function parameter out can be used directly instead of assigning it
to a temporary u64 variable first.
Remove the local variable tmp2 and use the parameter out directly as the
divisor in do_div() to remove the following Coccinelle/coccicheck
warning reported by do_div.cocci:
WARNING: do_div() does a 64-by-32 division, please consider using div64_u64 instead
drm/tegra: gr3d: Convert into dev_pm_domain_attach|detach_list()
Rather than hooking up the PM domains through devm_pm_opp_attach_genpd()
and manage the device-link, let's avoid the boilerplate-code by converting
into dev_pm_domain_attach|detach_list.
Mikko Perttunen [Fri, 31 May 2024 07:07:18 +0000 (10:07 +0300)]
gpu: host1x: Request syncpoint IRQs only during probe
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended and resumed.
Rearrange interrupt code to only request IRQs during initialization.
Melissa Wen [Sat, 25 May 2024 14:26:28 +0000 (16:26 +0200)]
MAINTAINERS: remove myself as a VKMS maintainer
I haven't been able to follow or review the work on the driver for some
time now and I don't see the situation improving anytime soon. I'd like
to continue being listed as a reviewer.
Thomas Hellström [Mon, 26 Aug 2024 14:34:50 +0000 (16:34 +0200)]
drm/xe: Use separate rpm lockdep map for non-d3cold-capable devices
For non-d3cold-capable devices we'd like to be able to wake up the
device from reclaim. In particular, for Lunar Lake we'd like to be
able to blit CCS metadata to system at shrink time; at least from
kswapd where it's reasonable OK to wait for rpm resume and a
preceding rpm suspend.
Therefore use a separate lockdep map for such devices and prime it
reclaim-tainted.
v2:
- Rename lockmap acquire- and release functions. (Rodrigo Vivi).
- Reinstate the old xe_pm_runtime_lockdep_prime() function and
rename it to xe_rpm_might_enter_cb(). (Matthew Auld).
- Introduce a separate xe_pm_runtime_lockdep_prime function
called from module init for known required locking orders.
v3:
- Actually hook up the prime function at module init.
v4:
- Rebase.
v5:
- Don't use reclaim-safe RPM with sriov.
Cc: Christian König <christian.koenig@amd.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240828083635.23601-2-nirmoy.das@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Nirmoy Das [Wed, 28 Aug 2024 08:36:34 +0000 (10:36 +0200)]
Revert "drm/xe/lnl: Offload system clear page activity to GPU"
This optimization relied on having to clear CCS on allocations.
If there is no need to clear CCS on allocations then this would mostly
help in reducing CPU utilization.
Revert this patch at this moment because of:
1 Currently Xe can't do clear on free and using a invalid ttm flag,
TTM_TT_FLAG_CLEARED_ON_FREE which could poison global ttm pool on
multi-device setup.
2 Also for LNL CPU:WB doesn't require clearing CCS as such BO will
not be allowed to bind with compression PTE. Subsequent patch will
disable clearing CCS for CPU:WB BOs for LNL.
Cc: Christian König <christian.koenig@amd.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240828083635.23601-1-nirmoy.das@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Maarten Lankhorst [Mon, 26 Aug 2024 17:01:16 +0000 (19:01 +0200)]
drm/xe: Align all VRAM scanout buffers to 64k physical pages when needed.
For CCS formats on affected platforms, CCS can be used freely, but
display engine requires a multiple of 64k physical pages. No other
changes are needed.
At the BO creation time we don't know if the BO will be used for CCS
or not. If the scanout flag is set, and the BO is a multiple of 64k,
we take the safe route and force the physical alignment of 64k pages.
If the BO is not a multiple of 64k, or the scanout flag was not set
at BO creation, we reject it for usage as CCS in display. The physical
pages are likely not aligned correctly, and this will cause corruption
when used as FB.
The scanout flag and size being a multiple of 64k are used together
to enforce 64k physical placement.
VM_BIND is completely unaffected, mappings to a VM can still be aligned
to 4k, just like for normal buffers.
Maarten Lankhorst [Mon, 26 Aug 2024 17:01:15 +0000 (19:01 +0200)]
drm/i915/display: Plane capability for 64k phys alignment
Some plane formats have been designed to require 64k physical alignment.
By returning whether this is the case for certain formats, we do not
need to hardcode this check inside Xe.
Thomas Zimmermann [Tue, 27 Aug 2024 12:09:05 +0000 (14:09 +0200)]
drm/xe: Support 'nomodeset' kernel command-line option
Setting 'nomodeset' on the kernel command line disables all graphics
drivers with modesetting capabilities, leaving only firmware drivers,
such as simpledrm or efifb.
Most DRM drivers automatically support 'nomodeset' via DRM's module
helper macros. In xe, which uses regular module_init(), manually call
drm_firmware_drivers_only() to test for 'nomodeset'. Do not register
the driver if set.
v2:
- use xe's init table (Lucas)
- do NULL test for init/exit functions
The panel should be handled through the samsung-atna33xc20 driver for
correct power up timings. Otherwise the backlight does not work correctly.
We have existing users of this panel through the generic "edp-panel"
compatible (e.g. the Qualcomm X1E80100 CRD), but the screen works only
partially in that configuration: It works after boot but once the screen
gets disabled it does not turn on again until after reboot. It behaves the
same way with the default "conservative" timings, so we might as well drop
the configuration from the panel-edp driver. That way, users with old DTBs
will get a warning and can move to the new driver.
Daniel Vetter [Tue, 27 Aug 2024 12:33:12 +0000 (14:33 +0200)]
Merge tag 'amd-drm-next-6.12-2024-08-26' of https://gitlab.freedesktop.org/agd5f/linux into drm-next
amd-drm-next-6.12-2024-08-26:
amdgpu:
- SDMA devcoredump support
- DCN 4.0.1 updates
- DC SUBVP fixes
- Refactor OPP in DC
- Refactor MMHUBBUB in DC
- DC DML 2.1 updates
- DC FAMS2 updates
- RAS updates
- GFX12 updates
- VCN 4.0.3 updates
- JPEG 4.0.3 updates
- Enable wave kill (soft recovery) for compute queues
- Clean up CP error interrupt handling
- Enable CP bad opcode interrupts
- VCN 4.x fixes
- VCN 5.x fixes
- GPU reset fixes
- Fix vbios embedded EDID size handling
- SMU 14.x updates
- Misc code cleanups and spelling fixes
- VCN devcoredump support
- ISP MFD i2c support
- DC vblank fixes
- GFX 12 fixes
- PSR fixes
- Convert vbios embedded EDID to drm_edid
- DCN 3.5 updates
- DMCUB updates
- Cursor fixes
- Overdrive support for SMU 14.x
- GFX CP padding optimizations
- DCC fixes
- DSC fixes
- Preliminary per queue reset infrastructure
- Initial per queue reset support for GFX 9
- Initial per queue reset support for GFX 7, 8
- DCN 3.2 fixes
- DP MST fixes
- SR-IOV fixes
- GFX 9.4.3/4 devcoredump support
- Add process isolation framework
- Enable process isolation support for GFX 9.4.3/4
- Take IOMMU remapping into account for P2P DMA checks
amdkfd:
- CRIU fixes
- Improved input validation for user queues
- HMM fix
- Enable process isolation support for GFX 9.4.3/4
- Initial per queue reset support for GFX 9
- Allow users to target recommended SDMA engines
radeon:
- remove .load and drm_dev_alloc
- Fix vbios embedded EDID size handling
- Convert vbios embedded EDID to drm_edid
- Use GEM references instead of TTM
- r100 cp init cleanup
- Fix potential overflows in evergreen CS offset tracking
Daniel Vetter [Tue, 27 Aug 2024 12:09:45 +0000 (14:09 +0200)]
Merge v6.11-rc5 into drm-next
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>
Daniel Vetter [Tue, 27 Aug 2024 10:55:16 +0000 (12:55 +0200)]
Merge tag 'drm-intel-gt-next-2024-08-23' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
UAPI Changes:
- Limit the number of relocations to INT_MAX (Tvrtko)
Only impact should be synthetic tests.
Driver Changes:
- Fix for #11396: GPU Hang and rcs0 reset on Cherrytrail platform
- Fix Virtual Memory mapping boundaries calculation (Andi)
- Fix for #11255: Long hangs in buddy allocator with DG2/A380 without
Resizable BAR since 6.9 (David)
- Mark the GT as dead when mmio is unreliable (Chris, Andi)
- Workaround additions / fixes for MTL, ARL and DG2 (John H, Nitin)
- Enable partial memory mapping of GPU virtual memory (Andi, Chris)
- Prevent NULL deref on intel_memory_regions_hw_probe (Jonathan, Dan)
- Avoid UAF on intel_engines_release (Krzysztof)
projects / users / jedix / linux-maple.git / log