[PATCH v2 1/3] drm/bridge: introduce bridge detaching mechanism

Daniel Vetter daniel at ffwll.ch
Thu Aug 25 06:43:21 UTC 2016


On Wed, Aug 24, 2016 at 02:05:59PM +0200, Andrea Merello wrote:
> Up to now, once a bridge has been attached to a DRM device, it cannot
> be undone.
> 
> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
> because the bridge would remain bound to the first (dead) driver instance.
> 
> This patch fixes this by introducing drm_encoder_detach() and a ->detach
> callback in drm_bridge_funcs for the bridge to be notified about detaches.
> 
> It's DRM/KMS driver responsibility to call drm_encoder_detach().
> 
> While adding the bridge detach callback, with its kerneldoc, I also added
> kerneldoc for attach callback.
> 
> Suggested-by: Daniel Vetter <daniel at ffwll.ch>
> Suggested-by: Lucas Stach <l.stach at pengutronix.de>
> Signed-off-by: Andrea Merello <andrea.merello at gmail.com>
> Cc: Archit Taneja <architt at codeaurora.org>
> Cc: David Airlie <airlied at linux.ie>
> Cc: Daniel Vetter <daniel at ffwll.ch>
> Cc: Lucas Stach <l.stach at pengutronix.de>
> ---
>  drivers/gpu/drm/drm_bridge.c | 26 ++++++++++++++++++++++++++
>  include/drm/drm_crtc.h       | 17 +++++++++++++++++
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 2555430..a77b3e0 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -125,6 +125,32 @@ int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge)
>  EXPORT_SYMBOL(drm_bridge_attach);
>  
>  /**
> + * drm_bridge_detach - deassociate given bridge from its DRM device
> + *
> + * @bridge: bridge control structure
> + *
> + * called by a kms driver to unlink the given bridge from its DRM device
> + *
> + * Note that tearing down links between the bridge and our encoder/bridge
> + * objects needs to be handled by the kms driver itself
> + *

Empty line, and we do full sentences (including capitalization and
punctuation) in the full kernel-doc paragraphs.

> + */
> +void drm_bridge_detach(struct drm_bridge *bridge)
> +{
> +	if (WARN_ON(!bridge))
> +		return;
> +
> +	if (WARN_ON(!bridge->dev))
> +		return;
> +
> +	if (bridge->funcs->detach)
> +		bridge->funcs->detach(bridge);
> +
> +	bridge->dev = NULL;
> +}
> +EXPORT_SYMBOL(drm_bridge_detach);
> +
> +/**
>   * DOC: bridge callbacks
>   *
>   * The &drm_bridge_funcs ops are populated by the bridge driver. The DRM
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b618b50..5e25e23 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1765,9 +1765,25 @@ struct drm_plane {
>   * @attach: Called during drm_bridge_attach
>   */
>  struct drm_bridge_funcs {
> +	/**
> +	 * @attach:
> +	 *
> +	 * This callback is invoked whenever our bridge is being attached.

... attached to a &drm_encoder. Similar for @detach.

Also I think we should mentation that these callbacks are optional, like
with the others. Just noticed that that remark is missing for @mode_fixup,
can you pls add it too?

lgtm otherwise.
-Daniel

> +	 *
> +	 * RETURNS:
> +	 *
> +	 * Zero on success, error code on failure
> +	 */
>  	int (*attach)(struct drm_bridge *bridge);
>  
>  	/**
> +	 * @detach:
> +	 *
> +	 * This callback is invoked whenever our bridge is being detached.
> +	 */
> +	void (*detach)(struct drm_bridge *bridge);
> +
> +	/**
>  	 * @mode_fixup:
>  	 *
>  	 * This callback is used to validate and adjust a mode. The paramater
> @@ -3196,6 +3212,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
>  extern void drm_bridge_remove(struct drm_bridge *bridge);
>  extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
>  extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge *bridge);
> +extern void drm_bridge_detach(struct drm_bridge *bridge);
>  
>  bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
>  			const struct drm_display_mode *mode,
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list