My previous patch ended up causing a regression for the
DRM_IOCTL_NOUVEAU_NVIF ioctl. The intention of my patch was to only
pass ioctl commands that have the correct dir/type/nr bits into the
nouveau_abi16_ioctl() function.
This turned out to be too strict, as userspace does use at least
write-only and write-read direction settings. Checking for both of these
still did not fix the issue, so the best we can do for the 6.16 release
is to revert back to what we've had since linux-3.16.
This version is still fragile, but at least it is known to work with
existing userspace. Fixing this properly requires a better understanding
of what commands are being passed from userspace in practice, and how
that relies on the undocumented (miss)behavior in nouveau_drm_ioctl().
Fixes: e5478166df ("drm/nouveau: check ioctl command codes better")
Reported-by: Satadru Pramanik <satadru@gmail.com>
Closes: https://lore.kernel.org/lkml/CAFrh3J85tsZRpOHQtKgNHUVnn=EG=QKBnZTRtWS8eWSc1K1xkA@mail.gmail.com/
Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Closes: https://lore.kernel.org/lkml/aH9n_QGMFx2ZbKlw@debian.local/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250722115830.2587297-1-arnd@kernel.org
[ Add Closes: tags, fix minor typo in commit message. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
With the Opaque<T>, the expectations are that Rust should not
make any assumptions on the layout or invariants of the wrapped
C types. That runs rather counter to ioctl arguments, which must
adhere to certain data-layout constraints. By using Opaque<T>,
ioctl handlers are forced to use unsafe code where none is actually
needed. This adds needless complexity and maintenance overhead,
brining no safety benefits.
Drop the use of Opaque for ioctl arguments as that is not the best
fit here.
Signed-off-by: Beata Michalska <beata.michalska@arm.com>
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/r/20250626162313.2755584-1-beata.michalska@arm.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
DRM_DEBUG_SELFTEST was removed in commit fc8d29e298 (drm: selftest:
convert drm_mm selftest to KUnit) and all functions under it were
converted to KUnit, under the DRM_KUNIT_TEST option
This conversion however did not occur in the Kconfig.debug file in the
i915 directory.
This patch replaces the select for DRM_DEBUG_SELFTEST, an option that no
longer exists, with the correct select, DRM_KUNIT_TEST.
Signed-off-by: Ruben Wauters <rubenru09@aol.com>
Link: https://lore.kernel.org/r/20250701115511.5445-1-rubenru09@aol.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
On g4x we currently use the 96MHz non-SSC refclk, which can't actually
generate an exact 2.7 Gbps link rate. In practice we end up with 2.688
Gbps which seems to be close enough to actually work, but link training
is currently failing due to miscalculating the DP_LINK_BW value (we
calcualte it directly from port_clock which reflects the actual PLL
outpout frequency).
Ideas how to fix this:
- nudge port_clock back up to 270000 during PLL computation/readout
- track port_clock and the nominal link rate separately so they might
differ a bit
- switch to the 100MHz refclk, but that one should be SSC so perhaps
not something we want
While we ponder about a better solution apply some band aid to the
immediate issue of miscalculated DP_LINK_BW value. With this
I can again use 2.7 Gbps link rate on g4x.
Cc: stable@vger.kernel.org
Fixes: 665a7b0409 ("drm/i915: Feed the DPLL output freq back into crtc_state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-2-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
(cherry picked from commit a8b874694d)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Nova changes for v6.17
DMA:
- Merge topic/dma-features-2025-06-23 from alloc tree.
- Clarify wording and be consistent in 'coherent' nomenclature.
- Convert the read!() / write!() macros to return a Result.
- Add as_slice() / write() methods in CoherentAllocation.
- Fix doc-comment of dma_handle().
- Expose count() and size() in CoherentAllocation and add the
corresponding type invariants.
- Implement CoherentAllocation::dma_handle_with_offset().
nova-core:
- Various register!() macro improvements.
- Custom Sleep / Delay helpers (until the actual abstractions land).
- Add DMA object abstraction.
- VBIOS
- Image parser / iterator.
- PMU table look up in FWSEC.
- FWSEC ucode extraction.
- Register sysmem flush page.
- Falcon
- Generic falcon boot code and HAL (Ampere).
- GSP / SEC2 specific code.
- FWSEC-FRTS
- Compute layout of FRTS region (FbLayout and HAL).
- Load into GSP falcon and execute.
- Add Documentation for VBIOS layout, Devinit process, Fwsec operation
and layout, Falcon basics.
- Update and annotate TODO list.
- Add Alexandre Courbot as co-maintainer.
Rust:
- Make ETIMEDOUT error available.
- Add size constants up to SZ_2G.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: "Danilo Krummrich" <dakr@kernel.org>
Link: https://lore.kernel.org/r/DBFKLDMUGZD9.Z93GN2N5B0FI@kernel.org
Rather than export a macro that delegates to `core::format_args`, simply
re-export `core::format_args` as `fmt` from the prelude. This exposes
clippy warnings which were previously obscured by this macro, such as:
warning: variables can be used directly in the `format!` string
--> ../drivers/cpufreq/rcpufreq_dt.rs:21:43
|
21 | let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#uninlined_format_args
= note: `-W clippy::uninlined-format-args` implied by `-W clippy::all`
= help: to override `-W clippy::all` add `#[allow(clippy::uninlined_format_args)]`
help: change this to
|
21 - let prop_name = CString::try_from_fmt(fmt!("{}-supply", name)).ok()?;
21 + let prop_name = CString::try_from_fmt(fmt!("{name}-supply")).ok()?;
|
Thus fix them in the same commit. This could possibly be fixed in two
stages, but the diff is small enough (outside of kernel/str.rs) that I
hope it can be taken in a single commit.
Signed-off-by: Tamir Duberstein <tamird@gmail.com>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20250704-core-cstr-prepare-v1-1-a91524037783@gmail.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Currently we pre-compute the plane surface/base address
partially (only for cursor_needs_physical cases) in
intel_plane_pin_fb() and finish the calculation in the
plane->update_arm(). Let's just precompute the whole thing
instead.
One benefit is that we get rid of all the vma offset stuff
from the low level plane code. Another use I have in mind
is including the surface address in the plane tracepoints,
which should make it easier to analyze display faults.
v2: Deal with xe reuse_vma() hacks
v3: use intel_plane_ggtt_offset() still in reuse_vma()
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250717203216.31258-1-ville.syrjala@linux.intel.com
GLK doesn't use the DSI C clock at all, no need to program
the divider for it. Bspec even says: "Do not program this field".
However looks like some firmware versions program this and
some do not. In order to avoid bogus fastset mismatches
we should also filter it out during readout.
v2: Clear all the DSI C clock bits during readout (Jani)
Adjust platform checks for new style, and add
has_dsic_clock() while at it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250718112928.27669-1-ville.syrjala@linux.intel.com
Currently the job free work item will lock sched->job_list_lock first time
to see if there are any jobs, free a single job, and then lock again to
decide whether to re-queue itself if there are more finished jobs.
Since drm_sched_get_finished_job() already looks at the second job in the
queue we can simply add the signaled check and have it return the presence
of more jobs to be freed to the caller. That way the work item does not
have to lock the list again and repeat the signaled check.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: Maíra Canal <mcanal@igalia.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://lore.kernel.org/r/20250716085117.56864-1-tvrtko.ursulin@igalia.com
CRIU restore of drm buffer objects requires the ability to create
or import a buffer object with a specific gem handle.
Add new drm ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, which takes
the gem handle of an object and moves that object to a
specified new gem handle.
This ioctl needs to call drm_prime_remove_buf_handle,
but that function acquires the prime lock, which the ioctl
needs to hold for other purposes.
Make drm_prime_remove_buf_handle not acquire the prime lock,
and change its other caller to reflect this.
The rest of the kernel patches required to enable CRIU can be
found at
https://lore.kernel.org/dri-devel/20250617194536.538681-1-David.Francis@amd.com/
v2 - Move documentation to UAPI headers
v3 - Always return 0 on success
Signed-off-by: David Francis <David.Francis@amd.com>
Acked-by: Felix Kuehling <felix.kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://lore.kernel.org/r/20250717143556.857893-2-David.Francis@amd.com
Our hardware registers are set through GCE, not by the CPU.
DRM might assume the hardware is disabled immediately after calling
atomic_disable() of drm_plane, but it is only truly disabled after the
GCE IRQ is triggered.
Additionally, the cursor plane in DRM uses async_commit, so DRM will
not wait for vblank and will free the buffer immediately after calling
atomic_disable().
To prevent the framebuffer from being freed before the layer disable
settings are configured into the hardware, which can cause an IOMMU
fault error, a wait_event_timeout has been added to wait for the
ddp_cmdq_cb() callback,indicating that the GCE IRQ has been triggered.
Fixes: 2f965be7f9 ("drm/mediatek: apply CMDQ control flow")
Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20250624113223.443274-1-jason-jh.lin@mediatek.com/
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
All platforms are capable of explicitly transmitting the idle
pattern. Implement it for everyone (so far it as implemented
only for HSW+).
The immediate benefit is that we gain the possibility of
implementing the POST_LT_ADJ_REQ sequence for all platforms.
Another potential future use would be a pseudo port sync mode on
pre-BDW where we attempt to sync up multiple ports/pipes by trying
to turn on the transcoders at the same time, and switching the
links to normal pixel transmission at the same time.
I'm not 100% sure the hardware is guaranteed to transmit the
required number of idle patterns (5) when switching away from
training pattern (either via explicit idle pattern, or straight
to the normal pixel output). Would be nice to confirm that at
some point, but for now let's assume it happens correctly in
both cases.
v2: Elaborate a bit more on the min required idle patterns
Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-7-ville.syrjala@linux.intel.com
We are supposed to switch off the training pattern in DPCD before
we start transmitting the idle pattern. For LTTPRs we do that
correctly, but for the sink DPRX we only do this correctly
for some platforms.
On pre-HSW (where we don't implement the .set_idle_link_train()
hook), we directly switch from transmitting the training pattern
to normal pixel transmission (the hardware should hopefully
guarantee that the minimum number of required idle patters will
be transmitted during this transition). The DPCD write correctly
precedes the actual switch away from the training pattern.
For HSW+ we start transmitting the idle pattern earlier, and only
switch off the DPCD training pattern after we switch from the idle
pattern to normal pixel transmission. Adjust the code to disable
the DPCD training pattern before we start transmitting the idle
pattern.
v2: Tweak the commit message a bit
Tested-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-4-ville.syrjala@linux.intel.com
For some reason we are switching over to the idle pattern before
disabling the DP port on pre-hsw. AFAICS this has never been part
of the documented sequence (and on hsw+ the spec explicitly says
not to do this). Get rid of it.
The code goes all the way back to commit 5eb08b69f5 ("drm/i915: enable
DisplayPort support on IGDNG"), and it was accompanied by a 17ms delay
which got changed to vbl wait in commit ab527efc2f ("drm/i915: use
wait_for_vblank instead of msleep(17)"), and was later completely removed
in commit 93c9c19b3d ("drm/i915: remove unexplained vblank wait in
the DP off code").
Smoke tested on g4x/snb/chv.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-3-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
