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 <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.
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);
>>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
