search for: justone

On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote: > There's no reason we need this, it's just confusing looking. > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Juston Li <juston.li at intel.com> > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git

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

From: Lyude Paul <lyude at redhat.com> [ Upstream commit ac0de16a38a9ec7026ca96132e3883c564497068 ] Currently, we enable hotplug detection only after we re-enable the display. However, this is too late if we're planning on sending sideband messages during the resume process - which we'll need to do in order to reprobe the topology on resume. So, enable hotplug events before

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

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

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: *

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

This is the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: - Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. - Added some debugging tools along the way that I ended up needing to figure out some issues in my own code Note that

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

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

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

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, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote: > There should be no functional changes here Would be good to explain what you did refactor here, instead of me trying to reconstruct it from the patch. Especially pre-coffee that helps :-) > > Signed-off-by: Lyude Paul <lyude at redhat.com> > Cc: Juston Li <juston.li at intel.com> > --- >

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

This is the large series for adding MST suspend/resume reprobing that I've been working on for quite a while now. In addition, I: - Refactored and cleaned up any code I ended up digging through in the process of understanding how some parts of these helpers worked. - Added some debugging tools along the way that I ended up needing to figure out some issues in my own code Note that

On Tue, Sep 03, 2019 at 04:46:04PM -0400, Lyude Paul wrote: > Currently we only print mstb/port pointer addresses in our malloc and > topology refcount functions using the hashed-by-default %p, but > unfortunately if you're trying to debug a use-after-free error caused by > a refcounting error then this really isn't terribly useful. On the other > hand though, everything in

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

There's no reason we need this, it's just confusing looking. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Juston Li <juston.li at intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ad0fb6d003be..9b1b5c9b1fa0 100644

So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Changes since v1: * Move drm_dp_mst_get_port_malloc() to where we assign intel_connector->port - danvet Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Daniel Vetter <daniel at

This has never actually worked, and isn't needed anyway: the driver's always going to try to deallocate VCPI when it tears down the display that the VCPI belongs to. Signed-off-by: Lyude Paul <lyude at redhat.com> Reviewed-by: Daniel Vetter <daniel at ffwll.ch> Cc: David Airlie <airlied at redhat.com> Cc: Jerry Zuo <Jerry.Zuo at amd.com> Cc: Harry Wentland