All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Steve Longerbeam <slongerbeam@gmail.com>,
	robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
	kernel@pengutronix.de, fabio.estevam@nxp.com,
	linux@armlinux.org.uk, mchehab@kernel.org, hverkuil@xs4all.nl,
	nick@shmanahar.org, markus.heiser@darmarIT.de,
	laurent.pinchart+renesas@ideasonboard.com, bparrot@ti.com,
	geert@linux-m68k.org, arnd@arndb.de, sudipm.mukherjee@gmail.com,
	minghsiu.tsai@mediatek.com, tiffany.lin@mediatek.com,
	jean-christophe.trotin@st.com, horms+renesas@verge.net.au,
	niklas.soderlund+renesas@ragnatech.se, robert.jarzmik@free.fr,
	songjun.wu@microchip.com, andrew-ct.chen@mediatek.com,
	gregkh@linuxfoundation.org, shuah@kernel.org,
	sakari.ailus@linux.intel.com, pavel@ucw.cz,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, devel@driverdev.osuosl.org,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Steve Longerbeam <steve_longerbeam@mentor.com>
Subject: Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Date: Thu, 13 Apr 2017 15:52:58 +0200	[thread overview]
Message-ID: <1492091578.2383.39.camel@pengutronix.de> (raw)
In-Reply-To: <20170404124732.GD3288@valkosipuli.retiisi.org.uk>

Hi Sakari,

thank you for the review.

On Tue, 2017-04-04 at 15:47 +0300, Sakari Ailus wrote:
> Hi Steve, Philipp and Pavel,
> 
> On Mon, Mar 27, 2017 at 05:40:34PM -0700, Steve Longerbeam wrote:
> > From: Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > This driver can handle SoC internal and external video bus multiplexers,
> > controlled either by register bit fields or by a GPIO. The subdevice
> > passes through frame interval and mbus configuration of the active input
> > to the output side.
> 
> The MUX framework is already in linux-next. Could you use that instead of
> adding new driver + bindings that are not compliant with the MUX framework?
> I don't think it'd be much of a change in terms of code, using the MUX
> framework appears quite simple.

It is not quite clear to me how to design the DT bindings for this. Just
splitting the video-multiplexer driver from the mux-mmio / mux-gpio
would make it necessary to keep the video-multiplexer node to describe
the of-graph bindings. But then we have two different nodes in the DT
that describe the same hardware:

	mux: mux {
		compatible = "mux-gpio";
		mux-gpios = <&gpio 0>, <&gpio 1>;
		#mux-control-cells = <0>;
	}

	video-multiplexer {
		compatible = "video-multiplexer"
		mux-controls = <&mux>;

		ports {
			/* ... */
		}
	}

It would feel more natural to have the ports in the mux node, but then
how would the video-multiplexer driver be instanciated, and how would it
get to the of-graph nodes?

> In general the driver looks pretty good, especially regarding the user space
> API implementation which is important for use with other drivers.
> 
> I have some more detailed comments below.
> 
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > - fixed a cut&paste error in vidsw_remove(): v4l2_async_register_subdev()
> >   should be unregister.
> > 
> > - added media_entity_cleanup() to vidsw_remove().
> > 
> > - added missing MODULE_DEVICE_TABLE().
> >   Suggested-by: Javier Martinez Canillas <javier@dowhile0.org>
> > 
> > - there was a line left over from a previous iteration that negated
> >   the new way of determining the pad count just before it which
> >   has been removed (num_pads = of_get_child_count(np)).
> > 
> > - removed [gs]_frame_interval ops. timeperframe is not used anywhwere
> >   in this subdev, and currently it has no control over frame rate.
> > 
> > - add link_validate to media_entity_operations.
> > 
> > - moved devicetree binding doc to a separate commit.
> > 
> > - Philipp Zabel has developed a set of patches that allow adding
> >   to the subdev async notifier waiting list using a chaining method
> >   from the async registered callbacks (v4l2_of_subdev_registered()
> >   and the prep patches for that). For now, I've removed the use of
> >   v4l2_of_subdev_registered() for the vidmux driver's registered
> >   callback. This doesn't affect the functionality of this driver,
> >   but allows for it to be merged now, before adding the chaining
> >   support.
> > 
> > Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> > ---
> >  drivers/media/platform/Kconfig             |   8 +
> >  drivers/media/platform/Makefile            |   2 +
> >  drivers/media/platform/video-multiplexer.c | 451 +++++++++++++++++++++++++++++
> >  3 files changed, 461 insertions(+)
> >  create mode 100644 drivers/media/platform/video-multiplexer.c
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index ab0bb48..c9b8d9c 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -74,6 +74,14 @@ config VIDEO_M32R_AR_M64278
> >  	  To compile this driver as a module, choose M here: the
> >  	  module will be called arv.
> >  
> > +config VIDEO_MULTIPLEXER
> > +	tristate "Video Multiplexer"
> > +	depends on VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
> > +	help
> > +	  This driver provides support for SoC internal N:1 video bus
> > +	  multiplexers controlled by register bitfields as well as external
> > +	  2:1 video multiplexers controlled by a single GPIO.
> > +
> >  config VIDEO_OMAP3
> >  	tristate "OMAP 3 Camera support"
> >  	depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > index 8959f6e..d418add 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)		+= sh_veu.o
> >  
> >  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)	+= m2m-deinterlace.o
> >  
> > +obj-$(CONFIG_VIDEO_MULTIPLEXER)		+= video-multiplexer.o
> > +
> >  obj-$(CONFIG_VIDEO_S3C_CAMIF) 		+= s3c-camif/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) 	+= exynos4-is/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)	+= s5p-jpeg/
> > diff --git a/drivers/media/platform/video-multiplexer.c b/drivers/media/platform/video-multiplexer.c
> > new file mode 100644
> > index 0000000..b18c317
> > --- /dev/null
> > +++ b/drivers/media/platform/video-multiplexer.c
> > @@ -0,0 +1,451 @@
> > +/*
> > + * video stream multiplexer controlled via gpio or syscon
> > + *
> > + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> > + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_graph.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <media/v4l2-async.h>
> > +#include <media/v4l2-device.h>
> > +#include <media/v4l2-subdev.h>
> > +#include <media/v4l2-of.h>
> > +
> > +struct vidsw {
> > +	struct v4l2_subdev subdev;
> > +	unsigned int num_pads;
> 
> You could use subdev.entity.num_pads instead of caching the value locally.

Ok, I'll change this.

> > +	struct media_pad *pads;
> > +	struct v4l2_mbus_framefmt *format_mbus;
> > +	struct v4l2_of_endpoint *endpoint;
> > +	struct regmap_field *field;
> > +	struct gpio_desc *gpio;
> > +	int active;
> > +};
> > +
> > +static inline struct vidsw *v4l2_subdev_to_vidsw(struct v4l2_subdev *sd)
> > +{
> > +	return container_of(sd, struct vidsw, subdev);
> > +}
> > +
> > +static void vidsw_set_active(struct vidsw *vidsw, int active)
> > +{
> > +	vidsw->active = active;
> > +	if (active < 0)
> > +		return;
> > +
> > +	dev_dbg(vidsw->subdev.dev, "setting %d active\n", active);
> > +
> > +	if (vidsw->field)
> > +		regmap_field_write(vidsw->field, active);
> > +	else if (vidsw->gpio)
> > +		gpiod_set_value(vidsw->gpio, active);
> > +}
> > +
> > +static int vidsw_link_setup(struct media_entity *entity,
> > +			    const struct media_pad *local,
> > +			    const struct media_pad *remote, u32 flags)
> > +{
> > +	struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +
> > +	/* We have no limitations on enabling or disabling our output link */
> > +	if (local->index == vidsw->num_pads - 1)
> > +		return 0;
> > +
> > +	dev_dbg(sd->dev, "link setup %s -> %s", remote->entity->name,
> > +		local->entity->name);
> > +
> > +	if (!(flags & MEDIA_LNK_FL_ENABLED)) {
> > +		if (local->index == vidsw->active) {
> > +			dev_dbg(sd->dev, "going inactive\n");
> > +			vidsw->active = -1;
> > +		}
> > +		return 0;
> > +	}
> > +
> > +	if (vidsw->active >= 0) {
> > +		struct media_pad *pad;
> > +
> > +		if (vidsw->active == local->index)
> > +			return 0;
> > +
> > +		pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
> > +		if (pad) {
> > +			struct media_link *link;
> > +			int ret;
> > +
> > +			link = media_entity_find_link(pad,
> > +						&vidsw->pads[vidsw->active]);
> > +			if (link) {
> > +				ret = __media_entity_setup_link(link, 0);
> 
> I wouldn't implicitly disable a link, even if only one can be active at a
> given time. No other drivers do that either.
> 
> Perhaps returning an error might be a better thing to do: if you're
> reconfiguring the pipeline anyway, there are likely issues elsewhere in it.
> 
> We could also change the behaviour later to allow implicit changes but we
> can't later on go the other way without breaking the user space.

Fair enough, I'll drop this.

> > +				if (ret)
> > +					return ret;
> > +			}
> > +		}
> > +	}
> > +
> > +	vidsw_set_active(vidsw, local->index);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct media_entity_operations vidsw_ops = {
> > +	.link_setup = vidsw_link_setup,
> > +	.link_validate = v4l2_subdev_link_validate,
> > +};
> > +
> > +static bool vidsw_endpoint_disabled(struct device_node *ep)
> > +{
> > +	struct device_node *rpp;
> > +
> > +	if (!of_device_is_available(ep))
> 
> ep here is the endpoint, whereas the argument to of_device_is_available()
> should correspond to the actual device.

Well, this was a convenience to allow adding status = "disabled" to
endpoints to turn them off (see the function name). I

> > +		return true;
> > +
> > +	rpp = of_graph_get_remote_port_parent(ep);
> > +	if (!rpp)
> > +		return true;
> > +
> > +	return !of_device_is_available(rpp);
> > +}
> > +
> > +static int vidsw_async_init(struct vidsw *vidsw, struct device_node *node)
> 
> I think I'd arrange this closer to probe as it's related to probe directly.
> Up to you.

I'll change this to
	rpp = of_graph_get_remote_port_parent(ep);
	return !of_device_is_available(rpp);
as Steve suggested.

> > +{
> > +	struct device_node *ep;
> > +	u32 portno;
> > +	int numports;
> > +	int ret;
> > +	int i;
> > +	bool active_link = false;
> > +
> > +	numports = vidsw->num_pads;
> > +
> > +	for (i = 0; i < numports - 1; i++)
> > +		vidsw->pads[i].flags = MEDIA_PAD_FL_SINK;
> > +	vidsw->pads[numports - 1].flags = MEDIA_PAD_FL_SOURCE;
> > +
> > +	vidsw->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
> > +	ret = media_entity_pads_init(&vidsw->subdev.entity, numports,
> > +				     vidsw->pads);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	vidsw->subdev.entity.ops = &vidsw_ops;
> > +
> > +	for_each_endpoint_of_node(node, ep) {
> > +		struct v4l2_of_endpoint endpoint;
> > +
> > +		v4l2_of_parse_endpoint(ep, &endpoint);
> > +
> > +		portno = endpoint.base.port;
> > +		if (portno >= numports - 1)
> > +			continue;
> > +
> > +		if (vidsw_endpoint_disabled(ep)) {
> > +			dev_dbg(vidsw->subdev.dev,
> > +				"port %d disabled\n", portno);
> > +			continue;
> > +		}
> > +
> > +		vidsw->endpoint[portno] = endpoint;
> > +
> > +		if (portno == vidsw->active)
> > +			active_link = true;
> > +	}
> > +
> > +	for (portno = 0; portno < numports - 1; portno++) {
> > +		if (!vidsw->endpoint[portno].base.local_node)
> > +			continue;
> > +
> > +		/* If the active input is not connected, use another */
> > +		if (!active_link) {
> > +			vidsw_set_active(vidsw, portno);
> > +			active_link = true;
> > +		}
> > +	}
> > +
> > +	return v4l2_async_register_subdev(&vidsw->subdev);
> > +}
> > +
> > +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct v4l2_mbus_config *cfg)
> 
> We should get rid of g_mbus_config() in the long run, but as we don't have
> the alternative (frame descriptors) isn't up to the job yet I guess it's ok.
> I don't think we'll have too many users for the video switch right now.

Ok, we can add a comment to mark this as undesirable.

> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct media_pad *pad;
> > +	int ret;
> > +
> > +	if (vidsw->active == -1) {
> > +		dev_err(sd->dev, "no configuration for inactive mux\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	/*
> > +	 * Retrieve media bus configuration from the entity connected to the
> > +	 * active input
> > +	 */
> > +	pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
> > +	if (pad) {
> > +		sd = media_entity_to_v4l2_subdev(pad->entity);
> > +		ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
> > +		if (ret == -ENOIOCTLCMD)
> > +			pad = NULL;
> > +		else if (ret < 0) {
> > +			dev_err(sd->dev, "failed to get source configuration\n");
> > +			return ret;
> > +		}
> > +	}
> > +	if (!pad) {
> > +		/* Mirror the input side on the output side */
> > +		cfg->type = vidsw->endpoint[vidsw->active].bus_type;
> > +		if (cfg->type == V4L2_MBUS_PARALLEL ||
> > +		    cfg->type == V4L2_MBUS_BT656)
> > +			cfg->flags = vidsw->endpoint[vidsw->active].bus.parallel.flags;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_s_stream(struct v4l2_subdev *sd, int enable)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct v4l2_subdev *upstream_sd;
> > +	struct media_pad *pad;
> > +
> > +	if (vidsw->active == -1) {
> > +		dev_err(sd->dev, "Can not start streaming on inactive mux\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	pad = media_entity_remote_pad(&sd->entity.pads[vidsw->active]);
> > +	if (!pad) {
> > +		dev_err(sd->dev, "Failed to find remote source pad\n");
> > +		return -ENOLINK;
> > +	}
> > +
> > +	if (!is_media_entity_v4l2_subdev(pad->entity)) {
> > +		dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
> > +
> > +	return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
> 
> Now that we'll have more than two drivers involved in the same pipeline it
> becomes necessary to define the behaviour of s_stream() throughout the
> pipeline --- i.e. whose responsibility is it to call s_stream() on the
> sub-devices in the pipeline?
> 
> I can submit a patch for that. I think the way you do it here is good, as it
> enables the caller to choose the appropriate behaviour, i.e. start the local
> device before or after the upstream sub-device.

Please do, this should be decided before any more complex inter-driver
pipelines show up.

> > +}
> > +
> > +static const struct v4l2_subdev_video_ops vidsw_subdev_video_ops = {
> > +	.g_mbus_config = vidsw_g_mbus_config,
> > +	.s_stream = vidsw_s_stream,
> > +};
> > +
> > +static struct v4l2_mbus_framefmt *
> > +__vidsw_get_pad_format(struct v4l2_subdev *sd,
> > +		       struct v4l2_subdev_pad_config *cfg,
> > +		       unsigned int pad, u32 which)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +
> > +	switch (which) {
> > +	case V4L2_SUBDEV_FORMAT_TRY:
> > +		return v4l2_subdev_get_try_format(sd, cfg, pad);
> > +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> > +		return &vidsw->format_mbus[pad];
> > +	default:
> > +		return NULL;
> > +	}
> > +}
> > +
> > +static int vidsw_get_format(struct v4l2_subdev *sd,
> > +			    struct v4l2_subdev_pad_config *cfg,
> > +			    struct v4l2_subdev_format *sdformat)
> > +{
> > +	sdformat->format = *__vidsw_get_pad_format(sd, cfg, sdformat->pad,
> > +						   sdformat->which);
> > +	return 0;
> > +}
> > +
> > +static int vidsw_set_format(struct v4l2_subdev *sd,
> > +			    struct v4l2_subdev_pad_config *cfg,
> > +			    struct v4l2_subdev_format *sdformat)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct v4l2_mbus_framefmt *mbusformat;
> > +
> > +	if (sdformat->pad >= vidsw->num_pads)
> > +		return -EINVAL;
> 
> This check is already performed in v4l2-subdev.c.

Excellent.

> > +
> > +	mbusformat = __vidsw_get_pad_format(sd, cfg, sdformat->pad,
> > +					    sdformat->which);
> > +	if (!mbusformat)
> > +		return -EINVAL;
> > +
> > +	/* Output pad mirrors active input pad, no limitations on input pads */
> 
> Source and sink pads.

Ok.

> > +	if (sdformat->pad == (vidsw->num_pads - 1) && vidsw->active >= 0)
> 
> I think it'd be cleaner to test for the pad flag instead of the number. Or,
> add a macro to obtain the source pad number.
> 
> > +		sdformat->format = vidsw->format_mbus[vidsw->active];
> > +
> > +	*mbusformat = sdformat->format;
> > +
> > +	return 0;
> > +}
> > +
> > +static struct v4l2_subdev_pad_ops vidsw_pad_ops = {
> > +	.get_fmt = vidsw_get_format,
> > +	.set_fmt = vidsw_set_format,
> > +};
> > +
> > +static struct v4l2_subdev_ops vidsw_subdev_ops = {
> > +	.pad = &vidsw_pad_ops,
> > +	.video = &vidsw_subdev_video_ops,
> > +};
> > +
> > +static int of_get_reg_field(struct device_node *node, struct reg_field *field)
> > +{
> > +	u32 bit_mask;
> > +	int ret;
> > +
> > +	ret = of_property_read_u32(node, "reg", &field->reg);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(node, "bit-mask", &bit_mask);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(node, "bit-shift", &field->lsb);
> > +	if (ret < 0)
> > +		return ret;
> 
> I think the above would look nice in a MUX driver. :-)

I'll submit an MMIO / syscon / regmap bitfield mux driver.

> > +
> > +	field->msb = field->lsb + fls(bit_mask) - 1;
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_probe(struct platform_device *pdev)
> > +{
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct of_endpoint endpoint;
> > +	struct device_node *ep;
> > +	struct reg_field field;
> > +	struct vidsw *vidsw;
> > +	struct regmap *map;
> > +	unsigned int num_pads;
> > +	int ret;
> > +
> > +	vidsw = devm_kzalloc(&pdev->dev, sizeof(*vidsw), GFP_KERNEL);
> > +	if (!vidsw)
> > +		return -ENOMEM;
> > +
> > +	platform_set_drvdata(pdev, vidsw);
> > +
> > +	v4l2_subdev_init(&vidsw->subdev, &vidsw_subdev_ops);
> > +	snprintf(vidsw->subdev.name, sizeof(vidsw->subdev.name), "%s",
> > +			np->name);
> > +	vidsw->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > +	vidsw->subdev.dev = &pdev->dev;
> > +
> > +	/*
> > +	 * The largest numbered port is the output port. It determines
> > +	 * total number of pads
> > +	 */
> > +	num_pads = 0;
> 
> You can initialise num_pads in variable declaration.
> 
> > +	for_each_endpoint_of_node(np, ep) {
> > +		of_graph_parse_endpoint(ep, &endpoint);
> > +		num_pads = max(num_pads, endpoint.port + 1);
> 
> Port numbers come directly from DT.
> 
> Shouldn't num_pads be only the number of pads that have links with actual
> physical connections? I.e. if a device is disabled, it shouldn't be
> counted here.

If we only create media pads for the connected DT ports with available
remote device, there is no 1:1 correspondence between pad number and the
physical mux setting anymore, complicating the driver.

> > +	}
> > +
> > +	if (num_pads < 2) {
> > +		dev_err(&pdev->dev, "Not enough ports %d\n", num_pads);
> > +		return -EINVAL;
> > +	}
> > +
> > +	ret = of_get_reg_field(np, &field);
> > +	if (ret == 0) {
> > +		map = syscon_node_to_regmap(np->parent);
> > +		if (!map) {
> > +			dev_err(&pdev->dev, "Failed to get syscon register map\n");
> > +			return PTR_ERR(map);
> > +		}
> > +
> > +		vidsw->field = devm_regmap_field_alloc(&pdev->dev, map, field);
> > +		if (IS_ERR(vidsw->field)) {
> > +			dev_err(&pdev->dev, "Failed to allocate regmap field\n");
> > +			return PTR_ERR(vidsw->field);
> > +		}
> > +
> > +		regmap_field_read(vidsw->field, &vidsw->active);
> > +	} else {
> > +		if (num_pads > 3) {
> > +			dev_err(&pdev->dev, "Too many ports %d\n", num_pads);
> > +			return -EINVAL;
> > +		}
> > +
> > +		vidsw->gpio = devm_gpiod_get(&pdev->dev, NULL, GPIOD_OUT_LOW);
> > +		if (IS_ERR(vidsw->gpio)) {
> > +			dev_warn(&pdev->dev,
> > +				 "could not request control gpio: %d\n", ret);
> > +			vidsw->gpio = NULL;
> > +		}
> > +
> > +		vidsw->active = gpiod_get_value(vidsw->gpio) ? 1 : 0;
> > +	}
> > +
> > +	vidsw->num_pads = num_pads;
> > +	vidsw->pads = devm_kzalloc(&pdev->dev, sizeof(*vidsw->pads) * num_pads,
> > +			GFP_KERNEL);
> > +	vidsw->format_mbus = devm_kzalloc(&pdev->dev,
> > +			sizeof(*vidsw->format_mbus) * num_pads, GFP_KERNEL);
> > +	vidsw->endpoint = devm_kzalloc(&pdev->dev,
> > +			sizeof(*vidsw->endpoint) * (num_pads - 1), GFP_KERNEL);
> > +
> > +	ret = vidsw_async_init(vidsw, np);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_remove(struct platform_device *pdev)
> > +{
> > +	struct vidsw *vidsw = platform_get_drvdata(pdev);
> > +	struct v4l2_subdev *sd = &vidsw->subdev;
> > +
> > +	v4l2_async_unregister_subdev(sd);
> > +	media_entity_cleanup(&sd->entity);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id vidsw_dt_ids[] = {
> > +	{ .compatible = "video-multiplexer", },
> > +	{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, vidsw_dt_ids);
> > +
> > +static struct platform_driver vidsw_driver = {
> > +	.probe		= vidsw_probe,
> > +	.remove		= vidsw_remove,
> > +	.driver		= {
> > +		.of_match_table = vidsw_dt_ids,
> > +		.name = "video-multiplexer",
> > +	},
> > +};
> > +
> > +module_platform_driver(vidsw_driver);
> > +
> > +MODULE_DESCRIPTION("video stream multiplexer");
> > +MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> > +MODULE_AUTHOR("Philipp Zabel, Pengutronix");
> > +MODULE_LICENSE("GPL");

regards
Philipp

WARNING: multiple messages have this Message-ID (diff)
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
Cc: Steve Longerbeam
	<slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
	fabio.estevam-3arQi8VN3Tc@public.gmane.org,
	linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
	mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org,
	nick-gcszYUEDH4VrovVCs/uTlw@public.gmane.org,
	markus.heiser-O6JHGLzbNUwb1SvskN2V4Q@public.gmane.org,
	laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
	bparrot-l0cyMroinI0@public.gmane.org,
	geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org,
	arnd-r2nGTMty4D4@public.gmane.org,
	sudipm.mukherjee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	tiffany.lin-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	jean-christophe.trotin-qxv4g6HH51o@public.gmane.org,
	horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org,
	niklas.soderlund+renesas-1zkq55x86MTxsAP9Fp7wbw@public.gmane.org,
	robert.jarzmik-GANU6spQydw@public.gmane.org,
	songjun.wu-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org,
	andrew-ct.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org,
	gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
	shuah-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	pavel-+ZI9xUNit7I@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWMMKQXVYFwzLw@public.gmane.org
Subject: Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Date: Thu, 13 Apr 2017 15:52:58 +0200	[thread overview]
Message-ID: <1492091578.2383.39.camel@pengutronix.de> (raw)
In-Reply-To: <20170404124732.GD3288-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>

Hi Sakari,

thank you for the review.

On Tue, 2017-04-04 at 15:47 +0300, Sakari Ailus wrote:
> Hi Steve, Philipp and Pavel,
> 
> On Mon, Mar 27, 2017 at 05:40:34PM -0700, Steve Longerbeam wrote:
> > From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > 
> > This driver can handle SoC internal and external video bus multiplexers,
> > controlled either by register bit fields or by a GPIO. The subdevice
> > passes through frame interval and mbus configuration of the active input
> > to the output side.
> 
> The MUX framework is already in linux-next. Could you use that instead of
> adding new driver + bindings that are not compliant with the MUX framework?
> I don't think it'd be much of a change in terms of code, using the MUX
> framework appears quite simple.

It is not quite clear to me how to design the DT bindings for this. Just
splitting the video-multiplexer driver from the mux-mmio / mux-gpio
would make it necessary to keep the video-multiplexer node to describe
the of-graph bindings. But then we have two different nodes in the DT
that describe the same hardware:

	mux: mux {
		compatible = "mux-gpio";
		mux-gpios = <&gpio 0>, <&gpio 1>;
		#mux-control-cells = <0>;
	}

	video-multiplexer {
		compatible = "video-multiplexer"
		mux-controls = <&mux>;

		ports {
			/* ... */
		}
	}

It would feel more natural to have the ports in the mux node, but then
how would the video-multiplexer driver be instanciated, and how would it
get to the of-graph nodes?

> In general the driver looks pretty good, especially regarding the user space
> API implementation which is important for use with other drivers.
> 
> I have some more detailed comments below.
> 
> > 
> > Signed-off-by: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > 
> > - fixed a cut&paste error in vidsw_remove(): v4l2_async_register_subdev()
> >   should be unregister.
> > 
> > - added media_entity_cleanup() to vidsw_remove().
> > 
> > - added missing MODULE_DEVICE_TABLE().
> >   Suggested-by: Javier Martinez Canillas <javier-0uQlZySMnqxg9hUCZPvPmw@public.gmane.org>
> > 
> > - there was a line left over from a previous iteration that negated
> >   the new way of determining the pad count just before it which
> >   has been removed (num_pads = of_get_child_count(np)).
> > 
> > - removed [gs]_frame_interval ops. timeperframe is not used anywhwere
> >   in this subdev, and currently it has no control over frame rate.
> > 
> > - add link_validate to media_entity_operations.
> > 
> > - moved devicetree binding doc to a separate commit.
> > 
> > - Philipp Zabel has developed a set of patches that allow adding
> >   to the subdev async notifier waiting list using a chaining method
> >   from the async registered callbacks (v4l2_of_subdev_registered()
> >   and the prep patches for that). For now, I've removed the use of
> >   v4l2_of_subdev_registered() for the vidmux driver's registered
> >   callback. This doesn't affect the functionality of this driver,
> >   but allows for it to be merged now, before adding the chaining
> >   support.
> > 
> > Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> > ---
> >  drivers/media/platform/Kconfig             |   8 +
> >  drivers/media/platform/Makefile            |   2 +
> >  drivers/media/platform/video-multiplexer.c | 451 +++++++++++++++++++++++++++++
> >  3 files changed, 461 insertions(+)
> >  create mode 100644 drivers/media/platform/video-multiplexer.c
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index ab0bb48..c9b8d9c 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -74,6 +74,14 @@ config VIDEO_M32R_AR_M64278
> >  	  To compile this driver as a module, choose M here: the
> >  	  module will be called arv.
> >  
> > +config VIDEO_MULTIPLEXER
> > +	tristate "Video Multiplexer"
> > +	depends on VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
> > +	help
> > +	  This driver provides support for SoC internal N:1 video bus
> > +	  multiplexers controlled by register bitfields as well as external
> > +	  2:1 video multiplexers controlled by a single GPIO.
> > +
> >  config VIDEO_OMAP3
> >  	tristate "OMAP 3 Camera support"
> >  	depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > index 8959f6e..d418add 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)		+= sh_veu.o
> >  
> >  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)	+= m2m-deinterlace.o
> >  
> > +obj-$(CONFIG_VIDEO_MULTIPLEXER)		+= video-multiplexer.o
> > +
> >  obj-$(CONFIG_VIDEO_S3C_CAMIF) 		+= s3c-camif/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) 	+= exynos4-is/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)	+= s5p-jpeg/
> > diff --git a/drivers/media/platform/video-multiplexer.c b/drivers/media/platform/video-multiplexer.c
> > new file mode 100644
> > index 0000000..b18c317
> > --- /dev/null
> > +++ b/drivers/media/platform/video-multiplexer.c
> > @@ -0,0 +1,451 @@
> > +/*
> > + * video stream multiplexer controlled via gpio or syscon
> > + *
> > + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_graph.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <media/v4l2-async.h>
> > +#include <media/v4l2-device.h>
> > +#include <media/v4l2-subdev.h>
> > +#include <media/v4l2-of.h>
> > +
> > +struct vidsw {
> > +	struct v4l2_subdev subdev;
> > +	unsigned int num_pads;
> 
> You could use subdev.entity.num_pads instead of caching the value locally.

Ok, I'll change this.

> > +	struct media_pad *pads;
> > +	struct v4l2_mbus_framefmt *format_mbus;
> > +	struct v4l2_of_endpoint *endpoint;
> > +	struct regmap_field *field;
> > +	struct gpio_desc *gpio;
> > +	int active;
> > +};
> > +
> > +static inline struct vidsw *v4l2_subdev_to_vidsw(struct v4l2_subdev *sd)
> > +{
> > +	return container_of(sd, struct vidsw, subdev);
> > +}
> > +
> > +static void vidsw_set_active(struct vidsw *vidsw, int active)
> > +{
> > +	vidsw->active = active;
> > +	if (active < 0)
> > +		return;
> > +
> > +	dev_dbg(vidsw->subdev.dev, "setting %d active\n", active);
> > +
> > +	if (vidsw->field)
> > +		regmap_field_write(vidsw->field, active);
> > +	else if (vidsw->gpio)
> > +		gpiod_set_value(vidsw->gpio, active);
> > +}
> > +
> > +static int vidsw_link_setup(struct media_entity *entity,
> > +			    const struct media_pad *local,
> > +			    const struct media_pad *remote, u32 flags)
> > +{
> > +	struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +
> > +	/* We have no limitations on enabling or disabling our output link */
> > +	if (local->index == vidsw->num_pads - 1)
> > +		return 0;
> > +
> > +	dev_dbg(sd->dev, "link setup %s -> %s", remote->entity->name,
> > +		local->entity->name);
> > +
> > +	if (!(flags & MEDIA_LNK_FL_ENABLED)) {
> > +		if (local->index == vidsw->active) {
> > +			dev_dbg(sd->dev, "going inactive\n");
> > +			vidsw->active = -1;
> > +		}
> > +		return 0;
> > +	}
> > +
> > +	if (vidsw->active >= 0) {
> > +		struct media_pad *pad;
> > +
> > +		if (vidsw->active == local->index)
> > +			return 0;
> > +
> > +		pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
> > +		if (pad) {
> > +			struct media_link *link;
> > +			int ret;
> > +
> > +			link = media_entity_find_link(pad,
> > +						&vidsw->pads[vidsw->active]);
> > +			if (link) {
> > +				ret = __media_entity_setup_link(link, 0);
> 
> I wouldn't implicitly disable a link, even if only one can be active at a
> given time. No other drivers do that either.
> 
> Perhaps returning an error might be a better thing to do: if you're
> reconfiguring the pipeline anyway, there are likely issues elsewhere in it.
> 
> We could also change the behaviour later to allow implicit changes but we
> can't later on go the other way without breaking the user space.

Fair enough, I'll drop this.

> > +				if (ret)
> > +					return ret;
> > +			}
> > +		}
> > +	}
> > +
> > +	vidsw_set_active(vidsw, local->index);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct media_entity_operations vidsw_ops = {
> > +	.link_setup = vidsw_link_setup,
> > +	.link_validate = v4l2_subdev_link_validate,
> > +};
> > +
> > +static bool vidsw_endpoint_disabled(struct device_node *ep)
> > +{
> > +	struct device_node *rpp;
> > +
> > +	if (!of_device_is_available(ep))
> 
> ep here is the endpoint, whereas the argument to of_device_is_available()
> should correspond to the actual device.

Well, this was a convenience to allow adding status = "disabled" to
endpoints to turn them off (see the function name). I

> > +		return true;
> > +
> > +	rpp = of_graph_get_remote_port_parent(ep);
> > +	if (!rpp)
> > +		return true;
> > +
> > +	return !of_device_is_available(rpp);
> > +}
> > +
> > +static int vidsw_async_init(struct vidsw *vidsw, struct device_node *node)
> 
> I think I'd arrange this closer to probe as it's related to probe directly.
> Up to you.

I'll change this to
	rpp = of_graph_get_remote_port_parent(ep);
	return !of_device_is_available(rpp);
as Steve suggested.

> > +{
> > +	struct device_node *ep;
> > +	u32 portno;
> > +	int numports;
> > +	int ret;
> > +	int i;
> > +	bool active_link = false;
> > +
> > +	numports = vidsw->num_pads;
> > +
> > +	for (i = 0; i < numports - 1; i++)
> > +		vidsw->pads[i].flags = MEDIA_PAD_FL_SINK;
> > +	vidsw->pads[numports - 1].flags = MEDIA_PAD_FL_SOURCE;
> > +
> > +	vidsw->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
> > +	ret = media_entity_pads_init(&vidsw->subdev.entity, numports,
> > +				     vidsw->pads);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	vidsw->subdev.entity.ops = &vidsw_ops;
> > +
> > +	for_each_endpoint_of_node(node, ep) {
> > +		struct v4l2_of_endpoint endpoint;
> > +
> > +		v4l2_of_parse_endpoint(ep, &endpoint);
> > +
> > +		portno = endpoint.base.port;
> > +		if (portno >= numports - 1)
> > +			continue;
> > +
> > +		if (vidsw_endpoint_disabled(ep)) {
> > +			dev_dbg(vidsw->subdev.dev,
> > +				"port %d disabled\n", portno);
> > +			continue;
> > +		}
> > +
> > +		vidsw->endpoint[portno] = endpoint;
> > +
> > +		if (portno == vidsw->active)
> > +			active_link = true;
> > +	}
> > +
> > +	for (portno = 0; portno < numports - 1; portno++) {
> > +		if (!vidsw->endpoint[portno].base.local_node)
> > +			continue;
> > +
> > +		/* If the active input is not connected, use another */
> > +		if (!active_link) {
> > +			vidsw_set_active(vidsw, portno);
> > +			active_link = true;
> > +		}
> > +	}
> > +
> > +	return v4l2_async_register_subdev(&vidsw->subdev);
> > +}
> > +
> > +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct v4l2_mbus_config *cfg)
> 
> We should get rid of g_mbus_config() in the long run, but as we don't have
> the alternative (frame descriptors) isn't up to the job yet I guess it's ok.
> I don't think we'll have too many users for the video switch right now.

Ok, we can add a comment to mark this as undesirable.

> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct media_pad *pad;
> > +	int ret;
> > +
> > +	if (vidsw->active == -1) {
> > +		dev_err(sd->dev, "no configuration for inactive mux\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	/*
> > +	 * Retrieve media bus configuration from the entity connected to the
> > +	 * active input
> > +	 */
> > +	pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
> > +	if (pad) {
> > +		sd = media_entity_to_v4l2_subdev(pad->entity);
> > +		ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
> > +		if (ret == -ENOIOCTLCMD)
> > +			pad = NULL;
> > +		else if (ret < 0) {
> > +			dev_err(sd->dev, "failed to get source configuration\n");
> > +			return ret;
> > +		}
> > +	}
> > +	if (!pad) {
> > +		/* Mirror the input side on the output side */
> > +		cfg->type = vidsw->endpoint[vidsw->active].bus_type;
> > +		if (cfg->type == V4L2_MBUS_PARALLEL ||
> > +		    cfg->type == V4L2_MBUS_BT656)
> > +			cfg->flags = vidsw->endpoint[vidsw->active].bus.parallel.flags;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_s_stream(struct v4l2_subdev *sd, int enable)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct v4l2_subdev *upstream_sd;
> > +	struct media_pad *pad;
> > +
> > +	if (vidsw->active == -1) {
> > +		dev_err(sd->dev, "Can not start streaming on inactive mux\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	pad = media_entity_remote_pad(&sd->entity.pads[vidsw->active]);
> > +	if (!pad) {
> > +		dev_err(sd->dev, "Failed to find remote source pad\n");
> > +		return -ENOLINK;
> > +	}
> > +
> > +	if (!is_media_entity_v4l2_subdev(pad->entity)) {
> > +		dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
> > +
> > +	return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
> 
> Now that we'll have more than two drivers involved in the same pipeline it
> becomes necessary to define the behaviour of s_stream() throughout the
> pipeline --- i.e. whose responsibility is it to call s_stream() on the
> sub-devices in the pipeline?
> 
> I can submit a patch for that. I think the way you do it here is good, as it
> enables the caller to choose the appropriate behaviour, i.e. start the local
> device before or after the upstream sub-device.

Please do, this should be decided before any more complex inter-driver
pipelines show up.

> > +}
> > +
> > +static const struct v4l2_subdev_video_ops vidsw_subdev_video_ops = {
> > +	.g_mbus_config = vidsw_g_mbus_config,
> > +	.s_stream = vidsw_s_stream,
> > +};
> > +
> > +static struct v4l2_mbus_framefmt *
> > +__vidsw_get_pad_format(struct v4l2_subdev *sd,
> > +		       struct v4l2_subdev_pad_config *cfg,
> > +		       unsigned int pad, u32 which)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +
> > +	switch (which) {
> > +	case V4L2_SUBDEV_FORMAT_TRY:
> > +		return v4l2_subdev_get_try_format(sd, cfg, pad);
> > +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> > +		return &vidsw->format_mbus[pad];
> > +	default:
> > +		return NULL;
> > +	}
> > +}
> > +
> > +static int vidsw_get_format(struct v4l2_subdev *sd,
> > +			    struct v4l2_subdev_pad_config *cfg,
> > +			    struct v4l2_subdev_format *sdformat)
> > +{
> > +	sdformat->format = *__vidsw_get_pad_format(sd, cfg, sdformat->pad,
> > +						   sdformat->which);
> > +	return 0;
> > +}
> > +
> > +static int vidsw_set_format(struct v4l2_subdev *sd,
> > +			    struct v4l2_subdev_pad_config *cfg,
> > +			    struct v4l2_subdev_format *sdformat)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct v4l2_mbus_framefmt *mbusformat;
> > +
> > +	if (sdformat->pad >= vidsw->num_pads)
> > +		return -EINVAL;
> 
> This check is already performed in v4l2-subdev.c.

Excellent.

> > +
> > +	mbusformat = __vidsw_get_pad_format(sd, cfg, sdformat->pad,
> > +					    sdformat->which);
> > +	if (!mbusformat)
> > +		return -EINVAL;
> > +
> > +	/* Output pad mirrors active input pad, no limitations on input pads */
> 
> Source and sink pads.

Ok.

> > +	if (sdformat->pad == (vidsw->num_pads - 1) && vidsw->active >= 0)
> 
> I think it'd be cleaner to test for the pad flag instead of the number. Or,
> add a macro to obtain the source pad number.
> 
> > +		sdformat->format = vidsw->format_mbus[vidsw->active];
> > +
> > +	*mbusformat = sdformat->format;
> > +
> > +	return 0;
> > +}
> > +
> > +static struct v4l2_subdev_pad_ops vidsw_pad_ops = {
> > +	.get_fmt = vidsw_get_format,
> > +	.set_fmt = vidsw_set_format,
> > +};
> > +
> > +static struct v4l2_subdev_ops vidsw_subdev_ops = {
> > +	.pad = &vidsw_pad_ops,
> > +	.video = &vidsw_subdev_video_ops,
> > +};
> > +
> > +static int of_get_reg_field(struct device_node *node, struct reg_field *field)
> > +{
> > +	u32 bit_mask;
> > +	int ret;
> > +
> > +	ret = of_property_read_u32(node, "reg", &field->reg);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(node, "bit-mask", &bit_mask);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(node, "bit-shift", &field->lsb);
> > +	if (ret < 0)
> > +		return ret;
> 
> I think the above would look nice in a MUX driver. :-)

I'll submit an MMIO / syscon / regmap bitfield mux driver.

> > +
> > +	field->msb = field->lsb + fls(bit_mask) - 1;
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_probe(struct platform_device *pdev)
> > +{
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct of_endpoint endpoint;
> > +	struct device_node *ep;
> > +	struct reg_field field;
> > +	struct vidsw *vidsw;
> > +	struct regmap *map;
> > +	unsigned int num_pads;
> > +	int ret;
> > +
> > +	vidsw = devm_kzalloc(&pdev->dev, sizeof(*vidsw), GFP_KERNEL);
> > +	if (!vidsw)
> > +		return -ENOMEM;
> > +
> > +	platform_set_drvdata(pdev, vidsw);
> > +
> > +	v4l2_subdev_init(&vidsw->subdev, &vidsw_subdev_ops);
> > +	snprintf(vidsw->subdev.name, sizeof(vidsw->subdev.name), "%s",
> > +			np->name);
> > +	vidsw->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > +	vidsw->subdev.dev = &pdev->dev;
> > +
> > +	/*
> > +	 * The largest numbered port is the output port. It determines
> > +	 * total number of pads
> > +	 */
> > +	num_pads = 0;
> 
> You can initialise num_pads in variable declaration.
> 
> > +	for_each_endpoint_of_node(np, ep) {
> > +		of_graph_parse_endpoint(ep, &endpoint);
> > +		num_pads = max(num_pads, endpoint.port + 1);
> 
> Port numbers come directly from DT.
> 
> Shouldn't num_pads be only the number of pads that have links with actual
> physical connections? I.e. if a device is disabled, it shouldn't be
> counted here.

If we only create media pads for the connected DT ports with available
remote device, there is no 1:1 correspondence between pad number and the
physical mux setting anymore, complicating the driver.

> > +	}
> > +
> > +	if (num_pads < 2) {
> > +		dev_err(&pdev->dev, "Not enough ports %d\n", num_pads);
> > +		return -EINVAL;
> > +	}
> > +
> > +	ret = of_get_reg_field(np, &field);
> > +	if (ret == 0) {
> > +		map = syscon_node_to_regmap(np->parent);
> > +		if (!map) {
> > +			dev_err(&pdev->dev, "Failed to get syscon register map\n");
> > +			return PTR_ERR(map);
> > +		}
> > +
> > +		vidsw->field = devm_regmap_field_alloc(&pdev->dev, map, field);
> > +		if (IS_ERR(vidsw->field)) {
> > +			dev_err(&pdev->dev, "Failed to allocate regmap field\n");
> > +			return PTR_ERR(vidsw->field);
> > +		}
> > +
> > +		regmap_field_read(vidsw->field, &vidsw->active);
> > +	} else {
> > +		if (num_pads > 3) {
> > +			dev_err(&pdev->dev, "Too many ports %d\n", num_pads);
> > +			return -EINVAL;
> > +		}
> > +
> > +		vidsw->gpio = devm_gpiod_get(&pdev->dev, NULL, GPIOD_OUT_LOW);
> > +		if (IS_ERR(vidsw->gpio)) {
> > +			dev_warn(&pdev->dev,
> > +				 "could not request control gpio: %d\n", ret);
> > +			vidsw->gpio = NULL;
> > +		}
> > +
> > +		vidsw->active = gpiod_get_value(vidsw->gpio) ? 1 : 0;
> > +	}
> > +
> > +	vidsw->num_pads = num_pads;
> > +	vidsw->pads = devm_kzalloc(&pdev->dev, sizeof(*vidsw->pads) * num_pads,
> > +			GFP_KERNEL);
> > +	vidsw->format_mbus = devm_kzalloc(&pdev->dev,
> > +			sizeof(*vidsw->format_mbus) * num_pads, GFP_KERNEL);
> > +	vidsw->endpoint = devm_kzalloc(&pdev->dev,
> > +			sizeof(*vidsw->endpoint) * (num_pads - 1), GFP_KERNEL);
> > +
> > +	ret = vidsw_async_init(vidsw, np);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_remove(struct platform_device *pdev)
> > +{
> > +	struct vidsw *vidsw = platform_get_drvdata(pdev);
> > +	struct v4l2_subdev *sd = &vidsw->subdev;
> > +
> > +	v4l2_async_unregister_subdev(sd);
> > +	media_entity_cleanup(&sd->entity);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id vidsw_dt_ids[] = {
> > +	{ .compatible = "video-multiplexer", },
> > +	{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, vidsw_dt_ids);
> > +
> > +static struct platform_driver vidsw_driver = {
> > +	.probe		= vidsw_probe,
> > +	.remove		= vidsw_remove,
> > +	.driver		= {
> > +		.of_match_table = vidsw_dt_ids,
> > +		.name = "video-multiplexer",
> > +	},
> > +};
> > +
> > +module_platform_driver(vidsw_driver);
> > +
> > +MODULE_DESCRIPTION("video stream multiplexer");
> > +MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> > +MODULE_AUTHOR("Philipp Zabel, Pengutronix");
> > +MODULE_LICENSE("GPL");

regards
Philipp


--
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: p.zabel@pengutronix.de (Philipp Zabel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Date: Thu, 13 Apr 2017 15:52:58 +0200	[thread overview]
Message-ID: <1492091578.2383.39.camel@pengutronix.de> (raw)
In-Reply-To: <20170404124732.GD3288@valkosipuli.retiisi.org.uk>

Hi Sakari,

thank you for the review.

On Tue, 2017-04-04 at 15:47 +0300, Sakari Ailus wrote:
> Hi Steve, Philipp and Pavel,
> 
> On Mon, Mar 27, 2017 at 05:40:34PM -0700, Steve Longerbeam wrote:
> > From: Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > This driver can handle SoC internal and external video bus multiplexers,
> > controlled either by register bit fields or by a GPIO. The subdevice
> > passes through frame interval and mbus configuration of the active input
> > to the output side.
> 
> The MUX framework is already in linux-next. Could you use that instead of
> adding new driver + bindings that are not compliant with the MUX framework?
> I don't think it'd be much of a change in terms of code, using the MUX
> framework appears quite simple.

It is not quite clear to me how to design the DT bindings for this. Just
splitting the video-multiplexer driver from the mux-mmio / mux-gpio
would make it necessary to keep the video-multiplexer node to describe
the of-graph bindings. But then we have two different nodes in the DT
that describe the same hardware:

	mux: mux {
		compatible = "mux-gpio";
		mux-gpios = <&gpio 0>, <&gpio 1>;
		#mux-control-cells = <0>;
	}

	video-multiplexer {
		compatible = "video-multiplexer"
		mux-controls = <&mux>;

		ports {
			/* ... */
		}
	}

It would feel more natural to have the ports in the mux node, but then
how would the video-multiplexer driver be instanciated, and how would it
get to the of-graph nodes?

> In general the driver looks pretty good, especially regarding the user space
> API implementation which is important for use with other drivers.
> 
> I have some more detailed comments below.
> 
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > 
> > - fixed a cut&paste error in vidsw_remove(): v4l2_async_register_subdev()
> >   should be unregister.
> > 
> > - added media_entity_cleanup() to vidsw_remove().
> > 
> > - added missing MODULE_DEVICE_TABLE().
> >   Suggested-by: Javier Martinez Canillas <javier@dowhile0.org>
> > 
> > - there was a line left over from a previous iteration that negated
> >   the new way of determining the pad count just before it which
> >   has been removed (num_pads = of_get_child_count(np)).
> > 
> > - removed [gs]_frame_interval ops. timeperframe is not used anywhwere
> >   in this subdev, and currently it has no control over frame rate.
> > 
> > - add link_validate to media_entity_operations.
> > 
> > - moved devicetree binding doc to a separate commit.
> > 
> > - Philipp Zabel has developed a set of patches that allow adding
> >   to the subdev async notifier waiting list using a chaining method
> >   from the async registered callbacks (v4l2_of_subdev_registered()
> >   and the prep patches for that). For now, I've removed the use of
> >   v4l2_of_subdev_registered() for the vidmux driver's registered
> >   callback. This doesn't affect the functionality of this driver,
> >   but allows for it to be merged now, before adding the chaining
> >   support.
> > 
> > Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> > ---
> >  drivers/media/platform/Kconfig             |   8 +
> >  drivers/media/platform/Makefile            |   2 +
> >  drivers/media/platform/video-multiplexer.c | 451 +++++++++++++++++++++++++++++
> >  3 files changed, 461 insertions(+)
> >  create mode 100644 drivers/media/platform/video-multiplexer.c
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index ab0bb48..c9b8d9c 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -74,6 +74,14 @@ config VIDEO_M32R_AR_M64278
> >  	  To compile this driver as a module, choose M here: the
> >  	  module will be called arv.
> >  
> > +config VIDEO_MULTIPLEXER
> > +	tristate "Video Multiplexer"
> > +	depends on VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
> > +	help
> > +	  This driver provides support for SoC internal N:1 video bus
> > +	  multiplexers controlled by register bitfields as well as external
> > +	  2:1 video multiplexers controlled by a single GPIO.
> > +
> >  config VIDEO_OMAP3
> >  	tristate "OMAP 3 Camera support"
> >  	depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
> > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > index 8959f6e..d418add 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_SH_VEU)		+= sh_veu.o
> >  
> >  obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)	+= m2m-deinterlace.o
> >  
> > +obj-$(CONFIG_VIDEO_MULTIPLEXER)		+= video-multiplexer.o
> > +
> >  obj-$(CONFIG_VIDEO_S3C_CAMIF) 		+= s3c-camif/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) 	+= exynos4-is/
> >  obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG)	+= s5p-jpeg/
> > diff --git a/drivers/media/platform/video-multiplexer.c b/drivers/media/platform/video-multiplexer.c
> > new file mode 100644
> > index 0000000..b18c317
> > --- /dev/null
> > +++ b/drivers/media/platform/video-multiplexer.c
> > @@ -0,0 +1,451 @@
> > +/*
> > + * video stream multiplexer controlled via gpio or syscon
> > + *
> > + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> > + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version 2
> > + * of the License, or (at your option) any later version.
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_graph.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/regmap.h>
> > +#include <media/v4l2-async.h>
> > +#include <media/v4l2-device.h>
> > +#include <media/v4l2-subdev.h>
> > +#include <media/v4l2-of.h>
> > +
> > +struct vidsw {
> > +	struct v4l2_subdev subdev;
> > +	unsigned int num_pads;
> 
> You could use subdev.entity.num_pads instead of caching the value locally.

Ok, I'll change this.

> > +	struct media_pad *pads;
> > +	struct v4l2_mbus_framefmt *format_mbus;
> > +	struct v4l2_of_endpoint *endpoint;
> > +	struct regmap_field *field;
> > +	struct gpio_desc *gpio;
> > +	int active;
> > +};
> > +
> > +static inline struct vidsw *v4l2_subdev_to_vidsw(struct v4l2_subdev *sd)
> > +{
> > +	return container_of(sd, struct vidsw, subdev);
> > +}
> > +
> > +static void vidsw_set_active(struct vidsw *vidsw, int active)
> > +{
> > +	vidsw->active = active;
> > +	if (active < 0)
> > +		return;
> > +
> > +	dev_dbg(vidsw->subdev.dev, "setting %d active\n", active);
> > +
> > +	if (vidsw->field)
> > +		regmap_field_write(vidsw->field, active);
> > +	else if (vidsw->gpio)
> > +		gpiod_set_value(vidsw->gpio, active);
> > +}
> > +
> > +static int vidsw_link_setup(struct media_entity *entity,
> > +			    const struct media_pad *local,
> > +			    const struct media_pad *remote, u32 flags)
> > +{
> > +	struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +
> > +	/* We have no limitations on enabling or disabling our output link */
> > +	if (local->index == vidsw->num_pads - 1)
> > +		return 0;
> > +
> > +	dev_dbg(sd->dev, "link setup %s -> %s", remote->entity->name,
> > +		local->entity->name);
> > +
> > +	if (!(flags & MEDIA_LNK_FL_ENABLED)) {
> > +		if (local->index == vidsw->active) {
> > +			dev_dbg(sd->dev, "going inactive\n");
> > +			vidsw->active = -1;
> > +		}
> > +		return 0;
> > +	}
> > +
> > +	if (vidsw->active >= 0) {
> > +		struct media_pad *pad;
> > +
> > +		if (vidsw->active == local->index)
> > +			return 0;
> > +
> > +		pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
> > +		if (pad) {
> > +			struct media_link *link;
> > +			int ret;
> > +
> > +			link = media_entity_find_link(pad,
> > +						&vidsw->pads[vidsw->active]);
> > +			if (link) {
> > +				ret = __media_entity_setup_link(link, 0);
> 
> I wouldn't implicitly disable a link, even if only one can be active at a
> given time. No other drivers do that either.
> 
> Perhaps returning an error might be a better thing to do: if you're
> reconfiguring the pipeline anyway, there are likely issues elsewhere in it.
> 
> We could also change the behaviour later to allow implicit changes but we
> can't later on go the other way without breaking the user space.

Fair enough, I'll drop this.

> > +				if (ret)
> > +					return ret;
> > +			}
> > +		}
> > +	}
> > +
> > +	vidsw_set_active(vidsw, local->index);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct media_entity_operations vidsw_ops = {
> > +	.link_setup = vidsw_link_setup,
> > +	.link_validate = v4l2_subdev_link_validate,
> > +};
> > +
> > +static bool vidsw_endpoint_disabled(struct device_node *ep)
> > +{
> > +	struct device_node *rpp;
> > +
> > +	if (!of_device_is_available(ep))
> 
> ep here is the endpoint, whereas the argument to of_device_is_available()
> should correspond to the actual device.

Well, this was a convenience to allow adding status = "disabled" to
endpoints to turn them off (see the function name). I

> > +		return true;
> > +
> > +	rpp = of_graph_get_remote_port_parent(ep);
> > +	if (!rpp)
> > +		return true;
> > +
> > +	return !of_device_is_available(rpp);
> > +}
> > +
> > +static int vidsw_async_init(struct vidsw *vidsw, struct device_node *node)
> 
> I think I'd arrange this closer to probe as it's related to probe directly.
> Up to you.

I'll change this to
	rpp = of_graph_get_remote_port_parent(ep);
	return !of_device_is_available(rpp);
as Steve suggested.

> > +{
> > +	struct device_node *ep;
> > +	u32 portno;
> > +	int numports;
> > +	int ret;
> > +	int i;
> > +	bool active_link = false;
> > +
> > +	numports = vidsw->num_pads;
> > +
> > +	for (i = 0; i < numports - 1; i++)
> > +		vidsw->pads[i].flags = MEDIA_PAD_FL_SINK;
> > +	vidsw->pads[numports - 1].flags = MEDIA_PAD_FL_SOURCE;
> > +
> > +	vidsw->subdev.entity.function = MEDIA_ENT_F_VID_MUX;
> > +	ret = media_entity_pads_init(&vidsw->subdev.entity, numports,
> > +				     vidsw->pads);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	vidsw->subdev.entity.ops = &vidsw_ops;
> > +
> > +	for_each_endpoint_of_node(node, ep) {
> > +		struct v4l2_of_endpoint endpoint;
> > +
> > +		v4l2_of_parse_endpoint(ep, &endpoint);
> > +
> > +		portno = endpoint.base.port;
> > +		if (portno >= numports - 1)
> > +			continue;
> > +
> > +		if (vidsw_endpoint_disabled(ep)) {
> > +			dev_dbg(vidsw->subdev.dev,
> > +				"port %d disabled\n", portno);
> > +			continue;
> > +		}
> > +
> > +		vidsw->endpoint[portno] = endpoint;
> > +
> > +		if (portno == vidsw->active)
> > +			active_link = true;
> > +	}
> > +
> > +	for (portno = 0; portno < numports - 1; portno++) {
> > +		if (!vidsw->endpoint[portno].base.local_node)
> > +			continue;
> > +
> > +		/* If the active input is not connected, use another */
> > +		if (!active_link) {
> > +			vidsw_set_active(vidsw, portno);
> > +			active_link = true;
> > +		}
> > +	}
> > +
> > +	return v4l2_async_register_subdev(&vidsw->subdev);
> > +}
> > +
> > +int vidsw_g_mbus_config(struct v4l2_subdev *sd, struct v4l2_mbus_config *cfg)
> 
> We should get rid of g_mbus_config() in the long run, but as we don't have
> the alternative (frame descriptors) isn't up to the job yet I guess it's ok.
> I don't think we'll have too many users for the video switch right now.

Ok, we can add a comment to mark this as undesirable.

> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct media_pad *pad;
> > +	int ret;
> > +
> > +	if (vidsw->active == -1) {
> > +		dev_err(sd->dev, "no configuration for inactive mux\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	/*
> > +	 * Retrieve media bus configuration from the entity connected to the
> > +	 * active input
> > +	 */
> > +	pad = media_entity_remote_pad(&vidsw->pads[vidsw->active]);
> > +	if (pad) {
> > +		sd = media_entity_to_v4l2_subdev(pad->entity);
> > +		ret = v4l2_subdev_call(sd, video, g_mbus_config, cfg);
> > +		if (ret == -ENOIOCTLCMD)
> > +			pad = NULL;
> > +		else if (ret < 0) {
> > +			dev_err(sd->dev, "failed to get source configuration\n");
> > +			return ret;
> > +		}
> > +	}
> > +	if (!pad) {
> > +		/* Mirror the input side on the output side */
> > +		cfg->type = vidsw->endpoint[vidsw->active].bus_type;
> > +		if (cfg->type == V4L2_MBUS_PARALLEL ||
> > +		    cfg->type == V4L2_MBUS_BT656)
> > +			cfg->flags = vidsw->endpoint[vidsw->active].bus.parallel.flags;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_s_stream(struct v4l2_subdev *sd, int enable)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct v4l2_subdev *upstream_sd;
> > +	struct media_pad *pad;
> > +
> > +	if (vidsw->active == -1) {
> > +		dev_err(sd->dev, "Can not start streaming on inactive mux\n");
> > +		return -EINVAL;
> > +	}
> > +
> > +	pad = media_entity_remote_pad(&sd->entity.pads[vidsw->active]);
> > +	if (!pad) {
> > +		dev_err(sd->dev, "Failed to find remote source pad\n");
> > +		return -ENOLINK;
> > +	}
> > +
> > +	if (!is_media_entity_v4l2_subdev(pad->entity)) {
> > +		dev_err(sd->dev, "Upstream entity is not a v4l2 subdev\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	upstream_sd = media_entity_to_v4l2_subdev(pad->entity);
> > +
> > +	return v4l2_subdev_call(upstream_sd, video, s_stream, enable);
> 
> Now that we'll have more than two drivers involved in the same pipeline it
> becomes necessary to define the behaviour of s_stream() throughout the
> pipeline --- i.e. whose responsibility is it to call s_stream() on the
> sub-devices in the pipeline?
> 
> I can submit a patch for that. I think the way you do it here is good, as it
> enables the caller to choose the appropriate behaviour, i.e. start the local
> device before or after the upstream sub-device.

Please do, this should be decided before any more complex inter-driver
pipelines show up.

> > +}
> > +
> > +static const struct v4l2_subdev_video_ops vidsw_subdev_video_ops = {
> > +	.g_mbus_config = vidsw_g_mbus_config,
> > +	.s_stream = vidsw_s_stream,
> > +};
> > +
> > +static struct v4l2_mbus_framefmt *
> > +__vidsw_get_pad_format(struct v4l2_subdev *sd,
> > +		       struct v4l2_subdev_pad_config *cfg,
> > +		       unsigned int pad, u32 which)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +
> > +	switch (which) {
> > +	case V4L2_SUBDEV_FORMAT_TRY:
> > +		return v4l2_subdev_get_try_format(sd, cfg, pad);
> > +	case V4L2_SUBDEV_FORMAT_ACTIVE:
> > +		return &vidsw->format_mbus[pad];
> > +	default:
> > +		return NULL;
> > +	}
> > +}
> > +
> > +static int vidsw_get_format(struct v4l2_subdev *sd,
> > +			    struct v4l2_subdev_pad_config *cfg,
> > +			    struct v4l2_subdev_format *sdformat)
> > +{
> > +	sdformat->format = *__vidsw_get_pad_format(sd, cfg, sdformat->pad,
> > +						   sdformat->which);
> > +	return 0;
> > +}
> > +
> > +static int vidsw_set_format(struct v4l2_subdev *sd,
> > +			    struct v4l2_subdev_pad_config *cfg,
> > +			    struct v4l2_subdev_format *sdformat)
> > +{
> > +	struct vidsw *vidsw = v4l2_subdev_to_vidsw(sd);
> > +	struct v4l2_mbus_framefmt *mbusformat;
> > +
> > +	if (sdformat->pad >= vidsw->num_pads)
> > +		return -EINVAL;
> 
> This check is already performed in v4l2-subdev.c.

Excellent.

> > +
> > +	mbusformat = __vidsw_get_pad_format(sd, cfg, sdformat->pad,
> > +					    sdformat->which);
> > +	if (!mbusformat)
> > +		return -EINVAL;
> > +
> > +	/* Output pad mirrors active input pad, no limitations on input pads */
> 
> Source and sink pads.

Ok.

> > +	if (sdformat->pad == (vidsw->num_pads - 1) && vidsw->active >= 0)
> 
> I think it'd be cleaner to test for the pad flag instead of the number. Or,
> add a macro to obtain the source pad number.
> 
> > +		sdformat->format = vidsw->format_mbus[vidsw->active];
> > +
> > +	*mbusformat = sdformat->format;
> > +
> > +	return 0;
> > +}
> > +
> > +static struct v4l2_subdev_pad_ops vidsw_pad_ops = {
> > +	.get_fmt = vidsw_get_format,
> > +	.set_fmt = vidsw_set_format,
> > +};
> > +
> > +static struct v4l2_subdev_ops vidsw_subdev_ops = {
> > +	.pad = &vidsw_pad_ops,
> > +	.video = &vidsw_subdev_video_ops,
> > +};
> > +
> > +static int of_get_reg_field(struct device_node *node, struct reg_field *field)
> > +{
> > +	u32 bit_mask;
> > +	int ret;
> > +
> > +	ret = of_property_read_u32(node, "reg", &field->reg);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(node, "bit-mask", &bit_mask);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = of_property_read_u32(node, "bit-shift", &field->lsb);
> > +	if (ret < 0)
> > +		return ret;
> 
> I think the above would look nice in a MUX driver. :-)

I'll submit an MMIO / syscon / regmap bitfield mux driver.

> > +
> > +	field->msb = field->lsb + fls(bit_mask) - 1;
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_probe(struct platform_device *pdev)
> > +{
> > +	struct device_node *np = pdev->dev.of_node;
> > +	struct of_endpoint endpoint;
> > +	struct device_node *ep;
> > +	struct reg_field field;
> > +	struct vidsw *vidsw;
> > +	struct regmap *map;
> > +	unsigned int num_pads;
> > +	int ret;
> > +
> > +	vidsw = devm_kzalloc(&pdev->dev, sizeof(*vidsw), GFP_KERNEL);
> > +	if (!vidsw)
> > +		return -ENOMEM;
> > +
> > +	platform_set_drvdata(pdev, vidsw);
> > +
> > +	v4l2_subdev_init(&vidsw->subdev, &vidsw_subdev_ops);
> > +	snprintf(vidsw->subdev.name, sizeof(vidsw->subdev.name), "%s",
> > +			np->name);
> > +	vidsw->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > +	vidsw->subdev.dev = &pdev->dev;
> > +
> > +	/*
> > +	 * The largest numbered port is the output port. It determines
> > +	 * total number of pads
> > +	 */
> > +	num_pads = 0;
> 
> You can initialise num_pads in variable declaration.
> 
> > +	for_each_endpoint_of_node(np, ep) {
> > +		of_graph_parse_endpoint(ep, &endpoint);
> > +		num_pads = max(num_pads, endpoint.port + 1);
> 
> Port numbers come directly from DT.
> 
> Shouldn't num_pads be only the number of pads that have links with actual
> physical connections? I.e. if a device is disabled, it shouldn't be
> counted here.

If we only create media pads for the connected DT ports with available
remote device, there is no 1:1 correspondence between pad number and the
physical mux setting anymore, complicating the driver.

> > +	}
> > +
> > +	if (num_pads < 2) {
> > +		dev_err(&pdev->dev, "Not enough ports %d\n", num_pads);
> > +		return -EINVAL;
> > +	}
> > +
> > +	ret = of_get_reg_field(np, &field);
> > +	if (ret == 0) {
> > +		map = syscon_node_to_regmap(np->parent);
> > +		if (!map) {
> > +			dev_err(&pdev->dev, "Failed to get syscon register map\n");
> > +			return PTR_ERR(map);
> > +		}
> > +
> > +		vidsw->field = devm_regmap_field_alloc(&pdev->dev, map, field);
> > +		if (IS_ERR(vidsw->field)) {
> > +			dev_err(&pdev->dev, "Failed to allocate regmap field\n");
> > +			return PTR_ERR(vidsw->field);
> > +		}
> > +
> > +		regmap_field_read(vidsw->field, &vidsw->active);
> > +	} else {
> > +		if (num_pads > 3) {
> > +			dev_err(&pdev->dev, "Too many ports %d\n", num_pads);
> > +			return -EINVAL;
> > +		}
> > +
> > +		vidsw->gpio = devm_gpiod_get(&pdev->dev, NULL, GPIOD_OUT_LOW);
> > +		if (IS_ERR(vidsw->gpio)) {
> > +			dev_warn(&pdev->dev,
> > +				 "could not request control gpio: %d\n", ret);
> > +			vidsw->gpio = NULL;
> > +		}
> > +
> > +		vidsw->active = gpiod_get_value(vidsw->gpio) ? 1 : 0;
> > +	}
> > +
> > +	vidsw->num_pads = num_pads;
> > +	vidsw->pads = devm_kzalloc(&pdev->dev, sizeof(*vidsw->pads) * num_pads,
> > +			GFP_KERNEL);
> > +	vidsw->format_mbus = devm_kzalloc(&pdev->dev,
> > +			sizeof(*vidsw->format_mbus) * num_pads, GFP_KERNEL);
> > +	vidsw->endpoint = devm_kzalloc(&pdev->dev,
> > +			sizeof(*vidsw->endpoint) * (num_pads - 1), GFP_KERNEL);
> > +
> > +	ret = vidsw_async_init(vidsw, np);
> > +	if (ret)
> > +		return ret;
> > +
> > +	return 0;
> > +}
> > +
> > +static int vidsw_remove(struct platform_device *pdev)
> > +{
> > +	struct vidsw *vidsw = platform_get_drvdata(pdev);
> > +	struct v4l2_subdev *sd = &vidsw->subdev;
> > +
> > +	v4l2_async_unregister_subdev(sd);
> > +	media_entity_cleanup(&sd->entity);
> > +
> > +	return 0;
> > +}
> > +
> > +static const struct of_device_id vidsw_dt_ids[] = {
> > +	{ .compatible = "video-multiplexer", },
> > +	{ /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, vidsw_dt_ids);
> > +
> > +static struct platform_driver vidsw_driver = {
> > +	.probe		= vidsw_probe,
> > +	.remove		= vidsw_remove,
> > +	.driver		= {
> > +		.of_match_table = vidsw_dt_ids,
> > +		.name = "video-multiplexer",
> > +	},
> > +};
> > +
> > +module_platform_driver(vidsw_driver);
> > +
> > +MODULE_DESCRIPTION("video stream multiplexer");
> > +MODULE_AUTHOR("Sascha Hauer, Pengutronix");
> > +MODULE_AUTHOR("Philipp Zabel, Pengutronix");
> > +MODULE_LICENSE("GPL");

regards
Philipp

  parent reply	other threads:[~2017-04-13 13:53 UTC|newest]

Thread overview: 286+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28  0:40 [PATCH v6 00/39] i.MX Media Driver Steve Longerbeam
2017-03-28  0:40 ` Steve Longerbeam
2017-03-28  0:40 ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 01/39] [media] dt-bindings: Add bindings for video-multiplexer device Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-04-03 14:14   ` Rob Herring
2017-04-03 14:14     ` Rob Herring
2017-04-03 14:14     ` Rob Herring
2017-03-28  0:40 ` [PATCH v6 02/39] [media] dt-bindings: Add bindings for i.MX media driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-29  0:21   ` Rob Herring
2017-03-29  0:21     ` Rob Herring
2017-03-29  0:21     ` Rob Herring
2017-03-29  0:35     ` Steve Longerbeam
2017-03-29  0:35       ` Steve Longerbeam
2017-03-29  0:35       ` Steve Longerbeam
2017-04-03 14:07       ` Rob Herring
2017-04-03 14:07         ` Rob Herring
2017-04-03 14:07         ` Rob Herring
2017-04-03 15:15         ` Russell King - ARM Linux
2017-04-03 15:15           ` Russell King - ARM Linux
2017-04-03 15:15           ` Russell King - ARM Linux
2017-03-29  8:39     ` Russell King - ARM Linux
2017-03-29  8:39       ` Russell King - ARM Linux
2017-03-29  8:39       ` Russell King - ARM Linux
2017-04-03 14:11       ` Rob Herring
2017-04-03 14:11         ` Rob Herring
2017-04-03 14:11         ` Rob Herring
2017-04-03 15:03         ` Russell King - ARM Linux
2017-04-03 15:03           ` Russell King - ARM Linux
2017-04-03 15:03           ` Russell King - ARM Linux
2017-03-28  0:40 ` [PATCH v6 03/39] [media] dt/bindings: Add bindings for OV5640 Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-04-03 14:15   ` Rob Herring
2017-04-03 14:15     ` Rob Herring
2017-04-03 14:15     ` Rob Herring
2017-03-28  0:40 ` [PATCH v6 04/39] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 05/39] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 06/39] ARM: dts: imx6qdl: add capture-subsystem device Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 08/39] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 09/39] ARM: dts: imx6-sabresd: " Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 10/39] ARM: dts: imx6-sabreauto: create i2cmux for i2c3 Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 11/39] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 12/39] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 13/39] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 14/39] add mux and video interface bridge entity functions Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 15/39] [media] v4l2-mc: add a function to inherit controls from a pipeline Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 16/39] [media] add Omnivision OV5640 sensor driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 17/39] platform: add video-multiplexer subdevice driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28 14:12   ` Vladimir Zapolskiy
2017-03-28 14:12     ` Vladimir Zapolskiy
2017-03-28 14:12     ` Vladimir Zapolskiy
2017-04-04 12:47   ` Sakari Ailus
2017-04-04 12:47     ` Sakari Ailus
2017-04-04 12:47     ` Sakari Ailus
2017-04-12  0:50     ` Steve Longerbeam
2017-04-12  0:50       ` Steve Longerbeam
2017-04-12  0:50       ` Steve Longerbeam
2017-04-12  9:09       ` Sakari Ailus
2017-04-12  9:09         ` Sakari Ailus
2017-04-12  9:09         ` Sakari Ailus
2017-04-13 13:52     ` Philipp Zabel [this message]
2017-04-13 13:52       ` Philipp Zabel
2017-04-13 13:52       ` Philipp Zabel
2017-04-14 20:32       ` Pavel Machek
2017-04-14 20:32         ` Pavel Machek
2017-04-14 20:32         ` Pavel Machek
2017-04-18  8:09         ` Philipp Zabel
2017-04-18  8:09           ` Philipp Zabel
2017-04-18  8:09           ` Philipp Zabel
2017-04-18  9:05           ` Pavel Machek
2017-04-18  9:05             ` Pavel Machek
2017-04-18  9:05             ` Pavel Machek
2017-04-05 11:18   ` Pavel Machek
2017-04-05 11:18     ` Pavel Machek
2017-04-05 11:18     ` Pavel Machek
2017-04-05 11:58     ` Lucas Stach
2017-04-05 11:58       ` Lucas Stach
2017-04-05 11:58       ` Lucas Stach
2017-04-05 18:05       ` Pavel Machek
2017-04-05 18:05         ` Pavel Machek
2017-04-05 18:05         ` Pavel Machek
2017-03-28  0:40 ` [PATCH v6 18/39] media: Add userspace header file for i.MX Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 19/39] media: Add i.MX media core driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-30 17:25   ` [RFC] [media] imx: assume MEDIA_ENT_F_ATV_DECODER entities output video on pad 1 Philipp Zabel
2017-03-30 17:25     ` Philipp Zabel
2017-04-04 22:11     ` Steve Longerbeam
2017-04-04 22:11       ` Steve Longerbeam
2017-04-04 22:11       ` Steve Longerbeam
2017-04-05  9:43       ` Philipp Zabel
2017-04-05  9:43         ` Philipp Zabel
2017-04-05  9:43         ` Philipp Zabel
2017-04-04 23:10     ` Russell King - ARM Linux
2017-04-04 23:10       ` Russell King - ARM Linux
2017-04-04 23:10       ` Russell King - ARM Linux
2017-04-05  0:40       ` Steve Longerbeam
2017-04-05  0:40         ` Steve Longerbeam
2017-04-05  0:40         ` Steve Longerbeam
2017-04-05  0:44         ` Steve Longerbeam
2017-04-05  0:44           ` Steve Longerbeam
2017-04-05  0:44           ` Steve Longerbeam
2017-04-05  8:21           ` Russell King - ARM Linux
2017-04-05  8:21             ` Russell King - ARM Linux
2017-04-05  8:21             ` Russell King - ARM Linux
2017-04-05  9:34             ` Philipp Zabel
2017-04-05  9:34               ` Philipp Zabel
2017-04-05  9:34               ` Philipp Zabel
2017-04-05 13:55               ` Javier Martinez Canillas
2017-04-05 13:55                 ` Javier Martinez Canillas
2017-04-05 13:55                 ` Javier Martinez Canillas
2017-04-05 13:55                 ` Javier Martinez Canillas
2017-04-05 14:53               ` Mauro Carvalho Chehab
2017-04-05 14:53                 ` Mauro Carvalho Chehab
2017-04-05 14:53                 ` Mauro Carvalho Chehab
2017-04-05 15:39                 ` Devin Heitmueller
2017-04-05 15:39                   ` Devin Heitmueller
2017-04-05 15:39                   ` Devin Heitmueller
2017-04-05 16:17                   ` Mauro Carvalho Chehab
2017-04-05 16:17                     ` Mauro Carvalho Chehab
2017-04-05 16:17                     ` Mauro Carvalho Chehab
2017-04-05 17:02                     ` Devin Heitmueller
2017-04-05 17:02                       ` Devin Heitmueller
2017-04-05 17:02                       ` Devin Heitmueller
2017-04-05 17:16                       ` Mauro Carvalho Chehab
2017-04-05 17:16                         ` Mauro Carvalho Chehab
2017-04-05 17:16                         ` Mauro Carvalho Chehab
2017-04-06  9:57                 ` Philipp Zabel
2017-04-06  9:57                   ` Philipp Zabel
2017-04-06  9:57                   ` Philipp Zabel
2017-04-05 11:32   ` [PATCH v6 19/39] media: Add i.MX media core driver Pavel Machek
2017-04-05 11:32     ` Pavel Machek
2017-04-05 11:32     ` Pavel Machek
2017-04-05 11:34   ` Pavel Machek
2017-04-05 11:34     ` Pavel Machek
2017-04-05 11:34     ` Pavel Machek
2017-04-06  9:43   ` Philipp Zabel
2017-04-06  9:43     ` Philipp Zabel
2017-04-06  9:43     ` Philipp Zabel
2017-04-06 23:51     ` Steve Longerbeam
2017-04-06 23:51       ` Steve Longerbeam
2017-04-06 23:51       ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 20/39] media: imx: Add Capture Device Interface Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 21/39] media: imx: Add CSI subdev driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-04-06 13:55   ` [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default Philipp Zabel
2017-04-06 13:55     ` Philipp Zabel
2017-04-06 13:55     ` Philipp Zabel
2017-04-06 14:05     ` Russell King - ARM Linux
2017-04-06 14:05       ` Russell King - ARM Linux
2017-04-06 14:05       ` Russell King - ARM Linux
2017-04-06 15:01       ` Philipp Zabel
2017-04-06 15:01         ` Philipp Zabel
2017-04-06 15:01         ` Philipp Zabel
2017-04-06 15:10         ` Russell King - ARM Linux
2017-04-06 15:10           ` Russell King - ARM Linux
2017-04-06 15:10           ` Russell King - ARM Linux
2017-04-06 15:25           ` Philipp Zabel
2017-04-06 15:25             ` Philipp Zabel
2017-04-06 15:25             ` Philipp Zabel
2017-04-13  0:33             ` Steve Longerbeam
2017-04-13  0:33               ` Steve Longerbeam
2017-04-13  0:33               ` Steve Longerbeam
2017-04-13  0:45               ` [PATCH 40/40] media: imx: set and propagate empty field, colorimetry params Steve Longerbeam
2017-04-13 10:09                 ` Philipp Zabel
2017-04-13 16:40                   ` Steve Longerbeam
2017-04-18  9:30                     ` Philipp Zabel
2017-05-08  9:41                 ` Philipp Zabel
2017-05-09  3:44                   ` Steve Longerbeam
2017-04-06 14:20     ` [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default Hans Verkuil
2017-04-06 14:20       ` Hans Verkuil
2017-04-06 14:20       ` Hans Verkuil
2017-04-06 14:38       ` Russell King - ARM Linux
2017-04-06 14:38         ` Russell King - ARM Linux
2017-04-06 14:38         ` Russell King - ARM Linux
2017-04-06 14:54       ` Philipp Zabel
2017-04-06 14:54         ` Philipp Zabel
2017-04-06 14:54         ` Philipp Zabel
2017-04-06 15:43         ` Hans Verkuil
2017-04-06 15:43           ` Hans Verkuil
2017-04-06 15:43           ` Hans Verkuil
2017-04-06 16:01           ` Philipp Zabel
2017-04-06 16:01             ` Philipp Zabel
2017-04-06 16:01             ` Philipp Zabel
2017-04-12  7:03             ` Hans Verkuil
2017-04-12  7:03               ` Hans Verkuil
2017-04-12  7:03               ` Hans Verkuil
2017-04-13 10:07               ` Philipp Zabel
2017-04-13 10:07                 ` Philipp Zabel
2017-04-13 10:07                 ` Philipp Zabel
2017-04-06 15:18       ` Philipp Zabel
2017-04-06 15:18         ` Philipp Zabel
2017-04-06 15:18         ` Philipp Zabel
2017-05-08  8:27     ` Hans Verkuil
2017-05-08  8:27       ` Hans Verkuil
2017-05-08  8:27       ` Hans Verkuil
2017-05-08  9:36       ` Philipp Zabel
2017-05-08  9:36         ` Philipp Zabel
2017-05-08  9:36         ` Philipp Zabel
2017-05-08 10:12         ` Hans Verkuil
2017-05-08 10:12           ` Hans Verkuil
2017-05-08 10:12           ` Hans Verkuil
2017-03-28  0:40 ` [PATCH v6 22/39] media: imx: Add VDIC subdev driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 23/39] media: imx: Add IC subdev drivers Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 24/39] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 25/39] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 26/39] media: imx: add support for bayer formats Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 27/39] media: imx: csi: " Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 28/39] media: imx: csi: fix crop rectangle changes in set_fmt Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 29/39] media: imx: csi: add __csi_get_fmt Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 30/39] media: imx: csi/fim: add support for frame intervals Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 31/39] media: imx: redo pixel format enumeration and negotiation Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 32/39] media: imx: csi: add frame skipping support Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 33/39] media: imx: csi: Avoid faulty sensor frames at stream start Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 34/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 35/39] media: imx: propagate sink pad formats to source pads Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 36/39] media: imx: csi: add sink selection rectangles Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 37/39] media: imx-csi: add frame size/interval enumeration Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 38/39] media: imx-ic-prpencvf: add frame size enumeration Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-28  0:40 ` [PATCH v6 39/39] media: imx-media-capture: add frame sizes/interval enumeration Steve Longerbeam
2017-03-28  0:40   ` Steve Longerbeam
2017-03-30 11:02 ` [PATCH v6 00/39] i.MX Media Driver Russell King - ARM Linux
2017-03-30 11:02   ` Russell King - ARM Linux
2017-03-30 11:02   ` Russell King - ARM Linux
2017-03-30 16:12   ` Steve Longerbeam
2017-03-30 16:12     ` Steve Longerbeam
2017-03-30 16:12     ` Steve Longerbeam
2017-03-30 16:27     ` Russell King - ARM Linux
2017-03-30 16:27       ` Russell King - ARM Linux
2017-03-30 16:27       ` Russell King - ARM Linux

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=1492091578.2383.39.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=andrew-ct.chen@mediatek.com \
    --cc=arnd@arndb.de \
    --cc=bparrot@ti.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=fabio.estevam@nxp.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms+renesas@verge.net.au \
    --cc=hverkuil@xs4all.nl \
    --cc=jean-christophe.trotin@st.com \
    --cc=kernel@pengutronix.de \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=markus.heiser@darmarIT.de \
    --cc=mchehab@kernel.org \
    --cc=minghsiu.tsai@mediatek.com \
    --cc=nick@shmanahar.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=pavel@ucw.cz \
    --cc=robert.jarzmik@free.fr \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=sakari.ailus@iki.fi \
    --cc=sakari.ailus@linux.intel.com \
    --cc=shawnguo@kernel.org \
    --cc=shuah@kernel.org \
    --cc=slongerbeam@gmail.com \
    --cc=songjun.wu@microchip.com \
    --cc=steve_longerbeam@mentor.com \
    --cc=sudipm.mukherjee@gmail.com \
    --cc=tiffany.lin@mediatek.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 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.