devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 04 Sep 2017 13:05:52 +0300	[thread overview]
Message-ID: <41798047.7Eux7kmorh@avalon> (raw)
In-Reply-To: <20170903074339.vswbczv2lfxykssq@valkosipuli.retiisi.org.uk>

Hi Sakari,

On Sunday, 3 September 2017 10:43:39 EEST Sakari Ailus wrote:
> On Sat, Sep 02, 2017 at 12:52:47PM +0300, Laurent Pinchart wrote:
> > 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:

[sinp]

> >>> 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 ?
> 
> Sounds good to me.
> 
> >> 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.
> 
> Could you elaborate?
> 
> If a driver would be interested in skipping endpoints in a subset of ports,
> in which case only a single port would be excluded from this?

I meant that I see use cases for parsing specific ports only (for instance in 
the R-Car case parsing only the sink ports in a CSI-2 receiver DT node), but 
not really for parsing specific endpoints only.

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2017-09-04 10:05 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
     [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-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
2017-09-03  7:43             ` Sakari Ailus
2017-09-04 10:05               ` Laurent Pinchart [this message]
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

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=41798047.7Eux7kmorh@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).