similar to: 3.12 nvidia switcheroo regression

nouveau_event_put_locked() only has 1 call site; fold into caller. Signed-off-by: Peter Hurley <peter at hurleysoftware.com> --- drivers/gpu/drm/nouveau/core/core/event.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/core/event.c b/drivers/gpu/drm/nouveau/core/core/event.c index ce0a0ef..45bcb37 100644 ---

On 08/12/2013 07:50 AM, Maarten Lankhorst wrote: > This fixes a deadlock inversion when vblank is enabled/disabled by drm. > &dev->vblank_time_lock is always taken when the vblank state is toggled, > which caused a deadlock when &event->lock was also taken during > event_get/put. > > Solve the race by requiring that lock to change enable/disable state, > and

Complete migration of nouveau_event_get/_put from add/remove semantics to enable/disable semantics. Introduce nouveau_event_handler_install/_remove interface to add/remove non-local-scope event handlers (ie., those stored in parent containers). This change in semantics makes explicit the handler lifetime, and distinguishes "one-of" event handlers (such as gpio) from "many

This fixes a deadlock inversion when vblank is enabled/disabled by drm. &dev->vblank_time_lock is always taken when the vblank state is toggled, which caused a deadlock when &event->lock was also taken during event_get/put. Solve the race by requiring that lock to change enable/disable state, and always keeping vblank on the event list. Core drm ignores unwanted vblanks, so extra

Prepare for transition to RCU-based event handler list; since RCU list traversal may have stale pointers, local storage may go out of scope before handler completes. Introduce nouveau_event_handler_create/_destroy which provides suitable semantics for multiple, temporary event handlers. Signed-off-by: Peter Hurley <peter at hurleysoftware.com> --- drivers/gpu/drm/nouveau/core/core/event.c

Most nouveau event handlers have storage in 'static' containers (structures with lifetimes nearly equivalent to the drm_device), but are dangerously reused via nouveau_event_get/_put. For example, if nouveau_event_get is called more than once for a given handler, the event handler list will be corrupted. Migrate nouveau_event_get/_put from add/remove semantics to enable/disable semantics.

On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley <peter at hurleysoftware.com> wrote: > This series was originally motivated by a deadlock, introduced in > commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b > 'drm/nouveau/disp: port vblank handling to event interface', > due to inverted lock order between nouveau_drm_vblank_enable() > and nouveau_drm_vblank_handler() (the

Lockdep report [1] correctly identifies a potential deadlock between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due to inverted lock order of event->lock with drm core's dev->vblank_time_lock. Fix vblank event deadlock by converting event handler list to RCU. List updates remain serialized by event->lock. List traversal & handler execution is lockless which

This series was originally motivated by a deadlock, introduced in commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b 'drm/nouveau/disp: port vblank handling to event interface', due to inverted lock order between nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() (the complete lockdep report is included in the patch 4/5 changelog). Because this series fixes the vblank event

After switcherooing to integrated and starting X, when X fails to start and causes a console switch, we get hit with a hanger (below). Fix by checking if we're already in D3. BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1703] [<ffffffffa037c538>] nv04_timer_read+0x28/0x70 [nouveau] [<ffffffffa037bfec>] nouveau_timer_wait_eq+0x7c/0xe0 [nouveau] [<ffffffffa03f4f4e>]

Replace the call to drm_fb_helper_output_poll_changed() with a call to drm_client_dev_hotplug(). It is equivalent in functionality, but uses the DRM client infrastructure. v2: - fix commit description Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++- 1 file changed, 2

On 8/12/24 10:28 AM, Thomas Zimmermann wrote: > Replace the call to drm_fb_helper_output_poll_changed() with a call > to drm_client_dev_hotplug(). It is equivalent in functionality, but > uses the DRM client infrastructure. > > v2: > - fix commit description > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > Reviewed-by: Daniel Vetter

Hi Am 12.08.24 um 14:17 schrieb Danilo Krummrich: > On 8/12/24 10:28 AM, Thomas Zimmermann wrote: >> Replace the call to drm_fb_helper_output_poll_changed() with a call >> to drm_client_dev_hotplug(). It is equivalent in functionality, but >> uses the DRM client infrastructure. >> >> v2: >> - fix commit description >> >> Signed-off-by: Thomas

While working on a vga_switcheroo handler for Apple's Macbook Pros I stumbled upon a few bugs regarding the usage of nouveau with other switcheroo handlers and module unloading, here are my fixes for them. Andreas Heider (3): drm/nouveau: Initialize has_optimus drm/nouveau: Check dsm on switcheroo unregister drm/nouveau: Unregister switcheroo client on exit

Op 24-07-13 09:13, Dave Airlie schreef: > After a full device powerdown via the optimus power switch, we seem > to lose the HDMI device completely on power on, this keep track of > whether we had a hdmi audio sub function device at power on, and > pokes a magic register to make it reappear after the optimus power > switch is thrown. > > This at least works on my NVC4 machine,

On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > their lastclose callbacks. Call it from drm_lastclose(), so that the > driver functions can finally be removed. Only PCI devices with enabled > switcheroo do the delayed switching. The call has no effect on other > hardware. > > v2: >

Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from their lastclose callbacks. Call it from drm_lastclose(), so that the driver functions can finally be removed. Only PCI devices with enabled switcheroo do the delayed switching. The call has no effect on other hardware. v2: - move change to drm_lastclose() (Sima) - update docs for vga_switcheroo_process_delayed_switch()

https://bugs.freedesktop.org/show_bug.cgi?id=70895 Priority: medium Bug ID: 70895 Assignee: nouveau at lists.freedesktop.org Summary: BUG: soft lockup - CPU#0 stuck for 22s! [Xorg:1292] after disable descrete card with switcheroo QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified

On Mon, Aug 12, 2024 at 11:23:44AM +0200, Daniel Vetter wrote: > On Mon, Aug 12, 2024 at 10:28:22AM +0200, Thomas Zimmermann wrote: > > Amdgpu and nouveau call vga_switcheroo_process_delayed_switch() from > > their lastclose callbacks. Call it from drm_lastclose(), so that the > > driver functions can finally be removed. Only PCI devices with enabled > > switcheroo do

https://bugs.freedesktop.org/show_bug.cgi?id=61765 Priority: medium Bug ID: 61765 Assignee: nouveau at lists.freedesktop.org Summary: Regression: null pointer dereference on reboot after switcheroo use QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux