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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <laurent.pinchart@xxxxxxxxxxxxxxxx>
> >>>>> ---
> >>>>>  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);
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux