From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Maxime Ripard <mripard@kernel.org>,
Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@gmail.com>
Subject: Re: [PATCH 3/5] drm/bridge: simple-bridge: Allow acquiring the next bridge with fwnode API
Date: Tue, 23 Jan 2024 17:18:35 +0200 [thread overview]
Message-ID: <20240123151835.GO10679@pendragon.ideasonboard.com> (raw)
In-Reply-To: <7f5e1c37-a637-494a-ab52-cad83095f2a6@linux.dev>
Hello Sui,
On Tue, Jan 23, 2024 at 08:18:22PM +0800, Sui Jingfeng wrote:
> On 2024/1/23 09:18, Laurent Pinchart wrote:
> > On Tue, Jan 23, 2024 at 12:32:18AM +0800, Sui Jingfeng wrote:
> >> Which make it possible to use this driver on non-DT based systems,
> >> meanwhile, made no functional changes for DT based systems.
> >>
> >> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
> >> ---
> >> drivers/gpu/drm/bridge/simple-bridge.c | 51 ++++++++++++++++++++++----
> >> 1 file changed, 44 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> >> index 595f672745b9..cfea5a67cc5b 100644
> >> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> >> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> >> @@ -184,6 +184,39 @@ static const void *simple_bridge_get_match_data(const struct device *dev)
> >> return NULL;
> >> }
> >>
> >> +static int simple_bridge_get_next_bridge_by_fwnode(struct device *dev,
> >> + struct drm_bridge **next_bridge)
> >> +{
> >> + struct drm_bridge *bridge;
> >> + struct fwnode_handle *ep;
> >> + struct fwnode_handle *remote;
> >> +
> >> + ep = fwnode_graph_get_endpoint_by_id(dev->fwnode, 1, 0, 0);
> >> + if (!ep) {
> >> + dev_err(dev, "The endpoint is unconnected\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + remote = fwnode_graph_get_remote_port_parent(ep);
> >> + fwnode_handle_put(ep);
> >> + if (!remote) {
> >> + dev_err(dev, "No valid remote node\n");
> >> + return -ENODEV;
> >> + }
> >> +
> >> + bridge = drm_bridge_find_by_fwnode(remote);
> >> + fwnode_handle_put(remote);
> >> +
> >> + if (!bridge) {
> >> + dev_warn(dev, "Next bridge not found, deferring probe\n");
> >> + return -EPROBE_DEFER;
> >> + }
> >> +
> >> + *next_bridge = bridge;
> >> +
> >> + return 0;
> >> +}
> >> +
> >
> > Hmmmm yes, this convinces me further that we should switch to fwnode,
> > not implement fwnode and OF side-by-side.
>
> OK, I'm agree with you.
>
> But this means that I have to make the drm_bridge_find_by_fwnode() function works
> on both DT systems and non-DT systems. This is also means that we will no longer
> need to call of_drm_find_bridge() function anymore. This will eventually lead to
> completely remove of_drm_find_bridge()?
It would be replaced by fwnode_drm_find_bridge(). Although, if we need
to rename the function, I think it would be best to make have a drm_
prefix, maybe drm_bridge_find-by_fwnode() or something similar.
> As far as I can see, if I follow you suggestion, drm/bridge subsystem will
> encountering a *big* refactor. My 'side-by-side' approach allows co-exist.
> It is not really meant to purge OF. I feel it is a little bit of aggressive.
>
> hello Maxime, are you watching this? what do you think?
>
> >> static int simple_bridge_probe(struct platform_device *pdev)
> >> {
> >> struct simple_bridge *sbridge;
> >> @@ -199,14 +232,17 @@ static int simple_bridge_probe(struct platform_device *pdev)
> >> else
> >> sbridge->info = simple_bridge_get_match_data(&pdev->dev);
> >>
> >> - /* Get the next bridge in the pipeline. */
> >> - remote = of_graph_get_remote_node(pdev->dev.of_node, 1, -1);
> >> - if (!remote)
> >> - return -EINVAL;
> >> -
> >> - sbridge->next_bridge = of_drm_find_bridge(remote);
> >> - of_node_put(remote);
> >> + if (pdev->dev.of_node) {
> >> + /* Get the next bridge in the pipeline. */
> >> + remote = of_graph_get_remote_node(pdev->dev.of_node, 1, -1);
> >> + if (!remote)
> >> + return -EINVAL;
> >>
> >> + sbridge->next_bridge = of_drm_find_bridge(remote);
> >> + of_node_put(remote);
> >> + } else {
> >> + simple_bridge_get_next_bridge_by_fwnode(&pdev->dev, &sbridge->next_bridge);
> >> + }
> >> if (!sbridge->next_bridge) {
> >> dev_dbg(&pdev->dev, "Next bridge not found, deferring probe\n");
> >> return -EPROBE_DEFER;
> >> @@ -231,6 +267,7 @@ static int simple_bridge_probe(struct platform_device *pdev)
> >> /* Register the bridge. */
> >> sbridge->bridge.funcs = &simple_bridge_bridge_funcs;
> >> sbridge->bridge.of_node = pdev->dev.of_node;
> >> + sbridge->bridge.fwnode = pdev->dev.fwnode;
> >> sbridge->bridge.timings = sbridge->info->timings;
> >>
> >> drm_bridge_add(&sbridge->bridge);
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sui Jingfeng <sui.jingfeng@linux.dev>
Cc: David Airlie <airlied@gmail.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Daniel Vetter <daniel@ffwll.ch>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] drm/bridge: simple-bridge: Allow acquiring the next bridge with fwnode API
Date: Tue, 23 Jan 2024 17:18:35 +0200 [thread overview]
Message-ID: <20240123151835.GO10679@pendragon.ideasonboard.com> (raw)
In-Reply-To: <7f5e1c37-a637-494a-ab52-cad83095f2a6@linux.dev>
Hello Sui,
On Tue, Jan 23, 2024 at 08:18:22PM +0800, Sui Jingfeng wrote:
> On 2024/1/23 09:18, Laurent Pinchart wrote:
> > On Tue, Jan 23, 2024 at 12:32:18AM +0800, Sui Jingfeng wrote:
> >> Which make it possible to use this driver on non-DT based systems,
> >> meanwhile, made no functional changes for DT based systems.
> >>
> >> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev>
> >> ---
> >> drivers/gpu/drm/bridge/simple-bridge.c | 51 ++++++++++++++++++++++----
> >> 1 file changed, 44 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
> >> index 595f672745b9..cfea5a67cc5b 100644
> >> --- a/drivers/gpu/drm/bridge/simple-bridge.c
> >> +++ b/drivers/gpu/drm/bridge/simple-bridge.c
> >> @@ -184,6 +184,39 @@ static const void *simple_bridge_get_match_data(const struct device *dev)
> >> return NULL;
> >> }
> >>
> >> +static int simple_bridge_get_next_bridge_by_fwnode(struct device *dev,
> >> + struct drm_bridge **next_bridge)
> >> +{
> >> + struct drm_bridge *bridge;
> >> + struct fwnode_handle *ep;
> >> + struct fwnode_handle *remote;
> >> +
> >> + ep = fwnode_graph_get_endpoint_by_id(dev->fwnode, 1, 0, 0);
> >> + if (!ep) {
> >> + dev_err(dev, "The endpoint is unconnected\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + remote = fwnode_graph_get_remote_port_parent(ep);
> >> + fwnode_handle_put(ep);
> >> + if (!remote) {
> >> + dev_err(dev, "No valid remote node\n");
> >> + return -ENODEV;
> >> + }
> >> +
> >> + bridge = drm_bridge_find_by_fwnode(remote);
> >> + fwnode_handle_put(remote);
> >> +
> >> + if (!bridge) {
> >> + dev_warn(dev, "Next bridge not found, deferring probe\n");
> >> + return -EPROBE_DEFER;
> >> + }
> >> +
> >> + *next_bridge = bridge;
> >> +
> >> + return 0;
> >> +}
> >> +
> >
> > Hmmmm yes, this convinces me further that we should switch to fwnode,
> > not implement fwnode and OF side-by-side.
>
> OK, I'm agree with you.
>
> But this means that I have to make the drm_bridge_find_by_fwnode() function works
> on both DT systems and non-DT systems. This is also means that we will no longer
> need to call of_drm_find_bridge() function anymore. This will eventually lead to
> completely remove of_drm_find_bridge()?
It would be replaced by fwnode_drm_find_bridge(). Although, if we need
to rename the function, I think it would be best to make have a drm_
prefix, maybe drm_bridge_find-by_fwnode() or something similar.
> As far as I can see, if I follow you suggestion, drm/bridge subsystem will
> encountering a *big* refactor. My 'side-by-side' approach allows co-exist.
> It is not really meant to purge OF. I feel it is a little bit of aggressive.
>
> hello Maxime, are you watching this? what do you think?
>
> >> static int simple_bridge_probe(struct platform_device *pdev)
> >> {
> >> struct simple_bridge *sbridge;
> >> @@ -199,14 +232,17 @@ static int simple_bridge_probe(struct platform_device *pdev)
> >> else
> >> sbridge->info = simple_bridge_get_match_data(&pdev->dev);
> >>
> >> - /* Get the next bridge in the pipeline. */
> >> - remote = of_graph_get_remote_node(pdev->dev.of_node, 1, -1);
> >> - if (!remote)
> >> - return -EINVAL;
> >> -
> >> - sbridge->next_bridge = of_drm_find_bridge(remote);
> >> - of_node_put(remote);
> >> + if (pdev->dev.of_node) {
> >> + /* Get the next bridge in the pipeline. */
> >> + remote = of_graph_get_remote_node(pdev->dev.of_node, 1, -1);
> >> + if (!remote)
> >> + return -EINVAL;
> >>
> >> + sbridge->next_bridge = of_drm_find_bridge(remote);
> >> + of_node_put(remote);
> >> + } else {
> >> + simple_bridge_get_next_bridge_by_fwnode(&pdev->dev, &sbridge->next_bridge);
> >> + }
> >> if (!sbridge->next_bridge) {
> >> dev_dbg(&pdev->dev, "Next bridge not found, deferring probe\n");
> >> return -EPROBE_DEFER;
> >> @@ -231,6 +267,7 @@ static int simple_bridge_probe(struct platform_device *pdev)
> >> /* Register the bridge. */
> >> sbridge->bridge.funcs = &simple_bridge_bridge_funcs;
> >> sbridge->bridge.of_node = pdev->dev.of_node;
> >> + sbridge->bridge.fwnode = pdev->dev.fwnode;
> >> sbridge->bridge.timings = sbridge->info->timings;
> >>
> >> drm_bridge_add(&sbridge->bridge);
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-01-23 15:18 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 16:32 [PATCH 0/5] drm/bridge: Allow using fwnode API to get the next bridge Sui Jingfeng
2024-01-22 16:32 ` Sui Jingfeng
2024-01-22 16:32 ` [PATCH 1/5] drm/bridge: Add drm_bridge_find_by_fwnode() helper Sui Jingfeng
2024-01-22 16:32 ` Sui Jingfeng
2024-01-23 1:17 ` Laurent Pinchart
2024-01-23 1:17 ` Laurent Pinchart
2024-01-23 8:01 ` Sui Jingfeng
2024-01-23 8:01 ` Sui Jingfeng
2024-01-23 15:15 ` Laurent Pinchart
2024-01-23 15:15 ` Laurent Pinchart
2024-01-22 16:32 ` [PATCH 2/5] drm/bridge: simple-bridge: Extend match support for non-DT based systems Sui Jingfeng
2024-01-22 16:32 ` Sui Jingfeng
2024-01-23 1:21 ` Laurent Pinchart
2024-01-23 1:21 ` Laurent Pinchart
2024-01-23 8:20 ` Sui Jingfeng
2024-01-23 8:20 ` Sui Jingfeng
2024-01-23 15:16 ` Laurent Pinchart
2024-01-23 15:16 ` Laurent Pinchart
2024-01-23 12:31 ` Sui Jingfeng
2024-01-23 12:31 ` Sui Jingfeng
2024-03-20 20:34 ` Andy Shevchenko
2024-01-22 16:32 ` [PATCH 3/5] drm/bridge: simple-bridge: Allow acquiring the next bridge with fwnode API Sui Jingfeng
2024-01-22 16:32 ` Sui Jingfeng
2024-01-23 1:18 ` Laurent Pinchart
2024-01-23 1:18 ` Laurent Pinchart
2024-01-23 12:18 ` Sui Jingfeng
2024-01-23 12:18 ` Sui Jingfeng
2024-01-23 15:18 ` Laurent Pinchart [this message]
2024-01-23 15:18 ` Laurent Pinchart
2024-01-24 15:00 ` Maxime Ripard
2024-01-24 15:00 ` Maxime Ripard
2024-01-22 16:32 ` [PATCH 4/5] drm/bridge: display-connector: Extend match support for non-DT based systems Sui Jingfeng
2024-01-22 16:32 ` Sui Jingfeng
2024-01-22 16:32 ` [PATCH 5/5] drm-bridge: display-connector: Switch to use fwnode API Sui Jingfeng
2024-01-22 16:32 ` Sui Jingfeng
2024-01-23 1:20 ` Laurent Pinchart
2024-01-23 1:20 ` Laurent Pinchart
2024-01-23 12:35 ` Sui Jingfeng
2024-01-23 12:35 ` Sui Jingfeng
2024-03-20 20:32 ` Andy Shevchenko
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=20240123151835.GO10679@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=sui.jingfeng@linux.dev \
--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 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.