similar to: [PATCH] drm/nouveau: Fix memory leak in nv50_mstm_del()

Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: f479c0ba4a17 drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream. The bot has tested the following trees: v4.19.8, v4.14.87, v4.19.8: Build OK! v4.14.87: Failed to apply! Possible dependencies: Unable to calculate How should we proceed with this patch?

There's no actual reason we pass the connector ID instead of a pointer to the connector itself, and we're going to need the entire connector (but only temporarily) in order to name MST debugfs folders properly since connector IDs can't be looked up until the driver has been registered with userspace which happens after debugfs init. So, just pass the entire drm_connector struct

There's no actual reason we pass the connector ID instead of a pointer to the connector itself, and we're going to need the entire connector (but only temporarily) in order to name MST debugfs folders properly since connector IDs can't be looked up until the driver has been registered with userspace which happens after debugfs init. So, just pass the entire drm_connector struct

We need to actually make sure we check this on resume since otherwise we won't know whether or not the topology is still there once we've resumed, which will cause us to still think the topology is connected even after it's been removed if the removal happens mid-suspend. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org ---

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

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,

Turns out we've been forgetting for a while now to actually destroy any of the mutexes that we create in drm_dp_mst_topology_mgr. So, let's 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 <hwentlan at amd.com> Cc: Daniel Vetter <daniel.vetter at

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

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

Currently, MST lacks locking in a lot of places that really should have some sort of locking. Hotplugging and link address code paths are some of the offenders here, as there is actually nothing preventing us from running a link address probe while at the same time handling a connection status update request - something that's likely always been possible but never seen in the wild because

This is the next version of my patch series for teaching DRM how to automatically create debugfs nodes for drivers with MST topologies. This was originally intended just for nouveau, but has since been expanded to all DRM drivers. Changes since previous version: - Fix documentation error that got noticed by the kbuild bot in "drm/dp_mst: Pass entire connector to

[ 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

When reprobing an MST topology during resume, we have to account for the fact that while we were suspended it's possible that mstbs may have been removed from any ports in the topology. Since iterating downwards in the topology requires that we hold &mgr->lock, destroying MSTBs from this context would result in attempting to lock &mgr->lock a second time and deadlocking. So, fix

Once upon a time, hotplugging devices on MST branches actually worked in DRM. Now, it only works in amdgpu (likely because of how it's hotplug handlers are implemented). On both i915 and nouveau, hotplug notifications from MST branches are noticed - but trying to respond to them causes messaging timeouts and causes the whole topology state to go out of sync with reality, usually resulting in

Once upon a time, hotplugging devices on MST branches actually worked in DRM. Now, it only works in amdgpu (likely because of how it's hotplug handlers are implemented). On both i915 and nouveau, hotplug notifications from MST branches are noticed - but trying to respond to them causes messaging timeouts and causes the whole topology state to go out of sync with reality, usually resulting in

For very subtle mistakes with topology refs, it can be rather difficult to trace them down with the debugging info that we already have. I had one such issue recently while trying to implement suspend/resume reprobing for MST, and ended up coming up with this. Inspired by Chris Wilson's wakeref tracking for i915, this adds a very similar feature to the DP MST helpers, which allows for partial

For very subtle mistakes with topology refs, it can be rather difficult to trace them down with the debugging info that we already have. I had one such issue recently while trying to implement suspend/resume reprobing for MST, and ended up coming up with this. Inspired by Chris Wilson's wakeref tracking for i915, this adds a very similar feature to the DP MST helpers, which allows for partial

Just a tiny drive-by cleanup, we can consolidate i915's code for checking for MST support into a helper to be shared across drivers. v5: * Drop !!() * Move drm_dp_has_mst() out of header * Change name from drm_dp_has_mst() to drm_dp_read_mst_cap() Signed-off-by: Lyude Paul <lyude at redhat.com> Reviewed-by: Sean Paul <sean at poorly.run> --- drivers/gpu/drm/drm_dp_mst_topology.c

Originally I was just going to be adding dp_mst_status for nouveau until Daniel Stone pointed out that we should probably just make this so it's magically added for every DRM driver that's using the DRM DP MST helpers. So, let's do that! Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com> Cc: Daniel Stone <daniel