search for: drm_dp_mst_get_port_malloc

...n", mstb, kref_read(&mstb->malloc_kref) - 1); > + DRM_DEBUG("mstb %p/%px (%d)\n", > + mstb, mstb, kref_read(&mstb->malloc_kref) - 1); > kref_put(&mstb->malloc_kref, drm_dp_free_mst_branch_device); > } > > @@ -1379,7 +1381,8 @@ void > drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port) > { > kref_get(&port->malloc_kref); > - DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->malloc_kref)); > + DRM_DEBUG("port %p/%px (%d)\n", > + port, port, kref_read(&port->malloc_kref)); > } > EXP...

...{ - DRM_DEBUG("mstb %p (%d)\n", mstb, kref_read(&mstb->malloc_kref) - 1); + DRM_DEBUG("mstb %p/%px (%d)\n", + mstb, mstb, kref_read(&mstb->malloc_kref) - 1); kref_put(&mstb->malloc_kref, drm_dp_free_mst_branch_device); } @@ -1379,7 +1381,8 @@ void drm_dp_mst_get_port_malloc(struct drm_dp_mst_port *port) { kref_get(&port->malloc_kref); - DRM_DEBUG("port %p (%d)\n", port, kref_read(&port->malloc_kref)); + DRM_DEBUG("port %p/%px (%d)\n", + port, port, kref_read(&port->malloc_kref)); } EXPORT_SYMBOL(drm_dp_mst_get_port_mall...

..._mst.c > index f05427b74e34..4d6ced34d465 100644 > --- a/drivers/gpu/drm/i915/intel_dp_mst.c > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c > @@ -484,6 +484,8 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo > if (ret) > goto err; > > + drm_dp_mst_get_port_malloc(port); Needs to be moved up where we assing intel_connector->port, or it'll underflow on cleanup on error paths. > + > return connector; > > err: > -- > 2.19.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

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 ffwll.ch> Cc: David Airlie <airlied at redhat.com> Cc: Jerry Zuo <Jerry.Zuo at amd.com> Cc: Harry Wentland <harry.wentland at amd.com>...

...mst_branch_device(lct, rad); > - if (port->mstb) { > - port->mstb->mgr = port->mgr; > - port->mstb->port_parent = port; > - /* > - * Make sure this port's memory allocation stays > - * around until its child MSTB releases it > - */ > - drm_dp_mst_get_port_malloc(port); > + mutex_lock(&mgr->lock); > + port->mstb = mstb; > + mstb->mgr = port->mgr; > + mstb->port_parent = port; > > - send_link = true; > - } > + /* > + * Make sure this port's memory allocation stays > + * around until its child...

...kref_put(&mstb->malloc_kref, drm_dp_free_mst_branch_device); +} + +static void drm_dp_free_mst_port(struct kref *kref) +{ + struct drm_dp_mst_port *port = + container_of(kref, struct drm_dp_mst_port, malloc_kref); + + drm_dp_mst_put_mstb_malloc(port->parent); + kfree(port); +} + +/** + * drm_dp_mst_get_port_malloc() - Increment the malloc refcount of an MST port + * @port: The &struct drm_dp_mst_port to increment the malloc refcount of + * + * Increments &drm_dp_mst_port.malloc_kref. When &drm_dp_mst_port.malloc_kref + * reaches 0, the memory allocation for @port will be released and @port may +...

...`struct +drm_dp_mst_port` respectively will be freed. + +Malloc refcounts for ports +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For :c:type:`struct drm_dp_mst_port`, malloc refcounts are exposed to drivers +through the following functions: + +.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c + :functions: drm_dp_mst_get_port_malloc drm_dp_mst_put_port_malloc + +Malloc refcounts for branch devices +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For :c:type:`struct drm_dp_mst_branch`, malloc refcounts are not currently +exposed to drivers. As of writing this documentation, there are no drivers that +have a usecase for accessing :c:type...

...kref_put(&mstb->malloc_kref, drm_dp_free_mst_branch_device); +} + +static void drm_dp_free_mst_port(struct kref *kref) +{ + struct drm_dp_mst_port *port = + container_of(kref, struct drm_dp_mst_port, malloc_kref); + + drm_dp_mst_put_mstb_malloc(port->parent); + kfree(port); +} + +/** + * drm_dp_mst_get_port_malloc() - Increment the malloc refcount of an MST port + * @port: The &struct drm_dp_mst_port to increment the malloc refcount of + * + * Increments &drm_dp_mst_port.malloc_kref. When &drm_dp_mst_port.malloc_kref + * reaches 0, the memory allocation for @port will be released and @port may +...

...e freed. > + > +Malloc refcounts for ports > +~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +For :c:type:`struct drm_dp_mst_port`, malloc refcounts are exposed to drivers > +through the following functions: > + > +.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c > + :functions: drm_dp_mst_get_port_malloc drm_dp_mst_put_port_malloc > + > +Malloc refcounts for branch devices > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +For :c:type:`struct drm_dp_mst_branch`, malloc refcounts are not currently > +exposed to drivers. As of writing this documentation, there are no drivers that > +h...

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

...~~~~~~ > > > + > > > +For :c:type:`struct drm_dp_mst_port`, malloc refcounts are exposed to > > > drivers > > > +through the following functions: > > > + > > > +.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c > > > + :functions: drm_dp_mst_get_port_malloc drm_dp_mst_put_port_malloc > > > + > > > +Malloc refcounts for branch devices > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > + > > > +For :c:type:`struct drm_dp_mst_branch`, malloc refcounts are not > > > currently > > > +exposed to d...

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

...rts > > +~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +For :c:type:`struct drm_dp_mst_port`, malloc refcounts are exposed to > > drivers > > +through the following functions: > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c > > + :functions: drm_dp_mst_get_port_malloc drm_dp_mst_put_port_malloc > > + > > +Malloc refcounts for branch devices > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +For :c:type:`struct drm_dp_mst_branch`, malloc refcounts are not > > currently > > +exposed to drivers. As of writing this document...

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

...t; + } - port->mstb = drm_dp_add_mst_branch_device(lct, rad); - if (port->mstb) { - port->mstb->mgr = port->mgr; - port->mstb->port_parent = port; - /* - * Make sure this port's memory allocation stays - * around until its child MSTB releases it - */ - drm_dp_mst_get_port_malloc(port); + mutex_lock(&mgr->lock); + port->mstb = mstb; + mstb->mgr = port->mgr; + mstb->port_parent = port; - send_link = true; - } + /* + * Make sure this port's memory allocation stays + * around until its child MSTB releases it + */ + drm_dp_mst_get_port_ma...

...t; + } - port->mstb = drm_dp_add_mst_branch_device(lct, rad); - if (port->mstb) { - port->mstb->mgr = port->mgr; - port->mstb->port_parent = port; - /* - * Make sure this port's memory allocation stays - * around until its child MSTB releases it - */ - drm_dp_mst_get_port_malloc(port); + mutex_lock(&mgr->lock); + port->mstb = mstb; + mstb->mgr = port->mgr; + mstb->port_parent = port; - send_link = true; - } + /* + * Make sure this port's memory allocation stays + * around until its child MSTB releases it + */ + drm_dp_mst_get_port_ma...