search for: drm_dp_mst_branch

...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 works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The intended purpose behind thi...

...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 works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The intended purpose behind thi...

...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 works like this: > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > this refcount hits 0 for either of the two, they're removed from the > topology state, but not immediately freed. Both ports and branch devices > will reinitialize their kref once it's hit 0 before actually destroying > themselves. The intende...

...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 works like this: drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When this refcount hits 0 for either of the two, they're removed from the topology state, but not immediately freed. Both ports and branch devices will reinitialize their kref once it's hit 0 before actually destroying themselves. The intended purpose behind thi...

...t'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 works like this: > > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > > > this refcount hits 0 for either of the two, they're removed from the > > > topology state, but not immediately freed. Both ports and branch devices > > > will reinitialize their kref once it's hit 0 before actually destroyin...

...ust 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 works like this: > > drm_dp_mst_port and drm_dp_mst_branch both have a single refcount. When > > this refcount hits 0 for either of the two, they're removed from the > > topology state, but not immediately freed. Both ports and branch devices > > will reinitialize their kref once it's hit 0 before actually destroying > > the...

...->next); - drm_dp_put_port(port); + drm_dp_mst_topology_put_port(port); } /* drop any tx slots msg */ @@ -911,7 +911,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref *kref) kref_put(kref, drm_dp_free_mst_branch_device); } -static void drm_dp_put_mst_branch_device(struct drm_dp_mst_branch *mstb) +static void drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb) { kref_put(&mstb->kref, drm_dp_destroy_mst_branch_device); } @@ -930,7 +930,7 @@ static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int old_pdt) case DP_PEER_DEVICE_MST_BRANCHING: mstb =...

...roy(&port->lock); > kfree(port); > } > > @@ -1906,6 +1907,36 @@ void drm_dp_mst_connector_early_unregister(struct drm_connector *connector, > } > EXPORT_SYMBOL(drm_dp_mst_connector_early_unregister); > > +static void > +drm_dp_mst_port_add_connector(struct drm_dp_mst_branch *mstb, > + struct drm_dp_mst_port *port) > +{ > + struct drm_dp_mst_topology_mgr *mgr = port->mgr; > + char proppath[255]; > + int ret; > + > + build_mst_prop_path(mstb, port->port_num, proppath, sizeof(proppath)); > + port->connector = mgr->cbs->add_c...

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

...; diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c > index d1610434a0cb..9944ef2ce885 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -1487,24 +1487,6 @@ drm_dp_mst_topology_put_mstb(struct drm_dp_mst_branch *mstb) > kref_put(&mstb->topology_kref, drm_dp_destroy_mst_branch_device); > } > > -static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int old_pdt) > -{ > - struct drm_dp_mst_branch *mstb; > - > - switch (old_pdt) { > - case DP_PEER_DEVICE_DP_L...

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

...drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c > index 2fe24e366925..5b5c0b3b3c0e 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -1327,7 +1327,8 @@ static void > drm_dp_mst_get_mstb_malloc(struct drm_dp_mst_branch *mstb) > { > kref_get(&mstb->malloc_kref); > - DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(&mstb->malloc_kref)); > + DRM_DEBUG("mstb %p/%px (%d)\n", > + mstb, mstb, kref_read(&mstb->malloc_kref)); > } > > /** > @@ -1344,7...

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

...ut_mstb_malloc(port->parent); + mutex_destroy(&port->lock); kfree(port); } @@ -1906,6 +1907,36 @@ void drm_dp_mst_connector_early_unregister(struct drm_connector *connector, } EXPORT_SYMBOL(drm_dp_mst_connector_early_unregister); +static void +drm_dp_mst_port_add_connector(struct drm_dp_mst_branch *mstb, + struct drm_dp_mst_port *port) +{ + struct drm_dp_mst_topology_mgr *mgr = port->mgr; + char proppath[255]; + int ret; + + build_mst_prop_path(mstb, port->port_num, proppath, sizeof(proppath)); + port->connector = mgr->cbs->add_connector(mgr, port, proppath); + if (!po...

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

...but never seen in the wild because hotplugging has been broken for ages now (with the exception of amdgpu, for reasons I don't think are worth digging into very far). Note: I'm going to start using the term "in-memory topology layout" here to refer to drm_dp_mst_port->mstb and drm_dp_mst_branch->ports. Locking in these places is a little tougher then it looks though. Generally we protect anything having to do with the in-memory topology layout under &mgr->lock. But this becomes nearly impossible to do from the context of link address probes due to the fact that &mgr->loc...

...unt, + topology_ref_type_to_str(entry->type), + ts_nsec, rem_nsec / 1000, buf); + } + + /* Now free the history, since this is the only time we expose it */ + kfree(history->entries); +out: + kfree(buf); +} + +static __always_inline void +drm_dp_mst_dump_mstb_topology_history(struct drm_dp_mst_branch *mstb) +{ + __dump_topology_ref_history(&mstb->topology_ref_history, mstb, + "MSTB"); +} + +static __always_inline void +drm_dp_mst_dump_port_topology_history(struct drm_dp_mst_port *port) +{ + __dump_topology_ref_history(&port->topology_ref_history, port, + &q...

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

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

...le changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 43452872efad..b44d3696c09a 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2060,7 +2060,7 @@ static struct drm_dp_mst_branch *drm_dp_get_mst_branch_device(struct drm_dp_mst_ static struct drm_dp_mst_branch *get_mst_branch_device_by_guid_helper( struct drm_dp_mst_branch *mstb, - uint8_t *guid) + const uint8_t *guid) { struct drm_dp_mst_branch *found_mstb; struct drm_dp_mst_port *port; @@ -2084,7 +2084,7 @@ stati...