similar to: [PATCH v2 00/16] MST refcounting/atomic helpers cleanup

Displaying 20 results from an estimated 3000 matches similar to: "[PATCH v2 00/16] MST refcounting/atomic helpers cleanup"

2019 Jan 03
16
[PATCH v3 00/16] MST refcounting/atomic helpers cleanup
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
2018 Dec 14
22
[WIP PATCH 00/15] MST refcounting/atomic helpers cleanup
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
2019 Jan 11
20
[PATCH v7 00/20] MST refcounting/atomic helpers cleanup
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
2019 Jan 10
21
[PATCH v6 00/20] MST refcounting/atomic helpers cleanup
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
2019 Jan 05
19
[PATCH v4 00/16] MST refcounting/atomic helpers cleanup
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
2019 Jan 09
27
[PATCH v5 00/20] MST refcounting/atomic helpers cleanup
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
2018 Dec 14
2
[WIP PATCH 03/15] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
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
2018 Dec 19
1
[WIP PATCH 03/15] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports
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
2018 Nov 17
9
[PATCH 0/6] Remove all bad dp_mst_port uses and hide struct def
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:
2019 Sep 25
2
[PATCH v2 16/27] drm/dp_mst: Refactor pdt setup/teardown, add more locking
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
2018 Dec 14
1
[WIP PATCH 05/15] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs
On Thu, Dec 13, 2018 at 08:25:34PM -0500, Lyude Paul wrote: > Up until now, freeing payloads on remote MST hubs that just had ports > removed has almost never worked because we've been relying on port > validation in order to stop us from accessing ports that have already > been freed from memory, but ports which need their payloads released due > to being removed will never be
2019 Oct 22
17
[PATCH v5 00/14] DP MST Refactors + debugging tools + suspend/resume reprobing
This is the final portion of 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
2019 Sep 03
50
[PATCH v2 00/27] 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
2019 Sep 25
1
[PATCH v2 20/27] drm/dp_mst: Protect drm_dp_mst_port members with connection_mutex
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
2019 Sep 25
2
[PATCH v2 03/27] drm/dp_mst: Destroy MSTBs asynchronously
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
2019 Sep 27
1
[PATCH v2 03/27] drm/dp_mst: Destroy MSTBs asynchronously
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
2018 Nov 16
8
[PATCH v6 0/6] drm/dp_mst: Improve VCPI helpers, use in nouveau
This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. [sorry for still not adding your R-Bs! I ended up needing to make a lot of changes to make it so we do actually kref() each port in the atomic state] Cc: Daniel
2018 Nov 29
1
[PATCH v6 3/6] drm/dp_mst: Start tracking per-port VCPI allocations
On Wed, 2018-11-28 at 09:17 +0100, Daniel Vetter wrote: > On Tue, Nov 27, 2018 at 08:44:14PM -0500, Lyude Paul wrote: > > On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote: > > > > We could do this the other way around so it looks like this maybe > > > > struct kref; /* manages kfree() */ > > struct topology_kref; /* corresonds to lifetime in topology
2018 Sep 18
4
[PATCH 1/6] drm/dp_mst: Introduce drm_dp_mst_connector_atomic_check()
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
2018 Nov 07
5
[PATCH RESEND v3 0/5] drm/dp_mst: Improve VCPI helpers, use in nouveau
[sorry about the resend-copy pasted the wrong header and I want to make sure this doesn't get missed!] This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude