devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel@lists.freedesktop.org,
	Lucas Stach <l.stach@pengutronix.de>,
	Chris Healy <cphealy@gmail.com>,
	Andrey Smirnov <andrew.smirnov@gmail.com>,
	Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	kernel@collabora.com, Daniel Vetter <daniel@ffwll.ch>,
	Inki Dae <inki.dae@samsung.com>,
	Joonyoung Shim <jy0922.shim@samsung.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Rob Clark <robdclark@gmail.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v3 03/21] drm/exynos: Declare the DSI encoder as a bridge element
Date: Sun, 24 Nov 2019 14:17:27 +0100	[thread overview]
Message-ID: <20191124141727.45597a6e@collabora.com> (raw)
In-Reply-To: <20191124102433.GD4727@pendragon.ideasonboard.com>

Hi Laurent,

On Sun, 24 Nov 2019 12:24:33 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Wed, Oct 23, 2019 at 05:44:54PM +0200, Boris Brezillon wrote:
> > Encoder drivers will progressively transition to the drm_bridge
> > interface in place of the drm_encoder one.
> > 
> > Converting the Exynos DSI encoder driver to this approach allows us to
> > use the ->pre_{enable,disable}()  hooks and get rid of the hack
> > resetting encoder->bridge.next (which was needed to control the
> > encoder/bridge enable/disable sequence).
> > 
> > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> > ---
> > Changes in v3:
> > * Embed a drm_bridge object in exynos_dsi since drm_encoder no longer
> >   has a dummy bridge
> > 
> > Changes in v2:
> > * New patch (replacement for "drm/exynos: Get rid of exynos_dsi->out_bridge")
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 89 +++++++++++++++----------
> >  1 file changed, 55 insertions(+), 34 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > index 72726f2c7a9f..3915f50b005e 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> > @@ -252,10 +252,10 @@ struct exynos_dsi_driver_data {
> >  
> >  struct exynos_dsi {
> >  	struct drm_encoder encoder;
> > +	struct drm_bridge bridge;
> >  	struct mipi_dsi_host dsi_host;
> >  	struct drm_connector connector;
> >  	struct drm_panel *panel;
> > -	struct drm_bridge *out_bridge;
> >  	struct device *dev;
> >  
> >  	void __iomem *reg_base;
> > @@ -291,6 +291,11 @@ static inline struct exynos_dsi *encoder_to_dsi(struct drm_encoder *e)
> >  	return container_of(e, struct exynos_dsi, encoder);
> >  }
> >  
> > +static inline struct exynos_dsi *bridge_to_dsi(struct drm_bridge *b)
> > +{
> > +	return container_of(b, struct exynos_dsi, bridge);
> > +}
> > +
> >  enum reg_idx {
> >  	DSIM_STATUS_REG,	/* Status register */
> >  	DSIM_SWRST_REG,		/* Software reset register */
> > @@ -1374,25 +1379,38 @@ static void exynos_dsi_unregister_te_irq(struct exynos_dsi *dsi)
> >  	}
> >  }
> >  
> > -static void exynos_dsi_enable(struct drm_encoder *encoder)
> > +static void exynos_dsi_pre_enable(struct drm_bridge *bridge)
> >  {
> > -	struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> > +	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
> >  	int ret;
> >  
> >  	if (dsi->state & DSIM_STATE_ENABLED)
> >  		return;  
> 
> This can probably be removed now as the core should ensure that
> double-enable or double-disable never occurs, but it can be done in a
> separate patch.

Except the enable/disable() implementations handle failures (the
framework does not expect those to fails BTW), and I guess it's
important to know the actual HW state in order to keep runtime PM
get/put calls balanced.

> 
> >  
> >  	pm_runtime_get_sync(dsi->dev);
> > -	dsi->state |= DSIM_STATE_ENABLED;
> >  
> >  	if (dsi->panel) {
> >  		ret = drm_panel_prepare(dsi->panel);
> >  		if (ret < 0)
> >  			goto err_put_sync;
> > -	} else {
> > -		drm_bridge_pre_enable(dsi->out_bridge);
> >  	}  
> 
> It would be nice to switch to the drm panel bridge, but that can also be
> done on top of this series.

I agree, just didn't want to add more stuff to this series.

> 
> >  
> > +	dsi->state |= DSIM_STATE_ENABLED;
> > +	return;
> > +
> > +err_put_sync:
> > +	pm_runtime_put(dsi->dev);
> > +}
> > +
> > +static void exynos_dsi_enable(struct drm_bridge *bridge)
> > +{
> > +	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
> > +	int ret;
> > +
> > +	if (!(dsi->state & DSIM_STATE_ENABLED) ||
> > +	    (dsi->state & DSIM_STATE_VIDOUT_AVAILABLE))
> > +		return;
> > +
> >  	exynos_dsi_set_display_mode(dsi);
> >  	exynos_dsi_set_display_enable(dsi, true);
> >  
> > @@ -1400,8 +1418,6 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
> >  		ret = drm_panel_enable(dsi->panel);
> >  		if (ret < 0)
> >  			goto err_display_disable;
> > -	} else {
> > -		drm_bridge_enable(dsi->out_bridge);
> >  	}
> >  
> >  	dsi->state |= DSIM_STATE_VIDOUT_AVAILABLE;
> > @@ -1410,28 +1426,30 @@ static void exynos_dsi_enable(struct drm_encoder *encoder)
> >  err_display_disable:
> >  	exynos_dsi_set_display_enable(dsi, false);
> >  	drm_panel_unprepare(dsi->panel);  
> 
> Does this belong here, as drm_panel_prepare() was called in
> exynos_dsi_pre_enable() ?

Nope, this one should be dropped.

> 
> > -
> > -err_put_sync:
> > -	dsi->state &= ~DSIM_STATE_ENABLED;
> > -	pm_runtime_put(dsi->dev);
> >  }
> >  
> > -static void exynos_dsi_disable(struct drm_encoder *encoder)
> > +static void exynos_dsi_disable(struct drm_bridge *bridge)
> >  {
> > -	struct exynos_dsi *dsi = encoder_to_dsi(encoder);
> > +	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
> > +
> > +	if (!(dsi->state & DSIM_STATE_VIDOUT_AVAILABLE))
> > +		return;
> > +
> > +	drm_panel_disable(dsi->panel);
> > +	exynos_dsi_set_display_enable(dsi, false);
> > +	dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
> > +}
> > +
> > +static void exynos_dsi_post_disable(struct drm_bridge *bridge)
> > +{
> > +	struct exynos_dsi *dsi = bridge_to_dsi(bridge);
> >  
> >  	if (!(dsi->state & DSIM_STATE_ENABLED))
> >  		return;
> >  
> > -	dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
> > -
> > -	drm_panel_disable(dsi->panel);
> > -	drm_bridge_disable(dsi->out_bridge);
> > -	exynos_dsi_set_display_enable(dsi, false);
> >  	drm_panel_unprepare(dsi->panel);
> > -	drm_bridge_post_disable(dsi->out_bridge);
> > -	dsi->state &= ~DSIM_STATE_ENABLED;
> >  	pm_runtime_put_sync(dsi->dev);
> > +	dsi->state &= ~DSIM_STATE_ENABLED;
> >  }
> >  
> >  static enum drm_connector_status
> > @@ -1499,9 +1517,11 @@ static int exynos_dsi_create_connector(struct drm_encoder *encoder)
> >  	return 0;
> >  }
> >  
> > -static const struct drm_encoder_helper_funcs exynos_dsi_encoder_helper_funcs = {
> > +static const struct drm_bridge_funcs exynos_dsi_bridge_funcs = {
> > +	.pre_enable = exynos_dsi_pre_enable,
> >  	.enable = exynos_dsi_enable,
> >  	.disable = exynos_dsi_disable,
> > +	.post_disable = exynos_dsi_post_disable,
> >  };
> >  
> >  static const struct drm_encoder_funcs exynos_dsi_encoder_funcs = {
> > @@ -1520,9 +1540,7 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host,
> >  
> >  	out_bridge  = of_drm_find_bridge(device->dev.of_node);
> >  	if (out_bridge) {
> > -		drm_bridge_attach(encoder, out_bridge, NULL);
> > -		dsi->out_bridge = out_bridge;
> > -		encoder->bridge = NULL;
> > +		drm_bridge_attach(encoder, out_bridge, &dsi->bridge);
> >  	} else {
> >  		int ret = exynos_dsi_create_connector(encoder);
> >  
> > @@ -1575,19 +1593,19 @@ static int exynos_dsi_host_detach(struct mipi_dsi_host *host,
> >  				  struct mipi_dsi_device *device)
> >  {
> >  	struct exynos_dsi *dsi = host_to_dsi(host);
> > +	struct drm_bridge *out_bridge = dsi->bridge.next;
> >  	struct drm_device *drm = dsi->encoder.dev;
> >  
> >  	if (dsi->panel) {
> >  		mutex_lock(&drm->mode_config.mutex);
> > -		exynos_dsi_disable(&dsi->encoder);
> > +		exynos_dsi_disable(&dsi->bridge);
> > +		exynos_dsi_post_disable(&dsi->bridge);
> >  		drm_panel_detach(dsi->panel);
> >  		dsi->panel = NULL;
> >  		dsi->connector.status = connector_status_disconnected;
> >  		mutex_unlock(&drm->mode_config.mutex);
> > -	} else {
> > -		if (dsi->out_bridge->funcs->detach)
> > -			dsi->out_bridge->funcs->detach(dsi->out_bridge);
> > -		dsi->out_bridge = NULL;
> > +	} else if (out_bridge && out_bridge->funcs->detach) {
> > +		out_bridge->funcs->detach(out_bridge);  
> 
> Maybe drm_bridge_detach() ?

This function is not exported, and I suppose that's why they used the
function pointer in this driver. I bet there's a good reason for not
exposing this function...

> 
> >  	}
> >  
> >  	if (drm->mode_config.poll_enabled)
> > @@ -1687,16 +1705,18 @@ static int exynos_dsi_bind(struct device *dev, struct device *master,
> >  	drm_encoder_init(drm_dev, encoder, &exynos_dsi_encoder_funcs,
> >  			 DRM_MODE_ENCODER_TMDS, NULL);
> >  
> > -	drm_encoder_helper_add(encoder, &exynos_dsi_encoder_helper_funcs);
> > -
> >  	ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
> >  	if (ret < 0)
> >  		return ret;
> >  
> > +	/* Declare ourself as the first bridge element. */
> > +	dsi->bridge.funcs = &exynos_dsi_bridge_funcs;
> > +	drm_bridge_attach(encoder, &dsi->bridge, NULL);
> > +
> >  	if (dsi->in_bridge_node) {
> >  		in_bridge = of_drm_find_bridge(dsi->in_bridge_node);
> >  		if (in_bridge)
> > -			drm_bridge_attach(encoder, in_bridge, NULL);
> > +			drm_bridge_attach(encoder, in_bridge, &dsi->bridge);
> >  	}  
> 
> Same as for patch 01/21, maybe this could be moved to this bridge's
> attach operation ? Actually, now that I've read the code, this in_bridge
> part looks weird. Why would the DSI encoder have an input bridge that is
> has to manage itself ?

Yes, I know, it doesn't make any sense. Either we're dealing with a
bridge which can be chained to other bridges (can be placed in the
middle of a chain as well), or we're dealing with an encoder which
precedes any bridges. In the latter case (which is how exynos_dsi is
implemented) in_bridge doesn't have any meaning, and that's even worse
since we're placing the so-called input bridge (AKA previous bridge)
after our encoder (that's what drm_bridge_attach(encoder, in_bridge,
NULL) does).

TBH, I didn't want to go that far and fix existing drivers when I
started this series, so I think I'll rework the patchset to get rid of
the VC4 and exynos patches, even if that means having 2 drivers that
mess up with the encoder->bridge_chain list.

Regards,

Boris

  reply	other threads:[~2019-11-24 13:17 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23 15:44 [PATCH v3 00/21] drm: Add support for bus-format negotiation Boris Brezillon
2019-10-23 15:44 ` [PATCH v3 01/21] drm/vc4: Declare the DSI encoder as a bridge element Boris Brezillon
2019-11-24 10:01   ` Laurent Pinchart
2019-11-24 10:47     ` Boris Brezillon
2019-10-23 15:44 ` [PATCH v3 02/21] drm/exynos: Don't reset bridge->next Boris Brezillon
2019-10-28 12:19   ` Inki Dae
2019-10-23 15:44 ` [PATCH v3 03/21] drm/exynos: Declare the DSI encoder as a bridge element Boris Brezillon
2019-11-24 10:24   ` Laurent Pinchart
2019-11-24 13:17     ` Boris Brezillon [this message]
2019-11-24 13:28       ` Boris Brezillon
2019-11-24 14:02       ` Laurent Pinchart
2019-10-23 15:44 ` [PATCH v3 04/21] drm/bridge: Rename bridge helpers targeting a bridge chain Boris Brezillon
2019-10-25 13:26   ` Neil Armstrong
2019-11-24 10:28   ` Laurent Pinchart
2019-10-23 15:44 ` [PATCH v3 05/21] drm/bridge: Introduce drm_bridge_chain_get_next_bridge() Boris Brezillon
2019-10-25 13:27   ` Neil Armstrong
2019-11-24 10:33   ` Laurent Pinchart
2019-11-24 10:56     ` Boris Brezillon
2019-11-24 14:04       ` Laurent Pinchart
2019-10-23 15:44 ` [PATCH v3 06/21] drm: Stop accessing encoder->bridge directly Boris Brezillon
2019-10-25 13:28   ` Neil Armstrong
2019-11-24 10:39   ` Laurent Pinchart
2019-11-24 13:40     ` Boris Brezillon
2019-10-23 15:44 ` [PATCH v3 07/21] drm/bridge: Make the bridge chain a double-linked list Boris Brezillon
2019-10-25 13:29   ` Neil Armstrong
2019-11-05 16:02     ` Neil Armstrong
2019-11-24  7:48       ` Boris Brezillon
2019-11-24 13:57   ` Laurent Pinchart
2019-10-23 15:44 ` [PATCH v3 08/21] drm/bridge: Add the drm_for_each_bridge_in_chain() helper Boris Brezillon
2019-10-25 13:30   ` Neil Armstrong
2019-11-24 14:07   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 09/21] drm/bridge: Add a drm_bridge_state object Boris Brezillon
2019-10-25 14:35   ` Neil Armstrong
2019-11-05 16:05   ` Neil Armstrong
2019-11-24  7:50     ` Boris Brezillon
2019-12-02 16:42   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 10/21] drm/bridge: Clarify the atomic enable/disable hooks semantics Boris Brezillon
2019-10-25 14:33   ` Neil Armstrong
2019-12-02 16:50   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 11/21] drm/bridge: Patch atomic hooks to take a drm_bridge_state Boris Brezillon
2019-12-02 16:57   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 12/21] drm/bridge: Add an ->atomic_check() hook Boris Brezillon
2019-10-25 14:35   ` Neil Armstrong
2019-12-02 17:03   ` Laurent Pinchart
2019-12-03 10:11     ` Boris Brezillon
2019-12-03 10:15       ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 13/21] drm/bridge: Add the drm_bridge_chain_get_prev_bridge() helper Boris Brezillon
2019-10-25 14:34   ` Neil Armstrong
2019-12-02 17:05   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 14/21] drm/bridge: Add the necessary bits to support bus format negotiation Boris Brezillon
2019-12-03 10:03   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 15/21] drm/imx: pd: Use bus format/flags provided by the bridge when available Boris Brezillon
2019-12-03 13:50   ` Philipp Zabel
2019-10-23 15:45 ` [PATCH v3 16/21] drm/bridge: lvds-encoder: Implement basic bus format negotiation Boris Brezillon
2019-12-03 10:14   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 17/21] dt-bindings: display: bridge: lvds-transmitter: Add new props Boris Brezillon
2019-10-25 19:57   ` Rob Herring
2019-10-31 13:04     ` Boris Brezillon
2019-12-02 17:11   ` Laurent Pinchart
2019-12-03 12:38     ` Boris Brezillon
2019-12-03 13:22       ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 18/21] drm/bridge: panel: Propage bus format/flags Boris Brezillon
2019-12-03 10:17   ` Laurent Pinchart
2020-01-22  9:27     ` Boris Brezillon
2019-10-23 15:45 ` [PATCH v3 19/21] drm/panel: simple: Add support for Toshiba LTA089AC29000 panel Boris Brezillon
2019-12-02 17:17   ` Laurent Pinchart
2019-12-03 12:42     ` Boris Brezillon
2019-12-03 13:28       ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 20/21] dt-bindings: display: panel: Add the LTA089AC29000 variant Boris Brezillon
2019-10-25 19:58   ` Rob Herring
2019-12-02 17:19   ` Laurent Pinchart
2019-10-23 15:45 ` [PATCH v3 21/21] ARM: dts: imx: imx51-zii-rdu1: Fix the display pipeline definition Boris Brezillon
2019-10-24 11:27 ` [PATCH v3 00/21] drm: Add support for bus-format negotiation Neil Armstrong
2019-10-24 13:22   ` Boris Brezillon
2019-11-24  0:46 ` Ezequiel Garcia
2019-11-24  7:32   ` Boris Brezillon
2019-11-24  9:34     ` Ezequiel Garcia

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=20191124141727.45597a6e@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=a.hajda@samsung.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=cphealy@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=jy0922.shim@samsung.com \
    --cc=kernel@collabora.com \
    --cc=kyungmin.park@samsung.com \
    --cc=l.stach@pengutronix.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=mark.rutland@arm.com \
    --cc=narmstrong@baylibre.com \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robdclark@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sw0312.kim@samsung.com \
    --cc=thierry.reding@gmail.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;
as well as URLs for NNTP newsgroup(s).