similar to: [PATCH 1/8] drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

No functional changes, just change the function names to match the callbacks they provide. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 33 ++++++++++++------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index

Noticed these in both the disable (which we'll be getting rid of in a moment) and the atomic disable callbacks: both callback types check whether or not there's actually a CRTC assigned to the given encoder. However, as ->atomic_disable and ->disable will never be called without a CRTC assigned to the given encoder there's no point in this check. So just remove it.

drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable: drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning: variable nv_connector set but not used [-Wunused-but-set-variable] commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom") left behind this. Reported-by: Hulk Robot <hulkci at huawei.com> Signed-off-by: YueHaibing

In order to be able to use bpc values that are different from what the connector reports, we want to be able to store the bpc value we decide on using for an atomic state in nv50_head_atom and refer to that instead of simply using the value that the connector reports throughout the whole atomic check phase and commit phase. This will let us (eventually) implement the max bpc connector property,

nv50_msto_disable() does not call nv50_outp_release() to match nv50_outp_acquire() like other disable(). Add the missed call to fix it. Signed-off-by: Chuhong Yuan <hslester96 at gmail.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index

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

Hi Ben, I was looking into some of the LUT-related modesetting issues. I've noticed the following... after I load nouveau, one of my secondary GPUs shows this on first modeset (with drm.debug=4): [ 2368.081307] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:44:DVI-I-1] [ 2368.113148] [drm:drm_add_display_info [drm]] non_desktop set to 0 [ 2368.113183]

[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: f479c0ba4a17

From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 39496368ba96b40b1dca07315418e473998eef15 ] drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable: drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning: variable nv_connector set but not used [-Wunused-but-set-variable] commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the bpc we're using in

From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 39496368ba96b40b1dca07315418e473998eef15 ] drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable: drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning: variable nv_connector set but not used [-Wunused-but-set-variable] commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the bpc we're using in

nv50_msto_disable() does not call nv50_outp_release() to match nv50_outp_acquire() like other disable(). Add the missed call to fix it. Signed-off-by: Chuhong Yuan <hslester96 at gmail.com> --- Changes in v2: - Fix the subject prefix. drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c

On Fri, 06 Dec 2019, Chuhong Yuan <hslester96 at gmail.com> wrote: > nv50_msto_disable() does not call nv50_outp_release() to match > nv50_outp_acquire() like other disable(). > Add the missed call to fix it. The subject prefix "drm/dp_mst" implies drm core change, but this is about nouveau. Please fix. BR, Jani. > > Signed-off-by: Chuhong Yuan <hslester96 at

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 order to ensure that when committing an artificially duplicated state (like during system

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 is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2

From: Lyude Paul <lyude at redhat.com> [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul

Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul <lyude at redhat.com> Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly? Cheers, -ilia

Same as we did for i915, but for nouveau this time. Additionally, we grab a malloc reference to the port that lasts for the entire lifetime of nv50_mstc, which gives us the guarantee that mstc->port will always point to valid memory for as long as the mstc stays around. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 +++++------------- 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()

Hi, > > > static void bochs_crtc_atomic_flush(struct drm_crtc *crtc, > > > struct drm_crtc_state *old_crtc_state) > > > { > > > @@ -66,6 +71,7 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = { > > > static const struct drm_crtc_helper_funcs bochs_helper_funcs = { > > > .mode_set_nofb = bochs_crtc_mode_set_nofb, > >