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
> >>>>>>>>>>>>> <[email protected]>
> >>>>>>>>>>>>> ---
> >>>>>>>>>>>>> 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);
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
