From: Daniel Vetter <daniel@ffwll.ch>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
dri-devel@lists.freedesktop.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sean Paul <sean@poorly.run>
Subject: Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
Date: Thu, 11 Jul 2019 09:35:48 +0200 [thread overview]
Message-ID: <20190711073548.GD15868@phenom.ffwll.local> (raw)
In-Reply-To: <1f98e5f0-d513-d3f2-420d-80e0e0c3c71b@samsung.com>
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@ideasonboard.com>
> > ---
> > drivers/gpu/drm/drm_bridge.c | 92 +++++++++++++++++++
> > include/drm/drm_bridge.h | 170 ++++++++++++++++++++++++++++++++++-
> > 2 files changed, 261 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 519577f363e3..3c2a255df7af 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > */
> > void drm_bridge_add(struct drm_bridge *bridge)
> > {
> > + mutex_init(&bridge->hpd_mutex);
> > +
> > mutex_lock(&bridge_lock);
> > list_add_tail(&bridge->list, &bridge_list);
> > mutex_unlock(&bridge_lock);
> > @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > mutex_lock(&bridge_lock);
> > list_del_init(&bridge->list);
> > mutex_unlock(&bridge_lock);
> > +
> > + mutex_destroy(&bridge->hpd_mutex);
> > }
> > EXPORT_SYMBOL(drm_bridge_remove);
> >
> > @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > }
> > EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >
> > +/**
> > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > + * @bridge: bridge control structure
> > + * @cb: hot-plug detection callback
> > + * @data: data to be passed to the hot-plug detection callback
> > + *
> > + * Call &drm_bridge_funcs.hpd_enable and register the given @cb and @data as
> > + * hot plug notification callback. From now on the @cb will be called with
> > + * @data when an output status change is detected by the bridge, until hot plug
> > + * notification gets disabled with drm_bridge_hpd_disable().
> > + *
> > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > + * bridge->ops. This function shall not be called when the flag is not set.
> > + *
> > + * Only one hot plug detection callback can be registered at a time, it is an
> > + * error to call this function when hot plug detection is already enabled for
> > + * the bridge.
> > + */
>
>
> To simplify architecture maybe would be better to enable hpd just on
> bridge attach:
>
> bridge->hpd_cb = cb;
>
> bridge->hpd_data = data;
>
> ret = drm_bridge_attach(...);
Yeah I like this more. The other problem here is, what if you need more
than 1 callback registers on the same bridge hdp signal?
> This way we could avoid adding new callbacks hpd_(enable|disable)
> without big sacrifices.
>
>
> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> notifies about sink status change, how it translates to this cb?
>
>
> > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > + void (*cb)(void *data,
> > + enum drm_connector_status status),
> > + void *data)
> > +{
> > + if (!bridge || !bridge->funcs->hpd_enable)
> > + return;
> > +
> > + mutex_lock(&bridge->hpd_mutex);
> > +
> > + if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
> > + goto unlock;
> > +
> > + bridge->hpd_cb = cb;
> > + bridge->hpd_data = data;
> > +
> > + bridge->funcs->hpd_enable(bridge);
> > +
> > +unlock:
> > + mutex_unlock(&bridge->hpd_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_enable);
> > +
> > +/**
> > + * drm_bridge_hpd_disable - disable hot plug detection for the bridge
> > + * @bridge: bridge control structure
> > + *
> > + * Call &drm_bridge_funcs.hpd_disable and unregister the hot plug detection
> > + * callback previously registered with drm_bridge_hpd_enable(). Once this
> > + * function returns the callback will not be called by the bridge when an
> > + * output status change occurs.
> > + *
> > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is set in
> > + * bridge->ops. This function shall not be called when the flag is not set.
> > + */
> > +void drm_bridge_hpd_disable(struct drm_bridge *bridge)
> > +{
> > + if (!bridge || !bridge->funcs->hpd_disable)
> > + return;
> > +
> > + mutex_lock(&bridge->hpd_mutex);
> > + bridge->funcs->hpd_disable(bridge);
> > +
> > + bridge->hpd_cb = NULL;
> > + bridge->hpd_data = NULL;
> > + mutex_unlock(&bridge->hpd_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
> > +
> > +/**
> > + * drm_bridge_hpd_notify - notify hot plug detection events
> > + * @bridge: bridge control structure
> > + * @status: output connection status
> > + *
> > + * Bridge drivers shall call this function to report hot plug events when they
> > + * detect a change in the output status, when hot plug detection has been
> > + * enabled by the &drm_bridge_funcs.hpd_enable callback.
> > + *
> > + * This function shall be called in a context that can sleep.
> > + */
> > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > + enum drm_connector_status status)
> > +{
> > + mutex_lock(&bridge->hpd_mutex);
> > + if (bridge->hpd_cb)
> > + bridge->hpd_cb(bridge->hpd_data, status);
So this isn't quite what I had in mind. Instead something like this:
/* iterates over all bridges in the chain containing @bridge */
for_each_bridge(tmp_bridge, bridge) {
if (tmp_bridge == bridge)
continue;
if (bridge->hpd_notify);
bridge->hpd_notify(tmp_bridge, bridge, status);
}
encoder = encoder_for_bridge(bridge);
if (encoder->helper_private->bridge_hpd_notify)
encoder->helper_private->bridge_hpd_notify(encoder, bridge, status);
dev = bridge->dev
if (dev->mode_config.helper_private->bridge_hpd_notify)
dev->mode_config.helper_private->bridge_hpd_notify(dev, bridge, status)
No register callback needed, no locking needed, everyone gets exactly the
hpd they want/need.
> > + mutex_unlock(&bridge->hpd_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
> > +
> > #ifdef CONFIG_OF
> > /**
> > * of_drm_find_bridge - find the bridge corresponding to the device node in
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index 08dc15f93ded..b9445aa5b1ef 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -23,8 +23,9 @@
> > #ifndef __DRM_BRIDGE_H__
> > #define __DRM_BRIDGE_H__
> >
> > -#include <linux/list.h>
> > #include <linux/ctype.h>
> > +#include <linux/list.h>
> > +#include <linux/mutex.h>
> > #include <drm/drm_mode_object.h>
> > #include <drm/drm_modes.h>
> >
> > @@ -334,6 +335,110 @@ struct drm_bridge_funcs {
> > */
> > void (*atomic_post_disable)(struct drm_bridge *bridge,
> > struct drm_atomic_state *state);
> > +
> > + /**
> > + * @detect:
> > + *
> > + * Check if anything is attached to the bridge output.
> > + *
> > + * This callback is optional, if not implemented the bridge will be
> > + * considered as always having a component attached to its output.
> > + * Bridges that implement this callback shall set the
> > + * DRM_BRIDGE_OP_DETECT flag in their &drm_bridge->ops.
> > + *
> > + * RETURNS:
> > + *
> > + * drm_connector_status indicating the bridge output status.
> > + */
> > + enum drm_connector_status (*detect)(struct drm_bridge *bridge);
> > +
> > + /**
> > + * @get_modes:
> > + *
> > + * Fill all modes currently valid for the sink into the &drm_connector
> > + * with drm_mode_probed_add().
> > + *
> > + * The @get_modes callback is mostly intended to support non-probable
> > + * displays such as many fixed panels. Bridges that support reading
> > + * EDID shall leave @get_modes unimplemented and implement the
> > + * &drm_bridge_funcs->get_edid callback instead.
> > + *
> > + * This callback is optional. Bridges that implement it shall set the
> > + * DRM_BRIDGE_OP_MODES flag in their &drm_bridge->ops.
> > + *
> > + * RETURNS:
> > + *
> > + * The number of modes added by calling drm_mode_probed_add().
> > + */
> > + int (*get_modes)(struct drm_bridge *bridge,
> > + struct drm_connector *connector);
> > +
> > + /**
> > + * @get_edid:
> > + *
> > + * Read and parse the EDID data of the connected display.
> > + *
> > + * The @get_edid callback is the preferred way of reporting mode
> > + * information for a display connected to the bridge output. Bridges
> > + * that support readind EDID shall implement this callback and leave
> > + * the @get_modes callback unimplemented.
> > + *
> > + * The caller of this operation shall first verify the output
> > + * connection status and refrain from reading EDID from a disconnected
> > + * output.
> > + *
> > + * This callback is optional. Bridges that implement it shall set the
> > + * DRM_BRIDGE_OP_EDID flag in their &drm_bridge->ops.
> > + *
> > + * RETURNS:
> > + *
> > + * An edid structure newly allocated with kmalloc() (or similar) on
> > + * success, or NULL otherwise. The caller is responsible for freeing
> > + * the returned edid structure with kfree().
> > + */
> > + struct edid *(*get_edid)(struct drm_bridge *bridge,
> > + struct drm_connector *connector);
>
>
> It overlaps with get_modes, I guess presence of one ops should disallow
> presence of another one?
>
> I am not really convinced we need this op at all, cannot we just assign
> some helper function to .get_modes cb, which will do the same?
Plan B): ditch ->get_edid, require that the driver has ->get_modes in that
case, and require that if it has an edid it must fill out connector->info
and connector->edid correctly.
Btw if a hpd happens, who's responible for making sure the edid/mode list
in the connector is up-to-date? With your current callback design that's
up to the callback, which doesn't feel great. Maybe drm_bridge_hpd_notify
should guarantee that it'll first walk the connectors to update status and
edid/mode list for the final drm_connector. And then instead of just
passing the simple "status", it'll pass the connector, with everything
correctly updated.
Otherwise everyone interested in that hpd signal will go and re-fetch the
edid, which is not so awesome :-)
-Daniel
>
>
> Regards
>
> Andrzej
>
>
> > +
> > + /**
> > + * @lost_hotplug:
> > + *
> > + * Notify the bridge of display disconnection.
> > + *
> > + * This callback is optional, it may be implemented by bridges that
> > + * need to be notified of display disconnection for internal reasons.
> > + * One use case is to reset the internal state of CEC controllers for
> > + * HDMI bridges.
> > + */
> > + void (*lost_hotplug)(struct drm_bridge *bridge);
> > +
> > + /**
> > + * @hpd_enable:
> > + *
> > + * Enable hot plug detection. From now on the bridge shall call
> > + * drm_bridge_hpd_notify() each time a change is detected in the output
> > + * connection status, until hot plug detection gets disabled with
> > + * @hpd_disable.
> > + *
> > + * This callback is optional and shall only be implemented by bridges
> > + * that support hot-plug notification without polling. Bridges that
> > + * implement it shall also implement the @hpd_disable callback and set
> > + * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > + */
> > + void (*hpd_enable)(struct drm_bridge *bridge);
> > +
> > + /**
> > + * @hpd_disable:
> > + *
> > + * Disable hot plug detection. Once this function returns the bridge
> > + * shall not call drm_bridge_hpd_notify() when a change in the output
> > + * connection status occurs.
> > + *
> > + * This callback is optional and shall only be implemented by bridges
> > + * that support hot-plug notification without polling. Bridges that
> > + * implement it shall also implement the @hpd_enable callback and set
> > + * the DRM_BRIDGE_OP_HPD flag in their &drm_bridge->ops.
> > + */
> > + void (*hpd_disable)(struct drm_bridge *bridge);
> > };
> >
> > /**
> > @@ -372,6 +477,38 @@ struct drm_bridge_timings {
> > bool dual_link;
> > };
> >
> > +/**
> > + * enum drm_bridge_ops - Bitmask of operations supported by the bridge
> > + */
> > +enum drm_bridge_ops {
> > + /**
> > + * @DRM_BRIDGE_OP_DETECT: The bridge can detect displays connected to
> > + * its output. Bridges that set this flag shall implement the
> > + * &drm_bridge_funcs->detect callback.
> > + */
> > + DRM_BRIDGE_OP_DETECT = BIT(0),
> > + /**
> > + * @DRM_BRIDGE_OP_EDID: The bridge can retrieve the EDID of the display
> > + * connected to its output. Bridges that set this flag shall implement
> > + * the &drm_bridge_funcs->get_edid callback.
> > + */
> > + DRM_BRIDGE_OP_EDID = BIT(1),
> > + /**
> > + * @DRM_BRIDGE_OP_HPD: The bridge can detect hot-plug and hot-unplug
> > + * without requiring polling. Bridges that set this flag shall
> > + * implement the &drm_bridge_funcs->hpd_enable and
> > + * &drm_bridge_funcs->disable_hpd_cb callbacks.
> > + */
> > + DRM_BRIDGE_OP_HPD = BIT(2),
> > + /**
> > + * @DRM_BRIDGE_OP_MODES: The bridge can retrieving the modes supported
> > + * by the display at its output. This does not include readind EDID
> > + * which is separately covered by @DRM_BRIDGE_OP_EDID. Bridges that set
> > + * this flag shall implement the &drm_bridge_funcs->get_modes callback.
> > + */
> > + DRM_BRIDGE_OP_MODES = BIT(3),
> > +};
> > +
> > /**
> > * struct drm_bridge - central DRM bridge control structure
> > */
> > @@ -398,6 +535,29 @@ struct drm_bridge {
> > const struct drm_bridge_funcs *funcs;
> > /** @driver_private: pointer to the bridge driver's internal context */
> > void *driver_private;
> > + /** @ops: bitmask of operations supported by the bridge */
> > + enum drm_bridge_ops ops;
> > + /**
> > + * @type: Type of the connection at the bridge output
> > + * (DRM_MODE_CONNECTOR_*). For bridges at the end of this chain this
> > + * identifies the type of connected display.
> > + */
> > + int type;
> > + /** private: */
> > + /**
> > + * @hpd_mutex: Protects the @hpd_cb and @hpd_data fields.
> > + */
> > + struct mutex hpd_mutex;
> > + /**
> > + * @hpd_cb: Hot plug detection callback, registered with
> > + * drm_bridge_hpd_enable().
> > + */
> > + void (*hpd_cb)(void *data, enum drm_connector_status status);
> > + /**
> > + * @hpd_data: Private data passed to the Hot plug detection callback
> > + * @hpd_cb.
> > + */
> > + void *hpd_data;
> > };
> >
> > void drm_bridge_add(struct drm_bridge *bridge);
> > @@ -428,6 +588,14 @@ void drm_atomic_bridge_pre_enable(struct drm_bridge *bridge,
> > void drm_atomic_bridge_enable(struct drm_bridge *bridge,
> > struct drm_atomic_state *state);
> >
> > +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> > + void (*cb)(void *data,
> > + enum drm_connector_status status),
> > + void *data);
> > +void drm_bridge_hpd_disable(struct drm_bridge *bridge);
> > +void drm_bridge_hpd_notify(struct drm_bridge *bridge,
> > + enum drm_connector_status status);
> > +
> > #ifdef CONFIG_DRM_PANEL_BRIDGE
> > struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
> > u32 connector_type);
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-07-11 7:35 UTC|newest]
Thread overview: 166+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-07 18:07 [PATCH 00/60] drm/omap: Replace custom display drivers with drm_bridge and drm_panel Laurent Pinchart
2019-07-07 18:07 ` [PATCH 01/60] drm/edid: Add flag to drm_display_info to identify HDMI sinks Laurent Pinchart
2019-07-09 13:20 ` Andrzej Hajda
2019-07-10 15:41 ` Daniel Vetter
2019-07-10 15:59 ` Ville Syrjälä
2019-07-07 18:07 ` [PATCH 02/60] video: hdmi: Change return type of hdmi_avi_infoframe_init() to void Laurent Pinchart
2019-07-07 18:14 ` Laurent Pinchart
2019-07-07 18:21 ` Ilia Mirkin
2019-07-09 13:22 ` Andrzej Hajda
2019-07-07 18:07 ` [PATCH 03/60] drm/bridge: dumb-vga-dac: Rename internal symbols to simple-bridge Laurent Pinchart
2019-07-09 13:34 ` Andrzej Hajda
2019-07-07 18:18 ` [PATCH 04/60] drm/bridge: dumb-vga-dac: Rename driver " Laurent Pinchart
2019-07-07 18:18 ` [PATCH 05/60] drm/bridge: simple-bridge: Add support for non-VGA bridges Laurent Pinchart
2019-07-09 14:08 ` Andrzej Hajda
2019-07-26 13:24 ` Stefan Agner
2019-07-07 18:18 ` [PATCH 06/60] drm/bridge: simple-bridge: Add support for enable GPIO Laurent Pinchart
2019-07-09 14:32 ` Andrzej Hajda
2019-07-26 13:19 ` Stefan Agner
2019-07-07 18:18 ` [PATCH 07/60] drm/bridge: simple-bridge: Add support for the TI OP362 Laurent Pinchart
2019-07-09 14:32 ` Andrzej Hajda
2019-08-27 6:16 ` Tomi Valkeinen
2019-07-07 18:18 ` [PATCH 08/60] drm/bridge: Extend bridge API to disable connector creation Laurent Pinchart
2019-07-17 6:39 ` Andrzej Hajda
2019-08-08 14:25 ` Laurent Pinchart
2019-08-08 17:36 ` Andrzej Hajda
2019-08-08 18:50 ` Laurent Pinchart
2019-08-14 8:18 ` Daniel Vetter
2019-08-14 9:55 ` Laurent Pinchart
2019-08-14 12:24 ` Daniel Vetter
2019-07-07 18:18 ` [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data Laurent Pinchart
2019-07-10 12:12 ` Andrzej Hajda
2019-07-11 7:35 ` Daniel Vetter [this message]
2019-07-11 12:41 ` Andrzej Hajda
2019-07-11 13:18 ` Daniel Vetter
2019-07-11 15:12 ` Andrzej Hajda
2019-07-11 15:50 ` Daniel Vetter
2019-07-12 9:01 ` Andrzej Hajda
2019-07-16 9:00 ` Daniel Vetter
2019-07-16 13:57 ` Andrzej Hajda
2019-08-08 19:32 ` Laurent Pinchart
2019-08-09 11:55 ` Andrzej Hajda
2019-08-10 22:43 ` Laurent Pinchart
2019-08-14 6:23 ` Andrzej Hajda
2019-08-14 10:04 ` Laurent Pinchart
2019-08-14 12:40 ` Daniel Vetter
2019-08-19 8:38 ` Andrzej Hajda
2019-08-19 22:45 ` Laurent Pinchart
2019-08-22 12:17 ` Andrzej Hajda
2019-08-26 16:27 ` Laurent Pinchart
2019-08-29 16:48 ` Andrzej Hajda
2019-12-02 15:40 ` Laurent Pinchart
2019-08-14 12:35 ` Daniel Vetter
2019-08-19 22:32 ` Laurent Pinchart
2019-08-20 8:30 ` Daniel Vetter
2019-08-26 15:57 ` Laurent Pinchart
2019-08-08 18:19 ` Laurent Pinchart
2019-08-08 18:36 ` Laurent Pinchart
2019-08-14 13:03 ` Daniel Vetter
2019-08-14 13:30 ` Laurent Pinchart
2019-08-14 17:02 ` Daniel Vetter
2019-08-16 23:30 ` Laurent Pinchart
2019-08-17 0:14 ` Laurent Pinchart
2019-08-19 2:37 ` Laurent Pinchart
2019-08-20 8:41 ` Daniel Vetter
2019-08-14 12:43 ` Daniel Vetter
2019-08-14 12:56 ` Laurent Pinchart
2019-07-07 18:18 ` [PATCH 10/60] drm/bridge: Add bridge driver for display connectors Laurent Pinchart
2019-07-16 9:28 ` Sam Ravnborg
2019-08-08 16:41 ` Laurent Pinchart
2019-09-30 11:15 ` Tomi Valkeinen
2019-10-01 20:08 ` Laurent Pinchart
2019-10-02 12:38 ` Tomi Valkeinen
2019-07-07 18:18 ` [PATCH 11/60] drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter Laurent Pinchart
[not found] ` <3347b6c8-6f2d-17d6-3dc8-e62a3bac634b@ti.com>
2019-08-27 7:30 ` Laurent Pinchart
2019-07-07 18:18 ` [PATCH 12/60] drm/bridge: panel: Implement bridge connector operations Laurent Pinchart
2019-07-16 11:08 ` drm_panel_get_modes() should take the connector as an argument [Was: drm/bridge: panel: Implement bridge ...] Sam Ravnborg
2019-08-08 16:07 ` Laurent Pinchart
2019-08-08 16:52 ` Sam Ravnborg
2019-08-08 18:37 ` Laurent Pinchart
2019-07-07 18:18 ` [PATCH 13/60] drm/bridge: tfp410: Don't include drmP.h Laurent Pinchart
[not found] ` <3bb82dc4-434a-aaac-8ea1-3aff0991e790@ti.com>
2019-08-27 7:47 ` Laurent Pinchart
2019-07-07 18:18 ` [PATCH 14/60] drm/bridge: tfp410: Replace manual connector handling with bridge Laurent Pinchart
2019-07-07 18:18 ` [PATCH 15/60] drm/bridge: tfp410: Allow operation without drm_connector Laurent Pinchart
2019-07-07 18:18 ` [PATCH 16/60] dt-bindings: Add vendor prefix for LG Display Laurent Pinchart
2019-07-24 16:22 ` Rob Herring
2019-07-07 18:18 ` [PATCH 17/60] dt-bindings: Add legacy 'toppoly' vendor prefix Laurent Pinchart
2019-07-08 19:00 ` Rob Herring
2019-07-09 1:00 ` Laurent Pinchart
2019-07-09 1:35 ` Rob Herring
2019-07-07 18:18 ` [PATCH 18/60] dt-bindings: display: panel: Add bindings for NEC NL8048HL11 panel Laurent Pinchart
2019-07-07 18:18 ` [PATCH 19/60] drm/panel: Add driver for the LG Philips LB035Q02 panel Laurent Pinchart
2019-07-08 18:51 ` Sam Ravnborg
2019-07-09 0:56 ` Laurent Pinchart
2019-07-09 5:47 ` Sam Ravnborg
2019-07-07 18:18 ` [PATCH 20/60] drm/panel: Add driver for the NEC NL8048HL11 panel Laurent Pinchart
2019-07-08 19:10 ` Sam Ravnborg
2019-07-08 19:26 ` Sam Ravnborg
2019-08-08 15:17 ` Laurent Pinchart
2019-07-07 18:18 ` [PATCH 21/60] drm/panel: Add driver for the Sharp LS037V7DW01 panel Laurent Pinchart
2019-07-08 19:44 ` Sam Ravnborg
2019-07-08 19:47 ` Sam Ravnborg
2019-08-08 15:31 ` Laurent Pinchart
2019-07-07 18:18 ` [PATCH 22/60] drm/panel: Add driver for the Sony ACX565AKM panel Laurent Pinchart
2019-07-07 18:19 ` [PATCH 23/60] drm/panel: Add driver for the Toppology TD028TTEC1 panel Laurent Pinchart
2019-07-10 7:48 ` Sam Ravnborg
2019-08-08 15:43 ` Laurent Pinchart
2019-07-07 18:19 ` [PATCH 24/60] drm/panel: Add driver for the Toppology TD043MTEA1 panel Laurent Pinchart
2019-07-10 13:09 ` Sam Ravnborg
2019-08-08 15:54 ` Laurent Pinchart
2019-08-09 13:33 ` Sam Ravnborg
2019-08-09 17:51 ` Laurent Pinchart
2019-07-07 18:19 ` [PATCH 25/60] drm: Add helper to create a connector for a chain of bridges Laurent Pinchart
2019-07-18 17:01 ` Daniel Vetter
2019-08-08 19:48 ` Laurent Pinchart
2019-08-14 15:01 ` Daniel Vetter
2019-08-19 22:16 ` Laurent Pinchart
2019-07-07 18:19 ` [PATCH 26/60] drm/omap: Detach from panels at remove time Laurent Pinchart
2019-08-13 7:28 ` Tomi Valkeinen
2019-08-13 13:50 ` Laurent Pinchart
2019-07-07 18:19 ` [PATCH 27/60] drm/omap: Simplify HDMI mode and infoframe configuration Laurent Pinchart
2019-08-13 7:29 ` Tomi Valkeinen
2019-07-07 18:19 ` [PATCH 28/60] drm/omap: Factor out display type to connector type conversion Laurent Pinchart
2019-08-13 7:32 ` Tomi Valkeinen
2019-08-13 15:18 ` Laurent Pinchart
2019-07-07 18:19 ` [PATCH 29/60] drm/omap: Use the drm_panel_bridge API Laurent Pinchart
2019-08-13 7:36 ` Tomi Valkeinen
2019-07-07 18:19 ` [PATCH 30/60] drm/omap: dss: Fix output next device lookup in DT Laurent Pinchart
2019-08-13 7:38 ` Tomi Valkeinen
2019-07-07 18:19 ` [PATCH 31/60] drm/omap: Add infrastructure to support drm_bridge local to DSS outputs Laurent Pinchart
2019-07-07 18:19 ` [PATCH 32/60] drm/omap: dss: Make omap_dss_device_ops optional Laurent Pinchart
2019-08-13 7:48 ` Tomi Valkeinen
2019-08-13 13:55 ` Laurent Pinchart
2019-07-07 18:19 ` [PATCH 33/60] drm/omap: hdmi: Allocate EDID in the .read_edid() operation Laurent Pinchart
2019-08-13 7:52 ` Tomi Valkeinen
2019-07-07 18:19 ` [PATCH 34/60] drm/omap: hdmi4: Rework EDID read to isolate data read Laurent Pinchart
2019-07-07 18:19 ` [PATCH 35/60] drm/omap: hdmi5: " Laurent Pinchart
2019-07-07 18:19 ` [PATCH 36/60] drm/omap: hdmi4: Register a drm_bridge for EDID read Laurent Pinchart
2019-07-07 18:19 ` [PATCH 37/60] drm/omap: hdmi5: " Laurent Pinchart
2019-07-07 18:19 ` [PATCH 38/60] drm/omap: hdmi4: Move mode set, enable and disable operations to bridge Laurent Pinchart
2019-07-07 18:19 ` [PATCH 39/60] drm/omap: hdmi5: " Laurent Pinchart
2019-07-07 18:19 ` [PATCH 40/60] drm/omap: hdmi4: Implement drm_bridge .lost_hotplug() operation Laurent Pinchart
2019-07-07 18:19 ` [PATCH 41/60] drm/omap: dss: Remove .set_hdmi_mode() and .set_infoframe() operations Laurent Pinchart
2019-07-07 18:19 ` [PATCH 42/60] drm/omap: venc: Register a drm_bridge Laurent Pinchart
2019-07-07 18:19 ` [PATCH 43/60] drm/omap: Create connector for bridges Laurent Pinchart
2019-07-07 18:19 ` [PATCH 44/60] drm/omap: Switch the HDMI and VENC outputs to drm_bridge Laurent Pinchart
2019-07-07 18:19 ` [PATCH 45/60] drm/omap: Remove HPD, detect and EDID omapdss operations Laurent Pinchart
2019-07-07 18:19 ` [PATCH 46/60] drm/omap: hdmi: Remove omap_dss_device operations Laurent Pinchart
2019-07-07 18:19 ` [PATCH 47/60] drm/omap: venc: " Laurent Pinchart
2019-07-07 18:19 ` [PATCH 48/60] drm/omap: hdmi4: Simplify EDID read Laurent Pinchart
2019-07-07 18:19 ` [PATCH 49/60] drm/omap: hdmi5: " Laurent Pinchart
2019-07-07 18:19 ` [PATCH 50/60] drm/omap: displays: Remove unused panel drivers Laurent Pinchart
2019-07-07 18:19 ` [PATCH 51/60] drm/omap: dpi: Sort includes alphabetically Laurent Pinchart
2019-07-07 18:19 ` [PATCH 52/60] drm/omap: dpi: Reorder functions in sections Laurent Pinchart
2019-07-07 18:19 ` [PATCH 53/60] drm/omap: dpi: Simplify clock setting API Laurent Pinchart
2019-07-07 18:19 ` [PATCH 54/60] drm/omap: dpi: Register a drm_bridge Laurent Pinchart
2019-07-07 18:19 ` [PATCH 55/60] drm/omap: sdi: Sort includes alphabetically Laurent Pinchart
2019-07-07 18:19 ` [PATCH 56/60] drm/omap: sdi: Register a drm_bridge Laurent Pinchart
2019-07-07 18:19 ` [PATCH 57/60] drm/omap: Simplify connector implementation Laurent Pinchart
2019-07-07 18:19 ` [PATCH 58/60] drm/omap: dss: Remove unused omap_dss_device operations Laurent Pinchart
2019-07-07 18:19 ` [PATCH 59/60] drm/omap: dss: Inline the omapdss_display_get() function Laurent Pinchart
2019-07-07 18:19 ` [PATCH 60/60] drm/omap: dss: Remove unused omapdss_of_find_connected_device() function Laurent Pinchart
2019-07-09 13:35 ` [PATCH 04/60] drm/bridge: dumb-vga-dac: Rename driver to simple-bridge Andrzej Hajda
2019-07-11 7:37 ` [PATCH 00/60] drm/omap: Replace custom display drivers with drm_bridge and drm_panel Daniel Vetter
2019-07-11 11:59 ` Sebastian Reichel
2019-08-08 14:26 ` Laurent Pinchart
2019-08-08 14:31 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190711073548.GD15868@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=a.hajda@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=maxime.ripard@bootlin.com \
--cc=sean@poorly.run \
--cc=sebastian.reichel@collabora.com \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox