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

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>]

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,

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

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=69180 Priority: medium Bug ID: 69180 Assignee: nouveau at lists.freedesktop.org Summary: Delays when using nouveau and switcheroo QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: a0vhv at t-online.de

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, probably needs testing on a few other laptops with other nvidia GPUs.

Hi, I''ve been trying to boot stefano''s minimal dom0 kernel from git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git 2.6.36-rc1-initial-domain-v2+pat On xen-unstable, I get the following WARN_ON()''s from Xen when bringing up the NIC''s, then the machine hangs forever when trying to login either over serial or NIC. (XEN) Xen WARN at msi.c:649 (XEN) ----[