similar to: [PATCH 0/9] drm/nouveau: Cleanup event/handler design

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

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

On Tue, 2013-03-19 at 11:13 -0400, Peter Hurley wrote: > On vanilla 3.9.0-rc3, I get this 100% repeatable oops after login when > the user X session is coming up: Perhaps I wasn't clear that this happens on every boot and is a regression from 3.8 I'd be happy to help resolve this but time is of the essence; it would be a shame to have to revert all of this for 3.9 Regards, Peter

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

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

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.

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

From: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/core/event.c | 4 drivers/gpu/drm/nouveau/nouveau_bo.c | 6 drivers/gpu/drm/nouveau/nouveau_display.c | 4 drivers/gpu/drm/nouveau/nouveau_fence.c | 434 ++++++++++++++++++++---------

Provide private field for event handlers exclusive use. Convert nouveau_fence_wait_uevent() and nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent. Signed-off-by: Peter Hurley <peter at hurleysoftware.com> --- drivers/gpu/drm/nouveau/core/include/core/event.h | 1 + drivers/gpu/drm/nouveau/nouveau_fence.c | 20 +++++++------------- 2 files changed, 8

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

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- include/linux/fence.h | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index d174585b874b..c1a4519ba2f5 100644 ---

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic

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

Not as thoroughly tested as I would like. Newer nvd0 and kepler are unsupported, as I don't know the registers yet. Information of the scanout position is based on Lucas Stach's original patch, with a teak to read vline twice, to prevent a race of hline with vline. Cc: Lucas Stach <dev at lynxeye.de> Cc: Mario Kleiner <mario.kleiner at tuebingen.mpg.de> Signed-off-by: Maarten

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It's unclear to me whether GF11x devices actually support this, but the disp "split" is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't actually have DP in the first place, so it may not be a huge issue. I

https://bugs.freedesktop.org/show_bug.cgi?id=58556 Priority: medium Bug ID: 58556 Assignee: nouveau at lists.freedesktop.org Summary: MacBook Pro 5,1 with nVidia 9400m and 9600m, scrambled screen QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: other

On Tue, Mar 17, 2020 at 08:40:58PM -0400, Lyude Paul wrote: > From: Ville Syrj?l? <ville.syrjala at linux.intel.com> > > Add some kind of vblank workers. The interface is similar to regular > delayed works, and also allows for re-scheduling. > > Whatever hardware programming we do in the work must be fast > (must at least complete during the vblank, sometimes during

Oops, completely forgot to link to the work_struct version of this patch: [1] https://gitlab.freedesktop.org/lyudess/linux/-/commit/f57886aebbd9631f1ee6e61b516bf73afbfe74f4 On Fri, 2020-03-27 at 16:29 -0400, Lyude Paul wrote: > Adding Tejun to this thread per-Daniel's suggestion on IRC. > > Hi Tejun! So, I don't know what your experience with modesetting related > stuff >

This patch series sets dev->vblank_disable_immediate = true on radeon/amdgpu-kms, nouveau-kms for nv50+, and vc4 for the real kms driver (as opposed to dispmanx firmware backed kms). All the drivers should be ready in theory, given their implementation, for fast vblank disable/enable. In practice, i have performed timing tests with my measurement equipment for all those drivers with the