From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
linux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,
robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph endpoints in a single port
Date: Sat, 02 Sep 2017 12:52:47 +0300 [thread overview]
Message-ID: <1981884.TcuAFemERJ@avalon> (raw)
In-Reply-To: <20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk>
Hi Sakari,
On Saturday, 2 September 2017 01:57:48 EEST Sakari Ailus wrote:
> On Fri, Sep 01, 2017 at 01:28:40PM +0200, Hans Verkuil wrote:
> >> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
> >> index d063ab4ff67b..dd13604178b4 100644
> >> --- a/include/media/v4l2-fwnode.h
> >> +++ b/include/media/v4l2-fwnode.h
> >> @@ -249,4 +249,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(
> >> struct v4l2_fwnode_endpoint *vep,
> >> struct v4l2_async_subdev *asd));
> >>
> >> +/**
> >> + * v4l2_async_notifier_parse_fwnode_endpoint - Set up async notifier
> >> for an
> >> + * fwnode based sub-device
> >> + * @dev: @struct device pointer
> >> + * @notifier: pointer to &struct v4l2_async_notifier
> >> + * @port_id: port number
> >> + * @endpoint_id: endpoint number
> >> + * @asd_struct_size: size of the driver's async sub-device struct,
> >> including
> >> + * sizeof(struct v4l2_async_subdev). The &struct
> >> + * v4l2_async_subdev shall be the first member of
> >> + * the driver's async sub-device struct, i.e. both
> >> + * begin at the same memory address.
> >> + * @parse_single: driver's callback function called on each V4L2 fwnode
> >> endpoint
> >> + *
> >> + * Parse the fwnode endpoint of the @dev device corresponding to the
> >> given port
> >> + * and endpoint numbres and populate the async sub- devices array of
> >> the
> >
> > numbers
> > no space after sub-
> >
> > > + * notifier. The @parse_endpoint callback function is called for the
> > > endpoint
> >
> > parse_single, but (as in the previous patch) I actually prefer
> > parse_endpoint.
> >
> >> + * with the corresponding async sub-device pointer to let the caller
> >> initialize
> >> + * the driver-specific part of the async sub-device structure.
> >> + *
> >> + * The notifier memory shall be zeroed before this function is called
> >> on the
> >> + * notifier.
> >
> > Should it? Doesn't this add additional subdevs?
> >
> > I'm lost. What's the relationship between
> > v4l2_async_notifier_parse_fwnode_endpoints and this function? When do you
> > use which? When you should zero the notifier?
> I thought there would be advantages in this approach as it lets you to
> choose which endpoints specifically you want to parse. That said, the
> expectation is that the device has no endpoints that aren't supported in
> hardware either.
>
> Some drivers currently iterate over all the endpoints and then validate
> them whereas others poke for some endpoints only (port 0, endpoint 0, for
> the rcar-vin driver, for instance). In DT binding documentation the
> endpoint numbers are currently not specified nor drivers have checked them.
> Common sense tells to use zero if there's no reason to do otherwise, but
> still this hasn't been documented nor validated in the past. So if we add
> that now, there could be a chance of breaking something.
>
> Additionally, specifying the endpoints to parse explicitly has been seen
> beneficial (or even necessary) in parsing endpoints for devices that have
> both input and output interfaces. Perhaps Niklas can comment on that.
>
> What I though was to introduce a specific error code (EPERM, better
> suggestions are taken)
Maybe ENOTCONN ?
> for the driver callback function (parse_endpoint) to silently skip endpoints
> the driver doesn't like for reason or another. This lets drivers to use the
> endpoint parser function added by the previous patch and still maintain the
> old behaviour, i.e. ignore endpoints that aren't explicitly recognised by
> the driver.
>
> I'll drop this patch from the next version.
Parsing a specific endpoint of a specific port is probably indeed a bit too
fine-grained, but I think there are use cases for parsing at the port level
instead of parsing all ports.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-09-02 9:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-30 11:49 [PATCH v6 0/5] Unified fwnode endpoint parser Sakari Ailus
2017-08-30 11:49 ` [PATCH v6 1/5] v4l: fwnode: Move KernelDoc documentation to the header Sakari Ailus
[not found] ` <20170830114946.17743-2-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-09-01 10:45 ` Hans Verkuil
2017-08-30 11:49 ` [PATCH v6 2/5] v4l: async: Add V4L2 async documentation to the documentation build Sakari Ailus
[not found] ` <20170830114946.17743-3-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-09-01 10:46 ` Hans Verkuil
2017-08-30 11:49 ` [PATCH v6 4/5] v4l: fwnode: Support generic parsing of graph endpoints in a device Sakari Ailus
2017-08-30 12:45 ` [PATCH v6.1 " Sakari Ailus
[not found] ` <20170830124530.26176-1-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-09-01 11:18 ` Hans Verkuil
[not found] ` <b707062c-d8df-5fb5-8099-8460f0dd7d5d-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2017-09-01 21:23 ` Sakari Ailus
2017-09-02 9:42 ` Laurent Pinchart
[not found] ` <20170830114946.17743-1-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-08-30 11:49 ` [PATCH v6 3/5] docs-rst: v4l: Include Qualcomm CAMSS in documentation build Sakari Ailus
2017-09-01 10:46 ` Hans Verkuil
2017-08-30 11:49 ` [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph endpoints in a single port Sakari Ailus
2017-09-01 11:28 ` Hans Verkuil
[not found] ` <95945222-3562-a330-609f-ad1a64034dd3-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
2017-09-01 22:57 ` Sakari Ailus
2017-09-02 9:52 ` Laurent Pinchart [this message]
2017-09-03 7:43 ` Sakari Ailus
2017-09-04 10:05 ` 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=1981884.TcuAFemERJ@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=devicetree@vger.kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=niklas.soderlund@ragnatech.se \
--cc=robh@kernel.org \
--cc=sakari.ailus@iki.fi \
--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;
as well as URLs for NNTP newsgroup(s).