DRM_GEM_SHADOW_PLANE_FUNCS currently sets .reset to
drm_gem_reset_shadow_plane. Since
drm_gem_create_shadow_plane_state() now exists and only handles
pristine state allocation without conflating it with hardware or
suspend/resume reset, switch the macro to use .atomic_create_state
instead.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260814-drm-no-more-plane-reset-v2-4-82d2963dd134@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
drm_gem_simple_kms_reset_shadow_plane() implements the reset_plane
hook for simple-kms shadow-buffered planes. Since the reset hook
conflates initial state creation with hardware and software reset
during suspend/resume, convert it to the create_plane_state pattern.
Replace it with drm_gem_simple_kms_create_shadow_plane_state(), which
implements the create_plane_state hook using
drm_gem_create_shadow_plane_state(). Update
DRM_GEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS accordingly.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260814-drm-no-more-plane-reset-v2-3-82d2963dd134@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The GEM shadow-plane helpers only expose reset functions
(drm_gem_reset_shadow_plane and __drm_gem_reset_shadow_plane) that
handle both the initial state allocation and the reset path. The new
atomic_create_state hook requires a function that only allocates and
initializes a pristine state without any side effect.
Create __drm_gem_shadow_plane_state_init() to initialize a
pre-allocated shadow plane state, and
drm_gem_create_shadow_plane_state() to allocate and initialize one
from scratch.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260814-drm-no-more-plane-reset-v2-2-82d2963dd134@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The simple-kms helper provides a reset_plane hook to let drivers
override the default plane reset. However, the reset hook is
overloaded: it is used to create the initial software state at probe
time, but also to reset both the hardware and software state during
suspend/resume. These two roles have different expectations, and
reset is not fallible which makes error handling difficult.
The atomic_create_state pattern was introduced to untangle this by
providing a hook that only allocates and initializes a pristine state
without any side effect.
Add a create_plane_state hook to struct
drm_simple_display_pipe_funcs. When provided,
drm_simple_kms_plane_reset() will use it to allocate a fresh state,
falling back to reset_plane and then to the default
drm_atomic_helper_plane_reset().
This will allow simple-kms drivers to be converted to the
atomic_create_state pattern.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patch.msgid.link/20260814-drm-no-more-plane-reset-v2-1-82d2963dd134@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Update drm_of_get_data_lanes_count_ep() return value documentation
to match the drm_of_get_data_lanes_count() return value documentation.
The drm_of_get_data_lanes_count_ep() is only a wrapper around the
drm_of_get_data_lanes_count() and therefore returns the same error
codes.
Simplify the return code description of drm_of_get_data_lanes_count()
and drm_of_get_data_lanes_count_ep() to -ENODATA and -EINVAL.
Fixes: fc801750b1 ("drm: of: Add drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20260305205840.95978-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The OMAP HDMI audio driver currently has no way of reporting HDMI cable
hotplug events to ASoC. As a result, user space cannot detect HDMI audio
availability through the standard jack mechanism and audio policy managers
cannot automatically route audio to or from the HDMI output.
Add an optional HPD callback to `omap_hdmi_audio_pdata` and invoke it from
the DRM HDMI bridge whenever the connector status changes. The HDMI audio
driver registers an ASoC jack and reports `SND_JACK_AVOUT` state changes in
response to these notifications.
Also fix the disconnect path by taking a runtime PM reference before
updating the CEC physical address.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Tested-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Link: https://patch.msgid.link/20260819171935.233946-1-ivo.g.dimitrov.75@gmail.com
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
nouveau_dp_irq() looks the encoder up and dereferences it in the same
breath, five lines before testing it:
struct nouveau_encoder *outp = find_encoder(connector, DCB_OUTPUT_DP);
struct nouveau_drm *drm = nouveau_drm(outp->base.base.dev);
...
if (!outp)
return;
find_encoder() walks the connector's possible encoders and returns NULL
when none of them matches the requested type, so the NULL test is not
decoration: it is the author saying this can happen. The initialiser
above it dereferences the same pointer regardless.
The NULL test predates the dereference. commit 773eb04d14
("drm/nouveau/disp: expose conn event class") turned nouveau_dp_irq()
into a work callback, and since the drm pointer was no longer passed in
as an argument it was recovered from the encoder in the declaration
block, which put the dereference above the existing test.
Move the drm lookup below the test. No functional change when outp is
non-NULL.
Fixes: 773eb04d14 ("drm/nouveau/disp: expose conn event class")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marek Czernohous <marek@czernohous.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/178682366004.3748010.14933649768375463967@gmail.com
nouveau_connector_destroy() tears the two nvif events down and then
frees the connector, but never cancels the work the IRQ event queues:
nvif_event_dtor(&nv_connector->irq);
nvif_event_dtor(&nv_connector->hpd);
kfree(nv_connector->edid);
...
kfree(connector);
nouveau_connector_irq() queues that work unconditionally:
schedule_work(&nv_connector->irq_work);
return NVIF_EVENT_KEEP;
A DP IRQ arriving just before nvif_event_dtor() therefore leaves
nv_connector->irq_work on the system queue past the kfree(). When it
runs, nouveau_dp_irq() derives both nv_connector and connector from the
work_struct and dereferences them, and goes on to take
outp->dp.hpd_irq_lock.
There is no cancel_work_sync() for irq_work anywhere in the driver, so
nothing else covers this. Add it after the event teardown, where no
further work can be queued, and before anything is freed.
Reported by the Sashiko review bot as a pre-existing issue, in its review
of an earlier nv04 FIFO series of mine, and confirmed against the source.
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Link: https://sashiko.dev/#/patchset/20260812231330.705425-1-mczernohous@gmail.com?part=1
Fixes: 773eb04d14 ("drm/nouveau/disp: expose conn event class")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marek Czernohous <marek@czernohous.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/178682366002.3748010.4096452389040554615@gmail.com
nouveau_fence_context_del() drains the uevent work while the event that
feeds it is still armed:
cancel_work_sync(&fctx->uevent_work);
nouveau_fence_context_kill(fctx, 0);
nvif_event_dtor(&fctx->event);
nouveau_fence_wait_uevent_handler() queues the work unconditionally:
schedule_work(&fctx->uevent_work);
return NVIF_EVENT_KEEP;
so a non-stall interrupt arriving after cancel_work_sync() has returned
re-arms the work that was just drained. The window closes in two steps,
neither of which is the drain. The kill blocks the event when the last
fence holding a notify_ref is signalled, which reaches
atomic_xchg(&ntfy->allowed, 0) (nvkm/core/event.c:104), and
nvkm_event_ntfy() skips a ntfy that is not allowed (:183). That stops
further handlers from starting, but not one that is already inside
nvkm_event_ntfy(): the event is created with wait = false
(nouveau_fence.c:201), so nvkm_event_ntfy_block_() leaves it on the list
and never takes event->list_lock. Only nvif_event_dtor() waits that one
out: nvkm_event_ntfy_del() (:141) goes through nvkm_event_ntfy_remove(),
which takes write_lock_irq() on that same list_lock (:84).
Either way the re-arm happens after the drain, and the caller drops its
reference immediately afterwards, for example nv84_fence_context_del():
nouveau_fence_context_del(&fctx->base);
chan->fence = NULL;
nouveau_fence_context_free(&fctx->base);
That is a kref_put() on fctx->fence_ref, so the context outlives the
teardown only while emitted fences still hold a reference of their own.
That is no safety net: whenever none do, the count reaches zero right
there and nouveau_fence_context_put() kfree()s fctx while the work is
still queued. &fctx->uevent_work is embedded in that allocation, so the
workqueue already dereferences freed memory when it picks the item up,
and nouveau_fence_uevent_work() can then take fctx->lock on it. With
CONFIG_DEBUG_OBJECTS_WORK and CONFIG_DEBUG_OBJECTS_FREE, kfree() of a
still-queued work item is reported as the free of an active object.
On live memory the re-armed work has nothing left to do:
nouveau_fence_context_kill() empties fctx->pending and sets fctx->killed
under fctx->lock, nouveau_fence_emit() then returns -ENODEV rather than
queueing anything new, and nouveau_fence_update() only reaches
nvif_event_block() if it signalled something off that list. The defect
is the access to freed memory, not what the work would have found.
Only chips from G84 on can reach this at all: nouveau_fence_context_new()
returns before nvif_event_ctor() when priv->uevent is clear, and
nv84_fence_create() is the only place that sets it.
nv84_fence_context_del() is the context_del for all of those, because
nvc0_fence_create() and gv100_fence_create() build on nv84_fence_create()
and override only context_new.
Use disable_work_sync() instead. It drains the work exactly like
cancel_work_sync() does, and additionally increments the work item's
disable count, after which "any attempt to queue @work will fail and
return %false" (kernel/workqueue.c, disable_work()). The handler's
schedule_work() then has nothing to re-arm, and the teardown order stays
as it is.
Draining a second time after nvif_event_dtor() would close the window as
well, and without the newer API: once nvkm_event_ntfy_remove() has
returned, no handler can start or still be running, so nothing re-arms
the work past that point. disable_work_sync() is preferred here because
it needs one synchronisation point instead of two, it keeps the work
from being queued at all rather than cleaning up after it, and it is
what drm has settled on for this (drm/xe, drm/panthor, drm_pagemap).
Blocking the event rather than the work is not an option: fctx->event is
created with wait = false, so a handler already inside nvkm_event_ntfy()
can still queue the work.
Note for backports: disable_work_sync() arrived in v6.10 with
commit 86898fa6b8 ("workqueue: Implement disable/enable for (delayed)
work items"), while the fix being corrected here reached 6.6.18 and
6.7.6. linux-6.6.y therefore carries this bug without the API, and this
patch would apply there and then fail to build. A 6.6.y backport wants
the second drain described above instead, as its own patch.
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260812233022.159301F000E9@smtp.kernel.org/
Fixes: 39126abc5e ("nouveau: offload fence uevents work to workqueue")
Cc: <stable@vger.kernel.org> # 6.10.x
Assisted-by: Claude:claude-opus-5
Signed-off-by: Marek Czernohous <marek@czernohous.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/178688513268.513871.3468844663561639695@gmail.com
When updating and debug-printing devfreq stats, in the very unlikely
off-chance that total device time is less than 100 ns, division by 0
would happen. Fix the divisor when relevant and rearrange operands.
Reported-by: Claude <noreply@anthropic.com>
Closes: https://gitlab.freedesktop.org/panfrost/linux/-/work_items/88
Fixes: f3ba91228e ("drm/panfrost: Add initial panfrost driver")
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patch.msgid.link/20260820-b4-panfrost-fixes-v1-2-1b2c2376f4bc@collabora.com
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
The verisilicon driver has a custom framebuffer address calculating
helper that the common drm_fb_dma_get_addr() can substitute.
Differences from drm_fb_dma_get_addr():
- Uses drm_format_info_min_pitch() to calculate the horizontal offset;
however the driver does not support any of the blocked formats, so
this just ends up being the same as in drm_fb_dma_get_addr():
"cpp[plane] * y"
- Uses clipped source coordinates instead of non-clipped coordinates
as in drm_fb_dma_get_addr();
For the primary plane this doesn't matter, since the primary plane
must match the output, i.e. it cannot be clipped. Also this driver
doesn't support scaling.
For the cursor plane this seems wrong, as the clipping seems to be
done by the hardware, and thus the buffer address should be unclipped.
As such, it should be fine to use the common helper and drop the custom
code.
Tested-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Fixes: 8c4ae21891 ("drm: verisilicon: add support for cursor planes")
Link: https://patch.msgid.link/20260813065127.341349-1-wenst@chromium.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The 4th argument of regmap_update_bits() expects a pre-shifted register
value instead of the field value when it's used to set a single field,
however I forgot this when writing the code setting the cursor X/Y
offset fields, thus the write operation doesn't happen at all (because
of the non-shifted values being masked by regmap_update_bits()).
Fix this problem so the cursor is correctly clipped.
The framebuffer address is also clipped so the cursor offset problem was
previously not discovered, and the framebuffer address deserves another
fix for proper cursor behavior when it's clipped.
Fixes: 8c4ae21891 ("drm: verisilicon: add support for cursor planes")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20260812154829.671777-1-zhengxingda@iscas.ac.cn
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
NVAC (MCP79/MCP7A) uses g94_pci_func, whose .msi_rearm is
nv40_pci_msi_rearm(): a re-arm write through the MMIO mirror of PCI
config space. On this IGP that path is unreliable; when a re-arm is
missed the interrupt line stays dead, command submission times out and
the GPU appears hung until reboot. On an Apple Mac mini (early 2009,
MCP79, boot0 0x0ac080b1) this showed as sporadic fifo timeouts and GPU
hangs under load unless MSI was disabled via config=NvMSI=0.
Give NVAC its own pci func that re-arms through real PCI config space
(nv46_pci_msi_rearm) instead. This follows existing precedent: nv46.c
documents the MMIO-mirror re-arm as broken on several related parts,
and commit 5112abc6a4 ("drm/nouveau/pci/g92: Fix rearm") fixed g92
the same way while moving the remaining chipsets, NVAC included, into
the newly added shared g94 table, where NVAC stayed on the MMIO path.
This change completes that fix for NVAC. The sibling IGP NVAA
(MCP77/MCP78) has MSI disabled entirely as "reported broken" in
nvkm_pci_new_(); NVAC works correctly once the re-arm goes through
config space, so disabling MSI is not necessary.
Only NVAC is switched: that is the hardware this has been validated
on. The other users of g94_pci_func (G94/G96/G98/GT2xx and the
MCP77/MCP89 IGPs) keep their current behavior; MCP77 and MCP89
plausibly want the same treatment but were not tested.
Tested on the Mac mini as a daily driver for two months with MSI
enabled and zero fifo timeouts. Independently confirmed stable on an
iMac9,1 (MCP79) running 6.12.90 with the v1 form of this change (the
same one-line functional switch, applied to that kernel's g94
implementation).
Fixes: 5112abc6a4 ("drm/nouveau/pci/g92: Fix rearm")
Cc: <stable@vger.kernel.org> # v6.16+
Tested-by: Fab Stz <fabstz-it@yahoo.fr>
Assisted-by: Claude:claude-opus-4-7
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Marek Czernohous <marek@czernohous.de>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/178688574401.522643.12812428444459119913@gmail.com
The SVM fault handler nouveau_svm_fault() looks up each fault's
nouveau_svmm under svm->mutex, caches it in the fault array, then drops
svm->mutex and dereferences the svmm across blocking faults
(mmu_interval_notifier_insert(), hmm_range_fault()).
nouveau_svmm is not refcounted. On DRM file close nouveau_svmm_fini() ->
mmu_notifier_put() frees it asynchronously via call_srcu() without
waiting for the handler, and mmget_not_zero() pins the mm, not the svmm.
flush_work() on the fault buffer otherwise runs only at device removal
and suspend, never on close, so a fault handled concurrently with a close
can dereference a freed svmm.
The instance is already unlinked by nouveau_svmm_part() earlier in the
same close, so no new fault can resolve to it. Drain the handler in
nouveau_svmm_fini() before the free, guarding the flush with a NULL check
on drm->svm: on device teardown nouveau_svm_fini() runs first and frees
drm->svm (NULL) after blocking the notify and flushing the buffer, so the
handler is already drained; on per-client close drm->svm is alive and the
flush runs.
Fixes: eeaf06ac1a ("drm/nouveau/svm: initial support for shared virtual memory")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260814-nouveau-svm-svmm-uaf-v2-1-8e6590519f07@gmail.com
nouveau_abi16_ioctl_notifierobj_alloc() passes the userspace-controlled
info->size to nvkm_mm_head() as both size_max and size_min without a lower
bound. A zero size satisfies the allocator's "e - s < size_min" gate
(size_min == 0 makes the unsigned comparison inert) and yields a
zero-length node, after which
args.limit = ntfy->node->offset + ntfy->node->length - 1;
underflows (offset 0, length 0 -> 0xffffffff) into an oversized ~4 GiB DMA
window. The dma object constructor only rejects start > limit, so the
validly ordered [base, base + 0xffffffff] range passes and is programmed
into the GPU DMA context. The ioctl is DRM_RENDER_ALLOW, so any render
node client can trigger this on pre-Fermi hardware.
Reject a zero-size request before allocating anything.
Fixes: ebb945a94b ("drm/nouveau: port all engines to new engine module format")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhao Wan <whi4ed0g@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patch.msgid.link/20260813-nouveau-abi16-notifierobj-zero-size-v1-1-20dee38077cb@gmail.com
drm_sched_entity_is_idle() contains a badly documented memory barrier
and an invalid lockless access to entity->stopped. Moreover, it also
accesses entity->list which is at all other places protected by
entity->lock.
This function is in no way performance critical, so it is safer, more
readable and more maintainable to take the spinlock.
Add locking to drm_sched_entity_is_idle().
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Link: https://patch.msgid.link/20260813094539.2407911-2-phasta@kernel.org
Follow up on the previous devm_drm_bridge_add() conversion by
converting the remaining manual cleanup in chipone-icn6211 to the
managed helper.
Suggested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patch.msgid.link/20260521212529.151493-1-osama.abdelkader@gmail.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
As it turns out, Turing isn't the only architecture that needs this. On
this Dell Precision 7780 with an AD103 GPU, along with pretty much every
other laptop I tested, runtime PM is still somewhat unreliable. At first
glance it seems as if it's fixed, but lowering the autosuspend delay to
500ms and then doing a stress test of suspend/resume cycles on the GPU ends
up causing everything to start timing out.
After quite a lot of digging, I eventually landed back on this magic
timeout in r535_gsp_fini(). As it turns out, increasing the timeout ends up
fixing the runtime PM issues as far as I can tell, even during intense
stress testing.
Unfortunately after spending quite a bit of time trying to dig through
OpenRM to figure out what this magic sleep is actually doing, I've also
come up short with any reasonable explanation. In lieu of that, I'm going
to include the observations I did make while trying to figure this out in
hopes someone eventually does figure this out:
* The magic sleep has to occur after fbsr is initialized. Performing it at
any time before that doesn't appear to work.
* In situations where runtime PM starts getting flaky, some rather
interesting visual effects end up happening on occasion before the GPU
fully falls over. In particular, squares that look like the result of an
incomplete blitting operation to a tiled buffer end up showing up on
applications like vkcube. Interestingly enough, they remain in precisely
the same place between runtime PM cycles until the GPU falls over - even
when restarting vkcube multiple times, and even when vkcube is actively
updating the screen. Even more interestingly, they're not limited to a
specific framebuffer - you can see the squares changing as the cube
rotates around.
We cannot however, say that this is likely to be a incomplete fbsr
operation. The magic sleep happens before fbsr is actually saved (which
happens on the GSP unload), so it's something else.
* During a short bit of testing with a desktop that I have, the magic sleep
seemed to make no difference to whether or not suspend/resume works. It
seems to generally work almost always. So we can assume this is likely
exclusive to runtime PM, not S3.
As well, here's a list of the things I tried before settling on the magic
sleep:
* Hooking up NV2080_CTRL_CMD_INTERNAL_GCX_ENTRY_PREREQUISITE and then
blocking runtime PM until OpenRM signals that GC6/GCOFF is ready appears
to make no difference.
* Hooking up some (maybe not all, unsure about that part) bits of comptag
saving including:
* Fetching static memsys information from GSP
* Adding the size of the comptag storage to the fbsr data
* Adding a GA103+ workaround for disabling raw compression mode during
fbsr (it doesn't seem like it applies for any systems I tried it on
anyhow)
* Setting bPreserveVideoMemoryAllocations=1 in GspSystemInfo
So, until we can figure this out properly - just sleep for longer.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac06238 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-5-lyude@redhat.com
There's two flags that we've never been setting when asking GSP to suspend
the GPU, which OpenRM does set:
GPU_STATE_FLAGS_PRESERVING
GPU_STATE_FLAGS_PM_TRANSITION
These flags aren't -supposed- to do much in GSP, they're mostly used by
OpenRM itself for state tracking. The only thing they do from GSP's side is
control whether or not a single display related workaround is applied
during suspend.
But as it turns out, that single workaround is actually quite crucial for
getting runtime PM working with nouveau - and without it set we end up
seeing a lot more failures with runtime PM resume. So, let's start setting
it.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac06238 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-4-lyude@redhat.com
Previously, it looked as if we were able to fix suspend/resume on some
desktops by setting Gcoff based on whether or not we were entering runtime
PM. This was a mistake though - the only time suspend/resume would end up
actually working was if Gcoff = 0.
It seems like it's likely the main reason for this is the FBSR GcOff
argument actually controls GSP's behavior with regards to which buffers it
decides to save across suspend/resume. When GcOff = 1, RM reserved regions
are saved unless they are marked as LOST_ON_SUSPEND, and RM channel-context
and kernel-client buffers are also saved -including- when they are
LOST_ON_SUSPEND. This means with GcOff = 1, we end up having GSP save and
restore buffers that actually need to be reinitialized on resume - causing
the failures we're setting.
Thanks to John Hubbard from Nvidia for providing some background on what
these options do in the GSP firmware do!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 53dac06238 ("drm/nouveau/gsp: add support for 570.144")
Cc: <stable@vger.kernel.org> # v6.16+
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-3-lyude@redhat.com
This reverts commit 8302d0afea.
It turns out this looked like the right fix on some systems, but it's not -
as this causes runtime PM to actually fail on many a laptop.
Fixes: 8302d0afea ("nouveau/gsp: fix suspend/resume regression on r570 firmware")
Cc: <stable@vger.kernel.org> # v6.19+
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260814194542.781955-2-lyude@redhat.com
Nouveau is one of the very few modern hardware drivers in the kernel that
doesn't have atomic modesetting enabled by default, in part because when it
was originally written by Ben there wasn't much in the way of good atomic
modesetting clients to actually test things out with.
Nowadays however, atomic modesetting is very much the norm - and support in
userspace for non-atomic drivers is starting to bitrot a bit - leading to
its own set of issues. At the same time, many of those issues are fixed by
just turning on atomic in nouveau. Plus, I've been running nouveau with
atomic modesetting on by default for most of the machines I work on, and
I've already fixed quite a number of issues to the point where things seem
quite stable (excluding a single screen flashing bug on my desktop, which I
am not particularly convinced has anything to do with atomic modesetting).
Now that we've protected against breaking things for chipsets where atomic
isn't supported (<nv50) - let's enable it by default on generations of
hardware that support it. We'll leave the module parameter around for the
time being, as turning it off may be helpful in the possibility that we hit
regressions.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260813204803.2097176-6-lyude@redhat.com
Atomic modesetting support was never added for pre-nv50 chipsets, so make
sure we don't allow it to be forced on. Additionally, print a small warning
when it's not supported.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260813204803.2097176-5-lyude@redhat.com
The way we handled the nouveau.atomic module parameter before was fairly
broken, and had a number of issues:
- It was only ever actually parsed in the case of PCI devices.
- When nouveau.atomic was enabled, it would add the cap for atomic
modesetting to the global driver_pci structure. This meant that if one
GPU on a system supported atomic and another didn't, it would still get
enabled for both.
Looking into this exposed further silliness in the way that we actually
handle the drm_driver struct. We have one global structure for platform
devices, and another for PCI devices - both of which are literally
identical.
So before we start preparing to enable atomic modesetting by default, let's
fix this. Instead of sharing driver_pci and driver_platform, we instead
create driver_legacy_kms and driver_atomic_kms, each of which is identical
except for the DRIVER_ATOMIC capabilities flag, and then assign either
depending on the nouveau_atomic module parameter.
Doing this is also preferable, as the next step for enabling atomic
modesetting by default will be ensuring that we don't enable it for legacy
devices that still don't support it. This requires only checking the atomic
modesetting module parameter after the NVKM device is ready, as this allows
us to check the GPU family that nouveau is running on.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260813204803.2097176-4-lyude@redhat.com
Seems like we never remembered to start printing the value for this, so
let's start to aid in troubleshooting in case we run into any issues with
atomic.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260813204803.2097176-3-lyude@redhat.com
Sashiko caught this while reviewing the patches for enabling atomic by
default - if we fail to allocate the DRM device pointer, we'll attempt to
free the error pointer that it returns rather than the actual struct.
Let's fix this while we're at it.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260813204803.2097176-2-lyude@redhat.com
create_sgt() receives the BO size as a u64 but stores the number of
pages in an int. qaic_create_bo_ioctl() page-aligns the user-supplied
size without an upper bound, so DIV_ROUND_UP(size, PAGE_SIZE) can exceed
INT_MAX and truncate when assigned to nr_pages.
When the page count wraps to a small positive value (for example a BO
larger than 16 TiB on a 4 KiB page kernel), create_sgt() succeeds after
allocating only a handful of pages while the GEM object still records
the full size, so the request never fails with -ENOMEM. The temporary
pages array and the allocation loop both use the truncated count, so the
backing SG table ends up smaller than obj->size. Later slice operations
validate against obj->size and then clone ranges from this short sgt.
Compute the page count as a u64 and reject sizes that do not fit in
nr_pages before the narrowing conversion.
Fixes: ff13be8303 ("accel/qaic: Add datapath")
Assisted-by: Claude:claude-fable-5
Signed-off-by: Hao-Qun Huang <alvinhuang0603@gmail.com>
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260708031959.966009-1-alvinhuang0603@gmail.com
qaic_ssr.c uses mhi_device_id implicitly. Include <linux/device-id/mhi.h>.
Fixes: 9675093ace ("accel/qaic: Implement basic SSR handling")
Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>
Reviewd-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260727173326.2219191-6-youssef.abdulrahman@oss.qualcomm.com
qaic_drv.c uses mhi_device_id implicitly. Include <linux/device-id/mhi.h>.
Fixes: c501ca23a6 ("accel/qaic: Add uapi and core driver file")
Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>
Reviewd-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260727173326.2219191-3-youssef.abdulrahman@oss.qualcomm.com
qaic_timesync.c and sahara.c use struct mhi_device_id implicitly since
commit 995832b2ce ("Replace <linux/mod_devicetable.h> by more specific
<linux/device-id/*.h> (c files)") removed <linux/mod_devicetable.h>.
Explicitly include <linux/device-id/mhi.h> in qaic_timesync.c and sahara.c.
Fixes: 995832b2ce ("Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)")
Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260727173326.2219191-2-youssef.abdulrahman@oss.qualcomm.com
The mipi_dsi_dcs_*() functions used by this driver are deprecated
in favour of their _multi() counterparts, as noted in
Documentation/gpu/todo.rst. The _multi() variants record the
first error in a context structure and skip subsequent calls once
an error is set, removing the need to check the return value
after each command. They also log failures internally, making the
per-call dev_err() calls redundant.
Convert prepare(), enable(), disable(), and unprepare() to use
mipi_dsi_dcs_*_multi().
unprepare() previously returned an error if
mipi_dsi_dcs_enter_sleep_mode() failed, skipping RESET assertion
and regulator_disable(). Because drm_panel_unprepare() does not
clear panel->prepared when the callback returns an error,
drm_panel_prepare() would then return early on the next call,
leaving the panel powered and unable to be re-initialised. The
converted code always asserts RESET, disables the regulator, and
returns 0.
Also fix a typo in a comment ("Enabe" -> "Enable").
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260810-mipi-dsi-s6d16d0-multi-v2-1-8fcdfbf9bbd2@gmail.com
Initialise the SCDC debugfs file for connectors that call the HDMI state
helper's debugfs_init helper. This makes all connectors that use the
helper expose the scdc_status file in their connector debugfs.
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Link: https://patch.msgid.link/20260724-scdc-link-health-v9-5-bdda406d016d@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
The HDMI debugfs files are only useful for connectors that already make
use of the HDMI state helpers. In addition, relying on HDMI-specific
functions in drm_debugfs.c can lead to circular linking problems later
down the line.
Move hdmi_debugfs_add() and friends to a new helper in
drm_hdmi_state_helper.c, and make all current users (vc4, sun4i, bridge)
either use it as a debugfs_init func, or call it directly in its
debugfs_init func.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Link: https://patch.msgid.link/20260724-scdc-link-health-v9-4-bdda406d016d@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
HDMI 2.1 redefines previously reserved fields in SCDC for various new
uses. No version check needs to be performed, as an HDMI 2.0 sink's
reserved SCDC fields are well-defined to be 0, and any zero-ness of
these fields for an HDMI 2.0 sink is not a surprise for SCDC parsers for
HDMI 2.1.
Implement reading and outputting these fields over debugfs.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Link: https://patch.msgid.link/20260724-scdc-link-health-v9-3-bdda406d016d@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
SCDC provides status information on the current display link. At the
very least, it may be useful to expose this info through debugfs.
Add a debugfs entry for it under the connector, which displays a few
more details parsed out of the SCDC registers. A new
drm_scdc_debugfs_init function can be called by the connector
implementation to initialise the debugfs file.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Link: https://patch.msgid.link/20260724-scdc-link-health-v9-2-bdda406d016d@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
drm_scdc_read and drm_scdc_write, both of which are only used within
drm_scdc_helper (although exported), use a ssize_t as their return type.
This would make sense if they returned the number of bytes read/written
on success, and negative errno otherwise. However, they return 0 on
success.
Demote them to "int" as their return type, in order to avoid needlessly
using 64 bits when less suffices.
No functional change.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Link: https://patch.msgid.link/20260724-scdc-link-health-v9-1-bdda406d016d@collabora.com
Signed-off-by: Daniel Stone <daniels@collabora.com>
drm_log_draw_new_line() calls drm_log_clear_line() and
drm_log_draw_line(), which independently call
drm_client_buffer_vmap_local(), drm_client_buffer_vunmap_local(),
and drm_client_buffer_flush(). For each call to
drm_log_draw_new_line(), this results in 2 vmap/vunmap pairs and
2 flush calls, even though vmap_local maps the entire framebuffer
each time.
Refactor drm_log_clear_line() and drm_log_draw_line() to accept a
pre-mapped iosys_map by value, removing the per-line vmap/vunmap/flush
calls. Move the single vmap/vunmap pair and flush up to
drm_log_draw_new_line(), which now maps once before clearing and
drawing, then issues a single flush after unmapping.
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn>
Link: https://patch.msgid.link/20260729084823.693723-1-oushixiong1025@163.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Simplify error condition logic in lvds device tree property parsing. It
makes it easier to add extra properties without handling complex goto
entries.
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
Link: https://patch.msgid.link/20260728122032.692482-2-wojciech.dubowik@mt.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
