Displaying 20 results from an estimated 3000 matches similar to: "[PATCH v4 00/16] MST refcounting/atomic helpers cleanup"
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
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
2018 Dec 20
22
[PATCH v2 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
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
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 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 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 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
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 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 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 27
1
[PATCH v2 26/27] drm/dp_mst: Also print unhashed pointers for malloc/topology references
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
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 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 28
3
[PATCH v6 3/6] drm/dp_mst: Start tracking per-port VCPI allocations
On Tue, 2018-11-27 at 20:44 +0100, Daniel Vetter wrote:
> On Tue, Nov 27, 2018 at 12:48:59PM -0500, Lyude Paul wrote:
> > On Mon, 2018-11-26 at 22:22 +0100, Daniel Vetter wrote:
> > > On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote:
> > > > On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote:
> > > > > There has been a TODO waiting
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