search for: mode_changed

...s attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: * DP-4 crtc=#1→NULL (VCPI n→0) * DP-5 crtc=NULL→#1 * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5 * CRTC #1 maintains the same mode as before, just with a different connector * mode_changed=n connectors_changed=y (we _SHOULD_ do VCPI 0→n here, but don't) Once the above scenario is repeated once, we'll attempt freeing VCPI from the connector that we didn't allocate due to the connectors changing, but the mode staying the same. Sigh. Since nv50_msto_atomic_check() has br...

...s attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: * DP-4 crtc=#1→NULL (VCPI n→0) * DP-5 crtc=NULL→#1 * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5 * CRTC #1 maintains the same mode as before, just with a different connector * mode_changed=n connectors_changed=y (we _SHOULD_ do VCPI 0→n here, but don't) Once the above scenario is repeated once, we'll attempt freeing VCPI from the connector that we didn't allocate due to the connectors changing, but the mode staying the same. Sigh. Since nv50_msto_atomic_check() has br...

...from DP-4 to DP-5, causing: > > * DP-4 crtc=#1→NULL (VCPI n→0) > > * DP-5 crtc=NULL→#1 > > * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5 > > * CRTC #1 maintains the same mode as before, just with a different > > connector > > * mode_changed=n connectors_changed=y > > (we _SHOULD_ do VCPI 0→n here, but don't) > > > > Once the above scenario is repeated once, we'll attempt freeing VCPI > > from the connector that we didn't allocate due to the connectors > > changing, but the mode staying the...

...ve=n > * CRTC #1 is changed from DP-4 to DP-5, causing: > * DP-4 crtc=#1→NULL (VCPI n→0) > * DP-5 crtc=NULL→#1 > * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5 > * CRTC #1 maintains the same mode as before, just with a different > connector > * mode_changed=n connectors_changed=y > (we _SHOULD_ do VCPI 0→n here, but don't) > > Once the above scenario is repeated once, we'll attempt freeing VCPI > from the connector that we didn't allocate due to the connectors > changing, but the mode staying the same. Sigh. > > Sin...

Since nv50_outp_atomic_check_view() can set crtc_state->mode_changed, we probably should be calling it before handling any PBN changes. Just a precaution. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Daniel Vetter <daniel.vette...

...ce 4c395c0c51b1f88d ]--- [drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for [MST PORT:00000000e288eb7d] found in mst state 000000008e642070 So, fix this by doing what we probably should have done from the start: only call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so that VCPI allocations remain for as long as the CRTC is enabled. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") Cc: Lyude Paul <lyude at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> C...

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

...c347ddbe..8efb778a3b207 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/head.c +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c @@ -306,7 +306,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state) asyh->set.or = head->func->or != NULL; } - if (asyh->state.mode_changed) + if (asyh->state.mode_changed || asyh->state.connectors_changed) nv50_head_atomic_check_mode(head, asyh); if (asyh->state.color_mgmt_changed || -- 2.20.1

...bce5b351..4f0b254ebabf2 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/head.c +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c @@ -306,7 +306,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state) asyh->set.or = head->func->or != NULL; } - if (asyh->state.mode_changed) + if (asyh->state.mode_changed || asyh->state.connectors_changed) nv50_head_atomic_check_mode(head, asyh); if (asyh->state.color_mgmt_changed || -- 2.20.1

...53797968..d81a99bb2ac31 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/head.c +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c @@ -306,7 +306,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state) asyh->set.or = head->func->or != NULL; } - if (asyh->state.mode_changed) + if (asyh->state.mode_changed || asyh->state.connectors_changed) nv50_head_atomic_check_mode(head, asyh); if (asyh->state.color_mgmt_changed || -- 2.20.1

...= max_rate) + break; + + asyh->or.bpc -= 2; + } + break; + default: + break; + } +} + static int nv50_outp_atomic_check(struct drm_encoder *encoder, struct drm_crtc_state *crtc_state, @@ -381,6 +410,9 @@ nv50_outp_atomic_check(struct drm_encoder *encoder, if (crtc_state->mode_changed || crtc_state->connectors_changed) asyh->or.bpc = connector->display_info.bpc; + /* We might have to reduce the bpc */ + nv50_outp_atomic_fix_depth(encoder, crtc_state); + return 0; } diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index e...

...n_mode(crtc_state->adjusted_mode.clock, bpp); + mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, + bpp); - slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn); - if (slots < 0) - return slots; + if (crtc_state->connectors_changed || crtc_state->mode_changed) { + slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr, + mstc->port, mstc->pbn); + if (slots < 0) + return slots; + } return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state, mstc->native); @@ -934,12 +940,42 @@ nv50_mstc_get_modes(st...

Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Fixes: f530bc60a30b ("drm/nouveau/disp: move HDMI config into acquire + infoframe methods") Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/gt215.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

...truct nouveau_connector *nv_connector = nouveau_connector(connector); + struct nv50_head_atom *asyh = nv50_head_atom(crtc_state); + int ret; + + ret = nv50_outp_atomic_check_view(encoder, crtc_state, conn_state, + nv_connector->native_mode); + if (ret) + return ret; + + if (crtc_state->mode_changed || crtc_state->connectors_changed) + asyh->or.bpc = connector->display_info.bpc; + + return 0; } /****************************************************************************** @@ -786,10 +796,10 @@ nv50_msto_atomic_check(struct drm_encoder *encoder, * may have changed after the st...

...s to @port, replacing any previous VCPI allocations it + * may have had. Any atomic drivers which support MST must call this function + * in their &drm_encoder_helper_funcs.atomic_check() callback to change the + * current VCPI allocation for the new state, but only when + * &drm_crtc_state.mode_changed or &drm_crtc_state.connectors_changed is set + * to ensure compatibility with userspace applications that still use the + * legacy modesetting UAPI. + * + * Allocations set by this function are not checked against the bandwidth + * restraints of @mgr until the driver calls drm_dp_mst_atomic_che...

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

...g any previous VCPI allocations it > + * may have had. Any atomic drivers which support MST must call this function > + * in their &drm_encoder_helper_funcs.atomic_check() callback to change the > + * current VCPI allocation for the new state, but only when > + * &drm_crtc_state.mode_changed or &drm_crtc_state.connectors_changed is set > + * to ensure compatibility with userspace applications that still use the > + * legacy modesetting UAPI. > + * > + * Allocations set by this function are not checked against the bandwidth > + * restraints of @mgr until the driver ca...

...s to @port, replacing any previous VCPI allocations it + * may have had. Any atomic drivers which support MST must call this function + * in their &drm_encoder_helper_funcs.atomic_check() callback to change the + * current VCPI allocation for the new state, but only when + * &drm_crtc_state.mode_changed or &drm_crtc_state.connectors_changed is set + * to ensure compatibility with userspace applications that still use the + * legacy modesetting UAPI. + * + * Allocations set by this function are not checked against the bandwidth + * restraints of @mgr until the driver calls drm_dp_mst_atomic_che...

...s.atomic_check() callback > > > > > > > to > > > > > > > change > > > > > > > the > > > > > > > + * current VCPI allocation for the new state, but only when > > > > > > > + * &drm_crtc_state.mode_changed or > > > > > > > &drm_crtc_state.connectors_changed > > > > > > > is set > > > > > > > + * to ensure compatibility with userspace applications that > > > > > > > still > > > > > > > use >...

...function > > > > > + * in their &drm_encoder_helper_funcs.atomic_check() callback to > > > > > change > > > > > the > > > > > + * current VCPI allocation for the new state, but only when > > > > > + * &drm_crtc_state.mode_changed or > > > > > &drm_crtc_state.connectors_changed > > > > > is set > > > > > + * to ensure compatibility with userspace applications that still > > > > > use > > > > > the > > > > > + * legacy modesetting UA...