similar to: [PATCH v5 00/14] DP MST Refactors + debugging tools + suspend/resume reprobing

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:45:54PM -0400, Lyude Paul wrote: > Since we're going to be implementing suspend/resume reprobing very soon, > we need to make sure we are extra careful to ensure that our locking > actually protects the topology state where we expect it to. Turns out > this isn't the case with drm_dp_port_setup_pdt() and > drm_dp_port_teardown_pdt(), both of which

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

On Tue, Sep 03, 2019 at 04:45:58PM -0400, Lyude Paul wrote: > Yes-you read that right. Currently there is literally no locking in > place for any of the drm_dp_mst_port struct members that can be modified > in response to a link address response, or a connection status response. > Which literally means if we're unlucky enough to have any sort of > hotplugging event happen 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

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

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 a WIP version of 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

On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > The current way of handling refcounting in the DP MST helpers is really > confusing and probably just plain wrong because it's been hacked up many > times over the years without anyone actually going over the code and > seeing if things could be simplified. > > To the best of my understanding, the current scheme

On Tue, Dec 18, 2018 at 04:27:58PM -0500, Lyude Paul wrote: > On Fri, 2018-12-14 at 10:29 +0100, Daniel Vetter wrote: > > On Thu, Dec 13, 2018 at 08:25:32PM -0500, Lyude Paul wrote: > > > The current way of handling refcounting in the DP MST helpers is really > > > confusing and probably just plain wrong because it's been hacked up many > > > times over the

On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > 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

On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote: > On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote: > > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote: > > > 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

So we don't ever have to worry about drivers touching drm_dp_mst_port structs without verifying them and crashing again. Lyude Paul (6): drm/dp_mst: Add drm_dp_get_payload_info() drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi drm/nouveau: Stop reading port->mgr in nv50_mstc_get_modes() drm/nouveau: Stop reading port->mgr in nv50_mstc_detect() drm/dp_mst:

On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul <lyude at redhat.com> wrote: > > Currently, every single piece of code in amdgpu that loops through > connectors does it incorrectly and doesn't use the proper list iteration > helpers, drm_connector_list_iter_begin() and > drm_connector_list_iter_end(). Yeesh. > > So, do that. In fairness, I think the origin of this code

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

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, usually by returning NULL from the best_encoder callback which in turn, causes the atomic

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

Currently the way that we prevent userspace from performing new modesets on MST connectors that have just been destroyed is rather broken. There's nothing in the actual DRM DP MST topology helpers that checks whether or not a connector still exists, instead each DRM driver does this on it's own, usually by returning NULL from the best_encoder callback which in turn, causes the atomic