Linux Media Controller 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>,
	linux-media@vger.kernel.org,
	"Sakari Ailus" <sakari.ailus@linux.intel.com>,
	"Jacopo Mondi" <jacopo+renesas@jmondi.org>,
	"Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
	"Kieran Bingham" <kieran.bingham+renesas@ideasonboard.com>,
	"Lad Prabhakar" <prabhakar.csengg@gmail.com>
Subject: Re: [PATCH] media: v4l2-async: Accept endpoints and devices for fwnode matching
Date: Mon, 16 Mar 2020 08:34:44 +0200	[thread overview]
Message-ID: <20200316063444.GE4732@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20200315214707.uo246kwe3njtc452@uno.localdomain>

Hi Jacopo,

On Sun, Mar 15, 2020 at 10:47:07PM +0100, Jacopo Mondi wrote:
> On Sun, Mar 15, 2020 at 02:55:11PM +0200, Laurent Pinchart wrote:
> > fwnode matching was designed to match on nodes corresponding to a
> > device. Some drivers, however, needed to match on endpoints, and have
> > passed endpoint fwnodes to v4l2-async. This works when both the subdev
> > and the notifier use the same fwnode types (endpoint or device), but
> > makes drivers that use different types incompatible.
> >
> > Fix this by extending the fwnode match to handle fwnodes of different
> > types. When the types (deduced from the node name) are different,
> > retrieve the device fwnode for the side that provides an endpoint
> > fwnode, and compare it with the device fwnode provided by the other
> > side. This allows interoperability between all drivers, regardless of
> > which type of fwnode they use for matching.
> 
> I'm sorry but I'm not sure why would make a difference compared to
> what Kieran's patch did.
> https://lore.kernel.org/patchwork/patch/788637/
> 
> If the bridge matches on device node, and the remote registers more
> than one endpoints it is possible to get a false match.

How so ? If a notifier entry points to a device node, and two subdevs
are registered with different endpoint nodes that are both part of the
same device node, the notifier will get either of them. Which subdev
match the notifier won't be guaranteed, but that's what the notifier
asked for if it contains a device node and not an endpoint node: any
subdev corresponding to the device node.

In practice notifiers will need to move to endpoint matching if they
want to get a particular subdev of a device, and this change allows
doing so without mass-patching every driver. It allows a notifier to
switch to endpoint nodes, while subdevs still use device nodes and are
gradually ported.

> I'm not sure how that would happen in practice, as the bridge would be
> registering the fwnode of the remote device twice, but I think that
> was the reason kieran's patch has not been collected or am I
> mistaken ?
> 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > This has been compile-tested only. Prabhakar, could you check if it
> > fixes your issue ?
> >
> >  drivers/media/v4l2-core/v4l2-async.c | 42 +++++++++++++++++++++++++++-
> >  1 file changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> > index 8bde33c21ce4..995e5464cba7 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -71,7 +71,47 @@ static bool match_devname(struct v4l2_subdev *sd,
> >
> >  static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> >  {
> > -	return sd->fwnode == asd->match.fwnode;
> > +	struct fwnode_handle *other_fwnode;
> > +	struct fwnode_handle *dev_fwnode;
> > +	bool asd_fwnode_is_ep;
> > +	bool sd_fwnode_is_ep;
> > +	const char *name;
> > +
> > +	/*
> > +	 * Both the subdev and the async subdev can provide either an endpoint
> > +	 * fwnode or a device fwnode. Start with the simple case of direct
> > +	 * fwnode matching.
> > +	 */
> > +	if (sd->fwnode == asd->match.fwnode)
> > +		return true;
> > +
> > +	/*
> > +	 * Otherwise, check if the sd fwnode and the asd fwnode refer to an
> > +	 * endpoint or a device. If they're of the same type, there's no match.
> > +	 */
> > +	name = fwnode_get_name(sd->fwnode);
> > +	sd_fwnode_is_ep = name && strstarts(name, "endpoint");
> > +	name = fwnode_get_name(asd->match.fwnode);
> > +	asd_fwnode_is_ep = name && strstarts(name, "endpoint");
> > +
> > +	if (sd_fwnode_is_ep == asd_fwnode_is_ep)
> > +		return false;
> > +
> > +	/*
> > +	 * The sd and asd fwnodes are of different types. Get the device fwnode
> > +	 * parent of the endpoint fwnode, and compare it with the other fwnode.
> > +	 */
> > +	if (sd_fwnode_is_ep) {
> > +		dev_fwnode = fwnode_graph_get_port_parent(sd->fwnode);
> > +		other_fwnode = asd->match.fwnode;
> > +	} else {
> > +		dev_fwnode = fwnode_graph_get_port_parent(asd->match.fwnode);
> > +		other_fwnode = sd->fwnode;
> > +	}
> > +
> > +	fwnode_handle_put(dev_fwnode);
> > +
> > +	return dev_fwnode == other_fwnode;
> >  }
> >
> >  static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2020-03-16  6:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-15 10:27 [PATCH 0/2] rcar-csi2: make use V4L2_ASYNC_MATCH_CUSTOM to do fwnode matching Lad Prabhakar
2020-03-15 10:27 ` [PATCH 1/2] media: v4l2-async: Pass pointer to struct v4l2_subdev in match_custom callback Lad Prabhakar
2020-03-15 10:56   ` Laurent Pinchart
2020-03-15 10:27 ` [PATCH 2/2] media: rcar-csi2: Let the driver handle fwnode matching using " Lad Prabhakar
2020-03-15 10:29   ` Laurent Pinchart
2020-03-15 12:10     ` Lad, Prabhakar
2020-03-15 12:57       ` Laurent Pinchart
2020-03-15 12:55 ` [PATCH] media: v4l2-async: Accept endpoints and devices for fwnode matching Laurent Pinchart
2020-03-15 13:32   ` Lad, Prabhakar
2020-03-15 21:47   ` Jacopo Mondi
2020-03-16  6:34     ` Laurent Pinchart [this message]
2020-03-16  8:59       ` Jacopo Mondi
2020-03-16  9:56         ` Laurent Pinchart
2020-03-16 21:40   ` Niklas Söderlund
2020-03-16 21:47     ` Laurent Pinchart
2020-03-17 12:33       ` Kieran Bingham
2020-03-17 23:08         ` Laurent Pinchart
2020-03-17 12:44   ` Sakari Ailus
2020-03-17 23:04     ` Laurent Pinchart
2020-03-18  0:17       ` Laurent Pinchart
2020-03-18  7:52         ` Sakari Ailus
2020-03-18 11:22           ` Laurent Pinchart
2020-03-18 13:35             ` Sakari Ailus

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=20200316063444.GE4732@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=jacopo+renesas@jmondi.org \
    --cc=jacopo@jmondi.org \
    --cc=kieran.bingham+renesas@ideasonboard.com \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=niklas.soderlund@ragnatech.se \
    --cc=prabhakar.csengg@gmail.com \
    --cc=sakari.ailus@linux.intel.com \
    /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