[09/60] drm/bridge: Add connector-related bridge operations and data

Commit Message

Laurent Pinchart July 7, 2019, 6:18 p.m. UTC

To support implementation of DRM connectors on top of DRM bridges
instead of by bridges, the drm_bridge needs to expose new operations and
data:

- Output detection, hot-plug notification, mode retrieval and EDID
  retrieval operations
- Bitmask of supported operations
- Bridge output type

Add and document these.

Three new bridge helper functions are also added to handle hot plug
notification in a way that is as transparent as possible for the
bridges.

Signed-off-by: Laurent Pinchart <[e-mail]>
---
 drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
 include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
 2 files changed, 261 insertions(+), 1 deletion(-)

Comments

Andrzej Hajda July 10, 2019, 12:12 p.m. UTC | #1

Hi Laurent,


I like the approach, current practice when almost every bridge should
optionally implement connector, or alternatively downstream bridge or
panel is very painful.
More comments inlined.

On 07.07.2019 20:18, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
>   retrieval operations
> - Bitmask of supported operations


Why do we need these bitmask at all? Why cannot we rely on presence of
operation's callback?


> - Bridge output type
>
> Add and document these.
>
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.


Documentation of new opses does not explain how it should cooperate with
bridge chaining, I suppose they should be chained explicitly, am I
right? More comments about it later.


>
> Signed-off-by: Laurent Pinchart <[e-mail]>
> ---
>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>  2 files changed, 261 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 519577f363e3..3c2a255df7af 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>   */
>  void drm_bridge_add(struct drm_bridge *bridge)
>  {
> +	mutex_init(&bridge->hpd_mutex);
> +
>  	mutex_lock(&bridge_lock);
>  	list_add_tail(&bridge->list, &bridge_list);
>  	mutex_unlock(&bridge_lock);
> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>  	mutex_lock(&bridge_lock);
>  	list_del_init(&bridge->list);
>  	mutex_unlock(&bridge_lock);
> +
> +	mutex_destroy(&bridge->hpd_mutex);
>  }
>  EXPORT_SYMBOL(drm_bridge_remove);
>  
> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>  }
>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>  
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> + * hot plug notification callback. From now on the @cb will be called with
> + * @data when an output status change is detected by the bridge, until hot plug
> + * notification gets disabled with drm_bridge_hpd_disable().
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> + * bridge->ops. This function shall not be called when the flag is not set.
> + *
> + * Only one hot plug detection callback can be registered at a time, it is an
> + * error to call this function when hot plug detection is already enabled for
> + * the bridge.
> + */


To simplify architecture maybe would be better to enable hpd just on
bridge attach:

bridge->hpd_cb = cb;

bridge->hpd_data = data;

ret = drm_bridge_attach(...);


This way we could avoid adding new callbacks hpd_(enable|disable)
without big sacrifices.


One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
notifies about sink status change, how it translates to this cb?


> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> +			   void (*cb)(void *data,
> +				      enum drm_connector_status status),
> +			   void *data)
> +{
> +	if (!bridge || !bridge->funcs->hpd_enable)
> +		return;
> +
> +	mutex_lock(&bridge->hpd_mutex);
> +
> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> +		goto unlock;
> +
> +	bridge->hpd_cb = cb;
> +	bridge->hpd_data = data;
> +
> +	bridge->funcs->hpd_enable(bridge);
> +
> +unlock:
> +	mutex_unlock(&bridge->hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> +
> +/**
> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + *
> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> + * function returns the callback will not be called by the bridge when an
> + * output status change occurs.
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> + * bridge->ops. This function shall not be called when the flag is not set.
> + */
> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> +{
> +	if (!bridge || !bridge->funcs->hpd_disable)
> +		return;
> +
> +	mutex_lock(&bridge->hpd_mutex);
> +	bridge->funcs->hpd_disable(bridge);
> +
> +	bridge->hpd_cb = NULL;
> +	bridge->hpd_data = NULL;
> +	mutex_unlock(&bridge->hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> +
> +/**
> + * drm_bridge_hpd_notify - notify hot plug detection events
> + * @bridge: bridge control structure
> + * @status: output connection status
> + *
> + * Bridge drivers shall call this function to report hot plug events when they
> + * detect a change in the output status, when hot plug detection has been
> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> + *
> + * This function shall be called in a context that can sleep.
> + */
> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> +			   enum drm_connector_status status)
> +{
> +	mutex_lock(&bridge->hpd_mutex);
> +	if (bridge->hpd_cb)
> +		bridge->hpd_cb(bridge->hpd_data, status);
> +	mutex_unlock(&bridge->hpd_mutex);
> +}
> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> +
>  #ifdef CONFIG_OF
>  /**
>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 08dc15f93ded..b9445aa5b1ef 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -23,8 +23,9 @@
>  #ifndef __DRM_BRIDGE_H__
>  #define __DRM_BRIDGE_H__
>  
> -#include <linux/list.h>
>  #include <linux/ctype.h>
> +#include <linux/list.h>
> +#include <linux/mutex.h>
>  #include <drm/drm_mode_object.h>
>  #include <drm/drm_modes.h>
>  
> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>  	 */
>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>  				    struct drm_atomic_state *state);
> +
> +	/**
> +	 * @detect:
> +	 *
> +	 * Check if anything is attached to the bridge output.
> +	 *
> +	 * This callback is optional, if not implemented the bridge will be
> +	 * considered as always having a component attached to its output.
> +	 * Bridges that implement this callback shall set the
> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> +	 *
> +	 * RETURNS:
> +	 *
> +	 * drm_connector_status indicating the bridge output status.
> +	 */
> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> +
> +	/**
> +	 * @get_modes:
> +	 *
> +	 * Fill all modes currently valid for the sink into the &drm_connector
> +	 * with drm_mode_probed_add().
> +	 *
> +	 * The @get_modes callback is mostly intended to support non-probable
> +	 * displays such as many fixed panels. Bridges that support reading
> +	 * EDID shall leave @get_modes unimplemented and implement the
> +	 * &drm_bridge_funcs->get_edid callback instead.
> +	 *
> +	 * This callback is optional. Bridges that implement it shall set the
> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> +	 *
> +	 * RETURNS:
> +	 *
> +	 * The number of modes added by calling drm_mode_probed_add().
> +	 */
> +	int (*get_modes)(struct drm_bridge *bridge,
> +			 struct drm_connector *connector);
> +
> +	/**
> +	 * @get_edid:
> +	 *
> +	 * Read and parse the EDID data of the connected display.
> +	 *
> +	 * The @get_edid callback is the preferred way of reporting mode
> +	 * information for a display connected to the bridge output. Bridges
> +	 * that support readind EDID shall implement this callback and leave
> +	 * the @get_modes callback unimplemented.
> +	 *
> +	 * The caller of this operation shall first verify the output
> +	 * connection status and refrain from reading EDID from a disconnected
> +	 * output.
> +	 *
> +	 * This callback is optional. Bridges that implement it shall set the
> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> +	 *
> +	 * RETURNS:
> +	 *
> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> +	 * success, or NULL otherwise. The caller is responsible for freeing
> +	 * the returned edid structure with kfree().
> +	 */
> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> +				 struct drm_connector *connector);


It overlaps with get_modes, I guess presence of one ops should disallow
presence of another one?

I am not really convinced we need this op at all, cannot we just assign
some helper function to .get_modes cb, which will do the same?


Regards

Andrzej


> +
> +	/**
> +	 * @lost_hotplug:
> +	 *
> +	 * Notify the bridge of display disconnection.
> +	 *
> +	 * This callback is optional, it may be implemented by bridges that
> +	 * need to be notified of display disconnection for internal reasons.
> +	 * One use case is to reset the internal state of CEC controllers for
> +	 * HDMI bridges.
> +	 */
> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> +
> +	/**
> +	 * @hpd_enable:
> +	 *
> +	 * Enable hot plug detection. From now on the bridge shall call
> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> +	 * connection status, until hot plug detection gets disabled with
> +	 * @hpd_disable.
> +	 *
> +	 * This callback is optional and shall only be implemented by bridges
> +	 * that support hot-plug notification without polling. Bridges that
> +	 * implement it shall also implement the @hpd_disable callback and set
> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> +	 */
> +	void (*hpd_enable)(struct drm_bridge *bridge);
> +
> +	/**
> +	 * @hpd_disable:
> +	 *
> +	 * Disable hot plug detection. Once this function returns the bridge
> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> +	 * connection status occurs.
> +	 *
> +	 * This callback is optional and shall only be implemented by bridges
> +	 * that support hot-plug notification without polling. Bridges that
> +	 * implement it shall also implement the @hpd_enable callback and set
> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> +	 */
> +	void (*hpd_disable)(struct drm_bridge *bridge);
>  };
>  
>  /**
> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>  	bool dual_link;
>  };
>  
> +/**
> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> + */
> +enum drm_bridge_ops {
> +	/**
> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> +	 * its output. Bridges that set this flag shall implement the
> +	 * &drm_bridge_funcs->detect callback.
> +	 */
> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> +	/**
> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> +	 * connected to its output. Bridges that set this flag shall implement
> +	 * the &drm_bridge_funcs->get_edid callback.
> +	 */
> +	DRM_BRIDGE_OP_EDID = BIT(1),
> +	/**
> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> +	 * without requiring polling. Bridges that set this flag shall
> +	 * implement the &drm_bridge_funcs->hpd_enable and
> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> +	 */
> +	DRM_BRIDGE_OP_HPD = BIT(2),
> +	/**
> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> +	 * by the display at its output. This does not include readind EDID
> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> +	 */
> +	DRM_BRIDGE_OP_MODES = BIT(3),
> +};
> +
>  /**
>   * struct drm_bridge - central DRM bridge control structure
>   */
> @@ -398,6 +535,29 @@ struct drm_bridge {
>  	const struct drm_bridge_funcs *funcs;
>  	/** @driver_private: pointer to the bridge driver's internal context */
>  	void *driver_private;
> +	/** @ops: bitmask of operations supported by the bridge */
> +	enum drm_bridge_ops ops;
> +	/**
> +	 * @type: Type of the connection at the bridge output
> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> +	 * identifies the type of connected display.
> +	 */
> +	int type;
> +	/** private: */
> +	/**
> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> +	 */
> +	struct mutex hpd_mutex;
> +	/**
> +	 * @hpd_cb: Hot plug detection callback, registered with
> +	 * drm_bridge_hpd_enable().
> +	 */
> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> +	/**
> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> +	 * @hpd_cb.
> +	 */
> +	void *hpd_data;
>  };
>  
>  void drm_bridge_add(struct drm_bridge *bridge);
> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>  			      struct drm_atomic_state *state);
>  
> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> +			   void (*cb)(void *data,
> +				      enum drm_connector_status status),
> +			   void *data);
> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> +			   enum drm_connector_status status);
> +
>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>  					u32 connector_type);

Daniel Vetter July 11, 2019, 7:35 a.m. UTC | #2

On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> Hi Laurent,
> 
> 
> I like the approach, current practice when almost every bridge should
> optionally implement connector, or alternatively downstream bridge or
> panel is very painful.

Yeah I think this looks mostly reasonable. Some api design comments on top
of Andrzej', with the fair warning that I didn't bother to read up on how
it's all used in the end. I probably should go and do that, at least to
get a feeling for what your hpd_cb usually does.

> More comments inlined.
> 
> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > To support implementation of DRM connectors on top of DRM bridges
> > instead of by bridges, the drm_bridge needs to expose new operations and
> > data:
> >
> > - Output detection, hot-plug notification, mode retrieval and EDID
> >   retrieval operations
> > - Bitmask of supported operations
> 
> 
> Why do we need these bitmask at all? Why cannot we rely on presence of
> operation's callback?

Yeah also not a huge fan of these bitmasks. Smells like
DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
add, generally good excuse to not have to think through the design between
different parts of drivers - "just" add another flag.
> 
> 
> > - Bridge output type
> >
> > Add and document these.
> >
> > Three new bridge helper functions are also added to handle hot plug
> > notification in a way that is as transparent as possible for the
> > bridges.
> 
> 
> Documentation of new opses does not explain how it should cooperate with
> bridge chaining, I suppose they should be chained explicitly, am I
> right? More comments about it later.
> 
> 
> >
> > Signed-off-by: Laurent Pinchart <[e-mail]>
> > ---
> >  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >  2 files changed, 261 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 519577f363e3..3c2a255df7af 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >   */
> >  void drm_bridge_add(struct drm_bridge *bridge)
> >  {
> > +	mutex_init(&bridge->hpd_mutex);
> > +
> >  	mutex_lock(&bridge_lock);
> >  	list_add_tail(&bridge->list, &bridge_list);
> >  	mutex_unlock(&bridge_lock);
> > @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >  	mutex_lock(&bridge_lock);
> >  	list_del_init(&bridge->list);
> >  	mutex_unlock(&bridge_lock);
> > +
> > +	mutex_destroy(&bridge->hpd_mutex);
> >  }
> >  EXPORT_SYMBOL(drm_bridge_remove);
> >  
> > @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >  }
> >  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >  
> > +/**
> > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > + * @bridge: bridge control structure
> > + * @cb: hot-plug detection callback
> > + * @data: data to be passed to the hot-plug detection callback
> > + *
> > + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > + * hot plug notification callback. From now on the @cb will be called with
> > + * @data when an output status change is detected by the bridge, until hot plug
> > + * notification gets disabled with drm_bridge_hpd_disable().
> > + *
> > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > + * bridge->ops. This function shall not be called when the flag is not set.
> > + *
> > + * Only one hot plug detection callback can be registered at a time, it is an
> > + * error to call this function when hot plug detection is already enabled for
> > + * the bridge.
> > + */
> 
> 
> To simplify architecture maybe would be better to enable hpd just on
> bridge attach:
> 
> bridge->hpd_cb = cb;
> 
> bridge->hpd_data = data;
> 
> ret = drm_bridge_attach(...);

Yeah I like this more. The other problem here is, what if you need more
than 1 callback registers on the same bridge hdp signal?


> This way we could avoid adding new callbacks hpd_(enable|disable)
> without big sacrifices.
> 
> 
> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> notifies about sink status change, how it translates to this cb?
> 
> 
> > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > +			   void (*cb)(void *data,
> > +				      enum drm_connector_status status),
> > +			   void *data)
> > +{
> > +	if (!bridge || !bridge->funcs->hpd_enable)
> > +		return;
> > +
> > +	mutex_lock(&bridge->hpd_mutex);
> > +
> > +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > +		goto unlock;
> > +
> > +	bridge->hpd_cb = cb;
> > +	bridge->hpd_data = data;
> > +
> > +	bridge->funcs->hpd_enable(bridge);
> > +
> > +unlock:
> > +	mutex_unlock(&bridge->hpd_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > +
> > +/**
> > + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > + * @bridge: bridge control structure
> > + *
> > + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > + * function returns the callback will not be called by the bridge when an
> > + * output status change occurs.
> > + *
> > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > + * bridge->ops. This function shall not be called when the flag is not set.
> > + */
> > +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > +{
> > +	if (!bridge || !bridge->funcs->hpd_disable)
> > +		return;
> > +
> > +	mutex_lock(&bridge->hpd_mutex);
> > +	bridge->funcs->hpd_disable(bridge);
> > +
> > +	bridge->hpd_cb = NULL;
> > +	bridge->hpd_data = NULL;
> > +	mutex_unlock(&bridge->hpd_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > +
> > +/**
> > + * drm_bridge_hpd_notify - notify hot plug detection events
> > + * @bridge: bridge control structure
> > + * @status: output connection status
> > + *
> > + * Bridge drivers shall call this function to report hot plug events when they
> > + * detect a change in the output status, when hot plug detection has been
> > + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > + *
> > + * This function shall be called in a context that can sleep.
> > + */
> > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > +			   enum drm_connector_status status)
> > +{
> > +	mutex_lock(&bridge->hpd_mutex);
> > +	if (bridge->hpd_cb)
> > +		bridge->hpd_cb(bridge->hpd_data, status);

So this isn't quite what I had in mind. Instead something like this:

	/* iterates over all bridges in the chain containing @bridge */
	for_each_bridge(tmp_bridge, bridge) {
		if (tmp_bridge == bridge)
			continue;
		if (bridge->hpd_notify);
			bridge->hpd_notify(tmp_bridge, bridge, status);
	}

	encoder = encoder_for_bridge(bridge);
	if (encoder->helper_private->bridge_hpd_notify)
		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);

	dev = bridge->dev
	if (dev->mode_config.helper_private->bridge_hpd_notify)
		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)

No register callback needed, no locking needed, everyone gets exactly the
hpd they want/need.

> > +	mutex_unlock(&bridge->hpd_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > +
> >  #ifdef CONFIG_OF
> >  /**
> >   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index 08dc15f93ded..b9445aa5b1ef 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -23,8 +23,9 @@
> >  #ifndef __DRM_BRIDGE_H__
> >  #define __DRM_BRIDGE_H__
> >  
> > -#include <linux/list.h>
> >  #include <linux/ctype.h>
> > +#include <linux/list.h>
> > +#include <linux/mutex.h>
> >  #include <drm/drm_mode_object.h>
> >  #include <drm/drm_modes.h>
> >  
> > @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >  	 */
> >  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >  				    struct drm_atomic_state *state);
> > +
> > +	/**
> > +	 * @detect:
> > +	 *
> > +	 * Check if anything is attached to the bridge output.
> > +	 *
> > +	 * This callback is optional, if not implemented the bridge will be
> > +	 * considered as always having a component attached to its output.
> > +	 * Bridges that implement this callback shall set the
> > +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > +	 *
> > +	 * RETURNS:
> > +	 *
> > +	 * drm_connector_status indicating the bridge output status.
> > +	 */
> > +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > +
> > +	/**
> > +	 * @get_modes:
> > +	 *
> > +	 * Fill all modes currently valid for the sink into the &drm_connector
> > +	 * with drm_mode_probed_add().
> > +	 *
> > +	 * The @get_modes callback is mostly intended to support non-probable
> > +	 * displays such as many fixed panels. Bridges that support reading
> > +	 * EDID shall leave @get_modes unimplemented and implement the
> > +	 * &drm_bridge_funcs->get_edid callback instead.
> > +	 *
> > +	 * This callback is optional. Bridges that implement it shall set the
> > +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > +	 *
> > +	 * RETURNS:
> > +	 *
> > +	 * The number of modes added by calling drm_mode_probed_add().
> > +	 */
> > +	int (*get_modes)(struct drm_bridge *bridge,
> > +			 struct drm_connector *connector);
> > +
> > +	/**
> > +	 * @get_edid:
> > +	 *
> > +	 * Read and parse the EDID data of the connected display.
> > +	 *
> > +	 * The @get_edid callback is the preferred way of reporting mode
> > +	 * information for a display connected to the bridge output. Bridges
> > +	 * that support readind EDID shall implement this callback and leave
> > +	 * the @get_modes callback unimplemented.
> > +	 *
> > +	 * The caller of this operation shall first verify the output
> > +	 * connection status and refrain from reading EDID from a disconnected
> > +	 * output.
> > +	 *
> > +	 * This callback is optional. Bridges that implement it shall set the
> > +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > +	 *
> > +	 * RETURNS:
> > +	 *
> > +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > +	 * success, or NULL otherwise. The caller is responsible for freeing
> > +	 * the returned edid structure with kfree().
> > +	 */
> > +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > +				 struct drm_connector *connector);
> 
> 
> It overlaps with get_modes, I guess presence of one ops should disallow
> presence of another one?
> 
> I am not really convinced we need this op at all, cannot we just assign
> some helper function to .get_modes cb, which will do the same?

Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
case, and require that if it has an edid it must fill out connector->info
and connector->edid correctly.

Btw if a hpd happens, who's responible for making sure the edid/mode list
in the connector is up-to-date? With your current callback design that's
up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
should guarantee that it'll first walk the connectors to update status and
edid/mode list for the final drm_connector. And then instead of just
passing the simple "status", it'll pass the connector, with everything
correctly updated.

Otherwise everyone interested in that hpd signal will go and re-fetch the
edid, which is not so awesome :-)
-Daniel

> 
> 
> Regards
> 
> Andrzej
> 
> 
> > +
> > +	/**
> > +	 * @lost_hotplug:
> > +	 *
> > +	 * Notify the bridge of display disconnection.
> > +	 *
> > +	 * This callback is optional, it may be implemented by bridges that
> > +	 * need to be notified of display disconnection for internal reasons.
> > +	 * One use case is to reset the internal state of CEC controllers for
> > +	 * HDMI bridges.
> > +	 */
> > +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > +
> > +	/**
> > +	 * @hpd_enable:
> > +	 *
> > +	 * Enable hot plug detection. From now on the bridge shall call
> > +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > +	 * connection status, until hot plug detection gets disabled with
> > +	 * @hpd_disable.
> > +	 *
> > +	 * This callback is optional and shall only be implemented by bridges
> > +	 * that support hot-plug notification without polling. Bridges that
> > +	 * implement it shall also implement the @hpd_disable callback and set
> > +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > +	 */
> > +	void (*hpd_enable)(struct drm_bridge *bridge);
> > +
> > +	/**
> > +	 * @hpd_disable:
> > +	 *
> > +	 * Disable hot plug detection. Once this function returns the bridge
> > +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > +	 * connection status occurs.
> > +	 *
> > +	 * This callback is optional and shall only be implemented by bridges
> > +	 * that support hot-plug notification without polling. Bridges that
> > +	 * implement it shall also implement the @hpd_enable callback and set
> > +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > +	 */
> > +	void (*hpd_disable)(struct drm_bridge *bridge);
> >  };
> >  
> >  /**
> > @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >  	bool dual_link;
> >  };
> >  
> > +/**
> > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > + */
> > +enum drm_bridge_ops {
> > +	/**
> > +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > +	 * its output. Bridges that set this flag shall implement the
> > +	 * &drm_bridge_funcs->detect callback.
> > +	 */
> > +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > +	/**
> > +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > +	 * connected to its output. Bridges that set this flag shall implement
> > +	 * the &drm_bridge_funcs->get_edid callback.
> > +	 */
> > +	DRM_BRIDGE_OP_EDID = BIT(1),
> > +	/**
> > +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > +	 * without requiring polling. Bridges that set this flag shall
> > +	 * implement the &drm_bridge_funcs->hpd_enable and
> > +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > +	 */
> > +	DRM_BRIDGE_OP_HPD = BIT(2),
> > +	/**
> > +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > +	 * by the display at its output. This does not include readind EDID
> > +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > +	 */
> > +	DRM_BRIDGE_OP_MODES = BIT(3),
> > +};
> > +
> >  /**
> >   * struct drm_bridge - central DRM bridge control structure
> >   */
> > @@ -398,6 +535,29 @@ struct drm_bridge {
> >  	const struct drm_bridge_funcs *funcs;
> >  	/** @driver_private: pointer to the bridge driver's internal context */
> >  	void *driver_private;
> > +	/** @ops: bitmask of operations supported by the bridge */
> > +	enum drm_bridge_ops ops;
> > +	/**
> > +	 * @type: Type of the connection at the bridge output
> > +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > +	 * identifies the type of connected display.
> > +	 */
> > +	int type;
> > +	/** private: */
> > +	/**
> > +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > +	 */
> > +	struct mutex hpd_mutex;
> > +	/**
> > +	 * @hpd_cb: Hot plug detection callback, registered with
> > +	 * drm_bridge_hpd_enable().
> > +	 */
> > +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > +	/**
> > +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > +	 * @hpd_cb.
> > +	 */
> > +	void *hpd_data;
> >  };
> >  
> >  void drm_bridge_add(struct drm_bridge *bridge);
> > @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >  			      struct drm_atomic_state *state);
> >  
> > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > +			   void (*cb)(void *data,
> > +				      enum drm_connector_status status),
> > +			   void *data);
> > +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > +			   enum drm_connector_status status);
> > +
> >  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >  					u32 connector_type);
> 
>

Andrzej Hajda July 11, 2019, 12:41 p.m. UTC | #3

On 11.07.2019 09:35, Daniel Vetter wrote:
> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>> Hi Laurent,
>>
>>
>> I like the approach, current practice when almost every bridge should
>> optionally implement connector, or alternatively downstream bridge or
>> panel is very painful.
> Yeah I think this looks mostly reasonable. Some api design comments on top
> of Andrzej', with the fair warning that I didn't bother to read up on how
> it's all used in the end. I probably should go and do that, at least to
> get a feeling for what your hpd_cb usually does.
>
>> More comments inlined.
>>
>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>> To support implementation of DRM connectors on top of DRM bridges
>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>> data:
>>>
>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>   retrieval operations
>>> - Bitmask of supported operations
>>
>> Why do we need these bitmask at all? Why cannot we rely on presence of
>> operation's callback?
> Yeah also not a huge fan of these bitmasks. Smells like
> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> add, generally good excuse to not have to think through the design between
> different parts of drivers - "just" add another flag.
>>
>>> - Bridge output type
>>>
>>> Add and document these.
>>>
>>> Three new bridge helper functions are also added to handle hot plug
>>> notification in a way that is as transparent as possible for the
>>> bridges.
>>
>> Documentation of new opses does not explain how it should cooperate with
>> bridge chaining, I suppose they should be chained explicitly, am I
>> right? More comments about it later.
>>
>>
>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>> ---
>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 519577f363e3..3c2a255df7af 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>   */
>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>  {
>>> +	mutex_init(&bridge->hpd_mutex);
>>> +
>>>  	mutex_lock(&bridge_lock);
>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>  	mutex_unlock(&bridge_lock);
>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>  	mutex_lock(&bridge_lock);
>>>  	list_del_init(&bridge->list);
>>>  	mutex_unlock(&bridge_lock);
>>> +
>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>  }
>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>  
>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>  }
>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>  
>>> +/**
>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>> + * @bridge: bridge control structure
>>> + * @cb: hot-plug detection callback
>>> + * @data: data to be passed to the hot-plug detection callback
>>> + *
>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>> + * hot plug notification callback. From now on the @cb will be called with
>>> + * @data when an output status change is detected by the bridge, until hot plug
>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>> + *
>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>> + *
>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>> + * error to call this function when hot plug detection is already enabled for
>>> + * the bridge.
>>> + */
>>
>> To simplify architecture maybe would be better to enable hpd just on
>> bridge attach:
>>
>> bridge->hpd_cb = cb;
>>
>> bridge->hpd_data = data;
>>
>> ret = drm_bridge_attach(...);
> Yeah I like this more. The other problem here is, what if you need more
> than 1 callback registers on the same bridge hdp signal?
>
>
>> This way we could avoid adding new callbacks hpd_(enable|disable)
>> without big sacrifices.
>>
>>
>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>> notifies about sink status change, how it translates to this cb?
>>
>>
>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>> +			   void (*cb)(void *data,
>>> +				      enum drm_connector_status status),
>>> +			   void *data)
>>> +{
>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>> +		return;
>>> +
>>> +	mutex_lock(&bridge->hpd_mutex);
>>> +
>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>> +		goto unlock;
>>> +
>>> +	bridge->hpd_cb = cb;
>>> +	bridge->hpd_data = data;
>>> +
>>> +	bridge->funcs->hpd_enable(bridge);
>>> +
>>> +unlock:
>>> +	mutex_unlock(&bridge->hpd_mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>> +
>>> +/**
>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>> + * @bridge: bridge control structure
>>> + *
>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>> + * function returns the callback will not be called by the bridge when an
>>> + * output status change occurs.
>>> + *
>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>> + */
>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>> +{
>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>> +		return;
>>> +
>>> +	mutex_lock(&bridge->hpd_mutex);
>>> +	bridge->funcs->hpd_disable(bridge);
>>> +
>>> +	bridge->hpd_cb = NULL;
>>> +	bridge->hpd_data = NULL;
>>> +	mutex_unlock(&bridge->hpd_mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>> +
>>> +/**
>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>> + * @bridge: bridge control structure
>>> + * @status: output connection status
>>> + *
>>> + * Bridge drivers shall call this function to report hot plug events when they
>>> + * detect a change in the output status, when hot plug detection has been
>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>> + *
>>> + * This function shall be called in a context that can sleep.
>>> + */
>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>> +			   enum drm_connector_status status)
>>> +{
>>> +	mutex_lock(&bridge->hpd_mutex);
>>> +	if (bridge->hpd_cb)
>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> So this isn't quite what I had in mind. Instead something like this:
>
> 	/* iterates over all bridges in the chain containing @bridge */
> 	for_each_bridge(tmp_bridge, bridge) {
> 		if (tmp_bridge == bridge)
> 			continue;
> 		if (bridge->hpd_notify);
> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> 	}
>
> 	encoder = encoder_for_bridge(bridge);
> 	if (encoder->helper_private->bridge_hpd_notify)
> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>
> 	dev = bridge->dev
> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>
> No register callback needed, no locking needed, everyone gets exactly the
> hpd they want/need.


As I understand you want to notify every member of the pipeline.

I think it should be enough to notify only the source, and then source
should decide if/when the hpd should be propagated upstream.

It looks more generic for me.


Regards

Andrzej


>
>>> +	mutex_unlock(&bridge->hpd_mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>> +
>>>  #ifdef CONFIG_OF
>>>  /**
>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -23,8 +23,9 @@
>>>  #ifndef __DRM_BRIDGE_H__
>>>  #define __DRM_BRIDGE_H__
>>>  
>>> -#include <linux/list.h>
>>>  #include <linux/ctype.h>
>>> +#include <linux/list.h>
>>> +#include <linux/mutex.h>
>>>  #include <drm/drm_mode_object.h>
>>>  #include <drm/drm_modes.h>
>>>  
>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>  	 */
>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>  				    struct drm_atomic_state *state);
>>> +
>>> +	/**
>>> +	 * @detect:
>>> +	 *
>>> +	 * Check if anything is attached to the bridge output.
>>> +	 *
>>> +	 * This callback is optional, if not implemented the bridge will be
>>> +	 * considered as always having a component attached to its output.
>>> +	 * Bridges that implement this callback shall set the
>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>> +	 *
>>> +	 * RETURNS:
>>> +	 *
>>> +	 * drm_connector_status indicating the bridge output status.
>>> +	 */
>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>> +
>>> +	/**
>>> +	 * @get_modes:
>>> +	 *
>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>> +	 * with drm_mode_probed_add().
>>> +	 *
>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>> +	 * displays such as many fixed panels. Bridges that support reading
>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>> +	 *
>>> +	 * This callback is optional. Bridges that implement it shall set the
>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>> +	 *
>>> +	 * RETURNS:
>>> +	 *
>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>> +	 */
>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>> +			 struct drm_connector *connector);
>>> +
>>> +	/**
>>> +	 * @get_edid:
>>> +	 *
>>> +	 * Read and parse the EDID data of the connected display.
>>> +	 *
>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>> +	 * information for a display connected to the bridge output. Bridges
>>> +	 * that support readind EDID shall implement this callback and leave
>>> +	 * the @get_modes callback unimplemented.
>>> +	 *
>>> +	 * The caller of this operation shall first verify the output
>>> +	 * connection status and refrain from reading EDID from a disconnected
>>> +	 * output.
>>> +	 *
>>> +	 * This callback is optional. Bridges that implement it shall set the
>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>> +	 *
>>> +	 * RETURNS:
>>> +	 *
>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>> +	 * the returned edid structure with kfree().
>>> +	 */
>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>> +				 struct drm_connector *connector);
>>
>> It overlaps with get_modes, I guess presence of one ops should disallow
>> presence of another one?
>>
>> I am not really convinced we need this op at all, cannot we just assign
>> some helper function to .get_modes cb, which will do the same?
> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> case, and require that if it has an edid it must fill out connector->info
> and connector->edid correctly.
>
> Btw if a hpd happens, who's responible for making sure the edid/mode list
> in the connector is up-to-date? With your current callback design that's
> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> should guarantee that it'll first walk the connectors to update status and
> edid/mode list for the final drm_connector. And then instead of just
> passing the simple "status", it'll pass the connector, with everything
> correctly updated.
>
> Otherwise everyone interested in that hpd signal will go and re-fetch the
> edid, which is not so awesome :-)
> -Daniel
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>> +
>>> +	/**
>>> +	 * @lost_hotplug:
>>> +	 *
>>> +	 * Notify the bridge of display disconnection.
>>> +	 *
>>> +	 * This callback is optional, it may be implemented by bridges that
>>> +	 * need to be notified of display disconnection for internal reasons.
>>> +	 * One use case is to reset the internal state of CEC controllers for
>>> +	 * HDMI bridges.
>>> +	 */
>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>> +
>>> +	/**
>>> +	 * @hpd_enable:
>>> +	 *
>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>> +	 * connection status, until hot plug detection gets disabled with
>>> +	 * @hpd_disable.
>>> +	 *
>>> +	 * This callback is optional and shall only be implemented by bridges
>>> +	 * that support hot-plug notification without polling. Bridges that
>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>> +	 */
>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>> +
>>> +	/**
>>> +	 * @hpd_disable:
>>> +	 *
>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>> +	 * connection status occurs.
>>> +	 *
>>> +	 * This callback is optional and shall only be implemented by bridges
>>> +	 * that support hot-plug notification without polling. Bridges that
>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>> +	 */
>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>  };
>>>  
>>>  /**
>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>  	bool dual_link;
>>>  };
>>>  
>>> +/**
>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>> + */
>>> +enum drm_bridge_ops {
>>> +	/**
>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>> +	 * its output. Bridges that set this flag shall implement the
>>> +	 * &drm_bridge_funcs->detect callback.
>>> +	 */
>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>> +	/**
>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>> +	 * connected to its output. Bridges that set this flag shall implement
>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>> +	 */
>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>> +	/**
>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>> +	 * without requiring polling. Bridges that set this flag shall
>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>> +	 */
>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>> +	/**
>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>> +	 * by the display at its output. This does not include readind EDID
>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>> +	 */
>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>> +};
>>> +
>>>  /**
>>>   * struct drm_bridge - central DRM bridge control structure
>>>   */
>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>  	const struct drm_bridge_funcs *funcs;
>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>  	void *driver_private;
>>> +	/** @ops: bitmask of operations supported by the bridge */
>>> +	enum drm_bridge_ops ops;
>>> +	/**
>>> +	 * @type: Type of the connection at the bridge output
>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>> +	 * identifies the type of connected display.
>>> +	 */
>>> +	int type;
>>> +	/** private: */
>>> +	/**
>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>> +	 */
>>> +	struct mutex hpd_mutex;
>>> +	/**
>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>> +	 * drm_bridge_hpd_enable().
>>> +	 */
>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>> +	/**
>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>> +	 * @hpd_cb.
>>> +	 */
>>> +	void *hpd_data;
>>>  };
>>>  
>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>  			      struct drm_atomic_state *state);
>>>  
>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>> +			   void (*cb)(void *data,
>>> +				      enum drm_connector_status status),
>>> +			   void *data);
>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>> +			   enum drm_connector_status status);
>>> +
>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>  					u32 connector_type);
>>

Daniel Vetter July 11, 2019, 1:18 p.m. UTC | #4

On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> On 11.07.2019 09:35, Daniel Vetter wrote:
> > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >> Hi Laurent,
> >>
> >>
> >> I like the approach, current practice when almost every bridge should
> >> optionally implement connector, or alternatively downstream bridge or
> >> panel is very painful.
> > Yeah I think this looks mostly reasonable. Some api design comments on top
> > of Andrzej', with the fair warning that I didn't bother to read up on how
> > it's all used in the end. I probably should go and do that, at least to
> > get a feeling for what your hpd_cb usually does.
> >
> >> More comments inlined.
> >>
> >> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>> To support implementation of DRM connectors on top of DRM bridges
> >>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>> data:
> >>>
> >>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>   retrieval operations
> >>> - Bitmask of supported operations
> >>
> >> Why do we need these bitmask at all? Why cannot we rely on presence of
> >> operation's callback?
> > Yeah also not a huge fan of these bitmasks. Smells like
> > DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > add, generally good excuse to not have to think through the design between
> > different parts of drivers - "just" add another flag.
> >>
> >>> - Bridge output type
> >>>
> >>> Add and document these.
> >>>
> >>> Three new bridge helper functions are also added to handle hot plug
> >>> notification in a way that is as transparent as possible for the
> >>> bridges.
> >>
> >> Documentation of new opses does not explain how it should cooperate with
> >> bridge chaining, I suppose they should be chained explicitly, am I
> >> right? More comments about it later.
> >>
> >>
> >>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>> ---
> >>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>> index 519577f363e3..3c2a255df7af 100644
> >>> --- a/drivers/gpu/drm/drm_bridge.c
> >>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>   */
> >>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>  {
> >>> +	mutex_init(&bridge->hpd_mutex);
> >>> +
> >>>  	mutex_lock(&bridge_lock);
> >>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>  	mutex_unlock(&bridge_lock);
> >>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>  	mutex_lock(&bridge_lock);
> >>>  	list_del_init(&bridge->list);
> >>>  	mutex_unlock(&bridge_lock);
> >>> +
> >>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>  }
> >>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>  
> >>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>  }
> >>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>  
> >>> +/**
> >>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>> + * @bridge: bridge control structure
> >>> + * @cb: hot-plug detection callback
> >>> + * @data: data to be passed to the hot-plug detection callback
> >>> + *
> >>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>> + * hot plug notification callback. From now on the @cb will be called with
> >>> + * @data when an output status change is detected by the bridge, until hot plug
> >>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>> + *
> >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>> + *
> >>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>> + * error to call this function when hot plug detection is already enabled for
> >>> + * the bridge.
> >>> + */
> >>
> >> To simplify architecture maybe would be better to enable hpd just on
> >> bridge attach:
> >>
> >> bridge->hpd_cb = cb;
> >>
> >> bridge->hpd_data = data;
> >>
> >> ret = drm_bridge_attach(...);
> > Yeah I like this more. The other problem here is, what if you need more
> > than 1 callback registers on the same bridge hdp signal?
> >
> >
> >> This way we could avoid adding new callbacks hpd_(enable|disable)
> >> without big sacrifices.
> >>
> >>
> >> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >> notifies about sink status change, how it translates to this cb?
> >>
> >>
> >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>> +			   void (*cb)(void *data,
> >>> +				      enum drm_connector_status status),
> >>> +			   void *data)
> >>> +{
> >>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>> +		return;
> >>> +
> >>> +	mutex_lock(&bridge->hpd_mutex);
> >>> +
> >>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>> +		goto unlock;
> >>> +
> >>> +	bridge->hpd_cb = cb;
> >>> +	bridge->hpd_data = data;
> >>> +
> >>> +	bridge->funcs->hpd_enable(bridge);
> >>> +
> >>> +unlock:
> >>> +	mutex_unlock(&bridge->hpd_mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>> +
> >>> +/**
> >>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>> + * @bridge: bridge control structure
> >>> + *
> >>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>> + * function returns the callback will not be called by the bridge when an
> >>> + * output status change occurs.
> >>> + *
> >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>> + */
> >>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>> +{
> >>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>> +		return;
> >>> +
> >>> +	mutex_lock(&bridge->hpd_mutex);
> >>> +	bridge->funcs->hpd_disable(bridge);
> >>> +
> >>> +	bridge->hpd_cb = NULL;
> >>> +	bridge->hpd_data = NULL;
> >>> +	mutex_unlock(&bridge->hpd_mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>> +
> >>> +/**
> >>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>> + * @bridge: bridge control structure
> >>> + * @status: output connection status
> >>> + *
> >>> + * Bridge drivers shall call this function to report hot plug events when they
> >>> + * detect a change in the output status, when hot plug detection has been
> >>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>> + *
> >>> + * This function shall be called in a context that can sleep.
> >>> + */
> >>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>> +			   enum drm_connector_status status)
> >>> +{
> >>> +	mutex_lock(&bridge->hpd_mutex);
> >>> +	if (bridge->hpd_cb)
> >>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > So this isn't quite what I had in mind. Instead something like this:
> >
> > 	/* iterates over all bridges in the chain containing @bridge */
> > 	for_each_bridge(tmp_bridge, bridge) {
> > 		if (tmp_bridge == bridge)
> > 			continue;
> > 		if (bridge->hpd_notify);
> > 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > 	}
> >
> > 	encoder = encoder_for_bridge(bridge);
> > 	if (encoder->helper_private->bridge_hpd_notify)
> > 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >
> > 	dev = bridge->dev
> > 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >
> > No register callback needed, no locking needed, everyone gets exactly the
> > hpd they want/need.
> 
> 
> As I understand you want to notify every member of the pipeline.
> 
> I think it should be enough to notify only the source, and then source
> should decide if/when the hpd should be propagated upstream.
> 
> It looks more generic for me.

I'm not parsing ... do you think my idea is more generic and useful, or
the one from Laurent? Kinda confused here.
-Daniel

> 
> 
> Regards
> 
> Andrzej
> 
> 
> >
> >>> +	mutex_unlock(&bridge->hpd_mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>> +
> >>>  #ifdef CONFIG_OF
> >>>  /**
> >>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>> --- a/include/drm/drm_bridge.h
> >>> +++ b/include/drm/drm_bridge.h
> >>> @@ -23,8 +23,9 @@
> >>>  #ifndef __DRM_BRIDGE_H__
> >>>  #define __DRM_BRIDGE_H__
> >>>  
> >>> -#include <linux/list.h>
> >>>  #include <linux/ctype.h>
> >>> +#include <linux/list.h>
> >>> +#include <linux/mutex.h>
> >>>  #include <drm/drm_mode_object.h>
> >>>  #include <drm/drm_modes.h>
> >>>  
> >>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>  	 */
> >>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>  				    struct drm_atomic_state *state);
> >>> +
> >>> +	/**
> >>> +	 * @detect:
> >>> +	 *
> >>> +	 * Check if anything is attached to the bridge output.
> >>> +	 *
> >>> +	 * This callback is optional, if not implemented the bridge will be
> >>> +	 * considered as always having a component attached to its output.
> >>> +	 * Bridges that implement this callback shall set the
> >>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>> +	 *
> >>> +	 * RETURNS:
> >>> +	 *
> >>> +	 * drm_connector_status indicating the bridge output status.
> >>> +	 */
> >>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>> +
> >>> +	/**
> >>> +	 * @get_modes:
> >>> +	 *
> >>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>> +	 * with drm_mode_probed_add().
> >>> +	 *
> >>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>> +	 * displays such as many fixed panels. Bridges that support reading
> >>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>> +	 *
> >>> +	 * This callback is optional. Bridges that implement it shall set the
> >>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>> +	 *
> >>> +	 * RETURNS:
> >>> +	 *
> >>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>> +	 */
> >>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>> +			 struct drm_connector *connector);
> >>> +
> >>> +	/**
> >>> +	 * @get_edid:
> >>> +	 *
> >>> +	 * Read and parse the EDID data of the connected display.
> >>> +	 *
> >>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>> +	 * information for a display connected to the bridge output. Bridges
> >>> +	 * that support readind EDID shall implement this callback and leave
> >>> +	 * the @get_modes callback unimplemented.
> >>> +	 *
> >>> +	 * The caller of this operation shall first verify the output
> >>> +	 * connection status and refrain from reading EDID from a disconnected
> >>> +	 * output.
> >>> +	 *
> >>> +	 * This callback is optional. Bridges that implement it shall set the
> >>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>> +	 *
> >>> +	 * RETURNS:
> >>> +	 *
> >>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>> +	 * the returned edid structure with kfree().
> >>> +	 */
> >>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>> +				 struct drm_connector *connector);
> >>
> >> It overlaps with get_modes, I guess presence of one ops should disallow
> >> presence of another one?
> >>
> >> I am not really convinced we need this op at all, cannot we just assign
> >> some helper function to .get_modes cb, which will do the same?
> > Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > case, and require that if it has an edid it must fill out connector->info
> > and connector->edid correctly.
> >
> > Btw if a hpd happens, who's responible for making sure the edid/mode list
> > in the connector is up-to-date? With your current callback design that's
> > up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > should guarantee that it'll first walk the connectors to update status and
> > edid/mode list for the final drm_connector. And then instead of just
> > passing the simple "status", it'll pass the connector, with everything
> > correctly updated.
> >
> > Otherwise everyone interested in that hpd signal will go and re-fetch the
> > edid, which is not so awesome :-)
> > -Daniel
> >
> >>
> >> Regards
> >>
> >> Andrzej
> >>
> >>
> >>> +
> >>> +	/**
> >>> +	 * @lost_hotplug:
> >>> +	 *
> >>> +	 * Notify the bridge of display disconnection.
> >>> +	 *
> >>> +	 * This callback is optional, it may be implemented by bridges that
> >>> +	 * need to be notified of display disconnection for internal reasons.
> >>> +	 * One use case is to reset the internal state of CEC controllers for
> >>> +	 * HDMI bridges.
> >>> +	 */
> >>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>> +
> >>> +	/**
> >>> +	 * @hpd_enable:
> >>> +	 *
> >>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>> +	 * connection status, until hot plug detection gets disabled with
> >>> +	 * @hpd_disable.
> >>> +	 *
> >>> +	 * This callback is optional and shall only be implemented by bridges
> >>> +	 * that support hot-plug notification without polling. Bridges that
> >>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>> +	 */
> >>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>> +
> >>> +	/**
> >>> +	 * @hpd_disable:
> >>> +	 *
> >>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>> +	 * connection status occurs.
> >>> +	 *
> >>> +	 * This callback is optional and shall only be implemented by bridges
> >>> +	 * that support hot-plug notification without polling. Bridges that
> >>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>> +	 */
> >>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>  };
> >>>  
> >>>  /**
> >>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>  	bool dual_link;
> >>>  };
> >>>  
> >>> +/**
> >>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>> + */
> >>> +enum drm_bridge_ops {
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>> +	 * its output. Bridges that set this flag shall implement the
> >>> +	 * &drm_bridge_funcs->detect callback.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>> +	 * connected to its output. Bridges that set this flag shall implement
> >>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>> +	 * without requiring polling. Bridges that set this flag shall
> >>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>> +	 * by the display at its output. This does not include readind EDID
> >>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>> +};
> >>> +
> >>>  /**
> >>>   * struct drm_bridge - central DRM bridge control structure
> >>>   */
> >>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>  	const struct drm_bridge_funcs *funcs;
> >>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>  	void *driver_private;
> >>> +	/** @ops: bitmask of operations supported by the bridge */
> >>> +	enum drm_bridge_ops ops;
> >>> +	/**
> >>> +	 * @type: Type of the connection at the bridge output
> >>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>> +	 * identifies the type of connected display.
> >>> +	 */
> >>> +	int type;
> >>> +	/** private: */
> >>> +	/**
> >>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>> +	 */
> >>> +	struct mutex hpd_mutex;
> >>> +	/**
> >>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>> +	 * drm_bridge_hpd_enable().
> >>> +	 */
> >>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>> +	/**
> >>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>> +	 * @hpd_cb.
> >>> +	 */
> >>> +	void *hpd_data;
> >>>  };
> >>>  
> >>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>  			      struct drm_atomic_state *state);
> >>>  
> >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>> +			   void (*cb)(void *data,
> >>> +				      enum drm_connector_status status),
> >>> +			   void *data);
> >>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>> +			   enum drm_connector_status status);
> >>> +
> >>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>  					u32 connector_type);
> >>
>

Andrzej Hajda July 11, 2019, 3:12 p.m. UTC | #5

On 11.07.2019 15:18, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>> Hi Laurent,
>>>>
>>>>
>>>> I like the approach, current practice when almost every bridge should
>>>> optionally implement connector, or alternatively downstream bridge or
>>>> panel is very painful.
>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>> it's all used in the end. I probably should go and do that, at least to
>>> get a feeling for what your hpd_cb usually does.
>>>
>>>> More comments inlined.
>>>>
>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>> data:
>>>>>
>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>   retrieval operations
>>>>> - Bitmask of supported operations
>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>> operation's callback?
>>> Yeah also not a huge fan of these bitmasks. Smells like
>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>> add, generally good excuse to not have to think through the design between
>>> different parts of drivers - "just" add another flag.
>>>>> - Bridge output type
>>>>>
>>>>> Add and document these.
>>>>>
>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>> notification in a way that is as transparent as possible for the
>>>>> bridges.
>>>> Documentation of new opses does not explain how it should cooperate with
>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>> right? More comments about it later.
>>>>
>>>>
>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>> ---
>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>   */
>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>  {
>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>> +
>>>>>  	mutex_lock(&bridge_lock);
>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>  	mutex_unlock(&bridge_lock);
>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>  	mutex_lock(&bridge_lock);
>>>>>  	list_del_init(&bridge->list);
>>>>>  	mutex_unlock(&bridge_lock);
>>>>> +
>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>  }
>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>  
>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>  }
>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>  
>>>>> +/**
>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>> + * @bridge: bridge control structure
>>>>> + * @cb: hot-plug detection callback
>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>> + *
>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>> + *
>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>> + *
>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>> + * the bridge.
>>>>> + */
>>>> To simplify architecture maybe would be better to enable hpd just on
>>>> bridge attach:
>>>>
>>>> bridge->hpd_cb = cb;
>>>>
>>>> bridge->hpd_data = data;
>>>>
>>>> ret = drm_bridge_attach(...);
>>> Yeah I like this more. The other problem here is, what if you need more
>>> than 1 callback registers on the same bridge hdp signal?
>>>
>>>
>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>> without big sacrifices.
>>>>
>>>>
>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>> notifies about sink status change, how it translates to this cb?
>>>>
>>>>
>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>> +			   void (*cb)(void *data,
>>>>> +				      enum drm_connector_status status),
>>>>> +			   void *data)
>>>>> +{
>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>> +		return;
>>>>> +
>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>> +
>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>> +		goto unlock;
>>>>> +
>>>>> +	bridge->hpd_cb = cb;
>>>>> +	bridge->hpd_data = data;
>>>>> +
>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>> +
>>>>> +unlock:
>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>> +
>>>>> +/**
>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>> + * @bridge: bridge control structure
>>>>> + *
>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>> + * function returns the callback will not be called by the bridge when an
>>>>> + * output status change occurs.
>>>>> + *
>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>> + */
>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>> +{
>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>> +		return;
>>>>> +
>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>> +
>>>>> +	bridge->hpd_cb = NULL;
>>>>> +	bridge->hpd_data = NULL;
>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>> +
>>>>> +/**
>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>> + * @bridge: bridge control structure
>>>>> + * @status: output connection status
>>>>> + *
>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>> + *
>>>>> + * This function shall be called in a context that can sleep.
>>>>> + */
>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>> +			   enum drm_connector_status status)
>>>>> +{
>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>> +	if (bridge->hpd_cb)
>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>> So this isn't quite what I had in mind. Instead something like this:
>>>
>>> 	/* iterates over all bridges in the chain containing @bridge */
>>> 	for_each_bridge(tmp_bridge, bridge) {
>>> 		if (tmp_bridge == bridge)
>>> 			continue;
>>> 		if (bridge->hpd_notify);
>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>> 	}
>>>
>>> 	encoder = encoder_for_bridge(bridge);
>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>
>>> 	dev = bridge->dev
>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>
>>> No register callback needed, no locking needed, everyone gets exactly the
>>> hpd they want/need.
>>
>> As I understand you want to notify every member of the pipeline.
>>
>> I think it should be enough to notify only the source, and then source
>> should decide if/when the hpd should be propagated upstream.
>>
>> It looks more generic for me.
> I'm not parsing ... do you think my idea is more generic and useful, or
> the one from Laurent? Kinda confused here.


Regarding general idea:

1. Laurent's approach is to notify only consumer, I guess usually video
source.

2. Your is to notify all other bridges and encoder.


And I prefer 1st approach, why:

- the source can decide if/when and to who propagate the signal,

- is more generic, for example if bridge send signal to two
monitors/panels, it can delay hpd propagation till both sinks are present,

- it resembles hardware wires :)


And regarding implementation:

1. Laurent proposes to register callback drm_bridge_hpd_enable.

2. You propose to add ops hpd_notify in bridges and encoders.


Your proposition is more straightforward, but if we want to notify only
source we should locate it by parsing notification chain (what about
unchained bridges), or store pointer somewhere during attachment.

It still leaves us with this ugly dualism - source is encoder or bridge,
similarly to sink as bridge or panel, but fixing it can be done later.


Regards

Andrzej


> -Daniel
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>> +
>>>>>  #ifdef CONFIG_OF
>>>>>  /**
>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>> --- a/include/drm/drm_bridge.h
>>>>> +++ b/include/drm/drm_bridge.h
>>>>> @@ -23,8 +23,9 @@
>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>  #define __DRM_BRIDGE_H__
>>>>>  
>>>>> -#include <linux/list.h>
>>>>>  #include <linux/ctype.h>
>>>>> +#include <linux/list.h>
>>>>> +#include <linux/mutex.h>
>>>>>  #include <drm/drm_mode_object.h>
>>>>>  #include <drm/drm_modes.h>
>>>>>  
>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>  	 */
>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>  				    struct drm_atomic_state *state);
>>>>> +
>>>>> +	/**
>>>>> +	 * @detect:
>>>>> +	 *
>>>>> +	 * Check if anything is attached to the bridge output.
>>>>> +	 *
>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>> +	 * considered as always having a component attached to its output.
>>>>> +	 * Bridges that implement this callback shall set the
>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>> +	 *
>>>>> +	 * RETURNS:
>>>>> +	 *
>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>> +	 */
>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>> +
>>>>> +	/**
>>>>> +	 * @get_modes:
>>>>> +	 *
>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>> +	 * with drm_mode_probed_add().
>>>>> +	 *
>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>> +	 *
>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>> +	 *
>>>>> +	 * RETURNS:
>>>>> +	 *
>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>> +	 */
>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>> +			 struct drm_connector *connector);
>>>>> +
>>>>> +	/**
>>>>> +	 * @get_edid:
>>>>> +	 *
>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>> +	 *
>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>> +	 * the @get_modes callback unimplemented.
>>>>> +	 *
>>>>> +	 * The caller of this operation shall first verify the output
>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>> +	 * output.
>>>>> +	 *
>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>> +	 *
>>>>> +	 * RETURNS:
>>>>> +	 *
>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>> +	 * the returned edid structure with kfree().
>>>>> +	 */
>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>> +				 struct drm_connector *connector);
>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>> presence of another one?
>>>>
>>>> I am not really convinced we need this op at all, cannot we just assign
>>>> some helper function to .get_modes cb, which will do the same?
>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>> case, and require that if it has an edid it must fill out connector->info
>>> and connector->edid correctly.
>>>
>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>> in the connector is up-to-date? With your current callback design that's
>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>> should guarantee that it'll first walk the connectors to update status and
>>> edid/mode list for the final drm_connector. And then instead of just
>>> passing the simple "status", it'll pass the connector, with everything
>>> correctly updated.
>>>
>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>> edid, which is not so awesome :-)
>>> -Daniel
>>>
>>>> Regards
>>>>
>>>> Andrzej
>>>>
>>>>
>>>>> +
>>>>> +	/**
>>>>> +	 * @lost_hotplug:
>>>>> +	 *
>>>>> +	 * Notify the bridge of display disconnection.
>>>>> +	 *
>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>> +	 * HDMI bridges.
>>>>> +	 */
>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>> +
>>>>> +	/**
>>>>> +	 * @hpd_enable:
>>>>> +	 *
>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>> +	 * @hpd_disable.
>>>>> +	 *
>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>> +	 */
>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>> +
>>>>> +	/**
>>>>> +	 * @hpd_disable:
>>>>> +	 *
>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>> +	 * connection status occurs.
>>>>> +	 *
>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>> +	 */
>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>  };
>>>>>  
>>>>>  /**
>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>  	bool dual_link;
>>>>>  };
>>>>>  
>>>>> +/**
>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>> + */
>>>>> +enum drm_bridge_ops {
>>>>> +	/**
>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>> +	 */
>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>> +	/**
>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>> +	 */
>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>> +	/**
>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>> +	 */
>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>> +	/**
>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>> +	 */
>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>> +};
>>>>> +
>>>>>  /**
>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>   */
>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>  	void *driver_private;
>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>> +	enum drm_bridge_ops ops;
>>>>> +	/**
>>>>> +	 * @type: Type of the connection at the bridge output
>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>> +	 * identifies the type of connected display.
>>>>> +	 */
>>>>> +	int type;
>>>>> +	/** private: */
>>>>> +	/**
>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>> +	 */
>>>>> +	struct mutex hpd_mutex;
>>>>> +	/**
>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>> +	 * drm_bridge_hpd_enable().
>>>>> +	 */
>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>> +	/**
>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>> +	 * @hpd_cb.
>>>>> +	 */
>>>>> +	void *hpd_data;
>>>>>  };
>>>>>  
>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>  			      struct drm_atomic_state *state);
>>>>>  
>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>> +			   void (*cb)(void *data,
>>>>> +				      enum drm_connector_status status),
>>>>> +			   void *data);
>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>> +			   enum drm_connector_status status);
>>>>> +
>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>  					u32 connector_type);

Daniel Vetter July 11, 2019, 3:50 p.m. UTC | #6

On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> On 11.07.2019 15:18, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>> Hi Laurent,
> >>>>
> >>>>
> >>>> I like the approach, current practice when almost every bridge should
> >>>> optionally implement connector, or alternatively downstream bridge or
> >>>> panel is very painful.
> >>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>> it's all used in the end. I probably should go and do that, at least to
> >>> get a feeling for what your hpd_cb usually does.
> >>>
> >>>> More comments inlined.
> >>>>
> >>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>> data:
> >>>>>
> >>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>   retrieval operations
> >>>>> - Bitmask of supported operations
> >>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>> operation's callback?
> >>> Yeah also not a huge fan of these bitmasks. Smells like
> >>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>> add, generally good excuse to not have to think through the design between
> >>> different parts of drivers - "just" add another flag.
> >>>>> - Bridge output type
> >>>>>
> >>>>> Add and document these.
> >>>>>
> >>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>> notification in a way that is as transparent as possible for the
> >>>>> bridges.
> >>>> Documentation of new opses does not explain how it should cooperate with
> >>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>> right? More comments about it later.
> >>>>
> >>>>
> >>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>> ---
> >>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>   */
> >>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>  {
> >>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>> +
> >>>>>  	mutex_lock(&bridge_lock);
> >>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>  	mutex_unlock(&bridge_lock);
> >>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>  	mutex_lock(&bridge_lock);
> >>>>>  	list_del_init(&bridge->list);
> >>>>>  	mutex_unlock(&bridge_lock);
> >>>>> +
> >>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>  }
> >>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>  
> >>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>  }
> >>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>  
> >>>>> +/**
> >>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>> + * @bridge: bridge control structure
> >>>>> + * @cb: hot-plug detection callback
> >>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>> + *
> >>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>> + *
> >>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>> + *
> >>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>> + * the bridge.
> >>>>> + */
> >>>> To simplify architecture maybe would be better to enable hpd just on
> >>>> bridge attach:
> >>>>
> >>>> bridge->hpd_cb = cb;
> >>>>
> >>>> bridge->hpd_data = data;
> >>>>
> >>>> ret = drm_bridge_attach(...);
> >>> Yeah I like this more. The other problem here is, what if you need more
> >>> than 1 callback registers on the same bridge hdp signal?
> >>>
> >>>
> >>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>> without big sacrifices.
> >>>>
> >>>>
> >>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>> notifies about sink status change, how it translates to this cb?
> >>>>
> >>>>
> >>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>> +			   void (*cb)(void *data,
> >>>>> +				      enum drm_connector_status status),
> >>>>> +			   void *data)
> >>>>> +{
> >>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>> +		return;
> >>>>> +
> >>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>> +
> >>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>> +		goto unlock;
> >>>>> +
> >>>>> +	bridge->hpd_cb = cb;
> >>>>> +	bridge->hpd_data = data;
> >>>>> +
> >>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>> +
> >>>>> +unlock:
> >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>> +
> >>>>> +/**
> >>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>> + * @bridge: bridge control structure
> >>>>> + *
> >>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>> + * function returns the callback will not be called by the bridge when an
> >>>>> + * output status change occurs.
> >>>>> + *
> >>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>> + */
> >>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>> +{
> >>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>> +		return;
> >>>>> +
> >>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>> +
> >>>>> +	bridge->hpd_cb = NULL;
> >>>>> +	bridge->hpd_data = NULL;
> >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>> +
> >>>>> +/**
> >>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>> + * @bridge: bridge control structure
> >>>>> + * @status: output connection status
> >>>>> + *
> >>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>> + *
> >>>>> + * This function shall be called in a context that can sleep.
> >>>>> + */
> >>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>> +			   enum drm_connector_status status)
> >>>>> +{
> >>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>> +	if (bridge->hpd_cb)
> >>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>> So this isn't quite what I had in mind. Instead something like this:
> >>>
> >>> 	/* iterates over all bridges in the chain containing @bridge */
> >>> 	for_each_bridge(tmp_bridge, bridge) {
> >>> 		if (tmp_bridge == bridge)
> >>> 			continue;
> >>> 		if (bridge->hpd_notify);
> >>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>> 	}
> >>>
> >>> 	encoder = encoder_for_bridge(bridge);
> >>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>
> >>> 	dev = bridge->dev
> >>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>
> >>> No register callback needed, no locking needed, everyone gets exactly the
> >>> hpd they want/need.
> >>
> >> As I understand you want to notify every member of the pipeline.
> >>
> >> I think it should be enough to notify only the source, and then source
> >> should decide if/when the hpd should be propagated upstream.
> >>
> >> It looks more generic for me.
> > I'm not parsing ... do you think my idea is more generic and useful, or
> > the one from Laurent? Kinda confused here.
> 
> 
> Regarding general idea:
> 
> 1. Laurent's approach is to notify only consumer, I guess usually video
> source.
> 
> 2. Your is to notify all other bridges and encoder.
> 
> 
> And I prefer 1st approach, why:
> 
> - the source can decide if/when and to who propagate the signal,
> 
> - is more generic, for example if bridge send signal to two
> monitors/panels, it can delay hpd propagation till both sinks are present,

With Laurent's approach the bridge cannot send the hpd to more than one
consumer. There's only 1 callback. So you're example doesn't work.

> - it resembles hardware wires :)

This isn't for the hw wires afaiui. The hw hpd terminates in the source
bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
interested in that hpd singal. This includes:
- Other bridges, e.g. if they provide CEC support.
- Other bridges, maybe they need to re-run the HDCP state engine
- Overall driver, so it can update the modes/connector status and send the
  uevent to the driver.
- Overall display pipeline for this specific bridge, maybe you need to
  shut down/re-enable the pipe because $reasons.
 
That's at least my understanding from lots of chats with Laurent about
what he wants to do here.

> And regarding implementation:
> 
> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> 
> 2. You propose to add ops hpd_notify in bridges and encoders.
> 
> 
> Your proposition is more straightforward, but if we want to notify only
> source we should locate it by parsing notification chain (what about
> unchained bridges), or store pointer somewhere during attachment.
> 
> It still leaves us with this ugly dualism - source is encoder or bridge,
> similarly to sink as bridge or panel, but fixing it can be done later.

Uh I think we're not talking about the same thing really. My understanding
is that this callback is if someone (outside of this bridge) is interested
in a hpd signal _from_ this bridge. Which means you can only ever have 1
listener.

You seem to have some other idea here.
-Daniel

> 
> 
> Regards
> 
> Andrzej
> 
> 
> > -Daniel
> >
> >>
> >> Regards
> >>
> >> Andrzej
> >>
> >>
> >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>> +
> >>>>>  #ifdef CONFIG_OF
> >>>>>  /**
> >>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>> --- a/include/drm/drm_bridge.h
> >>>>> +++ b/include/drm/drm_bridge.h
> >>>>> @@ -23,8 +23,9 @@
> >>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>  #define __DRM_BRIDGE_H__
> >>>>>  
> >>>>> -#include <linux/list.h>
> >>>>>  #include <linux/ctype.h>
> >>>>> +#include <linux/list.h>
> >>>>> +#include <linux/mutex.h>
> >>>>>  #include <drm/drm_mode_object.h>
> >>>>>  #include <drm/drm_modes.h>
> >>>>>  
> >>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>  	 */
> >>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>  				    struct drm_atomic_state *state);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @detect:
> >>>>> +	 *
> >>>>> +	 * Check if anything is attached to the bridge output.
> >>>>> +	 *
> >>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>> +	 * considered as always having a component attached to its output.
> >>>>> +	 * Bridges that implement this callback shall set the
> >>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>> +	 *
> >>>>> +	 * RETURNS:
> >>>>> +	 *
> >>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>> +	 */
> >>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @get_modes:
> >>>>> +	 *
> >>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>> +	 * with drm_mode_probed_add().
> >>>>> +	 *
> >>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>> +	 *
> >>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>> +	 *
> >>>>> +	 * RETURNS:
> >>>>> +	 *
> >>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>> +	 */
> >>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>> +			 struct drm_connector *connector);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @get_edid:
> >>>>> +	 *
> >>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>> +	 *
> >>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>> +	 * the @get_modes callback unimplemented.
> >>>>> +	 *
> >>>>> +	 * The caller of this operation shall first verify the output
> >>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>> +	 * output.
> >>>>> +	 *
> >>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>> +	 *
> >>>>> +	 * RETURNS:
> >>>>> +	 *
> >>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>> +	 * the returned edid structure with kfree().
> >>>>> +	 */
> >>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>> +				 struct drm_connector *connector);
> >>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>> presence of another one?
> >>>>
> >>>> I am not really convinced we need this op at all, cannot we just assign
> >>>> some helper function to .get_modes cb, which will do the same?
> >>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>> case, and require that if it has an edid it must fill out connector->info
> >>> and connector->edid correctly.
> >>>
> >>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>> in the connector is up-to-date? With your current callback design that's
> >>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>> should guarantee that it'll first walk the connectors to update status and
> >>> edid/mode list for the final drm_connector. And then instead of just
> >>> passing the simple "status", it'll pass the connector, with everything
> >>> correctly updated.
> >>>
> >>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>> edid, which is not so awesome :-)
> >>> -Daniel
> >>>
> >>>> Regards
> >>>>
> >>>> Andrzej
> >>>>
> >>>>
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @lost_hotplug:
> >>>>> +	 *
> >>>>> +	 * Notify the bridge of display disconnection.
> >>>>> +	 *
> >>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>> +	 * HDMI bridges.
> >>>>> +	 */
> >>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @hpd_enable:
> >>>>> +	 *
> >>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>> +	 * @hpd_disable.
> >>>>> +	 *
> >>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>> +	 */
> >>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @hpd_disable:
> >>>>> +	 *
> >>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>> +	 * connection status occurs.
> >>>>> +	 *
> >>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>> +	 */
> >>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>  };
> >>>>>  
> >>>>>  /**
> >>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>  	bool dual_link;
> >>>>>  };
> >>>>>  
> >>>>> +/**
> >>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>> + */
> >>>>> +enum drm_bridge_ops {
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>> +};
> >>>>> +
> >>>>>  /**
> >>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>   */
> >>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>  	void *driver_private;
> >>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>> +	enum drm_bridge_ops ops;
> >>>>> +	/**
> >>>>> +	 * @type: Type of the connection at the bridge output
> >>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>> +	 * identifies the type of connected display.
> >>>>> +	 */
> >>>>> +	int type;
> >>>>> +	/** private: */
> >>>>> +	/**
> >>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>> +	 */
> >>>>> +	struct mutex hpd_mutex;
> >>>>> +	/**
> >>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>> +	 * drm_bridge_hpd_enable().
> >>>>> +	 */
> >>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>> +	/**
> >>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>> +	 * @hpd_cb.
> >>>>> +	 */
> >>>>> +	void *hpd_data;
> >>>>>  };
> >>>>>  
> >>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>  			      struct drm_atomic_state *state);
> >>>>>  
> >>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>> +			   void (*cb)(void *data,
> >>>>> +				      enum drm_connector_status status),
> >>>>> +			   void *data);
> >>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>> +			   enum drm_connector_status status);
> >>>>> +
> >>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>  					u32 connector_type);
> 
>

Andrzej Hajda July 12, 2019, 9:01 a.m. UTC | #7

On 11.07.2019 17:50, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>> Hi Laurent,
>>>>>>
>>>>>>
>>>>>> I like the approach, current practice when almost every bridge should
>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>> panel is very painful.
>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>> get a feeling for what your hpd_cb usually does.
>>>>>
>>>>>> More comments inlined.
>>>>>>
>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>> data:
>>>>>>>
>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>   retrieval operations
>>>>>>> - Bitmask of supported operations
>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>> operation's callback?
>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>> add, generally good excuse to not have to think through the design between
>>>>> different parts of drivers - "just" add another flag.
>>>>>>> - Bridge output type
>>>>>>>
>>>>>>> Add and document these.
>>>>>>>
>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>> bridges.
>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>> right? More comments about it later.
>>>>>>
>>>>>>
>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>> ---
>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>   */
>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>  {
>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>> +
>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>> +
>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>  
>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>  }
>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>  
>>>>>>> +/**
>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>> + * @bridge: bridge control structure
>>>>>>> + * @cb: hot-plug detection callback
>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>> + *
>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>> + *
>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>> + *
>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>> + * the bridge.
>>>>>>> + */
>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>> bridge attach:
>>>>>>
>>>>>> bridge->hpd_cb = cb;
>>>>>>
>>>>>> bridge->hpd_data = data;
>>>>>>
>>>>>> ret = drm_bridge_attach(...);
>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>
>>>>>
>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>> without big sacrifices.
>>>>>>
>>>>>>
>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>
>>>>>>
>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>> +			   void (*cb)(void *data,
>>>>>>> +				      enum drm_connector_status status),
>>>>>>> +			   void *data)
>>>>>>> +{
>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>> +		return;
>>>>>>> +
>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>> +
>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>> +		goto unlock;
>>>>>>> +
>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>> +	bridge->hpd_data = data;
>>>>>>> +
>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>> +
>>>>>>> +unlock:
>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>> +}
>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>> + * @bridge: bridge control structure
>>>>>>> + *
>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>> + * output status change occurs.
>>>>>>> + *
>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>> + */
>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>> +{
>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>> +		return;
>>>>>>> +
>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>> +
>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>> +}
>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>> + * @bridge: bridge control structure
>>>>>>> + * @status: output connection status
>>>>>>> + *
>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>> + *
>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>> + */
>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>> +			   enum drm_connector_status status)
>>>>>>> +{
>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>> +	if (bridge->hpd_cb)
>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>
>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>> 		if (tmp_bridge == bridge)
>>>>> 			continue;
>>>>> 		if (bridge->hpd_notify);
>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>> 	}
>>>>>
>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>
>>>>> 	dev = bridge->dev
>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>
>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>> hpd they want/need.
>>>> As I understand you want to notify every member of the pipeline.
>>>>
>>>> I think it should be enough to notify only the source, and then source
>>>> should decide if/when the hpd should be propagated upstream.
>>>>
>>>> It looks more generic for me.
>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>> the one from Laurent? Kinda confused here.
>>
>> Regarding general idea:
>>
>> 1. Laurent's approach is to notify only consumer, I guess usually video
>> source.
>>
>> 2. Your is to notify all other bridges and encoder.
>>
>>
>> And I prefer 1st approach, why:
>>
>> - the source can decide if/when and to who propagate the signal,
>>
>> - is more generic, for example if bridge send signal to two
>> monitors/panels, it can delay hpd propagation till both sinks are present,
> With Laurent's approach the bridge cannot send the hpd to more than one
> consumer. There's only 1 callback. So you're example doesn't work.


If there will be two consumers, there will be two bridge attachments,
thus there will be two notifications, it should work.


>
>> - it resembles hardware wires :)
> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> interested in that hpd singal. This includes:
> - Other bridges, e.g. if they provide CEC support.
> - Other bridges, maybe they need to re-run the HDCP state engine
> - Overall driver, so it can update the modes/connector status and send the
>   uevent to the driver.
> - Overall display pipeline for this specific bridge, maybe you need to
>   shut down/re-enable the pipe because $reasons.
>  
> That's at least my understanding from lots of chats with Laurent about
> what he wants to do here.


I do not know the full picture, but the solution where particular bridge
notifies everything unconditionally seems to me much less flexible.

If HPD signals is received by the consumer, if there are no obstacles it
can propagate it further, upstream bridge/encoder or to drm core - it
will mimic your scenario.

But there are also other scenarios where bridge does not want to
propagate signal, because for example:

- it wants to wait for other sinks to wake up,

- it propagates HPD signal via hardware wire,

- first it wants to verify if the sink is valid/compatible/authorized
device.


In general HPD is input signal for notify of state changes on particular
bus, in case of typical video bridge on its output video bus.

In case of bridges they have also input video buses, and they can send
HPD signal via this bus, but this is indeed different HPD signal, even
if for most cases they looks similar.


>
>> And regarding implementation:
>>
>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>
>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>
>>
>> Your proposition is more straightforward, but if we want to notify only
>> source we should locate it by parsing notification chain (what about
>> unchained bridges), or store pointer somewhere during attachment.
>>
>> It still leaves us with this ugly dualism - source is encoder or bridge,
>> similarly to sink as bridge or panel, but fixing it can be done later.
> Uh I think we're not talking about the same thing really. My understanding
> is that this callback is if someone (outside of this bridge) is interested
> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> listener.


Do we have real life examples?

I want to distinguish two situations:

- another device wants to know if input bus of the bridge has changed state,

- another device wants to know if output bus of the bridge has changed
state.


Regards

Andrzej


>
> You seem to have some other idea here.
> -Daniel
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>> -Daniel
>>>
>>>> Regards
>>>>
>>>> Andrzej
>>>>
>>>>
>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>> +}
>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>> +
>>>>>>>  #ifdef CONFIG_OF
>>>>>>>  /**
>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>  
>>>>>>> -#include <linux/list.h>
>>>>>>>  #include <linux/ctype.h>
>>>>>>> +#include <linux/list.h>
>>>>>>> +#include <linux/mutex.h>
>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>  
>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>  	 */
>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>> +
>>>>>>> +	/**
>>>>>>> +	 * @detect:
>>>>>>> +	 *
>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>> +	 *
>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>> +	 *
>>>>>>> +	 * RETURNS:
>>>>>>> +	 *
>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>> +	 */
>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>> +
>>>>>>> +	/**
>>>>>>> +	 * @get_modes:
>>>>>>> +	 *
>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>> +	 *
>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>> +	 *
>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>> +	 *
>>>>>>> +	 * RETURNS:
>>>>>>> +	 *
>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>> +	 */
>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>> +			 struct drm_connector *connector);
>>>>>>> +
>>>>>>> +	/**
>>>>>>> +	 * @get_edid:
>>>>>>> +	 *
>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>> +	 *
>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>> +	 *
>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>> +	 * output.
>>>>>>> +	 *
>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>> +	 *
>>>>>>> +	 * RETURNS:
>>>>>>> +	 *
>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>> +	 */
>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>> +				 struct drm_connector *connector);
>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>> presence of another one?
>>>>>>
>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>> and connector->edid correctly.
>>>>>
>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>> in the connector is up-to-date? With your current callback design that's
>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>> correctly updated.
>>>>>
>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>> edid, which is not so awesome :-)
>>>>> -Daniel
>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Andrzej
>>>>>>
>>>>>>
>>>>>>> +
>>>>>>> +	/**
>>>>>>> +	 * @lost_hotplug:
>>>>>>> +	 *
>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>> +	 *
>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>> +	 * HDMI bridges.
>>>>>>> +	 */
>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>> +
>>>>>>> +	/**
>>>>>>> +	 * @hpd_enable:
>>>>>>> +	 *
>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>> +	 * @hpd_disable.
>>>>>>> +	 *
>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>> +	 */
>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>> +
>>>>>>> +	/**
>>>>>>> +	 * @hpd_disable:
>>>>>>> +	 *
>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>> +	 * connection status occurs.
>>>>>>> +	 *
>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>> +	 */
>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>  };
>>>>>>>  
>>>>>>>  /**
>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>  	bool dual_link;
>>>>>>>  };
>>>>>>>  
>>>>>>> +/**
>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>> + */
>>>>>>> +enum drm_bridge_ops {
>>>>>>> +	/**
>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>> +	 */
>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>> +	/**
>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>> +	 */
>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>> +	/**
>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>> +	 */
>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>> +	/**
>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>> +	 */
>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>> +};
>>>>>>> +
>>>>>>>  /**
>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>   */
>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>  	void *driver_private;
>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>> +	/**
>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>> +	 * identifies the type of connected display.
>>>>>>> +	 */
>>>>>>> +	int type;
>>>>>>> +	/** private: */
>>>>>>> +	/**
>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>> +	 */
>>>>>>> +	struct mutex hpd_mutex;
>>>>>>> +	/**
>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>> +	 */
>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>> +	/**
>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>> +	 * @hpd_cb.
>>>>>>> +	 */
>>>>>>> +	void *hpd_data;
>>>>>>>  };
>>>>>>>  
>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>  
>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>> +			   void (*cb)(void *data,
>>>>>>> +				      enum drm_connector_status status),
>>>>>>> +			   void *data);
>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>> +			   enum drm_connector_status status);
>>>>>>> +
>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>  					u32 connector_type);
>>

Daniel Vetter July 16, 2019, 9 a.m. UTC | #8

On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> On 11.07.2019 17:50, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>> Hi Laurent,
> >>>>>>
> >>>>>>
> >>>>>> I like the approach, current practice when almost every bridge should
> >>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>> panel is very painful.
> >>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>> get a feeling for what your hpd_cb usually does.
> >>>>>
> >>>>>> More comments inlined.
> >>>>>>
> >>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>> data:
> >>>>>>>
> >>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>   retrieval operations
> >>>>>>> - Bitmask of supported operations
> >>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>> operation's callback?
> >>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>> add, generally good excuse to not have to think through the design between
> >>>>> different parts of drivers - "just" add another flag.
> >>>>>>> - Bridge output type
> >>>>>>>
> >>>>>>> Add and document these.
> >>>>>>>
> >>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>> bridges.
> >>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>> right? More comments about it later.
> >>>>>>
> >>>>>>
> >>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>> ---
> >>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>   */
> >>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>  {
> >>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>> +
> >>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>> +
> >>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>  }
> >>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>  
> >>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>  }
> >>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>  
> >>>>>>> +/**
> >>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>> + * @bridge: bridge control structure
> >>>>>>> + * @cb: hot-plug detection callback
> >>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>> + *
> >>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>> + *
> >>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>> + *
> >>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>> + * the bridge.
> >>>>>>> + */
> >>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>> bridge attach:
> >>>>>>
> >>>>>> bridge->hpd_cb = cb;
> >>>>>>
> >>>>>> bridge->hpd_data = data;
> >>>>>>
> >>>>>> ret = drm_bridge_attach(...);
> >>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>
> >>>>>
> >>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>> without big sacrifices.
> >>>>>>
> >>>>>>
> >>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>
> >>>>>>
> >>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>> +			   void (*cb)(void *data,
> >>>>>>> +				      enum drm_connector_status status),
> >>>>>>> +			   void *data)
> >>>>>>> +{
> >>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>> +		return;
> >>>>>>> +
> >>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>> +
> >>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>> +		goto unlock;
> >>>>>>> +
> >>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>> +	bridge->hpd_data = data;
> >>>>>>> +
> >>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>> +
> >>>>>>> +unlock:
> >>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>> +}
> >>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>> +
> >>>>>>> +/**
> >>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>> + * @bridge: bridge control structure
> >>>>>>> + *
> >>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>> + * output status change occurs.
> >>>>>>> + *
> >>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>> + */
> >>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>> +{
> >>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>> +		return;
> >>>>>>> +
> >>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>> +
> >>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>> +}
> >>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>> +
> >>>>>>> +/**
> >>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>> + * @bridge: bridge control structure
> >>>>>>> + * @status: output connection status
> >>>>>>> + *
> >>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>> + *
> >>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>> + */
> >>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>> +			   enum drm_connector_status status)
> >>>>>>> +{
> >>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>> +	if (bridge->hpd_cb)
> >>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>
> >>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>> 		if (tmp_bridge == bridge)
> >>>>> 			continue;
> >>>>> 		if (bridge->hpd_notify);
> >>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>> 	}
> >>>>>
> >>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>
> >>>>> 	dev = bridge->dev
> >>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>
> >>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>> hpd they want/need.
> >>>> As I understand you want to notify every member of the pipeline.
> >>>>
> >>>> I think it should be enough to notify only the source, and then source
> >>>> should decide if/when the hpd should be propagated upstream.
> >>>>
> >>>> It looks more generic for me.
> >>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>> the one from Laurent? Kinda confused here.
> >>
> >> Regarding general idea:
> >>
> >> 1. Laurent's approach is to notify only consumer, I guess usually video
> >> source.
> >>
> >> 2. Your is to notify all other bridges and encoder.
> >>
> >>
> >> And I prefer 1st approach, why:
> >>
> >> - the source can decide if/when and to who propagate the signal,
> >>
> >> - is more generic, for example if bridge send signal to two
> >> monitors/panels, it can delay hpd propagation till both sinks are present,
> > With Laurent's approach the bridge cannot send the hpd to more than one
> > consumer. There's only 1 callback. So you're example doesn't work.
> 
> 
> If there will be two consumers, there will be two bridge attachments,
> thus there will be two notifications, it should work.

2 consumers, 1 producer. There's only _one_ callback in the producer. The
callback is registered on the produce bridge, not on the consumer bridge
(or I'm totallly misreading what Laurent does here).

> >> - it resembles hardware wires :)
> > This isn't for the hw wires afaiui. The hw hpd terminates in the source
> > bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> > interested in that hpd singal. This includes:
> > - Other bridges, e.g. if they provide CEC support.
> > - Other bridges, maybe they need to re-run the HDCP state engine
> > - Overall driver, so it can update the modes/connector status and send the
> >   uevent to the driver.
> > - Overall display pipeline for this specific bridge, maybe you need to
> >   shut down/re-enable the pipe because $reasons.
> >  
> > That's at least my understanding from lots of chats with Laurent about
> > what he wants to do here.
> 
> 
> I do not know the full picture, but the solution where particular bridge
> notifies everything unconditionally seems to me much less flexible.
> 
> If HPD signals is received by the consumer, if there are no obstacles it
> can propagate it further, upstream bridge/encoder or to drm core - it
> will mimic your scenario.
> 
> But there are also other scenarios where bridge does not want to
> propagate signal, because for example:
> 
> - it wants to wait for other sinks to wake up,

The other sink can just do that in their hpd callback.

> - it propagates HPD signal via hardware wire,

Again, the other sink can just not listen to sw hpd in that case, and use
the wire/hw hpd interrupt.

> - first it wants to verify if the sink is valid/compatible/authorized
> device.

Now you lost me. Why would someone glue incompatible IP into a SoC or
board?

> In general HPD is input signal for notify of state changes on particular
> bus, in case of typical video bridge on its output video bus.
> 
> In case of bridges they have also input video buses, and they can send
> HPD signal via this bus, but this is indeed different HPD signal, even
> if for most cases they looks similar.

Ah, I think this is a problem we will eventually have. But it's not
something we're currently solving here at all I think.

> >> And regarding implementation:
> >>
> >> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>
> >> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>
> >>
> >> Your proposition is more straightforward, but if we want to notify only
> >> source we should locate it by parsing notification chain (what about
> >> unchained bridges), or store pointer somewhere during attachment.
> >>
> >> It still leaves us with this ugly dualism - source is encoder or bridge,
> >> similarly to sink as bridge or panel, but fixing it can be done later.
> > Uh I think we're not talking about the same thing really. My understanding
> > is that this callback is if someone (outside of this bridge) is interested
> > in a hpd signal _from_ this bridge. Which means you can only ever have 1
> > listener.
> 
> 
> Do we have real life examples?
> 
> I want to distinguish two situations:
> 
> - another device wants to know if input bus of the bridge has changed state,
> 
> - another device wants to know if output bus of the bridge has changed
> state.

Uh, that's what drm_bridge_state is for (if it ever happens). That's how
bridges can exchange state and information about each another. hpd is
about the physical world, i.e. "is there a cable plugged into the port
I'm driving?". We're not going to use fake hpd to update bridge state and
fun stuff like that, we have the atomic_check machinery for this.
-Daniel

>
> 
> Regards
> 
> Andrzej
> 
> 
> >
> > You seem to have some other idea here.
> > -Daniel
> >
> >>
> >> Regards
> >>
> >> Andrzej
> >>
> >>
> >>> -Daniel
> >>>
> >>>> Regards
> >>>>
> >>>> Andrzej
> >>>>
> >>>>
> >>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>> +}
> >>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>> +
> >>>>>>>  #ifdef CONFIG_OF
> >>>>>>>  /**
> >>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>  
> >>>>>>> -#include <linux/list.h>
> >>>>>>>  #include <linux/ctype.h>
> >>>>>>> +#include <linux/list.h>
> >>>>>>> +#include <linux/mutex.h>
> >>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>  
> >>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>  	 */
> >>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @detect:
> >>>>>>> +	 *
> >>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>> +	 *
> >>>>>>> +	 * RETURNS:
> >>>>>>> +	 *
> >>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>> +	 */
> >>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @get_modes:
> >>>>>>> +	 *
> >>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>> +	 *
> >>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>> +	 *
> >>>>>>> +	 * RETURNS:
> >>>>>>> +	 *
> >>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>> +	 */
> >>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>> +			 struct drm_connector *connector);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @get_edid:
> >>>>>>> +	 *
> >>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>> +	 *
> >>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>> +	 *
> >>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>> +	 * output.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>> +	 *
> >>>>>>> +	 * RETURNS:
> >>>>>>> +	 *
> >>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>> +	 */
> >>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>> +				 struct drm_connector *connector);
> >>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>> presence of another one?
> >>>>>>
> >>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>> and connector->edid correctly.
> >>>>>
> >>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>> in the connector is up-to-date? With your current callback design that's
> >>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>> correctly updated.
> >>>>>
> >>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>> edid, which is not so awesome :-)
> >>>>> -Daniel
> >>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> Andrzej
> >>>>>>
> >>>>>>
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @lost_hotplug:
> >>>>>>> +	 *
> >>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>> +	 * HDMI bridges.
> >>>>>>> +	 */
> >>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_enable:
> >>>>>>> +	 *
> >>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>> +	 * @hpd_disable.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>> +	 */
> >>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_disable:
> >>>>>>> +	 *
> >>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>> +	 * connection status occurs.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>> +	 */
> >>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>  };
> >>>>>>>  
> >>>>>>>  /**
> >>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>  	bool dual_link;
> >>>>>>>  };
> >>>>>>>  
> >>>>>>> +/**
> >>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>> + */
> >>>>>>> +enum drm_bridge_ops {
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>> +};
> >>>>>>> +
> >>>>>>>  /**
> >>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>   */
> >>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>  	void *driver_private;
> >>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>> +	/**
> >>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>> +	 * identifies the type of connected display.
> >>>>>>> +	 */
> >>>>>>> +	int type;
> >>>>>>> +	/** private: */
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>> +	 */
> >>>>>>> +	struct mutex hpd_mutex;
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>> +	 */
> >>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>> +	 * @hpd_cb.
> >>>>>>> +	 */
> >>>>>>> +	void *hpd_data;
> >>>>>>>  };
> >>>>>>>  
> >>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>  
> >>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>> +			   void (*cb)(void *data,
> >>>>>>> +				      enum drm_connector_status status),
> >>>>>>> +			   void *data);
> >>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>> +			   enum drm_connector_status status);
> >>>>>>> +
> >>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>  					u32 connector_type);
> >>
>

Andrzej Hajda July 16, 2019, 1:57 p.m. UTC | #9

On 16.07.2019 11:00, Daniel Vetter wrote:
> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
>> On 11.07.2019 17:50, Daniel Vetter wrote:
>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>>>> Hi Laurent,
>>>>>>>>
>>>>>>>>
>>>>>>>> I like the approach, current practice when almost every bridge should
>>>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>>>> panel is very painful.
>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>>>> get a feeling for what your hpd_cb usually does.
>>>>>>>
>>>>>>>> More comments inlined.
>>>>>>>>
>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>>>> data:
>>>>>>>>>
>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>>>   retrieval operations
>>>>>>>>> - Bitmask of supported operations
>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>>>> operation's callback?
>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>>>> add, generally good excuse to not have to think through the design between
>>>>>>> different parts of drivers - "just" add another flag.
>>>>>>>>> - Bridge output type
>>>>>>>>>
>>>>>>>>> Add and document these.
>>>>>>>>>
>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>>>> bridges.
>>>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>>>> right? More comments about it later.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>>>> ---
>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>>>   */
>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>>>  {
>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>>>> +
>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>> +
>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>>>  }
>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>>>  
>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>  }
>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>>>  
>>>>>>>>> +/**
>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>> + * @cb: hot-plug detection callback
>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>>>> + *
>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>>>> + *
>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>> + *
>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>>>> + * the bridge.
>>>>>>>>> + */
>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>>>> bridge attach:
>>>>>>>>
>>>>>>>> bridge->hpd_cb = cb;
>>>>>>>>
>>>>>>>> bridge->hpd_data = data;
>>>>>>>>
>>>>>>>> ret = drm_bridge_attach(...);
>>>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>>>
>>>>>>>
>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>>>> without big sacrifices.
>>>>>>>>
>>>>>>>>
>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>>>
>>>>>>>>
>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>> +			   void *data)
>>>>>>>>> +{
>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>>>> +		return;
>>>>>>>>> +
>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>> +
>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>>>> +		goto unlock;
>>>>>>>>> +
>>>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>>>> +	bridge->hpd_data = data;
>>>>>>>>> +
>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>>>> +
>>>>>>>>> +unlock:
>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>> +}
>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>> + *
>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>>>> + * output status change occurs.
>>>>>>>>> + *
>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>> + */
>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>>>> +{
>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>>>> +		return;
>>>>>>>>> +
>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>>>> +
>>>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>> +}
>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>>>> +
>>>>>>>>> +/**
>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>> + * @status: output connection status
>>>>>>>>> + *
>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>>>> + *
>>>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>>>> + */
>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>> +			   enum drm_connector_status status)
>>>>>>>>> +{
>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>> +	if (bridge->hpd_cb)
>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>>>
>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>>>> 		if (tmp_bridge == bridge)
>>>>>>> 			continue;
>>>>>>> 		if (bridge->hpd_notify);
>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>>>> 	}
>>>>>>>
>>>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>>>
>>>>>>> 	dev = bridge->dev
>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>>>
>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>>>> hpd they want/need.
>>>>>> As I understand you want to notify every member of the pipeline.
>>>>>>
>>>>>> I think it should be enough to notify only the source, and then source
>>>>>> should decide if/when the hpd should be propagated upstream.
>>>>>>
>>>>>> It looks more generic for me.
>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>>>> the one from Laurent? Kinda confused here.
>>>> Regarding general idea:
>>>>
>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
>>>> source.
>>>>
>>>> 2. Your is to notify all other bridges and encoder.
>>>>
>>>>
>>>> And I prefer 1st approach, why:
>>>>
>>>> - the source can decide if/when and to who propagate the signal,
>>>>
>>>> - is more generic, for example if bridge send signal to two
>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
>>> With Laurent's approach the bridge cannot send the hpd to more than one
>>> consumer. There's only 1 callback. So you're example doesn't work.
>>
>> If there will be two consumers, there will be two bridge attachments,
>> thus there will be two notifications, it should work.
> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> callback is registered on the produce bridge, not on the consumer bridge
> (or I'm totallly misreading what Laurent does here).


I have assumed that if devices exposes two hardware sink interfaces it
will expose two separate bridges - of course it will not work with
"bridge chaining" thing, but this is a different story.


>
>>>> - it resembles hardware wires :)
>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
>>> interested in that hpd singal. This includes:
>>> - Other bridges, e.g. if they provide CEC support.
>>> - Other bridges, maybe they need to re-run the HDCP state engine
>>> - Overall driver, so it can update the modes/connector status and send the
>>>   uevent to the driver.
>>> - Overall display pipeline for this specific bridge, maybe you need to
>>>   shut down/re-enable the pipe because $reasons.
>>>  
>>> That's at least my understanding from lots of chats with Laurent about
>>> what he wants to do here.
>>
>> I do not know the full picture, but the solution where particular bridge
>> notifies everything unconditionally seems to me much less flexible.
>>
>> If HPD signals is received by the consumer, if there are no obstacles it
>> can propagate it further, upstream bridge/encoder or to drm core - it
>> will mimic your scenario.
>>
>> But there are also other scenarios where bridge does not want to
>> propagate signal, because for example:
>>
>> - it wants to wait for other sinks to wake up,
> The other sink can just do that in their hpd callback.
>
>> - it propagates HPD signal via hardware wire,
> Again, the other sink can just not listen to sw hpd in that case, and use
> the wire/hw hpd interrupt.


If it should ignore HPD, why it should receive it at all - it is
unnecessary noise. And I am afraid with more complicated pipelines it
will be impossible for particular component (bridge/encoder/whatever) to
distinguish if HPD notification which came from non-directly connected
component should be ignored or not.


>
>> - first it wants to verify if the sink is valid/compatible/authorized
>> device.
> Now you lost me. Why would someone glue incompatible IP into a SoC or
> board?


Bridge can have external connectors, and the user can connect there
anything.


>
>> In general HPD is input signal for notify of state changes on particular
>> bus, in case of typical video bridge on its output video bus.
>>
>> In case of bridges they have also input video buses, and they can send
>> HPD signal via this bus, but this is indeed different HPD signal, even
>> if for most cases they looks similar.
> Ah, I think this is a problem we will eventually have. But it's not
> something we're currently solving here at all I think.


Currently sii8620 device in tm2 sends hpd signal upstream via hardware
line, so this is not something from far future. And I guess with HPD
broadcasting it could be racy/error prone, for example EDID reading can
fail due to bridge being not ready (ddc of sii8620 is connected to i2c
controller via hw wires also).


>
>>>> And regarding implementation:
>>>>
>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>>>
>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>>>
>>>>
>>>> Your proposition is more straightforward, but if we want to notify only
>>>> source we should locate it by parsing notification chain (what about
>>>> unchained bridges), or store pointer somewhere during attachment.
>>>>
>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
>>>> similarly to sink as bridge or panel, but fixing it can be done later.
>>> Uh I think we're not talking about the same thing really. My understanding
>>> is that this callback is if someone (outside of this bridge) is interested
>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
>>> listener.
>>
>> Do we have real life examples?
>>
>> I want to distinguish two situations:
>>
>> - another device wants to know if input bus of the bridge has changed state,
>>
>> - another device wants to know if output bus of the bridge has changed
>> state.
> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> bridges can exchange state and information about each another. hpd is
> about the physical world, i.e. "is there a cable plugged into the port
> I'm driving?". We're not going to use fake hpd to update bridge state and
> fun stuff like that, we have the atomic_check machinery for this.


My question was if we have real examples that upstream device requires
knowledge about state of output line of the bridge?

To be more precise, we have following display pipeline:

A-->B-->C

And C sends HPD to B (ie signal that state of line between B and C
changed). Does A really wants to know this information? or it should
just need to know if state of line A-->B changed?


Regards

Andrzej


> -Daniel
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>> You seem to have some other idea here.
>>> -Daniel
>>>
>>>> Regards
>>>>
>>>> Andrzej
>>>>
>>>>
>>>>> -Daniel
>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Andrzej
>>>>>>
>>>>>>
>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>> +}
>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>>>> +
>>>>>>>>>  #ifdef CONFIG_OF
>>>>>>>>>  /**
>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>>>  
>>>>>>>>> -#include <linux/list.h>
>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>> +#include <linux/list.h>
>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>>>  
>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>>>  	 */
>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>>>> +
>>>>>>>>> +	/**
>>>>>>>>> +	 * @detect:
>>>>>>>>> +	 *
>>>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>>>> +	 *
>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>>>> +	 *
>>>>>>>>> +	 * RETURNS:
>>>>>>>>> +	 *
>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>>>> +	 */
>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>>>> +
>>>>>>>>> +	/**
>>>>>>>>> +	 * @get_modes:
>>>>>>>>> +	 *
>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>>>> +	 *
>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>>>> +	 *
>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>>>> +	 *
>>>>>>>>> +	 * RETURNS:
>>>>>>>>> +	 *
>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>>>> +	 */
>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>>>> +			 struct drm_connector *connector);
>>>>>>>>> +
>>>>>>>>> +	/**
>>>>>>>>> +	 * @get_edid:
>>>>>>>>> +	 *
>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>>>> +	 *
>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>>>> +	 *
>>>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>>>> +	 * output.
>>>>>>>>> +	 *
>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>>>> +	 *
>>>>>>>>> +	 * RETURNS:
>>>>>>>>> +	 *
>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>>>> +	 */
>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>>>> +				 struct drm_connector *connector);
>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>>>> presence of another one?
>>>>>>>>
>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>>>> and connector->edid correctly.
>>>>>>>
>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>>>> in the connector is up-to-date? With your current callback design that's
>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>>>> correctly updated.
>>>>>>>
>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>>>> edid, which is not so awesome :-)
>>>>>>> -Daniel
>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Andrzej
>>>>>>>>
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +	/**
>>>>>>>>> +	 * @lost_hotplug:
>>>>>>>>> +	 *
>>>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>>>> +	 *
>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>>>> +	 * HDMI bridges.
>>>>>>>>> +	 */
>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>>>> +
>>>>>>>>> +	/**
>>>>>>>>> +	 * @hpd_enable:
>>>>>>>>> +	 *
>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>>>> +	 * @hpd_disable.
>>>>>>>>> +	 *
>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>> +	 */
>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>>>> +
>>>>>>>>> +	/**
>>>>>>>>> +	 * @hpd_disable:
>>>>>>>>> +	 *
>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>>>> +	 * connection status occurs.
>>>>>>>>> +	 *
>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>> +	 */
>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>>>  };
>>>>>>>>>  
>>>>>>>>>  /**
>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>>>  	bool dual_link;
>>>>>>>>>  };
>>>>>>>>>  
>>>>>>>>> +/**
>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>>>> + */
>>>>>>>>> +enum drm_bridge_ops {
>>>>>>>>> +	/**
>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>>>> +	 */
>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>>>> +	/**
>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>>>> +	 */
>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>>>> +	/**
>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>>>> +	 */
>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>>>> +	/**
>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>>>> +	 */
>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>>>  /**
>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>>>   */
>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>>>  	void *driver_private;
>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>>>> +	/**
>>>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>>>> +	 * identifies the type of connected display.
>>>>>>>>> +	 */
>>>>>>>>> +	int type;
>>>>>>>>> +	/** private: */
>>>>>>>>> +	/**
>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>>>> +	 */
>>>>>>>>> +	struct mutex hpd_mutex;
>>>>>>>>> +	/**
>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>>>> +	 */
>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>>>> +	/**
>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>>>> +	 * @hpd_cb.
>>>>>>>>> +	 */
>>>>>>>>> +	void *hpd_data;
>>>>>>>>>  };
>>>>>>>>>  
>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>>>  
>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>> +			   void *data);
>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>> +			   enum drm_connector_status status);
>>>>>>>>> +
>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 8, 2019, 6:19 p.m. UTC | #10

Hello Daniel and Andrzej,

On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > Hi Laurent,
> > 
> > I like the approach, current practice when almost every bridge should
> > optionally implement connector, or alternatively downstream bridge or
> > panel is very painful.
> 
> Yeah I think this looks mostly reasonable. Some api design comments on top
> of Andrzej', with the fair warning that I didn't bother to read up on how
> it's all used in the end. I probably should go and do that, at least to
> get a feeling for what your hpd_cb usually does.
> 
> > More comments inlined.
> > 
> > On 07.07.2019 20:18, Laurent Pinchart wrote:
> > > To support implementation of DRM connectors on top of DRM bridges
> > > instead of by bridges, the drm_bridge needs to expose new operations and
> > > data:
> > >
> > > - Output detection, hot-plug notification, mode retrieval and EDID
> > >   retrieval operations
> > > - Bitmask of supported operations
> > 
> > 
> > Why do we need these bitmask at all? Why cannot we rely on presence of
> > operation's callback?
> 
> Yeah also not a huge fan of these bitmasks. Smells like
> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> add, generally good excuse to not have to think through the design between
> different parts of drivers - "just" add another flag.

The reason is that a bridge may support an operation (as in implemented
in the bridge hardware), but that operation may not be supported on a
particular board. For instance an HDMI encoder may support reading EDID
when the DDC lines are connected to the encoder, but a board may connect
the DDC lines to an I2C port of the SoC. We thus need to decouple
if a particular instance of the device supports the operation (exposed
by the ops flags) from the function pointers.

We could of course allocate the drm_bridge_funcs structure dynamically
for each bridge instance, and fill it with function pointers manually,
leaving the unused ops always NULL, but that would require making the
structure writable, which is considered a security issue. That's why I
decided to keep the drm_bridge_funcs structure as a global static const
structure, and add an ops bitmask.

> > > - Bridge output type
> > >
> > > Add and document these.
> > >
> > > Three new bridge helper functions are also added to handle hot plug
> > > notification in a way that is as transparent as possible for the
> > > bridges.
> > 
> > Documentation of new opses does not explain how it should cooperate with
> > bridge chaining, I suppose they should be chained explicitly, am I
> > right? More comments about it later.

No, the whole point is that they should not be chained at all. A bridge
does not have to propagate, for instance, .get_edid() to the next
bridge. That's one of the core design principles in this series, I want
to keep the bridges as simple as possible, and move the complexity of
the boilerplate code that is currently copied all around to helpers. See
patch "drm: Add helper to create a connector for a chain of bridges" for
more information about how this is used, with a helper that delegates
the connector operations to the correct bridge in the chain based on the
ops reported by each bridge.

> > > Signed-off-by: Laurent Pinchart <[e-mail]>
> > > ---
> > >  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >  2 files changed, 261 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > index 519577f363e3..3c2a255df7af 100644
> > > --- a/drivers/gpu/drm/drm_bridge.c
> > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >   */
> > >  void drm_bridge_add(struct drm_bridge *bridge)
> > >  {
> > > +	mutex_init(&bridge->hpd_mutex);
> > > +
> > >  	mutex_lock(&bridge_lock);
> > >  	list_add_tail(&bridge->list, &bridge_list);
> > >  	mutex_unlock(&bridge_lock);
> > > @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >  	mutex_lock(&bridge_lock);
> > >  	list_del_init(&bridge->list);
> > >  	mutex_unlock(&bridge_lock);
> > > +
> > > +	mutex_destroy(&bridge->hpd_mutex);
> > >  }
> > >  EXPORT_SYMBOL(drm_bridge_remove);
> > >  
> > > @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >  }
> > >  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >  
> > > +/**
> > > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > > + * @bridge: bridge control structure
> > > + * @cb: hot-plug detection callback
> > > + * @data: data to be passed to the hot-plug detection callback
> > > + *
> > > + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > > + * hot plug notification callback. From now on the @cb will be called with
> > > + * @data when an output status change is detected by the bridge, until hot plug
> > > + * notification gets disabled with drm_bridge_hpd_disable().
> > > + *
> > > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > > + * bridge->ops. This function shall not be called when the flag is not set.
> > > + *
> > > + * Only one hot plug detection callback can be registered at a time, it is an
> > > + * error to call this function when hot plug detection is already enabled for
> > > + * the bridge.
> > > + */
> > 
> > To simplify architecture maybe would be better to enable hpd just on
> > bridge attach:
> > 
> > bridge->hpd_cb = cb;
> > 
> > bridge->hpd_data = data;
> > 
> > ret = drm_bridge_attach(...);
> 
> Yeah I like this more. The other problem here is, what if you need more
> than 1 callback registers on the same bridge hdp signal?

That's why I decided to hide hide HPD through helpers,
drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
side, and drm_bridge_hpd_notify() on the event reporter side. While the
current implementation is limited to a single listener, only the helpers
would need to be changed to extend that to multiple listeners.

Note that the .hpd_enable() and .hpd_disable() operations also allow the
bridge to disable HPD detection when not used. Doing so keeps the bridge
simple, it only needs to care about reporting HPD events when they're
enabled, without caring who (if anyone) is listening, and gets clear
instructions on whether to enable or disable the HPD hardware (in case
it can be disabled).

> > This way we could avoid adding new callbacks hpd_(enable|disable)
> > without big sacrifices.
> > 
> > One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > notifies about sink status change, how it translates to this cb?

This is something this series doesn't implement. I don't think it would
be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
here. If you can elaborate on what would be needed, I can implement
that.

> > > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > > +			   void (*cb)(void *data,
> > > +				      enum drm_connector_status status),
> > > +			   void *data)
> > > +{
> > > +	if (!bridge || !bridge->funcs->hpd_enable)
> > > +		return;
> > > +
> > > +	mutex_lock(&bridge->hpd_mutex);
> > > +
> > > +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > > +		goto unlock;
> > > +
> > > +	bridge->hpd_cb = cb;
> > > +	bridge->hpd_data = data;
> > > +
> > > +	bridge->funcs->hpd_enable(bridge);
> > > +
> > > +unlock:
> > > +	mutex_unlock(&bridge->hpd_mutex);
> > > +}
> > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > > +
> > > +/**
> > > + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > > + * @bridge: bridge control structure
> > > + *
> > > + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > > + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > > + * function returns the callback will not be called by the bridge when an
> > > + * output status change occurs.
> > > + *
> > > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > > + * bridge->ops. This function shall not be called when the flag is not set.
> > > + */
> > > +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > > +{
> > > +	if (!bridge || !bridge->funcs->hpd_disable)
> > > +		return;
> > > +
> > > +	mutex_lock(&bridge->hpd_mutex);
> > > +	bridge->funcs->hpd_disable(bridge);
> > > +
> > > +	bridge->hpd_cb = NULL;
> > > +	bridge->hpd_data = NULL;
> > > +	mutex_unlock(&bridge->hpd_mutex);
> > > +}
> > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > > +
> > > +/**
> > > + * drm_bridge_hpd_notify - notify hot plug detection events
> > > + * @bridge: bridge control structure
> > > + * @status: output connection status
> > > + *
> > > + * Bridge drivers shall call this function to report hot plug events when they
> > > + * detect a change in the output status, when hot plug detection has been
> > > + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > > + *
> > > + * This function shall be called in a context that can sleep.
> > > + */
> > > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			   enum drm_connector_status status)
> > > +{
> > > +	mutex_lock(&bridge->hpd_mutex);
> > > +	if (bridge->hpd_cb)
> > > +		bridge->hpd_cb(bridge->hpd_data, status);
> 
> So this isn't quite what I had in mind. Instead something like this:
> 
> 	/* iterates over all bridges in the chain containing @bridge */
> 	for_each_bridge(tmp_bridge, bridge) {
> 		if (tmp_bridge == bridge)
> 			continue;
> 		if (bridge->hpd_notify);
> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> 	}
> 
> 	encoder = encoder_for_bridge(bridge);
> 	if (encoder->helper_private->bridge_hpd_notify)
> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> 
> 	dev = bridge->dev
> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> 
> No register callback needed, no locking needed, everyone gets exactly the
> hpd they want/need.

I'll reply to this further down the mail thread, to address additional
comments.

> > > +	mutex_unlock(&bridge->hpd_mutex);
> > > +}
> > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > > +
> > >  #ifdef CONFIG_OF
> > >  /**
> > >   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > > index 08dc15f93ded..b9445aa5b1ef 100644
> > > --- a/include/drm/drm_bridge.h
> > > +++ b/include/drm/drm_bridge.h
> > > @@ -23,8 +23,9 @@
> > >  #ifndef __DRM_BRIDGE_H__
> > >  #define __DRM_BRIDGE_H__
> > >  
> > > -#include <linux/list.h>
> > >  #include <linux/ctype.h>
> > > +#include <linux/list.h>
> > > +#include <linux/mutex.h>
> > >  #include <drm/drm_mode_object.h>
> > >  #include <drm/drm_modes.h>
> > >  
> > > @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >  	 */
> > >  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >  				    struct drm_atomic_state *state);
> > > +
> > > +	/**
> > > +	 * @detect:
> > > +	 *
> > > +	 * Check if anything is attached to the bridge output.
> > > +	 *
> > > +	 * This callback is optional, if not implemented the bridge will be
> > > +	 * considered as always having a component attached to its output.
> > > +	 * Bridges that implement this callback shall set the
> > > +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > > +	 *
> > > +	 * RETURNS:
> > > +	 *
> > > +	 * drm_connector_status indicating the bridge output status.
> > > +	 */
> > > +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > > +
> > > +	/**
> > > +	 * @get_modes:
> > > +	 *
> > > +	 * Fill all modes currently valid for the sink into the &drm_connector
> > > +	 * with drm_mode_probed_add().
> > > +	 *
> > > +	 * The @get_modes callback is mostly intended to support non-probable
> > > +	 * displays such as many fixed panels. Bridges that support reading
> > > +	 * EDID shall leave @get_modes unimplemented and implement the
> > > +	 * &drm_bridge_funcs->get_edid callback instead.
> > > +	 *
> > > +	 * This callback is optional. Bridges that implement it shall set the
> > > +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > > +	 *
> > > +	 * RETURNS:
> > > +	 *
> > > +	 * The number of modes added by calling drm_mode_probed_add().
> > > +	 */
> > > +	int (*get_modes)(struct drm_bridge *bridge,
> > > +			 struct drm_connector *connector);
> > > +
> > > +	/**
> > > +	 * @get_edid:
> > > +	 *
> > > +	 * Read and parse the EDID data of the connected display.
> > > +	 *
> > > +	 * The @get_edid callback is the preferred way of reporting mode
> > > +	 * information for a display connected to the bridge output. Bridges
> > > +	 * that support readind EDID shall implement this callback and leave
> > > +	 * the @get_modes callback unimplemented.
> > > +	 *
> > > +	 * The caller of this operation shall first verify the output
> > > +	 * connection status and refrain from reading EDID from a disconnected
> > > +	 * output.
> > > +	 *
> > > +	 * This callback is optional. Bridges that implement it shall set the
> > > +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > > +	 *
> > > +	 * RETURNS:
> > > +	 *
> > > +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > > +	 * success, or NULL otherwise. The caller is responsible for freeing
> > > +	 * the returned edid structure with kfree().
> > > +	 */
> > > +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > > +				 struct drm_connector *connector);
> > 
> > It overlaps with get_modes, I guess presence of one ops should disallow
> > presence of another one?
> > 
> > I am not really convinced we need this op at all, cannot we just assign
> > some helper function to .get_modes cb, which will do the same?
> 
> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> case, and require that if it has an edid it must fill out connector->info
> and connector->edid correctly.

I think that's doable, I'll have a look.

> Btw if a hpd happens, who's responible for making sure the edid/mode list
> in the connector is up-to-date? With your current callback design that's
> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> should guarantee that it'll first walk the connectors to update status and
> edid/mode list for the final drm_connector. And then instead of just
> passing the simple "status", it'll pass the connector, with everything
> correctly updated.
> 
> Otherwise everyone interested in that hpd signal will go and re-fetch the
> edid, which is not so awesome :-)

With the current design there's a single listener, so it's not a big
deal :-) Furthermore, the listener is the helper that creates a
connector on top of a chain of bridges, so it's a pretty good place to
handle this. See the call to drm_kms_helper_hotplug_event() in
drm_bridge_connector_hpd_cb().

I'm all for reworking HPD and mode fetching, but I think it's a bit too
big of a requirement as a prerequisite for this series (or as part of
this series). We have hardware that can report HPD with various level of
details (from "something happened on a connector" to "this particular
event happened on this particular connector"), and we channel that
through helpers such as drm_kms_helper_hotplug_event() that lose the
details and go through a heavy mechanism to refetch everything. I
understand this is needed in many cases, but I think there's room for
improvement. This series, in my opinion, doesn't go in the wrong
direction in that regard, as it eventually calls
drm_kms_helper_hotplug_event(), so I think improvements would make sense
on top of it. I'm even willing to work on this, provided I get feedback
on what is desired.

> > > +	/**
> > > +	 * @lost_hotplug:
> > > +	 *
> > > +	 * Notify the bridge of display disconnection.
> > > +	 *
> > > +	 * This callback is optional, it may be implemented by bridges that
> > > +	 * need to be notified of display disconnection for internal reasons.
> > > +	 * One use case is to reset the internal state of CEC controllers for
> > > +	 * HDMI bridges.
> > > +	 */
> > > +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > > +
> > > +	/**
> > > +	 * @hpd_enable:
> > > +	 *
> > > +	 * Enable hot plug detection. From now on the bridge shall call
> > > +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > > +	 * connection status, until hot plug detection gets disabled with
> > > +	 * @hpd_disable.
> > > +	 *
> > > +	 * This callback is optional and shall only be implemented by bridges
> > > +	 * that support hot-plug notification without polling. Bridges that
> > > +	 * implement it shall also implement the @hpd_disable callback and set
> > > +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > > +	 */
> > > +	void (*hpd_enable)(struct drm_bridge *bridge);
> > > +
> > > +	/**
> > > +	 * @hpd_disable:
> > > +	 *
> > > +	 * Disable hot plug detection. Once this function returns the bridge
> > > +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > > +	 * connection status occurs.
> > > +	 *
> > > +	 * This callback is optional and shall only be implemented by bridges
> > > +	 * that support hot-plug notification without polling. Bridges that
> > > +	 * implement it shall also implement the @hpd_enable callback and set
> > > +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > > +	 */
> > > +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >  };
> > >  
> > >  /**
> > > @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >  	bool dual_link;
> > >  };
> > >  
> > > +/**
> > > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > > + */
> > > +enum drm_bridge_ops {
> > > +	/**
> > > +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > > +	 * its output. Bridges that set this flag shall implement the
> > > +	 * &drm_bridge_funcs->detect callback.
> > > +	 */
> > > +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > > +	/**
> > > +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > > +	 * connected to its output. Bridges that set this flag shall implement
> > > +	 * the &drm_bridge_funcs->get_edid callback.
> > > +	 */
> > > +	DRM_BRIDGE_OP_EDID = BIT(1),
> > > +	/**
> > > +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > > +	 * without requiring polling. Bridges that set this flag shall
> > > +	 * implement the &drm_bridge_funcs->hpd_enable and
> > > +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > > +	 */
> > > +	DRM_BRIDGE_OP_HPD = BIT(2),
> > > +	/**
> > > +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > > +	 * by the display at its output. This does not include readind EDID
> > > +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > > +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > > +	 */
> > > +	DRM_BRIDGE_OP_MODES = BIT(3),
> > > +};
> > > +
> > >  /**
> > >   * struct drm_bridge - central DRM bridge control structure
> > >   */
> > > @@ -398,6 +535,29 @@ struct drm_bridge {
> > >  	const struct drm_bridge_funcs *funcs;
> > >  	/** @driver_private: pointer to the bridge driver's internal context */
> > >  	void *driver_private;
> > > +	/** @ops: bitmask of operations supported by the bridge */
> > > +	enum drm_bridge_ops ops;
> > > +	/**
> > > +	 * @type: Type of the connection at the bridge output
> > > +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > > +	 * identifies the type of connected display.
> > > +	 */
> > > +	int type;
> > > +	/** private: */
> > > +	/**
> > > +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > > +	 */
> > > +	struct mutex hpd_mutex;
> > > +	/**
> > > +	 * @hpd_cb: Hot plug detection callback, registered with
> > > +	 * drm_bridge_hpd_enable().
> > > +	 */
> > > +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > > +	/**
> > > +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > > +	 * @hpd_cb.
> > > +	 */
> > > +	void *hpd_data;
> > >  };
> > >  
> > >  void drm_bridge_add(struct drm_bridge *bridge);
> > > @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >  			      struct drm_atomic_state *state);
> > >  
> > > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > > +			   void (*cb)(void *data,
> > > +				      enum drm_connector_status status),
> > > +			   void *data);
> > > +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > > +			   enum drm_connector_status status);
> > > +
> > >  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >  					u32 connector_type);

Laurent Pinchart Aug. 8, 2019, 6:36 p.m. UTC | #11

On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >> Hi Laurent,
> >> 
> >> I like the approach, current practice when almost every bridge should
> >> optionally implement connector, or alternatively downstream bridge or
> >> panel is very painful.
> > 
> > Yeah I think this looks mostly reasonable. Some api design comments on top
> > of Andrzej', with the fair warning that I didn't bother to read up on how
> > it's all used in the end. I probably should go and do that, at least to
> > get a feeling for what your hpd_cb usually does.
> > 
> >> More comments inlined.
> >> 
> >> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>> To support implementation of DRM connectors on top of DRM bridges
> >>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>> data:
> >>>
> >>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>   retrieval operations
> >>> - Bitmask of supported operations
> >> 
> >> 
> >> Why do we need these bitmask at all? Why cannot we rely on presence of
> >> operation's callback?
> > 
> > Yeah also not a huge fan of these bitmasks. Smells like
> > DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > add, generally good excuse to not have to think through the design between
> > different parts of drivers - "just" add another flag.
> 
> The reason is that a bridge may support an operation (as in implemented
> in the bridge hardware), but that operation may not be supported on a
> particular board. For instance an HDMI encoder may support reading EDID
> when the DDC lines are connected to the encoder, but a board may connect
> the DDC lines to an I2C port of the SoC. We thus need to decouple
> if a particular instance of the device supports the operation (exposed
> by the ops flags) from the function pointers.
> 
> We could of course allocate the drm_bridge_funcs structure dynamically
> for each bridge instance, and fill it with function pointers manually,
> leaving the unused ops always NULL, but that would require making the
> structure writable, which is considered a security issue. That's why I
> decided to keep the drm_bridge_funcs structure as a global static const
> structure, and add an ops bitmask.
> 
> >>> - Bridge output type
> >>>
> >>> Add and document these.
> >>>
> >>> Three new bridge helper functions are also added to handle hot plug
> >>> notification in a way that is as transparent as possible for the
> >>> bridges.
> >> 
> >> Documentation of new opses does not explain how it should cooperate with
> >> bridge chaining, I suppose they should be chained explicitly, am I
> >> right? More comments about it later.
> 
> No, the whole point is that they should not be chained at all. A bridge
> does not have to propagate, for instance, .get_edid() to the next
> bridge. That's one of the core design principles in this series, I want
> to keep the bridges as simple as possible, and move the complexity of
> the boilerplate code that is currently copied all around to helpers. See
> patch "drm: Add helper to create a connector for a chain of bridges" for
> more information about how this is used, with a helper that delegates
> the connector operations to the correct bridge in the chain based on the
> ops reported by each bridge.
> 
> >>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>> ---
> >>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>> index 519577f363e3..3c2a255df7af 100644
> >>> --- a/drivers/gpu/drm/drm_bridge.c
> >>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>   */
> >>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>  {
> >>> +	mutex_init(&bridge->hpd_mutex);
> >>> +
> >>>  	mutex_lock(&bridge_lock);
> >>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>  	mutex_unlock(&bridge_lock);
> >>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>  	mutex_lock(&bridge_lock);
> >>>  	list_del_init(&bridge->list);
> >>>  	mutex_unlock(&bridge_lock);
> >>> +
> >>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>  }
> >>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>  
> >>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>  }
> >>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>  
> >>> +/**
> >>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>> + * @bridge: bridge control structure
> >>> + * @cb: hot-plug detection callback
> >>> + * @data: data to be passed to the hot-plug detection callback
> >>> + *
> >>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>> + * hot plug notification callback. From now on the @cb will be called with
> >>> + * @data when an output status change is detected by the bridge, until hot plug
> >>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>> + *
> >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>> + *
> >>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>> + * error to call this function when hot plug detection is already enabled for
> >>> + * the bridge.
> >>> + */
> >> 
> >> To simplify architecture maybe would be better to enable hpd just on
> >> bridge attach:
> >> 
> >> bridge->hpd_cb = cb;
> >> 
> >> bridge->hpd_data = data;
> >> 
> >> ret = drm_bridge_attach(...);
> > 
> > Yeah I like this more. The other problem here is, what if you need more
> > than 1 callback registers on the same bridge hdp signal?
> 
> That's why I decided to hide hide HPD through helpers,
> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> current implementation is limited to a single listener, only the helpers
> would need to be changed to extend that to multiple listeners.
> 
> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> bridge to disable HPD detection when not used. Doing so keeps the bridge
> simple, it only needs to care about reporting HPD events when they're
> enabled, without caring who (if anyone) is listening, and gets clear
> instructions on whether to enable or disable the HPD hardware (in case
> it can be disabled).
> 
> >> This way we could avoid adding new callbacks hpd_(enable|disable)
> >> without big sacrifices.
> >> 
> >> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >> notifies about sink status change, how it translates to this cb?
> 
> This is something this series doesn't implement. I don't think it would
> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> here. If you can elaborate on what would be needed, I can implement
> that.
> 
> >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>> +			   void (*cb)(void *data,
> >>> +				      enum drm_connector_status status),
> >>> +			   void *data)
> >>> +{
> >>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>> +		return;
> >>> +
> >>> +	mutex_lock(&bridge->hpd_mutex);
> >>> +
> >>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>> +		goto unlock;
> >>> +
> >>> +	bridge->hpd_cb = cb;
> >>> +	bridge->hpd_data = data;
> >>> +
> >>> +	bridge->funcs->hpd_enable(bridge);
> >>> +
> >>> +unlock:
> >>> +	mutex_unlock(&bridge->hpd_mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>> +
> >>> +/**
> >>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>> + * @bridge: bridge control structure
> >>> + *
> >>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>> + * function returns the callback will not be called by the bridge when an
> >>> + * output status change occurs.
> >>> + *
> >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>> + */
> >>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>> +{
> >>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>> +		return;
> >>> +
> >>> +	mutex_lock(&bridge->hpd_mutex);
> >>> +	bridge->funcs->hpd_disable(bridge);
> >>> +
> >>> +	bridge->hpd_cb = NULL;
> >>> +	bridge->hpd_data = NULL;
> >>> +	mutex_unlock(&bridge->hpd_mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>> +
> >>> +/**
> >>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>> + * @bridge: bridge control structure
> >>> + * @status: output connection status
> >>> + *
> >>> + * Bridge drivers shall call this function to report hot plug events when they
> >>> + * detect a change in the output status, when hot plug detection has been
> >>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>> + *
> >>> + * This function shall be called in a context that can sleep.
> >>> + */
> >>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>> +			   enum drm_connector_status status)
> >>> +{
> >>> +	mutex_lock(&bridge->hpd_mutex);
> >>> +	if (bridge->hpd_cb)
> >>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > 
> > So this isn't quite what I had in mind. Instead something like this:
> > 
> > 	/* iterates over all bridges in the chain containing @bridge */
> > 	for_each_bridge(tmp_bridge, bridge) {
> > 		if (tmp_bridge == bridge)
> > 			continue;
> > 		if (bridge->hpd_notify);
> > 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > 	}
> > 
> > 	encoder = encoder_for_bridge(bridge);
> > 	if (encoder->helper_private->bridge_hpd_notify)
> > 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > 
> > 	dev = bridge->dev
> > 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > 
> > No register callback needed, no locking needed, everyone gets exactly the
> > hpd they want/need.
> 
> I'll reply to this further down the mail thread, to address additional
> comments.
> 
> >>> +	mutex_unlock(&bridge->hpd_mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>> +
> >>>  #ifdef CONFIG_OF
> >>>  /**
> >>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>> --- a/include/drm/drm_bridge.h
> >>> +++ b/include/drm/drm_bridge.h
> >>> @@ -23,8 +23,9 @@
> >>>  #ifndef __DRM_BRIDGE_H__
> >>>  #define __DRM_BRIDGE_H__
> >>>  
> >>> -#include <linux/list.h>
> >>>  #include <linux/ctype.h>
> >>> +#include <linux/list.h>
> >>> +#include <linux/mutex.h>
> >>>  #include <drm/drm_mode_object.h>
> >>>  #include <drm/drm_modes.h>
> >>>  
> >>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>  	 */
> >>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>  				    struct drm_atomic_state *state);
> >>> +
> >>> +	/**
> >>> +	 * @detect:
> >>> +	 *
> >>> +	 * Check if anything is attached to the bridge output.
> >>> +	 *
> >>> +	 * This callback is optional, if not implemented the bridge will be
> >>> +	 * considered as always having a component attached to its output.
> >>> +	 * Bridges that implement this callback shall set the
> >>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>> +	 *
> >>> +	 * RETURNS:
> >>> +	 *
> >>> +	 * drm_connector_status indicating the bridge output status.
> >>> +	 */
> >>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>> +
> >>> +	/**
> >>> +	 * @get_modes:
> >>> +	 *
> >>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>> +	 * with drm_mode_probed_add().
> >>> +	 *
> >>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>> +	 * displays such as many fixed panels. Bridges that support reading
> >>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>> +	 *
> >>> +	 * This callback is optional. Bridges that implement it shall set the
> >>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>> +	 *
> >>> +	 * RETURNS:
> >>> +	 *
> >>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>> +	 */
> >>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>> +			 struct drm_connector *connector);
> >>> +
> >>> +	/**
> >>> +	 * @get_edid:
> >>> +	 *
> >>> +	 * Read and parse the EDID data of the connected display.
> >>> +	 *
> >>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>> +	 * information for a display connected to the bridge output. Bridges
> >>> +	 * that support readind EDID shall implement this callback and leave
> >>> +	 * the @get_modes callback unimplemented.
> >>> +	 *
> >>> +	 * The caller of this operation shall first verify the output
> >>> +	 * connection status and refrain from reading EDID from a disconnected
> >>> +	 * output.
> >>> +	 *
> >>> +	 * This callback is optional. Bridges that implement it shall set the
> >>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>> +	 *
> >>> +	 * RETURNS:
> >>> +	 *
> >>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>> +	 * the returned edid structure with kfree().
> >>> +	 */
> >>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>> +				 struct drm_connector *connector);
> >> 
> >> It overlaps with get_modes, I guess presence of one ops should disallow
> >> presence of another one?
> >> 
> >> I am not really convinced we need this op at all, cannot we just assign
> >> some helper function to .get_modes cb, which will do the same?
> > 
> > Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > case, and require that if it has an edid it must fill out connector->info
> > and connector->edid correctly.
> 
> I think that's doable, I'll have a look.

So I had a look, and while this is doable, it would essentially mean
that all bridges that retrieve modes from EDID would have to roll out
their own version of the following code:

static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
					       struct drm_bridge *bridge)
{
	enum drm_connector_status status;
	struct edid *edid;
	int n;

	status = drm_bridge_connector_detect(connector, false);
	if (status != connector_status_connected)
		goto no_edid;

	edid = bridge->funcs->get_edid(bridge, connector);
	if (!edid || !drm_edid_is_valid(edid)) {
		kfree(edid);
		goto no_edid;
	}

	drm_connector_update_edid_property(connector, edid);
	n = drm_add_edid_modes(connector, edid);

	kfree(edid);
	return n;

no_edid:
	drm_connector_update_edid_property(connector, NULL);
	return 0;
}

Is this desired ?

> > Btw if a hpd happens, who's responible for making sure the edid/mode list
> > in the connector is up-to-date? With your current callback design that's
> > up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > should guarantee that it'll first walk the connectors to update status and
> > edid/mode list for the final drm_connector. And then instead of just
> > passing the simple "status", it'll pass the connector, with everything
> > correctly updated.
> > 
> > Otherwise everyone interested in that hpd signal will go and re-fetch the
> > edid, which is not so awesome :-)
> 
> With the current design there's a single listener, so it's not a big
> deal :-) Furthermore, the listener is the helper that creates a
> connector on top of a chain of bridges, so it's a pretty good place to
> handle this. See the call to drm_kms_helper_hotplug_event() in
> drm_bridge_connector_hpd_cb().
> 
> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> big of a requirement as a prerequisite for this series (or as part of
> this series). We have hardware that can report HPD with various level of
> details (from "something happened on a connector" to "this particular
> event happened on this particular connector"), and we channel that
> through helpers such as drm_kms_helper_hotplug_event() that lose the
> details and go through a heavy mechanism to refetch everything. I
> understand this is needed in many cases, but I think there's room for
> improvement. This series, in my opinion, doesn't go in the wrong
> direction in that regard, as it eventually calls
> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> on top of it. I'm even willing to work on this, provided I get feedback
> on what is desired.
> 
> >>> +	/**
> >>> +	 * @lost_hotplug:
> >>> +	 *
> >>> +	 * Notify the bridge of display disconnection.
> >>> +	 *
> >>> +	 * This callback is optional, it may be implemented by bridges that
> >>> +	 * need to be notified of display disconnection for internal reasons.
> >>> +	 * One use case is to reset the internal state of CEC controllers for
> >>> +	 * HDMI bridges.
> >>> +	 */
> >>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>> +
> >>> +	/**
> >>> +	 * @hpd_enable:
> >>> +	 *
> >>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>> +	 * connection status, until hot plug detection gets disabled with
> >>> +	 * @hpd_disable.
> >>> +	 *
> >>> +	 * This callback is optional and shall only be implemented by bridges
> >>> +	 * that support hot-plug notification without polling. Bridges that
> >>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>> +	 */
> >>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>> +
> >>> +	/**
> >>> +	 * @hpd_disable:
> >>> +	 *
> >>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>> +	 * connection status occurs.
> >>> +	 *
> >>> +	 * This callback is optional and shall only be implemented by bridges
> >>> +	 * that support hot-plug notification without polling. Bridges that
> >>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>> +	 */
> >>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>  };
> >>>  
> >>>  /**
> >>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>  	bool dual_link;
> >>>  };
> >>>  
> >>> +/**
> >>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>> + */
> >>> +enum drm_bridge_ops {
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>> +	 * its output. Bridges that set this flag shall implement the
> >>> +	 * &drm_bridge_funcs->detect callback.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>> +	 * connected to its output. Bridges that set this flag shall implement
> >>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>> +	 * without requiring polling. Bridges that set this flag shall
> >>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>> +	/**
> >>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>> +	 * by the display at its output. This does not include readind EDID
> >>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>> +	 */
> >>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>> +};
> >>> +
> >>>  /**
> >>>   * struct drm_bridge - central DRM bridge control structure
> >>>   */
> >>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>  	const struct drm_bridge_funcs *funcs;
> >>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>  	void *driver_private;
> >>> +	/** @ops: bitmask of operations supported by the bridge */
> >>> +	enum drm_bridge_ops ops;
> >>> +	/**
> >>> +	 * @type: Type of the connection at the bridge output
> >>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>> +	 * identifies the type of connected display.
> >>> +	 */
> >>> +	int type;
> >>> +	/** private: */
> >>> +	/**
> >>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>> +	 */
> >>> +	struct mutex hpd_mutex;
> >>> +	/**
> >>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>> +	 * drm_bridge_hpd_enable().
> >>> +	 */
> >>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>> +	/**
> >>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>> +	 * @hpd_cb.
> >>> +	 */
> >>> +	void *hpd_data;
> >>>  };
> >>>  
> >>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>  			      struct drm_atomic_state *state);
> >>>  
> >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>> +			   void (*cb)(void *data,
> >>> +				      enum drm_connector_status status),
> >>> +			   void *data);
> >>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>> +			   enum drm_connector_status status);
> >>> +
> >>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>  					u32 connector_type);

Laurent Pinchart Aug. 8, 2019, 7:32 p.m. UTC | #12

Hello,

On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> On 16.07.2019 11:00, Daniel Vetter wrote:
> > On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>> Hi Laurent,
> >>>>>>>>
> >>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>> panel is very painful.
> >>>>>>>
> >>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>
> >>>>>>>> More comments inlined.
> >>>>>>>>
> >>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>> data:
> >>>>>>>>>
> >>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>   retrieval operations
> >>>>>>>>> - Bitmask of supported operations
> >>>>>>>>
> >>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>> operation's callback?
> >>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>
> >>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>
> >>>>>>>>> - Bridge output type
> >>>>>>>>>
> >>>>>>>>> Add and document these.
> >>>>>>>>>
> >>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>> bridges.
> >>>>>>>>
> >>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>> right? More comments about it later.
> >>>>>>>>
> >>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>> ---
> >>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>   */
> >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>  {
> >>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>> +
> >>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>> +
> >>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>  }
> >>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>  
> >>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>  }
> >>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>  
> >>>>>>>>> +/**
> >>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>> + *
> >>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>> + *
> >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>> + *
> >>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>> + * the bridge.
> >>>>>>>>> + */
> >>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>> bridge attach:
> >>>>>>>>
> >>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>
> >>>>>>>> bridge->hpd_data = data;
> >>>>>>>>
> >>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>
> >>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>
> >>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>> without big sacrifices.
> >>>>>>>>
> >>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>
> >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>> +			   void *data)
> >>>>>>>>> +{
> >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>> +		return;
> >>>>>>>>> +
> >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>> +
> >>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>> +		goto unlock;
> >>>>>>>>> +
> >>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>> +
> >>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>> +
> >>>>>>>>> +unlock:
> >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>> +}
> >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>> + *
> >>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>> + * output status change occurs.
> >>>>>>>>> + *
> >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>> + */
> >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>> +{
> >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>> +		return;
> >>>>>>>>> +
> >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>> +
> >>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>> +}
> >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>> + * @status: output connection status
> >>>>>>>>> + *
> >>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>> + *
> >>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>> + */
> >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>> +{
> >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>
> >>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>
> >>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>> 			continue;
> >>>>>>> 		if (bridge->hpd_notify);
> >>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>> 	}
> >>>>>>>
> >>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>
> >>>>>>> 	dev = bridge->dev
> >>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>
> >>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>> hpd they want/need.
> >>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>
> >>>>>> I think it should be enough to notify only the source, and then source
> >>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>
> >>>>>> It looks more generic for me.
> >>>>>
> >>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>> the one from Laurent? Kinda confused here.
> >>>>
> >>>> Regarding general idea:
> >>>>
> >>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>> source.
> >>>>
> >>>> 2. Your is to notify all other bridges and encoder.
> >>>>
> >>>> And I prefer 1st approach, why:
> >>>>
> >>>> - the source can decide if/when and to who propagate the signal,
> >>>>
> >>>> - is more generic, for example if bridge send signal to two
> >>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>
> >>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>> consumer. There's only 1 callback. So you're example doesn't work.
> >>
> >> If there will be two consumers, there will be two bridge attachments,
> >> thus there will be two notifications, it should work.
> >
> > 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> > callback is registered on the produce bridge, not on the consumer bridge
> > (or I'm totallly misreading what Laurent does here).
> 
> I have assumed that if devices exposes two hardware sink interfaces it
> will expose two separate bridges - of course it will not work with
> "bridge chaining" thing, but this is a different story.

Daniel is right that the current implementation only allows one
consumer. This is however not a limitation of the API, but of its
implementation, as I only needed a single consumer. The helpers in this
series ensure that neither the consumer nor the producer poke in the
drm_bridge structure to call back to the HPD handler:

- The consumer calls drm_bridge_hpd_enable() and
  drm_bridge_hpd_disable(), which could offer a reference-counted
  behaviour if desired without changes to the consumer.

- The producer gets configured by .hpd_enable() and .hpd_disable(),
  which could also easily accommodate reference-counting in the drm
  bridge core without changes to the producer.

- The producer notifies HPD with drm_bridge_hpd_notify(), which could
  easily be extended to support multiple consumers without changes to
  the producer.

This is actually my second version of the HPD mechanism. The first
version was never posted, poked into drm_bridge, and required the
producer to be aware of the callbacks. After discussing this privately
with Daniel, I came up with the implementation in this series that,
while not supporting multiple consumers now, makes it easy to extend
later without minimal effort.

Daniel's proposed implementation above looks reasonable to me, provided
we can iterate over the bridges in an order that don't depend on the
position of the producer in the chain (should be easy to solve by
starting at the encoder for instance). It however looks a bit like a
midlayer to me :-) That's why I have a similar implementation in the
connector-bridge helper, which could be extended to call
encoder->helper_private->bridge_hpd_notify() and
dev->mode_config.helper_private->bridge_hpd_notify() instead of
hardcoding drm_kms_helper_hotplug_event(). Moving the code to
drm_bridge_hpd_notify() would on the other hand set the notification
sequence towards the encoder and driver in stone. Daniel, do you think
that would be better ?

I would like to remind everybody that this series isn't the last I will
ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
open to suggestions, and can address problems on top of these patches,
provided obviously that this series doesn't go in the wrong direction.
I'm of course also willing to rework this series, but given the amount
of work we have in the drm_bridge realm, I can't fix everything in one
go :-)

> >>>> - it resembles hardware wires :)
> >>>
> >>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>> interested in that hpd singal. This includes:
> >>> - Other bridges, e.g. if they provide CEC support.
> >>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>> - Overall driver, so it can update the modes/connector status and send the
> >>>   uevent to the driver.
> >>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>   shut down/re-enable the pipe because $reasons.
> >>>  
> >>> That's at least my understanding from lots of chats with Laurent about
> >>> what he wants to do here.

That's correct, and that's what I was trying to implement :-) The
notification, in this patch series, goes from the producer bridge to a
central place (namely the connector, with a helper implementation
available as part of this series, but custom implementations in display
drivers are fine if needed) that then dispatches the notification to all
bridges (through the .lost_hotplug() operation, which we could replace
by an .hpd_notify() operation) for the first two purposes listed above,
and then to the overall driver. The only thing I don't support yet is
dispatching to the display pipeline (item 4 in the list above) as I had
no need for that, and didn't want to develop an API with no user. This
would however not be difficult to do when needed, the need is taken into
account in the proposed implementation.

> >> I do not know the full picture, but the solution where particular bridge
> >> notifies everything unconditionally seems to me much less flexible.
> >>
> >> If HPD signals is received by the consumer, if there are no obstacles it
> >> can propagate it further, upstream bridge/encoder or to drm core - it
> >> will mimic your scenario.
> >>
> >> But there are also other scenarios where bridge does not want to
> >> propagate signal, because for example:
> >>
> >> - it wants to wait for other sinks to wake up,
> >
> > The other sink can just do that in their hpd callback.
> >
> >> - it propagates HPD signal via hardware wire,
> >
> > Again, the other sink can just not listen to sw hpd in that case, and use
> > the wire/hw hpd interrupt.
> 
> If it should ignore HPD, why it should receive it at all - it is
> unnecessary noise. And I am afraid with more complicated pipelines it
> will be impossible for particular component (bridge/encoder/whatever) to
> distinguish if HPD notification which came from non-directly connected
> component should be ignored or not.
> 
> >> - first it wants to verify if the sink is valid/compatible/authorized
> >> device.
> >
> > Now you lost me. Why would someone glue incompatible IP into a SoC or
> > board?
> 
> Bridge can have external connectors, and the user can connect there
> anything.
> 
> >> In general HPD is input signal for notify of state changes on particular
> >> bus, in case of typical video bridge on its output video bus.
> >>
> >> In case of bridges they have also input video buses, and they can send
> >> HPD signal via this bus, but this is indeed different HPD signal, even
> >> if for most cases they looks similar.
> >
> > Ah, I think this is a problem we will eventually have. But it's not
> > something we're currently solving here at all I think.
> 
> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> line, so this is not something from far future. And I guess with HPD
> broadcasting it could be racy/error prone, for example EDID reading can
> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> controller via hw wires also).
> 
> >>>> And regarding implementation:
> >>>>
> >>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>
> >>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>
> >>>> Your proposition is more straightforward, but if we want to notify only
> >>>> source we should locate it by parsing notification chain (what about
> >>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>
> >>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>
> >>> Uh I think we're not talking about the same thing really. My understanding
> >>> is that this callback is if someone (outside of this bridge) is interested
> >>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>> listener.
> >>
> >> Do we have real life examples?
> >>
> >> I want to distinguish two situations:
> >>
> >> - another device wants to know if input bus of the bridge has changed state,
> >>
> >> - another device wants to know if output bus of the bridge has changed
> >> state.
> >
> > Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> > bridges can exchange state and information about each another. hpd is
> > about the physical world, i.e. "is there a cable plugged into the port
> > I'm driving?". We're not going to use fake hpd to update bridge state and
> > fun stuff like that, we have the atomic_check machinery for this.
> 
> My question was if we have real examples that upstream device requires
> knowledge about state of output line of the bridge?
> 
> To be more precise, we have following display pipeline:
> 
> A-->B-->C
> 
> And C sends HPD to B (ie signal that state of line between B and C
> changed). Does A really wants to know this information? or it should
> just need to know if state of line A-->B changed?

There's one real life example, where A is an HDMI encoder, B is an HDMI
ESD protector and level shifter, and C is the physical HDMI connector.
When the HDMI cable is unplugged, the CEC controller part of A needs to
be notified in order to reset the CEC state machine. One could however
argue that in that case the A-B link state changes too, but the
important part is that HPD detection is not performed by A, while A
needs to be informed of lost hotplug.

> >>> You seem to have some other idea here.
> >>>
> >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>> +}
> >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>> +
> >>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>  /**
> >>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>  
> >>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>> +#include <linux/list.h>
> >>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>  
> >>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>  	 */
> >>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @detect:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * RETURNS:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>> +	 */
> >>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @get_modes:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * RETURNS:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>> +	 */
> >>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @get_edid:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>> +	 * output.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * RETURNS:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>> +	 */
> >>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>> presence of another one?
> >>>>>>>>
> >>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>> and connector->edid correctly.
> >>>>>>>
> >>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>> correctly updated.
> >>>>>>>
> >>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>> edid, which is not so awesome :-)
> >>>>>>>
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>> +	 * connection status occurs.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>  };
> >>>>>>>>>  
> >>>>>>>>>  /**
> >>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>  	bool dual_link;
> >>>>>>>>>  };
> >>>>>>>>>  
> >>>>>>>>> +/**
> >>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>> + */
> >>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>>  /**
> >>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>   */
> >>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>  	void *driver_private;
> >>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>> +	 */
> >>>>>>>>> +	int type;
> >>>>>>>>> +	/** private: */
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>> +	 */
> >>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void *hpd_data;
> >>>>>>>>>  };
> >>>>>>>>>  
> >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>  
> >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>> +			   void *data);
> >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>> +
> >>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>  					u32 connector_type);

Andrzej Hajda Aug. 9, 2019, 11:55 a.m. UTC | #13

On 08.08.2019 21:32, Laurent Pinchart wrote:
> Hello,
>
> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
>> On 16.07.2019 11:00, Daniel Vetter wrote:
>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>>>>>> Hi Laurent,
>>>>>>>>>>
>>>>>>>>>> I like the approach, current practice when almost every bridge should
>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>>>>>> panel is very painful.
>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>>>>>> get a feeling for what your hpd_cb usually does.
>>>>>>>>>
>>>>>>>>>> More comments inlined.
>>>>>>>>>>
>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>>>>>> data:
>>>>>>>>>>>
>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>>>>>   retrieval operations
>>>>>>>>>>> - Bitmask of supported operations
>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>>>>>> operation's callback?
>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>>>>>>
>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>>>>>> add, generally good excuse to not have to think through the design between
>>>>>>>>> different parts of drivers - "just" add another flag.
>>>>>>>>>
>>>>>>>>>>> - Bridge output type
>>>>>>>>>>>
>>>>>>>>>>> Add and document these.
>>>>>>>>>>>
>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>>>>>> bridges.
>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>>>>>> right? More comments about it later.
>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>>>>>   */
>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>>>>>  {
>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>>>>>> +
>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>> +
>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>>>>>  }
>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>>>>>  
>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>  }
>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>>>>>  
>>>>>>>>>>> +/**
>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>> + * @cb: hot-plug detection callback
>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>>>>>> + *
>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>>>>>> + *
>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>> + *
>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>>>>>> + * the bridge.
>>>>>>>>>>> + */
>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>>>>>> bridge attach:
>>>>>>>>>>
>>>>>>>>>> bridge->hpd_cb = cb;
>>>>>>>>>>
>>>>>>>>>> bridge->hpd_data = data;
>>>>>>>>>>
>>>>>>>>>> ret = drm_bridge_attach(...);
>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>>>>>
>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>>>>>> without big sacrifices.
>>>>>>>>>>
>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>>>>>
>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>> +			   void *data)
>>>>>>>>>>> +{
>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>>>>>> +		return;
>>>>>>>>>>> +
>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>> +
>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>>>>>> +		goto unlock;
>>>>>>>>>>> +
>>>>>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>>>>>> +	bridge->hpd_data = data;
>>>>>>>>>>> +
>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>>>>>> +
>>>>>>>>>>> +unlock:
>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>> +}
>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>>>>>> +
>>>>>>>>>>> +/**
>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>> + *
>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>>>>>> + * output status change occurs.
>>>>>>>>>>> + *
>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>> + */
>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>>>>>> +{
>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>>>>>> +		return;
>>>>>>>>>>> +
>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>>>>>> +
>>>>>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>> +}
>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>>>>>> +
>>>>>>>>>>> +/**
>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>> + * @status: output connection status
>>>>>>>>>>> + *
>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>>>>>> + *
>>>>>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>>>>>> + */
>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>> +			   enum drm_connector_status status)
>>>>>>>>>>> +{
>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>> +	if (bridge->hpd_cb)
>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>>>>>
>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>>>>>> 		if (tmp_bridge == bridge)
>>>>>>>>> 			continue;
>>>>>>>>> 		if (bridge->hpd_notify);
>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>>>>>> 	}
>>>>>>>>>
>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>>>>>
>>>>>>>>> 	dev = bridge->dev
>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>>>>>
>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>>>>>> hpd they want/need.
>>>>>>>> As I understand you want to notify every member of the pipeline.
>>>>>>>>
>>>>>>>> I think it should be enough to notify only the source, and then source
>>>>>>>> should decide if/when the hpd should be propagated upstream.
>>>>>>>>
>>>>>>>> It looks more generic for me.
>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>>>>>> the one from Laurent? Kinda confused here.
>>>>>> Regarding general idea:
>>>>>>
>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
>>>>>> source.
>>>>>>
>>>>>> 2. Your is to notify all other bridges and encoder.
>>>>>>
>>>>>> And I prefer 1st approach, why:
>>>>>>
>>>>>> - the source can decide if/when and to who propagate the signal,
>>>>>>
>>>>>> - is more generic, for example if bridge send signal to two
>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
>>>>> consumer. There's only 1 callback. So you're example doesn't work.
>>>> If there will be two consumers, there will be two bridge attachments,
>>>> thus there will be two notifications, it should work.
>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
>>> callback is registered on the produce bridge, not on the consumer bridge
>>> (or I'm totallly misreading what Laurent does here).
>> I have assumed that if devices exposes two hardware sink interfaces it
>> will expose two separate bridges - of course it will not work with
>> "bridge chaining" thing, but this is a different story.
> Daniel is right that the current implementation only allows one
> consumer. This is however not a limitation of the API, but of its
> implementation, as I only needed a single consumer. The helpers in this
> series ensure that neither the consumer nor the producer poke in the
> drm_bridge structure to call back to the HPD handler:
>
> - The consumer calls drm_bridge_hpd_enable() and
>   drm_bridge_hpd_disable(), which could offer a reference-counted
>   behaviour if desired without changes to the consumer.
>
> - The producer gets configured by .hpd_enable() and .hpd_disable(),
>   which could also easily accommodate reference-counting in the drm
>   bridge core without changes to the producer.
>
> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
>   easily be extended to support multiple consumers without changes to
>   the producer.
>
> This is actually my second version of the HPD mechanism. The first
> version was never posted, poked into drm_bridge, and required the
> producer to be aware of the callbacks. After discussing this privately
> with Daniel, I came up with the implementation in this series that,
> while not supporting multiple consumers now, makes it easy to extend
> later without minimal effort.
>
> Daniel's proposed implementation above looks reasonable to me, provided
> we can iterate over the bridges in an order that don't depend on the
> position of the producer in the chain (should be easy to solve by
> starting at the encoder for instance). It however looks a bit like a
> midlayer to me :-) That's why I have a similar implementation in the
> connector-bridge helper, which could be extended to call
> encoder->helper_private->bridge_hpd_notify() and
> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> drm_bridge_hpd_notify() would on the other hand set the notification
> sequence towards the encoder and driver in stone. Daniel, do you think
> that would be better ?
>
> I would like to remind everybody that this series isn't the last I will
> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> open to suggestions, and can address problems on top of these patches,
> provided obviously that this series doesn't go in the wrong direction.
> I'm of course also willing to rework this series, but given the amount
> of work we have in the drm_bridge realm, I can't fix everything in one
> go :-)
>
>>>>>> - it resembles hardware wires :)
>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
>>>>> interested in that hpd singal. This includes:
>>>>> - Other bridges, e.g. if they provide CEC support.
>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
>>>>> - Overall driver, so it can update the modes/connector status and send the
>>>>>   uevent to the driver.
>>>>> - Overall display pipeline for this specific bridge, maybe you need to
>>>>>   shut down/re-enable the pipe because $reasons.
>>>>>  
>>>>> That's at least my understanding from lots of chats with Laurent about
>>>>> what he wants to do here.
> That's correct, and that's what I was trying to implement :-) The
> notification, in this patch series, goes from the producer bridge to a
> central place (namely the connector, with a helper implementation
> available as part of this series, but custom implementations in display
> drivers are fine if needed) that then dispatches the notification to all
> bridges (through the .lost_hotplug() operation, which we could replace
> by an .hpd_notify() operation) for the first two purposes listed above,
> and then to the overall driver. The only thing I don't support yet is
> dispatching to the display pipeline (item 4 in the list above) as I had
> no need for that, and didn't want to develop an API with no user. This
> would however not be difficult to do when needed, the need is taken into
> account in the proposed implementation.
>
>>>> I do not know the full picture, but the solution where particular bridge
>>>> notifies everything unconditionally seems to me much less flexible.
>>>>
>>>> If HPD signals is received by the consumer, if there are no obstacles it
>>>> can propagate it further, upstream bridge/encoder or to drm core - it
>>>> will mimic your scenario.
>>>>
>>>> But there are also other scenarios where bridge does not want to
>>>> propagate signal, because for example:
>>>>
>>>> - it wants to wait for other sinks to wake up,
>>> The other sink can just do that in their hpd callback.
>>>
>>>> - it propagates HPD signal via hardware wire,
>>> Again, the other sink can just not listen to sw hpd in that case, and use
>>> the wire/hw hpd interrupt.
>> If it should ignore HPD, why it should receive it at all - it is
>> unnecessary noise. And I am afraid with more complicated pipelines it
>> will be impossible for particular component (bridge/encoder/whatever) to
>> distinguish if HPD notification which came from non-directly connected
>> component should be ignored or not.
>>
>>>> - first it wants to verify if the sink is valid/compatible/authorized
>>>> device.
>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
>>> board?
>> Bridge can have external connectors, and the user can connect there
>> anything.
>>
>>>> In general HPD is input signal for notify of state changes on particular
>>>> bus, in case of typical video bridge on its output video bus.
>>>>
>>>> In case of bridges they have also input video buses, and they can send
>>>> HPD signal via this bus, but this is indeed different HPD signal, even
>>>> if for most cases they looks similar.
>>> Ah, I think this is a problem we will eventually have. But it's not
>>> something we're currently solving here at all I think.
>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
>> line, so this is not something from far future. And I guess with HPD
>> broadcasting it could be racy/error prone, for example EDID reading can
>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
>> controller via hw wires also).
>>
>>>>>> And regarding implementation:
>>>>>>
>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>>>>>
>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>>>>>
>>>>>> Your proposition is more straightforward, but if we want to notify only
>>>>>> source we should locate it by parsing notification chain (what about
>>>>>> unchained bridges), or store pointer somewhere during attachment.
>>>>>>
>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
>>>>> Uh I think we're not talking about the same thing really. My understanding
>>>>> is that this callback is if someone (outside of this bridge) is interested
>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
>>>>> listener.
>>>> Do we have real life examples?
>>>>
>>>> I want to distinguish two situations:
>>>>
>>>> - another device wants to know if input bus of the bridge has changed state,
>>>>
>>>> - another device wants to know if output bus of the bridge has changed
>>>> state.
>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
>>> bridges can exchange state and information about each another. hpd is
>>> about the physical world, i.e. "is there a cable plugged into the port
>>> I'm driving?". We're not going to use fake hpd to update bridge state and
>>> fun stuff like that, we have the atomic_check machinery for this.
>> My question was if we have real examples that upstream device requires
>> knowledge about state of output line of the bridge?
>>
>> To be more precise, we have following display pipeline:
>>
>> A-->B-->C
>>
>> And C sends HPD to B (ie signal that state of line between B and C
>> changed). Does A really wants to know this information? or it should
>> just need to know if state of line A-->B changed?
> There's one real life example, where A is an HDMI encoder, B is an HDMI
> ESD protector and level shifter, and C is the physical HDMI connector.
> When the HDMI cable is unplugged, the CEC controller part of A needs to
> be notified in order to reset the CEC state machine. One could however
> argue that in that case the A-B link state changes too, but the
> important part is that HPD detection is not performed by A, while A
> needs to be informed of lost hotplug.


I have no full picture but I guess in this case C sends HPD to B using
hardware wire, and then B sends HPD to A also via wire, so I wouldn't
say that B does not participate in HPD transmission/forwarding,

some shifters with 'advanced power saving' can even perform wake-up of
upstream pin logic after receiving HPD on downstream, so HPD sent from B
to A is indeed different than HPD sent from C to B.

Btw, with the above logic of propagation of HPD callback (proposed by
Daniel) I guess it will work this way:

- A will receive HPD signal via HW,

- then B and C will receive HPD callback via framework.

Am I right?


Regards

Andrzej


>
>>>>> You seem to have some other idea here.
>>>>>
>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>> +}
>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>>>>>> +
>>>>>>>>>>>  #ifdef CONFIG_OF
>>>>>>>>>>>  /**
>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>>>>>  
>>>>>>>>>>> -#include <linux/list.h>
>>>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>>>> +#include <linux/list.h>
>>>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>>>>>  
>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>>>>>  	 */
>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>>>>>> +
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @detect:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>>>>>> +
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @get_modes:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>>>>>> +			 struct drm_connector *connector);
>>>>>>>>>>> +
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @get_edid:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>>>>>> +	 * output.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>>>>>> +				 struct drm_connector *connector);
>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>>>>>> presence of another one?
>>>>>>>>>>
>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>>>>>> and connector->edid correctly.
>>>>>>>>>
>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>>>>>> in the connector is up-to-date? With your current callback design that's
>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>>>>>> correctly updated.
>>>>>>>>>
>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>>>>>> edid, which is not so awesome :-)
>>>>>>>>>
>>>>>>>>>>> +
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @lost_hotplug:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>>>>>> +	 * HDMI bridges.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>>>>>> +
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @hpd_enable:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>>>>>> +	 * @hpd_disable.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>>>>>> +
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @hpd_disable:
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>>>>>> +	 * connection status occurs.
>>>>>>>>>>> +	 *
>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>>>>>  };
>>>>>>>>>>>  
>>>>>>>>>>>  /**
>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>>>>>  	bool dual_link;
>>>>>>>>>>>  };
>>>>>>>>>>>  
>>>>>>>>>>> +/**
>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>>>>>> + */
>>>>>>>>>>> +enum drm_bridge_ops {
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>>>>>> +};
>>>>>>>>>>> +
>>>>>>>>>>>  /**
>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>>>>>   */
>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>>>>>  	void *driver_private;
>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>>>>>> +	 * identifies the type of connected display.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	int type;
>>>>>>>>>>> +	/** private: */
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	struct mutex hpd_mutex;
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>>>>>> +	/**
>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>>>>>> +	 * @hpd_cb.
>>>>>>>>>>> +	 */
>>>>>>>>>>> +	void *hpd_data;
>>>>>>>>>>>  };
>>>>>>>>>>>  
>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>>>>>  
>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>> +			   void *data);
>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>> +			   enum drm_connector_status status);
>>>>>>>>>>> +
>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 10, 2019, 10:43 p.m. UTC | #14

Hi Andrzej,

On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> On 08.08.2019 21:32, Laurent Pinchart wrote:
> > On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>> Hi Laurent,
> >>>>>>>>>>
> >>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>> panel is very painful.
> >>>>>>>>>
> >>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>
> >>>>>>>>>> More comments inlined.
> >>>>>>>>>>
> >>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>> data:
> >>>>>>>>>>>
> >>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>   retrieval operations
> >>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>
> >>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>> operation's callback?
> >>>>>>>>>
> >>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>
> >>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>
> >>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>
> >>>>>>>>>>> Add and document these.
> >>>>>>>>>>>
> >>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>> bridges.
> >>>>>>>>>>
> >>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>> ---
> >>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>   */
> >>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>  {
> >>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>> +
> >>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>  }
> >>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>  
> >>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>  }
> >>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>  
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>> + * the bridge.
> >>>>>>>>>>> + */
> >>>>>>>>>>
> >>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>> bridge attach:
> >>>>>>>>>>
> >>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>
> >>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>
> >>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>
> >>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>
> >>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>> without big sacrifices.
> >>>>>>>>>>
> >>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>
> >>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>> +			   void *data)
> >>>>>>>>>>> +{
> >>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>> +		return;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +unlock:
> >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>> +
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>> + */
> >>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>> +{
> >>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>> +		return;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>> +
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>> + */
> >>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>> +{
> >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>
> >>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>
> >>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>> 			continue;
> >>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>> 	}
> >>>>>>>>>
> >>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>
> >>>>>>>>> 	dev = bridge->dev
> >>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>
> >>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>> hpd they want/need.
> >>>>>>>>
> >>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>
> >>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>
> >>>>>>>> It looks more generic for me.
> >>>>>>>
> >>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>
> >>>>>> Regarding general idea:
> >>>>>>
> >>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>> source.
> >>>>>>
> >>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>
> >>>>>> And I prefer 1st approach, why:
> >>>>>>
> >>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>
> >>>>>> - is more generic, for example if bridge send signal to two
> >>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>
> >>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>
> >>>> If there will be two consumers, there will be two bridge attachments,
> >>>> thus there will be two notifications, it should work.
> >>>
> >>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>> callback is registered on the produce bridge, not on the consumer bridge
> >>> (or I'm totallly misreading what Laurent does here).
> >>
> >> I have assumed that if devices exposes two hardware sink interfaces it
> >> will expose two separate bridges - of course it will not work with
> >> "bridge chaining" thing, but this is a different story.
> >
> > Daniel is right that the current implementation only allows one
> > consumer. This is however not a limitation of the API, but of its
> > implementation, as I only needed a single consumer. The helpers in this
> > series ensure that neither the consumer nor the producer poke in the
> > drm_bridge structure to call back to the HPD handler:
> >
> > - The consumer calls drm_bridge_hpd_enable() and
> >   drm_bridge_hpd_disable(), which could offer a reference-counted
> >   behaviour if desired without changes to the consumer.
> >
> > - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >   which could also easily accommodate reference-counting in the drm
> >   bridge core without changes to the producer.
> >
> > - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >   easily be extended to support multiple consumers without changes to
> >   the producer.
> >
> > This is actually my second version of the HPD mechanism. The first
> > version was never posted, poked into drm_bridge, and required the
> > producer to be aware of the callbacks. After discussing this privately
> > with Daniel, I came up with the implementation in this series that,
> > while not supporting multiple consumers now, makes it easy to extend
> > later without minimal effort.
> >
> > Daniel's proposed implementation above looks reasonable to me, provided
> > we can iterate over the bridges in an order that don't depend on the
> > position of the producer in the chain (should be easy to solve by
> > starting at the encoder for instance). It however looks a bit like a
> > midlayer to me :-) That's why I have a similar implementation in the
> > connector-bridge helper, which could be extended to call
> > encoder->helper_private->bridge_hpd_notify() and
> > dev->mode_config.helper_private->bridge_hpd_notify() instead of
> > hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> > drm_bridge_hpd_notify() would on the other hand set the notification
> > sequence towards the encoder and driver in stone. Daniel, do you think
> > that would be better ?
> >
> > I would like to remind everybody that this series isn't the last I will
> > ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> > open to suggestions, and can address problems on top of these patches,
> > provided obviously that this series doesn't go in the wrong direction.
> > I'm of course also willing to rework this series, but given the amount
> > of work we have in the drm_bridge realm, I can't fix everything in one
> > go :-)
> >
> >>>>>> - it resembles hardware wires :)
> >>>>>
> >>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>> interested in that hpd singal. This includes:
> >>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>   uevent to the driver.
> >>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>  
> >>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>> what he wants to do here.
> >
> > That's correct, and that's what I was trying to implement :-) The
> > notification, in this patch series, goes from the producer bridge to a
> > central place (namely the connector, with a helper implementation
> > available as part of this series, but custom implementations in display
> > drivers are fine if needed) that then dispatches the notification to all
> > bridges (through the .lost_hotplug() operation, which we could replace
> > by an .hpd_notify() operation) for the first two purposes listed above,
> > and then to the overall driver. The only thing I don't support yet is
> > dispatching to the display pipeline (item 4 in the list above) as I had
> > no need for that, and didn't want to develop an API with no user. This
> > would however not be difficult to do when needed, the need is taken into
> > account in the proposed implementation.
> >
> >>>> I do not know the full picture, but the solution where particular bridge
> >>>> notifies everything unconditionally seems to me much less flexible.
> >>>>
> >>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>> will mimic your scenario.
> >>>>
> >>>> But there are also other scenarios where bridge does not want to
> >>>> propagate signal, because for example:
> >>>>
> >>>> - it wants to wait for other sinks to wake up,
> >>>>
> >>> The other sink can just do that in their hpd callback.
> >>>
> >>>> - it propagates HPD signal via hardware wire,
> >>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>> the wire/hw hpd interrupt.
> >>>
> >> If it should ignore HPD, why it should receive it at all - it is
> >> unnecessary noise. And I am afraid with more complicated pipelines it
> >> will be impossible for particular component (bridge/encoder/whatever) to
> >> distinguish if HPD notification which came from non-directly connected
> >> component should be ignored or not.
> >>
> >>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>> device.
> >>>
> >>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>> board?
> >>
> >> Bridge can have external connectors, and the user can connect there
> >> anything.
> >>
> >>>> In general HPD is input signal for notify of state changes on particular
> >>>> bus, in case of typical video bridge on its output video bus.
> >>>>
> >>>> In case of bridges they have also input video buses, and they can send
> >>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>> if for most cases they looks similar.
> >>>
> >>> Ah, I think this is a problem we will eventually have. But it's not
> >>> something we're currently solving here at all I think.
> >>
> >> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >> line, so this is not something from far future. And I guess with HPD
> >> broadcasting it could be racy/error prone, for example EDID reading can
> >> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >> controller via hw wires also).
> >>
> >>>>>> And regarding implementation:
> >>>>>>
> >>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>
> >>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>
> >>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>> source we should locate it by parsing notification chain (what about
> >>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>
> >>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>
> >>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>> listener.
> >>>>
> >>>> Do we have real life examples?
> >>>>
> >>>> I want to distinguish two situations:
> >>>>
> >>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>
> >>>> - another device wants to know if output bus of the bridge has changed
> >>>> state.
> >>>
> >>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>> bridges can exchange state and information about each another. hpd is
> >>> about the physical world, i.e. "is there a cable plugged into the port
> >>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>> fun stuff like that, we have the atomic_check machinery for this.
> >>
> >> My question was if we have real examples that upstream device requires
> >> knowledge about state of output line of the bridge?
> >>
> >> To be more precise, we have following display pipeline:
> >>
> >> A-->B-->C
> >>
> >> And C sends HPD to B (ie signal that state of line between B and C
> >> changed). Does A really wants to know this information? or it should
> >> just need to know if state of line A-->B changed?
> >
> > There's one real life example, where A is an HDMI encoder, B is an HDMI
> > ESD protector and level shifter, and C is the physical HDMI connector.
> > When the HDMI cable is unplugged, the CEC controller part of A needs to
> > be notified in order to reset the CEC state machine. One could however
> > argue that in that case the A-B link state changes too, but the
> > important part is that HPD detection is not performed by A, while A
> > needs to be informed of lost hotplug.
> 
> I have no full picture but I guess in this case C sends HPD to B using
> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
> say that B does not participate in HPD transmission/forwarding,

No, in this case A doesn't receive any hardware HPD signal, it requires
HPD notification through software.

> some shifters with 'advanced power saving' can even perform wake-up of
> upstream pin logic after receiving HPD on downstream, so HPD sent from B
> to A is indeed different than HPD sent from C to B.
> 
> Btw, with the above logic of propagation of HPD callback (proposed by
> Daniel) I guess it will work this way:
> 
> - A will receive HPD signal via HW,
> 
> - then B and C will receive HPD callback via framework.
> 
> Am I right?

It's the other way around.

In this case the HPD signal from the connector (C) is routed to an input
of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
IRQ and receive the hardware HPD notification. The driver for the HDMI
encoder (A) needs to receive HPD notification in software, through the
framework.

> >>>>> You seem to have some other idea here.
> >>>>>
> >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>> +
> >>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>  /**
> >>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>  
> >>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>  
> >>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>  	 */
> >>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>> +	 * output.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>>
> >>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>> presence of another one?
> >>>>>>>>>>
> >>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>>
> >>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>> and connector->edid correctly.
> >>>>>>>>>
> >>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>> correctly updated.
> >>>>>>>>>
> >>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>  };
> >>>>>>>>>>>  
> >>>>>>>>>>>  /**
> >>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>  };
> >>>>>>>>>>>  
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>> + */
> >>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>> +};
> >>>>>>>>>>> +
> >>>>>>>>>>>  /**
> >>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>   */
> >>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	int type;
> >>>>>>>>>>> +	/** private: */
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>  };
> >>>>>>>>>>>  
> >>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>  
> >>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>> +			   void *data);
> >>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>> +
> >>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>  					u32 connector_type);

Andrzej Hajda Aug. 14, 2019, 6:23 a.m. UTC | #15

Hi Laurent,

Sorry for late response.


On 11.08.2019 00:43, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
>> On 08.08.2019 21:32, Laurent Pinchart wrote:
>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>> Hi Laurent,
>>>>>>>>>>>>
>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>>>>>>>> panel is very painful.
>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
>>>>>>>>>>>
>>>>>>>>>>>> More comments inlined.
>>>>>>>>>>>>
>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>>>>>>>> data:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>>>>>>>   retrieval operations
>>>>>>>>>>>>> - Bitmask of supported operations
>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>>>>>>>> operation's callback?
>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>>>>>>>>
>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>>>>>>>> add, generally good excuse to not have to think through the design between
>>>>>>>>>>> different parts of drivers - "just" add another flag.
>>>>>>>>>>>
>>>>>>>>>>>>> - Bridge output type
>>>>>>>>>>>>>
>>>>>>>>>>>>> Add and document these.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>>>>>>>> bridges.
>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>>>>>>>> right? More comments about it later.
>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>>>>>>>   */
>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>>>>>>>  {
>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>>>>>>>> +
>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>>>>>>>  }
>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>>>>>>>  
>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>  }
>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>>>>>>>  
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>> + * @cb: hot-plug detection callback
>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>>>>>>>> + * the bridge.
>>>>>>>>>>>>> + */
>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>>>>>>>> bridge attach:
>>>>>>>>>>>>
>>>>>>>>>>>> bridge->hpd_cb = cb;
>>>>>>>>>>>>
>>>>>>>>>>>> bridge->hpd_data = data;
>>>>>>>>>>>>
>>>>>>>>>>>> ret = drm_bridge_attach(...);
>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>>>>>>>
>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>>>>>>>> without big sacrifices.
>>>>>>>>>>>>
>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>>>>>>>
>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>> +			   void *data)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>>>>>>>> +		goto unlock;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>>>>>>>> +	bridge->hpd_data = data;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +unlock:
>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>>>>>>>> + * output status change occurs.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>> + * @status: output connection status
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>> +			   enum drm_connector_status status)
>>>>>>>>>>>>> +{
>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>> +	if (bridge->hpd_cb)
>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>>>>>>>
>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>>>>>>>> 		if (tmp_bridge == bridge)
>>>>>>>>>>> 			continue;
>>>>>>>>>>> 		if (bridge->hpd_notify);
>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>>>>>>>> 	}
>>>>>>>>>>>
>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>>>>>>>
>>>>>>>>>>> 	dev = bridge->dev
>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>>>>>>>
>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>>>>>>>> hpd they want/need.
>>>>>>>>>> As I understand you want to notify every member of the pipeline.
>>>>>>>>>>
>>>>>>>>>> I think it should be enough to notify only the source, and then source
>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
>>>>>>>>>>
>>>>>>>>>> It looks more generic for me.
>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>>>>>>>> the one from Laurent? Kinda confused here.
>>>>>>>> Regarding general idea:
>>>>>>>>
>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
>>>>>>>> source.
>>>>>>>>
>>>>>>>> 2. Your is to notify all other bridges and encoder.
>>>>>>>>
>>>>>>>> And I prefer 1st approach, why:
>>>>>>>>
>>>>>>>> - the source can decide if/when and to who propagate the signal,
>>>>>>>>
>>>>>>>> - is more generic, for example if bridge send signal to two
>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
>>>>>> If there will be two consumers, there will be two bridge attachments,
>>>>>> thus there will be two notifications, it should work.
>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
>>>>> callback is registered on the produce bridge, not on the consumer bridge
>>>>> (or I'm totallly misreading what Laurent does here).
>>>> I have assumed that if devices exposes two hardware sink interfaces it
>>>> will expose two separate bridges - of course it will not work with
>>>> "bridge chaining" thing, but this is a different story.
>>> Daniel is right that the current implementation only allows one
>>> consumer. This is however not a limitation of the API, but of its
>>> implementation, as I only needed a single consumer. The helpers in this
>>> series ensure that neither the consumer nor the producer poke in the
>>> drm_bridge structure to call back to the HPD handler:
>>>
>>> - The consumer calls drm_bridge_hpd_enable() and
>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
>>>   behaviour if desired without changes to the consumer.
>>>
>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
>>>   which could also easily accommodate reference-counting in the drm
>>>   bridge core without changes to the producer.
>>>
>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
>>>   easily be extended to support multiple consumers without changes to
>>>   the producer.
>>>
>>> This is actually my second version of the HPD mechanism. The first
>>> version was never posted, poked into drm_bridge, and required the
>>> producer to be aware of the callbacks. After discussing this privately
>>> with Daniel, I came up with the implementation in this series that,
>>> while not supporting multiple consumers now, makes it easy to extend
>>> later without minimal effort.
>>>
>>> Daniel's proposed implementation above looks reasonable to me, provided
>>> we can iterate over the bridges in an order that don't depend on the
>>> position of the producer in the chain (should be easy to solve by
>>> starting at the encoder for instance). It however looks a bit like a
>>> midlayer to me :-) That's why I have a similar implementation in the
>>> connector-bridge helper, which could be extended to call
>>> encoder->helper_private->bridge_hpd_notify() and
>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
>>> drm_bridge_hpd_notify() would on the other hand set the notification
>>> sequence towards the encoder and driver in stone. Daniel, do you think
>>> that would be better ?
>>>
>>> I would like to remind everybody that this series isn't the last I will
>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
>>> open to suggestions, and can address problems on top of these patches,
>>> provided obviously that this series doesn't go in the wrong direction.
>>> I'm of course also willing to rework this series, but given the amount
>>> of work we have in the drm_bridge realm, I can't fix everything in one
>>> go :-)
>>>
>>>>>>>> - it resembles hardware wires :)
>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
>>>>>>> interested in that hpd singal. This includes:
>>>>>>> - Other bridges, e.g. if they provide CEC support.
>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
>>>>>>> - Overall driver, so it can update the modes/connector status and send the
>>>>>>>   uevent to the driver.
>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
>>>>>>>   shut down/re-enable the pipe because $reasons.
>>>>>>>  
>>>>>>> That's at least my understanding from lots of chats with Laurent about
>>>>>>> what he wants to do here.
>>> That's correct, and that's what I was trying to implement :-) The
>>> notification, in this patch series, goes from the producer bridge to a
>>> central place (namely the connector, with a helper implementation
>>> available as part of this series, but custom implementations in display
>>> drivers are fine if needed) that then dispatches the notification to all
>>> bridges (through the .lost_hotplug() operation, which we could replace
>>> by an .hpd_notify() operation) for the first two purposes listed above,
>>> and then to the overall driver. The only thing I don't support yet is
>>> dispatching to the display pipeline (item 4 in the list above) as I had
>>> no need for that, and didn't want to develop an API with no user. This
>>> would however not be difficult to do when needed, the need is taken into
>>> account in the proposed implementation.
>>>
>>>>>> I do not know the full picture, but the solution where particular bridge
>>>>>> notifies everything unconditionally seems to me much less flexible.
>>>>>>
>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
>>>>>> will mimic your scenario.
>>>>>>
>>>>>> But there are also other scenarios where bridge does not want to
>>>>>> propagate signal, because for example:
>>>>>>
>>>>>> - it wants to wait for other sinks to wake up,
>>>>>>
>>>>> The other sink can just do that in their hpd callback.
>>>>>
>>>>>> - it propagates HPD signal via hardware wire,
>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
>>>>> the wire/hw hpd interrupt.
>>>>>
>>>> If it should ignore HPD, why it should receive it at all - it is
>>>> unnecessary noise. And I am afraid with more complicated pipelines it
>>>> will be impossible for particular component (bridge/encoder/whatever) to
>>>> distinguish if HPD notification which came from non-directly connected
>>>> component should be ignored or not.
>>>>
>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
>>>>>> device.
>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
>>>>> board?
>>>> Bridge can have external connectors, and the user can connect there
>>>> anything.
>>>>
>>>>>> In general HPD is input signal for notify of state changes on particular
>>>>>> bus, in case of typical video bridge on its output video bus.
>>>>>>
>>>>>> In case of bridges they have also input video buses, and they can send
>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
>>>>>> if for most cases they looks similar.
>>>>> Ah, I think this is a problem we will eventually have. But it's not
>>>>> something we're currently solving here at all I think.
>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
>>>> line, so this is not something from far future. And I guess with HPD
>>>> broadcasting it could be racy/error prone, for example EDID reading can
>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
>>>> controller via hw wires also).
>>>>
>>>>>>>> And regarding implementation:
>>>>>>>>
>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>>>>>>>
>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>>>>>>>
>>>>>>>> Your proposition is more straightforward, but if we want to notify only
>>>>>>>> source we should locate it by parsing notification chain (what about
>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
>>>>>>>>
>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
>>>>>>> Uh I think we're not talking about the same thing really. My understanding
>>>>>>> is that this callback is if someone (outside of this bridge) is interested
>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
>>>>>>> listener.
>>>>>> Do we have real life examples?
>>>>>>
>>>>>> I want to distinguish two situations:
>>>>>>
>>>>>> - another device wants to know if input bus of the bridge has changed state,
>>>>>>
>>>>>> - another device wants to know if output bus of the bridge has changed
>>>>>> state.
>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
>>>>> bridges can exchange state and information about each another. hpd is
>>>>> about the physical world, i.e. "is there a cable plugged into the port
>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
>>>>> fun stuff like that, we have the atomic_check machinery for this.
>>>> My question was if we have real examples that upstream device requires
>>>> knowledge about state of output line of the bridge?
>>>>
>>>> To be more precise, we have following display pipeline:
>>>>
>>>> A-->B-->C
>>>>
>>>> And C sends HPD to B (ie signal that state of line between B and C
>>>> changed). Does A really wants to know this information? or it should
>>>> just need to know if state of line A-->B changed?
>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
>>> ESD protector and level shifter, and C is the physical HDMI connector.
>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
>>> be notified in order to reset the CEC state machine. One could however
>>> argue that in that case the A-B link state changes too, but the
>>> important part is that HPD detection is not performed by A, while A
>>> needs to be informed of lost hotplug.
>> I have no full picture but I guess in this case C sends HPD to B using
>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
>> say that B does not participate in HPD transmission/forwarding,
> No, in this case A doesn't receive any hardware HPD signal, it requires
> HPD notification through software.
>
>> some shifters with 'advanced power saving' can even perform wake-up of
>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
>> to A is indeed different than HPD sent from C to B.
>>
>> Btw, with the above logic of propagation of HPD callback (proposed by
>> Daniel) I guess it will work this way:
>>
>> - A will receive HPD signal via HW,
>>
>> - then B and C will receive HPD callback via framework.
>>
>> Am I right?
> It's the other way around.
>
> In this case the HPD signal from the connector (C) is routed to an input
> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
> IRQ and receive the hardware HPD notification. The driver for the HDMI
> encoder (A) needs to receive HPD notification in software, through the
> framework.


If this is GPIO I wonder why do not query this gpio by encoder directly,
rules of ownership of such gpios seems to be grey area, so in such case
I would advise to put it in the driver who really needs it.

This way it will be much simpler.


Going back to HPD notifications, as I said earlier broadcasting HPD
notification unconditionally to every member of the chain with hope that
the member will be able to filter-out undesired notification seems to me
incorrect - maybe it can solve some problems but is not flexible enough
to be usable in other scenarios.

If my arguments do not convince you please just continue with your
ideas, we can always add NO_HPD_BROADCAST somewhere :)


Regards

Andrzej


>
>>>>>>> You seem to have some other idea here.
>>>>>>>
>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>> +}
>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>>>>>>>> +
>>>>>>>>>>>>>  #ifdef CONFIG_OF
>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>>>>>>>  
>>>>>>>>>>>>> -#include <linux/list.h>
>>>>>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>>>>>> +#include <linux/list.h>
>>>>>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>>>>>>>  
>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>>>>>>>  	 */
>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @detect:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @get_modes:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>>>>>>>> +			 struct drm_connector *connector);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @get_edid:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>>>>>>>> +	 * output.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>>>>>>>> +				 struct drm_connector *connector);
>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>>>>>>>> presence of another one?
>>>>>>>>>>>>
>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>>>>>>>> and connector->edid correctly.
>>>>>>>>>>>
>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>>>>>>>> correctly updated.
>>>>>>>>>>>
>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>>>>>>>> edid, which is not so awesome :-)
>>>>>>>>>>>
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @lost_hotplug:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>>>>>>>> +	 * HDMI bridges.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @hpd_enable:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>>>>>>>> +	 * @hpd_disable.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @hpd_disable:
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>>>>>>>> +	 * connection status occurs.
>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>  };
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  /**
>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>>>>>>>  	bool dual_link;
>>>>>>>>>>>>>  };
>>>>>>>>>>>>>  
>>>>>>>>>>>>> +/**
>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +enum drm_bridge_ops {
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>>>>>>>> +};
>>>>>>>>>>>>> +
>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>>>>>>>   */
>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>>>>>>>  	void *driver_private;
>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>>>>>>>> +	 * identifies the type of connected display.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	int type;
>>>>>>>>>>>>> +	/** private: */
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	struct mutex hpd_mutex;
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>>>>>>>> +	 * @hpd_cb.
>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>> +	void *hpd_data;
>>>>>>>>>>>>>  };
>>>>>>>>>>>>>  
>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>>>>>>>  
>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>> +			   void *data);
>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>> +			   enum drm_connector_status status);
>>>>>>>>>>>>> +
>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 14, 2019, 10:04 a.m. UTC | #16

Hi Andrzej,

On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
> Hi Laurent,
> 
> Sorry for late response.

No worries.

> On 11.08.2019 00:43, Laurent Pinchart wrote:
> > On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> >> On 08.08.2019 21:32, Laurent Pinchart wrote:
> >>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >>>> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>> Hi Laurent,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>>>> panel is very painful.
> >>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>>>
> >>>>>>>>>>>> More comments inlined.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>>>> data:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>>>   retrieval operations
> >>>>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>>>> operation's callback?
> >>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>>>
> >>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>>>
> >>>>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Add and document these.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>>>> bridges.
> >>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>>>   */
> >>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>>>  {
> >>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>>>  }
> >>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  }
> >>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>>>> + * the bridge.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>>>> bridge attach:
> >>>>>>>>>>>>
> >>>>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>>>
> >>>>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>>>
> >>>>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>>>
> >>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>>>> without big sacrifices.
> >>>>>>>>>>>>
> >>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>> +			   void *data)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +unlock:
> >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>>>
> >>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>>>> 			continue;
> >>>>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>>>> 	}
> >>>>>>>>>>>
> >>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>>>
> >>>>>>>>>>> 	dev = bridge->dev
> >>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>>>
> >>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>>>> hpd they want/need.
> >>>>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>>>
> >>>>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>>>
> >>>>>>>>>> It looks more generic for me.
> >>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>>> Regarding general idea:
> >>>>>>>>
> >>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>>>> source.
> >>>>>>>>
> >>>>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>>>
> >>>>>>>> And I prefer 1st approach, why:
> >>>>>>>>
> >>>>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>>>
> >>>>>>>> - is more generic, for example if bridge send signal to two
> >>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>>> If there will be two consumers, there will be two bridge attachments,
> >>>>>> thus there will be two notifications, it should work.
> >>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>>>> callback is registered on the produce bridge, not on the consumer bridge
> >>>>> (or I'm totallly misreading what Laurent does here).
> >>>> I have assumed that if devices exposes two hardware sink interfaces it
> >>>> will expose two separate bridges - of course it will not work with
> >>>> "bridge chaining" thing, but this is a different story.
> >>> Daniel is right that the current implementation only allows one
> >>> consumer. This is however not a limitation of the API, but of its
> >>> implementation, as I only needed a single consumer. The helpers in this
> >>> series ensure that neither the consumer nor the producer poke in the
> >>> drm_bridge structure to call back to the HPD handler:
> >>>
> >>> - The consumer calls drm_bridge_hpd_enable() and
> >>>   drm_bridge_hpd_disable(), which could offer a reference-counted
> >>>   behaviour if desired without changes to the consumer.
> >>>
> >>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >>>   which could also easily accommodate reference-counting in the drm
> >>>   bridge core without changes to the producer.
> >>>
> >>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >>>   easily be extended to support multiple consumers without changes to
> >>>   the producer.
> >>>
> >>> This is actually my second version of the HPD mechanism. The first
> >>> version was never posted, poked into drm_bridge, and required the
> >>> producer to be aware of the callbacks. After discussing this privately
> >>> with Daniel, I came up with the implementation in this series that,
> >>> while not supporting multiple consumers now, makes it easy to extend
> >>> later without minimal effort.
> >>>
> >>> Daniel's proposed implementation above looks reasonable to me, provided
> >>> we can iterate over the bridges in an order that don't depend on the
> >>> position of the producer in the chain (should be easy to solve by
> >>> starting at the encoder for instance). It however looks a bit like a
> >>> midlayer to me :-) That's why I have a similar implementation in the
> >>> connector-bridge helper, which could be extended to call
> >>> encoder->helper_private->bridge_hpd_notify() and
> >>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> >>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> >>> drm_bridge_hpd_notify() would on the other hand set the notification
> >>> sequence towards the encoder and driver in stone. Daniel, do you think
> >>> that would be better ?
> >>>
> >>> I would like to remind everybody that this series isn't the last I will
> >>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> >>> open to suggestions, and can address problems on top of these patches,
> >>> provided obviously that this series doesn't go in the wrong direction.
> >>> I'm of course also willing to rework this series, but given the amount
> >>> of work we have in the drm_bridge realm, I can't fix everything in one
> >>> go :-)
> >>>
> >>>>>>>> - it resembles hardware wires :)
> >>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>>>> interested in that hpd singal. This includes:
> >>>>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>>>   uevent to the driver.
> >>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>>>  
> >>>>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>>>> what he wants to do here.
> >>> That's correct, and that's what I was trying to implement :-) The
> >>> notification, in this patch series, goes from the producer bridge to a
> >>> central place (namely the connector, with a helper implementation
> >>> available as part of this series, but custom implementations in display
> >>> drivers are fine if needed) that then dispatches the notification to all
> >>> bridges (through the .lost_hotplug() operation, which we could replace
> >>> by an .hpd_notify() operation) for the first two purposes listed above,
> >>> and then to the overall driver. The only thing I don't support yet is
> >>> dispatching to the display pipeline (item 4 in the list above) as I had
> >>> no need for that, and didn't want to develop an API with no user. This
> >>> would however not be difficult to do when needed, the need is taken into
> >>> account in the proposed implementation.
> >>>
> >>>>>> I do not know the full picture, but the solution where particular bridge
> >>>>>> notifies everything unconditionally seems to me much less flexible.
> >>>>>>
> >>>>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>>>> will mimic your scenario.
> >>>>>>
> >>>>>> But there are also other scenarios where bridge does not want to
> >>>>>> propagate signal, because for example:
> >>>>>>
> >>>>>> - it wants to wait for other sinks to wake up,
> >>>>>>
> >>>>> The other sink can just do that in their hpd callback.
> >>>>>
> >>>>>> - it propagates HPD signal via hardware wire,
> >>>>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>>>> the wire/hw hpd interrupt.
> >>>>>
> >>>> If it should ignore HPD, why it should receive it at all - it is
> >>>> unnecessary noise. And I am afraid with more complicated pipelines it
> >>>> will be impossible for particular component (bridge/encoder/whatever) to
> >>>> distinguish if HPD notification which came from non-directly connected
> >>>> component should be ignored or not.
> >>>>
> >>>>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>>>> device.
> >>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>>>> board?
> >>>> Bridge can have external connectors, and the user can connect there
> >>>> anything.
> >>>>
> >>>>>> In general HPD is input signal for notify of state changes on particular
> >>>>>> bus, in case of typical video bridge on its output video bus.
> >>>>>>
> >>>>>> In case of bridges they have also input video buses, and they can send
> >>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>>>> if for most cases they looks similar.
> >>>>> Ah, I think this is a problem we will eventually have. But it's not
> >>>>> something we're currently solving here at all I think.
> >>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >>>> line, so this is not something from far future. And I guess with HPD
> >>>> broadcasting it could be racy/error prone, for example EDID reading can
> >>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >>>> controller via hw wires also).
> >>>>
> >>>>>>>> And regarding implementation:
> >>>>>>>>
> >>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>>>
> >>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>>>
> >>>>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>>>> source we should locate it by parsing notification chain (what about
> >>>>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>>>
> >>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>>>> listener.
> >>>>>> Do we have real life examples?
> >>>>>>
> >>>>>> I want to distinguish two situations:
> >>>>>>
> >>>>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>>>
> >>>>>> - another device wants to know if output bus of the bridge has changed
> >>>>>> state.
> >>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>>>> bridges can exchange state and information about each another. hpd is
> >>>>> about the physical world, i.e. "is there a cable plugged into the port
> >>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>>>> fun stuff like that, we have the atomic_check machinery for this.
> >>>> My question was if we have real examples that upstream device requires
> >>>> knowledge about state of output line of the bridge?
> >>>>
> >>>> To be more precise, we have following display pipeline:
> >>>>
> >>>> A-->B-->C
> >>>>
> >>>> And C sends HPD to B (ie signal that state of line between B and C
> >>>> changed). Does A really wants to know this information? or it should
> >>>> just need to know if state of line A-->B changed?
> >>> There's one real life example, where A is an HDMI encoder, B is an HDMI
> >>> ESD protector and level shifter, and C is the physical HDMI connector.
> >>> When the HDMI cable is unplugged, the CEC controller part of A needs to
> >>> be notified in order to reset the CEC state machine. One could however
> >>> argue that in that case the A-B link state changes too, but the
> >>> important part is that HPD detection is not performed by A, while A
> >>> needs to be informed of lost hotplug.
> >> I have no full picture but I guess in this case C sends HPD to B using
> >> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
> >> say that B does not participate in HPD transmission/forwarding,
> > No, in this case A doesn't receive any hardware HPD signal, it requires
> > HPD notification through software.
> >
> >> some shifters with 'advanced power saving' can even perform wake-up of
> >> upstream pin logic after receiving HPD on downstream, so HPD sent from B
> >> to A is indeed different than HPD sent from C to B.
> >>
> >> Btw, with the above logic of propagation of HPD callback (proposed by
> >> Daniel) I guess it will work this way:
> >>
> >> - A will receive HPD signal via HW,
> >>
> >> - then B and C will receive HPD callback via framework.
> >>
> >> Am I right?
> 
> > It's the other way around.
> >
> > In this case the HPD signal from the connector (C) is routed to an input
> > of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
> > connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
> > IRQ and receive the hardware HPD notification. The driver for the HDMI
> > encoder (A) needs to receive HPD notification in software, through the
> > framework.
> 
> If this is GPIO I wonder why do not query this gpio by encoder directly,
> rules of ownership of such gpios seems to be grey area, so in such case
> I would advise to put it in the driver who really needs it.
> 
> This way it will be much simpler.

First to fall, multiple drivers may need to be informed of HPD events
coming from a GPIO, so we would need to duplicate it in multiple places,
and I don't think the GPIO framework allows acquiring a GPIO multiple
times.

Then, the GPIO is described in DT, and DT doesn't care about which
driver needs HPD events. DT specifies the GPIO in the node of the device
it belongs to, this is defined in DT bindings, and must be the same on
all boards, while depending on the board different devices may need to
be informed of HPD events.

For those two reasons HPD GPIO handling and consumption of HPD events
can't always be grouped in the same driver.

> Going back to HPD notifications, as I said earlier broadcasting HPD
> notification unconditionally to every member of the chain with hope that
> the member will be able to filter-out undesired notification seems to me
> incorrect - maybe it can solve some problems but is not flexible enough
> to be usable in other scenarios.
> 
> If my arguments do not convince you please just continue with your
> ideas, we can always add NO_HPD_BROADCAST somewhere :)

:-) I would like to understand the problems you're referring to though,
and hopefully solve them. If you could describe one of the scenarios
where you think this mechanism wouldn't be usable that would help. In
the meantime I will post a new version of the series with these
operations kept as-is to get the rest of the patches reviewed.

> >>>>>>> You seem to have some other idea here.
> >>>>>>>
> >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>>>  	 */
> >>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>>>> +	 * output.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>>>> presence of another one?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>>>> and connector->edid correctly.
> >>>>>>>>>>>
> >>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>>>> correctly updated.
> >>>>>>>>>>>
> >>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>>>
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>  };
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>>  /**
> >>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>>>  };
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>>>> +};
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>>>   */
> >>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	int type;
> >>>>>>>>>>>>> +	/** private: */
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>>>  };
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>> +			   void *data);
> >>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>>>  					u32 connector_type);

Daniel Vetter Aug. 14, 2019, 12:35 p.m. UTC | #17

On Thu, Aug 08, 2019 at 10:32:14PM +0300, Laurent Pinchart wrote:
> Hello,
> 
> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> > On 16.07.2019 11:00, Daniel Vetter wrote:
> > > On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> > >> On 11.07.2019 17:50, Daniel Vetter wrote:
> > >>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> > >>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> > >>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> > >>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> > >>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > >>>>>>>> Hi Laurent,
> > >>>>>>>>
> > >>>>>>>> I like the approach, current practice when almost every bridge should
> > >>>>>>>> optionally implement connector, or alternatively downstream bridge or
> > >>>>>>>> panel is very painful.
> > >>>>>>>
> > >>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> > >>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> > >>>>>>> it's all used in the end. I probably should go and do that, at least to
> > >>>>>>> get a feeling for what your hpd_cb usually does.
> > >>>>>>>
> > >>>>>>>> More comments inlined.
> > >>>>>>>>
> > >>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > >>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> > >>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> > >>>>>>>>> data:
> > >>>>>>>>>
> > >>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> > >>>>>>>>>   retrieval operations
> > >>>>>>>>> - Bitmask of supported operations
> > >>>>>>>>
> > >>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> > >>>>>>>> operation's callback?
> > >>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> > >>>>>>>
> > >>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > >>>>>>> add, generally good excuse to not have to think through the design between
> > >>>>>>> different parts of drivers - "just" add another flag.
> > >>>>>>>
> > >>>>>>>>> - Bridge output type
> > >>>>>>>>>
> > >>>>>>>>> Add and document these.
> > >>>>>>>>>
> > >>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> > >>>>>>>>> notification in a way that is as transparent as possible for the
> > >>>>>>>>> bridges.
> > >>>>>>>>
> > >>>>>>>> Documentation of new opses does not explain how it should cooperate with
> > >>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> > >>>>>>>> right? More comments about it later.
> > >>>>>>>>
> > >>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> > >>>>>>>>> ---
> > >>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> > >>>>>>>>>
> > >>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> > >>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >>>>>>>>>   */
> > >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> > >>>>>>>>>  {
> > >>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> > >>>>>>>>> +
> > >>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> > >>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>  	list_del_init(&bridge->list);
> > >>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>> +
> > >>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> > >>>>>>>>>  }
> > >>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> > >>>>>>>>>  
> > >>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>  }
> > >>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >>>>>>>>>  
> > >>>>>>>>> +/**
> > >>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > >>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>> + * @cb: hot-plug detection callback
> > >>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> > >>>>>>>>> + *
> > >>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > >>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> > >>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> > >>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> > >>>>>>>>> + *
> > >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>> + *
> > >>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> > >>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> > >>>>>>>>> + * the bridge.
> > >>>>>>>>> + */
> > >>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> > >>>>>>>> bridge attach:
> > >>>>>>>>
> > >>>>>>>> bridge->hpd_cb = cb;
> > >>>>>>>>
> > >>>>>>>> bridge->hpd_data = data;
> > >>>>>>>>
> > >>>>>>>> ret = drm_bridge_attach(...);
> > >>>>>>>
> > >>>>>>> Yeah I like this more. The other problem here is, what if you need more
> > >>>>>>> than 1 callback registers on the same bridge hdp signal?
> > >>>>>>>
> > >>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> > >>>>>>>> without big sacrifices.
> > >>>>>>>>
> > >>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > >>>>>>>> notifies about sink status change, how it translates to this cb?
> > >>>>>>>>
> > >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>> +			   void *data)
> > >>>>>>>>> +{
> > >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> > >>>>>>>>> +		return;
> > >>>>>>>>> +
> > >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>> +
> > >>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > >>>>>>>>> +		goto unlock;
> > >>>>>>>>> +
> > >>>>>>>>> +	bridge->hpd_cb = cb;
> > >>>>>>>>> +	bridge->hpd_data = data;
> > >>>>>>>>> +
> > >>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +unlock:
> > >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>> +}
> > >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > >>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>> + *
> > >>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > >>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > >>>>>>>>> + * function returns the callback will not be called by the bridge when an
> > >>>>>>>>> + * output status change occurs.
> > >>>>>>>>> + *
> > >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>> + */
> > >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > >>>>>>>>> +{
> > >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> > >>>>>>>>> +		return;
> > >>>>>>>>> +
> > >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	bridge->hpd_cb = NULL;
> > >>>>>>>>> +	bridge->hpd_data = NULL;
> > >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>> +}
> > >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> > >>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>> + * @status: output connection status
> > >>>>>>>>> + *
> > >>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> > >>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> > >>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > >>>>>>>>> + *
> > >>>>>>>>> + * This function shall be called in a context that can sleep.
> > >>>>>>>>> + */
> > >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>> +			   enum drm_connector_status status)
> > >>>>>>>>> +{
> > >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>> +	if (bridge->hpd_cb)
> > >>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > >>>>>>>
> > >>>>>>> So this isn't quite what I had in mind. Instead something like this:
> > >>>>>>>
> > >>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> > >>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> > >>>>>>> 		if (tmp_bridge == bridge)
> > >>>>>>> 			continue;
> > >>>>>>> 		if (bridge->hpd_notify);
> > >>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > >>>>>>> 	}
> > >>>>>>>
> > >>>>>>> 	encoder = encoder_for_bridge(bridge);
> > >>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> > >>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > >>>>>>>
> > >>>>>>> 	dev = bridge->dev
> > >>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > >>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > >>>>>>>
> > >>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> > >>>>>>> hpd they want/need.
> > >>>>>> As I understand you want to notify every member of the pipeline.
> > >>>>>>
> > >>>>>> I think it should be enough to notify only the source, and then source
> > >>>>>> should decide if/when the hpd should be propagated upstream.
> > >>>>>>
> > >>>>>> It looks more generic for me.
> > >>>>>
> > >>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> > >>>>> the one from Laurent? Kinda confused here.
> > >>>>
> > >>>> Regarding general idea:
> > >>>>
> > >>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> > >>>> source.
> > >>>>
> > >>>> 2. Your is to notify all other bridges and encoder.
> > >>>>
> > >>>> And I prefer 1st approach, why:
> > >>>>
> > >>>> - the source can decide if/when and to who propagate the signal,
> > >>>>
> > >>>> - is more generic, for example if bridge send signal to two
> > >>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> > >>>
> > >>> With Laurent's approach the bridge cannot send the hpd to more than one
> > >>> consumer. There's only 1 callback. So you're example doesn't work.
> > >>
> > >> If there will be two consumers, there will be two bridge attachments,
> > >> thus there will be two notifications, it should work.
> > >
> > > 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> > > callback is registered on the produce bridge, not on the consumer bridge
> > > (or I'm totallly misreading what Laurent does here).
> > 
> > I have assumed that if devices exposes two hardware sink interfaces it
> > will expose two separate bridges - of course it will not work with
> > "bridge chaining" thing, but this is a different story.
> 
> Daniel is right that the current implementation only allows one
> consumer. This is however not a limitation of the API, but of its
> implementation, as I only needed a single consumer. The helpers in this
> series ensure that neither the consumer nor the producer poke in the
> drm_bridge structure to call back to the HPD handler:
> 
> - The consumer calls drm_bridge_hpd_enable() and
>   drm_bridge_hpd_disable(), which could offer a reference-counted
>   behaviour if desired without changes to the consumer.
> 
> - The producer gets configured by .hpd_enable() and .hpd_disable(),
>   which could also easily accommodate reference-counting in the drm
>   bridge core without changes to the producer.
> 
> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
>   easily be extended to support multiple consumers without changes to
>   the producer.
> 
> This is actually my second version of the HPD mechanism. The first
> version was never posted, poked into drm_bridge, and required the
> producer to be aware of the callbacks. After discussing this privately
> with Daniel, I came up with the implementation in this series that,
> while not supporting multiple consumers now, makes it easy to extend
> later without minimal effort.
> 
> Daniel's proposed implementation above looks reasonable to me, provided
> we can iterate over the bridges in an order that don't depend on the
> position of the producer in the chain (should be easy to solve by
> starting at the encoder for instance). It however looks a bit like a
> midlayer to me :-) That's why I have a similar implementation in the
> connector-bridge helper, which could be extended to call
> encoder->helper_private->bridge_hpd_notify() and
> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> drm_bridge_hpd_notify() would on the other hand set the notification
> sequence towards the encoder and driver in stone. Daniel, do you think
> that would be better ?

So the difference between the midlayer and the helper is that the helper
can be ignored. Which the above still can:

- producer can choose to not call that function
- consumer can choose not to have the callback

Now great helpers allow you to ignore only parts of them, so that you can
mix&match. Which again I think with the bridge stuff we're discussing here
is assured.

So the final bit is how opinionated a helper can be, and imo it can be
very opinionated and strict and inflexible. That means it won't be useful
for every possible case, but those can be handled by simply not using the
helper (or that part of the helpers). Examples

- simple display pipe is very opinionated, but trades that in for being
  very useful for really simple displays

- similar with atomic helpers, there's a very strong suggestion that "if
  it doesn't fit, write your own commit_tail()"
 
And I think bridge helpers probably also need fairly opinioated, simply to
make sure that all the bridge drivers work together in a coherent fashion.
If we allow too much flexibility everyone bends the rules a bit, and
nothing fits.

Wrt your question: One option would be to do the same thing like shared
interrupt line handlers. As soon as the first interrupt handler says "I'
ve handled this one" we stop processing. But that might lead to more
confusion about who's responsible for an interrupt.
-Daniel

> 
> I would like to remind everybody that this series isn't the last I will
> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> open to suggestions, and can address problems on top of these patches,
> provided obviously that this series doesn't go in the wrong direction.
> I'm of course also willing to rework this series, but given the amount
> of work we have in the drm_bridge realm, I can't fix everything in one
> go :-)
> 
> > >>>> - it resembles hardware wires :)
> > >>>
> > >>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> > >>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> > >>> interested in that hpd singal. This includes:
> > >>> - Other bridges, e.g. if they provide CEC support.
> > >>> - Other bridges, maybe they need to re-run the HDCP state engine
> > >>> - Overall driver, so it can update the modes/connector status and send the
> > >>>   uevent to the driver.
> > >>> - Overall display pipeline for this specific bridge, maybe you need to
> > >>>   shut down/re-enable the pipe because $reasons.
> > >>>  
> > >>> That's at least my understanding from lots of chats with Laurent about
> > >>> what he wants to do here.
> 
> That's correct, and that's what I was trying to implement :-) The
> notification, in this patch series, goes from the producer bridge to a
> central place (namely the connector, with a helper implementation
> available as part of this series, but custom implementations in display
> drivers are fine if needed) that then dispatches the notification to all
> bridges (through the .lost_hotplug() operation, which we could replace
> by an .hpd_notify() operation) for the first two purposes listed above,
> and then to the overall driver. The only thing I don't support yet is
> dispatching to the display pipeline (item 4 in the list above) as I had
> no need for that, and didn't want to develop an API with no user. This
> would however not be difficult to do when needed, the need is taken into
> account in the proposed implementation.
> 
> > >> I do not know the full picture, but the solution where particular bridge
> > >> notifies everything unconditionally seems to me much less flexible.
> > >>
> > >> If HPD signals is received by the consumer, if there are no obstacles it
> > >> can propagate it further, upstream bridge/encoder or to drm core - it
> > >> will mimic your scenario.
> > >>
> > >> But there are also other scenarios where bridge does not want to
> > >> propagate signal, because for example:
> > >>
> > >> - it wants to wait for other sinks to wake up,
> > >
> > > The other sink can just do that in their hpd callback.
> > >
> > >> - it propagates HPD signal via hardware wire,
> > >
> > > Again, the other sink can just not listen to sw hpd in that case, and use
> > > the wire/hw hpd interrupt.
> > 
> > If it should ignore HPD, why it should receive it at all - it is
> > unnecessary noise. And I am afraid with more complicated pipelines it
> > will be impossible for particular component (bridge/encoder/whatever) to
> > distinguish if HPD notification which came from non-directly connected
> > component should be ignored or not.
> > 
> > >> - first it wants to verify if the sink is valid/compatible/authorized
> > >> device.
> > >
> > > Now you lost me. Why would someone glue incompatible IP into a SoC or
> > > board?
> > 
> > Bridge can have external connectors, and the user can connect there
> > anything.
> > 
> > >> In general HPD is input signal for notify of state changes on particular
> > >> bus, in case of typical video bridge on its output video bus.
> > >>
> > >> In case of bridges they have also input video buses, and they can send
> > >> HPD signal via this bus, but this is indeed different HPD signal, even
> > >> if for most cases they looks similar.
> > >
> > > Ah, I think this is a problem we will eventually have. But it's not
> > > something we're currently solving here at all I think.
> > 
> > Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> > line, so this is not something from far future. And I guess with HPD
> > broadcasting it could be racy/error prone, for example EDID reading can
> > fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> > controller via hw wires also).
> > 
> > >>>> And regarding implementation:
> > >>>>
> > >>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> > >>>>
> > >>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> > >>>>
> > >>>> Your proposition is more straightforward, but if we want to notify only
> > >>>> source we should locate it by parsing notification chain (what about
> > >>>> unchained bridges), or store pointer somewhere during attachment.
> > >>>>
> > >>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> > >>>> similarly to sink as bridge or panel, but fixing it can be done later.
> > >>>
> > >>> Uh I think we're not talking about the same thing really. My understanding
> > >>> is that this callback is if someone (outside of this bridge) is interested
> > >>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> > >>> listener.
> > >>
> > >> Do we have real life examples?
> > >>
> > >> I want to distinguish two situations:
> > >>
> > >> - another device wants to know if input bus of the bridge has changed state,
> > >>
> > >> - another device wants to know if output bus of the bridge has changed
> > >> state.
> > >
> > > Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> > > bridges can exchange state and information about each another. hpd is
> > > about the physical world, i.e. "is there a cable plugged into the port
> > > I'm driving?". We're not going to use fake hpd to update bridge state and
> > > fun stuff like that, we have the atomic_check machinery for this.
> > 
> > My question was if we have real examples that upstream device requires
> > knowledge about state of output line of the bridge?
> > 
> > To be more precise, we have following display pipeline:
> > 
> > A-->B-->C
> > 
> > And C sends HPD to B (ie signal that state of line between B and C
> > changed). Does A really wants to know this information? or it should
> > just need to know if state of line A-->B changed?
> 
> There's one real life example, where A is an HDMI encoder, B is an HDMI
> ESD protector and level shifter, and C is the physical HDMI connector.
> When the HDMI cable is unplugged, the CEC controller part of A needs to
> be notified in order to reset the CEC state machine. One could however
> argue that in that case the A-B link state changes too, but the
> important part is that HPD detection is not performed by A, while A
> needs to be informed of lost hotplug.
> 
> > >>> You seem to have some other idea here.
> > >>>
> > >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>> +}
> > >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > >>>>>>>>> +
> > >>>>>>>>>  #ifdef CONFIG_OF
> > >>>>>>>>>  /**
> > >>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > >>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > >>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> > >>>>>>>>> --- a/include/drm/drm_bridge.h
> > >>>>>>>>> +++ b/include/drm/drm_bridge.h
> > >>>>>>>>> @@ -23,8 +23,9 @@
> > >>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> > >>>>>>>>>  #define __DRM_BRIDGE_H__
> > >>>>>>>>>  
> > >>>>>>>>> -#include <linux/list.h>
> > >>>>>>>>>  #include <linux/ctype.h>
> > >>>>>>>>> +#include <linux/list.h>
> > >>>>>>>>> +#include <linux/mutex.h>
> > >>>>>>>>>  #include <drm/drm_mode_object.h>
> > >>>>>>>>>  #include <drm/drm_modes.h>
> > >>>>>>>>>  
> > >>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >>>>>>>>>  	 */
> > >>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >>>>>>>>>  				    struct drm_atomic_state *state);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @detect:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Check if anything is attached to the bridge output.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> > >>>>>>>>> +	 * considered as always having a component attached to its output.
> > >>>>>>>>> +	 * Bridges that implement this callback shall set the
> > >>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * RETURNS:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @get_modes:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> > >>>>>>>>> +	 * with drm_mode_probed_add().
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> > >>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> > >>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> > >>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * RETURNS:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> > >>>>>>>>> +			 struct drm_connector *connector);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @get_edid:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> > >>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> > >>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> > >>>>>>>>> +	 * the @get_modes callback unimplemented.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The caller of this operation shall first verify the output
> > >>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> > >>>>>>>>> +	 * output.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * RETURNS:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > >>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> > >>>>>>>>> +	 * the returned edid structure with kfree().
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > >>>>>>>>> +				 struct drm_connector *connector);
> > >>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> > >>>>>>>> presence of another one?
> > >>>>>>>>
> > >>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> > >>>>>>>> some helper function to .get_modes cb, which will do the same?
> > >>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > >>>>>>> case, and require that if it has an edid it must fill out connector->info
> > >>>>>>> and connector->edid correctly.
> > >>>>>>>
> > >>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> > >>>>>>> in the connector is up-to-date? With your current callback design that's
> > >>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > >>>>>>> should guarantee that it'll first walk the connectors to update status and
> > >>>>>>> edid/mode list for the final drm_connector. And then instead of just
> > >>>>>>> passing the simple "status", it'll pass the connector, with everything
> > >>>>>>> correctly updated.
> > >>>>>>>
> > >>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> > >>>>>>> edid, which is not so awesome :-)
> > >>>>>>>
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @lost_hotplug:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Notify the bridge of display disconnection.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> > >>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> > >>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> > >>>>>>>>> +	 * HDMI bridges.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_enable:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> > >>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > >>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> > >>>>>>>>> +	 * @hpd_disable.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> > >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_disable:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> > >>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > >>>>>>>>> +	 * connection status occurs.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> > >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >>>>>>>>>  };
> > >>>>>>>>>  
> > >>>>>>>>>  /**
> > >>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >>>>>>>>>  	bool dual_link;
> > >>>>>>>>>  };
> > >>>>>>>>>  
> > >>>>>>>>> +/**
> > >>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > >>>>>>>>> + */
> > >>>>>>>>> +enum drm_bridge_ops {
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > >>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> > >>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > >>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> > >>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > >>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> > >>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> > >>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > >>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> > >>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > >>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> > >>>>>>>>> +};
> > >>>>>>>>> +
> > >>>>>>>>>  /**
> > >>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> > >>>>>>>>>   */
> > >>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> > >>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> > >>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> > >>>>>>>>>  	void *driver_private;
> > >>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> > >>>>>>>>> +	enum drm_bridge_ops ops;
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @type: Type of the connection at the bridge output
> > >>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > >>>>>>>>> +	 * identifies the type of connected display.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	int type;
> > >>>>>>>>> +	/** private: */
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	struct mutex hpd_mutex;
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> > >>>>>>>>> +	 * drm_bridge_hpd_enable().
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > >>>>>>>>> +	 * @hpd_cb.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void *hpd_data;
> > >>>>>>>>>  };
> > >>>>>>>>>  
> > >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> > >>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>  			      struct drm_atomic_state *state);
> > >>>>>>>>>  
> > >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>> +			   void *data);
> > >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>> +			   enum drm_connector_status status);
> > >>>>>>>>> +
> > >>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >>>>>>>>>  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Daniel Vetter Aug. 14, 2019, 12:40 p.m. UTC | #18

On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
> Hi Andrzej,
> 
> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
> > Hi Laurent,
> > 
> > Sorry for late response.
> 
> No worries.
> 
> > On 11.08.2019 00:43, Laurent Pinchart wrote:
> > > On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> > >> On 08.08.2019 21:32, Laurent Pinchart wrote:
> > >>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> > >>>> On 16.07.2019 11:00, Daniel Vetter wrote:
> > >>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> > >>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> > >>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> > >>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> > >>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> > >>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> > >>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > >>>>>>>>>>>> Hi Laurent,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I like the approach, current practice when almost every bridge should
> > >>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> > >>>>>>>>>>>> panel is very painful.
> > >>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> > >>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> > >>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> > >>>>>>>>>>> get a feeling for what your hpd_cb usually does.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> More comments inlined.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > >>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> > >>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> > >>>>>>>>>>>>> data:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> > >>>>>>>>>>>>>   retrieval operations
> > >>>>>>>>>>>>> - Bitmask of supported operations
> > >>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> > >>>>>>>>>>>> operation's callback?
> > >>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> > >>>>>>>>>>>
> > >>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > >>>>>>>>>>> add, generally good excuse to not have to think through the design between
> > >>>>>>>>>>> different parts of drivers - "just" add another flag.
> > >>>>>>>>>>>
> > >>>>>>>>>>>>> - Bridge output type
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Add and document these.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> > >>>>>>>>>>>>> notification in a way that is as transparent as possible for the
> > >>>>>>>>>>>>> bridges.
> > >>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> > >>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> > >>>>>>>>>>>> right? More comments about it later.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> > >>>>>>>>>>>>> ---
> > >>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> > >>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >>>>>>>>>>>>>   */
> > >>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> > >>>>>>>>>>>>>  {
> > >>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> > >>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>>>>>  	list_del_init(&bridge->list);
> > >>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> > >>>>>>>>>>>>>  }
> > >>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>>>  }
> > >>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>> +/**
> > >>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > >>>>>>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>>>>>> + * @cb: hot-plug detection callback
> > >>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > >>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> > >>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> > >>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> > >>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> > >>>>>>>>>>>>> + * the bridge.
> > >>>>>>>>>>>>> + */
> > >>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> > >>>>>>>>>>>> bridge attach:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> bridge->hpd_cb = cb;
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> bridge->hpd_data = data;
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> ret = drm_bridge_attach(...);
> > >>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> > >>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> > >>>>>>>>>>>
> > >>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> > >>>>>>>>>>>> without big sacrifices.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > >>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>>>>>> +			   void *data)
> > >>>>>>>>>>>>> +{
> > >>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> > >>>>>>>>>>>>> +		return;
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > >>>>>>>>>>>>> +		goto unlock;
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	bridge->hpd_cb = cb;
> > >>>>>>>>>>>>> +	bridge->hpd_data = data;
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +unlock:
> > >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +}
> > >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +/**
> > >>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > >>>>>>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > >>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > >>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> > >>>>>>>>>>>>> + * output status change occurs.
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>>>>>> + */
> > >>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > >>>>>>>>>>>>> +{
> > >>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> > >>>>>>>>>>>>> +		return;
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
> > >>>>>>>>>>>>> +	bridge->hpd_data = NULL;
> > >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +}
> > >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +/**
> > >>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> > >>>>>>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>>>>>> + * @status: output connection status
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> > >>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> > >>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > >>>>>>>>>>>>> + *
> > >>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
> > >>>>>>>>>>>>> + */
> > >>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>>>>>> +			   enum drm_connector_status status)
> > >>>>>>>>>>>>> +{
> > >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +	if (bridge->hpd_cb)
> > >>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > >>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> > >>>>>>>>>>>
> > >>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> > >>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> > >>>>>>>>>>> 		if (tmp_bridge == bridge)
> > >>>>>>>>>>> 			continue;
> > >>>>>>>>>>> 		if (bridge->hpd_notify);
> > >>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > >>>>>>>>>>> 	}
> > >>>>>>>>>>>
> > >>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> > >>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> > >>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > >>>>>>>>>>>
> > >>>>>>>>>>> 	dev = bridge->dev
> > >>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > >>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > >>>>>>>>>>>
> > >>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> > >>>>>>>>>>> hpd they want/need.
> > >>>>>>>>>> As I understand you want to notify every member of the pipeline.
> > >>>>>>>>>>
> > >>>>>>>>>> I think it should be enough to notify only the source, and then source
> > >>>>>>>>>> should decide if/when the hpd should be propagated upstream.
> > >>>>>>>>>>
> > >>>>>>>>>> It looks more generic for me.
> > >>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> > >>>>>>>>> the one from Laurent? Kinda confused here.
> > >>>>>>>> Regarding general idea:
> > >>>>>>>>
> > >>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> > >>>>>>>> source.
> > >>>>>>>>
> > >>>>>>>> 2. Your is to notify all other bridges and encoder.
> > >>>>>>>>
> > >>>>>>>> And I prefer 1st approach, why:
> > >>>>>>>>
> > >>>>>>>> - the source can decide if/when and to who propagate the signal,
> > >>>>>>>>
> > >>>>>>>> - is more generic, for example if bridge send signal to two
> > >>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> > >>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> > >>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
> > >>>>>> If there will be two consumers, there will be two bridge attachments,
> > >>>>>> thus there will be two notifications, it should work.
> > >>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> > >>>>> callback is registered on the produce bridge, not on the consumer bridge
> > >>>>> (or I'm totallly misreading what Laurent does here).
> > >>>> I have assumed that if devices exposes two hardware sink interfaces it
> > >>>> will expose two separate bridges - of course it will not work with
> > >>>> "bridge chaining" thing, but this is a different story.
> > >>> Daniel is right that the current implementation only allows one
> > >>> consumer. This is however not a limitation of the API, but of its
> > >>> implementation, as I only needed a single consumer. The helpers in this
> > >>> series ensure that neither the consumer nor the producer poke in the
> > >>> drm_bridge structure to call back to the HPD handler:
> > >>>
> > >>> - The consumer calls drm_bridge_hpd_enable() and
> > >>>   drm_bridge_hpd_disable(), which could offer a reference-counted
> > >>>   behaviour if desired without changes to the consumer.
> > >>>
> > >>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
> > >>>   which could also easily accommodate reference-counting in the drm
> > >>>   bridge core without changes to the producer.
> > >>>
> > >>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> > >>>   easily be extended to support multiple consumers without changes to
> > >>>   the producer.
> > >>>
> > >>> This is actually my second version of the HPD mechanism. The first
> > >>> version was never posted, poked into drm_bridge, and required the
> > >>> producer to be aware of the callbacks. After discussing this privately
> > >>> with Daniel, I came up with the implementation in this series that,
> > >>> while not supporting multiple consumers now, makes it easy to extend
> > >>> later without minimal effort.
> > >>>
> > >>> Daniel's proposed implementation above looks reasonable to me, provided
> > >>> we can iterate over the bridges in an order that don't depend on the
> > >>> position of the producer in the chain (should be easy to solve by
> > >>> starting at the encoder for instance). It however looks a bit like a
> > >>> midlayer to me :-) That's why I have a similar implementation in the
> > >>> connector-bridge helper, which could be extended to call
> > >>> encoder->helper_private->bridge_hpd_notify() and
> > >>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> > >>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> > >>> drm_bridge_hpd_notify() would on the other hand set the notification
> > >>> sequence towards the encoder and driver in stone. Daniel, do you think
> > >>> that would be better ?
> > >>>
> > >>> I would like to remind everybody that this series isn't the last I will
> > >>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> > >>> open to suggestions, and can address problems on top of these patches,
> > >>> provided obviously that this series doesn't go in the wrong direction.
> > >>> I'm of course also willing to rework this series, but given the amount
> > >>> of work we have in the drm_bridge realm, I can't fix everything in one
> > >>> go :-)
> > >>>
> > >>>>>>>> - it resembles hardware wires :)
> > >>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> > >>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> > >>>>>>> interested in that hpd singal. This includes:
> > >>>>>>> - Other bridges, e.g. if they provide CEC support.
> > >>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> > >>>>>>> - Overall driver, so it can update the modes/connector status and send the
> > >>>>>>>   uevent to the driver.
> > >>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
> > >>>>>>>   shut down/re-enable the pipe because $reasons.
> > >>>>>>>  
> > >>>>>>> That's at least my understanding from lots of chats with Laurent about
> > >>>>>>> what he wants to do here.
> > >>> That's correct, and that's what I was trying to implement :-) The
> > >>> notification, in this patch series, goes from the producer bridge to a
> > >>> central place (namely the connector, with a helper implementation
> > >>> available as part of this series, but custom implementations in display
> > >>> drivers are fine if needed) that then dispatches the notification to all
> > >>> bridges (through the .lost_hotplug() operation, which we could replace
> > >>> by an .hpd_notify() operation) for the first two purposes listed above,
> > >>> and then to the overall driver. The only thing I don't support yet is
> > >>> dispatching to the display pipeline (item 4 in the list above) as I had
> > >>> no need for that, and didn't want to develop an API with no user. This
> > >>> would however not be difficult to do when needed, the need is taken into
> > >>> account in the proposed implementation.
> > >>>
> > >>>>>> I do not know the full picture, but the solution where particular bridge
> > >>>>>> notifies everything unconditionally seems to me much less flexible.
> > >>>>>>
> > >>>>>> If HPD signals is received by the consumer, if there are no obstacles it
> > >>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
> > >>>>>> will mimic your scenario.
> > >>>>>>
> > >>>>>> But there are also other scenarios where bridge does not want to
> > >>>>>> propagate signal, because for example:
> > >>>>>>
> > >>>>>> - it wants to wait for other sinks to wake up,
> > >>>>>>
> > >>>>> The other sink can just do that in their hpd callback.
> > >>>>>
> > >>>>>> - it propagates HPD signal via hardware wire,
> > >>>>> Again, the other sink can just not listen to sw hpd in that case, and use
> > >>>>> the wire/hw hpd interrupt.
> > >>>>>
> > >>>> If it should ignore HPD, why it should receive it at all - it is
> > >>>> unnecessary noise. And I am afraid with more complicated pipelines it
> > >>>> will be impossible for particular component (bridge/encoder/whatever) to
> > >>>> distinguish if HPD notification which came from non-directly connected
> > >>>> component should be ignored or not.
> > >>>>
> > >>>>>> - first it wants to verify if the sink is valid/compatible/authorized
> > >>>>>> device.
> > >>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> > >>>>> board?
> > >>>> Bridge can have external connectors, and the user can connect there
> > >>>> anything.
> > >>>>
> > >>>>>> In general HPD is input signal for notify of state changes on particular
> > >>>>>> bus, in case of typical video bridge on its output video bus.
> > >>>>>>
> > >>>>>> In case of bridges they have also input video buses, and they can send
> > >>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
> > >>>>>> if for most cases they looks similar.
> > >>>>> Ah, I think this is a problem we will eventually have. But it's not
> > >>>>> something we're currently solving here at all I think.
> > >>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> > >>>> line, so this is not something from far future. And I guess with HPD
> > >>>> broadcasting it could be racy/error prone, for example EDID reading can
> > >>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> > >>>> controller via hw wires also).
> > >>>>
> > >>>>>>>> And regarding implementation:
> > >>>>>>>>
> > >>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> > >>>>>>>>
> > >>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> > >>>>>>>>
> > >>>>>>>> Your proposition is more straightforward, but if we want to notify only
> > >>>>>>>> source we should locate it by parsing notification chain (what about
> > >>>>>>>> unchained bridges), or store pointer somewhere during attachment.
> > >>>>>>>>
> > >>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> > >>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> > >>>>>>> Uh I think we're not talking about the same thing really. My understanding
> > >>>>>>> is that this callback is if someone (outside of this bridge) is interested
> > >>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> > >>>>>>> listener.
> > >>>>>> Do we have real life examples?
> > >>>>>>
> > >>>>>> I want to distinguish two situations:
> > >>>>>>
> > >>>>>> - another device wants to know if input bus of the bridge has changed state,
> > >>>>>>
> > >>>>>> - another device wants to know if output bus of the bridge has changed
> > >>>>>> state.
> > >>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> > >>>>> bridges can exchange state and information about each another. hpd is
> > >>>>> about the physical world, i.e. "is there a cable plugged into the port
> > >>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
> > >>>>> fun stuff like that, we have the atomic_check machinery for this.
> > >>>> My question was if we have real examples that upstream device requires
> > >>>> knowledge about state of output line of the bridge?
> > >>>>
> > >>>> To be more precise, we have following display pipeline:
> > >>>>
> > >>>> A-->B-->C
> > >>>>
> > >>>> And C sends HPD to B (ie signal that state of line between B and C
> > >>>> changed). Does A really wants to know this information? or it should
> > >>>> just need to know if state of line A-->B changed?
> > >>> There's one real life example, where A is an HDMI encoder, B is an HDMI
> > >>> ESD protector and level shifter, and C is the physical HDMI connector.
> > >>> When the HDMI cable is unplugged, the CEC controller part of A needs to
> > >>> be notified in order to reset the CEC state machine. One could however
> > >>> argue that in that case the A-B link state changes too, but the
> > >>> important part is that HPD detection is not performed by A, while A
> > >>> needs to be informed of lost hotplug.
> > >> I have no full picture but I guess in this case C sends HPD to B using
> > >> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
> > >> say that B does not participate in HPD transmission/forwarding,
> > > No, in this case A doesn't receive any hardware HPD signal, it requires
> > > HPD notification through software.
> > >
> > >> some shifters with 'advanced power saving' can even perform wake-up of
> > >> upstream pin logic after receiving HPD on downstream, so HPD sent from B
> > >> to A is indeed different than HPD sent from C to B.
> > >>
> > >> Btw, with the above logic of propagation of HPD callback (proposed by
> > >> Daniel) I guess it will work this way:
> > >>
> > >> - A will receive HPD signal via HW,
> > >>
> > >> - then B and C will receive HPD callback via framework.
> > >>
> > >> Am I right?
> > 
> > > It's the other way around.
> > >
> > > In this case the HPD signal from the connector (C) is routed to an input
> > > of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
> > > connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
> > > IRQ and receive the hardware HPD notification. The driver for the HDMI
> > > encoder (A) needs to receive HPD notification in software, through the
> > > framework.
> > 
> > If this is GPIO I wonder why do not query this gpio by encoder directly,
> > rules of ownership of such gpios seems to be grey area, so in such case
> > I would advise to put it in the driver who really needs it.
> > 
> > This way it will be much simpler.
> 
> First to fall, multiple drivers may need to be informed of HPD events
> coming from a GPIO, so we would need to duplicate it in multiple places,
> and I don't think the GPIO framework allows acquiring a GPIO multiple
> times.
> 
> Then, the GPIO is described in DT, and DT doesn't care about which
> driver needs HPD events. DT specifies the GPIO in the node of the device
> it belongs to, this is defined in DT bindings, and must be the same on
> all boards, while depending on the board different devices may need to
> be informed of HPD events.
> 
> For those two reasons HPD GPIO handling and consumption of HPD events
> can't always be grouped in the same driver.
> 
> > Going back to HPD notifications, as I said earlier broadcasting HPD
> > notification unconditionally to every member of the chain with hope that
> > the member will be able to filter-out undesired notification seems to me
> > incorrect - maybe it can solve some problems but is not flexible enough
> > to be usable in other scenarios.
> > 
> > If my arguments do not convince you please just continue with your
> > ideas, we can always add NO_HPD_BROADCAST somewhere :)
> 
> :-) I would like to understand the problems you're referring to though,
> and hopefully solve them. If you could describe one of the scenarios
> where you think this mechanism wouldn't be usable that would help. In
> the meantime I will post a new version of the series with these
> operations kept as-is to get the rest of the patches reviewed.

See my little thing about midlayers, I think midlayers with lots of flags
for everything aren't a good idea. They should be more opinionated about
how things work.

So if there's a case where this broadcasting of various things doesn't
work, let's dig into it.
-Daniel

> 
> > >>>>>>> You seem to have some other idea here.
> > >>>>>>>
> > >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>>>>>> +}
> > >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>>  #ifdef CONFIG_OF
> > >>>>>>>>>>>>>  /**
> > >>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > >>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > >>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> > >>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
> > >>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> > >>>>>>>>>>>>> @@ -23,8 +23,9 @@
> > >>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> > >>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>> -#include <linux/list.h>
> > >>>>>>>>>>>>>  #include <linux/ctype.h>
> > >>>>>>>>>>>>> +#include <linux/list.h>
> > >>>>>>>>>>>>> +#include <linux/mutex.h>
> > >>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
> > >>>>>>>>>>>>>  #include <drm/drm_modes.h>
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >>>>>>>>>>>>>  	 */
> > >>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >>>>>>>>>>>>>  				    struct drm_atomic_state *state);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @detect:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> > >>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
> > >>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> > >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * RETURNS:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @get_modes:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> > >>>>>>>>>>>>> +	 * with drm_mode_probed_add().
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> > >>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> > >>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> > >>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * RETURNS:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> > >>>>>>>>>>>>> +			 struct drm_connector *connector);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @get_edid:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> > >>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> > >>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> > >>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> > >>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> > >>>>>>>>>>>>> +	 * output.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * RETURNS:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > >>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> > >>>>>>>>>>>>> +	 * the returned edid structure with kfree().
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > >>>>>>>>>>>>> +				 struct drm_connector *connector);
> > >>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> > >>>>>>>>>>>> presence of another one?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> > >>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> > >>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > >>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> > >>>>>>>>>>> and connector->edid correctly.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> > >>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
> > >>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > >>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> > >>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> > >>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> > >>>>>>>>>>> correctly updated.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> > >>>>>>>>>>> edid, which is not so awesome :-)
> > >>>>>>>>>>>
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @lost_hotplug:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> > >>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> > >>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> > >>>>>>>>>>>>> +	 * HDMI bridges.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @hpd_enable:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> > >>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > >>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> > >>>>>>>>>>>>> +	 * @hpd_disable.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> > >>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @hpd_disable:
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> > >>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > >>>>>>>>>>>>> +	 * connection status occurs.
> > >>>>>>>>>>>>> +	 *
> > >>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> > >>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >>>>>>>>>>>>>  };
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>>  /**
> > >>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >>>>>>>>>>>>>  	bool dual_link;
> > >>>>>>>>>>>>>  };
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>> +/**
> > >>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > >>>>>>>>>>>>> + */
> > >>>>>>>>>>>>> +enum drm_bridge_ops {
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > >>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> > >>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > >>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> > >>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > >>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> > >>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> > >>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > >>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> > >>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > >>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> > >>>>>>>>>>>>> +};
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>>  /**
> > >>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> > >>>>>>>>>>>>>   */
> > >>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> > >>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> > >>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> > >>>>>>>>>>>>>  	void *driver_private;
> > >>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> > >>>>>>>>>>>>> +	enum drm_bridge_ops ops;
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> > >>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > >>>>>>>>>>>>> +	 * identifies the type of connected display.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	int type;
> > >>>>>>>>>>>>> +	/** private: */
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	struct mutex hpd_mutex;
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> > >>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > >>>>>>>>>>>>> +	/**
> > >>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > >>>>>>>>>>>>> +	 * @hpd_cb.
> > >>>>>>>>>>>>> +	 */
> > >>>>>>>>>>>>> +	void *hpd_data;
> > >>>>>>>>>>>>>  };
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> > >>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>>>  			      struct drm_atomic_state *state);
> > >>>>>>>>>>>>>  
> > >>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>>>>>> +			   void *data);
> > >>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > >>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>>>>>> +			   enum drm_connector_status status);
> > >>>>>>>>>>>>> +
> > >>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >>>>>>>>>>>>>  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Daniel Vetter Aug. 14, 2019, 12:43 p.m. UTC | #19

On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> Hello Daniel and Andrzej,
> 
> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > > Hi Laurent,
> > > 
> > > I like the approach, current practice when almost every bridge should
> > > optionally implement connector, or alternatively downstream bridge or
> > > panel is very painful.
> > 
> > Yeah I think this looks mostly reasonable. Some api design comments on top
> > of Andrzej', with the fair warning that I didn't bother to read up on how
> > it's all used in the end. I probably should go and do that, at least to
> > get a feeling for what your hpd_cb usually does.
> > 
> > > More comments inlined.
> > > 
> > > On 07.07.2019 20:18, Laurent Pinchart wrote:
> > > > To support implementation of DRM connectors on top of DRM bridges
> > > > instead of by bridges, the drm_bridge needs to expose new operations and
> > > > data:
> > > >
> > > > - Output detection, hot-plug notification, mode retrieval and EDID
> > > >   retrieval operations
> > > > - Bitmask of supported operations
> > > 
> > > 
> > > Why do we need these bitmask at all? Why cannot we rely on presence of
> > > operation's callback?
> > 
> > Yeah also not a huge fan of these bitmasks. Smells like
> > DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > add, generally good excuse to not have to think through the design between
> > different parts of drivers - "just" add another flag.
> 
> The reason is that a bridge may support an operation (as in implemented
> in the bridge hardware), but that operation may not be supported on a
> particular board. For instance an HDMI encoder may support reading EDID
> when the DDC lines are connected to the encoder, but a board may connect
> the DDC lines to an I2C port of the SoC. We thus need to decouple
> if a particular instance of the device supports the operation (exposed
> by the ops flags) from the function pointers.
> 
> We could of course allocate the drm_bridge_funcs structure dynamically
> for each bridge instance, and fill it with function pointers manually,
> leaving the unused ops always NULL, but that would require making the
> structure writable, which is considered a security issue. That's why I
> decided to keep the drm_bridge_funcs structure as a global static const
> structure, and add an ops bitmask.

Yeah reallocating func structures is not great, I agree ...

Would an -ENXIO at runtime work too? Or do we need to know this
statically. It just feels so silly and redundant to have the flag and the
hook.

> > > > - Bridge output type
> > > >
> > > > Add and document these.
> > > >
> > > > Three new bridge helper functions are also added to handle hot plug
> > > > notification in a way that is as transparent as possible for the
> > > > bridges.
> > > 
> > > Documentation of new opses does not explain how it should cooperate with
> > > bridge chaining, I suppose they should be chained explicitly, am I
> > > right? More comments about it later.
> 
> No, the whole point is that they should not be chained at all. A bridge
> does not have to propagate, for instance, .get_edid() to the next
> bridge. That's one of the core design principles in this series, I want
> to keep the bridges as simple as possible, and move the complexity of
> the boilerplate code that is currently copied all around to helpers. See
> patch "drm: Add helper to create a connector for a chain of bridges" for
> more information about how this is used, with a helper that delegates
> the connector operations to the correct bridge in the chain based on the
> ops reported by each bridge.

Sounds like we have a general discussion of who should be owning the
topology around bridges. I guess there's arguments for both positions ...

Not sure what to do, aside from that I'm not a huge fan of flags
everywhere. But if that's the best we can do, so be it :-/
-Daniel

> 
> > > > Signed-off-by: Laurent Pinchart <[e-mail]>
> > > > ---
> > > >  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > > >  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > > >  2 files changed, 261 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > > > index 519577f363e3..3c2a255df7af 100644
> > > > --- a/drivers/gpu/drm/drm_bridge.c
> > > > +++ b/drivers/gpu/drm/drm_bridge.c
> > > > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > > >   */
> > > >  void drm_bridge_add(struct drm_bridge *bridge)
> > > >  {
> > > > +	mutex_init(&bridge->hpd_mutex);
> > > > +
> > > >  	mutex_lock(&bridge_lock);
> > > >  	list_add_tail(&bridge->list, &bridge_list);
> > > >  	mutex_unlock(&bridge_lock);
> > > > @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > > >  	mutex_lock(&bridge_lock);
> > > >  	list_del_init(&bridge->list);
> > > >  	mutex_unlock(&bridge_lock);
> > > > +
> > > > +	mutex_destroy(&bridge->hpd_mutex);
> > > >  }
> > > >  EXPORT_SYMBOL(drm_bridge_remove);
> > > >  
> > > > @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > > >  }
> > > >  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > > >  
> > > > +/**
> > > > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > > > + * @bridge: bridge control structure
> > > > + * @cb: hot-plug detection callback
> > > > + * @data: data to be passed to the hot-plug detection callback
> > > > + *
> > > > + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > > > + * hot plug notification callback. From now on the @cb will be called with
> > > > + * @data when an output status change is detected by the bridge, until hot plug
> > > > + * notification gets disabled with drm_bridge_hpd_disable().
> > > > + *
> > > > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > > > + * bridge->ops. This function shall not be called when the flag is not set.
> > > > + *
> > > > + * Only one hot plug detection callback can be registered at a time, it is an
> > > > + * error to call this function when hot plug detection is already enabled for
> > > > + * the bridge.
> > > > + */
> > > 
> > > To simplify architecture maybe would be better to enable hpd just on
> > > bridge attach:
> > > 
> > > bridge->hpd_cb = cb;
> > > 
> > > bridge->hpd_data = data;
> > > 
> > > ret = drm_bridge_attach(...);
> > 
> > Yeah I like this more. The other problem here is, what if you need more
> > than 1 callback registers on the same bridge hdp signal?
> 
> That's why I decided to hide hide HPD through helpers,
> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> current implementation is limited to a single listener, only the helpers
> would need to be changed to extend that to multiple listeners.
> 
> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> bridge to disable HPD detection when not used. Doing so keeps the bridge
> simple, it only needs to care about reporting HPD events when they're
> enabled, without caring who (if anyone) is listening, and gets clear
> instructions on whether to enable or disable the HPD hardware (in case
> it can be disabled).
> 
> > > This way we could avoid adding new callbacks hpd_(enable|disable)
> > > without big sacrifices.
> > > 
> > > One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > > notifies about sink status change, how it translates to this cb?
> 
> This is something this series doesn't implement. I don't think it would
> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> here. If you can elaborate on what would be needed, I can implement
> that.
> 
> > > > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > > > +			   void (*cb)(void *data,
> > > > +				      enum drm_connector_status status),
> > > > +			   void *data)
> > > > +{
> > > > +	if (!bridge || !bridge->funcs->hpd_enable)
> > > > +		return;
> > > > +
> > > > +	mutex_lock(&bridge->hpd_mutex);
> > > > +
> > > > +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > > > +		goto unlock;
> > > > +
> > > > +	bridge->hpd_cb = cb;
> > > > +	bridge->hpd_data = data;
> > > > +
> > > > +	bridge->funcs->hpd_enable(bridge);
> > > > +
> > > > +unlock:
> > > > +	mutex_unlock(&bridge->hpd_mutex);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > > > +
> > > > +/**
> > > > + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > > > + * @bridge: bridge control structure
> > > > + *
> > > > + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > > > + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > > > + * function returns the callback will not be called by the bridge when an
> > > > + * output status change occurs.
> > > > + *
> > > > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > > > + * bridge->ops. This function shall not be called when the flag is not set.
> > > > + */
> > > > +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > > > +{
> > > > +	if (!bridge || !bridge->funcs->hpd_disable)
> > > > +		return;
> > > > +
> > > > +	mutex_lock(&bridge->hpd_mutex);
> > > > +	bridge->funcs->hpd_disable(bridge);
> > > > +
> > > > +	bridge->hpd_cb = NULL;
> > > > +	bridge->hpd_data = NULL;
> > > > +	mutex_unlock(&bridge->hpd_mutex);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > > > +
> > > > +/**
> > > > + * drm_bridge_hpd_notify - notify hot plug detection events
> > > > + * @bridge: bridge control structure
> > > > + * @status: output connection status
> > > > + *
> > > > + * Bridge drivers shall call this function to report hot plug events when they
> > > > + * detect a change in the output status, when hot plug detection has been
> > > > + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > > > + *
> > > > + * This function shall be called in a context that can sleep.
> > > > + */
> > > > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > > > +			   enum drm_connector_status status)
> > > > +{
> > > > +	mutex_lock(&bridge->hpd_mutex);
> > > > +	if (bridge->hpd_cb)
> > > > +		bridge->hpd_cb(bridge->hpd_data, status);
> > 
> > So this isn't quite what I had in mind. Instead something like this:
> > 
> > 	/* iterates over all bridges in the chain containing @bridge */
> > 	for_each_bridge(tmp_bridge, bridge) {
> > 		if (tmp_bridge == bridge)
> > 			continue;
> > 		if (bridge->hpd_notify);
> > 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > 	}
> > 
> > 	encoder = encoder_for_bridge(bridge);
> > 	if (encoder->helper_private->bridge_hpd_notify)
> > 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > 
> > 	dev = bridge->dev
> > 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > 
> > No register callback needed, no locking needed, everyone gets exactly the
> > hpd they want/need.
> 
> I'll reply to this further down the mail thread, to address additional
> comments.
> 
> > > > +	mutex_unlock(&bridge->hpd_mutex);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > > > +
> > > >  #ifdef CONFIG_OF
> > > >  /**
> > > >   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > > > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > > > index 08dc15f93ded..b9445aa5b1ef 100644
> > > > --- a/include/drm/drm_bridge.h
> > > > +++ b/include/drm/drm_bridge.h
> > > > @@ -23,8 +23,9 @@
> > > >  #ifndef __DRM_BRIDGE_H__
> > > >  #define __DRM_BRIDGE_H__
> > > >  
> > > > -#include <linux/list.h>
> > > >  #include <linux/ctype.h>
> > > > +#include <linux/list.h>
> > > > +#include <linux/mutex.h>
> > > >  #include <drm/drm_mode_object.h>
> > > >  #include <drm/drm_modes.h>
> > > >  
> > > > @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > > >  	 */
> > > >  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > > >  				    struct drm_atomic_state *state);
> > > > +
> > > > +	/**
> > > > +	 * @detect:
> > > > +	 *
> > > > +	 * Check if anything is attached to the bridge output.
> > > > +	 *
> > > > +	 * This callback is optional, if not implemented the bridge will be
> > > > +	 * considered as always having a component attached to its output.
> > > > +	 * Bridges that implement this callback shall set the
> > > > +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > > > +	 *
> > > > +	 * RETURNS:
> > > > +	 *
> > > > +	 * drm_connector_status indicating the bridge output status.
> > > > +	 */
> > > > +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > > > +
> > > > +	/**
> > > > +	 * @get_modes:
> > > > +	 *
> > > > +	 * Fill all modes currently valid for the sink into the &drm_connector
> > > > +	 * with drm_mode_probed_add().
> > > > +	 *
> > > > +	 * The @get_modes callback is mostly intended to support non-probable
> > > > +	 * displays such as many fixed panels. Bridges that support reading
> > > > +	 * EDID shall leave @get_modes unimplemented and implement the
> > > > +	 * &drm_bridge_funcs->get_edid callback instead.
> > > > +	 *
> > > > +	 * This callback is optional. Bridges that implement it shall set the
> > > > +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > > > +	 *
> > > > +	 * RETURNS:
> > > > +	 *
> > > > +	 * The number of modes added by calling drm_mode_probed_add().
> > > > +	 */
> > > > +	int (*get_modes)(struct drm_bridge *bridge,
> > > > +			 struct drm_connector *connector);
> > > > +
> > > > +	/**
> > > > +	 * @get_edid:
> > > > +	 *
> > > > +	 * Read and parse the EDID data of the connected display.
> > > > +	 *
> > > > +	 * The @get_edid callback is the preferred way of reporting mode
> > > > +	 * information for a display connected to the bridge output. Bridges
> > > > +	 * that support readind EDID shall implement this callback and leave
> > > > +	 * the @get_modes callback unimplemented.
> > > > +	 *
> > > > +	 * The caller of this operation shall first verify the output
> > > > +	 * connection status and refrain from reading EDID from a disconnected
> > > > +	 * output.
> > > > +	 *
> > > > +	 * This callback is optional. Bridges that implement it shall set the
> > > > +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > > > +	 *
> > > > +	 * RETURNS:
> > > > +	 *
> > > > +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > > > +	 * success, or NULL otherwise. The caller is responsible for freeing
> > > > +	 * the returned edid structure with kfree().
> > > > +	 */
> > > > +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > > > +				 struct drm_connector *connector);
> > > 
> > > It overlaps with get_modes, I guess presence of one ops should disallow
> > > presence of another one?
> > > 
> > > I am not really convinced we need this op at all, cannot we just assign
> > > some helper function to .get_modes cb, which will do the same?
> > 
> > Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > case, and require that if it has an edid it must fill out connector->info
> > and connector->edid correctly.
> 
> I think that's doable, I'll have a look.
> 
> > Btw if a hpd happens, who's responible for making sure the edid/mode list
> > in the connector is up-to-date? With your current callback design that's
> > up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > should guarantee that it'll first walk the connectors to update status and
> > edid/mode list for the final drm_connector. And then instead of just
> > passing the simple "status", it'll pass the connector, with everything
> > correctly updated.
> > 
> > Otherwise everyone interested in that hpd signal will go and re-fetch the
> > edid, which is not so awesome :-)
> 
> With the current design there's a single listener, so it's not a big
> deal :-) Furthermore, the listener is the helper that creates a
> connector on top of a chain of bridges, so it's a pretty good place to
> handle this. See the call to drm_kms_helper_hotplug_event() in
> drm_bridge_connector_hpd_cb().
> 
> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> big of a requirement as a prerequisite for this series (or as part of
> this series). We have hardware that can report HPD with various level of
> details (from "something happened on a connector" to "this particular
> event happened on this particular connector"), and we channel that
> through helpers such as drm_kms_helper_hotplug_event() that lose the
> details and go through a heavy mechanism to refetch everything. I
> understand this is needed in many cases, but I think there's room for
> improvement. This series, in my opinion, doesn't go in the wrong
> direction in that regard, as it eventually calls
> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> on top of it. I'm even willing to work on this, provided I get feedback
> on what is desired.
> 
> > > > +	/**
> > > > +	 * @lost_hotplug:
> > > > +	 *
> > > > +	 * Notify the bridge of display disconnection.
> > > > +	 *
> > > > +	 * This callback is optional, it may be implemented by bridges that
> > > > +	 * need to be notified of display disconnection for internal reasons.
> > > > +	 * One use case is to reset the internal state of CEC controllers for
> > > > +	 * HDMI bridges.
> > > > +	 */
> > > > +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > > > +
> > > > +	/**
> > > > +	 * @hpd_enable:
> > > > +	 *
> > > > +	 * Enable hot plug detection. From now on the bridge shall call
> > > > +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > > > +	 * connection status, until hot plug detection gets disabled with
> > > > +	 * @hpd_disable.
> > > > +	 *
> > > > +	 * This callback is optional and shall only be implemented by bridges
> > > > +	 * that support hot-plug notification without polling. Bridges that
> > > > +	 * implement it shall also implement the @hpd_disable callback and set
> > > > +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > > > +	 */
> > > > +	void (*hpd_enable)(struct drm_bridge *bridge);
> > > > +
> > > > +	/**
> > > > +	 * @hpd_disable:
> > > > +	 *
> > > > +	 * Disable hot plug detection. Once this function returns the bridge
> > > > +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > > > +	 * connection status occurs.
> > > > +	 *
> > > > +	 * This callback is optional and shall only be implemented by bridges
> > > > +	 * that support hot-plug notification without polling. Bridges that
> > > > +	 * implement it shall also implement the @hpd_enable callback and set
> > > > +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > > > +	 */
> > > > +	void (*hpd_disable)(struct drm_bridge *bridge);
> > > >  };
> > > >  
> > > >  /**
> > > > @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > > >  	bool dual_link;
> > > >  };
> > > >  
> > > > +/**
> > > > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > > > + */
> > > > +enum drm_bridge_ops {
> > > > +	/**
> > > > +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > > > +	 * its output. Bridges that set this flag shall implement the
> > > > +	 * &drm_bridge_funcs->detect callback.
> > > > +	 */
> > > > +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > > > +	/**
> > > > +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > > > +	 * connected to its output. Bridges that set this flag shall implement
> > > > +	 * the &drm_bridge_funcs->get_edid callback.
> > > > +	 */
> > > > +	DRM_BRIDGE_OP_EDID = BIT(1),
> > > > +	/**
> > > > +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > > > +	 * without requiring polling. Bridges that set this flag shall
> > > > +	 * implement the &drm_bridge_funcs->hpd_enable and
> > > > +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > > > +	 */
> > > > +	DRM_BRIDGE_OP_HPD = BIT(2),
> > > > +	/**
> > > > +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > > > +	 * by the display at its output. This does not include readind EDID
> > > > +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > > > +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > > > +	 */
> > > > +	DRM_BRIDGE_OP_MODES = BIT(3),
> > > > +};
> > > > +
> > > >  /**
> > > >   * struct drm_bridge - central DRM bridge control structure
> > > >   */
> > > > @@ -398,6 +535,29 @@ struct drm_bridge {
> > > >  	const struct drm_bridge_funcs *funcs;
> > > >  	/** @driver_private: pointer to the bridge driver's internal context */
> > > >  	void *driver_private;
> > > > +	/** @ops: bitmask of operations supported by the bridge */
> > > > +	enum drm_bridge_ops ops;
> > > > +	/**
> > > > +	 * @type: Type of the connection at the bridge output
> > > > +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > > > +	 * identifies the type of connected display.
> > > > +	 */
> > > > +	int type;
> > > > +	/** private: */
> > > > +	/**
> > > > +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > > > +	 */
> > > > +	struct mutex hpd_mutex;
> > > > +	/**
> > > > +	 * @hpd_cb: Hot plug detection callback, registered with
> > > > +	 * drm_bridge_hpd_enable().
> > > > +	 */
> > > > +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > > > +	/**
> > > > +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > > > +	 * @hpd_cb.
> > > > +	 */
> > > > +	void *hpd_data;
> > > >  };
> > > >  
> > > >  void drm_bridge_add(struct drm_bridge *bridge);
> > > > @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > > >  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > > >  			      struct drm_atomic_state *state);
> > > >  
> > > > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > > > +			   void (*cb)(void *data,
> > > > +				      enum drm_connector_status status),
> > > > +			   void *data);
> > > > +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > > > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > > > +			   enum drm_connector_status status);
> > > > +
> > > >  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > > >  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > > >  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Laurent Pinchart Aug. 14, 2019, 12:56 p.m. UTC | #20

Hi Daniel,

On Wed, Aug 14, 2019 at 02:43:21PM +0200, Daniel Vetter wrote:
> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> >> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>> Hi Laurent,
> >>> 
> >>> I like the approach, current practice when almost every bridge should
> >>> optionally implement connector, or alternatively downstream bridge or
> >>> panel is very painful.
> >> 
> >> Yeah I think this looks mostly reasonable. Some api design comments on top
> >> of Andrzej', with the fair warning that I didn't bother to read up on how
> >> it's all used in the end. I probably should go and do that, at least to
> >> get a feeling for what your hpd_cb usually does.
> >> 
> >>> More comments inlined.
> >>> 
> >>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>> To support implementation of DRM connectors on top of DRM bridges
> >>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>> data:
> >>>>
> >>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>   retrieval operations
> >>>> - Bitmask of supported operations
> >>> 
> >>> 
> >>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>> operation's callback?
> >> 
> >> Yeah also not a huge fan of these bitmasks. Smells like
> >> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >> add, generally good excuse to not have to think through the design between
> >> different parts of drivers - "just" add another flag.
> > 
> > The reason is that a bridge may support an operation (as in implemented
> > in the bridge hardware), but that operation may not be supported on a
> > particular board. For instance an HDMI encoder may support reading EDID
> > when the DDC lines are connected to the encoder, but a board may connect
> > the DDC lines to an I2C port of the SoC. We thus need to decouple
> > if a particular instance of the device supports the operation (exposed
> > by the ops flags) from the function pointers.
> > 
> > We could of course allocate the drm_bridge_funcs structure dynamically
> > for each bridge instance, and fill it with function pointers manually,
> > leaving the unused ops always NULL, but that would require making the
> > structure writable, which is considered a security issue. That's why I
> > decided to keep the drm_bridge_funcs structure as a global static const
> > structure, and add an ops bitmask.
> 
> Yeah reallocating func structures is not great, I agree ...
> 
> Would an -ENXIO at runtime work too? Or do we need to know this
> statically. It just feels so silly and redundant to have the flag and the
> hook.

That would mean that the operation would need to be called in order to
determine if the bridge offers that particular capability. For some
operations we want to know ahead of time, for instance to determine at
connector creation time if HPD needs to be polled. At that time we don't
necessarily have the required arguments to call the information, and
even if we do, the operation could have side effects that are not
desired.

> >>>> - Bridge output type
> >>>>
> >>>> Add and document these.
> >>>>
> >>>> Three new bridge helper functions are also added to handle hot plug
> >>>> notification in a way that is as transparent as possible for the
> >>>> bridges.
> >>> 
> >>> Documentation of new opses does not explain how it should cooperate with
> >>> bridge chaining, I suppose they should be chained explicitly, am I
> >>> right? More comments about it later.
> > 
> > No, the whole point is that they should not be chained at all. A bridge
> > does not have to propagate, for instance, .get_edid() to the next
> > bridge. That's one of the core design principles in this series, I want
> > to keep the bridges as simple as possible, and move the complexity of
> > the boilerplate code that is currently copied all around to helpers. See
> > patch "drm: Add helper to create a connector for a chain of bridges" for
> > more information about how this is used, with a helper that delegates
> > the connector operations to the correct bridge in the chain based on the
> > ops reported by each bridge.
> 
> Sounds like we have a general discussion of who should be owning the
> topology around bridges. I guess there's arguments for both positions ...
> 
> Not sure what to do, aside from that I'm not a huge fan of flags
> everywhere. But if that's the best we can do, so be it :-/

I understand your concern, and I wasn't very happy to have to introduce
a bitmask in addition to function pointers, but it was the best
middleground I could find. I'll keep your comments in mind in case I can
find a better solution, but so far I believe this is the best option to
keep bridge code simple and to make the API well-defined.

> >>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>> ---
> >>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>> index 519577f363e3..3c2a255df7af 100644
> >>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>   */
> >>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>  {
> >>>> +	mutex_init(&bridge->hpd_mutex);
> >>>> +
> >>>>  	mutex_lock(&bridge_lock);
> >>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>  	mutex_unlock(&bridge_lock);
> >>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>  	mutex_lock(&bridge_lock);
> >>>>  	list_del_init(&bridge->list);
> >>>>  	mutex_unlock(&bridge_lock);
> >>>> +
> >>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>  }
> >>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>  
> >>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>  }
> >>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>  
> >>>> +/**
> >>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>> + * @bridge: bridge control structure
> >>>> + * @cb: hot-plug detection callback
> >>>> + * @data: data to be passed to the hot-plug detection callback
> >>>> + *
> >>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>> + *
> >>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>> + *
> >>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>> + * error to call this function when hot plug detection is already enabled for
> >>>> + * the bridge.
> >>>> + */
> >>> 
> >>> To simplify architecture maybe would be better to enable hpd just on
> >>> bridge attach:
> >>> 
> >>> bridge->hpd_cb = cb;
> >>> 
> >>> bridge->hpd_data = data;
> >>> 
> >>> ret = drm_bridge_attach(...);
> >> 
> >> Yeah I like this more. The other problem here is, what if you need more
> >> than 1 callback registers on the same bridge hdp signal?
> > 
> > That's why I decided to hide hide HPD through helpers,
> > drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> > side, and drm_bridge_hpd_notify() on the event reporter side. While the
> > current implementation is limited to a single listener, only the helpers
> > would need to be changed to extend that to multiple listeners.
> > 
> > Note that the .hpd_enable() and .hpd_disable() operations also allow the
> > bridge to disable HPD detection when not used. Doing so keeps the bridge
> > simple, it only needs to care about reporting HPD events when they're
> > enabled, without caring who (if anyone) is listening, and gets clear
> > instructions on whether to enable or disable the HPD hardware (in case
> > it can be disabled).
> > 
> >>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>> without big sacrifices.
> >>> 
> >>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>> notifies about sink status change, how it translates to this cb?
> > 
> > This is something this series doesn't implement. I don't think it would
> > be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> > here. If you can elaborate on what would be needed, I can implement
> > that.
> > 
> >>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>> +			   void (*cb)(void *data,
> >>>> +				      enum drm_connector_status status),
> >>>> +			   void *data)
> >>>> +{
> >>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>> +		return;
> >>>> +
> >>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>> +
> >>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>> +		goto unlock;
> >>>> +
> >>>> +	bridge->hpd_cb = cb;
> >>>> +	bridge->hpd_data = data;
> >>>> +
> >>>> +	bridge->funcs->hpd_enable(bridge);
> >>>> +
> >>>> +unlock:
> >>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>> +
> >>>> +/**
> >>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>> + * @bridge: bridge control structure
> >>>> + *
> >>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>> + * function returns the callback will not be called by the bridge when an
> >>>> + * output status change occurs.
> >>>> + *
> >>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>> + */
> >>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>> +{
> >>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>> +		return;
> >>>> +
> >>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>> +	bridge->funcs->hpd_disable(bridge);
> >>>> +
> >>>> +	bridge->hpd_cb = NULL;
> >>>> +	bridge->hpd_data = NULL;
> >>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>> +
> >>>> +/**
> >>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>> + * @bridge: bridge control structure
> >>>> + * @status: output connection status
> >>>> + *
> >>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>> + * detect a change in the output status, when hot plug detection has been
> >>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>> + *
> >>>> + * This function shall be called in a context that can sleep.
> >>>> + */
> >>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>> +			   enum drm_connector_status status)
> >>>> +{
> >>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>> +	if (bridge->hpd_cb)
> >>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >> 
> >> So this isn't quite what I had in mind. Instead something like this:
> >> 
> >> 	/* iterates over all bridges in the chain containing @bridge */
> >> 	for_each_bridge(tmp_bridge, bridge) {
> >> 		if (tmp_bridge == bridge)
> >> 			continue;
> >> 		if (bridge->hpd_notify);
> >> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >> 	}
> >> 
> >> 	encoder = encoder_for_bridge(bridge);
> >> 	if (encoder->helper_private->bridge_hpd_notify)
> >> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >> 
> >> 	dev = bridge->dev
> >> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >> 
> >> No register callback needed, no locking needed, everyone gets exactly the
> >> hpd they want/need.
> > 
> > I'll reply to this further down the mail thread, to address additional
> > comments.
> > 
> >>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>> +}
> >>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>> +
> >>>>  #ifdef CONFIG_OF
> >>>>  /**
> >>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>> --- a/include/drm/drm_bridge.h
> >>>> +++ b/include/drm/drm_bridge.h
> >>>> @@ -23,8 +23,9 @@
> >>>>  #ifndef __DRM_BRIDGE_H__
> >>>>  #define __DRM_BRIDGE_H__
> >>>>  
> >>>> -#include <linux/list.h>
> >>>>  #include <linux/ctype.h>
> >>>> +#include <linux/list.h>
> >>>> +#include <linux/mutex.h>
> >>>>  #include <drm/drm_mode_object.h>
> >>>>  #include <drm/drm_modes.h>
> >>>>  
> >>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>  	 */
> >>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>  				    struct drm_atomic_state *state);
> >>>> +
> >>>> +	/**
> >>>> +	 * @detect:
> >>>> +	 *
> >>>> +	 * Check if anything is attached to the bridge output.
> >>>> +	 *
> >>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>> +	 * considered as always having a component attached to its output.
> >>>> +	 * Bridges that implement this callback shall set the
> >>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>> +	 *
> >>>> +	 * RETURNS:
> >>>> +	 *
> >>>> +	 * drm_connector_status indicating the bridge output status.
> >>>> +	 */
> >>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>> +
> >>>> +	/**
> >>>> +	 * @get_modes:
> >>>> +	 *
> >>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>> +	 * with drm_mode_probed_add().
> >>>> +	 *
> >>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>> +	 *
> >>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>> +	 *
> >>>> +	 * RETURNS:
> >>>> +	 *
> >>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>> +	 */
> >>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>> +			 struct drm_connector *connector);
> >>>> +
> >>>> +	/**
> >>>> +	 * @get_edid:
> >>>> +	 *
> >>>> +	 * Read and parse the EDID data of the connected display.
> >>>> +	 *
> >>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>> +	 * information for a display connected to the bridge output. Bridges
> >>>> +	 * that support readind EDID shall implement this callback and leave
> >>>> +	 * the @get_modes callback unimplemented.
> >>>> +	 *
> >>>> +	 * The caller of this operation shall first verify the output
> >>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>> +	 * output.
> >>>> +	 *
> >>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>> +	 *
> >>>> +	 * RETURNS:
> >>>> +	 *
> >>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>> +	 * the returned edid structure with kfree().
> >>>> +	 */
> >>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>> +				 struct drm_connector *connector);
> >>> 
> >>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>> presence of another one?
> >>> 
> >>> I am not really convinced we need this op at all, cannot we just assign
> >>> some helper function to .get_modes cb, which will do the same?
> >> 
> >> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >> case, and require that if it has an edid it must fill out connector->info
> >> and connector->edid correctly.
> > 
> > I think that's doable, I'll have a look.
> > 
> >> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >> in the connector is up-to-date? With your current callback design that's
> >> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >> should guarantee that it'll first walk the connectors to update status and
> >> edid/mode list for the final drm_connector. And then instead of just
> >> passing the simple "status", it'll pass the connector, with everything
> >> correctly updated.
> >> 
> >> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >> edid, which is not so awesome :-)
> > 
> > With the current design there's a single listener, so it's not a big
> > deal :-) Furthermore, the listener is the helper that creates a
> > connector on top of a chain of bridges, so it's a pretty good place to
> > handle this. See the call to drm_kms_helper_hotplug_event() in
> > drm_bridge_connector_hpd_cb().
> > 
> > I'm all for reworking HPD and mode fetching, but I think it's a bit too
> > big of a requirement as a prerequisite for this series (or as part of
> > this series). We have hardware that can report HPD with various level of
> > details (from "something happened on a connector" to "this particular
> > event happened on this particular connector"), and we channel that
> > through helpers such as drm_kms_helper_hotplug_event() that lose the
> > details and go through a heavy mechanism to refetch everything. I
> > understand this is needed in many cases, but I think there's room for
> > improvement. This series, in my opinion, doesn't go in the wrong
> > direction in that regard, as it eventually calls
> > drm_kms_helper_hotplug_event(), so I think improvements would make sense
> > on top of it. I'm even willing to work on this, provided I get feedback
> > on what is desired.
> > 
> >>>> +	/**
> >>>> +	 * @lost_hotplug:
> >>>> +	 *
> >>>> +	 * Notify the bridge of display disconnection.
> >>>> +	 *
> >>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>> +	 * HDMI bridges.
> >>>> +	 */
> >>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>> +
> >>>> +	/**
> >>>> +	 * @hpd_enable:
> >>>> +	 *
> >>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>> +	 * connection status, until hot plug detection gets disabled with
> >>>> +	 * @hpd_disable.
> >>>> +	 *
> >>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>> +	 */
> >>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>> +
> >>>> +	/**
> >>>> +	 * @hpd_disable:
> >>>> +	 *
> >>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>> +	 * connection status occurs.
> >>>> +	 *
> >>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>> +	 */
> >>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>  };
> >>>>  
> >>>>  /**
> >>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>  	bool dual_link;
> >>>>  };
> >>>>  
> >>>> +/**
> >>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>> + */
> >>>> +enum drm_bridge_ops {
> >>>> +	/**
> >>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>> +	 * its output. Bridges that set this flag shall implement the
> >>>> +	 * &drm_bridge_funcs->detect callback.
> >>>> +	 */
> >>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>> +	/**
> >>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>> +	 */
> >>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>> +	/**
> >>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>> +	 */
> >>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>> +	/**
> >>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>> +	 * by the display at its output. This does not include readind EDID
> >>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>> +	 */
> >>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>> +};
> >>>> +
> >>>>  /**
> >>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>   */
> >>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>  	const struct drm_bridge_funcs *funcs;
> >>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>  	void *driver_private;
> >>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>> +	enum drm_bridge_ops ops;
> >>>> +	/**
> >>>> +	 * @type: Type of the connection at the bridge output
> >>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>> +	 * identifies the type of connected display.
> >>>> +	 */
> >>>> +	int type;
> >>>> +	/** private: */
> >>>> +	/**
> >>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>> +	 */
> >>>> +	struct mutex hpd_mutex;
> >>>> +	/**
> >>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>> +	 * drm_bridge_hpd_enable().
> >>>> +	 */
> >>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>> +	/**
> >>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>> +	 * @hpd_cb.
> >>>> +	 */
> >>>> +	void *hpd_data;
> >>>>  };
> >>>>  
> >>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>  			      struct drm_atomic_state *state);
> >>>>  
> >>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>> +			   void (*cb)(void *data,
> >>>> +				      enum drm_connector_status status),
> >>>> +			   void *data);
> >>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>> +			   enum drm_connector_status status);
> >>>> +
> >>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>  					u32 connector_type);

Daniel Vetter Aug. 14, 2019, 1:03 p.m. UTC | #21

On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > >> Hi Laurent,
> > >> 
> > >> I like the approach, current practice when almost every bridge should
> > >> optionally implement connector, or alternatively downstream bridge or
> > >> panel is very painful.
> > > 
> > > Yeah I think this looks mostly reasonable. Some api design comments on top
> > > of Andrzej', with the fair warning that I didn't bother to read up on how
> > > it's all used in the end. I probably should go and do that, at least to
> > > get a feeling for what your hpd_cb usually does.
> > > 
> > >> More comments inlined.
> > >> 
> > >> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > >>> To support implementation of DRM connectors on top of DRM bridges
> > >>> instead of by bridges, the drm_bridge needs to expose new operations and
> > >>> data:
> > >>>
> > >>> - Output detection, hot-plug notification, mode retrieval and EDID
> > >>>   retrieval operations
> > >>> - Bitmask of supported operations
> > >> 
> > >> 
> > >> Why do we need these bitmask at all? Why cannot we rely on presence of
> > >> operation's callback?
> > > 
> > > Yeah also not a huge fan of these bitmasks. Smells like
> > > DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > > add, generally good excuse to not have to think through the design between
> > > different parts of drivers - "just" add another flag.
> > 
> > The reason is that a bridge may support an operation (as in implemented
> > in the bridge hardware), but that operation may not be supported on a
> > particular board. For instance an HDMI encoder may support reading EDID
> > when the DDC lines are connected to the encoder, but a board may connect
> > the DDC lines to an I2C port of the SoC. We thus need to decouple
> > if a particular instance of the device supports the operation (exposed
> > by the ops flags) from the function pointers.
> > 
> > We could of course allocate the drm_bridge_funcs structure dynamically
> > for each bridge instance, and fill it with function pointers manually,
> > leaving the unused ops always NULL, but that would require making the
> > structure writable, which is considered a security issue. That's why I
> > decided to keep the drm_bridge_funcs structure as a global static const
> > structure, and add an ops bitmask.
> > 
> > >>> - Bridge output type
> > >>>
> > >>> Add and document these.
> > >>>
> > >>> Three new bridge helper functions are also added to handle hot plug
> > >>> notification in a way that is as transparent as possible for the
> > >>> bridges.
> > >> 
> > >> Documentation of new opses does not explain how it should cooperate with
> > >> bridge chaining, I suppose they should be chained explicitly, am I
> > >> right? More comments about it later.
> > 
> > No, the whole point is that they should not be chained at all. A bridge
> > does not have to propagate, for instance, .get_edid() to the next
> > bridge. That's one of the core design principles in this series, I want
> > to keep the bridges as simple as possible, and move the complexity of
> > the boilerplate code that is currently copied all around to helpers. See
> > patch "drm: Add helper to create a connector for a chain of bridges" for
> > more information about how this is used, with a helper that delegates
> > the connector operations to the correct bridge in the chain based on the
> > ops reported by each bridge.
> > 
> > >>> Signed-off-by: Laurent Pinchart <[e-mail]>
> > >>> ---
> > >>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >>>  2 files changed, 261 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > >>> index 519577f363e3..3c2a255df7af 100644
> > >>> --- a/drivers/gpu/drm/drm_bridge.c
> > >>> +++ b/drivers/gpu/drm/drm_bridge.c
> > >>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >>>   */
> > >>>  void drm_bridge_add(struct drm_bridge *bridge)
> > >>>  {
> > >>> +	mutex_init(&bridge->hpd_mutex);
> > >>> +
> > >>>  	mutex_lock(&bridge_lock);
> > >>>  	list_add_tail(&bridge->list, &bridge_list);
> > >>>  	mutex_unlock(&bridge_lock);
> > >>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >>>  	mutex_lock(&bridge_lock);
> > >>>  	list_del_init(&bridge->list);
> > >>>  	mutex_unlock(&bridge_lock);
> > >>> +
> > >>> +	mutex_destroy(&bridge->hpd_mutex);
> > >>>  }
> > >>>  EXPORT_SYMBOL(drm_bridge_remove);
> > >>>  
> > >>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>  }
> > >>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >>>  
> > >>> +/**
> > >>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > >>> + * @bridge: bridge control structure
> > >>> + * @cb: hot-plug detection callback
> > >>> + * @data: data to be passed to the hot-plug detection callback
> > >>> + *
> > >>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > >>> + * hot plug notification callback. From now on the @cb will be called with
> > >>> + * @data when an output status change is detected by the bridge, until hot plug
> > >>> + * notification gets disabled with drm_bridge_hpd_disable().
> > >>> + *
> > >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>> + *
> > >>> + * Only one hot plug detection callback can be registered at a time, it is an
> > >>> + * error to call this function when hot plug detection is already enabled for
> > >>> + * the bridge.
> > >>> + */
> > >> 
> > >> To simplify architecture maybe would be better to enable hpd just on
> > >> bridge attach:
> > >> 
> > >> bridge->hpd_cb = cb;
> > >> 
> > >> bridge->hpd_data = data;
> > >> 
> > >> ret = drm_bridge_attach(...);
> > > 
> > > Yeah I like this more. The other problem here is, what if you need more
> > > than 1 callback registers on the same bridge hdp signal?
> > 
> > That's why I decided to hide hide HPD through helpers,
> > drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> > side, and drm_bridge_hpd_notify() on the event reporter side. While the
> > current implementation is limited to a single listener, only the helpers
> > would need to be changed to extend that to multiple listeners.
> > 
> > Note that the .hpd_enable() and .hpd_disable() operations also allow the
> > bridge to disable HPD detection when not used. Doing so keeps the bridge
> > simple, it only needs to care about reporting HPD events when they're
> > enabled, without caring who (if anyone) is listening, and gets clear
> > instructions on whether to enable or disable the HPD hardware (in case
> > it can be disabled).
> > 
> > >> This way we could avoid adding new callbacks hpd_(enable|disable)
> > >> without big sacrifices.
> > >> 
> > >> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > >> notifies about sink status change, how it translates to this cb?
> > 
> > This is something this series doesn't implement. I don't think it would
> > be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> > here. If you can elaborate on what would be needed, I can implement
> > that.
> > 
> > >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>> +			   void (*cb)(void *data,
> > >>> +				      enum drm_connector_status status),
> > >>> +			   void *data)
> > >>> +{
> > >>> +	if (!bridge || !bridge->funcs->hpd_enable)
> > >>> +		return;
> > >>> +
> > >>> +	mutex_lock(&bridge->hpd_mutex);
> > >>> +
> > >>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > >>> +		goto unlock;
> > >>> +
> > >>> +	bridge->hpd_cb = cb;
> > >>> +	bridge->hpd_data = data;
> > >>> +
> > >>> +	bridge->funcs->hpd_enable(bridge);
> > >>> +
> > >>> +unlock:
> > >>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > >>> +
> > >>> +/**
> > >>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > >>> + * @bridge: bridge control structure
> > >>> + *
> > >>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > >>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > >>> + * function returns the callback will not be called by the bridge when an
> > >>> + * output status change occurs.
> > >>> + *
> > >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>> + */
> > >>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > >>> +{
> > >>> +	if (!bridge || !bridge->funcs->hpd_disable)
> > >>> +		return;
> > >>> +
> > >>> +	mutex_lock(&bridge->hpd_mutex);
> > >>> +	bridge->funcs->hpd_disable(bridge);
> > >>> +
> > >>> +	bridge->hpd_cb = NULL;
> > >>> +	bridge->hpd_data = NULL;
> > >>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > >>> +
> > >>> +/**
> > >>> + * drm_bridge_hpd_notify - notify hot plug detection events
> > >>> + * @bridge: bridge control structure
> > >>> + * @status: output connection status
> > >>> + *
> > >>> + * Bridge drivers shall call this function to report hot plug events when they
> > >>> + * detect a change in the output status, when hot plug detection has been
> > >>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > >>> + *
> > >>> + * This function shall be called in a context that can sleep.
> > >>> + */
> > >>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>> +			   enum drm_connector_status status)
> > >>> +{
> > >>> +	mutex_lock(&bridge->hpd_mutex);
> > >>> +	if (bridge->hpd_cb)
> > >>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > > 
> > > So this isn't quite what I had in mind. Instead something like this:
> > > 
> > > 	/* iterates over all bridges in the chain containing @bridge */
> > > 	for_each_bridge(tmp_bridge, bridge) {
> > > 		if (tmp_bridge == bridge)
> > > 			continue;
> > > 		if (bridge->hpd_notify);
> > > 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > > 	}
> > > 
> > > 	encoder = encoder_for_bridge(bridge);
> > > 	if (encoder->helper_private->bridge_hpd_notify)
> > > 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > > 
> > > 	dev = bridge->dev
> > > 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > > 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > > 
> > > No register callback needed, no locking needed, everyone gets exactly the
> > > hpd they want/need.
> > 
> > I'll reply to this further down the mail thread, to address additional
> > comments.
> > 
> > >>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>> +}
> > >>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > >>> +
> > >>>  #ifdef CONFIG_OF
> > >>>  /**
> > >>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > >>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > >>> index 08dc15f93ded..b9445aa5b1ef 100644
> > >>> --- a/include/drm/drm_bridge.h
> > >>> +++ b/include/drm/drm_bridge.h
> > >>> @@ -23,8 +23,9 @@
> > >>>  #ifndef __DRM_BRIDGE_H__
> > >>>  #define __DRM_BRIDGE_H__
> > >>>  
> > >>> -#include <linux/list.h>
> > >>>  #include <linux/ctype.h>
> > >>> +#include <linux/list.h>
> > >>> +#include <linux/mutex.h>
> > >>>  #include <drm/drm_mode_object.h>
> > >>>  #include <drm/drm_modes.h>
> > >>>  
> > >>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >>>  	 */
> > >>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >>>  				    struct drm_atomic_state *state);
> > >>> +
> > >>> +	/**
> > >>> +	 * @detect:
> > >>> +	 *
> > >>> +	 * Check if anything is attached to the bridge output.
> > >>> +	 *
> > >>> +	 * This callback is optional, if not implemented the bridge will be
> > >>> +	 * considered as always having a component attached to its output.
> > >>> +	 * Bridges that implement this callback shall set the
> > >>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > >>> +	 *
> > >>> +	 * RETURNS:
> > >>> +	 *
> > >>> +	 * drm_connector_status indicating the bridge output status.
> > >>> +	 */
> > >>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > >>> +
> > >>> +	/**
> > >>> +	 * @get_modes:
> > >>> +	 *
> > >>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> > >>> +	 * with drm_mode_probed_add().
> > >>> +	 *
> > >>> +	 * The @get_modes callback is mostly intended to support non-probable
> > >>> +	 * displays such as many fixed panels. Bridges that support reading
> > >>> +	 * EDID shall leave @get_modes unimplemented and implement the
> > >>> +	 * &drm_bridge_funcs->get_edid callback instead.
> > >>> +	 *
> > >>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > >>> +	 *
> > >>> +	 * RETURNS:
> > >>> +	 *
> > >>> +	 * The number of modes added by calling drm_mode_probed_add().
> > >>> +	 */
> > >>> +	int (*get_modes)(struct drm_bridge *bridge,
> > >>> +			 struct drm_connector *connector);
> > >>> +
> > >>> +	/**
> > >>> +	 * @get_edid:
> > >>> +	 *
> > >>> +	 * Read and parse the EDID data of the connected display.
> > >>> +	 *
> > >>> +	 * The @get_edid callback is the preferred way of reporting mode
> > >>> +	 * information for a display connected to the bridge output. Bridges
> > >>> +	 * that support readind EDID shall implement this callback and leave
> > >>> +	 * the @get_modes callback unimplemented.
> > >>> +	 *
> > >>> +	 * The caller of this operation shall first verify the output
> > >>> +	 * connection status and refrain from reading EDID from a disconnected
> > >>> +	 * output.
> > >>> +	 *
> > >>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > >>> +	 *
> > >>> +	 * RETURNS:
> > >>> +	 *
> > >>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > >>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> > >>> +	 * the returned edid structure with kfree().
> > >>> +	 */
> > >>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > >>> +				 struct drm_connector *connector);
> > >> 
> > >> It overlaps with get_modes, I guess presence of one ops should disallow
> > >> presence of another one?
> > >> 
> > >> I am not really convinced we need this op at all, cannot we just assign
> > >> some helper function to .get_modes cb, which will do the same?
> > > 
> > > Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > > case, and require that if it has an edid it must fill out connector->info
> > > and connector->edid correctly.
> > 
> > I think that's doable, I'll have a look.
> 
> So I had a look, and while this is doable, it would essentially mean
> that all bridges that retrieve modes from EDID would have to roll out
> their own version of the following code:
> 
> static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> 					       struct drm_bridge *bridge)
> {
> 	enum drm_connector_status status;
> 	struct edid *edid;
> 	int n;
> 
> 	status = drm_bridge_connector_detect(connector, false);
> 	if (status != connector_status_connected)
> 		goto no_edid;
> 
> 	edid = bridge->funcs->get_edid(bridge, connector);
> 	if (!edid || !drm_edid_is_valid(edid)) {
> 		kfree(edid);
> 		goto no_edid;
> 	}
> 
> 	drm_connector_update_edid_property(connector, edid);
> 	n = drm_add_edid_modes(connector, edid);
> 
> 	kfree(edid);
> 	return n;
> 
> no_edid:
> 	drm_connector_update_edid_property(connector, NULL);
> 	return 0;
> }
> 
> Is this desired ?

We store the edid, and we store a lot of decoded information in
drm_connector->display_info. Can't they just look there? Re-fetching the
edid definitely sounds like the wrong thing to do.

We might run into some ordering issue here I guess with hotplugs and who's
fetching the edid and everything like that.

Also maybe I'm missing the point here, and thinking too much of
->get_modes on the connector. But then I'm not clear on why the bridge
needs the connector, and why it instead can't just return the edid it can
read and let the caller/core figure out everything else?
-Daniel

> 
> > > Btw if a hpd happens, who's responible for making sure the edid/mode list
> > > in the connector is up-to-date? With your current callback design that's
> > > up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > > should guarantee that it'll first walk the connectors to update status and
> > > edid/mode list for the final drm_connector. And then instead of just
> > > passing the simple "status", it'll pass the connector, with everything
> > > correctly updated.
> > > 
> > > Otherwise everyone interested in that hpd signal will go and re-fetch the
> > > edid, which is not so awesome :-)
> > 
> > With the current design there's a single listener, so it's not a big
> > deal :-) Furthermore, the listener is the helper that creates a
> > connector on top of a chain of bridges, so it's a pretty good place to
> > handle this. See the call to drm_kms_helper_hotplug_event() in
> > drm_bridge_connector_hpd_cb().
> > 
> > I'm all for reworking HPD and mode fetching, but I think it's a bit too
> > big of a requirement as a prerequisite for this series (or as part of
> > this series). We have hardware that can report HPD with various level of
> > details (from "something happened on a connector" to "this particular
> > event happened on this particular connector"), and we channel that
> > through helpers such as drm_kms_helper_hotplug_event() that lose the
> > details and go through a heavy mechanism to refetch everything. I
> > understand this is needed in many cases, but I think there's room for
> > improvement. This series, in my opinion, doesn't go in the wrong
> > direction in that regard, as it eventually calls
> > drm_kms_helper_hotplug_event(), so I think improvements would make sense
> > on top of it. I'm even willing to work on this, provided I get feedback
> > on what is desired.
> > 
> > >>> +	/**
> > >>> +	 * @lost_hotplug:
> > >>> +	 *
> > >>> +	 * Notify the bridge of display disconnection.
> > >>> +	 *
> > >>> +	 * This callback is optional, it may be implemented by bridges that
> > >>> +	 * need to be notified of display disconnection for internal reasons.
> > >>> +	 * One use case is to reset the internal state of CEC controllers for
> > >>> +	 * HDMI bridges.
> > >>> +	 */
> > >>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > >>> +
> > >>> +	/**
> > >>> +	 * @hpd_enable:
> > >>> +	 *
> > >>> +	 * Enable hot plug detection. From now on the bridge shall call
> > >>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > >>> +	 * connection status, until hot plug detection gets disabled with
> > >>> +	 * @hpd_disable.
> > >>> +	 *
> > >>> +	 * This callback is optional and shall only be implemented by bridges
> > >>> +	 * that support hot-plug notification without polling. Bridges that
> > >>> +	 * implement it shall also implement the @hpd_disable callback and set
> > >>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>> +	 */
> > >>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> > >>> +
> > >>> +	/**
> > >>> +	 * @hpd_disable:
> > >>> +	 *
> > >>> +	 * Disable hot plug detection. Once this function returns the bridge
> > >>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > >>> +	 * connection status occurs.
> > >>> +	 *
> > >>> +	 * This callback is optional and shall only be implemented by bridges
> > >>> +	 * that support hot-plug notification without polling. Bridges that
> > >>> +	 * implement it shall also implement the @hpd_enable callback and set
> > >>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>> +	 */
> > >>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >>>  };
> > >>>  
> > >>>  /**
> > >>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >>>  	bool dual_link;
> > >>>  };
> > >>>  
> > >>> +/**
> > >>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > >>> + */
> > >>> +enum drm_bridge_ops {
> > >>> +	/**
> > >>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > >>> +	 * its output. Bridges that set this flag shall implement the
> > >>> +	 * &drm_bridge_funcs->detect callback.
> > >>> +	 */
> > >>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > >>> +	/**
> > >>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > >>> +	 * connected to its output. Bridges that set this flag shall implement
> > >>> +	 * the &drm_bridge_funcs->get_edid callback.
> > >>> +	 */
> > >>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> > >>> +	/**
> > >>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > >>> +	 * without requiring polling. Bridges that set this flag shall
> > >>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> > >>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > >>> +	 */
> > >>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> > >>> +	/**
> > >>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > >>> +	 * by the display at its output. This does not include readind EDID
> > >>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > >>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > >>> +	 */
> > >>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> > >>> +};
> > >>> +
> > >>>  /**
> > >>>   * struct drm_bridge - central DRM bridge control structure
> > >>>   */
> > >>> @@ -398,6 +535,29 @@ struct drm_bridge {
> > >>>  	const struct drm_bridge_funcs *funcs;
> > >>>  	/** @driver_private: pointer to the bridge driver's internal context */
> > >>>  	void *driver_private;
> > >>> +	/** @ops: bitmask of operations supported by the bridge */
> > >>> +	enum drm_bridge_ops ops;
> > >>> +	/**
> > >>> +	 * @type: Type of the connection at the bridge output
> > >>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > >>> +	 * identifies the type of connected display.
> > >>> +	 */
> > >>> +	int type;
> > >>> +	/** private: */
> > >>> +	/**
> > >>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > >>> +	 */
> > >>> +	struct mutex hpd_mutex;
> > >>> +	/**
> > >>> +	 * @hpd_cb: Hot plug detection callback, registered with
> > >>> +	 * drm_bridge_hpd_enable().
> > >>> +	 */
> > >>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > >>> +	/**
> > >>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > >>> +	 * @hpd_cb.
> > >>> +	 */
> > >>> +	void *hpd_data;
> > >>>  };
> > >>>  
> > >>>  void drm_bridge_add(struct drm_bridge *bridge);
> > >>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>  			      struct drm_atomic_state *state);
> > >>>  
> > >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>> +			   void (*cb)(void *data,
> > >>> +				      enum drm_connector_status status),
> > >>> +			   void *data);
> > >>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > >>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>> +			   enum drm_connector_status status);
> > >>> +
> > >>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >>>  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Laurent Pinchart Aug. 14, 2019, 1:30 p.m. UTC | #22

Hi Daniel,

On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> > On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> >> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> >>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>> Hi Laurent,
> >>>> 
> >>>> I like the approach, current practice when almost every bridge should
> >>>> optionally implement connector, or alternatively downstream bridge or
> >>>> panel is very painful.
> >>> 
> >>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>> it's all used in the end. I probably should go and do that, at least to
> >>> get a feeling for what your hpd_cb usually does.
> >>> 
> >>>> More comments inlined.
> >>>> 
> >>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>> data:
> >>>>>
> >>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>   retrieval operations
> >>>>> - Bitmask of supported operations
> >>>> 
> >>>> 
> >>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>> operation's callback?
> >>> 
> >>> Yeah also not a huge fan of these bitmasks. Smells like
> >>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>> add, generally good excuse to not have to think through the design between
> >>> different parts of drivers - "just" add another flag.
> >> 
> >> The reason is that a bridge may support an operation (as in implemented
> >> in the bridge hardware), but that operation may not be supported on a
> >> particular board. For instance an HDMI encoder may support reading EDID
> >> when the DDC lines are connected to the encoder, but a board may connect
> >> the DDC lines to an I2C port of the SoC. We thus need to decouple
> >> if a particular instance of the device supports the operation (exposed
> >> by the ops flags) from the function pointers.
> >> 
> >> We could of course allocate the drm_bridge_funcs structure dynamically
> >> for each bridge instance, and fill it with function pointers manually,
> >> leaving the unused ops always NULL, but that would require making the
> >> structure writable, which is considered a security issue. That's why I
> >> decided to keep the drm_bridge_funcs structure as a global static const
> >> structure, and add an ops bitmask.
> >> 
> >>>>> - Bridge output type
> >>>>>
> >>>>> Add and document these.
> >>>>>
> >>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>> notification in a way that is as transparent as possible for the
> >>>>> bridges.
> >>>> 
> >>>> Documentation of new opses does not explain how it should cooperate with
> >>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>> right? More comments about it later.
> >> 
> >> No, the whole point is that they should not be chained at all. A bridge
> >> does not have to propagate, for instance, .get_edid() to the next
> >> bridge. That's one of the core design principles in this series, I want
> >> to keep the bridges as simple as possible, and move the complexity of
> >> the boilerplate code that is currently copied all around to helpers. See
> >> patch "drm: Add helper to create a connector for a chain of bridges" for
> >> more information about how this is used, with a helper that delegates
> >> the connector operations to the correct bridge in the chain based on the
> >> ops reported by each bridge.
> >> 
> >>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>> ---
> >>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>   */
> >>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>  {
> >>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>> +
> >>>>>  	mutex_lock(&bridge_lock);
> >>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>  	mutex_unlock(&bridge_lock);
> >>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>  	mutex_lock(&bridge_lock);
> >>>>>  	list_del_init(&bridge->list);
> >>>>>  	mutex_unlock(&bridge_lock);
> >>>>> +
> >>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>  }
> >>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>  
> >>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>  }
> >>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>  
> >>>>> +/**
> >>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>> + * @bridge: bridge control structure
> >>>>> + * @cb: hot-plug detection callback
> >>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>> + *
> >>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>> + *
> >>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>> + *
> >>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>> + * the bridge.
> >>>>> + */
> >>>> 
> >>>> To simplify architecture maybe would be better to enable hpd just on
> >>>> bridge attach:
> >>>> 
> >>>> bridge->hpd_cb = cb;
> >>>> 
> >>>> bridge->hpd_data = data;
> >>>> 
> >>>> ret = drm_bridge_attach(...);
> >>> 
> >>> Yeah I like this more. The other problem here is, what if you need more
> >>> than 1 callback registers on the same bridge hdp signal?
> >> 
> >> That's why I decided to hide hide HPD through helpers,
> >> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> >> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> >> current implementation is limited to a single listener, only the helpers
> >> would need to be changed to extend that to multiple listeners.
> >> 
> >> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> >> bridge to disable HPD detection when not used. Doing so keeps the bridge
> >> simple, it only needs to care about reporting HPD events when they're
> >> enabled, without caring who (if anyone) is listening, and gets clear
> >> instructions on whether to enable or disable the HPD hardware (in case
> >> it can be disabled).
> >> 
> >>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>> without big sacrifices.
> >>>> 
> >>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>> notifies about sink status change, how it translates to this cb?
> >> 
> >> This is something this series doesn't implement. I don't think it would
> >> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> >> here. If you can elaborate on what would be needed, I can implement
> >> that.
> >> 
> >>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>> +			   void (*cb)(void *data,
> >>>>> +				      enum drm_connector_status status),
> >>>>> +			   void *data)
> >>>>> +{
> >>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>> +		return;
> >>>>> +
> >>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>> +
> >>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>> +		goto unlock;
> >>>>> +
> >>>>> +	bridge->hpd_cb = cb;
> >>>>> +	bridge->hpd_data = data;
> >>>>> +
> >>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>> +
> >>>>> +unlock:
> >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>> +
> >>>>> +/**
> >>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>> + * @bridge: bridge control structure
> >>>>> + *
> >>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>> + * function returns the callback will not be called by the bridge when an
> >>>>> + * output status change occurs.
> >>>>> + *
> >>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>> + */
> >>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>> +{
> >>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>> +		return;
> >>>>> +
> >>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>> +
> >>>>> +	bridge->hpd_cb = NULL;
> >>>>> +	bridge->hpd_data = NULL;
> >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>> +
> >>>>> +/**
> >>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>> + * @bridge: bridge control structure
> >>>>> + * @status: output connection status
> >>>>> + *
> >>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>> + *
> >>>>> + * This function shall be called in a context that can sleep.
> >>>>> + */
> >>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>> +			   enum drm_connector_status status)
> >>>>> +{
> >>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>> +	if (bridge->hpd_cb)
> >>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>> 
> >>> So this isn't quite what I had in mind. Instead something like this:
> >>> 
> >>> 	/* iterates over all bridges in the chain containing @bridge */
> >>> 	for_each_bridge(tmp_bridge, bridge) {
> >>> 		if (tmp_bridge == bridge)
> >>> 			continue;
> >>> 		if (bridge->hpd_notify);
> >>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>> 	}
> >>> 
> >>> 	encoder = encoder_for_bridge(bridge);
> >>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>> 
> >>> 	dev = bridge->dev
> >>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>> 
> >>> No register callback needed, no locking needed, everyone gets exactly the
> >>> hpd they want/need.
> >> 
> >> I'll reply to this further down the mail thread, to address additional
> >> comments.
> >> 
> >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>> +}
> >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>> +
> >>>>>  #ifdef CONFIG_OF
> >>>>>  /**
> >>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>> --- a/include/drm/drm_bridge.h
> >>>>> +++ b/include/drm/drm_bridge.h
> >>>>> @@ -23,8 +23,9 @@
> >>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>  #define __DRM_BRIDGE_H__
> >>>>>  
> >>>>> -#include <linux/list.h>
> >>>>>  #include <linux/ctype.h>
> >>>>> +#include <linux/list.h>
> >>>>> +#include <linux/mutex.h>
> >>>>>  #include <drm/drm_mode_object.h>
> >>>>>  #include <drm/drm_modes.h>
> >>>>>  
> >>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>  	 */
> >>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>  				    struct drm_atomic_state *state);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @detect:
> >>>>> +	 *
> >>>>> +	 * Check if anything is attached to the bridge output.
> >>>>> +	 *
> >>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>> +	 * considered as always having a component attached to its output.
> >>>>> +	 * Bridges that implement this callback shall set the
> >>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>> +	 *
> >>>>> +	 * RETURNS:
> >>>>> +	 *
> >>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>> +	 */
> >>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @get_modes:
> >>>>> +	 *
> >>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>> +	 * with drm_mode_probed_add().
> >>>>> +	 *
> >>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>> +	 *
> >>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>> +	 *
> >>>>> +	 * RETURNS:
> >>>>> +	 *
> >>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>> +	 */
> >>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>> +			 struct drm_connector *connector);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @get_edid:
> >>>>> +	 *
> >>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>> +	 *
> >>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>> +	 * the @get_modes callback unimplemented.
> >>>>> +	 *
> >>>>> +	 * The caller of this operation shall first verify the output
> >>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>> +	 * output.
> >>>>> +	 *
> >>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>> +	 *
> >>>>> +	 * RETURNS:
> >>>>> +	 *
> >>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>> +	 * the returned edid structure with kfree().
> >>>>> +	 */
> >>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>> +				 struct drm_connector *connector);
> >>>> 
> >>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>> presence of another one?
> >>>> 
> >>>> I am not really convinced we need this op at all, cannot we just assign
> >>>> some helper function to .get_modes cb, which will do the same?
> >>> 
> >>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>> case, and require that if it has an edid it must fill out connector->info
> >>> and connector->edid correctly.
> >> 
> >> I think that's doable, I'll have a look.
> > 
> > So I had a look, and while this is doable, it would essentially mean
> > that all bridges that retrieve modes from EDID would have to roll out
> > their own version of the following code:
> > 
> > static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> > 					       struct drm_bridge *bridge)
> > {
> > 	enum drm_connector_status status;
> > 	struct edid *edid;
> > 	int n;
> > 
> > 	status = drm_bridge_connector_detect(connector, false);
> > 	if (status != connector_status_connected)
> > 		goto no_edid;
> > 
> > 	edid = bridge->funcs->get_edid(bridge, connector);
> > 	if (!edid || !drm_edid_is_valid(edid)) {
> > 		kfree(edid);
> > 		goto no_edid;
> > 	}
> > 
> > 	drm_connector_update_edid_property(connector, edid);
> > 	n = drm_add_edid_modes(connector, edid);
> > 
> > 	kfree(edid);
> > 	return n;
> > 
> > no_edid:
> > 	drm_connector_update_edid_property(connector, NULL);
> > 	return 0;
> > }
> > 
> > Is this desired ?
> 
> We store the edid, and we store a lot of decoded information in
> drm_connector->display_info. Can't they just look there? Re-fetching the
> edid definitely sounds like the wrong thing to do.
> 
> We might run into some ordering issue here I guess with hotplugs and who's
> fetching the edid and everything like that.

That's exactly what I was about to answer after reading your first
paragraph :-) I believe caching EDID is a good idea, but my familiarity
with hotplug-related issues is limited to a handful of systems, and I'm
sure I'm missing some common problems. If you can tell me how you think
this should be done, I can give it a try.

> Also maybe I'm missing the point here, and thinking too much of
> ->get_modes on the connector. But then I'm not clear on why the bridge
> needs the connector, and why it instead can't just return the edid it can
> read and let the caller/core figure out everything else?

That's exactly what the .get_edid() operation that you asked me to
remove did... :-) You didn't like the fact that it duplicated the
.get_modes() logic. Should I add it back, and clearly document
.get_modes() as a fallback used only when the connector doesn't use EDID
?

> >>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>> in the connector is up-to-date? With your current callback design that's
> >>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>> should guarantee that it'll first walk the connectors to update status and
> >>> edid/mode list for the final drm_connector. And then instead of just
> >>> passing the simple "status", it'll pass the connector, with everything
> >>> correctly updated.
> >>> 
> >>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>> edid, which is not so awesome :-)
> >> 
> >> With the current design there's a single listener, so it's not a big
> >> deal :-) Furthermore, the listener is the helper that creates a
> >> connector on top of a chain of bridges, so it's a pretty good place to
> >> handle this. See the call to drm_kms_helper_hotplug_event() in
> >> drm_bridge_connector_hpd_cb().
> >> 
> >> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> >> big of a requirement as a prerequisite for this series (or as part of
> >> this series). We have hardware that can report HPD with various level of
> >> details (from "something happened on a connector" to "this particular
> >> event happened on this particular connector"), and we channel that
> >> through helpers such as drm_kms_helper_hotplug_event() that lose the
> >> details and go through a heavy mechanism to refetch everything. I
> >> understand this is needed in many cases, but I think there's room for
> >> improvement. This series, in my opinion, doesn't go in the wrong
> >> direction in that regard, as it eventually calls
> >> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> >> on top of it. I'm even willing to work on this, provided I get feedback
> >> on what is desired.
> >> 
> >>>>> +	/**
> >>>>> +	 * @lost_hotplug:
> >>>>> +	 *
> >>>>> +	 * Notify the bridge of display disconnection.
> >>>>> +	 *
> >>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>> +	 * HDMI bridges.
> >>>>> +	 */
> >>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @hpd_enable:
> >>>>> +	 *
> >>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>> +	 * @hpd_disable.
> >>>>> +	 *
> >>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>> +	 */
> >>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>> +
> >>>>> +	/**
> >>>>> +	 * @hpd_disable:
> >>>>> +	 *
> >>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>> +	 * connection status occurs.
> >>>>> +	 *
> >>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>> +	 */
> >>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>  };
> >>>>>  
> >>>>>  /**
> >>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>  	bool dual_link;
> >>>>>  };
> >>>>>  
> >>>>> +/**
> >>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>> + */
> >>>>> +enum drm_bridge_ops {
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>> +	/**
> >>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>> +	 */
> >>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>> +};
> >>>>> +
> >>>>>  /**
> >>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>   */
> >>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>  	void *driver_private;
> >>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>> +	enum drm_bridge_ops ops;
> >>>>> +	/**
> >>>>> +	 * @type: Type of the connection at the bridge output
> >>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>> +	 * identifies the type of connected display.
> >>>>> +	 */
> >>>>> +	int type;
> >>>>> +	/** private: */
> >>>>> +	/**
> >>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>> +	 */
> >>>>> +	struct mutex hpd_mutex;
> >>>>> +	/**
> >>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>> +	 * drm_bridge_hpd_enable().
> >>>>> +	 */
> >>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>> +	/**
> >>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>> +	 * @hpd_cb.
> >>>>> +	 */
> >>>>> +	void *hpd_data;
> >>>>>  };
> >>>>>  
> >>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>  			      struct drm_atomic_state *state);
> >>>>>  
> >>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>> +			   void (*cb)(void *data,
> >>>>> +				      enum drm_connector_status status),
> >>>>> +			   void *data);
> >>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>> +			   enum drm_connector_status status);
> >>>>> +
> >>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>  					u32 connector_type);

Daniel Vetter Aug. 14, 2019, 5:02 p.m. UTC | #23

On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> > > On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> > >> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > >>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > >>>> Hi Laurent,
> > >>>> 
> > >>>> I like the approach, current practice when almost every bridge should
> > >>>> optionally implement connector, or alternatively downstream bridge or
> > >>>> panel is very painful.
> > >>> 
> > >>> Yeah I think this looks mostly reasonable. Some api design comments on top
> > >>> of Andrzej', with the fair warning that I didn't bother to read up on how
> > >>> it's all used in the end. I probably should go and do that, at least to
> > >>> get a feeling for what your hpd_cb usually does.
> > >>> 
> > >>>> More comments inlined.
> > >>>> 
> > >>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > >>>>> To support implementation of DRM connectors on top of DRM bridges
> > >>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> > >>>>> data:
> > >>>>>
> > >>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> > >>>>>   retrieval operations
> > >>>>> - Bitmask of supported operations
> > >>>> 
> > >>>> 
> > >>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> > >>>> operation's callback?
> > >>> 
> > >>> Yeah also not a huge fan of these bitmasks. Smells like
> > >>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > >>> add, generally good excuse to not have to think through the design between
> > >>> different parts of drivers - "just" add another flag.
> > >> 
> > >> The reason is that a bridge may support an operation (as in implemented
> > >> in the bridge hardware), but that operation may not be supported on a
> > >> particular board. For instance an HDMI encoder may support reading EDID
> > >> when the DDC lines are connected to the encoder, but a board may connect
> > >> the DDC lines to an I2C port of the SoC. We thus need to decouple
> > >> if a particular instance of the device supports the operation (exposed
> > >> by the ops flags) from the function pointers.
> > >> 
> > >> We could of course allocate the drm_bridge_funcs structure dynamically
> > >> for each bridge instance, and fill it with function pointers manually,
> > >> leaving the unused ops always NULL, but that would require making the
> > >> structure writable, which is considered a security issue. That's why I
> > >> decided to keep the drm_bridge_funcs structure as a global static const
> > >> structure, and add an ops bitmask.
> > >> 
> > >>>>> - Bridge output type
> > >>>>>
> > >>>>> Add and document these.
> > >>>>>
> > >>>>> Three new bridge helper functions are also added to handle hot plug
> > >>>>> notification in a way that is as transparent as possible for the
> > >>>>> bridges.
> > >>>> 
> > >>>> Documentation of new opses does not explain how it should cooperate with
> > >>>> bridge chaining, I suppose they should be chained explicitly, am I
> > >>>> right? More comments about it later.
> > >> 
> > >> No, the whole point is that they should not be chained at all. A bridge
> > >> does not have to propagate, for instance, .get_edid() to the next
> > >> bridge. That's one of the core design principles in this series, I want
> > >> to keep the bridges as simple as possible, and move the complexity of
> > >> the boilerplate code that is currently copied all around to helpers. See
> > >> patch "drm: Add helper to create a connector for a chain of bridges" for
> > >> more information about how this is used, with a helper that delegates
> > >> the connector operations to the correct bridge in the chain based on the
> > >> ops reported by each bridge.
> > >> 
> > >>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> > >>>>> ---
> > >>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> > >>>>>
> > >>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > >>>>> index 519577f363e3..3c2a255df7af 100644
> > >>>>> --- a/drivers/gpu/drm/drm_bridge.c
> > >>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> > >>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >>>>>   */
> > >>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> > >>>>>  {
> > >>>>> +	mutex_init(&bridge->hpd_mutex);
> > >>>>> +
> > >>>>>  	mutex_lock(&bridge_lock);
> > >>>>>  	list_add_tail(&bridge->list, &bridge_list);
> > >>>>>  	mutex_unlock(&bridge_lock);
> > >>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >>>>>  	mutex_lock(&bridge_lock);
> > >>>>>  	list_del_init(&bridge->list);
> > >>>>>  	mutex_unlock(&bridge_lock);
> > >>>>> +
> > >>>>> +	mutex_destroy(&bridge->hpd_mutex);
> > >>>>>  }
> > >>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> > >>>>>  
> > >>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>  }
> > >>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >>>>>  
> > >>>>> +/**
> > >>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > >>>>> + * @bridge: bridge control structure
> > >>>>> + * @cb: hot-plug detection callback
> > >>>>> + * @data: data to be passed to the hot-plug detection callback
> > >>>>> + *
> > >>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > >>>>> + * hot plug notification callback. From now on the @cb will be called with
> > >>>>> + * @data when an output status change is detected by the bridge, until hot plug
> > >>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> > >>>>> + *
> > >>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>> + *
> > >>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> > >>>>> + * error to call this function when hot plug detection is already enabled for
> > >>>>> + * the bridge.
> > >>>>> + */
> > >>>> 
> > >>>> To simplify architecture maybe would be better to enable hpd just on
> > >>>> bridge attach:
> > >>>> 
> > >>>> bridge->hpd_cb = cb;
> > >>>> 
> > >>>> bridge->hpd_data = data;
> > >>>> 
> > >>>> ret = drm_bridge_attach(...);
> > >>> 
> > >>> Yeah I like this more. The other problem here is, what if you need more
> > >>> than 1 callback registers on the same bridge hdp signal?
> > >> 
> > >> That's why I decided to hide hide HPD through helpers,
> > >> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> > >> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> > >> current implementation is limited to a single listener, only the helpers
> > >> would need to be changed to extend that to multiple listeners.
> > >> 
> > >> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> > >> bridge to disable HPD detection when not used. Doing so keeps the bridge
> > >> simple, it only needs to care about reporting HPD events when they're
> > >> enabled, without caring who (if anyone) is listening, and gets clear
> > >> instructions on whether to enable or disable the HPD hardware (in case
> > >> it can be disabled).
> > >> 
> > >>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> > >>>> without big sacrifices.
> > >>>> 
> > >>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > >>>> notifies about sink status change, how it translates to this cb?
> > >> 
> > >> This is something this series doesn't implement. I don't think it would
> > >> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> > >> here. If you can elaborate on what would be needed, I can implement
> > >> that.
> > >> 
> > >>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>> +			   void (*cb)(void *data,
> > >>>>> +				      enum drm_connector_status status),
> > >>>>> +			   void *data)
> > >>>>> +{
> > >>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> > >>>>> +		return;
> > >>>>> +
> > >>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>> +
> > >>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > >>>>> +		goto unlock;
> > >>>>> +
> > >>>>> +	bridge->hpd_cb = cb;
> > >>>>> +	bridge->hpd_data = data;
> > >>>>> +
> > >>>>> +	bridge->funcs->hpd_enable(bridge);
> > >>>>> +
> > >>>>> +unlock:
> > >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>> +}
> > >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > >>>>> + * @bridge: bridge control structure
> > >>>>> + *
> > >>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > >>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > >>>>> + * function returns the callback will not be called by the bridge when an
> > >>>>> + * output status change occurs.
> > >>>>> + *
> > >>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>> + */
> > >>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > >>>>> +{
> > >>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> > >>>>> +		return;
> > >>>>> +
> > >>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>> +	bridge->funcs->hpd_disable(bridge);
> > >>>>> +
> > >>>>> +	bridge->hpd_cb = NULL;
> > >>>>> +	bridge->hpd_data = NULL;
> > >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>> +}
> > >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > >>>>> +
> > >>>>> +/**
> > >>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> > >>>>> + * @bridge: bridge control structure
> > >>>>> + * @status: output connection status
> > >>>>> + *
> > >>>>> + * Bridge drivers shall call this function to report hot plug events when they
> > >>>>> + * detect a change in the output status, when hot plug detection has been
> > >>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > >>>>> + *
> > >>>>> + * This function shall be called in a context that can sleep.
> > >>>>> + */
> > >>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>> +			   enum drm_connector_status status)
> > >>>>> +{
> > >>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>> +	if (bridge->hpd_cb)
> > >>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > >>> 
> > >>> So this isn't quite what I had in mind. Instead something like this:
> > >>> 
> > >>> 	/* iterates over all bridges in the chain containing @bridge */
> > >>> 	for_each_bridge(tmp_bridge, bridge) {
> > >>> 		if (tmp_bridge == bridge)
> > >>> 			continue;
> > >>> 		if (bridge->hpd_notify);
> > >>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > >>> 	}
> > >>> 
> > >>> 	encoder = encoder_for_bridge(bridge);
> > >>> 	if (encoder->helper_private->bridge_hpd_notify)
> > >>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > >>> 
> > >>> 	dev = bridge->dev
> > >>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > >>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > >>> 
> > >>> No register callback needed, no locking needed, everyone gets exactly the
> > >>> hpd they want/need.
> > >> 
> > >> I'll reply to this further down the mail thread, to address additional
> > >> comments.
> > >> 
> > >>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>> +}
> > >>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > >>>>> +
> > >>>>>  #ifdef CONFIG_OF
> > >>>>>  /**
> > >>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > >>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > >>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> > >>>>> --- a/include/drm/drm_bridge.h
> > >>>>> +++ b/include/drm/drm_bridge.h
> > >>>>> @@ -23,8 +23,9 @@
> > >>>>>  #ifndef __DRM_BRIDGE_H__
> > >>>>>  #define __DRM_BRIDGE_H__
> > >>>>>  
> > >>>>> -#include <linux/list.h>
> > >>>>>  #include <linux/ctype.h>
> > >>>>> +#include <linux/list.h>
> > >>>>> +#include <linux/mutex.h>
> > >>>>>  #include <drm/drm_mode_object.h>
> > >>>>>  #include <drm/drm_modes.h>
> > >>>>>  
> > >>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >>>>>  	 */
> > >>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >>>>>  				    struct drm_atomic_state *state);
> > >>>>> +
> > >>>>> +	/**
> > >>>>> +	 * @detect:
> > >>>>> +	 *
> > >>>>> +	 * Check if anything is attached to the bridge output.
> > >>>>> +	 *
> > >>>>> +	 * This callback is optional, if not implemented the bridge will be
> > >>>>> +	 * considered as always having a component attached to its output.
> > >>>>> +	 * Bridges that implement this callback shall set the
> > >>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > >>>>> +	 *
> > >>>>> +	 * RETURNS:
> > >>>>> +	 *
> > >>>>> +	 * drm_connector_status indicating the bridge output status.
> > >>>>> +	 */
> > >>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > >>>>> +
> > >>>>> +	/**
> > >>>>> +	 * @get_modes:
> > >>>>> +	 *
> > >>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> > >>>>> +	 * with drm_mode_probed_add().
> > >>>>> +	 *
> > >>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> > >>>>> +	 * displays such as many fixed panels. Bridges that support reading
> > >>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> > >>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> > >>>>> +	 *
> > >>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > >>>>> +	 *
> > >>>>> +	 * RETURNS:
> > >>>>> +	 *
> > >>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> > >>>>> +	 */
> > >>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> > >>>>> +			 struct drm_connector *connector);
> > >>>>> +
> > >>>>> +	/**
> > >>>>> +	 * @get_edid:
> > >>>>> +	 *
> > >>>>> +	 * Read and parse the EDID data of the connected display.
> > >>>>> +	 *
> > >>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> > >>>>> +	 * information for a display connected to the bridge output. Bridges
> > >>>>> +	 * that support readind EDID shall implement this callback and leave
> > >>>>> +	 * the @get_modes callback unimplemented.
> > >>>>> +	 *
> > >>>>> +	 * The caller of this operation shall first verify the output
> > >>>>> +	 * connection status and refrain from reading EDID from a disconnected
> > >>>>> +	 * output.
> > >>>>> +	 *
> > >>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > >>>>> +	 *
> > >>>>> +	 * RETURNS:
> > >>>>> +	 *
> > >>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > >>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> > >>>>> +	 * the returned edid structure with kfree().
> > >>>>> +	 */
> > >>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > >>>>> +				 struct drm_connector *connector);
> > >>>> 
> > >>>> It overlaps with get_modes, I guess presence of one ops should disallow
> > >>>> presence of another one?
> > >>>> 
> > >>>> I am not really convinced we need this op at all, cannot we just assign
> > >>>> some helper function to .get_modes cb, which will do the same?
> > >>> 
> > >>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > >>> case, and require that if it has an edid it must fill out connector->info
> > >>> and connector->edid correctly.
> > >> 
> > >> I think that's doable, I'll have a look.
> > > 
> > > So I had a look, and while this is doable, it would essentially mean
> > > that all bridges that retrieve modes from EDID would have to roll out
> > > their own version of the following code:
> > > 
> > > static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> > > 					       struct drm_bridge *bridge)
> > > {
> > > 	enum drm_connector_status status;
> > > 	struct edid *edid;
> > > 	int n;
> > > 
> > > 	status = drm_bridge_connector_detect(connector, false);
> > > 	if (status != connector_status_connected)
> > > 		goto no_edid;
> > > 
> > > 	edid = bridge->funcs->get_edid(bridge, connector);
> > > 	if (!edid || !drm_edid_is_valid(edid)) {
> > > 		kfree(edid);
> > > 		goto no_edid;
> > > 	}
> > > 
> > > 	drm_connector_update_edid_property(connector, edid);
> > > 	n = drm_add_edid_modes(connector, edid);
> > > 
> > > 	kfree(edid);
> > > 	return n;
> > > 
> > > no_edid:
> > > 	drm_connector_update_edid_property(connector, NULL);
> > > 	return 0;
> > > }
> > > 
> > > Is this desired ?
> > 
> > We store the edid, and we store a lot of decoded information in
> > drm_connector->display_info. Can't they just look there? Re-fetching the
> > edid definitely sounds like the wrong thing to do.
> > 
> > We might run into some ordering issue here I guess with hotplugs and who's
> > fetching the edid and everything like that.
> 
> That's exactly what I was about to answer after reading your first
> paragraph :-) I believe caching EDID is a good idea, but my familiarity
> with hotplug-related issues is limited to a handful of systems, and I'm
> sure I'm missing some common problems. If you can tell me how you think
> this should be done, I can give it a try.

I think all you need to do is make sure that when handling a hpd, the edid
is fetched first. Before other parts of the bridge try to reconfigure
themselves ...

> > Also maybe I'm missing the point here, and thinking too much of
> > ->get_modes on the connector. But then I'm not clear on why the bridge
> > needs the connector, and why it instead can't just return the edid it can
> > read and let the caller/core figure out everything else?
> 
> That's exactly what the .get_edid() operation that you asked me to
> remove did... :-) You didn't like the fact that it duplicated the
> .get_modes() logic. Should I add it back, and clearly document
> .get_modes() as a fallback used only when the connector doesn't use EDID
> ?

I guess I'm making a bit a fool of myself here. What I meant is that if we
do want to keep ->get_edid, then why do you need to pass the connector?
Just return the edid blob, and let the caller parse it, and stuff all
relevant data into drm_connector. Just thinking along the lines of your
goal of making the bridge drivers as dumb as possible.

Same thing for ->get_modes would be neat too, but we don't have a nice
datastructure for this. We'd need to pass both a list_head and a pointer
to the drm_display_info I think.

That would decouple bridges even more from connector, which I think is
somewhere on your goal list ...
-Daniel

> 
> > >>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> > >>> in the connector is up-to-date? With your current callback design that's
> > >>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > >>> should guarantee that it'll first walk the connectors to update status and
> > >>> edid/mode list for the final drm_connector. And then instead of just
> > >>> passing the simple "status", it'll pass the connector, with everything
> > >>> correctly updated.
> > >>> 
> > >>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> > >>> edid, which is not so awesome :-)
> > >> 
> > >> With the current design there's a single listener, so it's not a big
> > >> deal :-) Furthermore, the listener is the helper that creates a
> > >> connector on top of a chain of bridges, so it's a pretty good place to
> > >> handle this. See the call to drm_kms_helper_hotplug_event() in
> > >> drm_bridge_connector_hpd_cb().
> > >> 
> > >> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> > >> big of a requirement as a prerequisite for this series (or as part of
> > >> this series). We have hardware that can report HPD with various level of
> > >> details (from "something happened on a connector" to "this particular
> > >> event happened on this particular connector"), and we channel that
> > >> through helpers such as drm_kms_helper_hotplug_event() that lose the
> > >> details and go through a heavy mechanism to refetch everything. I
> > >> understand this is needed in many cases, but I think there's room for
> > >> improvement. This series, in my opinion, doesn't go in the wrong
> > >> direction in that regard, as it eventually calls
> > >> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> > >> on top of it. I'm even willing to work on this, provided I get feedback
> > >> on what is desired.
> > >> 
> > >>>>> +	/**
> > >>>>> +	 * @lost_hotplug:
> > >>>>> +	 *
> > >>>>> +	 * Notify the bridge of display disconnection.
> > >>>>> +	 *
> > >>>>> +	 * This callback is optional, it may be implemented by bridges that
> > >>>>> +	 * need to be notified of display disconnection for internal reasons.
> > >>>>> +	 * One use case is to reset the internal state of CEC controllers for
> > >>>>> +	 * HDMI bridges.
> > >>>>> +	 */
> > >>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > >>>>> +
> > >>>>> +	/**
> > >>>>> +	 * @hpd_enable:
> > >>>>> +	 *
> > >>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> > >>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > >>>>> +	 * connection status, until hot plug detection gets disabled with
> > >>>>> +	 * @hpd_disable.
> > >>>>> +	 *
> > >>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> > >>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>> +	 */
> > >>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> > >>>>> +
> > >>>>> +	/**
> > >>>>> +	 * @hpd_disable:
> > >>>>> +	 *
> > >>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> > >>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > >>>>> +	 * connection status occurs.
> > >>>>> +	 *
> > >>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> > >>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>> +	 */
> > >>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >>>>>  };
> > >>>>>  
> > >>>>>  /**
> > >>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >>>>>  	bool dual_link;
> > >>>>>  };
> > >>>>>  
> > >>>>> +/**
> > >>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > >>>>> + */
> > >>>>> +enum drm_bridge_ops {
> > >>>>> +	/**
> > >>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > >>>>> +	 * its output. Bridges that set this flag shall implement the
> > >>>>> +	 * &drm_bridge_funcs->detect callback.
> > >>>>> +	 */
> > >>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > >>>>> +	/**
> > >>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > >>>>> +	 * connected to its output. Bridges that set this flag shall implement
> > >>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> > >>>>> +	 */
> > >>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> > >>>>> +	/**
> > >>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > >>>>> +	 * without requiring polling. Bridges that set this flag shall
> > >>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> > >>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > >>>>> +	 */
> > >>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> > >>>>> +	/**
> > >>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > >>>>> +	 * by the display at its output. This does not include readind EDID
> > >>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > >>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > >>>>> +	 */
> > >>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> > >>>>> +};
> > >>>>> +
> > >>>>>  /**
> > >>>>>   * struct drm_bridge - central DRM bridge control structure
> > >>>>>   */
> > >>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> > >>>>>  	const struct drm_bridge_funcs *funcs;
> > >>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> > >>>>>  	void *driver_private;
> > >>>>> +	/** @ops: bitmask of operations supported by the bridge */
> > >>>>> +	enum drm_bridge_ops ops;
> > >>>>> +	/**
> > >>>>> +	 * @type: Type of the connection at the bridge output
> > >>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > >>>>> +	 * identifies the type of connected display.
> > >>>>> +	 */
> > >>>>> +	int type;
> > >>>>> +	/** private: */
> > >>>>> +	/**
> > >>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > >>>>> +	 */
> > >>>>> +	struct mutex hpd_mutex;
> > >>>>> +	/**
> > >>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> > >>>>> +	 * drm_bridge_hpd_enable().
> > >>>>> +	 */
> > >>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > >>>>> +	/**
> > >>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > >>>>> +	 * @hpd_cb.
> > >>>>> +	 */
> > >>>>> +	void *hpd_data;
> > >>>>>  };
> > >>>>>  
> > >>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> > >>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>  			      struct drm_atomic_state *state);
> > >>>>>  
> > >>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>> +			   void (*cb)(void *data,
> > >>>>> +				      enum drm_connector_status status),
> > >>>>> +			   void *data);
> > >>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > >>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>> +			   enum drm_connector_status status);
> > >>>>> +
> > >>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >>>>>  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Laurent Pinchart Aug. 16, 2019, 11:30 p.m. UTC | #24

Hi Daniel,

On Wed, Aug 14, 2019 at 07:02:29PM +0200, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> >> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> >>> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> >>>> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> >>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>> Hi Laurent,
> >>>>>> 
> >>>>>> I like the approach, current practice when almost every bridge should
> >>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>> panel is very painful.
> >>>>> 
> >>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>> get a feeling for what your hpd_cb usually does.
> >>>>> 
> >>>>>> More comments inlined.
> >>>>>> 
> >>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>> data:
> >>>>>>>
> >>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>   retrieval operations
> >>>>>>> - Bitmask of supported operations
> >>>>>> 
> >>>>>> 
> >>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>> operation's callback?
> >>>>> 
> >>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>> add, generally good excuse to not have to think through the design between
> >>>>> different parts of drivers - "just" add another flag.
> >>>> 
> >>>> The reason is that a bridge may support an operation (as in implemented
> >>>> in the bridge hardware), but that operation may not be supported on a
> >>>> particular board. For instance an HDMI encoder may support reading EDID
> >>>> when the DDC lines are connected to the encoder, but a board may connect
> >>>> the DDC lines to an I2C port of the SoC. We thus need to decouple
> >>>> if a particular instance of the device supports the operation (exposed
> >>>> by the ops flags) from the function pointers.
> >>>> 
> >>>> We could of course allocate the drm_bridge_funcs structure dynamically
> >>>> for each bridge instance, and fill it with function pointers manually,
> >>>> leaving the unused ops always NULL, but that would require making the
> >>>> structure writable, which is considered a security issue. That's why I
> >>>> decided to keep the drm_bridge_funcs structure as a global static const
> >>>> structure, and add an ops bitmask.
> >>>> 
> >>>>>>> - Bridge output type
> >>>>>>>
> >>>>>>> Add and document these.
> >>>>>>>
> >>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>> bridges.
> >>>>>> 
> >>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>> right? More comments about it later.
> >>>> 
> >>>> No, the whole point is that they should not be chained at all. A bridge
> >>>> does not have to propagate, for instance, .get_edid() to the next
> >>>> bridge. That's one of the core design principles in this series, I want
> >>>> to keep the bridges as simple as possible, and move the complexity of
> >>>> the boilerplate code that is currently copied all around to helpers. See
> >>>> patch "drm: Add helper to create a connector for a chain of bridges" for
> >>>> more information about how this is used, with a helper that delegates
> >>>> the connector operations to the correct bridge in the chain based on the
> >>>> ops reported by each bridge.
> >>>> 
> >>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>> ---
> >>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>   */
> >>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>  {
> >>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>> +
> >>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>> +
> >>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>  }
> >>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>  
> >>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>  }
> >>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>  
> >>>>>>> +/**
> >>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>> + * @bridge: bridge control structure
> >>>>>>> + * @cb: hot-plug detection callback
> >>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>> + *
> >>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>> + *
> >>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>> + *
> >>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>> + * the bridge.
> >>>>>>> + */
> >>>>>> 
> >>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>> bridge attach:
> >>>>>> 
> >>>>>> bridge->hpd_cb = cb;
> >>>>>> 
> >>>>>> bridge->hpd_data = data;
> >>>>>> 
> >>>>>> ret = drm_bridge_attach(...);
> >>>>> 
> >>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>> than 1 callback registers on the same bridge hdp signal?
> >>>> 
> >>>> That's why I decided to hide hide HPD through helpers,
> >>>> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> >>>> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> >>>> current implementation is limited to a single listener, only the helpers
> >>>> would need to be changed to extend that to multiple listeners.
> >>>> 
> >>>> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> >>>> bridge to disable HPD detection when not used. Doing so keeps the bridge
> >>>> simple, it only needs to care about reporting HPD events when they're
> >>>> enabled, without caring who (if anyone) is listening, and gets clear
> >>>> instructions on whether to enable or disable the HPD hardware (in case
> >>>> it can be disabled).
> >>>> 
> >>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>> without big sacrifices.
> >>>>>> 
> >>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>> notifies about sink status change, how it translates to this cb?
> >>>> 
> >>>> This is something this series doesn't implement. I don't think it would
> >>>> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> >>>> here. If you can elaborate on what would be needed, I can implement
> >>>> that.
> >>>> 
> >>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>> +			   void (*cb)(void *data,
> >>>>>>> +				      enum drm_connector_status status),
> >>>>>>> +			   void *data)
> >>>>>>> +{
> >>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>> +		return;
> >>>>>>> +
> >>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>> +
> >>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>> +		goto unlock;
> >>>>>>> +
> >>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>> +	bridge->hpd_data = data;
> >>>>>>> +
> >>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>> +
> >>>>>>> +unlock:
> >>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>> +}
> >>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>> +
> >>>>>>> +/**
> >>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>> + * @bridge: bridge control structure
> >>>>>>> + *
> >>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>> + * output status change occurs.
> >>>>>>> + *
> >>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>> + */
> >>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>> +{
> >>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>> +		return;
> >>>>>>> +
> >>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>> +
> >>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>> +}
> >>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>> +
> >>>>>>> +/**
> >>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>> + * @bridge: bridge control structure
> >>>>>>> + * @status: output connection status
> >>>>>>> + *
> >>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>> + *
> >>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>> + */
> >>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>> +			   enum drm_connector_status status)
> >>>>>>> +{
> >>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>> +	if (bridge->hpd_cb)
> >>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>> 
> >>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>> 
> >>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>> 		if (tmp_bridge == bridge)
> >>>>> 			continue;
> >>>>> 		if (bridge->hpd_notify);
> >>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>> 	}
> >>>>> 
> >>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>> 
> >>>>> 	dev = bridge->dev
> >>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>> 
> >>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>> hpd they want/need.
> >>>> 
> >>>> I'll reply to this further down the mail thread, to address additional
> >>>> comments.
> >>>> 
> >>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>> +}
> >>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>> +
> >>>>>>>  #ifdef CONFIG_OF
> >>>>>>>  /**
> >>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>  
> >>>>>>> -#include <linux/list.h>
> >>>>>>>  #include <linux/ctype.h>
> >>>>>>> +#include <linux/list.h>
> >>>>>>> +#include <linux/mutex.h>
> >>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>  
> >>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>  	 */
> >>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @detect:
> >>>>>>> +	 *
> >>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>> +	 *
> >>>>>>> +	 * RETURNS:
> >>>>>>> +	 *
> >>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>> +	 */
> >>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @get_modes:
> >>>>>>> +	 *
> >>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>> +	 *
> >>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>> +	 *
> >>>>>>> +	 * RETURNS:
> >>>>>>> +	 *
> >>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>> +	 */
> >>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>> +			 struct drm_connector *connector);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @get_edid:
> >>>>>>> +	 *
> >>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>> +	 *
> >>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>> +	 *
> >>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>> +	 * output.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>> +	 *
> >>>>>>> +	 * RETURNS:
> >>>>>>> +	 *
> >>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>> +	 */
> >>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>> +				 struct drm_connector *connector);
> >>>>>> 
> >>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>> presence of another one?
> >>>>>> 
> >>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>> 
> >>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>> and connector->edid correctly.
> >>>> 
> >>>> I think that's doable, I'll have a look.
> >>> 
> >>> So I had a look, and while this is doable, it would essentially mean
> >>> that all bridges that retrieve modes from EDID would have to roll out
> >>> their own version of the following code:
> >>> 
> >>> static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> >>> 					       struct drm_bridge *bridge)
> >>> {
> >>> 	enum drm_connector_status status;
> >>> 	struct edid *edid;
> >>> 	int n;
> >>> 
> >>> 	status = drm_bridge_connector_detect(connector, false);
> >>> 	if (status != connector_status_connected)
> >>> 		goto no_edid;
> >>> 
> >>> 	edid = bridge->funcs->get_edid(bridge, connector);
> >>> 	if (!edid || !drm_edid_is_valid(edid)) {
> >>> 		kfree(edid);
> >>> 		goto no_edid;
> >>> 	}
> >>> 
> >>> 	drm_connector_update_edid_property(connector, edid);
> >>> 	n = drm_add_edid_modes(connector, edid);
> >>> 
> >>> 	kfree(edid);
> >>> 	return n;
> >>> 
> >>> no_edid:
> >>> 	drm_connector_update_edid_property(connector, NULL);
> >>> 	return 0;
> >>> }
> >>> 
> >>> Is this desired ?
> >> 
> >> We store the edid, and we store a lot of decoded information in
> >> drm_connector->display_info. Can't they just look there? Re-fetching the
> >> edid definitely sounds like the wrong thing to do.
> >> 
> >> We might run into some ordering issue here I guess with hotplugs and who's
> >> fetching the edid and everything like that.
> > 
> > That's exactly what I was about to answer after reading your first
> > paragraph :-) I believe caching EDID is a good idea, but my familiarity
> > with hotplug-related issues is limited to a handful of systems, and I'm
> > sure I'm missing some common problems. If you can tell me how you think
> > this should be done, I can give it a try.
> 
> I think all you need to do is make sure that when handling a hpd, the edid
> is fetched first. Before other parts of the bridge try to reconfigure
> themselves ...
> 
> >> Also maybe I'm missing the point here, and thinking too much of
> >> ->get_modes on the connector. But then I'm not clear on why the bridge
> >> needs the connector, and why it instead can't just return the edid it can
> >> read and let the caller/core figure out everything else?
> > 
> > That's exactly what the .get_edid() operation that you asked me to
> > remove did... :-) You didn't like the fact that it duplicated the
> > .get_modes() logic. Should I add it back, and clearly document
> > .get_modes() as a fallback used only when the connector doesn't use EDID
> > ?
> 
> I guess I'm making a bit a fool of myself here. What I meant is that if we
> do want to keep ->get_edid, then why do you need to pass the connector?
> Just return the edid blob, and let the caller parse it, and stuff all
> relevant data into drm_connector. Just thinking along the lines of your
> goal of making the bridge drivers as dumb as possible.
> 
> Same thing for ->get_modes would be neat too, but we don't have a nice
> datastructure for this. We'd need to pass both a list_head and a pointer
> to the drm_display_info I think.
> 
> That would decouple bridges even more from connector, which I think is
> somewhere on your goal list ...

So I had a look at that. We would need to remove the connector argument
from drm_do_get_edid(). The connector currently stores a few fields
related to EDID parsing:

        /**
         * @null_edid_counter: track sinks that give us all zeros for the EDID.
         * Needed to workaround some HW bugs where we get all 0s
         */
        int null_edid_counter;

        /** @bad_edid_counter: track sinks that give us an EDID with invalid checksum */
        unsigned bad_edid_counter;

        /**
         * @edid_corrupt: Indicates whether the last read EDID was corrupt. Used
         * in Displayport compliance testing - Displayport Link CTS Core 1.2
         * rev1.1 4.2.2.6
         */
        bool edid_corrupt;

We would need to decouple that from drm_connector. One option would be
to create a new drm_edid structure that would store those three fields,
as well as a struct edid, and return it from drm_do_get_edid() instead
of the raw struct edid. Would you prefer a different solution ? Do you
think that's a prerequisite to for this patch ?

> >>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>> in the connector is up-to-date? With your current callback design that's
> >>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>> correctly updated.
> >>>>> 
> >>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>> edid, which is not so awesome :-)
> >>>> 
> >>>> With the current design there's a single listener, so it's not a big
> >>>> deal :-) Furthermore, the listener is the helper that creates a
> >>>> connector on top of a chain of bridges, so it's a pretty good place to
> >>>> handle this. See the call to drm_kms_helper_hotplug_event() in
> >>>> drm_bridge_connector_hpd_cb().
> >>>> 
> >>>> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> >>>> big of a requirement as a prerequisite for this series (or as part of
> >>>> this series). We have hardware that can report HPD with various level of
> >>>> details (from "something happened on a connector" to "this particular
> >>>> event happened on this particular connector"), and we channel that
> >>>> through helpers such as drm_kms_helper_hotplug_event() that lose the
> >>>> details and go through a heavy mechanism to refetch everything. I
> >>>> understand this is needed in many cases, but I think there's room for
> >>>> improvement. This series, in my opinion, doesn't go in the wrong
> >>>> direction in that regard, as it eventually calls
> >>>> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> >>>> on top of it. I'm even willing to work on this, provided I get feedback
> >>>> on what is desired.
> >>>> 
> >>>>>>> +	/**
> >>>>>>> +	 * @lost_hotplug:
> >>>>>>> +	 *
> >>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>> +	 * HDMI bridges.
> >>>>>>> +	 */
> >>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_enable:
> >>>>>>> +	 *
> >>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>> +	 * @hpd_disable.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>> +	 */
> >>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>> +
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_disable:
> >>>>>>> +	 *
> >>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>> +	 * connection status occurs.
> >>>>>>> +	 *
> >>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>> +	 */
> >>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>  };
> >>>>>>>  
> >>>>>>>  /**
> >>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>  	bool dual_link;
> >>>>>>>  };
> >>>>>>>  
> >>>>>>> +/**
> >>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>> + */
> >>>>>>> +enum drm_bridge_ops {
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>> +	/**
> >>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>> +	 */
> >>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>> +};
> >>>>>>> +
> >>>>>>>  /**
> >>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>   */
> >>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>  	void *driver_private;
> >>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>> +	/**
> >>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>> +	 * identifies the type of connected display.
> >>>>>>> +	 */
> >>>>>>> +	int type;
> >>>>>>> +	/** private: */
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>> +	 */
> >>>>>>> +	struct mutex hpd_mutex;
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>> +	 */
> >>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>> +	/**
> >>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>> +	 * @hpd_cb.
> >>>>>>> +	 */
> >>>>>>> +	void *hpd_data;
> >>>>>>>  };
> >>>>>>>  
> >>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>  
> >>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>> +			   void (*cb)(void *data,
> >>>>>>> +				      enum drm_connector_status status),
> >>>>>>> +			   void *data);
> >>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>> +			   enum drm_connector_status status);
> >>>>>>> +
> >>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 17, 2019, 12:14 a.m. UTC | #25

Hi Daniel,

On Sat, Aug 17, 2019 at 02:30:08AM +0300, Laurent Pinchart wrote:
> On Wed, Aug 14, 2019 at 07:02:29PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> >> On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> >>> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> >>>> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> >>>>> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> >>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>> Hi Laurent,
> >>>>>>> 
> >>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>> panel is very painful.
> >>>>>> 
> >>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>> 
> >>>>>>> More comments inlined.
> >>>>>>> 
> >>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>> data:
> >>>>>>>>
> >>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>   retrieval operations
> >>>>>>>> - Bitmask of supported operations
> >>>>>>> 
> >>>>>>> 
> >>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>> operation's callback?
> >>>>>> 
> >>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>> add, generally good excuse to not have to think through the design between
> >>>>>> different parts of drivers - "just" add another flag.
> >>>>> 
> >>>>> The reason is that a bridge may support an operation (as in implemented
> >>>>> in the bridge hardware), but that operation may not be supported on a
> >>>>> particular board. For instance an HDMI encoder may support reading EDID
> >>>>> when the DDC lines are connected to the encoder, but a board may connect
> >>>>> the DDC lines to an I2C port of the SoC. We thus need to decouple
> >>>>> if a particular instance of the device supports the operation (exposed
> >>>>> by the ops flags) from the function pointers.
> >>>>> 
> >>>>> We could of course allocate the drm_bridge_funcs structure dynamically
> >>>>> for each bridge instance, and fill it with function pointers manually,
> >>>>> leaving the unused ops always NULL, but that would require making the
> >>>>> structure writable, which is considered a security issue. That's why I
> >>>>> decided to keep the drm_bridge_funcs structure as a global static const
> >>>>> structure, and add an ops bitmask.
> >>>>> 
> >>>>>>>> - Bridge output type
> >>>>>>>>
> >>>>>>>> Add and document these.
> >>>>>>>>
> >>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>> bridges.
> >>>>>>> 
> >>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>> right? More comments about it later.
> >>>>> 
> >>>>> No, the whole point is that they should not be chained at all. A bridge
> >>>>> does not have to propagate, for instance, .get_edid() to the next
> >>>>> bridge. That's one of the core design principles in this series, I want
> >>>>> to keep the bridges as simple as possible, and move the complexity of
> >>>>> the boilerplate code that is currently copied all around to helpers. See
> >>>>> patch "drm: Add helper to create a connector for a chain of bridges" for
> >>>>> more information about how this is used, with a helper that delegates
> >>>>> the connector operations to the correct bridge in the chain based on the
> >>>>> ops reported by each bridge.
> >>>>> 
> >>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>> ---
> >>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>
> >>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>   */
> >>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>  {
> >>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>> +
> >>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>> +
> >>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>  }
> >>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>  
> >>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>  }
> >>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>  
> >>>>>>>> +/**
> >>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>> + * @bridge: bridge control structure
> >>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>> + *
> >>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>> + *
> >>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>> + *
> >>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>> + * the bridge.
> >>>>>>>> + */
> >>>>>>> 
> >>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>> bridge attach:
> >>>>>>> 
> >>>>>>> bridge->hpd_cb = cb;
> >>>>>>> 
> >>>>>>> bridge->hpd_data = data;
> >>>>>>> 
> >>>>>>> ret = drm_bridge_attach(...);
> >>>>>> 
> >>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>> 
> >>>>> That's why I decided to hide hide HPD through helpers,
> >>>>> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> >>>>> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> >>>>> current implementation is limited to a single listener, only the helpers
> >>>>> would need to be changed to extend that to multiple listeners.
> >>>>> 
> >>>>> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> >>>>> bridge to disable HPD detection when not used. Doing so keeps the bridge
> >>>>> simple, it only needs to care about reporting HPD events when they're
> >>>>> enabled, without caring who (if anyone) is listening, and gets clear
> >>>>> instructions on whether to enable or disable the HPD hardware (in case
> >>>>> it can be disabled).
> >>>>> 
> >>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>> without big sacrifices.
> >>>>>>> 
> >>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>> 
> >>>>> This is something this series doesn't implement. I don't think it would
> >>>>> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> >>>>> here. If you can elaborate on what would be needed, I can implement
> >>>>> that.
> >>>>> 
> >>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>> +			   void *data)
> >>>>>>>> +{
> >>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>> +		return;
> >>>>>>>> +
> >>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>> +
> >>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>> +		goto unlock;
> >>>>>>>> +
> >>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>> +
> >>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>> +
> >>>>>>>> +unlock:
> >>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>> +}
> >>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>> +
> >>>>>>>> +/**
> >>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>> + * @bridge: bridge control structure
> >>>>>>>> + *
> >>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>> + * output status change occurs.
> >>>>>>>> + *
> >>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>> + */
> >>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>> +{
> >>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>> +		return;
> >>>>>>>> +
> >>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>> +
> >>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>> +}
> >>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>> +
> >>>>>>>> +/**
> >>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>> + * @bridge: bridge control structure
> >>>>>>>> + * @status: output connection status
> >>>>>>>> + *
> >>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>> + *
> >>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>> + */
> >>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>> +{
> >>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>> 
> >>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>> 
> >>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>> 		if (tmp_bridge == bridge)
> >>>>>> 			continue;
> >>>>>> 		if (bridge->hpd_notify);
> >>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>> 	}
> >>>>>> 
> >>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>> 
> >>>>>> 	dev = bridge->dev
> >>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>> 
> >>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>> hpd they want/need.
> >>>>> 
> >>>>> I'll reply to this further down the mail thread, to address additional
> >>>>> comments.
> >>>>> 
> >>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>> +}
> >>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>> +
> >>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>  /**
> >>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>  
> >>>>>>>> -#include <linux/list.h>
> >>>>>>>>  #include <linux/ctype.h>
> >>>>>>>> +#include <linux/list.h>
> >>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>  
> >>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>  	 */
> >>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>> +
> >>>>>>>> +	/**
> >>>>>>>> +	 * @detect:
> >>>>>>>> +	 *
> >>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>> +	 *
> >>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>> +	 *
> >>>>>>>> +	 * RETURNS:
> >>>>>>>> +	 *
> >>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>> +	 */
> >>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>> +
> >>>>>>>> +	/**
> >>>>>>>> +	 * @get_modes:
> >>>>>>>> +	 *
> >>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>> +	 *
> >>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>> +	 *
> >>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>> +	 *
> >>>>>>>> +	 * RETURNS:
> >>>>>>>> +	 *
> >>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>> +	 */
> >>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>> +
> >>>>>>>> +	/**
> >>>>>>>> +	 * @get_edid:
> >>>>>>>> +	 *
> >>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>> +	 *
> >>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>> +	 *
> >>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>> +	 * output.
> >>>>>>>> +	 *
> >>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>> +	 *
> >>>>>>>> +	 * RETURNS:
> >>>>>>>> +	 *
> >>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>> +	 */
> >>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>> +				 struct drm_connector *connector);
> >>>>>>> 
> >>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>> presence of another one?
> >>>>>>> 
> >>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>> 
> >>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>> and connector->edid correctly.
> >>>>> 
> >>>>> I think that's doable, I'll have a look.
> >>>> 
> >>>> So I had a look, and while this is doable, it would essentially mean
> >>>> that all bridges that retrieve modes from EDID would have to roll out
> >>>> their own version of the following code:
> >>>> 
> >>>> static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> >>>> 					       struct drm_bridge *bridge)
> >>>> {
> >>>> 	enum drm_connector_status status;
> >>>> 	struct edid *edid;
> >>>> 	int n;
> >>>> 
> >>>> 	status = drm_bridge_connector_detect(connector, false);
> >>>> 	if (status != connector_status_connected)
> >>>> 		goto no_edid;
> >>>> 
> >>>> 	edid = bridge->funcs->get_edid(bridge, connector);
> >>>> 	if (!edid || !drm_edid_is_valid(edid)) {
> >>>> 		kfree(edid);
> >>>> 		goto no_edid;
> >>>> 	}
> >>>> 
> >>>> 	drm_connector_update_edid_property(connector, edid);
> >>>> 	n = drm_add_edid_modes(connector, edid);
> >>>> 
> >>>> 	kfree(edid);
> >>>> 	return n;
> >>>> 
> >>>> no_edid:
> >>>> 	drm_connector_update_edid_property(connector, NULL);
> >>>> 	return 0;
> >>>> }
> >>>> 
> >>>> Is this desired ?
> >>> 
> >>> We store the edid, and we store a lot of decoded information in
> >>> drm_connector->display_info. Can't they just look there? Re-fetching the
> >>> edid definitely sounds like the wrong thing to do.
> >>> 
> >>> We might run into some ordering issue here I guess with hotplugs and who's
> >>> fetching the edid and everything like that.
> >> 
> >> That's exactly what I was about to answer after reading your first
> >> paragraph :-) I believe caching EDID is a good idea, but my familiarity
> >> with hotplug-related issues is limited to a handful of systems, and I'm
> >> sure I'm missing some common problems. If you can tell me how you think
> >> this should be done, I can give it a try.
> > 
> > I think all you need to do is make sure that when handling a hpd, the edid
> > is fetched first. Before other parts of the bridge try to reconfigure
> > themselves ...
> > 
> >>> Also maybe I'm missing the point here, and thinking too much of
> >>> ->get_modes on the connector. But then I'm not clear on why the bridge
> >>> needs the connector, and why it instead can't just return the edid it can
> >>> read and let the caller/core figure out everything else?
> >> 
> >> That's exactly what the .get_edid() operation that you asked me to
> >> remove did... :-) You didn't like the fact that it duplicated the
> >> .get_modes() logic. Should I add it back, and clearly document
> >> .get_modes() as a fallback used only when the connector doesn't use EDID
> >> ?
> > 
> > I guess I'm making a bit a fool of myself here. What I meant is that if we
> > do want to keep ->get_edid, then why do you need to pass the connector?
> > Just return the edid blob, and let the caller parse it, and stuff all
> > relevant data into drm_connector. Just thinking along the lines of your
> > goal of making the bridge drivers as dumb as possible.
> > 
> > Same thing for ->get_modes would be neat too, but we don't have a nice
> > datastructure for this. We'd need to pass both a list_head and a pointer
> > to the drm_display_info I think.
> > 
> > That would decouple bridges even more from connector, which I think is
> > somewhere on your goal list ...
> 
> So I had a look at that. We would need to remove the connector argument
> from drm_do_get_edid(). The connector currently stores a few fields
> related to EDID parsing:
> 
>         /**
>          * @null_edid_counter: track sinks that give us all zeros for the EDID.
>          * Needed to workaround some HW bugs where we get all 0s
>          */
>         int null_edid_counter;
> 
>         /** @bad_edid_counter: track sinks that give us an EDID with invalid checksum */
>         unsigned bad_edid_counter;
> 
>         /**
>          * @edid_corrupt: Indicates whether the last read EDID was corrupt. Used
>          * in Displayport compliance testing - Displayport Link CTS Core 1.2
>          * rev1.1 4.2.2.6
>          */
>         bool edid_corrupt;
> 
> We would need to decouple that from drm_connector. One option would be
> to create a new drm_edid structure that would store those three fields,
> as well as a struct edid, and return it from drm_do_get_edid() instead
> of the raw struct edid. Would you prefer a different solution ? Do you
> think that's a prerequisite to for this patch ?

The more I look at EDID parsing, the more it feels that we should
redesign the whole HPD and EDID get handling, and the more it becomes
out of scope for this patch series :-S EDID retrieval and extraction of
information from EDID is intertwined, for instance drm_get_edid()
performs the following:

struct edid *drm_get_edid(struct drm_connector *connector,
			  struct i2c_adapter *adapter)
{
	struct edid *edid;

	if (connector->force == DRM_FORCE_OFF)
		return NULL;

	if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter))
		return NULL;

	edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
	if (edid)
		drm_get_displayid(connector, edid);
	return edid;
}

I don't think the drm_get_displayid() call belongs there. Moving it to
the numerous callers of drm_get_edid() doesn't seem a good idea. Ideally
it should be done at the same time as populating the modes from EDID,
but I'm pretty sure that would break things, with not all EDID retrieval
resulting in modes updates.

A few drivers call drm_do_get_edid() directly, in order to provide a
custom EDID block read function, and they skip connector->force handling
and drm_get_displayid() as a result. In most case I assume that's a bug
that just went unnoticed.

Decoupling EDID read from drm_connector for bridges in a proper way seem
like a huge piece of work to me, and I really can't make it a
prerequisite for this patch.

> >>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>> correctly updated.
> >>>>>> 
> >>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>> edid, which is not so awesome :-)
> >>>>> 
> >>>>> With the current design there's a single listener, so it's not a big
> >>>>> deal :-) Furthermore, the listener is the helper that creates a
> >>>>> connector on top of a chain of bridges, so it's a pretty good place to
> >>>>> handle this. See the call to drm_kms_helper_hotplug_event() in
> >>>>> drm_bridge_connector_hpd_cb().
> >>>>> 
> >>>>> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> >>>>> big of a requirement as a prerequisite for this series (or as part of
> >>>>> this series). We have hardware that can report HPD with various level of
> >>>>> details (from "something happened on a connector" to "this particular
> >>>>> event happened on this particular connector"), and we channel that
> >>>>> through helpers such as drm_kms_helper_hotplug_event() that lose the
> >>>>> details and go through a heavy mechanism to refetch everything. I
> >>>>> understand this is needed in many cases, but I think there's room for
> >>>>> improvement. This series, in my opinion, doesn't go in the wrong
> >>>>> direction in that regard, as it eventually calls
> >>>>> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> >>>>> on top of it. I'm even willing to work on this, provided I get feedback
> >>>>> on what is desired.
> >>>>> 
> >>>>>>>> +	/**
> >>>>>>>> +	 * @lost_hotplug:
> >>>>>>>> +	 *
> >>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>> +	 *
> >>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>> +	 * HDMI bridges.
> >>>>>>>> +	 */
> >>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>> +
> >>>>>>>> +	/**
> >>>>>>>> +	 * @hpd_enable:
> >>>>>>>> +	 *
> >>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>> +	 * @hpd_disable.
> >>>>>>>> +	 *
> >>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>> +	 */
> >>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>> +
> >>>>>>>> +	/**
> >>>>>>>> +	 * @hpd_disable:
> >>>>>>>> +	 *
> >>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>> +	 * connection status occurs.
> >>>>>>>> +	 *
> >>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>> +	 */
> >>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>  };
> >>>>>>>>  
> >>>>>>>>  /**
> >>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>  	bool dual_link;
> >>>>>>>>  };
> >>>>>>>>  
> >>>>>>>> +/**
> >>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>> + */
> >>>>>>>> +enum drm_bridge_ops {
> >>>>>>>> +	/**
> >>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>> +	 */
> >>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>> +	/**
> >>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>> +	 */
> >>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>> +	/**
> >>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>> +	 */
> >>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>> +	/**
> >>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>> +	 */
> >>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>> +};
> >>>>>>>> +
> >>>>>>>>  /**
> >>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>   */
> >>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>  	void *driver_private;
> >>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>> +	/**
> >>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>> +	 */
> >>>>>>>> +	int type;
> >>>>>>>> +	/** private: */
> >>>>>>>> +	/**
> >>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>> +	 */
> >>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>> +	/**
> >>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>> +	 */
> >>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>> +	/**
> >>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>> +	 * @hpd_cb.
> >>>>>>>> +	 */
> >>>>>>>> +	void *hpd_data;
> >>>>>>>>  };
> >>>>>>>>  
> >>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>  
> >>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>> +			   void *data);
> >>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>> +
> >>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 19, 2019, 2:37 a.m. UTC | #26

Hi Daniel,

On Sat, Aug 17, 2019 at 03:14:56AM +0300, Laurent Pinchart wrote:
> On Sat, Aug 17, 2019 at 02:30:08AM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 14, 2019 at 07:02:29PM +0200, Daniel Vetter wrote:
> >> On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> >>> On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> >>>> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> >>>>> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> >>>>>> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> >>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>> Hi Laurent,
> >>>>>>>> 
> >>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>> panel is very painful.
> >>>>>>> 
> >>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>> 
> >>>>>>>> More comments inlined.
> >>>>>>>> 
> >>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>> data:
> >>>>>>>>>
> >>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>   retrieval operations
> >>>>>>>>> - Bitmask of supported operations
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>> operation's callback?
> >>>>>>> 
> >>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>> different parts of drivers - "just" add another flag.
> >>>>>> 
> >>>>>> The reason is that a bridge may support an operation (as in implemented
> >>>>>> in the bridge hardware), but that operation may not be supported on a
> >>>>>> particular board. For instance an HDMI encoder may support reading EDID
> >>>>>> when the DDC lines are connected to the encoder, but a board may connect
> >>>>>> the DDC lines to an I2C port of the SoC. We thus need to decouple
> >>>>>> if a particular instance of the device supports the operation (exposed
> >>>>>> by the ops flags) from the function pointers.
> >>>>>> 
> >>>>>> We could of course allocate the drm_bridge_funcs structure dynamically
> >>>>>> for each bridge instance, and fill it with function pointers manually,
> >>>>>> leaving the unused ops always NULL, but that would require making the
> >>>>>> structure writable, which is considered a security issue. That's why I
> >>>>>> decided to keep the drm_bridge_funcs structure as a global static const
> >>>>>> structure, and add an ops bitmask.
> >>>>>> 
> >>>>>>>>> - Bridge output type
> >>>>>>>>>
> >>>>>>>>> Add and document these.
> >>>>>>>>>
> >>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>> bridges.
> >>>>>>>> 
> >>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>> right? More comments about it later.
> >>>>>> 
> >>>>>> No, the whole point is that they should not be chained at all. A bridge
> >>>>>> does not have to propagate, for instance, .get_edid() to the next
> >>>>>> bridge. That's one of the core design principles in this series, I want
> >>>>>> to keep the bridges as simple as possible, and move the complexity of
> >>>>>> the boilerplate code that is currently copied all around to helpers. See
> >>>>>> patch "drm: Add helper to create a connector for a chain of bridges" for
> >>>>>> more information about how this is used, with a helper that delegates
> >>>>>> the connector operations to the correct bridge in the chain based on the
> >>>>>> ops reported by each bridge.
> >>>>>> 
> >>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>> ---
> >>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>   */
> >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>  {
> >>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>> +
> >>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>> +
> >>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>  }
> >>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>  
> >>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>  }
> >>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>  
> >>>>>>>>> +/**
> >>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>> + *
> >>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>> + *
> >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>> + *
> >>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>> + * the bridge.
> >>>>>>>>> + */
> >>>>>>>> 
> >>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>> bridge attach:
> >>>>>>>> 
> >>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>> 
> >>>>>>>> bridge->hpd_data = data;
> >>>>>>>> 
> >>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>> 
> >>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>> 
> >>>>>> That's why I decided to hide hide HPD through helpers,
> >>>>>> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> >>>>>> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> >>>>>> current implementation is limited to a single listener, only the helpers
> >>>>>> would need to be changed to extend that to multiple listeners.
> >>>>>> 
> >>>>>> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> >>>>>> bridge to disable HPD detection when not used. Doing so keeps the bridge
> >>>>>> simple, it only needs to care about reporting HPD events when they're
> >>>>>> enabled, without caring who (if anyone) is listening, and gets clear
> >>>>>> instructions on whether to enable or disable the HPD hardware (in case
> >>>>>> it can be disabled).
> >>>>>> 
> >>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>> without big sacrifices.
> >>>>>>>> 
> >>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>> 
> >>>>>> This is something this series doesn't implement. I don't think it would
> >>>>>> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> >>>>>> here. If you can elaborate on what would be needed, I can implement
> >>>>>> that.
> >>>>>> 
> >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>> +			   void *data)
> >>>>>>>>> +{
> >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>> +		return;
> >>>>>>>>> +
> >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>> +
> >>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>> +		goto unlock;
> >>>>>>>>> +
> >>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>> +
> >>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>> +
> >>>>>>>>> +unlock:
> >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>> +}
> >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>> + *
> >>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>> + * output status change occurs.
> >>>>>>>>> + *
> >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>> + */
> >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>> +{
> >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>> +		return;
> >>>>>>>>> +
> >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>> +
> >>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>> +}
> >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>> +
> >>>>>>>>> +/**
> >>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>> + * @status: output connection status
> >>>>>>>>> + *
> >>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>> + *
> >>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>> + */
> >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>> +{
> >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>> 
> >>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>> 
> >>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>> 			continue;
> >>>>>>> 		if (bridge->hpd_notify);
> >>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>> 	}
> >>>>>>> 
> >>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>> 
> >>>>>>> 	dev = bridge->dev
> >>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>> 
> >>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>> hpd they want/need.
> >>>>>> 
> >>>>>> I'll reply to this further down the mail thread, to address additional
> >>>>>> comments.
> >>>>>> 
> >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>> +}
> >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>> +
> >>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>  /**
> >>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>  
> >>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>> +#include <linux/list.h>
> >>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>  
> >>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>  	 */
> >>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @detect:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * RETURNS:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>> +	 */
> >>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @get_modes:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * RETURNS:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>> +	 */
> >>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @get_edid:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>> +	 * output.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * RETURNS:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>> +	 */
> >>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>> 
> >>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>> presence of another one?
> >>>>>>>> 
> >>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>> 
> >>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>> and connector->edid correctly.
> >>>>>> 
> >>>>>> I think that's doable, I'll have a look.
> >>>>> 
> >>>>> So I had a look, and while this is doable, it would essentially mean
> >>>>> that all bridges that retrieve modes from EDID would have to roll out
> >>>>> their own version of the following code:
> >>>>> 
> >>>>> static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> >>>>> 					       struct drm_bridge *bridge)
> >>>>> {
> >>>>> 	enum drm_connector_status status;
> >>>>> 	struct edid *edid;
> >>>>> 	int n;
> >>>>> 
> >>>>> 	status = drm_bridge_connector_detect(connector, false);
> >>>>> 	if (status != connector_status_connected)
> >>>>> 		goto no_edid;
> >>>>> 
> >>>>> 	edid = bridge->funcs->get_edid(bridge, connector);
> >>>>> 	if (!edid || !drm_edid_is_valid(edid)) {
> >>>>> 		kfree(edid);
> >>>>> 		goto no_edid;
> >>>>> 	}
> >>>>> 
> >>>>> 	drm_connector_update_edid_property(connector, edid);
> >>>>> 	n = drm_add_edid_modes(connector, edid);
> >>>>> 
> >>>>> 	kfree(edid);
> >>>>> 	return n;
> >>>>> 
> >>>>> no_edid:
> >>>>> 	drm_connector_update_edid_property(connector, NULL);
> >>>>> 	return 0;
> >>>>> }
> >>>>> 
> >>>>> Is this desired ?
> >>>> 
> >>>> We store the edid, and we store a lot of decoded information in
> >>>> drm_connector->display_info. Can't they just look there? Re-fetching the
> >>>> edid definitely sounds like the wrong thing to do.
> >>>> 
> >>>> We might run into some ordering issue here I guess with hotplugs and who's
> >>>> fetching the edid and everything like that.
> >>> 
> >>> That's exactly what I was about to answer after reading your first
> >>> paragraph :-) I believe caching EDID is a good idea, but my familiarity
> >>> with hotplug-related issues is limited to a handful of systems, and I'm
> >>> sure I'm missing some common problems. If you can tell me how you think
> >>> this should be done, I can give it a try.
> >> 
> >> I think all you need to do is make sure that when handling a hpd, the edid
> >> is fetched first. Before other parts of the bridge try to reconfigure
> >> themselves ...
> >> 
> >>>> Also maybe I'm missing the point here, and thinking too much of
> >>>> ->get_modes on the connector. But then I'm not clear on why the bridge
> >>>> needs the connector, and why it instead can't just return the edid it can
> >>>> read and let the caller/core figure out everything else?
> >>> 
> >>> That's exactly what the .get_edid() operation that you asked me to
> >>> remove did... :-) You didn't like the fact that it duplicated the
> >>> .get_modes() logic. Should I add it back, and clearly document
> >>> .get_modes() as a fallback used only when the connector doesn't use EDID
> >>> ?
> >> 
> >> I guess I'm making a bit a fool of myself here. What I meant is that if we
> >> do want to keep ->get_edid, then why do you need to pass the connector?
> >> Just return the edid blob, and let the caller parse it, and stuff all
> >> relevant data into drm_connector. Just thinking along the lines of your
> >> goal of making the bridge drivers as dumb as possible.
> >> 
> >> Same thing for ->get_modes would be neat too, but we don't have a nice
> >> datastructure for this. We'd need to pass both a list_head and a pointer
> >> to the drm_display_info I think.
> >> 
> >> That would decouple bridges even more from connector, which I think is
> >> somewhere on your goal list ...
> > 
> > So I had a look at that. We would need to remove the connector argument
> > from drm_do_get_edid(). The connector currently stores a few fields
> > related to EDID parsing:
> > 
> >         /**
> >          * @null_edid_counter: track sinks that give us all zeros for the EDID.
> >          * Needed to workaround some HW bugs where we get all 0s
> >          */
> >         int null_edid_counter;
> > 
> >         /** @bad_edid_counter: track sinks that give us an EDID with invalid checksum */
> >         unsigned bad_edid_counter;
> > 
> >         /**
> >          * @edid_corrupt: Indicates whether the last read EDID was corrupt. Used
> >          * in Displayport compliance testing - Displayport Link CTS Core 1.2
> >          * rev1.1 4.2.2.6
> >          */
> >         bool edid_corrupt;
> > 
> > We would need to decouple that from drm_connector. One option would be
> > to create a new drm_edid structure that would store those three fields,
> > as well as a struct edid, and return it from drm_do_get_edid() instead
> > of the raw struct edid. Would you prefer a different solution ? Do you
> > think that's a prerequisite to for this patch ?
> 
> The more I look at EDID parsing, the more it feels that we should
> redesign the whole HPD and EDID get handling, and the more it becomes
> out of scope for this patch series :-S EDID retrieval and extraction of
> information from EDID is intertwined, for instance drm_get_edid()
> performs the following:
> 
> struct edid *drm_get_edid(struct drm_connector *connector,
> 			  struct i2c_adapter *adapter)
> {
> 	struct edid *edid;
> 
> 	if (connector->force == DRM_FORCE_OFF)
> 		return NULL;
> 
> 	if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter))
> 		return NULL;
> 
> 	edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
> 	if (edid)
> 		drm_get_displayid(connector, edid);
> 	return edid;
> }
> 
> I don't think the drm_get_displayid() call belongs there. Moving it to
> the numerous callers of drm_get_edid() doesn't seem a good idea. Ideally
> it should be done at the same time as populating the modes from EDID,
> but I'm pretty sure that would break things, with not all EDID retrieval
> resulting in modes updates.
> 
> A few drivers call drm_do_get_edid() directly, in order to provide a
> custom EDID block read function, and they skip connector->force handling
> and drm_get_displayid() as a result. In most case I assume that's a bug
> that just went unnoticed.
> 
> Decoupling EDID read from drm_connector for bridges in a proper way seem
> like a huge piece of work to me, and I really can't make it a
> prerequisite for this patch.

I still gave it a try, and it resulted in

	git://linuxtv.org/pinchartl/media.git omapdrm/edid

Could you have a look at the last five patches in the branch ?

drm/edid: Reorganise the DisplayID parsing code
drm/edid: Move functions to avoid forward declaration
drm/edid: Move DisplayID tile parsing to drm_connector.c
drm/edid: Honour connector->force in drm_do_get_edid()
[WIP] drm/edid: Decouple EDID retrieval from connector

While the first four patches probably make sense and could be merged
independently of the last one, it's really the fifth patch that makes
decoupling of .get_edid() from drm_connector possible. And it's the
patch I'm the least happy with in this whole series :-S As written in
it's commit message, is it worth it ?

> >>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>> correctly updated.
> >>>>>>> 
> >>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>> edid, which is not so awesome :-)
> >>>>>> 
> >>>>>> With the current design there's a single listener, so it's not a big
> >>>>>> deal :-) Furthermore, the listener is the helper that creates a
> >>>>>> connector on top of a chain of bridges, so it's a pretty good place to
> >>>>>> handle this. See the call to drm_kms_helper_hotplug_event() in
> >>>>>> drm_bridge_connector_hpd_cb().
> >>>>>> 
> >>>>>> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> >>>>>> big of a requirement as a prerequisite for this series (or as part of
> >>>>>> this series). We have hardware that can report HPD with various level of
> >>>>>> details (from "something happened on a connector" to "this particular
> >>>>>> event happened on this particular connector"), and we channel that
> >>>>>> through helpers such as drm_kms_helper_hotplug_event() that lose the
> >>>>>> details and go through a heavy mechanism to refetch everything. I
> >>>>>> understand this is needed in many cases, but I think there's room for
> >>>>>> improvement. This series, in my opinion, doesn't go in the wrong
> >>>>>> direction in that regard, as it eventually calls
> >>>>>> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> >>>>>> on top of it. I'm even willing to work on this, provided I get feedback
> >>>>>> on what is desired.
> >>>>>> 
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>> +
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>> +	 * connection status occurs.
> >>>>>>>>> +	 *
> >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>  };
> >>>>>>>>>  
> >>>>>>>>>  /**
> >>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>  	bool dual_link;
> >>>>>>>>>  };
> >>>>>>>>>  
> >>>>>>>>> +/**
> >>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>> + */
> >>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>> +	 */
> >>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>> +};
> >>>>>>>>> +
> >>>>>>>>>  /**
> >>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>   */
> >>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>  	void *driver_private;
> >>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>> +	 */
> >>>>>>>>> +	int type;
> >>>>>>>>> +	/** private: */
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>> +	 */
> >>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>> +	 */
> >>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>> +	/**
> >>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>> +	 */
> >>>>>>>>> +	void *hpd_data;
> >>>>>>>>>  };
> >>>>>>>>>  
> >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>  
> >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>> +			   void *data);
> >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>> +
> >>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>  					u32 connector_type);

Andrzej Hajda Aug. 19, 2019, 8:38 a.m. UTC | #27

On 14.08.2019 14:40, Daniel Vetter wrote:
> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
>> Hi Andrzej,
>>
>> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
>>> Hi Laurent,
>>>
>>> Sorry for late response.
>> No worries.
>>
>>> On 11.08.2019 00:43, Laurent Pinchart wrote:
>>>> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
>>>>> On 08.08.2019 21:32, Laurent Pinchart wrote:
>>>>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
>>>>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
>>>>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
>>>>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
>>>>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>>>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>>>> Hi Laurent,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
>>>>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>>>>>>>>>>> panel is very painful.
>>>>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> More comments inlined.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>>>>>>>>>>> data:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>>>>>>>>>>   retrieval operations
>>>>>>>>>>>>>>>> - Bitmask of supported operations
>>>>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>>>>>>>>>>> operation's callback?
>>>>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>>>>>>>>>>> add, generally good excuse to not have to think through the design between
>>>>>>>>>>>>>> different parts of drivers - "just" add another flag.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> - Bridge output type
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Add and document these.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>>>>>>>>>>> bridges.
>>>>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>>>>>>>>>>> right? More comments about it later.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>>>>>>>>>>   */
>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>  {
>>>>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>> + * @cb: hot-plug detection callback
>>>>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>>>>>>>>>>> + * the bridge.
>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>>>>>>>>>>> bridge attach:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> bridge->hpd_cb = cb;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> bridge->hpd_data = data;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ret = drm_bridge_attach(...);
>>>>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>>>>>>>>>>> without big sacrifices.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>>>>> +			   void *data)
>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>>>>>>>>>>> +		goto unlock;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>>>>>>>>>>> +	bridge->hpd_data = data;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +unlock:
>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>>>>>>>>>>> + * output status change occurs.
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>> + * @status: output connection status
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>> +			   enum drm_connector_status status)
>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +	if (bridge->hpd_cb)
>>>>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>>>>>>>>>>> 		if (tmp_bridge == bridge)
>>>>>>>>>>>>>> 			continue;
>>>>>>>>>>>>>> 		if (bridge->hpd_notify);
>>>>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>>>>>>>>>>> 	}
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 	dev = bridge->dev
>>>>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>>>>>>>>>>> hpd they want/need.
>>>>>>>>>>>>> As I understand you want to notify every member of the pipeline.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it should be enough to notify only the source, and then source
>>>>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It looks more generic for me.
>>>>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>>>>>>>>>>> the one from Laurent? Kinda confused here.
>>>>>>>>>>> Regarding general idea:
>>>>>>>>>>>
>>>>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
>>>>>>>>>>> source.
>>>>>>>>>>>
>>>>>>>>>>> 2. Your is to notify all other bridges and encoder.
>>>>>>>>>>>
>>>>>>>>>>> And I prefer 1st approach, why:
>>>>>>>>>>>
>>>>>>>>>>> - the source can decide if/when and to who propagate the signal,
>>>>>>>>>>>
>>>>>>>>>>> - is more generic, for example if bridge send signal to two
>>>>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
>>>>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
>>>>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
>>>>>>>>> If there will be two consumers, there will be two bridge attachments,
>>>>>>>>> thus there will be two notifications, it should work.
>>>>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
>>>>>>>> callback is registered on the produce bridge, not on the consumer bridge
>>>>>>>> (or I'm totallly misreading what Laurent does here).
>>>>>>> I have assumed that if devices exposes two hardware sink interfaces it
>>>>>>> will expose two separate bridges - of course it will not work with
>>>>>>> "bridge chaining" thing, but this is a different story.
>>>>>> Daniel is right that the current implementation only allows one
>>>>>> consumer. This is however not a limitation of the API, but of its
>>>>>> implementation, as I only needed a single consumer. The helpers in this
>>>>>> series ensure that neither the consumer nor the producer poke in the
>>>>>> drm_bridge structure to call back to the HPD handler:
>>>>>>
>>>>>> - The consumer calls drm_bridge_hpd_enable() and
>>>>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
>>>>>>   behaviour if desired without changes to the consumer.
>>>>>>
>>>>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
>>>>>>   which could also easily accommodate reference-counting in the drm
>>>>>>   bridge core without changes to the producer.
>>>>>>
>>>>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
>>>>>>   easily be extended to support multiple consumers without changes to
>>>>>>   the producer.
>>>>>>
>>>>>> This is actually my second version of the HPD mechanism. The first
>>>>>> version was never posted, poked into drm_bridge, and required the
>>>>>> producer to be aware of the callbacks. After discussing this privately
>>>>>> with Daniel, I came up with the implementation in this series that,
>>>>>> while not supporting multiple consumers now, makes it easy to extend
>>>>>> later without minimal effort.
>>>>>>
>>>>>> Daniel's proposed implementation above looks reasonable to me, provided
>>>>>> we can iterate over the bridges in an order that don't depend on the
>>>>>> position of the producer in the chain (should be easy to solve by
>>>>>> starting at the encoder for instance). It however looks a bit like a
>>>>>> midlayer to me :-) That's why I have a similar implementation in the
>>>>>> connector-bridge helper, which could be extended to call
>>>>>> encoder->helper_private->bridge_hpd_notify() and
>>>>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
>>>>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
>>>>>> drm_bridge_hpd_notify() would on the other hand set the notification
>>>>>> sequence towards the encoder and driver in stone. Daniel, do you think
>>>>>> that would be better ?
>>>>>>
>>>>>> I would like to remind everybody that this series isn't the last I will
>>>>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
>>>>>> open to suggestions, and can address problems on top of these patches,
>>>>>> provided obviously that this series doesn't go in the wrong direction.
>>>>>> I'm of course also willing to rework this series, but given the amount
>>>>>> of work we have in the drm_bridge realm, I can't fix everything in one
>>>>>> go :-)
>>>>>>
>>>>>>>>>>> - it resembles hardware wires :)
>>>>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
>>>>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
>>>>>>>>>> interested in that hpd singal. This includes:
>>>>>>>>>> - Other bridges, e.g. if they provide CEC support.
>>>>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
>>>>>>>>>> - Overall driver, so it can update the modes/connector status and send the
>>>>>>>>>>   uevent to the driver.
>>>>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
>>>>>>>>>>   shut down/re-enable the pipe because $reasons.
>>>>>>>>>>  
>>>>>>>>>> That's at least my understanding from lots of chats with Laurent about
>>>>>>>>>> what he wants to do here.
>>>>>> That's correct, and that's what I was trying to implement :-) The
>>>>>> notification, in this patch series, goes from the producer bridge to a
>>>>>> central place (namely the connector, with a helper implementation
>>>>>> available as part of this series, but custom implementations in display
>>>>>> drivers are fine if needed) that then dispatches the notification to all
>>>>>> bridges (through the .lost_hotplug() operation, which we could replace
>>>>>> by an .hpd_notify() operation) for the first two purposes listed above,
>>>>>> and then to the overall driver. The only thing I don't support yet is
>>>>>> dispatching to the display pipeline (item 4 in the list above) as I had
>>>>>> no need for that, and didn't want to develop an API with no user. This
>>>>>> would however not be difficult to do when needed, the need is taken into
>>>>>> account in the proposed implementation.
>>>>>>
>>>>>>>>> I do not know the full picture, but the solution where particular bridge
>>>>>>>>> notifies everything unconditionally seems to me much less flexible.
>>>>>>>>>
>>>>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
>>>>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
>>>>>>>>> will mimic your scenario.
>>>>>>>>>
>>>>>>>>> But there are also other scenarios where bridge does not want to
>>>>>>>>> propagate signal, because for example:
>>>>>>>>>
>>>>>>>>> - it wants to wait for other sinks to wake up,
>>>>>>>>>
>>>>>>>> The other sink can just do that in their hpd callback.
>>>>>>>>
>>>>>>>>> - it propagates HPD signal via hardware wire,
>>>>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
>>>>>>>> the wire/hw hpd interrupt.
>>>>>>>>
>>>>>>> If it should ignore HPD, why it should receive it at all - it is
>>>>>>> unnecessary noise. And I am afraid with more complicated pipelines it
>>>>>>> will be impossible for particular component (bridge/encoder/whatever) to
>>>>>>> distinguish if HPD notification which came from non-directly connected
>>>>>>> component should be ignored or not.
>>>>>>>
>>>>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
>>>>>>>>> device.
>>>>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
>>>>>>>> board?
>>>>>>> Bridge can have external connectors, and the user can connect there
>>>>>>> anything.
>>>>>>>
>>>>>>>>> In general HPD is input signal for notify of state changes on particular
>>>>>>>>> bus, in case of typical video bridge on its output video bus.
>>>>>>>>>
>>>>>>>>> In case of bridges they have also input video buses, and they can send
>>>>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
>>>>>>>>> if for most cases they looks similar.
>>>>>>>> Ah, I think this is a problem we will eventually have. But it's not
>>>>>>>> something we're currently solving here at all I think.
>>>>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
>>>>>>> line, so this is not something from far future. And I guess with HPD
>>>>>>> broadcasting it could be racy/error prone, for example EDID reading can
>>>>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
>>>>>>> controller via hw wires also).
>>>>>>>
>>>>>>>>>>> And regarding implementation:
>>>>>>>>>>>
>>>>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>>>>>>>>>>
>>>>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>>>>>>>>>>
>>>>>>>>>>> Your proposition is more straightforward, but if we want to notify only
>>>>>>>>>>> source we should locate it by parsing notification chain (what about
>>>>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
>>>>>>>>>>>
>>>>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
>>>>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
>>>>>>>>>> Uh I think we're not talking about the same thing really. My understanding
>>>>>>>>>> is that this callback is if someone (outside of this bridge) is interested
>>>>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
>>>>>>>>>> listener.
>>>>>>>>> Do we have real life examples?
>>>>>>>>>
>>>>>>>>> I want to distinguish two situations:
>>>>>>>>>
>>>>>>>>> - another device wants to know if input bus of the bridge has changed state,
>>>>>>>>>
>>>>>>>>> - another device wants to know if output bus of the bridge has changed
>>>>>>>>> state.
>>>>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
>>>>>>>> bridges can exchange state and information about each another. hpd is
>>>>>>>> about the physical world, i.e. "is there a cable plugged into the port
>>>>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
>>>>>>>> fun stuff like that, we have the atomic_check machinery for this.
>>>>>>> My question was if we have real examples that upstream device requires
>>>>>>> knowledge about state of output line of the bridge?
>>>>>>>
>>>>>>> To be more precise, we have following display pipeline:
>>>>>>>
>>>>>>> A-->B-->C
>>>>>>>
>>>>>>> And C sends HPD to B (ie signal that state of line between B and C
>>>>>>> changed). Does A really wants to know this information? or it should
>>>>>>> just need to know if state of line A-->B changed?
>>>>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
>>>>>> ESD protector and level shifter, and C is the physical HDMI connector.
>>>>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
>>>>>> be notified in order to reset the CEC state machine. One could however
>>>>>> argue that in that case the A-B link state changes too, but the
>>>>>> important part is that HPD detection is not performed by A, while A
>>>>>> needs to be informed of lost hotplug.
>>>>> I have no full picture but I guess in this case C sends HPD to B using
>>>>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
>>>>> say that B does not participate in HPD transmission/forwarding,
>>>> No, in this case A doesn't receive any hardware HPD signal, it requires
>>>> HPD notification through software.
>>>>
>>>>> some shifters with 'advanced power saving' can even perform wake-up of
>>>>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
>>>>> to A is indeed different than HPD sent from C to B.
>>>>>
>>>>> Btw, with the above logic of propagation of HPD callback (proposed by
>>>>> Daniel) I guess it will work this way:
>>>>>
>>>>> - A will receive HPD signal via HW,
>>>>>
>>>>> - then B and C will receive HPD callback via framework.
>>>>>
>>>>> Am I right?
>>>> It's the other way around.
>>>>
>>>> In this case the HPD signal from the connector (C) is routed to an input
>>>> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
>>>> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
>>>> IRQ and receive the hardware HPD notification. The driver for the HDMI
>>>> encoder (A) needs to receive HPD notification in software, through the
>>>> framework.
>>> If this is GPIO I wonder why do not query this gpio by encoder directly,
>>> rules of ownership of such gpios seems to be grey area, so in such case
>>> I would advise to put it in the driver who really needs it.
>>>
>>> This way it will be much simpler.
>> First to fall, multiple drivers may need to be informed of HPD events
>> coming from a GPIO, so we would need to duplicate it in multiple places,
>> and I don't think the GPIO framework allows acquiring a GPIO multiple
>> times.
>>
>> Then, the GPIO is described in DT, and DT doesn't care about which
>> driver needs HPD events. DT specifies the GPIO in the node of the device
>> it belongs to, this is defined in DT bindings, and must be the same on
>> all boards, while depending on the board different devices may need to
>> be informed of HPD events.
>>
>> For those two reasons HPD GPIO handling and consumption of HPD events
>> can't always be grouped in the same driver.
>>
>>> Going back to HPD notifications, as I said earlier broadcasting HPD
>>> notification unconditionally to every member of the chain with hope that
>>> the member will be able to filter-out undesired notification seems to me
>>> incorrect - maybe it can solve some problems but is not flexible enough
>>> to be usable in other scenarios.
>>>
>>> If my arguments do not convince you please just continue with your
>>> ideas, we can always add NO_HPD_BROADCAST somewhere :)
>> :-) I would like to understand the problems you're referring to though,
>> and hopefully solve them. If you could describe one of the scenarios
>> where you think this mechanism wouldn't be usable that would help. In
>> the meantime I will post a new version of the series with these
>> operations kept as-is to get the rest of the patches reviewed.
> See my little thing about midlayers, I think midlayers with lots of flags
> for everything aren't a good idea. They should be more opinionated about
> how things work.
>
> So if there's a case where this broadcasting of various things doesn't
> work, let's dig into it.
> -Daniel


OK, almost real life example:

A -> B -> C

A - RGB/HDMI converter,

B - HDMI/MHL converter,

C - uUSB controller (MUIC).


C - detects presence of MHL sink and routes MHL lines to B in such case.

B - has no hardware logic to detect HPD, but it's firmware can read EDID
from downstream component via HW lines and it has hardware lines to
upstream component to send EDID,

A - can read EDID from B via hardware lines, but does not have hardware HPD.


So how it should work (according to specification):

1. C detects MHL sink.

2. C switches his mux to route lines to B.

3. C sends HPD notification to B.

4. B powers on, its firmware reads EDID from downstream lines (possibly
adjusting it) and makes it available to upstream component A.

5. B sends HPD notification to A.


I do not know how it could work with HPD broadcasting.

I guess C should be HPD provider, but in case of HPD broadcasting A and
B would receive notification in the same time, as a result A would start
reading EDID too early - fail.


Regards

Andrzej


>
>>>>>>>>>> You seem to have some other idea here.
>>>>>>>>>>
>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>  #ifdef CONFIG_OF
>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> -#include <linux/list.h>
>>>>>>>>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>>>>>>>>> +#include <linux/list.h>
>>>>>>>>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>>>>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>>>>>>>>>>  	 */
>>>>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @detect:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @get_modes:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>> +			 struct drm_connector *connector);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @get_edid:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>>>>>>>>>>> +	 * output.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>> +				 struct drm_connector *connector);
>>>>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>>>>>>>>>>> presence of another one?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>>>>>>>>>>> and connector->edid correctly.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
>>>>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>>>>>>>>>>> correctly updated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>>>>>>>>>>> edid, which is not so awesome :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @lost_hotplug:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>>>>>>>>>>> +	 * HDMI bridges.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @hpd_enable:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>>>>>>>>>>> +	 * @hpd_disable.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @hpd_disable:
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>>>>>>>>>>> +	 * connection status occurs.
>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>>>>>>>>>>  	bool dual_link;
>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>> +enum drm_bridge_ops {
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>>>>>>>>>>   */
>>>>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>>>>>>>>>>  	void *driver_private;
>>>>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>>>>>>>>>>> +	 * identifies the type of connected display.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	int type;
>>>>>>>>>>>>>>>> +	/** private: */
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	struct mutex hpd_mutex;
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>>>>>>>>>>> +	 * @hpd_cb.
>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>> +	void *hpd_data;
>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>>>>> +			   void *data);
>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>> +			   enum drm_connector_status status);
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>>>>>>>>>>  					u32 connector_type);
>> -- 
>> Regards,
>>
>> Laurent Pinchart

Laurent Pinchart Aug. 19, 2019, 10:32 p.m. UTC | #28

Hi Daniel,

On Wed, Aug 14, 2019 at 02:35:10PM +0200, Daniel Vetter wrote:
> On Thu, Aug 08, 2019 at 10:32:14PM +0300, Laurent Pinchart wrote:
> > On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>> Hi Laurent,
> >>>>>>>>>>
> >>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>> panel is very painful.
> >>>>>>>>>
> >>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>
> >>>>>>>>>> More comments inlined.
> >>>>>>>>>>
> >>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>> data:
> >>>>>>>>>>>
> >>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>   retrieval operations
> >>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>
> >>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>> operation's callback?
> >>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>
> >>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>
> >>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>
> >>>>>>>>>>> Add and document these.
> >>>>>>>>>>>
> >>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>> bridges.
> >>>>>>>>>>
> >>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>> ---
> >>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>   */
> >>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>  {
> >>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>> +
> >>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>  }
> >>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>  
> >>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>  }
> >>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>  
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>> + * the bridge.
> >>>>>>>>>>> + */
> >>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>> bridge attach:
> >>>>>>>>>>
> >>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>
> >>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>
> >>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>
> >>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>
> >>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>> without big sacrifices.
> >>>>>>>>>>
> >>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>
> >>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>> +			   void *data)
> >>>>>>>>>>> +{
> >>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>> +		return;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +unlock:
> >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>> +
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>> + */
> >>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>> +{
> >>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>> +		return;
> >>>>>>>>>>> +
> >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>> +
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>> + */
> >>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>> +{
> >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>
> >>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>
> >>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>> 			continue;
> >>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>> 	}
> >>>>>>>>>
> >>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>
> >>>>>>>>> 	dev = bridge->dev
> >>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>
> >>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>> hpd they want/need.
> >>>>>>>>
> >>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>
> >>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>
> >>>>>>>> It looks more generic for me.
> >>>>>>>
> >>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>
> >>>>>> Regarding general idea:
> >>>>>>
> >>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>> source.
> >>>>>>
> >>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>
> >>>>>> And I prefer 1st approach, why:
> >>>>>>
> >>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>
> >>>>>> - is more generic, for example if bridge send signal to two
> >>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>
> >>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>
> >>>> If there will be two consumers, there will be two bridge attachments,
> >>>> thus there will be two notifications, it should work.
> >>>
> >>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>> callback is registered on the produce bridge, not on the consumer bridge
> >>> (or I'm totallly misreading what Laurent does here).
> >> 
> >> I have assumed that if devices exposes two hardware sink interfaces it
> >> will expose two separate bridges - of course it will not work with
> >> "bridge chaining" thing, but this is a different story.
> > 
> > Daniel is right that the current implementation only allows one
> > consumer. This is however not a limitation of the API, but of its
> > implementation, as I only needed a single consumer. The helpers in this
> > series ensure that neither the consumer nor the producer poke in the
> > drm_bridge structure to call back to the HPD handler:
> > 
> > - The consumer calls drm_bridge_hpd_enable() and
> >   drm_bridge_hpd_disable(), which could offer a reference-counted
> >   behaviour if desired without changes to the consumer.
> > 
> > - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >   which could also easily accommodate reference-counting in the drm
> >   bridge core without changes to the producer.
> > 
> > - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >   easily be extended to support multiple consumers without changes to
> >   the producer.
> > 
> > This is actually my second version of the HPD mechanism. The first
> > version was never posted, poked into drm_bridge, and required the
> > producer to be aware of the callbacks. After discussing this privately
> > with Daniel, I came up with the implementation in this series that,
> > while not supporting multiple consumers now, makes it easy to extend
> > later without minimal effort.
> > 
> > Daniel's proposed implementation above looks reasonable to me, provided
> > we can iterate over the bridges in an order that don't depend on the
> > position of the producer in the chain (should be easy to solve by
> > starting at the encoder for instance). It however looks a bit like a
> > midlayer to me :-) That's why I have a similar implementation in the
> > connector-bridge helper, which could be extended to call
> > encoder->helper_private->bridge_hpd_notify() and
> > dev->mode_config.helper_private->bridge_hpd_notify() instead of
> > hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> > drm_bridge_hpd_notify() would on the other hand set the notification
> > sequence towards the encoder and driver in stone. Daniel, do you think
> > that would be better ?
> 
> So the difference between the midlayer and the helper is that the helper
> can be ignored. Which the above still can:
> 
> - producer can choose to not call that function
> - consumer can choose not to have the callback
> 
> Now great helpers allow you to ignore only parts of them, so that you can
> mix&match. Which again I think with the bridge stuff we're discussing here
> is assured.

That's a bit difficult for the first part, as if the producer doesn't
notify of HPD events, consumers won't be able to get them :-) The second
part, consumers not having the callback, is already supported.

> So the final bit is how opinionated a helper can be, and imo it can be
> very opinionated and strict and inflexible. That means it won't be useful
> for every possible case, but those can be handled by simply not using the
> helper (or that part of the helpers). Examples
> 
> - simple display pipe is very opinionated, but trades that in for being
>   very useful for really simple displays
> 
> - similar with atomic helpers, there's a very strong suggestion that "if
>   it doesn't fit, write your own commit_tail()"

(On a side note, doing so is quite complex, and I understand why nobody
wants to really ditch the atomic helpers)

> And I think bridge helpers probably also need fairly opinioated, simply to
> make sure that all the bridge drivers work together in a coherent fashion.
> If we allow too much flexibility everyone bends the rules a bit, and
> nothing fits.

I agree with you on that.

> Wrt your question: One option would be to do the same thing like shared
> interrupt line handlers. As soon as the first interrupt handler says "I'
> ve handled this one" we stop processing. But that might lead to more
> confusion about who's responsible for an interrupt.

I don't think that's a good idea, as more than one consumer may need to
process the event. A real life example with two consumers would be a CEC
controller part of a bridge needing to get informed about HDMI
plug/unplug to set the CEC address in the device (this notification is
handled through the bridge notification operation), and the display
driver needing to report HPD to the DRM core.

As I'm still not sure why you think I should replace the existing
implementation with your above proposal, so I'll keep the existing code
for the v2 that I will post soon until we complete this discussion.

To hopefully help with the discussion, I would like to repeat my main
argument : moving the dispatching of the notification to
drm_bridge_hpd_notify() sets the order in which components (bridges,
encoders, drivers) are notified in stone, while keeping it in the
drm_bridge_connector helper allows drivers to not use the helper and
come up with a different implementation that fits their needs better.

> > I would like to remind everybody that this series isn't the last I will
> > ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> > open to suggestions, and can address problems on top of these patches,
> > provided obviously that this series doesn't go in the wrong direction.
> > I'm of course also willing to rework this series, but given the amount
> > of work we have in the drm_bridge realm, I can't fix everything in one
> > go :-)
> > 
> >>>>>> - it resembles hardware wires :)
> >>>>>
> >>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>> interested in that hpd singal. This includes:
> >>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>   uevent to the driver.
> >>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>  
> >>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>> what he wants to do here.
> > 
> > That's correct, and that's what I was trying to implement :-) The
> > notification, in this patch series, goes from the producer bridge to a
> > central place (namely the connector, with a helper implementation
> > available as part of this series, but custom implementations in display
> > drivers are fine if needed) that then dispatches the notification to all
> > bridges (through the .lost_hotplug() operation, which we could replace
> > by an .hpd_notify() operation) for the first two purposes listed above,
> > and then to the overall driver. The only thing I don't support yet is
> > dispatching to the display pipeline (item 4 in the list above) as I had
> > no need for that, and didn't want to develop an API with no user. This
> > would however not be difficult to do when needed, the need is taken into
> > account in the proposed implementation.
> > 
> >>>> I do not know the full picture, but the solution where particular bridge
> >>>> notifies everything unconditionally seems to me much less flexible.
> >>>>
> >>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>> will mimic your scenario.
> >>>>
> >>>> But there are also other scenarios where bridge does not want to
> >>>> propagate signal, because for example:
> >>>>
> >>>> - it wants to wait for other sinks to wake up,
> >>>
> >>> The other sink can just do that in their hpd callback.
> >>>
> >>>> - it propagates HPD signal via hardware wire,
> >>>
> >>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>> the wire/hw hpd interrupt.
> >> 
> >> If it should ignore HPD, why it should receive it at all - it is
> >> unnecessary noise. And I am afraid with more complicated pipelines it
> >> will be impossible for particular component (bridge/encoder/whatever) to
> >> distinguish if HPD notification which came from non-directly connected
> >> component should be ignored or not.
> >> 
> >>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>> device.
> >>>
> >>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>> board?
> >> 
> >> Bridge can have external connectors, and the user can connect there
> >> anything.
> >> 
> >>>> In general HPD is input signal for notify of state changes on particular
> >>>> bus, in case of typical video bridge on its output video bus.
> >>>>
> >>>> In case of bridges they have also input video buses, and they can send
> >>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>> if for most cases they looks similar.
> >>>
> >>> Ah, I think this is a problem we will eventually have. But it's not
> >>> something we're currently solving here at all I think.
> >> 
> >> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >> line, so this is not something from far future. And I guess with HPD
> >> broadcasting it could be racy/error prone, for example EDID reading can
> >> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >> controller via hw wires also).
> >> 
> >>>>>> And regarding implementation:
> >>>>>>
> >>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>
> >>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>
> >>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>> source we should locate it by parsing notification chain (what about
> >>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>
> >>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>
> >>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>> listener.
> >>>>
> >>>> Do we have real life examples?
> >>>>
> >>>> I want to distinguish two situations:
> >>>>
> >>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>
> >>>> - another device wants to know if output bus of the bridge has changed
> >>>> state.
> >>>
> >>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>> bridges can exchange state and information about each another. hpd is
> >>> about the physical world, i.e. "is there a cable plugged into the port
> >>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>> fun stuff like that, we have the atomic_check machinery for this.
> >> 
> >> My question was if we have real examples that upstream device requires
> >> knowledge about state of output line of the bridge?
> >> 
> >> To be more precise, we have following display pipeline:
> >> 
> >> A-->B-->C
> >> 
> >> And C sends HPD to B (ie signal that state of line between B and C
> >> changed). Does A really wants to know this information? or it should
> >> just need to know if state of line A-->B changed?
> > 
> > There's one real life example, where A is an HDMI encoder, B is an HDMI
> > ESD protector and level shifter, and C is the physical HDMI connector.
> > When the HDMI cable is unplugged, the CEC controller part of A needs to
> > be notified in order to reset the CEC state machine. One could however
> > argue that in that case the A-B link state changes too, but the
> > important part is that HPD detection is not performed by A, while A
> > needs to be informed of lost hotplug.
> > 
> >>>>> You seem to have some other idea here.
> >>>>>
> >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>> +}
> >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>> +
> >>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>  /**
> >>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>  
> >>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>  
> >>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>  	 */
> >>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>> +	 * output.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>> presence of another one?
> >>>>>>>>>>
> >>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>> and connector->edid correctly.
> >>>>>>>>>
> >>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>> correctly updated.
> >>>>>>>>>
> >>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>> +
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>> +	 *
> >>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>  };
> >>>>>>>>>>>  
> >>>>>>>>>>>  /**
> >>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>  };
> >>>>>>>>>>>  
> >>>>>>>>>>> +/**
> >>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>> + */
> >>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>> +};
> >>>>>>>>>>> +
> >>>>>>>>>>>  /**
> >>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>   */
> >>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	int type;
> >>>>>>>>>>> +	/** private: */
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>> +	/**
> >>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>> +	 */
> >>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>  };
> >>>>>>>>>>>  
> >>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>  
> >>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>> +			   void *data);
> >>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>> +
> >>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 19, 2019, 10:45 p.m. UTC | #29

Hi Andrzej,

On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
> On 14.08.2019 14:40, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
> >> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
> >>> On 11.08.2019 00:43, Laurent Pinchart wrote:
> >>>> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> >>>>> On 08.08.2019 21:32, Laurent Pinchart wrote:
> >>>>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >>>>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>>>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>>>> Hi Laurent,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>>>>>>> panel is very painful.
> >>>>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> More comments inlined.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>>>>>>> data:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>>>>>>   retrieval operations
> >>>>>>>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>>>>>>> operation's callback?
> >>>>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Add and document these.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>>>>>>> bridges.
> >>>>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>>>>>>   */
> >>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>  {
> >>>>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>>>>>>> + * the bridge.
> >>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>>>>>>> bridge attach:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>>>>>>> without big sacrifices.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>>>>> +			   void *data)
> >>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +unlock:
> >>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>>>>>>> 			continue;
> >>>>>>>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>>>>>>> 	}
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 	dev = bridge->dev
> >>>>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>>>>>>> hpd they want/need.
> >>>>>>>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It looks more generic for me.
> >>>>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>>>>>> Regarding general idea:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>>>>>>> source.
> >>>>>>>>>>>
> >>>>>>>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>>>>>>
> >>>>>>>>>>> And I prefer 1st approach, why:
> >>>>>>>>>>>
> >>>>>>>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>>>>>>
> >>>>>>>>>>> - is more generic, for example if bridge send signal to two
> >>>>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>>>>>> If there will be two consumers, there will be two bridge attachments,
> >>>>>>>>> thus there will be two notifications, it should work.
> >>>>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>>>>>>> callback is registered on the produce bridge, not on the consumer bridge
> >>>>>>>> (or I'm totallly misreading what Laurent does here).
> >>>>>>> I have assumed that if devices exposes two hardware sink interfaces it
> >>>>>>> will expose two separate bridges - of course it will not work with
> >>>>>>> "bridge chaining" thing, but this is a different story.
> >>>>>> Daniel is right that the current implementation only allows one
> >>>>>> consumer. This is however not a limitation of the API, but of its
> >>>>>> implementation, as I only needed a single consumer. The helpers in this
> >>>>>> series ensure that neither the consumer nor the producer poke in the
> >>>>>> drm_bridge structure to call back to the HPD handler:
> >>>>>>
> >>>>>> - The consumer calls drm_bridge_hpd_enable() and
> >>>>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
> >>>>>>   behaviour if desired without changes to the consumer.
> >>>>>>
> >>>>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >>>>>>   which could also easily accommodate reference-counting in the drm
> >>>>>>   bridge core without changes to the producer.
> >>>>>>
> >>>>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >>>>>>   easily be extended to support multiple consumers without changes to
> >>>>>>   the producer.
> >>>>>>
> >>>>>> This is actually my second version of the HPD mechanism. The first
> >>>>>> version was never posted, poked into drm_bridge, and required the
> >>>>>> producer to be aware of the callbacks. After discussing this privately
> >>>>>> with Daniel, I came up with the implementation in this series that,
> >>>>>> while not supporting multiple consumers now, makes it easy to extend
> >>>>>> later without minimal effort.
> >>>>>>
> >>>>>> Daniel's proposed implementation above looks reasonable to me, provided
> >>>>>> we can iterate over the bridges in an order that don't depend on the
> >>>>>> position of the producer in the chain (should be easy to solve by
> >>>>>> starting at the encoder for instance). It however looks a bit like a
> >>>>>> midlayer to me :-) That's why I have a similar implementation in the
> >>>>>> connector-bridge helper, which could be extended to call
> >>>>>> encoder->helper_private->bridge_hpd_notify() and
> >>>>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> >>>>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> >>>>>> drm_bridge_hpd_notify() would on the other hand set the notification
> >>>>>> sequence towards the encoder and driver in stone. Daniel, do you think
> >>>>>> that would be better ?
> >>>>>>
> >>>>>> I would like to remind everybody that this series isn't the last I will
> >>>>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> >>>>>> open to suggestions, and can address problems on top of these patches,
> >>>>>> provided obviously that this series doesn't go in the wrong direction.
> >>>>>> I'm of course also willing to rework this series, but given the amount
> >>>>>> of work we have in the drm_bridge realm, I can't fix everything in one
> >>>>>> go :-)
> >>>>>>
> >>>>>>>>>>> - it resembles hardware wires :)
> >>>>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>>>>>>> interested in that hpd singal. This includes:
> >>>>>>>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>>>>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>>>>>>   uevent to the driver.
> >>>>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>>>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>>>>>>  
> >>>>>>>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>>>>>>> what he wants to do here.
> >>>>>> That's correct, and that's what I was trying to implement :-) The
> >>>>>> notification, in this patch series, goes from the producer bridge to a
> >>>>>> central place (namely the connector, with a helper implementation
> >>>>>> available as part of this series, but custom implementations in display
> >>>>>> drivers are fine if needed) that then dispatches the notification to all
> >>>>>> bridges (through the .lost_hotplug() operation, which we could replace
> >>>>>> by an .hpd_notify() operation) for the first two purposes listed above,
> >>>>>> and then to the overall driver. The only thing I don't support yet is
> >>>>>> dispatching to the display pipeline (item 4 in the list above) as I had
> >>>>>> no need for that, and didn't want to develop an API with no user. This
> >>>>>> would however not be difficult to do when needed, the need is taken into
> >>>>>> account in the proposed implementation.
> >>>>>>
> >>>>>>>>> I do not know the full picture, but the solution where particular bridge
> >>>>>>>>> notifies everything unconditionally seems to me much less flexible.
> >>>>>>>>>
> >>>>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>>>>>>> will mimic your scenario.
> >>>>>>>>>
> >>>>>>>>> But there are also other scenarios where bridge does not want to
> >>>>>>>>> propagate signal, because for example:
> >>>>>>>>>
> >>>>>>>>> - it wants to wait for other sinks to wake up,
> >>>>>>>>>
> >>>>>>>> The other sink can just do that in their hpd callback.
> >>>>>>>>
> >>>>>>>>> - it propagates HPD signal via hardware wire,
> >>>>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>>>>>>> the wire/hw hpd interrupt.
> >>>>>>>>
> >>>>>>> If it should ignore HPD, why it should receive it at all - it is
> >>>>>>> unnecessary noise. And I am afraid with more complicated pipelines it
> >>>>>>> will be impossible for particular component (bridge/encoder/whatever) to
> >>>>>>> distinguish if HPD notification which came from non-directly connected
> >>>>>>> component should be ignored or not.
> >>>>>>>
> >>>>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>>>>>>> device.
> >>>>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>>>>>>> board?
> >>>>>>> Bridge can have external connectors, and the user can connect there
> >>>>>>> anything.
> >>>>>>>
> >>>>>>>>> In general HPD is input signal for notify of state changes on particular
> >>>>>>>>> bus, in case of typical video bridge on its output video bus.
> >>>>>>>>>
> >>>>>>>>> In case of bridges they have also input video buses, and they can send
> >>>>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>>>>>>> if for most cases they looks similar.
> >>>>>>>> Ah, I think this is a problem we will eventually have. But it's not
> >>>>>>>> something we're currently solving here at all I think.
> >>>>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >>>>>>> line, so this is not something from far future. And I guess with HPD
> >>>>>>> broadcasting it could be racy/error prone, for example EDID reading can
> >>>>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >>>>>>> controller via hw wires also).
> >>>>>>>
> >>>>>>>>>>> And regarding implementation:
> >>>>>>>>>>>
> >>>>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>>>>>>
> >>>>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>>>>>>
> >>>>>>>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>>>>>>> source we should locate it by parsing notification chain (what about
> >>>>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>>>>>>
> >>>>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>>>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>>>>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>>>>>>> listener.
> >>>>>>>>> Do we have real life examples?
> >>>>>>>>>
> >>>>>>>>> I want to distinguish two situations:
> >>>>>>>>>
> >>>>>>>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>>>>>>
> >>>>>>>>> - another device wants to know if output bus of the bridge has changed
> >>>>>>>>> state.
> >>>>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>>>>>>> bridges can exchange state and information about each another. hpd is
> >>>>>>>> about the physical world, i.e. "is there a cable plugged into the port
> >>>>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>>>>>>> fun stuff like that, we have the atomic_check machinery for this.
> >>>>>>> My question was if we have real examples that upstream device requires
> >>>>>>> knowledge about state of output line of the bridge?
> >>>>>>>
> >>>>>>> To be more precise, we have following display pipeline:
> >>>>>>>
> >>>>>>> A-->B-->C
> >>>>>>>
> >>>>>>> And C sends HPD to B (ie signal that state of line between B and C
> >>>>>>> changed). Does A really wants to know this information? or it should
> >>>>>>> just need to know if state of line A-->B changed?
> >>>>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
> >>>>>> ESD protector and level shifter, and C is the physical HDMI connector.
> >>>>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
> >>>>>> be notified in order to reset the CEC state machine. One could however
> >>>>>> argue that in that case the A-B link state changes too, but the
> >>>>>> important part is that HPD detection is not performed by A, while A
> >>>>>> needs to be informed of lost hotplug.
> >>>>> I have no full picture but I guess in this case C sends HPD to B using
> >>>>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
> >>>>> say that B does not participate in HPD transmission/forwarding,
> >>>> No, in this case A doesn't receive any hardware HPD signal, it requires
> >>>> HPD notification through software.
> >>>>
> >>>>> some shifters with 'advanced power saving' can even perform wake-up of
> >>>>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
> >>>>> to A is indeed different than HPD sent from C to B.
> >>>>>
> >>>>> Btw, with the above logic of propagation of HPD callback (proposed by
> >>>>> Daniel) I guess it will work this way:
> >>>>>
> >>>>> - A will receive HPD signal via HW,
> >>>>>
> >>>>> - then B and C will receive HPD callback via framework.
> >>>>>
> >>>>> Am I right?
> >>>> It's the other way around.
> >>>>
> >>>> In this case the HPD signal from the connector (C) is routed to an input
> >>>> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
> >>>> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
> >>>> IRQ and receive the hardware HPD notification. The driver for the HDMI
> >>>> encoder (A) needs to receive HPD notification in software, through the
> >>>> framework.
> >>> If this is GPIO I wonder why do not query this gpio by encoder directly,
> >>> rules of ownership of such gpios seems to be grey area, so in such case
> >>> I would advise to put it in the driver who really needs it.
> >>>
> >>> This way it will be much simpler.
> >> First to fall, multiple drivers may need to be informed of HPD events
> >> coming from a GPIO, so we would need to duplicate it in multiple places,
> >> and I don't think the GPIO framework allows acquiring a GPIO multiple
> >> times.
> >>
> >> Then, the GPIO is described in DT, and DT doesn't care about which
> >> driver needs HPD events. DT specifies the GPIO in the node of the device
> >> it belongs to, this is defined in DT bindings, and must be the same on
> >> all boards, while depending on the board different devices may need to
> >> be informed of HPD events.
> >>
> >> For those two reasons HPD GPIO handling and consumption of HPD events
> >> can't always be grouped in the same driver.
> >>
> >>> Going back to HPD notifications, as I said earlier broadcasting HPD
> >>> notification unconditionally to every member of the chain with hope that
> >>> the member will be able to filter-out undesired notification seems to me
> >>> incorrect - maybe it can solve some problems but is not flexible enough
> >>> to be usable in other scenarios.
> >>>
> >>> If my arguments do not convince you please just continue with your
> >>> ideas, we can always add NO_HPD_BROADCAST somewhere :)
> >> :-) I would like to understand the problems you're referring to though,
> >> and hopefully solve them. If you could describe one of the scenarios
> >> where you think this mechanism wouldn't be usable that would help. In
> >> the meantime I will post a new version of the series with these
> >> operations kept as-is to get the rest of the patches reviewed.
> > See my little thing about midlayers, I think midlayers with lots of flags
> > for everything aren't a good idea. They should be more opinionated about
> > how things work.
> >
> > So if there's a case where this broadcasting of various things doesn't
> > work, let's dig into it.
> > -Daniel
> 
> OK, almost real life example:
> 
> A -> B -> C
> 
> A - RGB/HDMI converter,
> 
> B - HDMI/MHL converter,
> 
> C - uUSB controller (MUIC).
> 
> 
> C - detects presence of MHL sink and routes MHL lines to B in such case.
> 
> B - has no hardware logic to detect HPD, but it's firmware can read EDID
> from downstream component via HW lines and it has hardware lines to
> upstream component to send EDID,
> 
> A - can read EDID from B via hardware lines, but does not have hardware HPD.

It probably doesn't matter much for the overall discussion, but out of
curiosity, does B have a CBUS interface towards C and a DDC (I2C)
interface towards A ? And does A read the EDID on DDC and expose it
towards the SoC through a custom protocol (for instance as the ADV7511
does), or does it forward the DDC lines to the SoC ?

> So how it should work (according to specification):
> 
> 1. C detects MHL sink.
> 
> 2. C switches his mux to route lines to B.
> 
> 3. C sends HPD notification to B.
> 
> 4. B powers on, its firmware reads EDID from downstream lines (possibly
> adjusting it) and makes it available to upstream component A.
> 
> 5. B sends HPD notification to A.
> 
> 
> I do not know how it could work with HPD broadcasting.
> 
> I guess C should be HPD provider, but in case of HPD broadcasting A and
> B would receive notification in the same time, as a result A would start
> reading EDID too early - fail.

That's an interesting case indeed. Now I understand what you meant
earlier.

The HPD notification from C to B is purely internal, and should not be
visible from a DRM/KMS point of view. It just happens that this hardware
setup has a more complex HPD sequence that requires software
intervention in the middle of the sequence. As such, if we forget about
this patch series for a minute, C would need a custom API to send MHL
notification to B, and the HPD for DRM/KMS would be notified by B, right
?

I think it's possible to handle both the MHL notification and the
user-visible HPD notification through the same bridge API, provided that
we offer a way for a bridge to block forwarding of the HPD notification.
This will also require calling the HPD notifiers on bridges in the sink
to source order. Both are doable, the bridge HPD notifier operation
could return a bool that blocks propagation of the notification. Would
that work for you ?

> >>>>>>>>>> You seem to have some other idea here.
> >>>>>>>>>>
> >>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>>>>>>  	 */
> >>>>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>>>>>>> +	 * output.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>>>>>>> presence of another one?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>>>>>>> and connector->edid correctly.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>>>>>>> correctly updated.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>>>>>>   */
> >>>>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	int type;
> >>>>>>>>>>>>>>>> +	/** private: */
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>>>>> +			   void *data);
> >>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>>>>>>  					u32 connector_type);

Daniel Vetter Aug. 20, 2019, 8:30 a.m. UTC | #30

On Tue, Aug 20, 2019 at 01:32:09AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Wed, Aug 14, 2019 at 02:35:10PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 08, 2019 at 10:32:14PM +0300, Laurent Pinchart wrote:
> > > On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> > >> On 16.07.2019 11:00, Daniel Vetter wrote:
> > >>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> > >>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> > >>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> > >>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> > >>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> > >>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> > >>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > >>>>>>>>>> Hi Laurent,
> > >>>>>>>>>>
> > >>>>>>>>>> I like the approach, current practice when almost every bridge should
> > >>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> > >>>>>>>>>> panel is very painful.
> > >>>>>>>>>
> > >>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> > >>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> > >>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> > >>>>>>>>> get a feeling for what your hpd_cb usually does.
> > >>>>>>>>>
> > >>>>>>>>>> More comments inlined.
> > >>>>>>>>>>
> > >>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > >>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> > >>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> > >>>>>>>>>>> data:
> > >>>>>>>>>>>
> > >>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> > >>>>>>>>>>>   retrieval operations
> > >>>>>>>>>>> - Bitmask of supported operations
> > >>>>>>>>>>
> > >>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> > >>>>>>>>>> operation's callback?
> > >>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> > >>>>>>>>>
> > >>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > >>>>>>>>> add, generally good excuse to not have to think through the design between
> > >>>>>>>>> different parts of drivers - "just" add another flag.
> > >>>>>>>>>
> > >>>>>>>>>>> - Bridge output type
> > >>>>>>>>>>>
> > >>>>>>>>>>> Add and document these.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> > >>>>>>>>>>> notification in a way that is as transparent as possible for the
> > >>>>>>>>>>> bridges.
> > >>>>>>>>>>
> > >>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> > >>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> > >>>>>>>>>> right? More comments about it later.
> > >>>>>>>>>>
> > >>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> > >>>>>>>>>>>
> > >>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> > >>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >>>>>>>>>>>   */
> > >>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> > >>>>>>>>>>>  {
> > >>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> > >>>>>>>>>>> +
> > >>>>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> > >>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >>>>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>>>  	list_del_init(&bridge->list);
> > >>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> > >>>>>>>>>>>  }
> > >>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> > >>>>>>>>>>>  
> > >>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>  }
> > >>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >>>>>>>>>>>  
> > >>>>>>>>>>> +/**
> > >>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > >>>>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>>>> + * @cb: hot-plug detection callback
> > >>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > >>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> > >>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> > >>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> > >>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> > >>>>>>>>>>> + * the bridge.
> > >>>>>>>>>>> + */
> > >>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> > >>>>>>>>>> bridge attach:
> > >>>>>>>>>>
> > >>>>>>>>>> bridge->hpd_cb = cb;
> > >>>>>>>>>>
> > >>>>>>>>>> bridge->hpd_data = data;
> > >>>>>>>>>>
> > >>>>>>>>>> ret = drm_bridge_attach(...);
> > >>>>>>>>>
> > >>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> > >>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> > >>>>>>>>>
> > >>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> > >>>>>>>>>> without big sacrifices.
> > >>>>>>>>>>
> > >>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > >>>>>>>>>> notifies about sink status change, how it translates to this cb?
> > >>>>>>>>>>
> > >>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>>>> +			   void *data)
> > >>>>>>>>>>> +{
> > >>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> > >>>>>>>>>>> +		return;
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > >>>>>>>>>>> +		goto unlock;
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	bridge->hpd_cb = cb;
> > >>>>>>>>>>> +	bridge->hpd_data = data;
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +unlock:
> > >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>>>> +}
> > >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +/**
> > >>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > >>>>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > >>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > >>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> > >>>>>>>>>>> + * output status change occurs.
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>>>> + */
> > >>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > >>>>>>>>>>> +{
> > >>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> > >>>>>>>>>>> +		return;
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	bridge->hpd_cb = NULL;
> > >>>>>>>>>>> +	bridge->hpd_data = NULL;
> > >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>>>> +}
> > >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +/**
> > >>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> > >>>>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>>>> + * @status: output connection status
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> > >>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> > >>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > >>>>>>>>>>> + *
> > >>>>>>>>>>> + * This function shall be called in a context that can sleep.
> > >>>>>>>>>>> + */
> > >>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>>>> +			   enum drm_connector_status status)
> > >>>>>>>>>>> +{
> > >>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>>>> +	if (bridge->hpd_cb)
> > >>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > >>>>>>>>>
> > >>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> > >>>>>>>>>
> > >>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> > >>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> > >>>>>>>>> 		if (tmp_bridge == bridge)
> > >>>>>>>>> 			continue;
> > >>>>>>>>> 		if (bridge->hpd_notify);
> > >>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > >>>>>>>>> 	}
> > >>>>>>>>>
> > >>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> > >>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> > >>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > >>>>>>>>>
> > >>>>>>>>> 	dev = bridge->dev
> > >>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > >>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > >>>>>>>>>
> > >>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> > >>>>>>>>> hpd they want/need.
> > >>>>>>>>
> > >>>>>>>> As I understand you want to notify every member of the pipeline.
> > >>>>>>>>
> > >>>>>>>> I think it should be enough to notify only the source, and then source
> > >>>>>>>> should decide if/when the hpd should be propagated upstream.
> > >>>>>>>>
> > >>>>>>>> It looks more generic for me.
> > >>>>>>>
> > >>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> > >>>>>>> the one from Laurent? Kinda confused here.
> > >>>>>>
> > >>>>>> Regarding general idea:
> > >>>>>>
> > >>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> > >>>>>> source.
> > >>>>>>
> > >>>>>> 2. Your is to notify all other bridges and encoder.
> > >>>>>>
> > >>>>>> And I prefer 1st approach, why:
> > >>>>>>
> > >>>>>> - the source can decide if/when and to who propagate the signal,
> > >>>>>>
> > >>>>>> - is more generic, for example if bridge send signal to two
> > >>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> > >>>>>
> > >>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> > >>>>> consumer. There's only 1 callback. So you're example doesn't work.
> > >>>>
> > >>>> If there will be two consumers, there will be two bridge attachments,
> > >>>> thus there will be two notifications, it should work.
> > >>>
> > >>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> > >>> callback is registered on the produce bridge, not on the consumer bridge
> > >>> (or I'm totallly misreading what Laurent does here).
> > >> 
> > >> I have assumed that if devices exposes two hardware sink interfaces it
> > >> will expose two separate bridges - of course it will not work with
> > >> "bridge chaining" thing, but this is a different story.
> > > 
> > > Daniel is right that the current implementation only allows one
> > > consumer. This is however not a limitation of the API, but of its
> > > implementation, as I only needed a single consumer. The helpers in this
> > > series ensure that neither the consumer nor the producer poke in the
> > > drm_bridge structure to call back to the HPD handler:
> > > 
> > > - The consumer calls drm_bridge_hpd_enable() and
> > >   drm_bridge_hpd_disable(), which could offer a reference-counted
> > >   behaviour if desired without changes to the consumer.
> > > 
> > > - The producer gets configured by .hpd_enable() and .hpd_disable(),
> > >   which could also easily accommodate reference-counting in the drm
> > >   bridge core without changes to the producer.
> > > 
> > > - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> > >   easily be extended to support multiple consumers without changes to
> > >   the producer.
> > > 
> > > This is actually my second version of the HPD mechanism. The first
> > > version was never posted, poked into drm_bridge, and required the
> > > producer to be aware of the callbacks. After discussing this privately
> > > with Daniel, I came up with the implementation in this series that,
> > > while not supporting multiple consumers now, makes it easy to extend
> > > later without minimal effort.
> > > 
> > > Daniel's proposed implementation above looks reasonable to me, provided
> > > we can iterate over the bridges in an order that don't depend on the
> > > position of the producer in the chain (should be easy to solve by
> > > starting at the encoder for instance). It however looks a bit like a
> > > midlayer to me :-) That's why I have a similar implementation in the
> > > connector-bridge helper, which could be extended to call
> > > encoder->helper_private->bridge_hpd_notify() and
> > > dev->mode_config.helper_private->bridge_hpd_notify() instead of
> > > hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> > > drm_bridge_hpd_notify() would on the other hand set the notification
> > > sequence towards the encoder and driver in stone. Daniel, do you think
> > > that would be better ?
> > 
> > So the difference between the midlayer and the helper is that the helper
> > can be ignored. Which the above still can:
> > 
> > - producer can choose to not call that function
> > - consumer can choose not to have the callback
> > 
> > Now great helpers allow you to ignore only parts of them, so that you can
> > mix&match. Which again I think with the bridge stuff we're discussing here
> > is assured.
> 
> That's a bit difficult for the first part, as if the producer doesn't
> notify of HPD events, consumers won't be able to get them :-) The second
> part, consumers not having the callback, is already supported.
> 
> > So the final bit is how opinionated a helper can be, and imo it can be
> > very opinionated and strict and inflexible. That means it won't be useful
> > for every possible case, but those can be handled by simply not using the
> > helper (or that part of the helpers). Examples
> > 
> > - simple display pipe is very opinionated, but trades that in for being
> >   very useful for really simple displays
> > 
> > - similar with atomic helpers, there's a very strong suggestion that "if
> >   it doesn't fit, write your own commit_tail()"
> 
> (On a side note, doing so is quite complex, and I understand why nobody
> wants to really ditch the atomic helpers)

But most drivers do overwrite parts of it, which is kinda my point:
Everyone still keeps using at least some parts of atomic, and benefitting
from the opinionated guidelines those have.

> > And I think bridge helpers probably also need fairly opinioated, simply to
> > make sure that all the bridge drivers work together in a coherent fashion.
> > If we allow too much flexibility everyone bends the rules a bit, and
> > nothing fits.
> 
> I agree with you on that.
> 
> > Wrt your question: One option would be to do the same thing like shared
> > interrupt line handlers. As soon as the first interrupt handler says "I'
> > ve handled this one" we stop processing. But that might lead to more
> > confusion about who's responsible for an interrupt.
> 
> I don't think that's a good idea, as more than one consumer may need to
> process the event. A real life example with two consumers would be a CEC
> controller part of a bridge needing to get informed about HDMI
> plug/unplug to set the CEC address in the device (this notification is
> handled through the bridge notification operation), and the display
> driver needing to report HPD to the DRM core.
> 
> As I'm still not sure why you think I should replace the existing
> implementation with your above proposal, so I'll keep the existing code
> for the v2 that I will post soon until we complete this discussion.
> 
> To hopefully help with the discussion, I would like to repeat my main
> argument : moving the dispatching of the notification to
> drm_bridge_hpd_notify() sets the order in which components (bridges,
> encoders, drivers) are notified in stone, while keeping it in the
> drm_bridge_connector helper allows drivers to not use the helper and
> come up with a different implementation that fits their needs better.

That "set things in stone" is actually what I want. Well, not stone, but
really clear semantics. You're essentially creating a notifier, except
there's only every one notified entity at most. Ime bad things happen with
notifiers, it's unavoidable.

So maybe what we need instead is a bridge_hpd_process callback (in
mode_config.helpers or wherever, or on the encoder, dunno), with the above
default implementation. But you can then overwrite it.

Or another option would be that at least on DT platforms, DT gets to spec
the entire hpd routing.

I just fear that if we let bridge drivers all manage this themselves we'll
end up with a formadible mess of slight incompatibilities.
-Daniel

> 
> > > I would like to remind everybody that this series isn't the last I will
> > > ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> > > open to suggestions, and can address problems on top of these patches,
> > > provided obviously that this series doesn't go in the wrong direction.
> > > I'm of course also willing to rework this series, but given the amount
> > > of work we have in the drm_bridge realm, I can't fix everything in one
> > > go :-)
> > > 
> > >>>>>> - it resembles hardware wires :)
> > >>>>>
> > >>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> > >>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> > >>>>> interested in that hpd singal. This includes:
> > >>>>> - Other bridges, e.g. if they provide CEC support.
> > >>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> > >>>>> - Overall driver, so it can update the modes/connector status and send the
> > >>>>>   uevent to the driver.
> > >>>>> - Overall display pipeline for this specific bridge, maybe you need to
> > >>>>>   shut down/re-enable the pipe because $reasons.
> > >>>>>  
> > >>>>> That's at least my understanding from lots of chats with Laurent about
> > >>>>> what he wants to do here.
> > > 
> > > That's correct, and that's what I was trying to implement :-) The
> > > notification, in this patch series, goes from the producer bridge to a
> > > central place (namely the connector, with a helper implementation
> > > available as part of this series, but custom implementations in display
> > > drivers are fine if needed) that then dispatches the notification to all
> > > bridges (through the .lost_hotplug() operation, which we could replace
> > > by an .hpd_notify() operation) for the first two purposes listed above,
> > > and then to the overall driver. The only thing I don't support yet is
> > > dispatching to the display pipeline (item 4 in the list above) as I had
> > > no need for that, and didn't want to develop an API with no user. This
> > > would however not be difficult to do when needed, the need is taken into
> > > account in the proposed implementation.
> > > 
> > >>>> I do not know the full picture, but the solution where particular bridge
> > >>>> notifies everything unconditionally seems to me much less flexible.
> > >>>>
> > >>>> If HPD signals is received by the consumer, if there are no obstacles it
> > >>>> can propagate it further, upstream bridge/encoder or to drm core - it
> > >>>> will mimic your scenario.
> > >>>>
> > >>>> But there are also other scenarios where bridge does not want to
> > >>>> propagate signal, because for example:
> > >>>>
> > >>>> - it wants to wait for other sinks to wake up,
> > >>>
> > >>> The other sink can just do that in their hpd callback.
> > >>>
> > >>>> - it propagates HPD signal via hardware wire,
> > >>>
> > >>> Again, the other sink can just not listen to sw hpd in that case, and use
> > >>> the wire/hw hpd interrupt.
> > >> 
> > >> If it should ignore HPD, why it should receive it at all - it is
> > >> unnecessary noise. And I am afraid with more complicated pipelines it
> > >> will be impossible for particular component (bridge/encoder/whatever) to
> > >> distinguish if HPD notification which came from non-directly connected
> > >> component should be ignored or not.
> > >> 
> > >>>> - first it wants to verify if the sink is valid/compatible/authorized
> > >>>> device.
> > >>>
> > >>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> > >>> board?
> > >> 
> > >> Bridge can have external connectors, and the user can connect there
> > >> anything.
> > >> 
> > >>>> In general HPD is input signal for notify of state changes on particular
> > >>>> bus, in case of typical video bridge on its output video bus.
> > >>>>
> > >>>> In case of bridges they have also input video buses, and they can send
> > >>>> HPD signal via this bus, but this is indeed different HPD signal, even
> > >>>> if for most cases they looks similar.
> > >>>
> > >>> Ah, I think this is a problem we will eventually have. But it's not
> > >>> something we're currently solving here at all I think.
> > >> 
> > >> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> > >> line, so this is not something from far future. And I guess with HPD
> > >> broadcasting it could be racy/error prone, for example EDID reading can
> > >> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> > >> controller via hw wires also).
> > >> 
> > >>>>>> And regarding implementation:
> > >>>>>>
> > >>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> > >>>>>>
> > >>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> > >>>>>>
> > >>>>>> Your proposition is more straightforward, but if we want to notify only
> > >>>>>> source we should locate it by parsing notification chain (what about
> > >>>>>> unchained bridges), or store pointer somewhere during attachment.
> > >>>>>>
> > >>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> > >>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> > >>>>>
> > >>>>> Uh I think we're not talking about the same thing really. My understanding
> > >>>>> is that this callback is if someone (outside of this bridge) is interested
> > >>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> > >>>>> listener.
> > >>>>
> > >>>> Do we have real life examples?
> > >>>>
> > >>>> I want to distinguish two situations:
> > >>>>
> > >>>> - another device wants to know if input bus of the bridge has changed state,
> > >>>>
> > >>>> - another device wants to know if output bus of the bridge has changed
> > >>>> state.
> > >>>
> > >>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> > >>> bridges can exchange state and information about each another. hpd is
> > >>> about the physical world, i.e. "is there a cable plugged into the port
> > >>> I'm driving?". We're not going to use fake hpd to update bridge state and
> > >>> fun stuff like that, we have the atomic_check machinery for this.
> > >> 
> > >> My question was if we have real examples that upstream device requires
> > >> knowledge about state of output line of the bridge?
> > >> 
> > >> To be more precise, we have following display pipeline:
> > >> 
> > >> A-->B-->C
> > >> 
> > >> And C sends HPD to B (ie signal that state of line between B and C
> > >> changed). Does A really wants to know this information? or it should
> > >> just need to know if state of line A-->B changed?
> > > 
> > > There's one real life example, where A is an HDMI encoder, B is an HDMI
> > > ESD protector and level shifter, and C is the physical HDMI connector.
> > > When the HDMI cable is unplugged, the CEC controller part of A needs to
> > > be notified in order to reset the CEC state machine. One could however
> > > argue that in that case the A-B link state changes too, but the
> > > important part is that HPD detection is not performed by A, while A
> > > needs to be informed of lost hotplug.
> > > 
> > >>>>> You seem to have some other idea here.
> > >>>>>
> > >>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>>>> +}
> > >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > >>>>>>>>>>> +
> > >>>>>>>>>>>  #ifdef CONFIG_OF
> > >>>>>>>>>>>  /**
> > >>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > >>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > >>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> > >>>>>>>>>>> --- a/include/drm/drm_bridge.h
> > >>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> > >>>>>>>>>>> @@ -23,8 +23,9 @@
> > >>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> > >>>>>>>>>>>  #define __DRM_BRIDGE_H__
> > >>>>>>>>>>>  
> > >>>>>>>>>>> -#include <linux/list.h>
> > >>>>>>>>>>>  #include <linux/ctype.h>
> > >>>>>>>>>>> +#include <linux/list.h>
> > >>>>>>>>>>> +#include <linux/mutex.h>
> > >>>>>>>>>>>  #include <drm/drm_mode_object.h>
> > >>>>>>>>>>>  #include <drm/drm_modes.h>
> > >>>>>>>>>>>  
> > >>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >>>>>>>>>>>  	 */
> > >>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >>>>>>>>>>>  				    struct drm_atomic_state *state);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @detect:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> > >>>>>>>>>>> +	 * considered as always having a component attached to its output.
> > >>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> > >>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * RETURNS:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @get_modes:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> > >>>>>>>>>>> +	 * with drm_mode_probed_add().
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> > >>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> > >>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> > >>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * RETURNS:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> > >>>>>>>>>>> +			 struct drm_connector *connector);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @get_edid:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> > >>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> > >>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> > >>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> > >>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> > >>>>>>>>>>> +	 * output.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * RETURNS:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > >>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> > >>>>>>>>>>> +	 * the returned edid structure with kfree().
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > >>>>>>>>>>> +				 struct drm_connector *connector);
> > >>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> > >>>>>>>>>> presence of another one?
> > >>>>>>>>>>
> > >>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> > >>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> > >>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > >>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> > >>>>>>>>> and connector->edid correctly.
> > >>>>>>>>>
> > >>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> > >>>>>>>>> in the connector is up-to-date? With your current callback design that's
> > >>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > >>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> > >>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> > >>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> > >>>>>>>>> correctly updated.
> > >>>>>>>>>
> > >>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> > >>>>>>>>> edid, which is not so awesome :-)
> > >>>>>>>>>
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @lost_hotplug:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> > >>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> > >>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> > >>>>>>>>>>> +	 * HDMI bridges.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @hpd_enable:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> > >>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > >>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> > >>>>>>>>>>> +	 * @hpd_disable.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> > >>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> > >>>>>>>>>>> +
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @hpd_disable:
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> > >>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > >>>>>>>>>>> +	 * connection status occurs.
> > >>>>>>>>>>> +	 *
> > >>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> > >>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >>>>>>>>>>>  };
> > >>>>>>>>>>>  
> > >>>>>>>>>>>  /**
> > >>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >>>>>>>>>>>  	bool dual_link;
> > >>>>>>>>>>>  };
> > >>>>>>>>>>>  
> > >>>>>>>>>>> +/**
> > >>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > >>>>>>>>>>> + */
> > >>>>>>>>>>> +enum drm_bridge_ops {
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > >>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> > >>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > >>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> > >>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > >>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> > >>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> > >>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > >>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> > >>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > >>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> > >>>>>>>>>>> +};
> > >>>>>>>>>>> +
> > >>>>>>>>>>>  /**
> > >>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> > >>>>>>>>>>>   */
> > >>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> > >>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> > >>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> > >>>>>>>>>>>  	void *driver_private;
> > >>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> > >>>>>>>>>>> +	enum drm_bridge_ops ops;
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> > >>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > >>>>>>>>>>> +	 * identifies the type of connected display.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	int type;
> > >>>>>>>>>>> +	/** private: */
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	struct mutex hpd_mutex;
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> > >>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > >>>>>>>>>>> +	/**
> > >>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > >>>>>>>>>>> +	 * @hpd_cb.
> > >>>>>>>>>>> +	 */
> > >>>>>>>>>>> +	void *hpd_data;
> > >>>>>>>>>>>  };
> > >>>>>>>>>>>  
> > >>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> > >>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>>  			      struct drm_atomic_state *state);
> > >>>>>>>>>>>  
> > >>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>>>> +			   void *data);
> > >>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > >>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>>>> +			   enum drm_connector_status status);
> > >>>>>>>>>>> +
> > >>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >>>>>>>>>>>  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Daniel Vetter Aug. 20, 2019, 8:41 a.m. UTC | #31

On Mon, Aug 19, 2019 at 05:37:36AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
> 
> On Sat, Aug 17, 2019 at 03:14:56AM +0300, Laurent Pinchart wrote:
> > On Sat, Aug 17, 2019 at 02:30:08AM +0300, Laurent Pinchart wrote:
> > > On Wed, Aug 14, 2019 at 07:02:29PM +0200, Daniel Vetter wrote:
> > >> On Wed, Aug 14, 2019 at 04:30:57PM +0300, Laurent Pinchart wrote:
> > >>> On Wed, Aug 14, 2019 at 03:03:29PM +0200, Daniel Vetter wrote:
> > >>>> On Thu, Aug 08, 2019 at 09:36:31PM +0300, Laurent Pinchart wrote:
> > >>>>> On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> > >>>>>> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > >>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > >>>>>>>> Hi Laurent,
> > >>>>>>>> 
> > >>>>>>>> I like the approach, current practice when almost every bridge should
> > >>>>>>>> optionally implement connector, or alternatively downstream bridge or
> > >>>>>>>> panel is very painful.
> > >>>>>>> 
> > >>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> > >>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> > >>>>>>> it's all used in the end. I probably should go and do that, at least to
> > >>>>>>> get a feeling for what your hpd_cb usually does.
> > >>>>>>> 
> > >>>>>>>> More comments inlined.
> > >>>>>>>> 
> > >>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > >>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> > >>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> > >>>>>>>>> data:
> > >>>>>>>>>
> > >>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> > >>>>>>>>>   retrieval operations
> > >>>>>>>>> - Bitmask of supported operations
> > >>>>>>>> 
> > >>>>>>>> 
> > >>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> > >>>>>>>> operation's callback?
> > >>>>>>> 
> > >>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> > >>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > >>>>>>> add, generally good excuse to not have to think through the design between
> > >>>>>>> different parts of drivers - "just" add another flag.
> > >>>>>> 
> > >>>>>> The reason is that a bridge may support an operation (as in implemented
> > >>>>>> in the bridge hardware), but that operation may not be supported on a
> > >>>>>> particular board. For instance an HDMI encoder may support reading EDID
> > >>>>>> when the DDC lines are connected to the encoder, but a board may connect
> > >>>>>> the DDC lines to an I2C port of the SoC. We thus need to decouple
> > >>>>>> if a particular instance of the device supports the operation (exposed
> > >>>>>> by the ops flags) from the function pointers.
> > >>>>>> 
> > >>>>>> We could of course allocate the drm_bridge_funcs structure dynamically
> > >>>>>> for each bridge instance, and fill it with function pointers manually,
> > >>>>>> leaving the unused ops always NULL, but that would require making the
> > >>>>>> structure writable, which is considered a security issue. That's why I
> > >>>>>> decided to keep the drm_bridge_funcs structure as a global static const
> > >>>>>> structure, and add an ops bitmask.
> > >>>>>> 
> > >>>>>>>>> - Bridge output type
> > >>>>>>>>>
> > >>>>>>>>> Add and document these.
> > >>>>>>>>>
> > >>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> > >>>>>>>>> notification in a way that is as transparent as possible for the
> > >>>>>>>>> bridges.
> > >>>>>>>> 
> > >>>>>>>> Documentation of new opses does not explain how it should cooperate with
> > >>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> > >>>>>>>> right? More comments about it later.
> > >>>>>> 
> > >>>>>> No, the whole point is that they should not be chained at all. A bridge
> > >>>>>> does not have to propagate, for instance, .get_edid() to the next
> > >>>>>> bridge. That's one of the core design principles in this series, I want
> > >>>>>> to keep the bridges as simple as possible, and move the complexity of
> > >>>>>> the boilerplate code that is currently copied all around to helpers. See
> > >>>>>> patch "drm: Add helper to create a connector for a chain of bridges" for
> > >>>>>> more information about how this is used, with a helper that delegates
> > >>>>>> the connector operations to the correct bridge in the chain based on the
> > >>>>>> ops reported by each bridge.
> > >>>>>> 
> > >>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> > >>>>>>>>> ---
> > >>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> > >>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> > >>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> > >>>>>>>>>
> > >>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> > >>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> > >>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > >>>>>>>>>   */
> > >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> > >>>>>>>>>  {
> > >>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> > >>>>>>>>> +
> > >>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> > >>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > >>>>>>>>>  	mutex_lock(&bridge_lock);
> > >>>>>>>>>  	list_del_init(&bridge->list);
> > >>>>>>>>>  	mutex_unlock(&bridge_lock);
> > >>>>>>>>> +
> > >>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> > >>>>>>>>>  }
> > >>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> > >>>>>>>>>  
> > >>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>  }
> > >>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> > >>>>>>>>>  
> > >>>>>>>>> +/**
> > >>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > >>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>> + * @cb: hot-plug detection callback
> > >>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> > >>>>>>>>> + *
> > >>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > >>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> > >>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> > >>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> > >>>>>>>>> + *
> > >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>> + *
> > >>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> > >>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> > >>>>>>>>> + * the bridge.
> > >>>>>>>>> + */
> > >>>>>>>> 
> > >>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> > >>>>>>>> bridge attach:
> > >>>>>>>> 
> > >>>>>>>> bridge->hpd_cb = cb;
> > >>>>>>>> 
> > >>>>>>>> bridge->hpd_data = data;
> > >>>>>>>> 
> > >>>>>>>> ret = drm_bridge_attach(...);
> > >>>>>>> 
> > >>>>>>> Yeah I like this more. The other problem here is, what if you need more
> > >>>>>>> than 1 callback registers on the same bridge hdp signal?
> > >>>>>> 
> > >>>>>> That's why I decided to hide hide HPD through helpers,
> > >>>>>> drm_bridge_hpd_enable() and drm_bridge_hpd_disable() on the listener
> > >>>>>> side, and drm_bridge_hpd_notify() on the event reporter side. While the
> > >>>>>> current implementation is limited to a single listener, only the helpers
> > >>>>>> would need to be changed to extend that to multiple listeners.
> > >>>>>> 
> > >>>>>> Note that the .hpd_enable() and .hpd_disable() operations also allow the
> > >>>>>> bridge to disable HPD detection when not used. Doing so keeps the bridge
> > >>>>>> simple, it only needs to care about reporting HPD events when they're
> > >>>>>> enabled, without caring who (if anyone) is listening, and gets clear
> > >>>>>> instructions on whether to enable or disable the HPD hardware (in case
> > >>>>>> it can be disabled).
> > >>>>>> 
> > >>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> > >>>>>>>> without big sacrifices.
> > >>>>>>>> 
> > >>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> > >>>>>>>> notifies about sink status change, how it translates to this cb?
> > >>>>>> 
> > >>>>>> This is something this series doesn't implement. I don't think it would
> > >>>>>> be a big deal, but my knowledge of HPD (especially for DisplayPort) ends
> > >>>>>> here. If you can elaborate on what would be needed, I can implement
> > >>>>>> that.
> > >>>>>> 
> > >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>> +			   void *data)
> > >>>>>>>>> +{
> > >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> > >>>>>>>>> +		return;
> > >>>>>>>>> +
> > >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>> +
> > >>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > >>>>>>>>> +		goto unlock;
> > >>>>>>>>> +
> > >>>>>>>>> +	bridge->hpd_cb = cb;
> > >>>>>>>>> +	bridge->hpd_data = data;
> > >>>>>>>>> +
> > >>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +unlock:
> > >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>> +}
> > >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > >>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>> + *
> > >>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > >>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > >>>>>>>>> + * function returns the callback will not be called by the bridge when an
> > >>>>>>>>> + * output status change occurs.
> > >>>>>>>>> + *
> > >>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > >>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> > >>>>>>>>> + */
> > >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > >>>>>>>>> +{
> > >>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> > >>>>>>>>> +		return;
> > >>>>>>>>> +
> > >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	bridge->hpd_cb = NULL;
> > >>>>>>>>> +	bridge->hpd_data = NULL;
> > >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>> +}
> > >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > >>>>>>>>> +
> > >>>>>>>>> +/**
> > >>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> > >>>>>>>>> + * @bridge: bridge control structure
> > >>>>>>>>> + * @status: output connection status
> > >>>>>>>>> + *
> > >>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> > >>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> > >>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > >>>>>>>>> + *
> > >>>>>>>>> + * This function shall be called in a context that can sleep.
> > >>>>>>>>> + */
> > >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>> +			   enum drm_connector_status status)
> > >>>>>>>>> +{
> > >>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> > >>>>>>>>> +	if (bridge->hpd_cb)
> > >>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> > >>>>>>> 
> > >>>>>>> So this isn't quite what I had in mind. Instead something like this:
> > >>>>>>> 
> > >>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> > >>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> > >>>>>>> 		if (tmp_bridge == bridge)
> > >>>>>>> 			continue;
> > >>>>>>> 		if (bridge->hpd_notify);
> > >>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> > >>>>>>> 	}
> > >>>>>>> 
> > >>>>>>> 	encoder = encoder_for_bridge(bridge);
> > >>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> > >>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> > >>>>>>> 
> > >>>>>>> 	dev = bridge->dev
> > >>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> > >>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> > >>>>>>> 
> > >>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> > >>>>>>> hpd they want/need.
> > >>>>>> 
> > >>>>>> I'll reply to this further down the mail thread, to address additional
> > >>>>>> comments.
> > >>>>>> 
> > >>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> > >>>>>>>>> +}
> > >>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > >>>>>>>>> +
> > >>>>>>>>>  #ifdef CONFIG_OF
> > >>>>>>>>>  /**
> > >>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> > >>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > >>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> > >>>>>>>>> --- a/include/drm/drm_bridge.h
> > >>>>>>>>> +++ b/include/drm/drm_bridge.h
> > >>>>>>>>> @@ -23,8 +23,9 @@
> > >>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> > >>>>>>>>>  #define __DRM_BRIDGE_H__
> > >>>>>>>>>  
> > >>>>>>>>> -#include <linux/list.h>
> > >>>>>>>>>  #include <linux/ctype.h>
> > >>>>>>>>> +#include <linux/list.h>
> > >>>>>>>>> +#include <linux/mutex.h>
> > >>>>>>>>>  #include <drm/drm_mode_object.h>
> > >>>>>>>>>  #include <drm/drm_modes.h>
> > >>>>>>>>>  
> > >>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > >>>>>>>>>  	 */
> > >>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> > >>>>>>>>>  				    struct drm_atomic_state *state);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @detect:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Check if anything is attached to the bridge output.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> > >>>>>>>>> +	 * considered as always having a component attached to its output.
> > >>>>>>>>> +	 * Bridges that implement this callback shall set the
> > >>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * RETURNS:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @get_modes:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> > >>>>>>>>> +	 * with drm_mode_probed_add().
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> > >>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> > >>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> > >>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * RETURNS:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> > >>>>>>>>> +			 struct drm_connector *connector);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @get_edid:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> > >>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> > >>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> > >>>>>>>>> +	 * the @get_modes callback unimplemented.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * The caller of this operation shall first verify the output
> > >>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> > >>>>>>>>> +	 * output.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> > >>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * RETURNS:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> > >>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> > >>>>>>>>> +	 * the returned edid structure with kfree().
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> > >>>>>>>>> +				 struct drm_connector *connector);
> > >>>>>>>> 
> > >>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> > >>>>>>>> presence of another one?
> > >>>>>>>> 
> > >>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> > >>>>>>>> some helper function to .get_modes cb, which will do the same?
> > >>>>>>> 
> > >>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> > >>>>>>> case, and require that if it has an edid it must fill out connector->info
> > >>>>>>> and connector->edid correctly.
> > >>>>>> 
> > >>>>>> I think that's doable, I'll have a look.
> > >>>>> 
> > >>>>> So I had a look, and while this is doable, it would essentially mean
> > >>>>> that all bridges that retrieve modes from EDID would have to roll out
> > >>>>> their own version of the following code:
> > >>>>> 
> > >>>>> static int drm_bridge_connector_get_modes_edid(struct drm_connector *connector,
> > >>>>> 					       struct drm_bridge *bridge)
> > >>>>> {
> > >>>>> 	enum drm_connector_status status;
> > >>>>> 	struct edid *edid;
> > >>>>> 	int n;
> > >>>>> 
> > >>>>> 	status = drm_bridge_connector_detect(connector, false);
> > >>>>> 	if (status != connector_status_connected)
> > >>>>> 		goto no_edid;
> > >>>>> 
> > >>>>> 	edid = bridge->funcs->get_edid(bridge, connector);
> > >>>>> 	if (!edid || !drm_edid_is_valid(edid)) {
> > >>>>> 		kfree(edid);
> > >>>>> 		goto no_edid;
> > >>>>> 	}
> > >>>>> 
> > >>>>> 	drm_connector_update_edid_property(connector, edid);
> > >>>>> 	n = drm_add_edid_modes(connector, edid);
> > >>>>> 
> > >>>>> 	kfree(edid);
> > >>>>> 	return n;
> > >>>>> 
> > >>>>> no_edid:
> > >>>>> 	drm_connector_update_edid_property(connector, NULL);
> > >>>>> 	return 0;
> > >>>>> }
> > >>>>> 
> > >>>>> Is this desired ?
> > >>>> 
> > >>>> We store the edid, and we store a lot of decoded information in
> > >>>> drm_connector->display_info. Can't they just look there? Re-fetching the
> > >>>> edid definitely sounds like the wrong thing to do.
> > >>>> 
> > >>>> We might run into some ordering issue here I guess with hotplugs and who's
> > >>>> fetching the edid and everything like that.
> > >>> 
> > >>> That's exactly what I was about to answer after reading your first
> > >>> paragraph :-) I believe caching EDID is a good idea, but my familiarity
> > >>> with hotplug-related issues is limited to a handful of systems, and I'm
> > >>> sure I'm missing some common problems. If you can tell me how you think
> > >>> this should be done, I can give it a try.
> > >> 
> > >> I think all you need to do is make sure that when handling a hpd, the edid
> > >> is fetched first. Before other parts of the bridge try to reconfigure
> > >> themselves ...
> > >> 
> > >>>> Also maybe I'm missing the point here, and thinking too much of
> > >>>> ->get_modes on the connector. But then I'm not clear on why the bridge
> > >>>> needs the connector, and why it instead can't just return the edid it can
> > >>>> read and let the caller/core figure out everything else?
> > >>> 
> > >>> That's exactly what the .get_edid() operation that you asked me to
> > >>> remove did... :-) You didn't like the fact that it duplicated the
> > >>> .get_modes() logic. Should I add it back, and clearly document
> > >>> .get_modes() as a fallback used only when the connector doesn't use EDID
> > >>> ?
> > >> 
> > >> I guess I'm making a bit a fool of myself here. What I meant is that if we
> > >> do want to keep ->get_edid, then why do you need to pass the connector?
> > >> Just return the edid blob, and let the caller parse it, and stuff all
> > >> relevant data into drm_connector. Just thinking along the lines of your
> > >> goal of making the bridge drivers as dumb as possible.
> > >> 
> > >> Same thing for ->get_modes would be neat too, but we don't have a nice
> > >> datastructure for this. We'd need to pass both a list_head and a pointer
> > >> to the drm_display_info I think.
> > >> 
> > >> That would decouple bridges even more from connector, which I think is
> > >> somewhere on your goal list ...
> > > 
> > > So I had a look at that. We would need to remove the connector argument
> > > from drm_do_get_edid(). The connector currently stores a few fields
> > > related to EDID parsing:
> > > 
> > >         /**
> > >          * @null_edid_counter: track sinks that give us all zeros for the EDID.
> > >          * Needed to workaround some HW bugs where we get all 0s
> > >          */
> > >         int null_edid_counter;
> > > 
> > >         /** @bad_edid_counter: track sinks that give us an EDID with invalid checksum */
> > >         unsigned bad_edid_counter;
> > > 
> > >         /**
> > >          * @edid_corrupt: Indicates whether the last read EDID was corrupt. Used
> > >          * in Displayport compliance testing - Displayport Link CTS Core 1.2
> > >          * rev1.1 4.2.2.6
> > >          */
> > >         bool edid_corrupt;
> > > 
> > > We would need to decouple that from drm_connector. One option would be
> > > to create a new drm_edid structure that would store those three fields,
> > > as well as a struct edid, and return it from drm_do_get_edid() instead
> > > of the raw struct edid. Would you prefer a different solution ? Do you
> > > think that's a prerequisite to for this patch ?
> > 
> > The more I look at EDID parsing, the more it feels that we should
> > redesign the whole HPD and EDID get handling, and the more it becomes
> > out of scope for this patch series :-S EDID retrieval and extraction of
> > information from EDID is intertwined, for instance drm_get_edid()
> > performs the following:
> > 
> > struct edid *drm_get_edid(struct drm_connector *connector,
> > 			  struct i2c_adapter *adapter)
> > {
> > 	struct edid *edid;
> > 
> > 	if (connector->force == DRM_FORCE_OFF)
> > 		return NULL;
> > 
> > 	if (connector->force == DRM_FORCE_UNSPECIFIED && !drm_probe_ddc(adapter))
> > 		return NULL;
> > 
> > 	edid = drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
> > 	if (edid)
> > 		drm_get_displayid(connector, edid);
> > 	return edid;
> > }
> > 
> > I don't think the drm_get_displayid() call belongs there. Moving it to
> > the numerous callers of drm_get_edid() doesn't seem a good idea. Ideally
> > it should be done at the same time as populating the modes from EDID,
> > but I'm pretty sure that would break things, with not all EDID retrieval
> > resulting in modes updates.
> > 
> > A few drivers call drm_do_get_edid() directly, in order to provide a
> > custom EDID block read function, and they skip connector->force handling
> > and drm_get_displayid() as a result. In most case I assume that's a bug
> > that just went unnoticed.
> > 
> > Decoupling EDID read from drm_connector for bridges in a proper way seem
> > like a huge piece of work to me, and I really can't make it a
> > prerequisite for this patch.

Well, that's what you're doing with the bridge get_edid stuff. Higher
levels need to wrap that up in the drm_do_get_edid. And yes we have a mess
here :-/

> I still gave it a try, and it resulted in
> 
> 	git://linuxtv.org/pinchartl/media.git omapdrm/edid
> 
> Could you have a look at the last five patches in the branch ?
> 
> drm/edid: Reorganise the DisplayID parsing code
> drm/edid: Move functions to avoid forward declaration
> drm/edid: Move DisplayID tile parsing to drm_connector.c
> drm/edid: Honour connector->force in drm_do_get_edid()
> [WIP] drm/edid: Decouple EDID retrieval from connector
> 
> While the first four patches probably make sense and could be merged
> independently of the last one, it's really the fifth patch that makes
> decoupling of .get_edid() from drm_connector possible. And it's the
> patch I'm the least happy with in this whole series :-S As written in
> it's commit message, is it worth it ?

Hm ... the trouble I'm seeing is that if we give the bridges the
connector, your nice attempt at pulling connectors out of bridges will be
fooled.

Otoh, this is indeed a bit a mess, and not clean at all either.

I'd say up to you which of these wind-mills you'd prefer to tilt, and in
which order :-) Just make sure the kerneldoc for the hooks explains what's
going on, and what people should or should not do with the connector
argument.
-Daniel

> 
> > >>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> > >>>>>>> in the connector is up-to-date? With your current callback design that's
> > >>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> > >>>>>>> should guarantee that it'll first walk the connectors to update status and
> > >>>>>>> edid/mode list for the final drm_connector. And then instead of just
> > >>>>>>> passing the simple "status", it'll pass the connector, with everything
> > >>>>>>> correctly updated.
> > >>>>>>> 
> > >>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> > >>>>>>> edid, which is not so awesome :-)
> > >>>>>> 
> > >>>>>> With the current design there's a single listener, so it's not a big
> > >>>>>> deal :-) Furthermore, the listener is the helper that creates a
> > >>>>>> connector on top of a chain of bridges, so it's a pretty good place to
> > >>>>>> handle this. See the call to drm_kms_helper_hotplug_event() in
> > >>>>>> drm_bridge_connector_hpd_cb().
> > >>>>>> 
> > >>>>>> I'm all for reworking HPD and mode fetching, but I think it's a bit too
> > >>>>>> big of a requirement as a prerequisite for this series (or as part of
> > >>>>>> this series). We have hardware that can report HPD with various level of
> > >>>>>> details (from "something happened on a connector" to "this particular
> > >>>>>> event happened on this particular connector"), and we channel that
> > >>>>>> through helpers such as drm_kms_helper_hotplug_event() that lose the
> > >>>>>> details and go through a heavy mechanism to refetch everything. I
> > >>>>>> understand this is needed in many cases, but I think there's room for
> > >>>>>> improvement. This series, in my opinion, doesn't go in the wrong
> > >>>>>> direction in that regard, as it eventually calls
> > >>>>>> drm_kms_helper_hotplug_event(), so I think improvements would make sense
> > >>>>>> on top of it. I'm even willing to work on this, provided I get feedback
> > >>>>>> on what is desired.
> > >>>>>> 
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @lost_hotplug:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Notify the bridge of display disconnection.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> > >>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> > >>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> > >>>>>>>>> +	 * HDMI bridges.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_enable:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> > >>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> > >>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> > >>>>>>>>> +	 * @hpd_disable.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> > >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> > >>>>>>>>> +
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_disable:
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> > >>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> > >>>>>>>>> +	 * connection status occurs.
> > >>>>>>>>> +	 *
> > >>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> > >>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> > >>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> > >>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> > >>>>>>>>>  };
> > >>>>>>>>>  
> > >>>>>>>>>  /**
> > >>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > >>>>>>>>>  	bool dual_link;
> > >>>>>>>>>  };
> > >>>>>>>>>  
> > >>>>>>>>> +/**
> > >>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > >>>>>>>>> + */
> > >>>>>>>>> +enum drm_bridge_ops {
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > >>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> > >>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > >>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> > >>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > >>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> > >>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> > >>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > >>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> > >>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > >>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> > >>>>>>>>> +};
> > >>>>>>>>> +
> > >>>>>>>>>  /**
> > >>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> > >>>>>>>>>   */
> > >>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> > >>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> > >>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> > >>>>>>>>>  	void *driver_private;
> > >>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> > >>>>>>>>> +	enum drm_bridge_ops ops;
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @type: Type of the connection at the bridge output
> > >>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > >>>>>>>>> +	 * identifies the type of connected display.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	int type;
> > >>>>>>>>> +	/** private: */
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	struct mutex hpd_mutex;
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> > >>>>>>>>> +	 * drm_bridge_hpd_enable().
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> > >>>>>>>>> +	/**
> > >>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> > >>>>>>>>> +	 * @hpd_cb.
> > >>>>>>>>> +	 */
> > >>>>>>>>> +	void *hpd_data;
> > >>>>>>>>>  };
> > >>>>>>>>>  
> > >>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> > >>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > >>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > >>>>>>>>>  			      struct drm_atomic_state *state);
> > >>>>>>>>>  
> > >>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > >>>>>>>>> +			   void (*cb)(void *data,
> > >>>>>>>>> +				      enum drm_connector_status status),
> > >>>>>>>>> +			   void *data);
> > >>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > >>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > >>>>>>>>> +			   enum drm_connector_status status);
> > >>>>>>>>> +
> > >>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> > >>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > >>>>>>>>>  					u32 connector_type);
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Andrzej Hajda Aug. 22, 2019, 12:17 p.m. UTC | #32

On 20.08.2019 00:45, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
>> On 14.08.2019 14:40, Daniel Vetter wrote:
>>> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
>>>> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
>>>>> On 11.08.2019 00:43, Laurent Pinchart wrote:
>>>>>> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
>>>>>>> On 08.08.2019 21:32, Laurent Pinchart wrote:
>>>>>>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
>>>>>>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
>>>>>>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
>>>>>>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
>>>>>>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>>>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>>>>>> Hi Laurent,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
>>>>>>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>>>>>>>>>>>>> panel is very painful.
>>>>>>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>>>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>>>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>>>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> More comments inlined.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>>>>>>>>>>>>> data:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>>>>>>>>>>>>   retrieval operations
>>>>>>>>>>>>>>>>>> - Bitmask of supported operations
>>>>>>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>>>>>>>>>>>>> operation's callback?
>>>>>>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>>>>>>>>>>>>> add, generally good excuse to not have to think through the design between
>>>>>>>>>>>>>>>> different parts of drivers - "just" add another flag.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> - Bridge output type
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Add and document these.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>>>>>>>>>>>>> bridges.
>>>>>>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>>>>>>>>>>>>> right? More comments about it later.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>>>>>>>>>>>>   */
>>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>>>  {
>>>>>>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>>>> + * @cb: hot-plug detection callback
>>>>>>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>>>>>>>>>>>>> + * the bridge.
>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>>>>>>>>>>>>> bridge attach:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bridge->hpd_cb = cb;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> bridge->hpd_data = data;
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ret = drm_bridge_attach(...);
>>>>>>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>>>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>>>>>>>>>>>>> without big sacrifices.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>>>>>>> +			   void *data)
>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>>>>>>>>>>>>> +		goto unlock;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>>>>>>>>>>>>> +	bridge->hpd_data = data;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +unlock:
>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>>>>>>>>>>>>> + * output status change occurs.
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>>>> + * @status: output connection status
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status)
>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +	if (bridge->hpd_cb)
>>>>>>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>>>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>>>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>>>>>>>>>>>>> 		if (tmp_bridge == bridge)
>>>>>>>>>>>>>>>> 			continue;
>>>>>>>>>>>>>>>> 		if (bridge->hpd_notify);
>>>>>>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>>>>>>>>>>>>> 	}
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>>>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>>>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 	dev = bridge->dev
>>>>>>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>>>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>>>>>>>>>>>>> hpd they want/need.
>>>>>>>>>>>>>>> As I understand you want to notify every member of the pipeline.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think it should be enough to notify only the source, and then source
>>>>>>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It looks more generic for me.
>>>>>>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>>>>>>>>>>>>> the one from Laurent? Kinda confused here.
>>>>>>>>>>>>> Regarding general idea:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
>>>>>>>>>>>>> source.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. Your is to notify all other bridges and encoder.
>>>>>>>>>>>>>
>>>>>>>>>>>>> And I prefer 1st approach, why:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - the source can decide if/when and to who propagate the signal,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - is more generic, for example if bridge send signal to two
>>>>>>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
>>>>>>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
>>>>>>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
>>>>>>>>>>> If there will be two consumers, there will be two bridge attachments,
>>>>>>>>>>> thus there will be two notifications, it should work.
>>>>>>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
>>>>>>>>>> callback is registered on the produce bridge, not on the consumer bridge
>>>>>>>>>> (or I'm totallly misreading what Laurent does here).
>>>>>>>>> I have assumed that if devices exposes two hardware sink interfaces it
>>>>>>>>> will expose two separate bridges - of course it will not work with
>>>>>>>>> "bridge chaining" thing, but this is a different story.
>>>>>>>> Daniel is right that the current implementation only allows one
>>>>>>>> consumer. This is however not a limitation of the API, but of its
>>>>>>>> implementation, as I only needed a single consumer. The helpers in this
>>>>>>>> series ensure that neither the consumer nor the producer poke in the
>>>>>>>> drm_bridge structure to call back to the HPD handler:
>>>>>>>>
>>>>>>>> - The consumer calls drm_bridge_hpd_enable() and
>>>>>>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
>>>>>>>>   behaviour if desired without changes to the consumer.
>>>>>>>>
>>>>>>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
>>>>>>>>   which could also easily accommodate reference-counting in the drm
>>>>>>>>   bridge core without changes to the producer.
>>>>>>>>
>>>>>>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
>>>>>>>>   easily be extended to support multiple consumers without changes to
>>>>>>>>   the producer.
>>>>>>>>
>>>>>>>> This is actually my second version of the HPD mechanism. The first
>>>>>>>> version was never posted, poked into drm_bridge, and required the
>>>>>>>> producer to be aware of the callbacks. After discussing this privately
>>>>>>>> with Daniel, I came up with the implementation in this series that,
>>>>>>>> while not supporting multiple consumers now, makes it easy to extend
>>>>>>>> later without minimal effort.
>>>>>>>>
>>>>>>>> Daniel's proposed implementation above looks reasonable to me, provided
>>>>>>>> we can iterate over the bridges in an order that don't depend on the
>>>>>>>> position of the producer in the chain (should be easy to solve by
>>>>>>>> starting at the encoder for instance). It however looks a bit like a
>>>>>>>> midlayer to me :-) That's why I have a similar implementation in the
>>>>>>>> connector-bridge helper, which could be extended to call
>>>>>>>> encoder->helper_private->bridge_hpd_notify() and
>>>>>>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
>>>>>>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
>>>>>>>> drm_bridge_hpd_notify() would on the other hand set the notification
>>>>>>>> sequence towards the encoder and driver in stone. Daniel, do you think
>>>>>>>> that would be better ?
>>>>>>>>
>>>>>>>> I would like to remind everybody that this series isn't the last I will
>>>>>>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
>>>>>>>> open to suggestions, and can address problems on top of these patches,
>>>>>>>> provided obviously that this series doesn't go in the wrong direction.
>>>>>>>> I'm of course also willing to rework this series, but given the amount
>>>>>>>> of work we have in the drm_bridge realm, I can't fix everything in one
>>>>>>>> go :-)
>>>>>>>>
>>>>>>>>>>>>> - it resembles hardware wires :)
>>>>>>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
>>>>>>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
>>>>>>>>>>>> interested in that hpd singal. This includes:
>>>>>>>>>>>> - Other bridges, e.g. if they provide CEC support.
>>>>>>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
>>>>>>>>>>>> - Overall driver, so it can update the modes/connector status and send the
>>>>>>>>>>>>   uevent to the driver.
>>>>>>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
>>>>>>>>>>>>   shut down/re-enable the pipe because $reasons.
>>>>>>>>>>>>  
>>>>>>>>>>>> That's at least my understanding from lots of chats with Laurent about
>>>>>>>>>>>> what he wants to do here.
>>>>>>>> That's correct, and that's what I was trying to implement :-) The
>>>>>>>> notification, in this patch series, goes from the producer bridge to a
>>>>>>>> central place (namely the connector, with a helper implementation
>>>>>>>> available as part of this series, but custom implementations in display
>>>>>>>> drivers are fine if needed) that then dispatches the notification to all
>>>>>>>> bridges (through the .lost_hotplug() operation, which we could replace
>>>>>>>> by an .hpd_notify() operation) for the first two purposes listed above,
>>>>>>>> and then to the overall driver. The only thing I don't support yet is
>>>>>>>> dispatching to the display pipeline (item 4 in the list above) as I had
>>>>>>>> no need for that, and didn't want to develop an API with no user. This
>>>>>>>> would however not be difficult to do when needed, the need is taken into
>>>>>>>> account in the proposed implementation.
>>>>>>>>
>>>>>>>>>>> I do not know the full picture, but the solution where particular bridge
>>>>>>>>>>> notifies everything unconditionally seems to me much less flexible.
>>>>>>>>>>>
>>>>>>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
>>>>>>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
>>>>>>>>>>> will mimic your scenario.
>>>>>>>>>>>
>>>>>>>>>>> But there are also other scenarios where bridge does not want to
>>>>>>>>>>> propagate signal, because for example:
>>>>>>>>>>>
>>>>>>>>>>> - it wants to wait for other sinks to wake up,
>>>>>>>>>>>
>>>>>>>>>> The other sink can just do that in their hpd callback.
>>>>>>>>>>
>>>>>>>>>>> - it propagates HPD signal via hardware wire,
>>>>>>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
>>>>>>>>>> the wire/hw hpd interrupt.
>>>>>>>>>>
>>>>>>>>> If it should ignore HPD, why it should receive it at all - it is
>>>>>>>>> unnecessary noise. And I am afraid with more complicated pipelines it
>>>>>>>>> will be impossible for particular component (bridge/encoder/whatever) to
>>>>>>>>> distinguish if HPD notification which came from non-directly connected
>>>>>>>>> component should be ignored or not.
>>>>>>>>>
>>>>>>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
>>>>>>>>>>> device.
>>>>>>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
>>>>>>>>>> board?
>>>>>>>>> Bridge can have external connectors, and the user can connect there
>>>>>>>>> anything.
>>>>>>>>>
>>>>>>>>>>> In general HPD is input signal for notify of state changes on particular
>>>>>>>>>>> bus, in case of typical video bridge on its output video bus.
>>>>>>>>>>>
>>>>>>>>>>> In case of bridges they have also input video buses, and they can send
>>>>>>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
>>>>>>>>>>> if for most cases they looks similar.
>>>>>>>>>> Ah, I think this is a problem we will eventually have. But it's not
>>>>>>>>>> something we're currently solving here at all I think.
>>>>>>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
>>>>>>>>> line, so this is not something from far future. And I guess with HPD
>>>>>>>>> broadcasting it could be racy/error prone, for example EDID reading can
>>>>>>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
>>>>>>>>> controller via hw wires also).
>>>>>>>>>
>>>>>>>>>>>>> And regarding implementation:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Your proposition is more straightforward, but if we want to notify only
>>>>>>>>>>>>> source we should locate it by parsing notification chain (what about
>>>>>>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
>>>>>>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
>>>>>>>>>>>> Uh I think we're not talking about the same thing really. My understanding
>>>>>>>>>>>> is that this callback is if someone (outside of this bridge) is interested
>>>>>>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
>>>>>>>>>>>> listener.
>>>>>>>>>>> Do we have real life examples?
>>>>>>>>>>>
>>>>>>>>>>> I want to distinguish two situations:
>>>>>>>>>>>
>>>>>>>>>>> - another device wants to know if input bus of the bridge has changed state,
>>>>>>>>>>>
>>>>>>>>>>> - another device wants to know if output bus of the bridge has changed
>>>>>>>>>>> state.
>>>>>>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
>>>>>>>>>> bridges can exchange state and information about each another. hpd is
>>>>>>>>>> about the physical world, i.e. "is there a cable plugged into the port
>>>>>>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
>>>>>>>>>> fun stuff like that, we have the atomic_check machinery for this.
>>>>>>>>> My question was if we have real examples that upstream device requires
>>>>>>>>> knowledge about state of output line of the bridge?
>>>>>>>>>
>>>>>>>>> To be more precise, we have following display pipeline:
>>>>>>>>>
>>>>>>>>> A-->B-->C
>>>>>>>>>
>>>>>>>>> And C sends HPD to B (ie signal that state of line between B and C
>>>>>>>>> changed). Does A really wants to know this information? or it should
>>>>>>>>> just need to know if state of line A-->B changed?
>>>>>>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
>>>>>>>> ESD protector and level shifter, and C is the physical HDMI connector.
>>>>>>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
>>>>>>>> be notified in order to reset the CEC state machine. One could however
>>>>>>>> argue that in that case the A-B link state changes too, but the
>>>>>>>> important part is that HPD detection is not performed by A, while A
>>>>>>>> needs to be informed of lost hotplug.
>>>>>>> I have no full picture but I guess in this case C sends HPD to B using
>>>>>>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
>>>>>>> say that B does not participate in HPD transmission/forwarding,
>>>>>> No, in this case A doesn't receive any hardware HPD signal, it requires
>>>>>> HPD notification through software.
>>>>>>
>>>>>>> some shifters with 'advanced power saving' can even perform wake-up of
>>>>>>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
>>>>>>> to A is indeed different than HPD sent from C to B.
>>>>>>>
>>>>>>> Btw, with the above logic of propagation of HPD callback (proposed by
>>>>>>> Daniel) I guess it will work this way:
>>>>>>>
>>>>>>> - A will receive HPD signal via HW,
>>>>>>>
>>>>>>> - then B and C will receive HPD callback via framework.
>>>>>>>
>>>>>>> Am I right?
>>>>>> It's the other way around.
>>>>>>
>>>>>> In this case the HPD signal from the connector (C) is routed to an input
>>>>>> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
>>>>>> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
>>>>>> IRQ and receive the hardware HPD notification. The driver for the HDMI
>>>>>> encoder (A) needs to receive HPD notification in software, through the
>>>>>> framework.
>>>>> If this is GPIO I wonder why do not query this gpio by encoder directly,
>>>>> rules of ownership of such gpios seems to be grey area, so in such case
>>>>> I would advise to put it in the driver who really needs it.
>>>>>
>>>>> This way it will be much simpler.
>>>> First to fall, multiple drivers may need to be informed of HPD events
>>>> coming from a GPIO, so we would need to duplicate it in multiple places,
>>>> and I don't think the GPIO framework allows acquiring a GPIO multiple
>>>> times.
>>>>
>>>> Then, the GPIO is described in DT, and DT doesn't care about which
>>>> driver needs HPD events. DT specifies the GPIO in the node of the device
>>>> it belongs to, this is defined in DT bindings, and must be the same on
>>>> all boards, while depending on the board different devices may need to
>>>> be informed of HPD events.
>>>>
>>>> For those two reasons HPD GPIO handling and consumption of HPD events
>>>> can't always be grouped in the same driver.
>>>>
>>>>> Going back to HPD notifications, as I said earlier broadcasting HPD
>>>>> notification unconditionally to every member of the chain with hope that
>>>>> the member will be able to filter-out undesired notification seems to me
>>>>> incorrect - maybe it can solve some problems but is not flexible enough
>>>>> to be usable in other scenarios.
>>>>>
>>>>> If my arguments do not convince you please just continue with your
>>>>> ideas, we can always add NO_HPD_BROADCAST somewhere :)
>>>> :-) I would like to understand the problems you're referring to though,
>>>> and hopefully solve them. If you could describe one of the scenarios
>>>> where you think this mechanism wouldn't be usable that would help. In
>>>> the meantime I will post a new version of the series with these
>>>> operations kept as-is to get the rest of the patches reviewed.
>>> See my little thing about midlayers, I think midlayers with lots of flags
>>> for everything aren't a good idea. They should be more opinionated about
>>> how things work.
>>>
>>> So if there's a case where this broadcasting of various things doesn't
>>> work, let's dig into it.
>>> -Daniel
>> OK, almost real life example:
>>
>> A -> B -> C
>>
>> A - RGB/HDMI converter,
>>
>> B - HDMI/MHL converter,
>>
>> C - uUSB controller (MUIC).
>>
>>
>> C - detects presence of MHL sink and routes MHL lines to B in such case.
>>
>> B - has no hardware logic to detect HPD, but it's firmware can read EDID
>> from downstream component via HW lines and it has hardware lines to
>> upstream component to send EDID,
>>
>> A - can read EDID from B via hardware lines, but does not have hardware HPD.
> It probably doesn't matter much for the overall discussion, but out of
> curiosity, does B have a CBUS interface towards C and a DDC (I2C)
> interface towards A ?


Yes, but C (MUIC) is not MHL aware, beside initial 1K resistance
detection on ID pin, AFAIK.


>  And does A read the EDID on DDC and expose it
> towards the SoC through a custom protocol (for instance as the ADV7511
> does), or does it forward the DDC lines to the SoC ?
>
>> So how it should work (according to specification):
>>
>> 1. C detects MHL sink.
>>
>> 2. C switches his mux to route lines to B.
>>
>> 3. C sends HPD notification to B.
>>
>> 4. B powers on, its firmware reads EDID from downstream lines (possibly
>> adjusting it) and makes it available to upstream component A.
>>
>> 5. B sends HPD notification to A.
>>
>>
>> I do not know how it could work with HPD broadcasting.
>>
>> I guess C should be HPD provider, but in case of HPD broadcasting A and
>> B would receive notification in the same time, as a result A would start
>> reading EDID too early - fail.
> That's an interesting case indeed. Now I understand what you meant
> earlier.
>
> The HPD notification from C to B is purely internal, and should not be
> visible from a DRM/KMS point of view. It just happens that this hardware
> setup has a more complex HPD sequence that requires software
> intervention in the middle of the sequence. As such, if we forget about
> this patch series for a minute, C would need a custom API to send MHL
> notification to B, and the HPD for DRM/KMS would be notified by B, right
> ?


I just want to convince you that maybe all HPD signals
(hardware/software) are purely internal (ie they should be handled only
by upstream devices), and the hotplug event should be sent to
userspace/drm_core only when WHOLE pipeline is ready to query modes
(i2c/sideband channels/whatever is functional).


>
> I think it's possible to handle both the MHL notification and the
> user-visible HPD notification through the same bridge API, provided that
> we offer a way for a bridge to block forwarding of the HPD notification.
> This will also require calling the HPD notifiers on bridges in the sink
> to source order. Both are doable, the bridge HPD notifier operation
> could return a bool that blocks propagation of the notification. Would
> that work for you ?


It could work, in this case.

But it will still have problems with non-linear pipelines - where stream
is split to two or more bridges/panels.


Regards

Andrzej

 

>
>>>>>>>>>>>> You seem to have some other idea here.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>  #ifdef CONFIG_OF
>>>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> -#include <linux/list.h>
>>>>>>>>>>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>>>>>>>>>>> +#include <linux/list.h>
>>>>>>>>>>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>>>>>>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>>>>>>>>>>>>  	 */
>>>>>>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @detect:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @get_modes:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>> +			 struct drm_connector *connector);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @get_edid:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>>>>>>>>>>>>> +	 * output.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>> +				 struct drm_connector *connector);
>>>>>>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>>>>>>>>>>>>> presence of another one?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>>>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>>>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>>>>>>>>>>>>> and connector->edid correctly.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>>>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
>>>>>>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>>>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>>>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>>>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>>>>>>>>>>>>> correctly updated.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>>>>>>>>>>>>> edid, which is not so awesome :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @lost_hotplug:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>>>>>>>>>>>>> +	 * HDMI bridges.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @hpd_enable:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>>>>>>>>>>>>> +	 * @hpd_disable.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @hpd_disable:
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>>>>>>>>>>>>> +	 * connection status occurs.
>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>>>>>>>>>>>>  	bool dual_link;
>>>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>> +enum drm_bridge_ops {
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>>>>>>>>>>>>   */
>>>>>>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>>>>>>>>>>>>  	void *driver_private;
>>>>>>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>>>>>>>>>>>>> +	 * identifies the type of connected display.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	int type;
>>>>>>>>>>>>>>>>>> +	/** private: */
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	struct mutex hpd_mutex;
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>>>>>>>>>>>>> +	 * @hpd_cb.
>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>> +	void *hpd_data;
>>>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>>>>>>> +			   void *data);
>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status);
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>>>>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 26, 2019, 3:57 p.m. UTC | #33

Hi Daniel,

On Tue, Aug 20, 2019 at 10:30:46AM +0200, Daniel Vetter wrote:
> On Tue, Aug 20, 2019 at 01:32:09AM +0300, Laurent Pinchart wrote:
> > On Wed, Aug 14, 2019 at 02:35:10PM +0200, Daniel Vetter wrote:
> >> On Thu, Aug 08, 2019 at 10:32:14PM +0300, Laurent Pinchart wrote:
> >>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >>>> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>> Hi Laurent,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>>>> panel is very painful.
> >>>>>>>>>>>
> >>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>>>
> >>>>>>>>>>>> More comments inlined.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>>>> data:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>>>   retrieval operations
> >>>>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>>>
> >>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>>>> operation's callback?
> >>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>>>
> >>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>>>
> >>>>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Add and document these.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>>>> bridges.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>>>   */
> >>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>>>  {
> >>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>>>  }
> >>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  }
> >>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>>>> + * the bridge.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>>>> bridge attach:
> >>>>>>>>>>>>
> >>>>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>>>
> >>>>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>>>
> >>>>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>>>
> >>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>>>
> >>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>>>> without big sacrifices.
> >>>>>>>>>>>>
> >>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>>>
> >>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>> +			   void *data)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +unlock:
> >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>>>> + *
> >>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>>>> +{
> >>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>>>
> >>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>>>
> >>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>>>> 			continue;
> >>>>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>>>> 	}
> >>>>>>>>>>>
> >>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>>>
> >>>>>>>>>>> 	dev = bridge->dev
> >>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>>>
> >>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>>>> hpd they want/need.
> >>>>>>>>>>
> >>>>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>>>
> >>>>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>>>
> >>>>>>>>>> It looks more generic for me.
> >>>>>>>>>
> >>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>>>
> >>>>>>>> Regarding general idea:
> >>>>>>>>
> >>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>>>> source.
> >>>>>>>>
> >>>>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>>>
> >>>>>>>> And I prefer 1st approach, why:
> >>>>>>>>
> >>>>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>>>
> >>>>>>>> - is more generic, for example if bridge send signal to two
> >>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>>>
> >>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>>>
> >>>>>> If there will be two consumers, there will be two bridge attachments,
> >>>>>> thus there will be two notifications, it should work.
> >>>>>
> >>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>>>> callback is registered on the produce bridge, not on the consumer bridge
> >>>>> (or I'm totallly misreading what Laurent does here).
> >>>> 
> >>>> I have assumed that if devices exposes two hardware sink interfaces it
> >>>> will expose two separate bridges - of course it will not work with
> >>>> "bridge chaining" thing, but this is a different story.
> >>> 
> >>> Daniel is right that the current implementation only allows one
> >>> consumer. This is however not a limitation of the API, but of its
> >>> implementation, as I only needed a single consumer. The helpers in this
> >>> series ensure that neither the consumer nor the producer poke in the
> >>> drm_bridge structure to call back to the HPD handler:
> >>> 
> >>> - The consumer calls drm_bridge_hpd_enable() and
> >>>   drm_bridge_hpd_disable(), which could offer a reference-counted
> >>>   behaviour if desired without changes to the consumer.
> >>> 
> >>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >>>   which could also easily accommodate reference-counting in the drm
> >>>   bridge core without changes to the producer.
> >>> 
> >>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >>>   easily be extended to support multiple consumers without changes to
> >>>   the producer.
> >>> 
> >>> This is actually my second version of the HPD mechanism. The first
> >>> version was never posted, poked into drm_bridge, and required the
> >>> producer to be aware of the callbacks. After discussing this privately
> >>> with Daniel, I came up with the implementation in this series that,
> >>> while not supporting multiple consumers now, makes it easy to extend
> >>> later without minimal effort.
> >>> 
> >>> Daniel's proposed implementation above looks reasonable to me, provided
> >>> we can iterate over the bridges in an order that don't depend on the
> >>> position of the producer in the chain (should be easy to solve by
> >>> starting at the encoder for instance). It however looks a bit like a
> >>> midlayer to me :-) That's why I have a similar implementation in the
> >>> connector-bridge helper, which could be extended to call
> >>> encoder->helper_private->bridge_hpd_notify() and
> >>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> >>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> >>> drm_bridge_hpd_notify() would on the other hand set the notification
> >>> sequence towards the encoder and driver in stone. Daniel, do you think
> >>> that would be better ?
> >> 
> >> So the difference between the midlayer and the helper is that the helper
> >> can be ignored. Which the above still can:
> >> 
> >> - producer can choose to not call that function
> >> - consumer can choose not to have the callback
> >> 
> >> Now great helpers allow you to ignore only parts of them, so that you can
> >> mix&match. Which again I think with the bridge stuff we're discussing here
> >> is assured.
> > 
> > That's a bit difficult for the first part, as if the producer doesn't
> > notify of HPD events, consumers won't be able to get them :-) The second
> > part, consumers not having the callback, is already supported.
> > 
> >> So the final bit is how opinionated a helper can be, and imo it can be
> >> very opinionated and strict and inflexible. That means it won't be useful
> >> for every possible case, but those can be handled by simply not using the
> >> helper (or that part of the helpers). Examples
> >> 
> >> - simple display pipe is very opinionated, but trades that in for being
> >>   very useful for really simple displays
> >> 
> >> - similar with atomic helpers, there's a very strong suggestion that "if
> >>   it doesn't fit, write your own commit_tail()"
> > 
> > (On a side note, doing so is quite complex, and I understand why nobody
> > wants to really ditch the atomic helpers)
> 
> But most drivers do overwrite parts of it, which is kinda my point:
> Everyone still keeps using at least some parts of atomic, and benefitting
> from the opinionated guidelines those have.

Ah, yes, reusing the existing helpers to tweak the behaviour is indeed
fine (although based on my experience with the rcar-du driver, it often
trades one set of issues for another, but that may be because more
helpers would be needed for different classes of devices).

> >> And I think bridge helpers probably also need fairly opinioated, simply to
> >> make sure that all the bridge drivers work together in a coherent fashion.
> >> If we allow too much flexibility everyone bends the rules a bit, and
> >> nothing fits.
> > 
> > I agree with you on that.
> > 
> >> Wrt your question: One option would be to do the same thing like shared
> >> interrupt line handlers. As soon as the first interrupt handler says "I'
> >> ve handled this one" we stop processing. But that might lead to more
> >> confusion about who's responsible for an interrupt.
> > 
> > I don't think that's a good idea, as more than one consumer may need to
> > process the event. A real life example with two consumers would be a CEC
> > controller part of a bridge needing to get informed about HDMI
> > plug/unplug to set the CEC address in the device (this notification is
> > handled through the bridge notification operation), and the display
> > driver needing to report HPD to the DRM core.
> > 
> > As I'm still not sure why you think I should replace the existing
> > implementation with your above proposal, so I'll keep the existing code
> > for the v2 that I will post soon until we complete this discussion.
> > 
> > To hopefully help with the discussion, I would like to repeat my main
> > argument : moving the dispatching of the notification to
> > drm_bridge_hpd_notify() sets the order in which components (bridges,
> > encoders, drivers) are notified in stone, while keeping it in the
> > drm_bridge_connector helper allows drivers to not use the helper and
> > come up with a different implementation that fits their needs better.
> 
> That "set things in stone" is actually what I want. Well, not stone, but
> really clear semantics. You're essentially creating a notifier, except
> there's only every one notified entity at most. Ime bad things happen with
> notifiers, it's unavoidable.
> 
> So maybe what we need instead is a bridge_hpd_process callback (in
> mode_config.helpers or wherever, or on the encoder, dunno), with the above
> default implementation. But you can then overwrite it.

That sounds reasonable, but I think I'd make it a connector callback
instead, as it's really about a chain of bridges + connector. What do
you think ?

> Or another option would be that at least on DT platforms, DT gets to spec
> the entire hpd routing.
> 
> I just fear that if we let bridge drivers all manage this themselves we'll
> end up with a formadible mess of slight incompatibilities.

Bridges drivers don't manage this themselves in the current proposal :-)
The behaviour is implemented in a helper, which registers itself as a
listener for HPD. Drivers don't have to use that helper.

I can replace that registration mechanism with a connector call already
if you prefer.

> >>> I would like to remind everybody that this series isn't the last I will
> >>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> >>> open to suggestions, and can address problems on top of these patches,
> >>> provided obviously that this series doesn't go in the wrong direction.
> >>> I'm of course also willing to rework this series, but given the amount
> >>> of work we have in the drm_bridge realm, I can't fix everything in one
> >>> go :-)
> >>> 
> >>>>>>>> - it resembles hardware wires :)
> >>>>>>>
> >>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>>>> interested in that hpd singal. This includes:
> >>>>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>>>   uevent to the driver.
> >>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>>>  
> >>>>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>>>> what he wants to do here.
> >>> 
> >>> That's correct, and that's what I was trying to implement :-) The
> >>> notification, in this patch series, goes from the producer bridge to a
> >>> central place (namely the connector, with a helper implementation
> >>> available as part of this series, but custom implementations in display
> >>> drivers are fine if needed) that then dispatches the notification to all
> >>> bridges (through the .lost_hotplug() operation, which we could replace
> >>> by an .hpd_notify() operation) for the first two purposes listed above,
> >>> and then to the overall driver. The only thing I don't support yet is
> >>> dispatching to the display pipeline (item 4 in the list above) as I had
> >>> no need for that, and didn't want to develop an API with no user. This
> >>> would however not be difficult to do when needed, the need is taken into
> >>> account in the proposed implementation.
> >>> 
> >>>>>> I do not know the full picture, but the solution where particular bridge
> >>>>>> notifies everything unconditionally seems to me much less flexible.
> >>>>>>
> >>>>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>>>> will mimic your scenario.
> >>>>>>
> >>>>>> But there are also other scenarios where bridge does not want to
> >>>>>> propagate signal, because for example:
> >>>>>>
> >>>>>> - it wants to wait for other sinks to wake up,
> >>>>>
> >>>>> The other sink can just do that in their hpd callback.
> >>>>>
> >>>>>> - it propagates HPD signal via hardware wire,
> >>>>>
> >>>>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>>>> the wire/hw hpd interrupt.
> >>>> 
> >>>> If it should ignore HPD, why it should receive it at all - it is
> >>>> unnecessary noise. And I am afraid with more complicated pipelines it
> >>>> will be impossible for particular component (bridge/encoder/whatever) to
> >>>> distinguish if HPD notification which came from non-directly connected
> >>>> component should be ignored or not.
> >>>> 
> >>>>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>>>> device.
> >>>>>
> >>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>>>> board?
> >>>> 
> >>>> Bridge can have external connectors, and the user can connect there
> >>>> anything.
> >>>> 
> >>>>>> In general HPD is input signal for notify of state changes on particular
> >>>>>> bus, in case of typical video bridge on its output video bus.
> >>>>>>
> >>>>>> In case of bridges they have also input video buses, and they can send
> >>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>>>> if for most cases they looks similar.
> >>>>>
> >>>>> Ah, I think this is a problem we will eventually have. But it's not
> >>>>> something we're currently solving here at all I think.
> >>>> 
> >>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >>>> line, so this is not something from far future. And I guess with HPD
> >>>> broadcasting it could be racy/error prone, for example EDID reading can
> >>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >>>> controller via hw wires also).
> >>>> 
> >>>>>>>> And regarding implementation:
> >>>>>>>>
> >>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>>>
> >>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>>>
> >>>>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>>>> source we should locate it by parsing notification chain (what about
> >>>>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>>>
> >>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>>>
> >>>>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>>>> listener.
> >>>>>>
> >>>>>> Do we have real life examples?
> >>>>>>
> >>>>>> I want to distinguish two situations:
> >>>>>>
> >>>>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>>>
> >>>>>> - another device wants to know if output bus of the bridge has changed
> >>>>>> state.
> >>>>>
> >>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>>>> bridges can exchange state and information about each another. hpd is
> >>>>> about the physical world, i.e. "is there a cable plugged into the port
> >>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>>>> fun stuff like that, we have the atomic_check machinery for this.
> >>>> 
> >>>> My question was if we have real examples that upstream device requires
> >>>> knowledge about state of output line of the bridge?
> >>>> 
> >>>> To be more precise, we have following display pipeline:
> >>>> 
> >>>> A-->B-->C
> >>>> 
> >>>> And C sends HPD to B (ie signal that state of line between B and C
> >>>> changed). Does A really wants to know this information? or it should
> >>>> just need to know if state of line A-->B changed?
> >>> 
> >>> There's one real life example, where A is an HDMI encoder, B is an HDMI
> >>> ESD protector and level shifter, and C is the physical HDMI connector.
> >>> When the HDMI cable is unplugged, the CEC controller part of A needs to
> >>> be notified in order to reset the CEC state machine. One could however
> >>> argue that in that case the A-B link state changes too, but the
> >>> important part is that HPD detection is not performed by A, while A
> >>> needs to be informed of lost hotplug.
> >>> 
> >>>>>>> You seem to have some other idea here.
> >>>>>>>
> >>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>> +}
> >>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>>>  	 */
> >>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>>>> +	 * output.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>>>> presence of another one?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>>>> and connector->edid correctly.
> >>>>>>>>>>>
> >>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>>>> correctly updated.
> >>>>>>>>>>>
> >>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>>>
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>  };
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>>  /**
> >>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>>>  };
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> +/**
> >>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>>>> + */
> >>>>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>>>> +};
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>>>   */
> >>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	int type;
> >>>>>>>>>>>>> +	/** private: */
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>>>  };
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>>>  
> >>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>> +			   void *data);
> >>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>>>> +
> >>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Aug. 26, 2019, 4:27 p.m. UTC | #34

Hi Andrzej,

On Thu, Aug 22, 2019 at 02:17:16PM +0200, Andrzej Hajda wrote:
> On 20.08.2019 00:45, Laurent Pinchart wrote:
> > On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
> >> On 14.08.2019 14:40, Daniel Vetter wrote:
> >>> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
> >>>> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
> >>>>> On 11.08.2019 00:43, Laurent Pinchart wrote:
> >>>>>> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> >>>>>>> On 08.08.2019 21:32, Laurent Pinchart wrote:
> >>>>>>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >>>>>>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>>>>>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>>>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>>>>>> Hi Laurent,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>>>>>>>>> panel is very painful.
> >>>>>>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> More comments inlined.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>>>>>>>>> data:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>>>>>>>>   retrieval operations
> >>>>>>>>>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>>>>>>>>> operation's callback?
> >>>>>>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Add and document these.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>>>>>>>>> bridges.
> >>>>>>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>>>>>>>>   */
> >>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>>>  {
> >>>>>>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>>>>>>>>> + * the bridge.
> >>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>>>>>>>>> bridge attach:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>>>>>>>>> without big sacrifices.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>>>>>>> +			   void *data)
> >>>>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +unlock:
> >>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>>>>>>>>> 			continue;
> >>>>>>>>>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>>>>>>>>> 	}
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 	dev = bridge->dev
> >>>>>>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>>>>>>>>> hpd they want/need.
> >>>>>>>>>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It looks more generic for me.
> >>>>>>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>>>>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>>>>>>>> Regarding general idea:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>>>>>>>>> source.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And I prefer 1st approach, why:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - is more generic, for example if bridge send signal to two
> >>>>>>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>>>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>>>>>>>> If there will be two consumers, there will be two bridge attachments,
> >>>>>>>>>>> thus there will be two notifications, it should work.
> >>>>>>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>>>>>>>>> callback is registered on the produce bridge, not on the consumer bridge
> >>>>>>>>>> (or I'm totallly misreading what Laurent does here).
> >>>>>>>>> I have assumed that if devices exposes two hardware sink interfaces it
> >>>>>>>>> will expose two separate bridges - of course it will not work with
> >>>>>>>>> "bridge chaining" thing, but this is a different story.
> >>>>>>>> Daniel is right that the current implementation only allows one
> >>>>>>>> consumer. This is however not a limitation of the API, but of its
> >>>>>>>> implementation, as I only needed a single consumer. The helpers in this
> >>>>>>>> series ensure that neither the consumer nor the producer poke in the
> >>>>>>>> drm_bridge structure to call back to the HPD handler:
> >>>>>>>>
> >>>>>>>> - The consumer calls drm_bridge_hpd_enable() and
> >>>>>>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
> >>>>>>>>   behaviour if desired without changes to the consumer.
> >>>>>>>>
> >>>>>>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >>>>>>>>   which could also easily accommodate reference-counting in the drm
> >>>>>>>>   bridge core without changes to the producer.
> >>>>>>>>
> >>>>>>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >>>>>>>>   easily be extended to support multiple consumers without changes to
> >>>>>>>>   the producer.
> >>>>>>>>
> >>>>>>>> This is actually my second version of the HPD mechanism. The first
> >>>>>>>> version was never posted, poked into drm_bridge, and required the
> >>>>>>>> producer to be aware of the callbacks. After discussing this privately
> >>>>>>>> with Daniel, I came up with the implementation in this series that,
> >>>>>>>> while not supporting multiple consumers now, makes it easy to extend
> >>>>>>>> later without minimal effort.
> >>>>>>>>
> >>>>>>>> Daniel's proposed implementation above looks reasonable to me, provided
> >>>>>>>> we can iterate over the bridges in an order that don't depend on the
> >>>>>>>> position of the producer in the chain (should be easy to solve by
> >>>>>>>> starting at the encoder for instance). It however looks a bit like a
> >>>>>>>> midlayer to me :-) That's why I have a similar implementation in the
> >>>>>>>> connector-bridge helper, which could be extended to call
> >>>>>>>> encoder->helper_private->bridge_hpd_notify() and
> >>>>>>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> >>>>>>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> >>>>>>>> drm_bridge_hpd_notify() would on the other hand set the notification
> >>>>>>>> sequence towards the encoder and driver in stone. Daniel, do you think
> >>>>>>>> that would be better ?
> >>>>>>>>
> >>>>>>>> I would like to remind everybody that this series isn't the last I will
> >>>>>>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> >>>>>>>> open to suggestions, and can address problems on top of these patches,
> >>>>>>>> provided obviously that this series doesn't go in the wrong direction.
> >>>>>>>> I'm of course also willing to rework this series, but given the amount
> >>>>>>>> of work we have in the drm_bridge realm, I can't fix everything in one
> >>>>>>>> go :-)
> >>>>>>>>
> >>>>>>>>>>>>> - it resembles hardware wires :)
> >>>>>>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>>>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>>>>>>>>> interested in that hpd singal. This includes:
> >>>>>>>>>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>>>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>>>>>>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>>>>>>>>   uevent to the driver.
> >>>>>>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>>>>>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>>>>>>>>  
> >>>>>>>>>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>>>>>>>>> what he wants to do here.
> >>>>>>>> That's correct, and that's what I was trying to implement :-) The
> >>>>>>>> notification, in this patch series, goes from the producer bridge to a
> >>>>>>>> central place (namely the connector, with a helper implementation
> >>>>>>>> available as part of this series, but custom implementations in display
> >>>>>>>> drivers are fine if needed) that then dispatches the notification to all
> >>>>>>>> bridges (through the .lost_hotplug() operation, which we could replace
> >>>>>>>> by an .hpd_notify() operation) for the first two purposes listed above,
> >>>>>>>> and then to the overall driver. The only thing I don't support yet is
> >>>>>>>> dispatching to the display pipeline (item 4 in the list above) as I had
> >>>>>>>> no need for that, and didn't want to develop an API with no user. This
> >>>>>>>> would however not be difficult to do when needed, the need is taken into
> >>>>>>>> account in the proposed implementation.
> >>>>>>>>
> >>>>>>>>>>> I do not know the full picture, but the solution where particular bridge
> >>>>>>>>>>> notifies everything unconditionally seems to me much less flexible.
> >>>>>>>>>>>
> >>>>>>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>>>>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>>>>>>>>> will mimic your scenario.
> >>>>>>>>>>>
> >>>>>>>>>>> But there are also other scenarios where bridge does not want to
> >>>>>>>>>>> propagate signal, because for example:
> >>>>>>>>>>>
> >>>>>>>>>>> - it wants to wait for other sinks to wake up,
> >>>>>>>>>>>
> >>>>>>>>>> The other sink can just do that in their hpd callback.
> >>>>>>>>>>
> >>>>>>>>>>> - it propagates HPD signal via hardware wire,
> >>>>>>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>>>>>>>>> the wire/hw hpd interrupt.
> >>>>>>>>>>
> >>>>>>>>> If it should ignore HPD, why it should receive it at all - it is
> >>>>>>>>> unnecessary noise. And I am afraid with more complicated pipelines it
> >>>>>>>>> will be impossible for particular component (bridge/encoder/whatever) to
> >>>>>>>>> distinguish if HPD notification which came from non-directly connected
> >>>>>>>>> component should be ignored or not.
> >>>>>>>>>
> >>>>>>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>>>>>>>>> device.
> >>>>>>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>>>>>>>>> board?
> >>>>>>>>> Bridge can have external connectors, and the user can connect there
> >>>>>>>>> anything.
> >>>>>>>>>
> >>>>>>>>>>> In general HPD is input signal for notify of state changes on particular
> >>>>>>>>>>> bus, in case of typical video bridge on its output video bus.
> >>>>>>>>>>>
> >>>>>>>>>>> In case of bridges they have also input video buses, and they can send
> >>>>>>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>>>>>>>>> if for most cases they looks similar.
> >>>>>>>>>> Ah, I think this is a problem we will eventually have. But it's not
> >>>>>>>>>> something we're currently solving here at all I think.
> >>>>>>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >>>>>>>>> line, so this is not something from far future. And I guess with HPD
> >>>>>>>>> broadcasting it could be racy/error prone, for example EDID reading can
> >>>>>>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >>>>>>>>> controller via hw wires also).
> >>>>>>>>>
> >>>>>>>>>>>>> And regarding implementation:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>>>>>>>>> source we should locate it by parsing notification chain (what about
> >>>>>>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>>>>>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>>>>>>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>>>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>>>>>>>>> listener.
> >>>>>>>>>>> Do we have real life examples?
> >>>>>>>>>>>
> >>>>>>>>>>> I want to distinguish two situations:
> >>>>>>>>>>>
> >>>>>>>>>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>>>>>>>>
> >>>>>>>>>>> - another device wants to know if output bus of the bridge has changed
> >>>>>>>>>>> state.
> >>>>>>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>>>>>>>>> bridges can exchange state and information about each another. hpd is
> >>>>>>>>>> about the physical world, i.e. "is there a cable plugged into the port
> >>>>>>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>>>>>>>>> fun stuff like that, we have the atomic_check machinery for this.
> >>>>>>>>> My question was if we have real examples that upstream device requires
> >>>>>>>>> knowledge about state of output line of the bridge?
> >>>>>>>>>
> >>>>>>>>> To be more precise, we have following display pipeline:
> >>>>>>>>>
> >>>>>>>>> A-->B-->C
> >>>>>>>>>
> >>>>>>>>> And C sends HPD to B (ie signal that state of line between B and C
> >>>>>>>>> changed). Does A really wants to know this information? or it should
> >>>>>>>>> just need to know if state of line A-->B changed?
> >>>>>>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
> >>>>>>>> ESD protector and level shifter, and C is the physical HDMI connector.
> >>>>>>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
> >>>>>>>> be notified in order to reset the CEC state machine. One could however
> >>>>>>>> argue that in that case the A-B link state changes too, but the
> >>>>>>>> important part is that HPD detection is not performed by A, while A
> >>>>>>>> needs to be informed of lost hotplug.
> >>>>>>> I have no full picture but I guess in this case C sends HPD to B using
> >>>>>>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
> >>>>>>> say that B does not participate in HPD transmission/forwarding,
> >>>>>> No, in this case A doesn't receive any hardware HPD signal, it requires
> >>>>>> HPD notification through software.
> >>>>>>
> >>>>>>> some shifters with 'advanced power saving' can even perform wake-up of
> >>>>>>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
> >>>>>>> to A is indeed different than HPD sent from C to B.
> >>>>>>>
> >>>>>>> Btw, with the above logic of propagation of HPD callback (proposed by
> >>>>>>> Daniel) I guess it will work this way:
> >>>>>>>
> >>>>>>> - A will receive HPD signal via HW,
> >>>>>>>
> >>>>>>> - then B and C will receive HPD callback via framework.
> >>>>>>>
> >>>>>>> Am I right?
> >>>>>> It's the other way around.
> >>>>>>
> >>>>>> In this case the HPD signal from the connector (C) is routed to an input
> >>>>>> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
> >>>>>> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
> >>>>>> IRQ and receive the hardware HPD notification. The driver for the HDMI
> >>>>>> encoder (A) needs to receive HPD notification in software, through the
> >>>>>> framework.
> >>>>> If this is GPIO I wonder why do not query this gpio by encoder directly,
> >>>>> rules of ownership of such gpios seems to be grey area, so in such case
> >>>>> I would advise to put it in the driver who really needs it.
> >>>>>
> >>>>> This way it will be much simpler.
> >>>> First to fall, multiple drivers may need to be informed of HPD events
> >>>> coming from a GPIO, so we would need to duplicate it in multiple places,
> >>>> and I don't think the GPIO framework allows acquiring a GPIO multiple
> >>>> times.
> >>>>
> >>>> Then, the GPIO is described in DT, and DT doesn't care about which
> >>>> driver needs HPD events. DT specifies the GPIO in the node of the device
> >>>> it belongs to, this is defined in DT bindings, and must be the same on
> >>>> all boards, while depending on the board different devices may need to
> >>>> be informed of HPD events.
> >>>>
> >>>> For those two reasons HPD GPIO handling and consumption of HPD events
> >>>> can't always be grouped in the same driver.
> >>>>
> >>>>> Going back to HPD notifications, as I said earlier broadcasting HPD
> >>>>> notification unconditionally to every member of the chain with hope that
> >>>>> the member will be able to filter-out undesired notification seems to me
> >>>>> incorrect - maybe it can solve some problems but is not flexible enough
> >>>>> to be usable in other scenarios.
> >>>>>
> >>>>> If my arguments do not convince you please just continue with your
> >>>>> ideas, we can always add NO_HPD_BROADCAST somewhere :)
> >>>> :-) I would like to understand the problems you're referring to though,
> >>>> and hopefully solve them. If you could describe one of the scenarios
> >>>> where you think this mechanism wouldn't be usable that would help. In
> >>>> the meantime I will post a new version of the series with these
> >>>> operations kept as-is to get the rest of the patches reviewed.
> >>> See my little thing about midlayers, I think midlayers with lots of flags
> >>> for everything aren't a good idea. They should be more opinionated about
> >>> how things work.
> >>>
> >>> So if there's a case where this broadcasting of various things doesn't
> >>> work, let's dig into it.
> >>>
> >> OK, almost real life example:
> >>
> >> A -> B -> C
> >>
> >> A - RGB/HDMI converter,
> >>
> >> B - HDMI/MHL converter,
> >>
> >> C - uUSB controller (MUIC).
> >>
> >>
> >> C - detects presence of MHL sink and routes MHL lines to B in such case.
> >>
> >> B - has no hardware logic to detect HPD, but it's firmware can read EDID
> >> from downstream component via HW lines and it has hardware lines to
> >> upstream component to send EDID,
> >>
> >> A - can read EDID from B via hardware lines, but does not have hardware HPD.
> > 
> > It probably doesn't matter much for the overall discussion, but out of
> > curiosity, does B have a CBUS interface towards C and a DDC (I2C)
> > interface towards A ?
> 
> Yes, but C (MUIC) is not MHL aware, beside initial 1K resistance
> detection on ID pin, AFAIK.
> 
> >  And does A read the EDID on DDC and expose it
> > towards the SoC through a custom protocol (for instance as the ADV7511
> > does), or does it forward the DDC lines to the SoC ?
> >
> >> So how it should work (according to specification):
> >>
> >> 1. C detects MHL sink.
> >>
> >> 2. C switches his mux to route lines to B.
> >>
> >> 3. C sends HPD notification to B.
> >>
> >> 4. B powers on, its firmware reads EDID from downstream lines (possibly
> >> adjusting it) and makes it available to upstream component A.
> >>
> >> 5. B sends HPD notification to A.
> >>
> >>
> >> I do not know how it could work with HPD broadcasting.
> >>
> >> I guess C should be HPD provider, but in case of HPD broadcasting A and
> >> B would receive notification in the same time, as a result A would start
> >> reading EDID too early - fail.
> >
> > That's an interesting case indeed. Now I understand what you meant
> > earlier.
> >
> > The HPD notification from C to B is purely internal, and should not be
> > visible from a DRM/KMS point of view. It just happens that this hardware
> > setup has a more complex HPD sequence that requires software
> > intervention in the middle of the sequence. As such, if we forget about
> > this patch series for a minute, C would need a custom API to send MHL
> > notification to B, and the HPD for DRM/KMS would be notified by B, right
> > ?
> 
> I just want to convince you that maybe all HPD signals
> (hardware/software) are purely internal (ie they should be handled only
> by upstream devices), and the hotplug event should be sent to
> userspace/drm_core only when WHOLE pipeline is ready to query modes
> (i2c/sideband channels/whatever is functional).

I think that most HPD events are not internal, and that the above case
is more an exception than a rule :-) It should however be supported, and
I agree that HPD should be notified to the DRM core only when it has
traversed the whole pipeline, yes.

I'd like to keep bridge drivers simple though, and avoid requiring
manual HPD propagation as I think that's the common case. That's why I
proposed blocking the propagation below. What do you think ?

This also means that, if we switch to a model where propagation can be
disabled, a bridge will only notify upstream (closer to the CRTC)
bridges. If, in a A-B-C chain, bridge B receives the external HPD event,
then bridge C would never be notified. Do you think that could be an
issue ?

> > I think it's possible to handle both the MHL notification and the
> > user-visible HPD notification through the same bridge API, provided that
> > we offer a way for a bridge to block forwarding of the HPD notification.
> > This will also require calling the HPD notifiers on bridges in the sink
> > to source order. Both are doable, the bridge HPD notifier operation
> > could return a bool that blocks propagation of the notification. Would
> > that work for you ?
> 
> It could work, in this case.
> 
> But it will still have problems with non-linear pipelines - where stream
> is split to two or more bridges/panels.

I agree, but that's not supported by the bridge API for now. I'm not
sure I'm looking forward to dealing with this, but I think it will be
needed :-)

> >>>>>>>>>>>> You seem to have some other idea here.
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>>>>>>>>  	 */
> >>>>>>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>>>>>>>>> +	 * output.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>>>>>>>>> presence of another one?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>>>>>>>>> and connector->edid correctly.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>>>>>>>>> correctly updated.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>>>>>>>>   */
> >>>>>>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	int type;
> >>>>>>>>>>>>>>>>>> +	/** private: */
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>>>>>>> +			   void *data);
> >>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>>>>>>>>  					u32 connector_type);

Andrzej Hajda Aug. 29, 2019, 4:48 p.m. UTC | #35

On 26.08.2019 18:27, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Thu, Aug 22, 2019 at 02:17:16PM +0200, Andrzej Hajda wrote:
>> On 20.08.2019 00:45, Laurent Pinchart wrote:
>>> On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
>>>> On 14.08.2019 14:40, Daniel Vetter wrote:
>>>>> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
>>>>>> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
>>>>>>> On 11.08.2019 00:43, Laurent Pinchart wrote:
>>>>>>>> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
>>>>>>>>> On 08.08.2019 21:32, Laurent Pinchart wrote:
>>>>>>>>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
>>>>>>>>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
>>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>>>>>>>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>>>>>>>>>>>>>>>>>>> Hi Laurent,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
>>>>>>>>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
>>>>>>>>>>>>>>>>>>> panel is very painful.
>>>>>>>>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>>>>>>>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>>>>>>>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
>>>>>>>>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> More comments inlined.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>>>>>>>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
>>>>>>>>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>>>>>>>>>>>>>>>>>>> data:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>>>>>>>>>>>>>>>>>>>   retrieval operations
>>>>>>>>>>>>>>>>>>>> - Bitmask of supported operations
>>>>>>>>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
>>>>>>>>>>>>>>>>>>> operation's callback?
>>>>>>>>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>>>>>>>>>>>>>>>>> add, generally good excuse to not have to think through the design between
>>>>>>>>>>>>>>>>>> different parts of drivers - "just" add another flag.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> - Bridge output type
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Add and document these.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
>>>>>>>>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
>>>>>>>>>>>>>>>>>>>> bridges.
>>>>>>>>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
>>>>>>>>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
>>>>>>>>>>>>>>>>>>> right? More comments about it later.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
>>>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
>>>>>>>>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
>>>>>>>>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
>>>>>>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>>>>>>>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>>>>>>>>>>>>>>>>>>>   */
>>>>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>>>>>  {
>>>>>>>>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
>>>>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
>>>>>>>>>>>>>>>>>>>>  	list_del_init(&bridge->list);
>>>>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>>  }
>>>>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>>>>>> + * @cb: hot-plug detection callback
>>>>>>>>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
>>>>>>>>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
>>>>>>>>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
>>>>>>>>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
>>>>>>>>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
>>>>>>>>>>>>>>>>>>>> + * the bridge.
>>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
>>>>>>>>>>>>>>>>>>> bridge attach:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> bridge->hpd_cb = cb;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> bridge->hpd_data = data;
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ret = drm_bridge_attach(...);
>>>>>>>>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
>>>>>>>>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
>>>>>>>>>>>>>>>>>>> without big sacrifices.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>>>>>>>>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>>>>>>>>> +			   void *data)
>>>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
>>>>>>>>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>>>>>>>>>>>>>>>>>>> +		goto unlock;
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
>>>>>>>>>>>>>>>>>>>> +	bridge->hpd_data = data;
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +unlock:
>>>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
>>>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
>>>>>>>>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
>>>>>>>>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
>>>>>>>>>>>>>>>>>>>> + * output status change occurs.
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
>>>>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
>>>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
>>>>>>>>>>>>>>>>>>>> +		return;
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
>>>>>>>>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
>>>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
>>>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
>>>>>>>>>>>>>>>>>>>> + * @status: output connection status
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
>>>>>>>>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
>>>>>>>>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
>>>>>>>>>>>>>>>>>>>> + *
>>>>>>>>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
>>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status)
>>>>>>>>>>>>>>>>>>>> +{
>>>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +	if (bridge->hpd_cb)
>>>>>>>>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
>>>>>>>>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
>>>>>>>>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
>>>>>>>>>>>>>>>>>> 		if (tmp_bridge == bridge)
>>>>>>>>>>>>>>>>>> 			continue;
>>>>>>>>>>>>>>>>>> 		if (bridge->hpd_notify);
>>>>>>>>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
>>>>>>>>>>>>>>>>>> 	}
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
>>>>>>>>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
>>>>>>>>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 	dev = bridge->dev
>>>>>>>>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
>>>>>>>>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
>>>>>>>>>>>>>>>>>> hpd they want/need.
>>>>>>>>>>>>>>>>> As I understand you want to notify every member of the pipeline.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think it should be enough to notify only the source, and then source
>>>>>>>>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It looks more generic for me.
>>>>>>>>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
>>>>>>>>>>>>>>>> the one from Laurent? Kinda confused here.
>>>>>>>>>>>>>>> Regarding general idea:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
>>>>>>>>>>>>>>> source.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. Your is to notify all other bridges and encoder.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And I prefer 1st approach, why:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - the source can decide if/when and to who propagate the signal,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - is more generic, for example if bridge send signal to two
>>>>>>>>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
>>>>>>>>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
>>>>>>>>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
>>>>>>>>>>>>> If there will be two consumers, there will be two bridge attachments,
>>>>>>>>>>>>> thus there will be two notifications, it should work.
>>>>>>>>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
>>>>>>>>>>>> callback is registered on the produce bridge, not on the consumer bridge
>>>>>>>>>>>> (or I'm totallly misreading what Laurent does here).
>>>>>>>>>>> I have assumed that if devices exposes two hardware sink interfaces it
>>>>>>>>>>> will expose two separate bridges - of course it will not work with
>>>>>>>>>>> "bridge chaining" thing, but this is a different story.
>>>>>>>>>> Daniel is right that the current implementation only allows one
>>>>>>>>>> consumer. This is however not a limitation of the API, but of its
>>>>>>>>>> implementation, as I only needed a single consumer. The helpers in this
>>>>>>>>>> series ensure that neither the consumer nor the producer poke in the
>>>>>>>>>> drm_bridge structure to call back to the HPD handler:
>>>>>>>>>>
>>>>>>>>>> - The consumer calls drm_bridge_hpd_enable() and
>>>>>>>>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
>>>>>>>>>>   behaviour if desired without changes to the consumer.
>>>>>>>>>>
>>>>>>>>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
>>>>>>>>>>   which could also easily accommodate reference-counting in the drm
>>>>>>>>>>   bridge core without changes to the producer.
>>>>>>>>>>
>>>>>>>>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
>>>>>>>>>>   easily be extended to support multiple consumers without changes to
>>>>>>>>>>   the producer.
>>>>>>>>>>
>>>>>>>>>> This is actually my second version of the HPD mechanism. The first
>>>>>>>>>> version was never posted, poked into drm_bridge, and required the
>>>>>>>>>> producer to be aware of the callbacks. After discussing this privately
>>>>>>>>>> with Daniel, I came up with the implementation in this series that,
>>>>>>>>>> while not supporting multiple consumers now, makes it easy to extend
>>>>>>>>>> later without minimal effort.
>>>>>>>>>>
>>>>>>>>>> Daniel's proposed implementation above looks reasonable to me, provided
>>>>>>>>>> we can iterate over the bridges in an order that don't depend on the
>>>>>>>>>> position of the producer in the chain (should be easy to solve by
>>>>>>>>>> starting at the encoder for instance). It however looks a bit like a
>>>>>>>>>> midlayer to me :-) That's why I have a similar implementation in the
>>>>>>>>>> connector-bridge helper, which could be extended to call
>>>>>>>>>> encoder->helper_private->bridge_hpd_notify() and
>>>>>>>>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
>>>>>>>>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
>>>>>>>>>> drm_bridge_hpd_notify() would on the other hand set the notification
>>>>>>>>>> sequence towards the encoder and driver in stone. Daniel, do you think
>>>>>>>>>> that would be better ?
>>>>>>>>>>
>>>>>>>>>> I would like to remind everybody that this series isn't the last I will
>>>>>>>>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
>>>>>>>>>> open to suggestions, and can address problems on top of these patches,
>>>>>>>>>> provided obviously that this series doesn't go in the wrong direction.
>>>>>>>>>> I'm of course also willing to rework this series, but given the amount
>>>>>>>>>> of work we have in the drm_bridge realm, I can't fix everything in one
>>>>>>>>>> go :-)
>>>>>>>>>>
>>>>>>>>>>>>>>> - it resembles hardware wires :)
>>>>>>>>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
>>>>>>>>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
>>>>>>>>>>>>>> interested in that hpd singal. This includes:
>>>>>>>>>>>>>> - Other bridges, e.g. if they provide CEC support.
>>>>>>>>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
>>>>>>>>>>>>>> - Overall driver, so it can update the modes/connector status and send the
>>>>>>>>>>>>>>   uevent to the driver.
>>>>>>>>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
>>>>>>>>>>>>>>   shut down/re-enable the pipe because $reasons.
>>>>>>>>>>>>>>  
>>>>>>>>>>>>>> That's at least my understanding from lots of chats with Laurent about
>>>>>>>>>>>>>> what he wants to do here.
>>>>>>>>>> That's correct, and that's what I was trying to implement :-) The
>>>>>>>>>> notification, in this patch series, goes from the producer bridge to a
>>>>>>>>>> central place (namely the connector, with a helper implementation
>>>>>>>>>> available as part of this series, but custom implementations in display
>>>>>>>>>> drivers are fine if needed) that then dispatches the notification to all
>>>>>>>>>> bridges (through the .lost_hotplug() operation, which we could replace
>>>>>>>>>> by an .hpd_notify() operation) for the first two purposes listed above,
>>>>>>>>>> and then to the overall driver. The only thing I don't support yet is
>>>>>>>>>> dispatching to the display pipeline (item 4 in the list above) as I had
>>>>>>>>>> no need for that, and didn't want to develop an API with no user. This
>>>>>>>>>> would however not be difficult to do when needed, the need is taken into
>>>>>>>>>> account in the proposed implementation.
>>>>>>>>>>
>>>>>>>>>>>>> I do not know the full picture, but the solution where particular bridge
>>>>>>>>>>>>> notifies everything unconditionally seems to me much less flexible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
>>>>>>>>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
>>>>>>>>>>>>> will mimic your scenario.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But there are also other scenarios where bridge does not want to
>>>>>>>>>>>>> propagate signal, because for example:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - it wants to wait for other sinks to wake up,
>>>>>>>>>>>>>
>>>>>>>>>>>> The other sink can just do that in their hpd callback.
>>>>>>>>>>>>
>>>>>>>>>>>>> - it propagates HPD signal via hardware wire,
>>>>>>>>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
>>>>>>>>>>>> the wire/hw hpd interrupt.
>>>>>>>>>>>>
>>>>>>>>>>> If it should ignore HPD, why it should receive it at all - it is
>>>>>>>>>>> unnecessary noise. And I am afraid with more complicated pipelines it
>>>>>>>>>>> will be impossible for particular component (bridge/encoder/whatever) to
>>>>>>>>>>> distinguish if HPD notification which came from non-directly connected
>>>>>>>>>>> component should be ignored or not.
>>>>>>>>>>>
>>>>>>>>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
>>>>>>>>>>>>> device.
>>>>>>>>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
>>>>>>>>>>>> board?
>>>>>>>>>>> Bridge can have external connectors, and the user can connect there
>>>>>>>>>>> anything.
>>>>>>>>>>>
>>>>>>>>>>>>> In general HPD is input signal for notify of state changes on particular
>>>>>>>>>>>>> bus, in case of typical video bridge on its output video bus.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In case of bridges they have also input video buses, and they can send
>>>>>>>>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
>>>>>>>>>>>>> if for most cases they looks similar.
>>>>>>>>>>>> Ah, I think this is a problem we will eventually have. But it's not
>>>>>>>>>>>> something we're currently solving here at all I think.
>>>>>>>>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
>>>>>>>>>>> line, so this is not something from far future. And I guess with HPD
>>>>>>>>>>> broadcasting it could be racy/error prone, for example EDID reading can
>>>>>>>>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
>>>>>>>>>>> controller via hw wires also).
>>>>>>>>>>>
>>>>>>>>>>>>>>> And regarding implementation:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Your proposition is more straightforward, but if we want to notify only
>>>>>>>>>>>>>>> source we should locate it by parsing notification chain (what about
>>>>>>>>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
>>>>>>>>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
>>>>>>>>>>>>>> Uh I think we're not talking about the same thing really. My understanding
>>>>>>>>>>>>>> is that this callback is if someone (outside of this bridge) is interested
>>>>>>>>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
>>>>>>>>>>>>>> listener.
>>>>>>>>>>>>> Do we have real life examples?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I want to distinguish two situations:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - another device wants to know if input bus of the bridge has changed state,
>>>>>>>>>>>>>
>>>>>>>>>>>>> - another device wants to know if output bus of the bridge has changed
>>>>>>>>>>>>> state.
>>>>>>>>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
>>>>>>>>>>>> bridges can exchange state and information about each another. hpd is
>>>>>>>>>>>> about the physical world, i.e. "is there a cable plugged into the port
>>>>>>>>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
>>>>>>>>>>>> fun stuff like that, we have the atomic_check machinery for this.
>>>>>>>>>>> My question was if we have real examples that upstream device requires
>>>>>>>>>>> knowledge about state of output line of the bridge?
>>>>>>>>>>>
>>>>>>>>>>> To be more precise, we have following display pipeline:
>>>>>>>>>>>
>>>>>>>>>>> A-->B-->C
>>>>>>>>>>>
>>>>>>>>>>> And C sends HPD to B (ie signal that state of line between B and C
>>>>>>>>>>> changed). Does A really wants to know this information? or it should
>>>>>>>>>>> just need to know if state of line A-->B changed?
>>>>>>>>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
>>>>>>>>>> ESD protector and level shifter, and C is the physical HDMI connector.
>>>>>>>>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
>>>>>>>>>> be notified in order to reset the CEC state machine. One could however
>>>>>>>>>> argue that in that case the A-B link state changes too, but the
>>>>>>>>>> important part is that HPD detection is not performed by A, while A
>>>>>>>>>> needs to be informed of lost hotplug.
>>>>>>>>> I have no full picture but I guess in this case C sends HPD to B using
>>>>>>>>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
>>>>>>>>> say that B does not participate in HPD transmission/forwarding,
>>>>>>>> No, in this case A doesn't receive any hardware HPD signal, it requires
>>>>>>>> HPD notification through software.
>>>>>>>>
>>>>>>>>> some shifters with 'advanced power saving' can even perform wake-up of
>>>>>>>>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
>>>>>>>>> to A is indeed different than HPD sent from C to B.
>>>>>>>>>
>>>>>>>>> Btw, with the above logic of propagation of HPD callback (proposed by
>>>>>>>>> Daniel) I guess it will work this way:
>>>>>>>>>
>>>>>>>>> - A will receive HPD signal via HW,
>>>>>>>>>
>>>>>>>>> - then B and C will receive HPD callback via framework.
>>>>>>>>>
>>>>>>>>> Am I right?
>>>>>>>> It's the other way around.
>>>>>>>>
>>>>>>>> In this case the HPD signal from the connector (C) is routed to an input
>>>>>>>> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
>>>>>>>> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
>>>>>>>> IRQ and receive the hardware HPD notification. The driver for the HDMI
>>>>>>>> encoder (A) needs to receive HPD notification in software, through the
>>>>>>>> framework.
>>>>>>> If this is GPIO I wonder why do not query this gpio by encoder directly,
>>>>>>> rules of ownership of such gpios seems to be grey area, so in such case
>>>>>>> I would advise to put it in the driver who really needs it.
>>>>>>>
>>>>>>> This way it will be much simpler.
>>>>>> First to fall, multiple drivers may need to be informed of HPD events
>>>>>> coming from a GPIO, so we would need to duplicate it in multiple places,
>>>>>> and I don't think the GPIO framework allows acquiring a GPIO multiple
>>>>>> times.
>>>>>>
>>>>>> Then, the GPIO is described in DT, and DT doesn't care about which
>>>>>> driver needs HPD events. DT specifies the GPIO in the node of the device
>>>>>> it belongs to, this is defined in DT bindings, and must be the same on
>>>>>> all boards, while depending on the board different devices may need to
>>>>>> be informed of HPD events.
>>>>>>
>>>>>> For those two reasons HPD GPIO handling and consumption of HPD events
>>>>>> can't always be grouped in the same driver.
>>>>>>
>>>>>>> Going back to HPD notifications, as I said earlier broadcasting HPD
>>>>>>> notification unconditionally to every member of the chain with hope that
>>>>>>> the member will be able to filter-out undesired notification seems to me
>>>>>>> incorrect - maybe it can solve some problems but is not flexible enough
>>>>>>> to be usable in other scenarios.
>>>>>>>
>>>>>>> If my arguments do not convince you please just continue with your
>>>>>>> ideas, we can always add NO_HPD_BROADCAST somewhere :)
>>>>>> :-) I would like to understand the problems you're referring to though,
>>>>>> and hopefully solve them. If you could describe one of the scenarios
>>>>>> where you think this mechanism wouldn't be usable that would help. In
>>>>>> the meantime I will post a new version of the series with these
>>>>>> operations kept as-is to get the rest of the patches reviewed.
>>>>> See my little thing about midlayers, I think midlayers with lots of flags
>>>>> for everything aren't a good idea. They should be more opinionated about
>>>>> how things work.
>>>>>
>>>>> So if there's a case where this broadcasting of various things doesn't
>>>>> work, let's dig into it.
>>>>>
>>>> OK, almost real life example:
>>>>
>>>> A -> B -> C
>>>>
>>>> A - RGB/HDMI converter,
>>>>
>>>> B - HDMI/MHL converter,
>>>>
>>>> C - uUSB controller (MUIC).
>>>>
>>>>
>>>> C - detects presence of MHL sink and routes MHL lines to B in such case.
>>>>
>>>> B - has no hardware logic to detect HPD, but it's firmware can read EDID
>>>> from downstream component via HW lines and it has hardware lines to
>>>> upstream component to send EDID,
>>>>
>>>> A - can read EDID from B via hardware lines, but does not have hardware HPD.
>>> It probably doesn't matter much for the overall discussion, but out of
>>> curiosity, does B have a CBUS interface towards C and a DDC (I2C)
>>> interface towards A ?
>> Yes, but C (MUIC) is not MHL aware, beside initial 1K resistance
>> detection on ID pin, AFAIK.
>>
>>>  And does A read the EDID on DDC and expose it
>>> towards the SoC through a custom protocol (for instance as the ADV7511
>>> does), or does it forward the DDC lines to the SoC ?
>>>
>>>> So how it should work (according to specification):
>>>>
>>>> 1. C detects MHL sink.
>>>>
>>>> 2. C switches his mux to route lines to B.
>>>>
>>>> 3. C sends HPD notification to B.
>>>>
>>>> 4. B powers on, its firmware reads EDID from downstream lines (possibly
>>>> adjusting it) and makes it available to upstream component A.
>>>>
>>>> 5. B sends HPD notification to A.
>>>>
>>>>
>>>> I do not know how it could work with HPD broadcasting.
>>>>
>>>> I guess C should be HPD provider, but in case of HPD broadcasting A and
>>>> B would receive notification in the same time, as a result A would start
>>>> reading EDID too early - fail.
>>> That's an interesting case indeed. Now I understand what you meant
>>> earlier.
>>>
>>> The HPD notification from C to B is purely internal, and should not be
>>> visible from a DRM/KMS point of view. It just happens that this hardware
>>> setup has a more complex HPD sequence that requires software
>>> intervention in the middle of the sequence. As such, if we forget about
>>> this patch series for a minute, C would need a custom API to send MHL
>>> notification to B, and the HPD for DRM/KMS would be notified by B, right
>>> ?
>> I just want to convince you that maybe all HPD signals
>> (hardware/software) are purely internal (ie they should be handled only
>> by upstream devices), and the hotplug event should be sent to
>> userspace/drm_core only when WHOLE pipeline is ready to query modes
>> (i2c/sideband channels/whatever is functional).
> I think that most HPD events are not internal, and that the above case
> is more an exception than a rule :-) It should however be supported, and
> I agree that HPD should be notified to the DRM core only when it has
> traversed the whole pipeline, yes.
>
> I'd like to keep bridge drivers simple though, and avoid requiring
> manual HPD propagation as I think that's the common case. That's why I
> proposed blocking the propagation below. What do you think ?
>
> This also means that, if we switch to a model where propagation can be
> disabled, a bridge will only notify upstream (closer to the CRTC)
> bridges. If, in a A-B-C chain, bridge B receives the external HPD event,
> then bridge C would never be notified. Do you think that could be an
> issue ?


As I said somewhere earlier it should work.

Btw, since bridges are currently connected via single-linked list (just
drm_bridge->next), do you plan to switch to double linked list, to find
upstream bridge, or add logic to discover upstream bridge on the fly?


>
>>> I think it's possible to handle both the MHL notification and the
>>> user-visible HPD notification through the same bridge API, provided that
>>> we offer a way for a bridge to block forwarding of the HPD notification.
>>> This will also require calling the HPD notifiers on bridges in the sink
>>> to source order. Both are doable, the bridge HPD notifier operation
>>> could return a bool that blocks propagation of the notification. Would
>>> that work for you ?
>> It could work, in this case.
>>
>> But it will still have problems with non-linear pipelines - where stream
>> is split to two or more bridges/panels.
> I agree, but that's not supported by the bridge API for now. I'm not
> sure I'm looking forward to dealing with this, but I think it will be
> needed :-)


Currently there are two modes of usage of bridge:

- part of bridge chain,

- private bridge - it can be attached to other components via private
pointer, not drm_encoder->bridge, nor drm_bridge->next.

Non-linear pipelines can be ( and I guess they are ) implemented using
the latter.

Anyway if we want to extend bridge API it would be good to allow usage
of this API also with detached bridges.


Regards

Andrzej


>
>>>>>>>>>>>>>> You seem to have some other idea here.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
>>>>>>>>>>>>>>>>>>>> +}
>>>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>>  #ifdef CONFIG_OF
>>>>>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
>>>>>>>>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
>>>>>>>>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
>>>>>>>>>>>>>>>>>>>> @@ -23,8 +23,9 @@
>>>>>>>>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
>>>>>>>>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> -#include <linux/list.h>
>>>>>>>>>>>>>>>>>>>>  #include <linux/ctype.h>
>>>>>>>>>>>>>>>>>>>> +#include <linux/list.h>
>>>>>>>>>>>>>>>>>>>> +#include <linux/mutex.h>
>>>>>>>>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
>>>>>>>>>>>>>>>>>>>>  #include <drm/drm_modes.h>
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
>>>>>>>>>>>>>>>>>>>>  	 */
>>>>>>>>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @detect:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
>>>>>>>>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
>>>>>>>>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
>>>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @get_modes:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
>>>>>>>>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
>>>>>>>>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
>>>>>>>>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
>>>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>> +			 struct drm_connector *connector);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @get_edid:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
>>>>>>>>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
>>>>>>>>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
>>>>>>>>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
>>>>>>>>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
>>>>>>>>>>>>>>>>>>>> +	 * output.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
>>>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * RETURNS:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
>>>>>>>>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
>>>>>>>>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>> +				 struct drm_connector *connector);
>>>>>>>>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
>>>>>>>>>>>>>>>>>>> presence of another one?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
>>>>>>>>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
>>>>>>>>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
>>>>>>>>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
>>>>>>>>>>>>>>>>>> and connector->edid correctly.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
>>>>>>>>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
>>>>>>>>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
>>>>>>>>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
>>>>>>>>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
>>>>>>>>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
>>>>>>>>>>>>>>>>>> correctly updated.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
>>>>>>>>>>>>>>>>>> edid, which is not so awesome :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @lost_hotplug:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
>>>>>>>>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
>>>>>>>>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
>>>>>>>>>>>>>>>>>>>> +	 * HDMI bridges.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_enable:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
>>>>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
>>>>>>>>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_disable.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
>>>>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_disable:
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
>>>>>>>>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
>>>>>>>>>>>>>>>>>>>> +	 * connection status occurs.
>>>>>>>>>>>>>>>>>>>> +	 *
>>>>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
>>>>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
>>>>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
>>>>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
>>>>>>>>>>>>>>>>>>>>  	bool dual_link;
>>>>>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> +/**
>>>>>>>>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
>>>>>>>>>>>>>>>>>>>> + */
>>>>>>>>>>>>>>>>>>>> +enum drm_bridge_ops {
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
>>>>>>>>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
>>>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
>>>>>>>>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
>>>>>>>>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
>>>>>>>>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
>>>>>>>>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
>>>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
>>>>>>>>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
>>>>>>>>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
>>>>>>>>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
>>>>>>>>>>>>>>>>>>>> +};
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>>  /**
>>>>>>>>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
>>>>>>>>>>>>>>>>>>>>   */
>>>>>>>>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
>>>>>>>>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
>>>>>>>>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
>>>>>>>>>>>>>>>>>>>>  	void *driver_private;
>>>>>>>>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
>>>>>>>>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
>>>>>>>>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
>>>>>>>>>>>>>>>>>>>> +	 * identifies the type of connected display.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	int type;
>>>>>>>>>>>>>>>>>>>> +	/** private: */
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	struct mutex hpd_mutex;
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
>>>>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
>>>>>>>>>>>>>>>>>>>> +	/**
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
>>>>>>>>>>>>>>>>>>>> +	 * @hpd_cb.
>>>>>>>>>>>>>>>>>>>> +	 */
>>>>>>>>>>>>>>>>>>>> +	void *hpd_data;
>>>>>>>>>>>>>>>>>>>>  };
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
>>>>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
>>>>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
>>>>>>>>>>>>>>>>>>>> +			   void *data);
>>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
>>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
>>>>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status);
>>>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
>>>>>>>>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>>>>>>>>>>>>>>>>>>>  					u32 connector_type);

Laurent Pinchart Dec. 2, 2019, 3:40 p.m. UTC | #36

Hi Andrzej,

On Thu, Aug 29, 2019 at 06:48:42PM +0200, Andrzej Hajda wrote:
> On 26.08.2019 18:27, Laurent Pinchart wrote:
> > On Thu, Aug 22, 2019 at 02:17:16PM +0200, Andrzej Hajda wrote:
> >> On 20.08.2019 00:45, Laurent Pinchart wrote:
> >>> On Mon, Aug 19, 2019 at 10:38:35AM +0200, Andrzej Hajda wrote:
> >>>> On 14.08.2019 14:40, Daniel Vetter wrote:
> >>>>> On Wed, Aug 14, 2019 at 01:04:03PM +0300, Laurent Pinchart wrote:
> >>>>>> On Wed, Aug 14, 2019 at 08:23:12AM +0200, Andrzej Hajda wrote:
> >>>>>>> On 11.08.2019 00:43, Laurent Pinchart wrote:
> >>>>>>>> On Fri, Aug 09, 2019 at 01:55:53PM +0200, Andrzej Hajda wrote:
> >>>>>>>>> On 08.08.2019 21:32, Laurent Pinchart wrote:
> >>>>>>>>>> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>> On 16.07.2019 11:00, Daniel Vetter wrote:
> >>>>>>>>>>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>> On 11.07.2019 17:50, Daniel Vetter wrote:
> >>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>>>> On 11.07.2019 15:18, Daniel Vetter wrote:
> >>>>>>>>>>>>>>>> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>>>>>> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>>>>>>>>>>>>>>>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >>>>>>>>>>>>>>>>>>> Hi Laurent,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I like the approach, current practice when almost every bridge should
> >>>>>>>>>>>>>>>>>>> optionally implement connector, or alternatively downstream bridge or
> >>>>>>>>>>>>>>>>>>> panel is very painful.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>>>>>>>>>>>>>>>>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>>>>>>>>>>>>>>>>> it's all used in the end. I probably should go and do that, at least to
> >>>>>>>>>>>>>>>>>> get a feeling for what your hpd_cb usually does.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> More comments inlined.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>>>>>>>>>>>>>>>>>>> To support implementation of DRM connectors on top of DRM bridges
> >>>>>>>>>>>>>>>>>>>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>>>>>>>>>>>>>>>>>>> data:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>>>>>>>>>>>>>>>>>>>   retrieval operations
> >>>>>>>>>>>>>>>>>>>> - Bitmask of supported operations
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Why do we need these bitmask at all? Why cannot we rely on presence of
> >>>>>>>>>>>>>>>>>>> operation's callback?
> >>>>>>>>>>>>>>>>>> Yeah also not a huge fan of these bitmasks. Smells like
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>>>>>>>>>>>>>>>>> add, generally good excuse to not have to think through the design between
> >>>>>>>>>>>>>>>>>> different parts of drivers - "just" add another flag.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> - Bridge output type
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Add and document these.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Three new bridge helper functions are also added to handle hot plug
> >>>>>>>>>>>>>>>>>>>> notification in a way that is as transparent as possible for the
> >>>>>>>>>>>>>>>>>>>> bridges.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Documentation of new opses does not explain how it should cooperate with
> >>>>>>>>>>>>>>>>>>> bridge chaining, I suppose they should be chained explicitly, am I
> >>>>>>>>>>>>>>>>>>> right? More comments about it later.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Signed-off-by: Laurent Pinchart <[e-mail]>
> >>>>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>>>  drivers/gpu/drm/drm_bridge.c |  92 +++++++++++++++++++
> >>>>>>>>>>>>>>>>>>>>  include/drm/drm_bridge.h     | 170 ++++++++++++++++++++++++++++++++++-
> >>>>>>>>>>>>>>>>>>>>  2 files changed, 261 insertions(+), 1 deletion(-)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>>>>>> index 519577f363e3..3c2a255df7af 100644
> >>>>>>>>>>>>>>>>>>>> --- a/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>>>>>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>>>>>>>>>>>>>>>>>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>>>>>>>>>>>>>>>>>>>   */
> >>>>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>>>>>  {
> >>>>>>>>>>>>>>>>>>>> +	mutex_init(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>>>>>>>>  	list_add_tail(&bridge->list, &bridge_list);
> >>>>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>>>>>>>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>>>>>  	mutex_lock(&bridge_lock);
> >>>>>>>>>>>>>>>>>>>>  	list_del_init(&bridge->list);
> >>>>>>>>>>>>>>>>>>>>  	mutex_unlock(&bridge_lock);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	mutex_destroy(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_bridge_remove);
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>>  }
> >>>>>>>>>>>>>>>>>>>>  EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>>>>>> + * @cb: hot-plug detection callback
> >>>>>>>>>>>>>>>>>>>> + * @data: data to be passed to the hot-plug detection callback
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> >>>>>>>>>>>>>>>>>>>> + * hot plug notification callback. From now on the @cb will be called with
> >>>>>>>>>>>>>>>>>>>> + * @data when an output status change is detected by the bridge, until hot plug
> >>>>>>>>>>>>>>>>>>>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * Only one hot plug detection callback can be registered at a time, it is an
> >>>>>>>>>>>>>>>>>>>> + * error to call this function when hot plug detection is already enabled for
> >>>>>>>>>>>>>>>>>>>> + * the bridge.
> >>>>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> To simplify architecture maybe would be better to enable hpd just on
> >>>>>>>>>>>>>>>>>>> bridge attach:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> bridge->hpd_cb = cb;
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> bridge->hpd_data = data;
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ret = drm_bridge_attach(...);
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yeah I like this more. The other problem here is, what if you need more
> >>>>>>>>>>>>>>>>>> than 1 callback registers on the same bridge hdp signal?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> This way we could avoid adding new callbacks hpd_(enable|disable)
> >>>>>>>>>>>>>>>>>>> without big sacrifices.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >>>>>>>>>>>>>>>>>>> notifies about sink status change, how it translates to this cb?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>>>>>>>>> +			   void *data)
> >>>>>>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_enable)
> >>>>>>>>>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> >>>>>>>>>>>>>>>>>>>> +		goto unlock;
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = cb;
> >>>>>>>>>>>>>>>>>>>> +	bridge->hpd_data = data;
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_enable(bridge);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +unlock:
> >>>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> >>>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> >>>>>>>>>>>>>>>>>>>> + * callback previously registered with drm_bridge_hpd_enable(). Once this
> >>>>>>>>>>>>>>>>>>>> + * function returns the callback will not be called by the bridge when an
> >>>>>>>>>>>>>>>>>>>> + * output status change occurs.
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> >>>>>>>>>>>>>>>>>>>> + * bridge->ops. This function shall not be called when the flag is not set.
> >>>>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> >>>>>>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>>>>>> +	if (!bridge || !bridge->funcs->hpd_disable)
> >>>>>>>>>>>>>>>>>>>> +		return;
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +	bridge->funcs->hpd_disable(bridge);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	bridge->hpd_cb = NULL;
> >>>>>>>>>>>>>>>>>>>> +	bridge->hpd_data = NULL;
> >>>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>>>> + * drm_bridge_hpd_notify - notify hot plug detection events
> >>>>>>>>>>>>>>>>>>>> + * @bridge: bridge control structure
> >>>>>>>>>>>>>>>>>>>> + * @status: output connection status
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * Bridge drivers shall call this function to report hot plug events when they
> >>>>>>>>>>>>>>>>>>>> + * detect a change in the output status, when hot plug detection has been
> >>>>>>>>>>>>>>>>>>>> + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> >>>>>>>>>>>>>>>>>>>> + *
> >>>>>>>>>>>>>>>>>>>> + * This function shall be called in a context that can sleep.
> >>>>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status)
> >>>>>>>>>>>>>>>>>>>> +{
> >>>>>>>>>>>>>>>>>>>> +	mutex_lock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +	if (bridge->hpd_cb)
> >>>>>>>>>>>>>>>>>>>> +		bridge->hpd_cb(bridge->hpd_data, status);
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> So this isn't quite what I had in mind. Instead something like this:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 	/* iterates over all bridges in the chain containing @bridge */
> >>>>>>>>>>>>>>>>>> 	for_each_bridge(tmp_bridge, bridge) {
> >>>>>>>>>>>>>>>>>> 		if (tmp_bridge == bridge)
> >>>>>>>>>>>>>>>>>> 			continue;
> >>>>>>>>>>>>>>>>>> 		if (bridge->hpd_notify);
> >>>>>>>>>>>>>>>>>> 			bridge->hpd_notify(tmp_bridge, bridge, status);
> >>>>>>>>>>>>>>>>>> 	}
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 	encoder = encoder_for_bridge(bridge);
> >>>>>>>>>>>>>>>>>> 	if (encoder->helper_private->bridge_hpd_notify)
> >>>>>>>>>>>>>>>>>> 		encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 	dev = bridge->dev
> >>>>>>>>>>>>>>>>>> 	if (dev->mode_config.helper_private->bridge_hpd_notify)
> >>>>>>>>>>>>>>>>>> 		dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> No register callback needed, no locking needed, everyone gets exactly the
> >>>>>>>>>>>>>>>>>> hpd they want/need.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> As I understand you want to notify every member of the pipeline.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think it should be enough to notify only the source, and then source
> >>>>>>>>>>>>>>>>> should decide if/when the hpd should be propagated upstream.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It looks more generic for me.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I'm not parsing ... do you think my idea is more generic and useful, or
> >>>>>>>>>>>>>>>> the one from Laurent? Kinda confused here.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regarding general idea:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1. Laurent's approach is to notify only consumer, I guess usually video
> >>>>>>>>>>>>>>> source.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2. Your is to notify all other bridges and encoder.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> And I prefer 1st approach, why:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - the source can decide if/when and to who propagate the signal,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - is more generic, for example if bridge send signal to two
> >>>>>>>>>>>>>>> monitors/panels, it can delay hpd propagation till both sinks are present,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> With Laurent's approach the bridge cannot send the hpd to more than one
> >>>>>>>>>>>>>> consumer. There's only 1 callback. So you're example doesn't work.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If there will be two consumers, there will be two bridge attachments,
> >>>>>>>>>>>>> thus there will be two notifications, it should work.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2 consumers, 1 producer. There's only _one_ callback in the producer. The
> >>>>>>>>>>>> callback is registered on the produce bridge, not on the consumer bridge
> >>>>>>>>>>>> (or I'm totallly misreading what Laurent does here).
> >>>>>>>>>>>
> >>>>>>>>>>> I have assumed that if devices exposes two hardware sink interfaces it
> >>>>>>>>>>> will expose two separate bridges - of course it will not work with
> >>>>>>>>>>> "bridge chaining" thing, but this is a different story.
> >>>>>>>>>>
> >>>>>>>>>> Daniel is right that the current implementation only allows one
> >>>>>>>>>> consumer. This is however not a limitation of the API, but of its
> >>>>>>>>>> implementation, as I only needed a single consumer. The helpers in this
> >>>>>>>>>> series ensure that neither the consumer nor the producer poke in the
> >>>>>>>>>> drm_bridge structure to call back to the HPD handler:
> >>>>>>>>>>
> >>>>>>>>>> - The consumer calls drm_bridge_hpd_enable() and
> >>>>>>>>>>   drm_bridge_hpd_disable(), which could offer a reference-counted
> >>>>>>>>>>   behaviour if desired without changes to the consumer.
> >>>>>>>>>>
> >>>>>>>>>> - The producer gets configured by .hpd_enable() and .hpd_disable(),
> >>>>>>>>>>   which could also easily accommodate reference-counting in the drm
> >>>>>>>>>>   bridge core without changes to the producer.
> >>>>>>>>>>
> >>>>>>>>>> - The producer notifies HPD with drm_bridge_hpd_notify(), which could
> >>>>>>>>>>   easily be extended to support multiple consumers without changes to
> >>>>>>>>>>   the producer.
> >>>>>>>>>>
> >>>>>>>>>> This is actually my second version of the HPD mechanism. The first
> >>>>>>>>>> version was never posted, poked into drm_bridge, and required the
> >>>>>>>>>> producer to be aware of the callbacks. After discussing this privately
> >>>>>>>>>> with Daniel, I came up with the implementation in this series that,
> >>>>>>>>>> while not supporting multiple consumers now, makes it easy to extend
> >>>>>>>>>> later without minimal effort.
> >>>>>>>>>>
> >>>>>>>>>> Daniel's proposed implementation above looks reasonable to me, provided
> >>>>>>>>>> we can iterate over the bridges in an order that don't depend on the
> >>>>>>>>>> position of the producer in the chain (should be easy to solve by
> >>>>>>>>>> starting at the encoder for instance). It however looks a bit like a
> >>>>>>>>>> midlayer to me :-) That's why I have a similar implementation in the
> >>>>>>>>>> connector-bridge helper, which could be extended to call
> >>>>>>>>>> encoder->helper_private->bridge_hpd_notify() and
> >>>>>>>>>> dev->mode_config.helper_private->bridge_hpd_notify() instead of
> >>>>>>>>>> hardcoding drm_kms_helper_hotplug_event(). Moving the code to
> >>>>>>>>>> drm_bridge_hpd_notify() would on the other hand set the notification
> >>>>>>>>>> sequence towards the encoder and driver in stone. Daniel, do you think
> >>>>>>>>>> that would be better ?
> >>>>>>>>>>
> >>>>>>>>>> I would like to remind everybody that this series isn't the last I will
> >>>>>>>>>> ever submit, and I plan to do more work on drm_bridge and drm_panel. I'm
> >>>>>>>>>> open to suggestions, and can address problems on top of these patches,
> >>>>>>>>>> provided obviously that this series doesn't go in the wrong direction.
> >>>>>>>>>> I'm of course also willing to rework this series, but given the amount
> >>>>>>>>>> of work we have in the drm_bridge realm, I can't fix everything in one
> >>>>>>>>>> go :-)
> >>>>>>>>>>
> >>>>>>>>>>>>>>> - it resembles hardware wires :)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This isn't for the hw wires afaiui. The hw hpd terminates in the source
> >>>>>>>>>>>>>> bridge, which then calls drm_bridge_hpd_notify() to inform anyone else
> >>>>>>>>>>>>>> interested in that hpd singal. This includes:
> >>>>>>>>>>>>>> - Other bridges, e.g. if they provide CEC support.
> >>>>>>>>>>>>>> - Other bridges, maybe they need to re-run the HDCP state engine
> >>>>>>>>>>>>>> - Overall driver, so it can update the modes/connector status and send the
> >>>>>>>>>>>>>>   uevent to the driver.
> >>>>>>>>>>>>>> - Overall display pipeline for this specific bridge, maybe you need to
> >>>>>>>>>>>>>>   shut down/re-enable the pipe because $reasons.
> >>>>>>>>>>>>>>  
> >>>>>>>>>>>>>> That's at least my understanding from lots of chats with Laurent about
> >>>>>>>>>>>>>> what he wants to do here.
> >>>>>>>>>>
> >>>>>>>>>> That's correct, and that's what I was trying to implement :-) The
> >>>>>>>>>> notification, in this patch series, goes from the producer bridge to a
> >>>>>>>>>> central place (namely the connector, with a helper implementation
> >>>>>>>>>> available as part of this series, but custom implementations in display
> >>>>>>>>>> drivers are fine if needed) that then dispatches the notification to all
> >>>>>>>>>> bridges (through the .lost_hotplug() operation, which we could replace
> >>>>>>>>>> by an .hpd_notify() operation) for the first two purposes listed above,
> >>>>>>>>>> and then to the overall driver. The only thing I don't support yet is
> >>>>>>>>>> dispatching to the display pipeline (item 4 in the list above) as I had
> >>>>>>>>>> no need for that, and didn't want to develop an API with no user. This
> >>>>>>>>>> would however not be difficult to do when needed, the need is taken into
> >>>>>>>>>> account in the proposed implementation.
> >>>>>>>>>>
> >>>>>>>>>>>>> I do not know the full picture, but the solution where particular bridge
> >>>>>>>>>>>>> notifies everything unconditionally seems to me much less flexible.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If HPD signals is received by the consumer, if there are no obstacles it
> >>>>>>>>>>>>> can propagate it further, upstream bridge/encoder or to drm core - it
> >>>>>>>>>>>>> will mimic your scenario.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But there are also other scenarios where bridge does not want to
> >>>>>>>>>>>>> propagate signal, because for example:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - it wants to wait for other sinks to wake up,
> >>>>>>>>>>>>
> >>>>>>>>>>>> The other sink can just do that in their hpd callback.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> - it propagates HPD signal via hardware wire,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Again, the other sink can just not listen to sw hpd in that case, and use
> >>>>>>>>>>>> the wire/hw hpd interrupt.
> >>>>>>>>>>>
> >>>>>>>>>>> If it should ignore HPD, why it should receive it at all - it is
> >>>>>>>>>>> unnecessary noise. And I am afraid with more complicated pipelines it
> >>>>>>>>>>> will be impossible for particular component (bridge/encoder/whatever) to
> >>>>>>>>>>> distinguish if HPD notification which came from non-directly connected
> >>>>>>>>>>> component should be ignored or not.
> >>>>>>>>>>>
> >>>>>>>>>>>>> - first it wants to verify if the sink is valid/compatible/authorized
> >>>>>>>>>>>>> device.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Now you lost me. Why would someone glue incompatible IP into a SoC or
> >>>>>>>>>>>> board?
> >>>>>>>>>>>
> >>>>>>>>>>> Bridge can have external connectors, and the user can connect there
> >>>>>>>>>>> anything.
> >>>>>>>>>>>
> >>>>>>>>>>>>> In general HPD is input signal for notify of state changes on particular
> >>>>>>>>>>>>> bus, in case of typical video bridge on its output video bus.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In case of bridges they have also input video buses, and they can send
> >>>>>>>>>>>>> HPD signal via this bus, but this is indeed different HPD signal, even
> >>>>>>>>>>>>> if for most cases they looks similar.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ah, I think this is a problem we will eventually have. But it's not
> >>>>>>>>>>>> something we're currently solving here at all I think.
> >>>>>>>>>>>
> >>>>>>>>>>> Currently sii8620 device in tm2 sends hpd signal upstream via hardware
> >>>>>>>>>>> line, so this is not something from far future. And I guess with HPD
> >>>>>>>>>>> broadcasting it could be racy/error prone, for example EDID reading can
> >>>>>>>>>>> fail due to bridge being not ready (ddc of sii8620 is connected to i2c
> >>>>>>>>>>> controller via hw wires also).
> >>>>>>>>>>>
> >>>>>>>>>>>>>>> And regarding implementation:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1. Laurent proposes to register callback drm_bridge_hpd_enable.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2. You propose to add ops hpd_notify in bridges and encoders.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Your proposition is more straightforward, but if we want to notify only
> >>>>>>>>>>>>>>> source we should locate it by parsing notification chain (what about
> >>>>>>>>>>>>>>> unchained bridges), or store pointer somewhere during attachment.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It still leaves us with this ugly dualism - source is encoder or bridge,
> >>>>>>>>>>>>>>> similarly to sink as bridge or panel, but fixing it can be done later.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Uh I think we're not talking about the same thing really. My understanding
> >>>>>>>>>>>>>> is that this callback is if someone (outside of this bridge) is interested
> >>>>>>>>>>>>>> in a hpd signal _from_ this bridge. Which means you can only ever have 1
> >>>>>>>>>>>>>> listener.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Do we have real life examples?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I want to distinguish two situations:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - another device wants to know if input bus of the bridge has changed state,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> - another device wants to know if output bus of the bridge has changed
> >>>>>>>>>>>>> state.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Uh, that's what drm_bridge_state is for (if it ever happens). That's how
> >>>>>>>>>>>> bridges can exchange state and information about each another. hpd is
> >>>>>>>>>>>> about the physical world, i.e. "is there a cable plugged into the port
> >>>>>>>>>>>> I'm driving?". We're not going to use fake hpd to update bridge state and
> >>>>>>>>>>>> fun stuff like that, we have the atomic_check machinery for this.
> >>>>>>>>>>>
> >>>>>>>>>>> My question was if we have real examples that upstream device requires
> >>>>>>>>>>> knowledge about state of output line of the bridge?
> >>>>>>>>>>>
> >>>>>>>>>>> To be more precise, we have following display pipeline:
> >>>>>>>>>>>
> >>>>>>>>>>> A-->B-->C
> >>>>>>>>>>>
> >>>>>>>>>>> And C sends HPD to B (ie signal that state of line between B and C
> >>>>>>>>>>> changed). Does A really wants to know this information? or it should
> >>>>>>>>>>> just need to know if state of line A-->B changed?
> >>>>>>>>>>
> >>>>>>>>>> There's one real life example, where A is an HDMI encoder, B is an HDMI
> >>>>>>>>>> ESD protector and level shifter, and C is the physical HDMI connector.
> >>>>>>>>>> When the HDMI cable is unplugged, the CEC controller part of A needs to
> >>>>>>>>>> be notified in order to reset the CEC state machine. One could however
> >>>>>>>>>> argue that in that case the A-B link state changes too, but the
> >>>>>>>>>> important part is that HPD detection is not performed by A, while A
> >>>>>>>>>> needs to be informed of lost hotplug.
> >>>>>>>>>
> >>>>>>>>> I have no full picture but I guess in this case C sends HPD to B using
> >>>>>>>>> hardware wire, and then B sends HPD to A also via wire, so I wouldn't
> >>>>>>>>> say that B does not participate in HPD transmission/forwarding,
> >>>>>>>>
> >>>>>>>> No, in this case A doesn't receive any hardware HPD signal, it requires
> >>>>>>>> HPD notification through software.
> >>>>>>>>
> >>>>>>>>> some shifters with 'advanced power saving' can even perform wake-up of
> >>>>>>>>> upstream pin logic after receiving HPD on downstream, so HPD sent from B
> >>>>>>>>> to A is indeed different than HPD sent from C to B.
> >>>>>>>>>
> >>>>>>>>> Btw, with the above logic of propagation of HPD callback (proposed by
> >>>>>>>>> Daniel) I guess it will work this way:
> >>>>>>>>>
> >>>>>>>>> - A will receive HPD signal via HW,
> >>>>>>>>>
> >>>>>>>>> - then B and C will receive HPD callback via framework.
> >>>>>>>>>
> >>>>>>>>> Am I right?
> >>>>>>>>
> >>>>>>>> It's the other way around.
> >>>>>>>>
> >>>>>>>> In this case the HPD signal from the connector (C) is routed to an input
> >>>>>>>> of the ESD chip (B). The ESD chip outputs a shifted HPD hardware signal
> >>>>>>>> connected to a GPIO of the SoC. The driver for (B) thus registers a GPIO
> >>>>>>>> IRQ and receive the hardware HPD notification. The driver for the HDMI
> >>>>>>>> encoder (A) needs to receive HPD notification in software, through the
> >>>>>>>> framework.
> >>>>>>>
> >>>>>>> If this is GPIO I wonder why do not query this gpio by encoder directly,
> >>>>>>> rules of ownership of such gpios seems to be grey area, so in such case
> >>>>>>> I would advise to put it in the driver who really needs it.
> >>>>>>>
> >>>>>>> This way it will be much simpler.
> >>>>>>
> >>>>>> First to fall, multiple drivers may need to be informed of HPD events
> >>>>>> coming from a GPIO, so we would need to duplicate it in multiple places,
> >>>>>> and I don't think the GPIO framework allows acquiring a GPIO multiple
> >>>>>> times.
> >>>>>>
> >>>>>> Then, the GPIO is described in DT, and DT doesn't care about which
> >>>>>> driver needs HPD events. DT specifies the GPIO in the node of the device
> >>>>>> it belongs to, this is defined in DT bindings, and must be the same on
> >>>>>> all boards, while depending on the board different devices may need to
> >>>>>> be informed of HPD events.
> >>>>>>
> >>>>>> For those two reasons HPD GPIO handling and consumption of HPD events
> >>>>>> can't always be grouped in the same driver.
> >>>>>>
> >>>>>>> Going back to HPD notifications, as I said earlier broadcasting HPD
> >>>>>>> notification unconditionally to every member of the chain with hope that
> >>>>>>> the member will be able to filter-out undesired notification seems to me
> >>>>>>> incorrect - maybe it can solve some problems but is not flexible enough
> >>>>>>> to be usable in other scenarios.
> >>>>>>>
> >>>>>>> If my arguments do not convince you please just continue with your
> >>>>>>> ideas, we can always add NO_HPD_BROADCAST somewhere :)
> >>>>>>
> >>>>>> :-) I would like to understand the problems you're referring to though,
> >>>>>> and hopefully solve them. If you could describe one of the scenarios
> >>>>>> where you think this mechanism wouldn't be usable that would help. In
> >>>>>> the meantime I will post a new version of the series with these
> >>>>>> operations kept as-is to get the rest of the patches reviewed.
> >>>>>
> >>>>> See my little thing about midlayers, I think midlayers with lots of flags
> >>>>> for everything aren't a good idea. They should be more opinionated about
> >>>>> how things work.
> >>>>>
> >>>>> So if there's a case where this broadcasting of various things doesn't
> >>>>> work, let's dig into it.
> >>>>
> >>>> OK, almost real life example:
> >>>>
> >>>> A -> B -> C
> >>>>
> >>>> A - RGB/HDMI converter,
> >>>>
> >>>> B - HDMI/MHL converter,
> >>>>
> >>>> C - uUSB controller (MUIC).
> >>>>
> >>>>
> >>>> C - detects presence of MHL sink and routes MHL lines to B in such case.
> >>>>
> >>>> B - has no hardware logic to detect HPD, but it's firmware can read EDID
> >>>> from downstream component via HW lines and it has hardware lines to
> >>>> upstream component to send EDID,
> >>>>
> >>>> A - can read EDID from B via hardware lines, but does not have hardware HPD.
> >>>
> >>> It probably doesn't matter much for the overall discussion, but out of
> >>> curiosity, does B have a CBUS interface towards C and a DDC (I2C)
> >>> interface towards A ?
> >>
> >> Yes, but C (MUIC) is not MHL aware, beside initial 1K resistance
> >> detection on ID pin, AFAIK.
> >>
> >>>  And does A read the EDID on DDC and expose it
> >>> towards the SoC through a custom protocol (for instance as the ADV7511
> >>> does), or does it forward the DDC lines to the SoC ?
> >>>
> >>>> So how it should work (according to specification):
> >>>>
> >>>> 1. C detects MHL sink.
> >>>>
> >>>> 2. C switches his mux to route lines to B.
> >>>>
> >>>> 3. C sends HPD notification to B.
> >>>>
> >>>> 4. B powers on, its firmware reads EDID from downstream lines (possibly
> >>>> adjusting it) and makes it available to upstream component A.
> >>>>
> >>>> 5. B sends HPD notification to A.
> >>>>
> >>>>
> >>>> I do not know how it could work with HPD broadcasting.
> >>>>
> >>>> I guess C should be HPD provider, but in case of HPD broadcasting A and
> >>>> B would receive notification in the same time, as a result A would start
> >>>> reading EDID too early - fail.
> >>>
> >>> That's an interesting case indeed. Now I understand what you meant
> >>> earlier.
> >>>
> >>> The HPD notification from C to B is purely internal, and should not be
> >>> visible from a DRM/KMS point of view. It just happens that this hardware
> >>> setup has a more complex HPD sequence that requires software
> >>> intervention in the middle of the sequence. As such, if we forget about
> >>> this patch series for a minute, C would need a custom API to send MHL
> >>> notification to B, and the HPD for DRM/KMS would be notified by B, right
> >>> ?
> >>
> >> I just want to convince you that maybe all HPD signals
> >> (hardware/software) are purely internal (ie they should be handled only
> >> by upstream devices), and the hotplug event should be sent to
> >> userspace/drm_core only when WHOLE pipeline is ready to query modes
> >> (i2c/sideband channels/whatever is functional).
> >
> > I think that most HPD events are not internal, and that the above case
> > is more an exception than a rule :-) It should however be supported, and
> > I agree that HPD should be notified to the DRM core only when it has
> > traversed the whole pipeline, yes.
> >
> > I'd like to keep bridge drivers simple though, and avoid requiring
> > manual HPD propagation as I think that's the common case. That's why I
> > proposed blocking the propagation below. What do you think ?
> >
> > This also means that, if we switch to a model where propagation can be
> > disabled, a bridge will only notify upstream (closer to the CRTC)
> > bridges. If, in a A-B-C chain, bridge B receives the external HPD event,
> > then bridge C would never be notified. Do you think that could be an
> > issue ?
> 
> As I said somewhere earlier it should work.

I'll give it a try then.

> Btw, since bridges are currently connected via single-linked list (just
> drm_bridge->next), do you plan to switch to double linked list, to find
> upstream bridge, or add logic to discover upstream bridge on the fly?

Boris has submitted a patch series ([1]) to switch to a double-linked
list, it will be useful here.

> >>> I think it's possible to handle both the MHL notification and the
> >>> user-visible HPD notification through the same bridge API, provided that
> >>> we offer a way for a bridge to block forwarding of the HPD notification.
> >>> This will also require calling the HPD notifiers on bridges in the sink
> >>> to source order. Both are doable, the bridge HPD notifier operation
> >>> could return a bool that blocks propagation of the notification. Would
> >>> that work for you ?
> >>
> >> It could work, in this case.
> >>
> >> But it will still have problems with non-linear pipelines - where stream
> >> is split to two or more bridges/panels.
> >
> > I agree, but that's not supported by the bridge API for now. I'm not
> > sure I'm looking forward to dealing with this, but I think it will be
> > needed :-)
> 
> Currently there are two modes of usage of bridge:
> 
> - part of bridge chain,
> 
> - private bridge - it can be attached to other components via private
> pointer, not drm_encoder->bridge, nor drm_bridge->next.
> 
> Non-linear pipelines can be ( and I guess they are ) implemented using
> the latter.
>
> Anyway if we want to extend bridge API it would be good to allow usage
> of this API also with detached bridges.

Do you have any pointer to such cases ? Boris' series deals with Exynos
and VC4 that both use bridges privately, but as far as I understand they
still have linear pipelines.

[1] https://patchwork.kernel.org/cover/11207085/

> >>>>>>>>>>>>>> You seem to have some other idea here.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> +	mutex_unlock(&bridge->hpd_mutex);
> >>>>>>>>>>>>>>>>>>>> +}
> >>>>>>>>>>>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>>  #ifdef CONFIG_OF
> >>>>>>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>>>>>   * of_drm_find_bridge - find the bridge corresponding to the device node in
> >>>>>>>>>>>>>>>>>>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>>>>>> index 08dc15f93ded..b9445aa5b1ef 100644
> >>>>>>>>>>>>>>>>>>>> --- a/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>>>>>> +++ b/include/drm/drm_bridge.h
> >>>>>>>>>>>>>>>>>>>> @@ -23,8 +23,9 @@
> >>>>>>>>>>>>>>>>>>>>  #ifndef __DRM_BRIDGE_H__
> >>>>>>>>>>>>>>>>>>>>  #define __DRM_BRIDGE_H__
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>> -#include <linux/list.h>
> >>>>>>>>>>>>>>>>>>>>  #include <linux/ctype.h>
> >>>>>>>>>>>>>>>>>>>> +#include <linux/list.h>
> >>>>>>>>>>>>>>>>>>>> +#include <linux/mutex.h>
> >>>>>>>>>>>>>>>>>>>>  #include <drm/drm_mode_object.h>
> >>>>>>>>>>>>>>>>>>>>  #include <drm/drm_modes.h>
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>> @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> >>>>>>>>>>>>>>>>>>>>  	 */
> >>>>>>>>>>>>>>>>>>>>  	void (*atomic_post_disable)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>>  				    struct drm_atomic_state *state);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @detect:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * Check if anything is attached to the bridge output.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * This callback is optional, if not implemented the bridge will be
> >>>>>>>>>>>>>>>>>>>> +	 * considered as always having a component attached to its output.
> >>>>>>>>>>>>>>>>>>>> +	 * Bridges that implement this callback shall set the
> >>>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * drm_connector_status indicating the bridge output status.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @get_modes:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * Fill all modes currently valid for the sink into the &drm_connector
> >>>>>>>>>>>>>>>>>>>> +	 * with drm_mode_probed_add().
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * The @get_modes callback is mostly intended to support non-probable
> >>>>>>>>>>>>>>>>>>>> +	 * displays such as many fixed panels. Bridges that support reading
> >>>>>>>>>>>>>>>>>>>> +	 * EDID shall leave @get_modes unimplemented and implement the
> >>>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->get_edid callback instead.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * The number of modes added by calling drm_mode_probed_add().
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	int (*get_modes)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>> +			 struct drm_connector *connector);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @get_edid:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * Read and parse the EDID data of the connected display.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * The @get_edid callback is the preferred way of reporting mode
> >>>>>>>>>>>>>>>>>>>> +	 * information for a display connected to the bridge output. Bridges
> >>>>>>>>>>>>>>>>>>>> +	 * that support readind EDID shall implement this callback and leave
> >>>>>>>>>>>>>>>>>>>> +	 * the @get_modes callback unimplemented.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * The caller of this operation shall first verify the output
> >>>>>>>>>>>>>>>>>>>> +	 * connection status and refrain from reading EDID from a disconnected
> >>>>>>>>>>>>>>>>>>>> +	 * output.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * This callback is optional. Bridges that implement it shall set the
> >>>>>>>>>>>>>>>>>>>> +	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * RETURNS:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * An edid structure newly allocated with kmalloc() (or similar) on
> >>>>>>>>>>>>>>>>>>>> +	 * success, or NULL otherwise. The caller is responsible for freeing
> >>>>>>>>>>>>>>>>>>>> +	 * the returned edid structure with kfree().
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	struct edid *(*get_edid)(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>> +				 struct drm_connector *connector);
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> It overlaps with get_modes, I guess presence of one ops should disallow
> >>>>>>>>>>>>>>>>>>> presence of another one?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I am not really convinced we need this op at all, cannot we just assign
> >>>>>>>>>>>>>>>>>>> some helper function to .get_modes cb, which will do the same?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
> >>>>>>>>>>>>>>>>>> case, and require that if it has an edid it must fill out connector->info
> >>>>>>>>>>>>>>>>>> and connector->edid correctly.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Btw if a hpd happens, who's responible for making sure the edid/mode list
> >>>>>>>>>>>>>>>>>> in the connector is up-to-date? With your current callback design that's
> >>>>>>>>>>>>>>>>>> up to the callback, which doesn't feel great. Maybe  drm_bridge_hpd_notify
> >>>>>>>>>>>>>>>>>> should guarantee that it'll first walk the connectors to update status and
> >>>>>>>>>>>>>>>>>> edid/mode list for the final drm_connector. And then instead of just
> >>>>>>>>>>>>>>>>>> passing the simple "status", it'll pass the connector, with everything
> >>>>>>>>>>>>>>>>>> correctly updated.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Otherwise everyone interested in that hpd signal will go and re-fetch the
> >>>>>>>>>>>>>>>>>> edid, which is not so awesome :-)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @lost_hotplug:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * Notify the bridge of display disconnection.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * This callback is optional, it may be implemented by bridges that
> >>>>>>>>>>>>>>>>>>>> +	 * need to be notified of display disconnection for internal reasons.
> >>>>>>>>>>>>>>>>>>>> +	 * One use case is to reset the internal state of CEC controllers for
> >>>>>>>>>>>>>>>>>>>> +	 * HDMI bridges.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	void (*lost_hotplug)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_enable:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * Enable hot plug detection. From now on the bridge shall call
> >>>>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_notify() each time a change is detected in the output
> >>>>>>>>>>>>>>>>>>>> +	 * connection status, until hot plug detection gets disabled with
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_disable.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_disable callback and set
> >>>>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	void (*hpd_enable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_disable:
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * Disable hot plug detection. Once this function returns the bridge
> >>>>>>>>>>>>>>>>>>>> +	 * shall not call drm_bridge_hpd_notify() when a change in the output
> >>>>>>>>>>>>>>>>>>>> +	 * connection status occurs.
> >>>>>>>>>>>>>>>>>>>> +	 *
> >>>>>>>>>>>>>>>>>>>> +	 * This callback is optional and shall only be implemented by bridges
> >>>>>>>>>>>>>>>>>>>> +	 * that support hot-plug notification without polling. Bridges that
> >>>>>>>>>>>>>>>>>>>> +	 * implement it shall also implement the @hpd_enable callback and set
> >>>>>>>>>>>>>>>>>>>> +	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	void (*hpd_disable)(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>>>>> @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> >>>>>>>>>>>>>>>>>>>>  	bool dual_link;
> >>>>>>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>> +/**
> >>>>>>>>>>>>>>>>>>>> + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> >>>>>>>>>>>>>>>>>>>> + */
> >>>>>>>>>>>>>>>>>>>> +enum drm_bridge_ops {
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> >>>>>>>>>>>>>>>>>>>> +	 * its output. Bridges that set this flag shall implement the
> >>>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->detect callback.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_DETECT = BIT(0),
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> >>>>>>>>>>>>>>>>>>>> +	 * connected to its output. Bridges that set this flag shall implement
> >>>>>>>>>>>>>>>>>>>> +	 * the &drm_bridge_funcs->get_edid callback.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_EDID = BIT(1),
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> >>>>>>>>>>>>>>>>>>>> +	 * without requiring polling. Bridges that set this flag shall
> >>>>>>>>>>>>>>>>>>>> +	 * implement the &drm_bridge_funcs->hpd_enable and
> >>>>>>>>>>>>>>>>>>>> +	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_HPD = BIT(2),
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> >>>>>>>>>>>>>>>>>>>> +	 * by the display at its output. This does not include readind EDID
> >>>>>>>>>>>>>>>>>>>> +	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> >>>>>>>>>>>>>>>>>>>> +	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	DRM_BRIDGE_OP_MODES = BIT(3),
> >>>>>>>>>>>>>>>>>>>> +};
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>>  /**
> >>>>>>>>>>>>>>>>>>>>   * struct drm_bridge - central DRM bridge control structure
> >>>>>>>>>>>>>>>>>>>>   */
> >>>>>>>>>>>>>>>>>>>> @@ -398,6 +535,29 @@ struct drm_bridge {
> >>>>>>>>>>>>>>>>>>>>  	const struct drm_bridge_funcs *funcs;
> >>>>>>>>>>>>>>>>>>>>  	/** @driver_private: pointer to the bridge driver's internal context */
> >>>>>>>>>>>>>>>>>>>>  	void *driver_private;
> >>>>>>>>>>>>>>>>>>>> +	/** @ops: bitmask of operations supported by the bridge */
> >>>>>>>>>>>>>>>>>>>> +	enum drm_bridge_ops ops;
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @type: Type of the connection at the bridge output
> >>>>>>>>>>>>>>>>>>>> +	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> >>>>>>>>>>>>>>>>>>>> +	 * identifies the type of connected display.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	int type;
> >>>>>>>>>>>>>>>>>>>> +	/** private: */
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	struct mutex hpd_mutex;
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_cb: Hot plug detection callback, registered with
> >>>>>>>>>>>>>>>>>>>> +	 * drm_bridge_hpd_enable().
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	void (*hpd_cb)(void *data, enum drm_connector_status status);
> >>>>>>>>>>>>>>>>>>>> +	/**
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_data: Private data passed to the Hot plug detection callback
> >>>>>>>>>>>>>>>>>>>> +	 * @hpd_cb.
> >>>>>>>>>>>>>>>>>>>> +	 */
> >>>>>>>>>>>>>>>>>>>> +	void *hpd_data;
> >>>>>>>>>>>>>>>>>>>>  };
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>>  void drm_bridge_add(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>>> @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>>  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>>  			      struct drm_atomic_state *state);
> >>>>>>>>>>>>>>>>>>>>  
> >>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>> +			   void (*cb)(void *data,
> >>>>>>>>>>>>>>>>>>>> +				      enum drm_connector_status status),
> >>>>>>>>>>>>>>>>>>>> +			   void *data);
> >>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> >>>>>>>>>>>>>>>>>>>> +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> >>>>>>>>>>>>>>>>>>>> +			   enum drm_connector_status status);
> >>>>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>>>>  #ifdef CONFIG_DRM_PANEL_BRIDGE
> >>>>>>>>>>>>>>>>>>>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> >>>>>>>>>>>>>>>>>>>>  					u32 connector_type);

Patch

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 519577f363e3..3c2a255df7af 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -70,6 +70,8 @@  static LIST_HEAD(bridge_list);
  */
 void drm_bridge_add(struct drm_bridge *bridge)
 {
+	mutex_init(&bridge->hpd_mutex);
+
 	mutex_lock(&bridge_lock);
 	list_add_tail(&bridge->list, &bridge_list);
 	mutex_unlock(&bridge_lock);
@@ -86,6 +88,8 @@  void drm_bridge_remove(struct drm_bridge *bridge)
 	mutex_lock(&bridge_lock);
 	list_del_init(&bridge->list);
 	mutex_unlock(&bridge_lock);
+
+	mutex_destroy(&bridge->hpd_mutex);
 }
 EXPORT_SYMBOL(drm_bridge_remove);
 
@@ -463,6 +467,94 @@  void drm_atomic_bridge_enable(struct drm_bridge *bridge,
 }
 EXPORT_SYMBOL(drm_atomic_bridge_enable);
 
+/**
+ * drm_bridge_hpd_enable - enable hot plug detection for the bridge
+ * @bridge: bridge control structure
+ * @cb: hot-plug detection callback
+ * @data: data to be passed to the hot-plug detection callback
+ *
+ * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
+ * hot plug notification callback. From now on the @cb will be called with
+ * @data when an output status change is detected by the bridge, until hot plug
+ * notification gets disabled with drm_bridge_hpd_disable().
+ *
+ * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
+ * bridge->ops. This function shall not be called when the flag is not set.
+ *
+ * Only one hot plug detection callback can be registered at a time, it is an
+ * error to call this function when hot plug detection is already enabled for
+ * the bridge.
+ */
+void drm_bridge_hpd_enable(struct drm_bridge *bridge,
+			   void (*cb)(void *data,
+				      enum drm_connector_status status),
+			   void *data)
+{
+	if (!bridge || !bridge->funcs->hpd_enable)
+		return;
+
+	mutex_lock(&bridge->hpd_mutex);
+
+	if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
+		goto unlock;
+
+	bridge->hpd_cb = cb;
+	bridge->hpd_data = data;
+
+	bridge->funcs->hpd_enable(bridge);
+
+unlock:
+	mutex_unlock(&bridge->hpd_mutex);
+}
+EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
+
+/**
+ * drm_bridge_hpd_disable - disable hot plug detection for the bridge
+ * @bridge: bridge control structure
+ *
+ * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
+ * callback previously registered with drm_bridge_hpd_enable(). Once this
+ * function returns the callback will not be called by the bridge when an
+ * output status change occurs.
+ *
+ * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
+ * bridge->ops. This function shall not be called when the flag is not set.
+ */
+void drm_bridge_hpd_disable(struct drm_bridge *bridge)
+{
+	if (!bridge || !bridge->funcs->hpd_disable)
+		return;
+
+	mutex_lock(&bridge->hpd_mutex);
+	bridge->funcs->hpd_disable(bridge);
+
+	bridge->hpd_cb = NULL;
+	bridge->hpd_data = NULL;
+	mutex_unlock(&bridge->hpd_mutex);
+}
+EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
+
+/**
+ * drm_bridge_hpd_notify - notify hot plug detection events
+ * @bridge: bridge control structure
+ * @status: output connection status
+ *
+ * Bridge drivers shall call this function to report hot plug events when they
+ * detect a change in the output status, when hot plug detection has been
+ * enabled by the &drm_bridge_funcs.hpd_enable callback.
+ *
+ * This function shall be called in a context that can sleep.
+ */
+void drm_bridge_hpd_notify(struct drm_bridge *bridge,
+			   enum drm_connector_status status)
+{
+	mutex_lock(&bridge->hpd_mutex);
+	if (bridge->hpd_cb)
+		bridge->hpd_cb(bridge->hpd_data, status);
+	mutex_unlock(&bridge->hpd_mutex);
+}
+EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
+
 #ifdef CONFIG_OF
 /**
  * of_drm_find_bridge - find the bridge corresponding to the device node in
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 08dc15f93ded..b9445aa5b1ef 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -23,8 +23,9 @@ 
 #ifndef __DRM_BRIDGE_H__
 #define __DRM_BRIDGE_H__
 
-#include <linux/list.h>
 #include <linux/ctype.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
 #include <drm/drm_mode_object.h>
 #include <drm/drm_modes.h>
 
@@ -334,6 +335,110 @@  struct drm_bridge_funcs {
 	 */
 	void (*atomic_post_disable)(struct drm_bridge *bridge,
 				    struct drm_atomic_state *state);
+
+	/**
+	 * @detect:
+	 *
+	 * Check if anything is attached to the bridge output.
+	 *
+	 * This callback is optional, if not implemented the bridge will be
+	 * considered as always having a component attached to its output.
+	 * Bridges that implement this callback shall set the
+	 * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
+	 *
+	 * RETURNS:
+	 *
+	 * drm_connector_status indicating the bridge output status.
+	 */
+	enum drm_connector_status (*detect)(struct drm_bridge *bridge);
+
+	/**
+	 * @get_modes:
+	 *
+	 * Fill all modes currently valid for the sink into the &drm_connector
+	 * with drm_mode_probed_add().
+	 *
+	 * The @get_modes callback is mostly intended to support non-probable
+	 * displays such as many fixed panels. Bridges that support reading
+	 * EDID shall leave @get_modes unimplemented and implement the
+	 * &drm_bridge_funcs->get_edid callback instead.
+	 *
+	 * This callback is optional. Bridges that implement it shall set the
+	 * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
+	 *
+	 * RETURNS:
+	 *
+	 * The number of modes added by calling drm_mode_probed_add().
+	 */
+	int (*get_modes)(struct drm_bridge *bridge,
+			 struct drm_connector *connector);
+
+	/**
+	 * @get_edid:
+	 *
+	 * Read and parse the EDID data of the connected display.
+	 *
+	 * The @get_edid callback is the preferred way of reporting mode
+	 * information for a display connected to the bridge output. Bridges
+	 * that support readind EDID shall implement this callback and leave
+	 * the @get_modes callback unimplemented.
+	 *
+	 * The caller of this operation shall first verify the output
+	 * connection status and refrain from reading EDID from a disconnected
+	 * output.
+	 *
+	 * This callback is optional. Bridges that implement it shall set the
+	 * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
+	 *
+	 * RETURNS:
+	 *
+	 * An edid structure newly allocated with kmalloc() (or similar) on
+	 * success, or NULL otherwise. The caller is responsible for freeing
+	 * the returned edid structure with kfree().
+	 */
+	struct edid *(*get_edid)(struct drm_bridge *bridge,
+				 struct drm_connector *connector);
+
+	/**
+	 * @lost_hotplug:
+	 *
+	 * Notify the bridge of display disconnection.
+	 *
+	 * This callback is optional, it may be implemented by bridges that
+	 * need to be notified of display disconnection for internal reasons.
+	 * One use case is to reset the internal state of CEC controllers for
+	 * HDMI bridges.
+	 */
+	void (*lost_hotplug)(struct drm_bridge *bridge);
+
+	/**
+	 * @hpd_enable:
+	 *
+	 * Enable hot plug detection. From now on the bridge shall call
+	 * drm_bridge_hpd_notify() each time a change is detected in the output
+	 * connection status, until hot plug detection gets disabled with
+	 * @hpd_disable.
+	 *
+	 * This callback is optional and shall only be implemented by bridges
+	 * that support hot-plug notification without polling. Bridges that
+	 * implement it shall also implement the @hpd_disable callback and set
+	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
+	 */
+	void (*hpd_enable)(struct drm_bridge *bridge);
+
+	/**
+	 * @hpd_disable:
+	 *
+	 * Disable hot plug detection. Once this function returns the bridge
+	 * shall not call drm_bridge_hpd_notify() when a change in the output
+	 * connection status occurs.
+	 *
+	 * This callback is optional and shall only be implemented by bridges
+	 * that support hot-plug notification without polling. Bridges that
+	 * implement it shall also implement the @hpd_enable callback and set
+	 * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
+	 */
+	void (*hpd_disable)(struct drm_bridge *bridge);
 };
 
 /**
@@ -372,6 +477,38 @@  struct drm_bridge_timings {
 	bool dual_link;
 };
 
+/**
+ * enum drm_bridge_ops - Bitmask of operations supported by the bridge
+ */
+enum drm_bridge_ops {
+	/**
+	 * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
+	 * its output. Bridges that set this flag shall implement the
+	 * &drm_bridge_funcs->detect callback.
+	 */
+	DRM_BRIDGE_OP_DETECT = BIT(0),
+	/**
+	 * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
+	 * connected to its output. Bridges that set this flag shall implement
+	 * the &drm_bridge_funcs->get_edid callback.
+	 */
+	DRM_BRIDGE_OP_EDID = BIT(1),
+	/**
+	 * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
+	 * without requiring polling. Bridges that set this flag shall
+	 * implement the &drm_bridge_funcs->hpd_enable and
+	 * &drm_bridge_funcs->disable_hpd_cb callbacks.
+	 */
+	DRM_BRIDGE_OP_HPD = BIT(2),
+	/**
+	 * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
+	 * by the display at its output. This does not include readind EDID
+	 * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
+	 * this flag shall implement the &drm_bridge_funcs->get_modes callback.
+	 */
+	DRM_BRIDGE_OP_MODES = BIT(3),
+};
+
 /**
  * struct drm_bridge - central DRM bridge control structure
  */
@@ -398,6 +535,29 @@  struct drm_bridge {
 	const struct drm_bridge_funcs *funcs;
 	/** @driver_private: pointer to the bridge driver's internal context */
 	void *driver_private;
+	/** @ops: bitmask of operations supported by the bridge */
+	enum drm_bridge_ops ops;
+	/**
+	 * @type: Type of the connection at the bridge output
+	 * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
+	 * identifies the type of connected display.
+	 */
+	int type;
+	/** private: */
+	/**
+	 * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
+	 */
+	struct mutex hpd_mutex;
+	/**
+	 * @hpd_cb: Hot plug detection callback, registered with
+	 * drm_bridge_hpd_enable().
+	 */
+	void (*hpd_cb)(void *data, enum drm_connector_status status);
+	/**
+	 * @hpd_data: Private data passed to the Hot plug detection callback
+	 * @hpd_cb.
+	 */
+	void *hpd_data;
 };
 
 void drm_bridge_add(struct drm_bridge *bridge);
@@ -428,6 +588,14 @@  void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
 void drm_atomic_bridge_enable(struct drm_bridge *bridge,
 			      struct drm_atomic_state *state);
 
+void drm_bridge_hpd_enable(struct drm_bridge *bridge,
+			   void (*cb)(void *data,
+				      enum drm_connector_status status),
+			   void *data);
+void drm_bridge_hpd_disable(struct drm_bridge *bridge);
+void drm_bridge_hpd_notify(struct drm_bridge *bridge,
+			   enum drm_connector_status status);
+
 #ifdef CONFIG_DRM_PANEL_BRIDGE
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
 					u32 connector_type);