similar to: [PATCH] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes

I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: *

On Thu, 2019-08-08 at 18:17 +0000, William Lewis wrote: > On 8/8/19 1:04 PM, Lyude Paul wrote: > > I -thought- I had fixed this entirely, but it looks like that I didn't > > test this thoroughly enough as we apparently still make one big mistake > > with nv50_msto_atomic_check() - we don't handle the following scenario: > > > > * CRTC #1 has n VCPI

Realized when I moved nouveau over to using the atomic DP MST VCPI helpers that I forgot to ensure that we clamp the BPC to 8 to make us less likely to run out of bandwidth on a topology when enabling multiple displays that support >8 BPC - something we want to do until we have support for dynamically selecting the bpc based on the topology's available bandwidth, since userspace isn't

Looks like a regression got introduced into nv50_mstc_atomic_check() that somehow didn't get found until now. If userspace changes crtc_state->active to false but leaves the CRTC enabled, we end up calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in asyh->dp.pbn. However, if the display is inactive we end up calculating a PBN of 0, which inadvertently causes us to have an

On 8/8/19 1:04 PM, Lyude Paul wrote: > I -thought- I had fixed this entirely, but it looks like that I didn't > test this thoroughly enough as we apparently still make one big mistake > with nv50_msto_atomic_check() - we don't handle the following scenario: > > * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 > which is attached to encoder #1.

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 <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

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 <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. [sorry for still not adding your R-Bs! I ended up needing to make a lot of changes to make it so we do actually kref() each port in the atomic state] Cc: Daniel

With DSC, bpp can be fractional in multiples of 1/16. Change drm_dp_calc_pbn_mode to reflect this, adding a new parameter bool dsc. When this parameter is true, treat the bpp parameter as having units not of bits per pixel, but 1/16 of a bit per pixel v2: Don't add separate function for this Cc: amd-gfx at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc: intel-gfx at

On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > There has been a TODO waiting for quite a long time in > drm_dp_mst_topology.c: > > /* We cannot rely on port->vcpi.num_slots to update > * topology_state->avail_slots as the port may not exist if the parent > * branch device was unplugged. This should be fixed by tracking > * per-port slot allocation

On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote: > On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote: > > On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote: > > > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote: > > > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > > > > > There has been a TODO waiting

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote: > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote: > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote: > > > There has been a TODO waiting for quite a long time in > > > drm_dp_mst_topology.c: > > > > > > /* We cannot rely on port->vcpi.num_slots to update > >

[sorry about the resend-copy pasted the wrong header and I want to make sure this doesn't get missed!] This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (5): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream implementation requires a

On Wed, 2018-11-28 at 09:17 +0100, Daniel Vetter wrote: > On Tue, Nov 27, 2018 at 08:44:14PM -0500, Lyude Paul wrote: > > On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote: > > > > We could do this the other way around so it looks like this maybe > > > > struct kref; /* manages kfree() */ > > struct topology_kref; /* corresonds to lifetime in topology

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (5): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually

This is a WIP version of the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting works so that it actually makes sense, since the current upstream