Linux Renesas SOC kernel development
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Jacopo Mondi <jacopo@jmondi.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel@lists.freedesktop.org,
	linux-renesas-soc@vger.kernel.org,
	Kieran Bingham <kieran.bingham@ideasonboard.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Jacopo Mondi <jacopo+renesas@jmondi.org>
Subject: Re: [PATCH/RFC 06/15] drm: bridge: thc63: Report input bus mode through bridge timings
Date: Fri, 8 Mar 2019 20:00:28 +0200	[thread overview]
Message-ID: <20190308180028.GB11318@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20190308173259.oize6d766dlzkz2q@uno.localdomain>

Hi Jacopo,

On Fri, Mar 08, 2019 at 06:32:59PM +0100, Jacopo Mondi wrote:
> On Thu, Mar 07, 2019 at 01:23:36AM +0200, Laurent Pinchart wrote:
> > Set a drm_bridge_timings in the drm_bridge, and use it to report the
> > input bus mode (single-link or dual-link). The other fields of the
> > timings structure are kept to 0 as they do not apply to LVDS buses.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >  drivers/gpu/drm/bridge/thc63lvd1024.c | 46 ++++++++++++++++++++-------
> >  1 file changed, 35 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > index b083a740565c..206b0af5e154 100644
> > --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -31,6 +31,8 @@ struct thc63_dev {
> >
> >  	struct drm_bridge bridge;
> >  	struct drm_bridge *next;
> > +
> > +	struct drm_bridge_timings timings;
> >  };
> >
> >  static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > @@ -48,15 +50,28 @@ static int thc63_attach(struct drm_bridge *bridge)
> >  static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
> >  					const struct drm_display_mode *mode)
> >  {
> > +	struct thc63_dev *thc63 = to_thc63(bridge);
> > +	unsigned int min_freq;
> > +	unsigned int max_freq;
> > +
> >  	/*
> > -	 * The THC63LVD1024 clock frequency range is 8 to 135 MHz in single-in
> > -	 * mode. Note that the limits are different in dual-in, single-out mode,
> > -	 * and will need to be adjusted accordingly.
> > +	 * The THC63LVD1024 pixel rate range is 8 to 135 MHz in all modes but
> > +	 * dual-in, single-out where it is 40 to 150 MHz. As dual-in, dual-out
> > +	 * isn't supported by the driver yet, simply derive the limits from the
> > +	 * input mode.
> >  	 */
> > -	if (mode->clock < 8000)
> > +	if (thc63->timings.dual_link) {
> > +		min_freq = 40000;
> > +		max_freq = 150000;
> > +	} else {
> > +		min_freq = 8000;
> > +		max_freq = 135000;
> > +	}
> > +
> > +	if (mode->clock < min_freq)
> >  		return MODE_CLOCK_LOW;
> >
> > -	if (mode->clock > 135000)
> > +	if (mode->clock > max_freq)
> >  		return MODE_CLOCK_HIGH;
> >
> >  	return MODE_OK;
> > @@ -101,19 +116,19 @@ static const struct drm_bridge_funcs thc63_bridge_func = {
> >
> >  static int thc63_parse_dt(struct thc63_dev *thc63)
> >  {
> > -	struct device_node *thc63_out;
> > +	struct device_node *endpoint;
> >  	struct device_node *remote;
> >
> > -	thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> > -						  THC63_RGB_OUT0, -1);
> > -	if (!thc63_out) {
> > +	endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> > +						 THC63_RGB_OUT0, -1);
> > +	if (!endpoint) {
> >  		dev_err(thc63->dev, "Missing endpoint in port@%u\n",
> >  			THC63_RGB_OUT0);
> >  		return -ENODEV;
> >  	}
> >
> > -	remote = of_graph_get_remote_port_parent(thc63_out);
> > -	of_node_put(thc63_out);
> > +	remote = of_graph_get_remote_port_parent(endpoint);
> > +	of_node_put(endpoint);
> >  	if (!remote) {
> >  		dev_err(thc63->dev, "Endpoint in port@%u unconnected\n",
> >  			THC63_RGB_OUT0);
> > @@ -132,6 +147,14 @@ static int thc63_parse_dt(struct thc63_dev *thc63)
> >  	if (!thc63->next)
> >  		return -EPROBE_DEFER;
> >
> > +	endpoint = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
> > +						 THC63_LVDS_IN1, -1);
> > +	of_node_put(endpoint);
> > +
> 
> Should you check if endpoint is enabled?

Can endpoints be disabled ?

> By the way, this seems to me works properly, as in [12/15] if skip
> creation of the LVDS1 encoder if it is operating in dual link mode.
> Without that, we would hit again the issue of matching on device
> nodes, as the same bridge would be attached twice, am I wrong?
> 
> I feel we've been there already :)
> https://lkml.org/lkml/2018/3/20/341
> 
> and it is not just an issue on matching on endpoints, it's that the
> drm bridge itself that would need to handle multiple attach/detaches..

Correct. Thanks to 12/15 we don't need this yet :-)

> > +	thc63->timings.dual_link = endpoint != NULL;
> > +	dev_dbg(thc63->dev, "operating in %s-link mode\n",
> > +		thc63->timings.dual_link ? "dual" : "single");
> > +
> >  	return 0;
> >  }
> >
> > @@ -188,6 +211,7 @@ static int thc63_probe(struct platform_device *pdev)
> >  	thc63->bridge.driver_private = thc63;
> >  	thc63->bridge.of_node = pdev->dev.of_node;
> >  	thc63->bridge.funcs = &thc63_bridge_func;
> > +	thc63->bridge.timings = &thc63->timings;
> >
> >  	drm_bridge_add(&thc63->bridge);
> >

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2019-03-08 18:00 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 23:23 [PATCH/RFC 00/15] R-Car DU: LVDS dual-link mode support Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 01/15] drm: Clarify definition of the DRM_BUS_FLAG_(PIXDATA|SYNC)_* macros Laurent Pinchart
2019-04-24  8:15   ` Kieran Bingham
2019-03-06 23:23 ` [PATCH/RFC 02/15] drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags Laurent Pinchart
2019-04-24  8:15   ` Kieran Bingham
2019-05-11 20:44     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 03/15] drm/bridge: use bus flags in bridge timings Laurent Pinchart
2019-04-24  8:13   ` Kieran Bingham
2019-03-06 23:23 ` [PATCH/RFC 04/15] drm: bridge: Add dual_link field to the drm_bridge_timings structure Laurent Pinchart
2019-04-24  8:12   ` Kieran Bingham
2019-05-11 20:36     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 05/15] dt-bindings: display: bridge: thc63lvd1024: Document dual-link operation Laurent Pinchart
2019-03-08 16:49   ` Jacopo Mondi
2019-03-08 17:57     ` Laurent Pinchart
2019-03-09 11:23       ` Jacopo Mondi
2019-03-09 11:51         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 06/15] drm: bridge: thc63: Report input bus mode through bridge timings Laurent Pinchart
2019-03-08 17:32   ` Jacopo Mondi
2019-03-08 18:00     ` Laurent Pinchart [this message]
2019-03-09 11:24       ` Jacopo Mondi
2019-03-09 11:45         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 07/15] dt-bindings: display: renesas: lvds: Add renesas,companion property Laurent Pinchart
2019-03-18 10:21   ` Geert Uytterhoeven
2019-03-18 14:22     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 08/15] drm: rcar-du: lvds: Remove LVDS double-enable checks Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 09/15] drm: rcar-du: lvds: Adjust operating frequency for D3 and E3 Laurent Pinchart
2019-03-08 16:28   ` Jacopo Mondi
2019-03-06 23:23 ` [PATCH/RFC 10/15] drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3 Laurent Pinchart
2019-03-08 16:25   ` Jacopo Mondi
2019-03-08 18:07     ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 11/15] drm: rcar-du: lvds: Add support for dual-link mode Laurent Pinchart
2019-03-08 17:20   ` Jacopo Mondi
2019-03-08 18:12     ` Laurent Pinchart
2019-03-09 11:11       ` Jacopo Mondi
2019-03-09 11:25         ` Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 12/15] drm: rcar-du: Skip LVDS1 output on Gen3 when using dual-link LVDS mode Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 13/15] arm64: dts: renesas: r8a7799[05]: Point LVDS0 to its companion LVDS1 Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 14/15] [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation Laurent Pinchart
2019-03-06 23:23 ` [PATCH/RFC 15/15] [HACK] arm64: dts: renesas: ebisu: " 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=20190308180028.GB11318@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jacopo+renesas@jmondi.org \
    --cc=jacopo@jmondi.org \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-renesas-soc@vger.kernel.org \
    /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