similar to: [PATCH v2] drm/nouveau: wait for vblank on page flipping

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

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

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

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Replace the legacy drm_send_vblank_event() with the new helper function. v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner) Cc: Mario Kleiner <mario.kleiner.de at gmail.com> Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/nouveau/nouveau_display.c | 19

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Replace the legacy drm_send_vblank_event() with the new helper function. v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner) Cc: Mario Kleiner <mario.kleiner.de at gmail.com> Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/nouveau/nouveau_display.c | 19

From: Gustavo Padovan <gustavo.padovan at collabora.co.uk> Replace the legacy drm_send_vblank_event() with the new helper function. v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner) Cc: Mario Kleiner <mario.kleiner.de at gmail.com> Signed-off-by: Gustavo Padovan <gustavo.padovan at collabora.co.uk> --- drivers/gpu/drm/nouveau/nouveau_display.c | 19

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

Just updated versions of the patches send by Mario Kleiner. This ones are rebased on top of the nouveau tree and updated according to the review feedback. Regards, Lucas

This patch implements the drivers hooks needed for precise vblank timestamping. This is a complementary patch to Mario Kleiner's patches to to improve swap scheduling. With the complete patchset applied nouveau will be able to provide correct and precise pageflip timestamps (compliant to OML_sync_control spec) Kudos to Mario for his many helpful comments and testing. Signed-off-by: Lucas

Hi, these are two patches against the nouveau kms driver. The first patch makes sure that pageflip completion events get their vblank count and timestamp from the drm. The second patch from Lucas Stach, here included with his permission, makes sure that the timestamps of vblanks are calculated with high precision and robustness. Both patches together make sure that all timestamps returned by the

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

Not holding the mutex potentially causes corruption of the kernel channel when page flipping. Cc: stable at vger.kernel.org #3.13 Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 29c3efdfc7dd..76e3cf025c10 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c

Allow the software channel to be created now, since methods for vblanking have been implemented. The instmem flush seems to be needed on fermi to prevent a race, but I enabled it on earlier cards too since they seem to be susceptible to the same race. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 9 ----

https://bugs.freedesktop.org/show_bug.cgi?id=74613 Priority: medium Bug ID: 74613 Assignee: nouveau at lists.freedesktop.org Summary: [v3.14-rc1] [nv34] nouveau: get 0x10000000 put 0x0000ed30 state 0xc0000000 (err: MEM_FAULT) push 0x00000000 QA Contact: xorg-team at lists.x.org Severity: normal

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

Dropping Tegra ML, it's not the place where Nouveau mails should go. Adding Nouveau ML and Maarten, who probably knows Lockdep+Nouveau best. Am Montag, den 04.03.2013, 22:16 +0100 schrieb Borislav Petkov: > New -rc1, so let the stabilization games begin. > > I see the following on rc1, let me know if you need more info. > > > [ 0.633617]

Op 15-07-13 08:05, Ben Skeggs schreef: > On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >> VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to >> get real-time 1080p decoding. It prevents a lot of

This will allow the nouveau module to only include support for nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination). Only compiling one of the card types at a time reduces the size of the nouveau module, from 1.3M to 700-800K, depending on the type (including symbols/etc). It should also yield a reduction in compile time as a lot fewer files are compiled. Here are the sizes

Op 04-09-13 03:24, Ben Skeggs schreef: > On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> Op 15-07-13 08:05, Ben Skeggs schreef: >>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst >>> <maarten.lankhorst at canonical.com> wrote: >>>> I have no idea what this bogus restriction on placement