similar to: [PATCH 0/2] drm/nouveau: Use more standard logging styles

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

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

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Commit de7b7d59d54852c introduced tiled GART, but a linear copy is still performed. This may result in errors on eviction, fix it by checking tiling from memtype. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> Cc: stable at vger.kernel.org #3.10+ --- drivers/gpu/drm/nouveau/nouveau_bo.c | 33

Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait") converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout(). However, dma_resv_wait_timeout() returns greater than zero on success as opposed to ttm_bo_wait_ctx(). As a result, relocs will fail and log errors even when it was a success. Change the return code handling to match that of nouveau_gem_ioctl_cpu_prep(), which was

Am 15.04.23 um 04:02 schrieb John Ogness: > Commit 41d351f29528 ("drm/nouveau: stop using ttm_bo_wait") > converted from ttm_bo_wait_ctx() to dma_resv_wait_timeout(). > However, dma_resv_wait_timeout() returns greater than zero on > success as opposed to ttm_bo_wait_ctx(). As a result, relocs > will fail and log errors even when it was a success. > > Change the

gcc-4.9 notices that the validate_init() function returns unintialized data when called with a zero 'nr_buffers' argument, when called with the -Wmaybe-uninitialized flag: drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’: drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] However, the

Hi guys, I'd like to start a new thread about explicit fence synchronization. This time with a Nouveau twist. :-) First, let me define what I understand by implicit/explicit sync: Implicit synchronization * Fences are attached to buffers * Kernel manages fences automatically based on buffer read/write access Explicit synchronization * Fences are passed around independently * Kernel takes

On Thu, 2018-09-06 at 17:43 -0400, Lyude Paul wrote: > Since we're about to use this in nouveau_backlight.c. Same thing as > DRM_WARN_ONCE, DRM_INFO_ONCE, etc... Can you redefine this in terms of the patches I submitted instead? https://lore.kernel.org/patchwork/patch/979598/ https://lore.kernel.org/patchwork/patch/979601/ > Signed-off-by: Lyude Paul <lyude at redhat.com>

A couple of new warnings and build errors appeared through the DRM tree in linux-next after the merge window opened. The first patch here is for scripts/headers_check.pl, but as the bug is only present in drm-next at the moment, it would be good to add all five patches to that tree before they make it into mainline. It's likely that some of these have already been fixed since this

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

Currently, NO_PREFETCH is passed implicitly through drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len. Since this is a direct representation of how the HW is programmed it isn't really future proof for a uAPI. Hence, fix this up for the new uAPI and split up the va_len field of struct drm_nouveau_exec_push, such that we keep 32bit for va_len and 32bit for flags. For

I was getting a order 4 allocation failure from kmalloc when testing some game after a few days uptime with some suspend/resumes. For big allocations vmalloc should be used instead. Also limit size more aggressively to 256 KiB. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++++++++++++++++++++++------- 1 file

Signed-off-by: Pekka Paalanen <pq at iki.fi> --- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index 64e59fb..75cae79 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -595,7 +595,7 @@

Refactor for Ben, hopefully this time this should apply to his tree. Next version of https://patchwork.freedesktop.org/series/48596/ No changes otherwise. Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

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

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to

Next version of https://patchwork.freedesktop.org/series/48596/ . Added NV_INFO_ONCE and made "Move backlight device into nouveau_connector" use that instead so we don't print the GMUX warning more then once. Lyude Paul (5): drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau:

Forgot to send 6 patches instead of five since there's one new one now, whoops! No actual changes, next version of https://patchwork.freedesktop.org/series/48596/ Lyude Paul (6): drm/nouveau: Check backlight IDs are >= 0, not > 0 drm/nouveau: Add NV_PRINTK_ONCE and variants drm/nouveau: Move backlight device into nouveau_connector drm/nouveau: