Use checked_add() when computing offsets from firmware-provided values
in the RISC-V firmware parsing code. These values come from the BinHdr
structure parsed from the firmware file header.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-6-joelagnelf@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing the firmware data end offset in the
BinFirmware::data() method. The data_offset and data_size fields come
from the BinHdr structure parsed from the firmware file header.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-5-joelagnelf@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing the end offset in the frombytes_at()
helper function. This function is called with firmware-provided offsets.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-4-joelagnelf@nvidia.com
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() when computing signature offsets from firmware-
provided values in signatures_iter().
Without checked arithmetic, overflow could wrap to a small plausible
offset that points to entirely wrong data.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-3-joelagnelf@nvidia.com
[acourbot@nvidia.com: remove obvious computation comments.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Use checked_add() and checked_mul() when computing offsets from
firmware-provided values in new_fwsec().
Without checked arithmetic, corrupt firmware could cause integer
overflow. The danger is not just wrapping to a huge value, but
potentially wrapping to a small plausible offset that passes validation
yet accesses entirely wrong data, causing silent corruption or security
issues.
Reviewed-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260126202305.2526618-2-joelagnelf@nvidia.com
[acourbot@nvidia.com: rewrap commit message to make checkpatch happy.]
[acourbot@nvidia.com: add missing empty lines after new code blocks.]
[acourbot@nvidia.com: move SAFETY comments to the unsafe statement they
describe.]
[acourbot@nvidia.com: remove obvious computation comments and use
`CALC:` for the remaining ones.]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Wa_15010599737 was a workaround originally proposed (and ultimately
rejected) for DG2-G10. There's no record of it ever being relevant or
even considered for any other platforms.
The specific bit this workaround was setting is documented as "This bit
should be set to 1 for the DX9 API and 0 for all other APIs" which means
that it should almost always be left at the default value of 0 on Linux.
The register itself is directly accessible from userspace, so in the
special cases where it might be relevant (e.g., Wine/Proton running
Windows DX9 apps), the userspace drivers already have the ability to
change the setting without involvement of the kernel.
Fixes: 7f3ee7d880 ("drm/xe/xe2hpg: Add initial GT workarounds")
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260223-forupstream-wa_cleanup-v3-2-7f201eb2f172@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_18041344222 applies to all graphics versions from 20.01 through 30.00
(inclusive). Consolidate the RTP entries into a single range-based
entry.
v2:
- Drop the FUNC(xe_rtp_match_not_sriov_vf) to align with commit
a800b95c24 ("drm/xe/xe2hpg: Remove SRIOV VF check for
Wa_18041344222") and commit 0ffe9dcf26 ("drm/xe/xe3: Remove SRIOV
VF check for Wa_18041344222") which just landed. (Shuicheng)
Cc: Shuicheng Lin <shuicheng.lin@intel.com>
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260223-forupstream-wa_cleanup-v3-1-7f201eb2f172@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Correct the kernel-doc notation, add a missing struct member comment,
and add a missing "Returns:" function comment to eliminate kernel-doc
warnings:
Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:116 Incorrect use of
kernel-doc format: * @mode_set
Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:125 struct member 'mode_set'
not described in 'sunxi_engine_ops'
Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:144 struct member 'list'
not described in 'sunxi_engine'
Warning: drivers/gpu/drm/sun4i/sunxi_engine.h:168 No description found
for return value of 'sunxi_engine_layers_init'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/20260219215524.468142-1-rdunlap@infradead.org
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
The function drm_atomic_get_plane_state() can return an error pointer
and is not checked for it. Add error pointer check.
Detected by Smatch:
drivers/gpu/drm/sun4i/sun4i_backend.c:496 sun4i_backend_atomic_check() error:
'plane_state' dereferencing possible ERR_PTR()
Fixes: 96180dde23 ("drm/sun4i: backend: Add a custom atomic_check for the frontend")
Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/20260217014801.60760-1-ethantidmore06@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
The i915_active selftest no longer builds after the dma-fence locking
rework because it directly accessed the fence’s spinlock. The helper
dma_fence_spinlock() must now be used to obtain the spinlock. Update the
selftest to use dma_fence_spinlock() accordingly.
Fixes: 1f32f310a1 ("dma-buf: inline spinlock for fence protection v5")
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260223172553.1663749-1-matthew.brost@intel.com
The kernel-doc for drm_gpusvm_pages_valid_unlocked() was stale and still
referenced old range-based arguments and naming. Update the documentation
to match the current function arguments and signature.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patch.msgid.link/20260219205029.1011336-1-matthew.brost@intel.com
The auxiliary device registration was using a hardcoded ID of 0, which
caused probe() to fail on multi-GPU systems with:
sysfs: cannot create duplicate filename '/bus/auxiliary/devices/NovaCore.nova-drm.0'
Fix this by using an atomic counter to generate unique IDs for each
GPU's aux device registration. The TODO item to eventually use XArray
for recycling aux device IDs is retained, but for now, this works very
nicely.
This has the side effect of making debugfs[1] work on multi-GPU systems.
[1] https://lore.kernel.org/20260203224757.871729-1-ttabi@nvidia.com
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://patch.msgid.link/20260221020952.412352-2-jhubbard@nvidia.com
[ Use LKMM atomics; inline and slightly reword TODO comment. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Some compute applications may try to allocate device memory to probe
how much device memory is actually available, assuming that the
application will be the only one running on the particular GPU.
That strategy fails in fault mode since it allows VM overcommit.
While this could be resolved in user-space it's further complicated
by cgroups potentially restricting the amount of memory available
to the application.
Introduce a vm create flag, DRM_XE_VM_CREATE_NO_VM_OVERCOMMIT, that
allows fault mode to mimic the behaviour of !fault mode WRT this. It
blocks evicting same vm bos during VM_BIND processing. However,
it does *not* block evicting same-vm bos during pagefault
processing, preferring eviction rather than VM banning in
OOM situations.
Cc: John Falkowski <john.falkowski@intel.com>
Cc: Michal Mrozek <michal.mrozek@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20260204153320.17989-1-thomas.hellstrom@linux.intel.com
Add kernel-side support for using the zcull hardware in nvidia gpus.
zcull aims to improve memory bandwidth by using an early approximate
depth test, similar to hierarchical Z on an AMD card.
Add a new ioctl that exposes zcull information that has been read
from the hardware. Userspace uses each of these parameters either
in a heuristic for determining zcull region parameters or in the
calculation of a buffer size.
It appears the hardware hasn't changed its structure for these
values since FERMI_C (circa 2011), so the assumption is that it
won't change on us too quickly, and is therefore reasonable to
include in UAPI.
This bypasses the nvif layer and instead accesses nvkm_gr directly,
which mirrors existing usage of nvkm_gr_units(). There is no nvif
object for nvkm_gr yet, and adding one is not trivial.
Signed-off-by: Mel Henning <mhenning@darkrefraction.com>
Link: https://patch.msgid.link/20260219-zcull3-v3-2-dbe6a716f104@darkrefraction.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
This information will be exposed to userspace in the following commit.
Add struct nvkm_gr_zcull_info, which serves as abstraction layer between
the corresponding uAPI (added in a subsequent patch) and the firmware
structure.
Extend the existing get_ctxbufs callback to also fill in zcull info.
ctxsw_size and ctxsw_align come from
NV2080_CTRL_CMD_INTERNAL_STATIC_KGR_GET_CONTEXT_BUFFERS_INFO, which is
already called by r570_gr_get_ctxbufs, while the rest of the zcull
info comes from
NV0080_CTRL_FIFO_GET_ENGINE_CONTEXT_PROPERTIES_ENGINE_ID_GRAPHICS_ZCULL.
Adding a separate callback for zcull info would require us to either:
1) Call GET_CONTEXT_BUFFERS_INFO twice, once for each callback. This
is a little slower and more verbose than calling it once.
or
2) Fill out zcull_info partially in r570_gr_get_ctxbufs and partially
in the new callback. Since we fill out only some of the info in each
we now need to handle edge cases where one function is called but not
the other as well as them being called in an arbitrary order.
Because of this, it's simplest to combine them in a single call
(get_ctxbufs_and_zcull_info), which avoids repeated rpc calls
to the gpu without the complexity of handling partially complete states.
Signed-off-by: Mel Henning <mhenning@darkrefraction.com>
Link: https://patch.msgid.link/20260219-zcull3-v3-1-dbe6a716f104@darkrefraction.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Recently, the hdisplay calculation is working for 3:1 compressed ratio
only. If we have a video panel with DSC BPP = 8, and BPC = 10, we still
use the default bits_per_pclk = 24, then we get the wrong hdisplay. We
can draw the conclusion by cross-comparing the calculation with the
calculation in dsi_adjust_pclk_for_compression().
Since CMD mode does not use this, we can remove
!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO) safely.
Fixes: efcbd6f9cd ("drm/msm/dsi: Enable widebus for DSI")
Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/704822/
Link: https://lore.kernel.org/r/20260214105145.105308-1-mitltlatltl@gmail.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Currently Tyr uses rustfmt style for imports, but the kernel uses a
vertical layout that makes it easier to resolve conflicts and rebase.
Import guidelines are documented here:
https://docs.kernel.org/rust/coding-guidelines.html#imports
Change all of Tyr's imports to use the vertical layout. This will
ease the introduction of additional Tyr patches upstream.
There should be no functional changes in this patch.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Link: https://patch.msgid.link/20260223203833.207955-1-deborah.brouwer@collabora.com
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
GpuInfo::log() was decoding GPU_ID like this:
major = (self.gpu_id >> 16) & 0xff;
minor = (self.gpu_id >> 8) & 0xff;
status = self.gpu_id & 0xff;
That does not match the Mali GPU_ID layout and mixes unrelated
fields. Due to that, model detection becomes `mali-unknown` on
rk3588s which is wrong.
We can already get all the version information with a single
GpuId::from call (less code and cleaner), so this patch uses it.
Also renamed `GpuModels` fields from `major/minor` to
`arch_major/prod_major` to reflect their real meaning.
This change was tested on Orange Pi 5 (rk3588s) board and the
results are as follows:
Before this change:
$ dmesg | grep 'tyr'
[ 19.698338] tyr fb000000.gpu: mali-unknown id 0xa867 major 0x67 minor 0x0 status 0x5
[ 19.699050] tyr fb000000.gpu: Features: L2:0x7120306 Tiler:0x809 Mem:0x301 MMU:0x2830 AS:0xff
[ 19.699817] tyr fb000000.gpu: shader_present=0x0000000000050005 l2_present=0x0000000000000001 tiler_present=0x0000000000000001
[ 19.702493] tyr fb000000.gpu: Tyr initialized correctly.
After this change:
$ dmesg | grep 'tyr'
[ 19.591692] tyr fb000000.gpu: mali-g610 id 0xa867 major 0x0 minor 0x0 status 0x5
[ 19.592374] tyr fb000000.gpu: Features: L2:0x7120306 Tiler:0x809 Mem:0x301 MMU:0x2830 AS:0xff
[ 19.593141] tyr fb000000.gpu: shader_present=0x0000000000050005 l2_present=0x0000000000000001 tiler_present=0x0000000000000001
[ 19.595831] tyr fb000000.gpu: Tyr initialized correctly.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Tested-by: Alvin Sun <sk.alvin.x@gmail.com>
Link: https://patch.msgid.link/20260210183812.261142-1-work@onurozkan.dev
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Move buddy to the start of the link order, so its __init runs before any
other built-in drivers that may depend on it. Otherwise, a built-in
driver that tries to use the buddy allocator will run into a kernel NULL
pointer dereference because slab_blocks is uninitialized.
Specifically, this fixes drm/xe (as built-in) running into a kernel
panic during boot, because it uses buddy during device probe.
Fixes: ba110db8e1 ("gpu: Move DRM buddy allocator one level up (part two)")
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: intel-xe@lists.freedesktop.org
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Peter Senna Tschudin <peter.senna@linux.intel.com>
Signed-off-by: Koen Koning <koen.koning@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260213152047.179628-1-koen.koning@linux.intel.com
On top the timeouts mentioned in the spec which includes only the PHY
timeouts include the SoC and the OS turnaround time.
The overhead value is based on the stress test results with multiple
available panels.
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260216-timeout-v3-2-055522c22560@intel.com
The port refclk enable timeout and the soc ready timeout value mentioned
in the spec is the PHY timings and doesn't include the turnaround time
from the SoC or OS. So add an overhead timeout value on top of the
recommended timeouts from the PHY spec.
The overhead value is based on the stress test results with multiple
available panels.
Reported-by: Cole Leavitt <cole@unwrap.rs>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14713
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260216-timeout-v3-1-055522c22560@intel.com
Wa_14023061436 applies to all graphics versions from 30.00 through 30.05
(inclusive) since there is currently no IP that uses version 30.02.
Consolidate the RTP rules into a single range.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-23-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Given the new policy of allowing graphics/media IP ranges to extend over
unused IP versions, we can consolidate some of the OOB workaround rules
and simplify the table. If new IP variants eventually show up that use
these unused versions (e.g., media version 30.01, graphics versions
20.03 / 30.02, etc.), and if an existing workaround does not extend to
that new intermediate version, the ranges will be split back apart as
part of the enablement work for that new IP version.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-22-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_15016589081 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the RTP entries into a single range-based entry.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-20-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_18033852989 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the RTP entries into a single range-based entry.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-19-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14019988906 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the RTP entries into a single range-based entry.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-18-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14019386621 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the RTP entries into a single range-based entry.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-17-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14019877138 applies to all graphics versions from 12.55 through 20.04
(inclusive) that have a render engine. Consolidate the RTP entries into
a single range-based entry.
Note that the DG2 entry for this workaround was missing an
ENGINE_CLASS(RENDER) rule; that mistake is fixed by this consolidation.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-16-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_13012615864 applies to all graphics versions from 20.01 through 30.05
(inclusive). Consolidate the RTP entries into a single range-based
entry.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-14-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14021402888 applies to all graphics versions from 20.01 through 30.05
(inclusive). Consolidate the RTP entries into a single range-based
entry.
Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-13-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_16021639441 applies to all graphics versions from 20.01 through 20.04
(inclusive) and all media versions from 13.01 to 20.00 (inclusive).
Consolidate the RTP entries into a single range-based entry.
Also drop the reference to Wa_18032095049 which was only relevant to
pre-production platforms that we no longer support.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-12-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14018471104 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the two RTP entries into a single range-based
entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-11-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14020338487 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the two RTP entries into a single range-based
entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-10-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_16018712365 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the two RTP entries into a single range-based
entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-9-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_18032247524 applies to all graphics versions from 20.01 through 20.04
(inclusive). Consolidate the two RTP entries into a single range-based
entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-8-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_16021865536 applies to both media versions 30.00 and 30.02; since
version 30.01 is currently unused we can consolidate the two RTP entries
into a single range-based entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-7-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_16028005424 applies to all media IPs from 13.01 to 35.00 (inclusive)
and all graphics IPs from 30.00 and 30.05 (inclusive). Conslidate the
multiple RTP entries into a single range-based entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-6-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14019449301 applies to both media IP 13.01 and 20.00 and none of the
version numbers between those are used. Conslidate the two entries into
a single range entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-5-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_16021867713 applies to every single media IP from 13.00 to 30.02
(inclusive). We can consolidate the multiple per-version entries down
to a single range entry.
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-4-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
During early Xe driver development, our policy for applying workarounds
to ranges of IP versions was to only use GRAPHICS_VERSION_RANGE and
MEDIA_VERSION_RANGE rules when all of the affected IP versions had
consecutive version numbers; otherwise separate RTP entries should be
used. For example, a workaround that applies to all Xe2-based platforms
would be implemented in the driver with two RTP entries: one using
GRAPHICS_VERSION_RANGE(2001, 2002) and the other using
GRAPHICS_VERSION(2004). This ensured that if a new IP variant showed up
in the future with currently unused version 20.03, an old workaround
entry wouldn't automatically apply to it by accident (and we could
always consolidate those two distinct entries in the future if the
workaround database did explicitly indicate that 20.03 also needed the
workaround).
Now that we're a couple years down the road with this driver, the number
of IP versions supported is much larger (several Xe2 20.xx versions,
several Xe3 30.xx versions, and a couple Xe3p 35.xx versions). When new
workarounds are discovered that need to apply to a wide range of IPs,
it's becoming more of a pain to create independent entries for each
non-contiguous range of versions, and the general consensus is that we
should revisit our previous policy and start allowing use of
VERSION_RANGE constructs for non-contiguous version ranges.
Note that allowing ranges that cover currently unused versions will
require additional care if/when some of those intermediate version
numbers start being used in the future. We'll need to re-check every
workaround that has a range including the new IP version and check the
hardware database to see whether the workaround also applies to the new
version (no code change required) or whether we need to split the
existing range into two separate ranges that don't cover the new
version. The platform enabling engineers are willing to take on this
extra review burden at the time we first enable a new IP in the driver
(see lore link below for one recent discussion).
Update the kerneldoc for the workaround file to make the new policy
official.
Link: https://lore.kernel.org/all/20260203233600.GT458797@mdroper-desk1.amr.corp.intel.com/
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-3-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Production PVC hardware had a graphics stepping of C0. Xe1 platforms
already aren't officially supported by the Xe driver, but pre-production
steppings are especially out of scope (and 'has_pre_prod_wa' is not set
in the device descriptor). Drop the workarounds that aren't relevant to
production hardware.
v2:
- Drop the stream->override_gucrc which is no longer set anywhere after
the removal of Wa_1509372804. (Bala)
- Drop xe_guc_rc_set_mode / xe_guc_rc_unset_mode which are no longer
used after the removal of Wa_1509372804.
Bspec: 44484
Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-2-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Wa_14015795083 and Wa_14014475959 only apply to early steppings of
Xe_LPG that appeared only in pre-production hardware (in fact
Wa_14014475959 wasn't supposed to apply to _any_ steppings of version
12.71). Xe1 platforms already aren't officially supported by the Xe
driver, but pre-production steppings are especially out of scope (and
'has_pre_prod_wa' is not set in the device descriptor). Drop both
workarounds.
Bspec: 55420
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patch.msgid.link/20260220-forupstream-wa_cleanup-v2-1-b12005a05af6@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d24 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.
Switch to the regular pointer formatting which is safer and
easier to reason about.
This was previously fixed in this driver in commit 1ba9fbe403
("drm/msm: Don't use %pK through printk") but an additional usage
was reintroduced in commit 39a750ff5f ("drm/msm/dpu: Add DSPP GC
driver to provide GAMMA_LUT DRM property")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Fixes: 39a750ff5f ("drm/msm/dpu: Add DSPP GC driver to provide GAMMA_LUT DRM property")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/706229/
Link: https://lore.kernel.org/r/20260223-restricted-pointers-msm-v1-1-14c0b451e372@linutronix.de
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
The assigned type is "void **" but the returned type will be "void ***".
These are the same allocation size (pointer size), but the types do not
match. Adjust the allocation type to match the assignment.
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/703588/
Link: https://lore.kernel.org/r/20260206222151.work.016-kees@kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The register space has grown with what seems to be DPU8.
Bump up the .len to match.
Fixes: e3b1f369db ("drm/msm/dpu: Add X1E80100 support")
Fixes: 4a352c2fc1 ("drm/msm/dpu: Introduce SC8280XP")
Fixes: efcd010772 ("drm/msm/dpu: add support for SM8550")
Fixes: 100d7ef699 ("drm/msm/dpu: add support for SM8450")
Fixes: 1785751734 ("drm/msm/dpu: add catalog entry for SAR2130P")
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/701063/
Link: https://lore.kernel.org/r/20260127-topic-lm_size_fix-v1-1-25f88d014dfd@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
