All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
To: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
Cc: Sakari Ailus
	<sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	niklas.soderlund-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org,
	robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph endpoints in a single port
Date: Sat, 2 Sep 2017 01:57:48 +0300	[thread overview]
Message-ID: <20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <95945222-3562-a330-609f-ad1a64034dd3-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>

Hi Hans,

Thanks for the review.

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) 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.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus-X3B1VOXEql0@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>,
	linux-media@vger.kernel.org, niklas.soderlund@ragnatech.se,
	robh@kernel.org, laurent.pinchart@ideasonboard.com,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v6 5/5] v4l: fwnode: Support generic parsing of graph endpoints in a single port
Date: Sat, 2 Sep 2017 01:57:48 +0300	[thread overview]
Message-ID: <20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk> (raw)
In-Reply-To: <95945222-3562-a330-609f-ad1a64034dd3@xs4all.nl>

Hi Hans,

Thanks for the review.

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) 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.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi

  parent reply	other threads:[~2017-09-01 22:57 UTC|newest]

Thread overview: 27+ 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 ` 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-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-09-01 10:46       ` Hans Verkuil
     [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 " Sakari Ailus
2017-08-30 11:49     ` 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-08-30 11:49     ` 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 [this message]
2017-09-01 22:57           ` Sakari Ailus
2017-09-02  9:52           ` Laurent Pinchart
2017-09-03  7:43             ` Sakari Ailus
2017-09-04 10:05               ` Laurent Pinchart
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
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-01 21:23             ` Sakari Ailus
2017-09-02  9:42           ` Laurent Pinchart
2017-09-02  9:42             ` 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=20170901225748.ygk35gzmt6vrtetw@valkosipuli.retiisi.org.uk \
    --to=sakari.ailus-x3b1voxeql0@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=niklas.soderlund-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org \
    --cc=robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    /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.