similar to: [PATCH 1/2] drm/nouveau: hold mutex while syncing to kernel channel

Seems to make suspend slightly more reliable on my system. Cc: stable at vger.kernel.org [3.7+] Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b6bdc9f..5032c31 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -464,6

Hey Mario, It seems that your ddx commit b4231dd715a8 is causing a regression when I use mplayer -vo vdpau rendering with mesa 9.1. It fails to start drawing here, leaving the mplayer screen black, I can make it recover usually by seeking or moving another window in front. When I revert the commit it behaves normally. Changing can_sync_to_vblank(draw) to 0 in nouveau_dri2_schedule_swap also fixes

It's questionable use case, but weston/wayland already relies on this behaviour, and other drivers don't care about it, so it's a matter of compatibility. Without it, process invoking such page flip hangs in unkillable state, trying to reserve the same buffer twice. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 20

From: Thierry Reding <treding at nvidia.com> This small series of patches implements support for waiting on and emitting fence FDs on kickoff. This enables explicit fencing and can be used for example to synchronize buffer accesses between the display engine and the GPU on Tegra. The first patch lays the groundwork by splitting up nouveau_fence_sync() to allow reuse. Patch 2 is where the

From: Thierry Reding <treding at nvidia.com> Hi, This series implements a new IOCTL to submit push buffers that can optionally return a sync FD or sync object to userspace. This is useful in cases where userspace wants to synchronize operations between the GPU and another driver (such as KMS for display). Among other things this allows extensions such as eglDupNativeFenceFDANDROID to be

This is a bit messed up because chan->cli->mutex is a different class, depending on whether it is the global drm client or not. This is because the global cli->mutex lock can be taken for eviction, so locking it before pinning the buffer objects may result in a deadlock. The locking order from outer to inner is: - &cli->mutex - ttm_bo - &drm_client_lock (global

The ffsll function is a lot slower than the __ffs64 built-in which compiles to a single instruction on 64-bit. It's also nice to avoid custom versions of standard functions. Note that __ffs == ffs - 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I wrote a user-space program to test these out and make sure that the functions behaved as expected. The logic in abi16 had to be

This will ensure we always hold the required lock when calling those functions. --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 ++ drivers/gpu/drm/nouveau/nouveau_display.c | 17 +++++++++++++---- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index b6dc85c614be..33eb7164525a 100644 ---

This patch set replaces the occurrences of drm_*_reference() and drm_*_unreference() with the new drm_*_get() and drm_*_put() functions. All patches in the series do the same thing, converting to the new APIs. I created patches per DRM driver as suggested by Daniel Vetter. Background: In the kernel, reference counting APIs use *_get(), *_put() style naming to reference-count the objects. But DRM

This patch set replaces functions named {un,reference} by their {put,get} counterparts. Affected data types are struct drm_connector, struct drm_framebuffer, struct drm_gem_object, and struct drm_device. With the reference-counting functions being named {put,get}, the DRM interface is more aligned to Linux kernel nameing standard. The patch set does not change driver-internal interfaces. Thomas

Reduces object size ~4kb Joe Perches (2): drm/nouveau: Add new logging function nv_cli_printk drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_<level> macros drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 12 +++---- drivers/gpu/drm/nouveau/nouveau_drm.c | 21 +++++++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 44

nouveau_abi16_ioctl_channel_alloc() and nouveau_cli_init() simply call their corresponding *_fini() counterpart. This can lead to nouveau_sched_fini() being called without struct nouveau_sched ever being initialized in the first place. Instead of embedding struct nouveau_sched into struct nouveau_cli and struct nouveau_chan_abi16, allocate struct nouveau_sched separately, such that we can check

Commit "drm/nouveau: port all engines to new engine module format" changed IB size calculation to be less wasteful, but didn't take into account already existing off-by-one bugs :). So: - ib_max is the last entry, so we need to +1 when calculating number of free entries - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1 on nouveau_gem_ioctl_pushbuf

Revised patch set v2. [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c [PATCH 2/8] drm/nouveau: use bo accessors for push buffers [PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops [PATCH 4/8] drm/nv50: proper notifier_bo access in nv50_display_vblank_crtc_handler() [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors [PATCH 6/8] drm/nouveau: screen_base and

Introduce accessors for TTM buffer object memory that has been mapped into the kernel virtual address space or as IO memory. IO memory needs to be accessed via special accessor functions, not by dereferencing the iomem cookie. The wrappers hide the details of 32-bit access and honour the TTM map type. nv04_crtc_cursor_set() is changed to use the new wrappers. 'cursor' is received from

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index

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

https://bugs.freedesktop.org/show_bug.cgi?id=58087 Priority: medium Bug ID: 58087 Assignee: nouveau at lists.freedesktop.org Summary: [-next] nouveau corrupts kernel mm allocator QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: peter at

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Replace the legacy drm_send_vblank_event(), drm_arm_vblank_event() and drm_vblank_{get,put}() with the new helper functions. v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner) Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Signed-off-by: Gustavo Padovan <gustavo.padovan at

The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new()