From: Rob Herring <robh@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
"Kuninori Morimoto" <kuninori.morimoto.gx@renesas.com>,
alsa-devel@alsa-project.org, devicetree@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-media@vger.kernel.org,
linux-sound@vger.kernel.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Daniel Vetter" <daniel@ffwll.ch>,
"David Airlie" <airlied@gmail.com>,
"Frank Rowand" <frowand.list@gmail.com>,
"Helge Deller" <deller@gmx.de>,
"Jaroslav Kysela" <perex@perex.cz>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Mark Brown" <broonie@kernel.org>,
"Mauro Carvalho Chehab" <mchehab@kernel.org>,
"Maxime Ripard" <mripard@kernel.org>,
"Michal Simek" <michal.simek@amd.com>,
"Saravana Kannan" <saravanak@google.com>,
"Takashi Iwai" <tiwai@suse.com>,
"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: Re: [PATCH v2 03/13] of: property: add of_graph_get_next_endpoint_raw()
Date: Wed, 31 Jan 2024 12:43:47 -0600 [thread overview]
Message-ID: <20240131184347.GA1906672-robh@kernel.org> (raw)
In-Reply-To: <20240129130219.GA20460@pendragon.ideasonboard.com>
On Mon, Jan 29, 2024 at 03:02:19PM +0200, Laurent Pinchart wrote:
> On Mon, Jan 29, 2024 at 02:29:22PM +0200, Tomi Valkeinen wrote:
> > On 29/01/2024 02:54, Kuninori Morimoto wrote:
> > > We already have of_graph_get_next_endpoint(), but it is not intuitive
> > > to use.
> > >
> > > (X) node {
> > > (Y) ports {
> > > port@0 { endpoint { remote-endpoint = ...; };};
> > > (A1) port@1 { endpoint { remote-endpoint = ...; };
> > > (A2) endpoint { remote-endpoint = ...; };};
> > > (B) port@2 { endpoint { remote-endpoint = ...; };};
> > > };
> > > };
> > >
> > > For example, if I want to handle port@1's 2 endpoints (= A1, A2),
> > > I want to use like below
> > >
> > > A1 = of_graph_get_next_endpoint(port1, NULL);
> > > A2 = of_graph_get_next_endpoint(port1, A1);
> > >
> > > But 1st one will be error, because of_graph_get_next_endpoint() requested
> > > "parent" means "node" (X) or "ports" (Y), not "port".
> > > Below are OK
> > >
> > > of_graph_get_next_endpoint(node, NULL); // node/ports/port@0/endpoint
> > > of_graph_get_next_endpoint(ports, NULL); // node/ports/port@0/endpoint
> > >
> > > In other words, we can't handle A1/A2 directly via
> > > of_graph_get_next_endpoint() so far.
> > >
> > > There is another non intuitive behavior on of_graph_get_next_endpoint().
> > > In case of if I could get A1 pointer for some way, and if I want to
> > > handle port@1 things, I would like use it like below
> > >
> > > /*
> > > * "endpoint" is now A1, and handle port1 things here,
> > > * but we don't know how many endpoints port1 has.
> > > *
> > > * Because "endpoint" is non NULL, we can use port1
> > > * as of_graph_get_next_endpoint(port1, xxx)
> > > */
> > > do {
> > > /* do something for port1 specific things here */
> > > } while (endpoint = of_graph_get_next_endpoint(port1, endpoint))
> > >
> > > But it also not worked as I expected.
> > > I expect it will be A1 -> A2 -> NULL,
> > > but it will be A1 -> A2 -> B, because of_graph_get_next_endpoint()
> > > will fetch endpoint beyond the port.
> > >
> > > It is not useful on generic driver like Generic Sound Card.
> > > It uses of_get_next_child() instead for now, but it is not intuitive,
> > > and not check node name (= "endpoint").
> > >
> > > To handle endpoint more intuitive, create of_graph_get_next_endpoint_raw()
> > >
> > > of_graph_get_next_endpoint_raw(port1, NULL); // A1
> > > of_graph_get_next_endpoint_raw(port1, A1); // A2
> > > of_graph_get_next_endpoint_raw(port1, A2); // NULL
> > >
> > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > > ---
> > > drivers/of/property.c | 26 +++++++++++++++++++++++++-
> > > include/linux/of_graph.h | 2 ++
> > > 2 files changed, 27 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > index 14ffd199c9b1..37dbb1b0e742 100644
> > > --- a/drivers/of/property.c
> > > +++ b/drivers/of/property.c
> > > @@ -667,6 +667,30 @@ struct device_node *of_graph_get_next_port(const struct device_node *parent,
> > > }
> > > EXPORT_SYMBOL(of_graph_get_next_port);
> > >
> > > +/**
> > > + * of_graph_get_next_endpoint_raw() - get next endpoint node
> >
> > How about "of_graph_get_next_port_endpoint()"?
>
> We may want to also rename the existing of_graph_get_next_endpoint()
> function to of_graph_next_dev_endpoint() then. It would be a tree-wide
> patch, which is always annoying to get reviewed and merged, so if Rob
> would prefer avoiding the rename, I'm fine with that.
I think we should get rid of or minimize of_graph_get_next_endpoint() in
its current form. In general, drivers should be asking for a specific
port number because their function is fixed in the binding. Iterating
over endpoints within a port is okay as that's usually a selecting 1 of
N operation.
Most cases are in the form of of_graph_get_next_endpoint(dev, NULL)
which is equivalent to of_graph_get_endpoint_by_regs(dev, 0, 0).
Technically, -1 instead of 0 is equivalent, but I'd argue is sloppy and
wrong.
I also added of_graph_get_remote_node() for this reason and cleaned a
lot of these (in DRM) up some time ago. Because in the end, a driver
generally just wants the remote device it is connected to and details of
parsing the graph should be mostly opaque.
Wouldn't something like this work for this case:
#define for_each_port_endpoint_of_node(parent, port, child) \
for (child = of_graph_get_endpoint_by_regs(parent, port, -1); child != NULL; \
child = of_get_next_child(parent, child))
Rob
next prev parent reply other threads:[~2024-01-31 18:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 0:54 [PATCH v2 00/13] of: property: add port base loop Kuninori Morimoto
2024-01-29 0:54 ` [PATCH v2 01/13] " Kuninori Morimoto
2024-01-29 12:16 ` Tomi Valkeinen
2024-01-31 18:52 ` Rob Herring
2024-01-31 23:25 ` Kuninori Morimoto
2024-01-31 18:59 ` Rob Herring
2024-01-29 0:54 ` [PATCH v2 02/13] of: property: use of_graph_get_next_port() on of_graph_get_next_endpoint() Kuninori Morimoto
2024-01-29 12:18 ` Tomi Valkeinen
2024-01-29 0:54 ` [PATCH v2 03/13] of: property: add of_graph_get_next_endpoint_raw() Kuninori Morimoto
2024-01-29 12:29 ` Tomi Valkeinen
2024-01-29 13:02 ` Laurent Pinchart
2024-01-30 0:08 ` Kuninori Morimoto
2024-01-31 18:43 ` Rob Herring [this message]
2024-02-01 0:43 ` Kuninori Morimoto
2024-02-01 1:48 ` Kuninori Morimoto
2024-01-29 13:37 ` Sakari Ailus
2024-01-30 0:37 ` Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 04/13] drm: omapdrm: use of_graph_get_next_endpoint_raw() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 05/13] media: xilinx-tpg: " Kuninori Morimoto
2024-01-30 13:35 ` kernel test robot
2024-01-29 0:55 ` [PATCH v2 06/13] ASoC: audio-graph-card: " Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 07/13] ASoC: audio-graph-card2: use of_graph_get_next_port() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 08/13] ASoC: audio-graph-card2: use of_graph_get_next_endpoint_raw() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 09/13] ASoC: test-component: use for_each_port_of_node() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 10/13] fbdev: omapfb: use of_graph_get_remote_port() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 11/13] fbdev: omapfb: use of_graph_get_next_port() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 12/13] fbdev: omapfb: use of_graph_get_next_endpoint_raw() Kuninori Morimoto
2024-01-29 0:55 ` [PATCH v2 13/13] fbdev: omapfb: use of_graph_get_next_endpoint() Kuninori Morimoto
2024-01-29 12:27 ` [PATCH v2 00/13] of: property: add port base loop Laurent Pinchart
2024-01-29 13:29 ` Sakari Ailus
2024-01-30 0:34 ` Kuninori Morimoto
2024-01-30 7:31 ` Sakari Ailus
2024-01-30 7:37 ` Tomi Valkeinen
2024-01-30 7:40 ` Sakari Ailus
2024-01-30 23:24 ` Kuninori Morimoto
2024-02-01 9:18 ` Sakari Ailus
2024-02-05 5:31 ` Kuninori Morimoto
2024-02-05 9:26 ` 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=20240131184347.GA1906672-robh@kernel.org \
--to=robh@kernel.org \
--cc=airlied@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=lgirdwood@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mchehab@kernel.org \
--cc=michal.simek@amd.com \
--cc=mripard@kernel.org \
--cc=perex@perex.cz \
--cc=saravanak@google.com \
--cc=tiwai@suse.com \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tzimmermann@suse.de \
--cc=u.kleine-koenig@pengutronix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.