devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jagan Teki <jagan@amarulasolutions.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	devicetree@vger.kernel.org, linux-amarula@amarulasolutions.com
Subject: Re: [PATCH v2] drm: of: Lookup if child node has panel or bridge
Date: Wed, 12 Jan 2022 15:14:35 +0530	[thread overview]
Message-ID: <CAMty3ZC1qOS42jvUTyGtOWBDT0ewghnivK3Rej8NGN2dqVNcug@mail.gmail.com> (raw)
In-Reply-To: <Ybc8dym7NWvBmYYf@pendragon.ideasonboard.com>

Hi Laurent,

On Mon, Dec 13, 2021 at 5:59 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Jagan,
>
> Thank you for the patch.
>
> On Mon, Dec 13, 2021 at 05:46:13PM +0530, Jagan Teki wrote:
> > Some OF graphs don't require 'ports' to represent the
> > downstream panel or bridge; instead it simply adds a child
> > node on a given parent node.
> >
> > drm_of_find_panel_or_bridge can lookup panel or bridge for
> > a given node based on the OF graph port and endpoint and it
> > fails to use if the given node has a child panel or bridge.
> >
> > This patch add support to lookup that given node has child
> > panel or bridge however that child node cannot be a 'port'
> > alone or it cannot be a 'port' node too.
> >
> > Example OF graph representation of DSI host, which doesn't
> > have 'ports' and has child panel.
> >
> > dsi {
> >       compatible = "allwinner,sun6i-a31-mipi-dsi";
> >       #address-cells = <1>;
> >       #size-cells = <0>;
> >
> >       port {
> >               dsi_in_tcon0: endpoint {
> >                       remote-endpoint = <tcon0_out_dsi>;
> >       };
> >
> >       panel@0 {
> >               reg = <0>;
> >       };
> > };
> >
> > Example OF graph representation of DSI host, which doesn't
> > have 'ports' and has child bridge.
> >
> > dsi {
> >       compatible = "allwinner,sun6i-a31-mipi-dsi";
> >       #address-cells = <1>;
> >       #size-cells = <0>;
> >
> >       port {
> >               dsi_in_tcon0: endpoint {
> >                       remote-endpoint = <tcon0_out_dsi>;
> >       };
> >
> >       bridge@0 {
> >               reg = <0>;
> >
> >               ports {
> >                       #address-cells = <1>;
> >                       #size-cells = <0>;
> >
> >                       bridge_out: port@1 {
> >                               reg = <1>;
> >
> >                               bridge_out_panel: endpoint {
> >                                       remote-endpoint = <&panel_out_bridge>;
> >                               };
> >                       };
> >               };
> >       };
> > };
> >
> > Example OF graph representation of DSI host, which doesn't
> > have 'ports' or 'port' and has child panel.
> >
> > dsi0 {
> >       compatible = "ste,mcde-dsi";
> >       #address-cells = <1>;
> >       #size-cells = <0>;
> >
> >       panel@0 {
> >               reg = <0>;
> >       };
> > };
> >
> > Example OF graph representation of LTDC host, which doesn't
> > have 'ports' or child panel/bridge and has 'port'.
> >
> > ltdc {
> >       compatible = "st,stm32-ltdc";
> >       #address-cells = <1>;
> >       #size-cells = <0>;
> >
> >       port {
> >       };
> > };
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > Changes for v2:
> > - drop of helper
> > https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-jagan@amarulasolutions.com/
> > - support 'port' alone OF graph
> > - updated comments
> > - added simple code
> >
> >  drivers/gpu/drm/drm_of.c | 23 +++++++++++++++++++++++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index 59d368ea006b..7d018ff8bc83 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -249,6 +249,27 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
> >       if (panel)
> >               *panel = NULL;
> >
> > +     /**
> > +      * Some OF graphs don't require 'ports' to represent the downstream
> > +      * panel or bridge; instead it simply adds a child node on a given
> > +      * parent node.
> > +      *
> > +      * Lookup that child node for a given parent however that child
> > +      * cannot be a 'port' alone or it cannot be a 'port' node too.
> > +      */
> > +     if (!of_get_child_by_name(np, "ports")) {
> > +             if (of_get_child_by_name(np, "port") && (of_get_child_count(np) == 1))
>
> This messes up reference counting of device_node.
>
> > +                     goto of_graph_get_remote;
> > +
> > +             for_each_available_child_of_node(np, remote) {
> > +                     if (of_node_name_eq(remote, "port"))
> > +                             continue;
> > +
> > +                     goto of_find_panel_or_bridge;
> > +             }
> > +     }
>
> This really looks like a hack to me, I'm worried it may cause issues. It
> would be better, I think, to split the drm_of_find_panel_or_bridge()
> function in two, with the of_graph_get_remote_node() call moved to a
> wrapper function, calling an inner function that takes the remote
> device_node pointer. For the DSI use case, you could either look up the
> panel DT node in the display driver and call the inner function
> directly, or implement a DSI-specific wrapper.

I sent the V3 for this, and considered whole video pipeline use cases.
Please have a look and comment.

Thanks,
Jagan.

      parent reply	other threads:[~2022-01-12  9:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 12:16 [PATCH v2] drm: of: Lookup if child node has panel or bridge Jagan Teki
2021-12-13 12:28 ` Laurent Pinchart
2021-12-13 13:09   ` Maxime Ripard
2021-12-13 13:35     ` Laurent Pinchart
2021-12-13 13:42       ` Maxime Ripard
2022-01-12 10:13         ` Laurent Pinchart
2022-01-12  9:44   ` Jagan Teki [this message]

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=CAMty3ZC1qOS42jvUTyGtOWBDT0ewghnivK3Rej8NGN2dqVNcug@mail.gmail.com \
    --to=jagan@amarulasolutions.com \
    --cc=andrzej.hajda@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-amarula@amarulasolutions.com \
    --cc=m.szyprowski@samsung.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tzimmermann@suse.de \
    /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).