linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Marco Felsch <m.felsch@pengutronix.de>
Cc: devicetree@vger.kernel.org, linux-media@vger.kernel.org,
	robh+dt@kernel.org, hans.verkuil@cisco.com,
	jacopo+renesas@jmondi.org, kernel@pengutronix.de,
	Sakari Ailus <sakari.ailus@iki.fi>,
	mchehab@kernel.org, laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v10 03/14] media: v4l2-fwnode: add initial connector parsing support
Date: Tue, 7 Jan 2020 15:49:23 +0200	[thread overview]
Message-ID: <20200107134923.GP19828@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20191210095003.7t42ar2hnipjjrbk@pengutronix.de>

Hi Marco,

On Tue, Dec 10, 2019 at 10:50:03AM +0100, Marco Felsch wrote:
> Hi Sakari,
> 
> On 19-11-27 14:24, Sakari Ailus wrote:
> > Hi Marco,
> > 
> > On Wed, Nov 27, 2019 at 09:26:16AM +0100, Marco Felsch wrote:
> > > Hi Sakari,
> > > 
> > > this is a gentle ping and I've added a comment inline.
> > > 
> > > On 19-11-19 12:15, Marco Felsch wrote:
> > > > Hi Sakari,
> > > > 
> > > > many thanks for the review :)
> > > > 
> > > > On 19-11-16 01:06, Sakari Ailus wrote:
> > > > > Hi Marco,
> > > > > 
> > > > > On Fri, Nov 08, 2019 at 09:58:52AM +0100, Marco Felsch wrote:
> > > > > > Hi Sakari,
> > > > > > 
> > > > > > sorry for my delay now ^^
> > > > > > 
> > > > > > On 19-10-24 15:02, Sakari Ailus wrote:
> > > > > > > Hi Marco,
> > > > > > > 
> > > > > > > On Wed, Oct 23, 2019 at 02:21:57PM +0200, Marco Felsch wrote:
> > > > > > > > Hi Sakari,
> > > > > > > > 
> > > > > > > > On 19-10-23 13:57, Sakari Ailus wrote:
> > > > > > > > > Hi Marco,
> > > > > > > > > 
> > > > > > > > > Apologies for the delay.
> > > > > > > > 
> > > > > > > > No problem.
> > > > > > > > 
> > > > > > > > > On Wed, Oct 02, 2019 at 10:07:35AM +0200, Marco Felsch wrote:
> > > > > > > > > > Hi Sakari,
> > > > > > > > > > 
> > > > > > > > > > On 19-10-02 10:03, Sakari Ailus wrote:
> > > > > > > > > > > Hi Marco,
> > > > > > > > > > > 
> > > > > > > > > > > On Fri, Aug 30, 2019 at 12:16:35PM +0200, Marco Felsch wrote:
> > > > > > > > > > > > The patch adds the initial connector parsing code, so we can move from a
> > > > > > > > > > > > driver specific parsing code to a generic one. Currently only the
> > > > > > > > > > > > generic fields and the analog-connector specific fields are parsed. Parsing
> > > > > > > > > > > > the other connector specific fields can be added by a simple callbacks.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > > [1] https://patchwork.kernel.org/cover/10794703/
> > > > > > > > > > > > 
> > > > > > > > > > > > v10:
> > > > > > > > > > > > - drop V4L2_CONN_HDMI support
> > > > > > > > > > > > - adapt pr_err msg to reflect new state (-> connector is unkown)
> > > > > > > > > > > > 
> > > > > > > > > > > > v9:
> > > > > > > > > > > > - Fix leading semicolon found by kbuild semicolon.cocci
> > > > > > > > > > > > 
> > > > > > > > > > > > v8:
> > > > > > > > > > > > - V4L2_CON_* -> V4L2_CONN_*
> > > > > > > > > > > > - tvnorms -> sdtv-standards
> > > > > > > > > > > > - adapt to new v4l2_fwnode_connector_analog member
> > > > > > > > > > > > - return error in case of V4L2_CONN_HDMI
> > > > > > > > > > > > 
> > > > > > > > > > > > v7:
> > > > > > > > > > > > @Jacopo: I dropped your r b tag becuase of the amount of changes I
> > > > > > > > > > > > made..
> > > > > > > > > > > > 
> > > > > > > > > > > > - drop unnecessary comments
> > > > > > > > > > > > - fix commet style
> > > > > > > > > > > > - s/v4l2_fwnode_connector_conv.name/v4l2_fwnode_connector_conv.compatible/
> > > > > > > > > > > > - make label size variable and drop V4L2_CONNECTOR_MAX_LABEL usage
> > > > > > > > > > > > - do not assign a default label in case of no label was specified
> > > > > > > > > > > > - remove useless /* fall through */ comments
> > > > > > > > > > > > - add support for N connector links
> > > > > > > > > > > > - rename local variables to be more meaningful
> > > > > > > > > > > > - adjust kernedoc
> > > > > > > > > > > > - add v4l2_fwnode_connector_free()
> > > > > > > > > > > > - improve error handling (use different error values)
> > > > > > > > > > > > - make use of pr_warn_once()
> > > > > > > > > > > > 
> > > > > > > > > > > > v6:
> > > > > > > > > > > > - use unsigned count var
> > > > > > > > > > > > - fix comment and style issues
> > > > > > > > > > > > - place '/* fall through */' to correct places
> > > > > > > > > > > > - fix error handling and cleanup by releasing fwnode
> > > > > > > > > > > > - drop vga and dvi parsing support as those connectors are rarely used
> > > > > > > > > > > >   these days
> > > > > > > > > > > > 
> > > > > > > > > > > > v5:
> > > > > > > > > > > > - s/strlcpy/strscpy/
> > > > > > > > > > > > 
> > > > > > > > > > > > v2-v4:
> > > > > > > > > > > > - nothing since the patch was squashed from series [1] into this
> > > > > > > > > > > >   series.
> > > > > > > > > > > > 
> > > > > > > > > > > >  drivers/media/v4l2-core/v4l2-fwnode.c | 129 ++++++++++++++++++++++++++
> > > > > > > > > > > >  include/media/v4l2-fwnode.h           |  38 ++++++++
> > > > > > > > > > > >  2 files changed, 167 insertions(+)
> > > > > > > > > > > > 
> > > > > > > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c b/drivers/media/v4l2-core/v4l2-fwnode.c
> > > > > > > > > > > > index 3bd1888787eb..0bfa7cbf78df 100644
> > > > > > > > > > > > --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> > > > > > > > > > > > +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> > > > > > > > > > > > @@ -595,6 +595,135 @@ void v4l2_fwnode_put_link(struct v4l2_fwnode_link *link)
> > > > > > > > > > > >  }
> > > > > > > > > > > >  EXPORT_SYMBOL_GPL(v4l2_fwnode_put_link);
> > > > > > > > > > > >  
> > > > > > > > > > > > +static const struct v4l2_fwnode_connector_conv {
> > > > > > > > > > > > +	enum v4l2_connector_type type;
> > > > > > > > > > > > +	const char *compatible;
> > > > > > > > > > > > +} connectors[] = {
> > > > > > > > > > > > +	{
> > > > > > > > > > > > +		.type = V4L2_CONN_COMPOSITE,
> > > > > > > > > > > > +		.compatible = "composite-video-connector",
> > > > > > > > > > > > +	}, {
> > > > > > > > > > > > +		.type = V4L2_CONN_SVIDEO,
> > > > > > > > > > > > +		.compatible = "svideo-connector",
> > > > > > > > > > > > +	},
> > > > > > > > > > > > +};
> > > > > > > > > > > > +
> > > > > > > > > > > > +static enum v4l2_connector_type
> > > > > > > > > > > > +v4l2_fwnode_string_to_connector_type(const char *con_str)
> > > > > > > > > > > > +{
> > > > > > > > > > > > +	unsigned int i;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	for (i = 0; i < ARRAY_SIZE(connectors); i++)
> > > > > > > > > > > > +		if (!strcmp(con_str, connectors[i].compatible))
> > > > > > > > > > > > +			return connectors[i].type;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	return V4L2_CONN_UNKNOWN;
> > > > > > > > > > > > +}
> > > > > > > > > > > > +
> > > > > > > > > > > > +static int
> > > > > > > > > > > > +v4l2_fwnode_connector_parse_analog(struct fwnode_handle *fwnode,
> > > > > > > > > > > > +				   struct v4l2_fwnode_connector *vc)
> > > > > > > > > > > > +{
> > > > > > > > > > > > +	u32 stds;
> > > > > > > > > > > > +	int ret;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	ret = fwnode_property_read_u32(fwnode, "sdtv-standards", &stds);
> > > > > > > > > > > > +
> > > > > > > > > > > > +	/* The property is optional. */
> > > > > > > > > > > > +	vc->connector.analog.sdtv_stds = ret ? V4L2_STD_ALL : stds;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	return 0;
> > > > > > > > > > > > +}
> > > > > > > > > > > > +
> > > > > > > > > > > > +void v4l2_fwnode_connector_free(struct v4l2_fwnode_connector *connector)
> > > > > > > > > > > > +{
> > > > > > > > > > > > +	unsigned int i;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	if (IS_ERR_OR_NULL(connector))
> > > > > > > > > > > > +		return;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	for (i = 0; i < connector->nr_of_links; i++)
> > > > > > > > > > > > +		v4l2_fwnode_put_link(&connector->links[i]);
> > > > > > > > > > > > +	kfree(connector->links);
> > > > > > > > > > > 
> > > > > > > > > > > Please assign connector->links NULL here, and nr_of_links to zero.
> > > > > > > > > > 
> > > > > > > > > > Okay, I can do that.
> > > > > > > > > > 
> > > > > > > > > > > > +}
> > > > > > > > > > > > +EXPORT_SYMBOL_GPL(v4l2_fwnode_connector_free);
> > > > > > > > > > > > +
> > > > > > > > > > > > +int v4l2_fwnode_connector_alloc_parse(struct fwnode_handle *fwnode,
> > > > > > > > > > > > +				      struct v4l2_fwnode_connector *connector)
> > > > > > > > > > > > +{
> > > > > > > > > > > > +	struct fwnode_handle *remote_pp, *remote_ep;
> > > > > > > > > > > > +	const char *type_name;
> > > > > > > > > > > > +	unsigned int i = 0, ep_num = 0;
> > > > > > > > > > > > +	int err;
> > > > > > > > > > > > +
> > > > > > > > > > > > +	memset(connector, 0, sizeof(*connector));
> > > > > > > > > > > > +
> > > > > > > > > > > > +	remote_pp = fwnode_graph_get_remote_port_parent(fwnode);
> > > > > > > > > > > 
> > > > > > > > > > > How do you know a remote endpoint is a connector, and not another device's
> > > > > > > > > > > endpoint?
> > > > > > > > > > 
> > > > > > > > > > Well, I think that the caller won't use this function if it isn't a
> > > > > > > > > > connector. If it helps I can check if the compatible of the remote ends
> > > > > > > > > > with "-connector".
> > > > > > > > > 
> > > > > > > > > The function is called by a driver. A driver shouldn't know what's at the
> > > > > > > > > other end of the graph arc; the information should come from the firmware
> > > > > > > > > instead.
> > > > > > > > > 
> > > > > > > > > On some board there could be another device where you have a connector now.
> > > > > > > > > 
> > > > > > > > > As the connector has its own compatible string, there could be a connector
> > > > > > > > > driver to tell this is actually a connector, even if there's nothing to
> > > > > > > > > control. It'd be a very tiny driver.
> > > > > > > > 
> > > > > > > > Yes I know a connector driver would be the best. This also have the
> > > > > > > > advantage to do drop the connector handling in each subdev driver.. But
> > > > > > > > unfortunately I haven't the time yet. Would it be okay for you too check
> > > > > > > > that the remote is a connector and if not to exit?
> > > > > > > 
> > > > > > > The current design is also problematic in the sense that it parses remote DT
> > > > > > > graph endpoints (as well as device nodes) that are not under the device's
> > > > > > > own scope.
> > > > > > 
> > > > > > You are right that is not good. Would it be okay with you to parse only
> > > > > > the local node so the caller must pass the connector node?
> > > > > > 
> > > > > > > I wonder what kind of changes would that require, and how much more
> > > > > > > difficult would the changes be to implement later on if a number of drivers
> > > > > > > uses the newly added APIs.
> > > > > > > 
> > > > > > > v4l2_fwnode_parse_endpoint() should be considered as well. This is the
> > > > > > > current API to parse endpoints. Could connectors be meaningfully parsed
> > > > > > > within v4l2_fwnode_parse_endpoint()?
> > > > > > 
> > > > > > I think v4l2_fwnode_endpoint_parse() isn't the correct place. Of course
> > > > > > it is a endpoint but I don't think that a connector should be placed
> > > > > > there. Currently the endpoint is mostly used to describe the connection
> > > > > > between the isp and a sensor. I think we shouldn't add something
> > > > > > unrelated just because it's an fw-endpoint. The connector just describes
> > > > > > who users can interact with the device. A connector isn't connected to a
> > > > > > chip using mipi or something else.
> > > > > 
> > > > > If the endpoints pointing to a connector are not parsed by
> > > > > v4l2_fwnode_endpoint_parse(), then it means that they're parsed somewhere
> > > > > else, and that's something the caller needs to know. The fact that there is
> > > > > a connector, is only apparent from the compatible string of the remote
> > > > > device. That's simply not something for the caller to figure out.
> > > > 
> > > > That is a goot point, I got that.
> > > > 
> > > > > Endpoints in general refer to other devices' connection points. It doesn't
> > > > > matter what kind of a device it is, they should be treated the same way.
> > > > > 
> > > > > I'm still not proposing to mangle connectors with the bus properties. Still,
> > > > > the two are mostly exclusive: if there's a connector, then any properties of
> > > > > the signal likely have nothing to do what was described in the firmware.
> > > > > 
> > > > > How about adding an fwnode API function called e.g.g
> > > > > v4l2_fwnode_is_connector(), to tell whether a given local endpoint is
> > > > > connected to a remote which is a connector? That, I think, would be
> > > > > sufficient to make the connectors vs. wired busses easy for drivers to work
> > > > > with.
> > > > 
> > > > A v4l2_fwnode_is_connector() function is nice. Just to got you right,
> > > > you want something like:
> > > > 
> > > > 	v4l2_fwnode_endpoint_alloc_parse()
> > > > 	{
> > > > 		int rval;
> > > > 
> > > > 		if (v4l2_fwnode_is_connector())
> > > > 			return v4l2_fwnode_connector_alloc_parse();
> > > > 
> > > > 		rval = __v4l2_fwnode_endpoint_parse(fwnode, vep);
> > > > 		if (rval < 0)
> > > > 			return rval;
> > > > 
> > > > 		...
> > > > 	}
> > > > 
> > > > If I got that right we need to squash the 'struct v4l2_fwnode_connector'
> > > > into the 'struct v4l2_fwnode_endpoint' or we need to accept both structs.
> > > > The first attempt can be error prone if a caller access invalid data.
> > > > What do you think?
> > > 
> > > After my short excursion to the drm subsystem I noticed such a function:
> > > drm_of_find_panel_or_bridge(). Basically the function fills a bridge or
> > > panel struct and the driver need to check if there was a panel or a
> > > bridge. It seems that we can use exactly the same logic for our
> > > use-case.
> > 
> > We could. Then the bus_type field would likely need to be used for the
> > connector types as well. The field would seem to deserve a rename as a
> > result though.
> 
> I don't think that we should squash both struct. Should we go the
> current way with just an additional v4l2_fwnode_is_connector() helper?
> So the driver knows which parse helper should be called?

Thanks for the ping.

I'm in favour of having such a helper, that's enough for drivers not having
to care too much about it. Connectors generally are somewhat different from
the rest of the busses (where the framework parses their properties) rather
than just the types of connectors being used.

-- 
Regards,

Sakari Ailus

  parent reply	other threads:[~2020-01-07 13:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30 10:16 [PATCH v10 00/14] TVP5150 features and fixes Marco Felsch
2019-08-30 10:16 ` [PATCH v10 01/14] dt-bindings: connector: analog: add sdtv standards property Marco Felsch
2019-09-27  9:09   ` Hans Verkuil
2019-09-27 10:01     ` Marco Felsch
2019-08-30 10:16 ` [PATCH v10 02/14] media: v4l2-fwnode: add v4l2_fwnode_connector Marco Felsch
2019-08-30 10:16 ` [PATCH v10 03/14] media: v4l2-fwnode: add initial connector parsing support Marco Felsch
2019-10-02  7:03   ` Sakari Ailus
2019-10-02  8:07     ` Marco Felsch
2019-10-22 10:17       ` Marco Felsch
2019-10-23 10:57       ` Sakari Ailus
2019-10-23 12:21         ` Marco Felsch
2019-10-24 12:02           ` Sakari Ailus
2019-11-08  8:58             ` Marco Felsch
2019-11-15 23:06               ` Sakari Ailus
2019-11-19 11:15                 ` Marco Felsch
2019-11-27  8:26                   ` Marco Felsch
2019-11-27 12:24                     ` Sakari Ailus
2019-12-10  9:50                       ` Marco Felsch
2020-01-07 11:56                         ` Marco Felsch
2020-01-07 13:49                         ` Sakari Ailus [this message]
2020-01-07 14:00                           ` Marco Felsch
2020-01-07 14:03                             ` Sakari Ailus
2019-11-27 12:21                   ` Sakari Ailus
2019-08-30 10:16 ` [PATCH v10 04/14] partial revert of "[media] tvp5150: add HW input connectors support" Marco Felsch
2019-08-30 10:16 ` [PATCH v10 05/14] media: tvp5150: add input source selection of_graph support Marco Felsch
2019-09-27  8:54   ` Hans Verkuil
2019-09-27 12:09     ` Marco Felsch
2019-08-30 10:16 ` [PATCH v10 06/14] media: dt-bindings: tvp5150: Add input port connectors DT bindings Marco Felsch
2019-08-30 10:16 ` [PATCH v10 07/14] media: tvp5150: fix set_selection rectangle handling Marco Felsch
2019-09-27 12:13   ` Marco Felsch
2019-09-27 12:14     ` Hans Verkuil
2019-08-30 10:16 ` [PATCH v10 08/14] media: tvp5150: add FORMAT_TRY support for get/set selection handlers Marco Felsch
2019-09-27  9:01   ` Hans Verkuil
2019-09-27 10:57     ` Marco Felsch
2019-09-27 11:05       ` Hans Verkuil
2019-08-30 10:16 ` [PATCH v10 09/14] media: tvp5150: initialize subdev before parsing device tree Marco Felsch
2019-08-30 10:16 ` [PATCH v10 10/14] media: tvp5150: add s_power callback Marco Felsch
2019-08-30 10:16 ` [PATCH v10 11/14] media: dt-bindings: tvp5150: cleanup bindings stlye Marco Felsch
2019-08-30 10:16 ` [PATCH v10 12/14] media: dt-bindings: tvp5150: add optional sdtv standards documentation Marco Felsch
2019-08-30 10:16 ` [PATCH v10 13/14] media: tvp5150: add support to limit sdtv standards Marco Felsch
2019-09-27  8:52   ` Hans Verkuil
2019-09-27 12:09     ` Marco Felsch
2019-08-30 10:16 ` [PATCH v10 14/14] media: tvp5150: make debug output more readable Marco Felsch

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=20200107134923.GP19828@paasikivi.fi.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hans.verkuil@cisco.com \
    --cc=jacopo+renesas@jmondi.org \
    --cc=kernel@pengutronix.de \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=mchehab@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@iki.fi \
    /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).