similar to: [PATCH] drm/nouveau: set irq_enabled manually

On Thu, Jan 30, 2014 at 3:33 AM, Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jan 30, 2014 at 1:53 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup >> ourselves"), drm_device->irq_enabled remained unset. This is needed in >> order to properly wait for a vblank event in the

https://bugs.freedesktop.org/show_bug.cgi?id=74195 Priority: medium Bug ID: 74195 Assignee: nouveau at lists.freedesktop.org Summary: Responsivity to input with vsync on is slower after update QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All)

On Thu, Jan 30, 2014 at 1:53 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Since commit 0fa9061ae8c ("drm/nouveau/mc: handle irq-related setup > ourselves"), drm_device->irq_enabled remained unset. This is needed in > order to properly wait for a vblank event in the generic drm code. > > See https://bugs.freedesktop.org/show_bug.cgi?id=74195 > >

https://bugs.freedesktop.org/show_bug.cgi?id=83021 Priority: medium Bug ID: 83021 Assignee: nouveau at lists.freedesktop.org Summary: Separate X screens --> Xvideo is vsynced to primary screen only QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux

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

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

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

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before the rework to event interface, so I guess it got reintroduced. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c b/drivers/gpu/drm/nouveau/core/engine/disp/nv50.c index 7e3875d..35e526b 100644 ---

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efault at gmx.de> wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not > >>

Please find below an automated bisection report for a kernel Oops seen during the initialisation of the nouveau GPU driver on jetson-tk1. All the LAVA test jobs for this bisection can be found here: http://lava.baylibre.com:10080/scheduler/alljobs?length=25&search=lava-bisect-staging-7366#table Here's the beginning of the Oops stack trace: [ 7.485361] [00000064] *pgd=f9e7b835 [

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

VBLANK handlers in struct drm_driver are deprecated. Only legacy, non-KMS drivers are supposed to used them. DRM drivers with kernel modesetting are supposed to use VBLANK callbacks of the CRTC infrastructure. This patchset converts all DRM drivers to CRTC VBLANK callbacks and cleans up struct drm_driver. The remaining VBLANK callbacks in struct drm_driver are only used by legacy drivers. Patch

This series is intended to add support for shutting down the GPU on kernel shutdown/reboot using the ->shutdown() hook, similar to what amdgpu does. This is mainly intended to workaround a bios issue on the P50 that was preventing nouveau from initializing the dedicated GM107 GPU on that system properly. You can find more details on this issue in the patch labeled "Shut down GPU on kernel

Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests that we'll be sending in just a short bit. This additionally adds a feature that Ville Syrj?l? came up with: vblank works. Basically, this is just a generic DRM

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.

This series fixes a number of use-after-frees in nouveau's postclose() handler. It was discovered by pointing IGT's core_hotunplug tests at a nouveau device, but the steps to reproduce it are simple: 1. Open the device file 2. Unbind the driver or remove the device 3. Close the file opened in step 1. During the device removal, the nouveau_drm structure is de-allocated, but is