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
next prev parent 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