similar to: [PATCH] drm/nouveau: Check rc from drm_dp_mst_topology_mgr_resume()

patch is Reviewed-by: Karol Herbst <kherbst at redhat.com> @Sasha: I think we can ignore this patch for those older kernels as there is no mstm support to begin with inside Nouveau meaning you wouldn't run into that issue. On Sat, Nov 24, 2018 at 5:00 AM Sasha Levin <sashal at kernel.org> wrote: > > Hi, > > [This is an automated email] > > This commit has been

Hi, [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v4.19.2, v4.18.19, v4.14.81, v4.9.137, v4.4.163, v3.18.125. v4.19.2: Build OK! v4.18.19: Build OK! v4.14.81: Failed to apply! Possible dependencies: Unable to calculate

From: Colin Ian King <colin.king at canonical.com> The null check on the array msto is incorrect since msto is never null. The null check should be instead on msto[i] since this is being dereferenced in the call to drm_mode_connector_attach_encoder. Thanks to Emil Velikov for pointing out the mistake in my original fix and for suggesting the correct fix. Detected by CoverityScan,

Noticed this while working on redoing the reference counting scheme in the DP MST helpers. Nouveau doesn't attempt to call drm_dp_mst_topology_mgr_destroy() at all, which leaves it leaking all of the resources for drm_dp_mst_topology_mgr and it's children mstbs+ports. Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream") Signed-off-by: Lyude Paul

On 17/08/17 23:07, Ilia Mirkin wrote: > On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.king at canonical.com> wrote: >> From: Colin Ian King <colin.king at canonical.com> >> >> The null check on the array msto is incorrect since msto is never >> null. The null check should be instead on msto[i] since this is >> being dereferenced in the call to

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

[ 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

Finally! For a very long time, our MST helpers have had one very annoying issue: They don't know how to reprobe the topology state when coming out of suspend. This means that if a user has a machine connected to an MST topology and decides to suspend their machine, we lose all topology changes that happened during that period. That can be a big problem if the machine was connected to a

On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote: > Finally! For a very long time, our MST helpers have had one very > annoying issue: They don't know how to reprobe the topology state when > coming out of suspend. This means that if a user has a machine connected > to an MST topology and decides to suspend their machine, we lose all > topology changes that happened

On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.king at canonical.com> wrote: > From: Colin Ian King <colin.king at canonical.com> > > The null check on the array msto is incorrect since msto is never > null. The null check should be instead on msto[i] since this is > being dereferenced in the call to drm_mode_connector_attach_encoder. > > Thanks to Emil Velikov

On 08/18/2017 08:16 AM, Colin Ian King wrote: > On 17/08/17 23:07, Ilia Mirkin wrote: >> On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.king at canonical.com> wrote: >>> From: Colin Ian King <colin.king at canonical.com> >>> >>> The null check on the array msto is incorrect since msto is never >>> null. The null check should be instead

Hello Ben Skeggs, The patch f479c0ba4a17: "drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream" from Nov 4, 2016, leads to the following static checker warning: drivers/gpu/drm/nouveau/nv50_display.c:3158 nv50_mstc_new() warn: this array is probably non-NULL. 'mstm->msto' drivers/gpu/drm/nouveau/nv50_display.c 3155

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

Does what it says on the tin. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland <hwentlan at amd.com> Cc: Daniel Vetter <daniel.vetter at ffwll.ch> Reviewed-by: Sean Paul <sean at poorly.run> Signed-off-by: Lyude Paul <lyude at redhat.com> ---

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Manasi Navare <manasi.d.navare at

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Manasi Navare <manasi.d.navare at

This is useful for drivers (which will probably be all of them soon) which need to track state that is exclusive to the topology, and not a specific connector on said topology. This includes things such as the link rate and lane count that are shared by all of the connectors on the topology. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Manasi Navare <manasi.d.navare at

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul <lyude at redhat.com> wrote: > > Since we're going to be reprobing the entire topology state on resume > now using sideband transactions, we need to ensure that we actually have > short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume(). > So, do that. > > Cc: Juston Li <juston.li at intel.com> > Cc:

Since we're going to be reprobing the entire topology state on resume now using sideband transactions, we need to ensure that we actually have short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume(). So, do that. Cc: Juston Li <juston.li at intel.com> Cc: Imre Deak <imre.deak at intel.com> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com> Cc: Harry Wentland