[Nouveau] [PATCH v3 1/4] drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we never successfully allocated VCPI to it. This is contrary to what we do in drm_dp_mst_allocate_vcpi(), where we only call drm_dp_mst_get_port_malloc() on the p

[Nouveau] [PATCH v3 0/4] drm/dp_mst: Fix regressions from new atomic VCPI helpers

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter Lyude Paul (4): drm/dp_

[Nouveau] [PATCH v3 3/4] drm/atomic: Add drm_atomic_state->duplicated

Since commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered connectors harder") We've been failing atomic checks if they try to enable new displays on unregistered connectors. This is fine except for the one situation that breaks atomic assumptions: suspend/resume. If a connector

[Nouveau] [PATCH v3 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

Atomic checks should never modify anything outside of the state that they're passed in. Unfortunately this appears to be exactly what we're doing in nv50_msto_atomic_check() where we update mstc->pbn every time the function is called. This hasn't caused any bugs yet, but it needs to be fixed in ord

[Nouveau] [PATCH v3 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

Since we now have an easy way of refcounting drm_dp_mst_port structs and safely accessing their contents, there isn't any good reason to keep validating ports here. It doesn't prevent us from performing modesets on branch devices that have been removed either, and we already disallow enabling new d

Re: [Nouveau] [PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

Important! below On Fri, 2019-02-01 at 18:57 +0100, Daniel Vetter wrote: > On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote: > > Since > > > > commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered > > connectors harder") > > > > We've been failing atomic checks if they

Re: [Nouveau] Render Targets and Pitch Linear Textures in Maxwell/Pascal Question

Miptree layout for linear textures: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nv50/nv50_miptree.c#n238 Setting for RTs: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n224 Follow the !nouveau_bo_memtype path (and

[Nouveau] Render Targets and Pitch Linear Textures in Maxwell/Pascal Question

So I have been going on over the documentation trying to figure out the exact layout of Pitch Linear Textures and find some missing values. First Question: What's the correct layout of pitch linear textures in memory? Is padding of the pitch added at start or at the end? Do they have some kind of

[Nouveau] [Bug 109529] [NV46] unable to handle kernel paging request

https://bugs.freedesktop.org/show_bug.cgi?id=109529 --- Comment #1 from dfloger...@gmail.com --- I made it lock-up using 4.19.18 with mesa-git. However, there may be two separate issues going on. This time, I did not get anything in dmesg after the event. -- You are receiving this mail because

Re: [Nouveau] [PATCH v2 3/4] drm/atomic: Add drm_atomic_state->duplicated

On Thu, Jan 31, 2019 at 08:14:50PM -0500, Lyude Paul wrote: > Since > > commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered > connectors harder") > > We've been failing atomic checks if they try to enable new displays on > unregistered connectors. This is fine except for the on

Re: [Nouveau] [PATCH v2 2/4] drm/dp_mst: Remove port validation in drm_dp_atomic_find_vcpi_slots()

On Thu, Jan 31, 2019 at 08:14:49PM -0500, Lyude Paul wrote: > Since we now have an easy way of refcounting drm_dp_mst_port structs and > safely accessing their contents, there isn't any good reason to keep > validating ports here. It doesn't prevent us from performing modesets on > branch devices t

[Nouveau] [PATCH] drm: prefix header search paths with $(srctree)/

Currently, the Kbuild core manipulates header search paths in a crazy way [1]. To fix this mess, I want all Makefiles to add explicit $(srctree)/ to the search paths in the srctree. Some Makefiles are already written in that way, but not all. The goal of this work is to make the notation consisten

Re: [Nouveau] [Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT

On Fri, Jan 25, 2019 at 03:02:46PM +, Emil Velikov wrote: > On Thu, 24 Jan 2019 at 17:00, Daniel Vetter wrote: > > > > It's 0. > > > I'd add a bit more information here. Feel free to reuse as much/little > of the following: > > Both macros evaluate to 0. At the same time flag is already set t

Re: [Nouveau] [PATCH -next] drm/nouveau: fix copy-paste error in nouveau_fence_wait_uevent_handler

Friendly ping, Ben. I see that in `nouveau_fence_done()` there is a check on `chan` not being NULL prior to passing it to `nouveau_fence_update()`. Would something similar be needed here? Pierre On 2018-11-15 — 12:14, YueHaibing wrote: > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers

[Nouveau] [Bug 109529] New: [NV46] unable to handle kernel paging request

https://bugs.freedesktop.org/show_bug.cgi?id=109529 Bug ID: 109529 Summary: [NV46] unable to handle kernel paging request Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal