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