From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
linux-media@vger.kernel.org,
Philipp Zabel <p.zabel@pengutronix.de>,
hverkuil@xs4all.nl, Francesco Dolcini <francesco@dolcini.it>,
aishwarya.kothari@toradex.com, Robert Foss <rfoss@kernel.org>,
Todor Tomov <todor.too@gmail.com>,
Hyun Kwon <hyun.kwon@xilinx.com>
Subject: Re: [PATCH 02/18] media: v4l: async: Add some debug prints
Date: Thu, 27 Apr 2023 20:27:52 +0300 [thread overview]
Message-ID: <20230427172752.GD26786@pendragon.ideasonboard.com> (raw)
In-Reply-To: <ZEo980G94VUofYSp@kekkonen.localdomain>
On Thu, Apr 27, 2023 at 12:18:43PM +0300, Sakari Ailus wrote:
> On Fri, Apr 21, 2023 at 11:18:42AM +0300, Laurent Pinchart wrote:
> > On Fri, Apr 14, 2023 at 01:46:54PM +0300, Sakari Ailus wrote:
> > > On Thu, Apr 13, 2023 at 06:49:52PM +0200, Jacopo Mondi wrote:
> > > > On Thu, Mar 30, 2023 at 02:58:37PM +0300, Sakari Ailus wrote:
> > > > > Just add some debug prints for V4L2 async sub-device matching process.
> > > > > These might come useful in figuring out why things don't work as expected.
> > > > >
> > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > ---
> > > > > drivers/media/v4l2-core/v4l2-async.c | 59 ++++++++++++++++++++++++----
> > > > > 1 file changed, 52 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c
> > > > > index 008a2a3e312e..6dd426c2ca68 100644
> > > > > --- a/drivers/media/v4l2-core/v4l2-async.c
> > > > > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > > > > @@ -75,6 +75,12 @@ static bool match_i2c(struct v4l2_async_notifier *notifier,
> > > > > #endif
> > > > > }
> > > > >
> > > > > +static struct device *notifier_dev(struct v4l2_async_notifier *notifier)
> > > > > +{
> > > > > + return notifier->sd ? notifier->sd->dev : notifier->v4l2_dev ?
> > > > > + notifier->v4l2_dev->dev : NULL;
> >
> > Nested ?: operators can be confusing, I'd write
> >
> > if (notifier->sd)
> > return notifier->sd->dev
> > if (notifier->v4l2_dev)
> > return notifier->v4l2_dev->dev;
> > return NULL;
>
> I don't mind. I can use that, I'll add some newlines, too.
>
> > > > > +}
> > > > > +
> > > > > static bool
> > > > > match_fwnode_one(struct v4l2_async_notifier *notifier,
> > > > > struct v4l2_subdev *sd, struct fwnode_handle *sd_fwnode,
> > > > > @@ -86,13 +92,18 @@ match_fwnode_one(struct v4l2_async_notifier *notifier,
> > > > > bool sd_fwnode_is_ep;
> > > > > struct device *dev;
> > > > >
> > > > > + dev_dbg(sd->dev, "async: fwnode match: need %pfw, trying %pfw\n",
> >
> > "async:" is a bit too generic as a prefix. Maybe "v4l2_async:" or
> > "async_nf:" instead ?
>
> "v4l2-async"?
Works for me.
> > > > > + sd_fwnode, asd->match.fwnode);
> > > > > +
> > > > > /*
> > > > > * 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)
> > > > > + if (sd_fwnode == asd->match.fwnode) {
> > > > > + dev_dbg(sd->dev, "async: direct match found\n");
> > > > > return true;
> > > > > + }
> > > > >
> > > > > /*
> > > > > * Otherwise, check if the sd fwnode and the asd fwnode refer to an
> > > > > @@ -105,8 +116,10 @@ match_fwnode_one(struct v4l2_async_notifier *notifier,
> > > > > sd_fwnode_is_ep = fwnode_graph_is_endpoint(sd_fwnode);
> > > > > asd_fwnode_is_ep = fwnode_graph_is_endpoint(asd->match.fwnode);
> > > > >
> > > > > - if (sd_fwnode_is_ep == asd_fwnode_is_ep)
> > > > > + if (sd_fwnode_is_ep == asd_fwnode_is_ep) {
> > > > > + dev_dbg(sd->dev, "async: matching node types\n");
> > > >
> > > > "matching node type" is misleading as it suggests a match has been
> > > > found. As both sd and asd are of the same type, I would use a
> > > > message similar to the above
> > > >
> > > > dev_dbg(sd->dev, "async: direct match failed\n");
> > >
> > > As it seems further matching attempts will always produce more debug
> > > prints, I'll just drop this altogether.
> >
> > I'm not sure what you mean here. Isn't it useful to have an explicit
> > message on failure ? I like Jacopo's proposal.
>
> I'm fine with that.
>
> > > > > return false;
> > > > > + }
> > > > >
> > > > > /*
> > > > > * The sd and asd fwnodes are of different types. Get the device fwnode
> > > > > @@ -120,10 +133,15 @@ match_fwnode_one(struct v4l2_async_notifier *notifier,
> > > > > other_fwnode = sd_fwnode;
> > > > > }
> > > > >
> > > > > + dev_dbg(sd->dev, "async: fwnode compat match, need %pfw, trying %pfw\n",
> > > > > + dev_fwnode, other_fwnode);
> > > > > +
> > > > > fwnode_handle_put(dev_fwnode);
> > > > >
> > > > > - if (dev_fwnode != other_fwnode)
> > > > > + if (dev_fwnode != other_fwnode) {
> > > > > + dev_dbg(sd->dev, "async: compat match not found\n");
> > > >
> > > > and to be more consistent: "compat match failed"
> > >
> > > I think it's in all cases either "found" or "not found" in this patch.
> > >
> > > > > return false;
> > > > > + }
> > > > >
> > > > > /*
> > > > > * We have a heterogeneous match. Retrieve the struct device of the side
> > > > > @@ -143,12 +161,17 @@ match_fwnode_one(struct v4l2_async_notifier *notifier,
> > > > > dev->driver->name);
> > > > > }
> > > > >
> > > > > + dev_dbg(sd->dev, "async: compat match found\n");
> > > > > +
> > > > > return true;
> > > > > }
> > > > >
> > > > > static bool match_fwnode(struct v4l2_async_notifier *notifier,
> > > > > struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
> > > > > {
> > > > > + dev_dbg(sd->dev, "async: matching for notifier %pfw, sd %pfw\n",
> >
> > Maybe mentioning "fwnode" here ?
>
> Yes. I'll remove "for", too.
>
> > > > > + dev_fwnode(notifier_dev(notifier)), sd->fwnode);
> >
> > Is there a reason to print the notifier dev as a fwnode instead of using
> > dev_name() ?
>
> Yes. These strings are comparable to sub-device node names, so this should
> help figuring out what is the async sub-device being matched to. This is
> the case on both DT and ACPI.
>
> But see below.
>
> > I'm also wondering, wouldn't it be better to use notifier_dev(notifier)
> > as the dev argument to dev_dbg(), and print dev_name(sd->dev) in the
> > format string ? That's what you're doing below.
>
> Once there is a match, yes. But if that fails to happen, fwnodes are the
> most relevant...
My main point was about using notifier_dev(notifier) as the dev argument
to dev_dbg(), and printing sd in the message. The notifier seems to be
the core object to me here, I think that's what we should use as context
for dev_dbg().
> > Also, sd->fwnode is printed in match_fwnode_one(), so you could possibly
> > drop it from here.
>
> but yes, that's a good point. I'll drop printing fwnodes here.
>
> > > > > +
> > > > > if (match_fwnode_one(notifier, sd, sd->fwnode, asd))
> > > > > return true;
> > > > >
> > > > > @@ -156,6 +179,8 @@ static bool match_fwnode(struct v4l2_async_notifier *notifier,
> > > > > if (IS_ERR_OR_NULL(sd->fwnode->secondary))
> > > > > return false;
> > > > >
> > > > > + dev_dbg(sd->dev, "async: trying secondary fwnode match\n");
> > > > > +
> > > > > return match_fwnode_one(notifier, sd, sd->fwnode->secondary, asd);
> > > > > }
> > > > >
> > > > > @@ -247,16 +272,21 @@ v4l2_async_nf_can_complete(struct v4l2_async_notifier *notifier)
> > > > > {
> > > > > struct v4l2_subdev *sd;
> > > > >
> > > > > - if (!list_empty(¬ifier->waiting))
> > > > > + if (!list_empty(¬ifier->waiting)) {
> > > > > + dev_dbg(notifier_dev(notifier), "async: waiting for subdevs\n");
> > > > > return false;
> > > > > + }
> > > > >
> > > > > list_for_each_entry(sd, ¬ifier->done, async_list) {
> > > > > struct v4l2_async_notifier *subdev_notifier =
> > > > > v4l2_async_find_subdev_notifier(sd);
> > > > >
> > > > > if (subdev_notifier &&
> > > > > - !v4l2_async_nf_can_complete(subdev_notifier))
> > > > > + !v4l2_async_nf_can_complete(subdev_notifier)) {
> > > > > + dev_dbg(notifier_dev(notifier),
> > > > > + "async: cannot complete\n");
> > > >
> > > > These two will be printed out a lot of times, don't they ?
> > >
> > > That may be, if you have many async sub-devices. Perhaps these could be
> > > dropped --- the user will be able to find what is still pending via sysfs.
> >
> > I'm fine with that. If you want to keep the message, can you print the
> > subdev_notifier dev in the message here ?
>
> I'll drop it for now.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2023-04-27 17:27 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 11:58 [PATCH 00/18] Separate links and async sub-devices Sakari Ailus
2023-03-30 11:58 ` [PATCH 01/18] media: v4l: async: Return async sub-devices to subnotifier list Sakari Ailus
2023-04-13 16:49 ` Jacopo Mondi
2023-04-25 1:28 ` Laurent Pinchart
2023-04-25 8:32 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 02/18] media: v4l: async: Add some debug prints Sakari Ailus
2023-04-13 16:49 ` Jacopo Mondi
2023-04-14 10:46 ` Sakari Ailus
2023-04-21 8:18 ` Laurent Pinchart
2023-04-27 9:18 ` Sakari Ailus
2023-04-27 17:27 ` Laurent Pinchart [this message]
2023-04-28 7:29 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 03/18] media: v4l: async: Simplify async sub-device fwnode matching Sakari Ailus
2023-04-13 16:50 ` Jacopo Mondi
2023-04-14 11:07 ` Sakari Ailus
2023-04-24 19:20 ` Niklas Söderlund
2023-04-24 19:33 ` Sakari Ailus
2023-04-25 1:37 ` Laurent Pinchart
2023-04-27 9:23 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 04/18] media: v4l: async: Make V4L2 async match information a struct Sakari Ailus
2023-04-13 16:51 ` Jacopo Mondi
2023-04-27 10:47 ` Sakari Ailus
2023-04-25 1:10 ` Laurent Pinchart
2023-04-27 10:36 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 05/18] media: v4l: async: Clean testing for duplicated async subdevs Sakari Ailus
2023-04-13 16:58 ` Jacopo Mondi
2023-04-14 11:16 ` Sakari Ailus
2023-04-25 1:15 ` Laurent Pinchart
2023-04-27 11:06 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 06/18] media: v4l: async: Only pass match information for async subdev validation Sakari Ailus
2023-04-14 7:15 ` Jacopo Mondi
2023-04-14 11:39 ` Sakari Ailus
2023-04-25 1:24 ` Laurent Pinchart
2023-04-27 11:45 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 07/18] media: v4l: async: Clean up list heads and entries Sakari Ailus
2023-04-14 7:26 ` Jacopo Mondi
2023-04-14 11:54 ` Sakari Ailus
2023-04-25 0:49 ` Laurent Pinchart
2023-04-27 11:52 ` Sakari Ailus
2023-04-27 17:36 ` Laurent Pinchart
2023-04-28 7:37 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 08/18] media: v4l: async: Rename v4l2_async_subdev as v4l2_async_connection Sakari Ailus
2023-04-14 8:22 ` Jacopo Mondi
2023-04-14 12:17 ` Sakari Ailus
2023-04-25 0:59 ` Laurent Pinchart
2023-04-28 9:33 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 09/18] media: v4l: async: Differentiate connecting and creating sub-devices Sakari Ailus
2023-04-14 8:52 ` Jacopo Mondi
2023-04-14 13:35 ` Sakari Ailus
2023-04-25 2:14 ` Laurent Pinchart
2023-04-28 9:46 ` Sakari Ailus
2023-04-28 10:29 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 10/18] media: pxa_camera: Register V4L2 device early, fix probe error handling Sakari Ailus
2023-04-25 0:25 ` Laurent Pinchart
2023-04-28 11:21 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 11/18] media: marvell: cafe: Register V4L2 device earlier Sakari Ailus
2023-04-25 0:27 ` Laurent Pinchart
2023-04-28 11:22 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 12/18] media: am437x-vpfe: Register V4L2 device early Sakari Ailus
2023-03-30 11:58 ` [PATCH 13/18] media: omap3isp: Initialise V4L2 async notifier later Sakari Ailus
2023-03-30 11:58 ` [PATCH 14/18] media: xilinx-vipp: Init async notifier after registering V4L2 device Sakari Ailus
2023-04-25 0:31 ` Laurent Pinchart
2023-03-30 11:58 ` [PATCH 15/18] media: davinci: " Sakari Ailus
2023-03-30 11:58 ` [PATCH 16/18] media: qcom: Initialise V4L2 async notifier later Sakari Ailus
2023-03-30 11:58 ` [PATCH 17/18] media: v4l: async: Set v4l2_device in async notifier init Sakari Ailus
2023-04-25 0:35 ` Laurent Pinchart
2023-04-25 2:00 ` Laurent Pinchart
2023-04-28 10:35 ` Sakari Ailus
2023-04-28 10:33 ` Sakari Ailus
2023-03-30 11:58 ` [PATCH 18/18] Documentation: media: Document sub-device notifiers Sakari Ailus
2023-04-14 9:14 ` [PATCH 19/18] media: v4l: Drop v4l2_async_nf_parse_fwnode_endpoints() Jacopo Mondi
2023-04-25 1:06 ` Laurent Pinchart
2023-04-28 11:30 ` 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=20230427172752.GD26786@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=aishwarya.kothari@toradex.com \
--cc=francesco@dolcini.it \
--cc=hverkuil@xs4all.nl \
--cc=hyun.kwon@xilinx.com \
--cc=jacopo.mondi@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=rfoss@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=todor.too@gmail.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