All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Longerbeam <slongerbeam@gmail.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: 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,
	p.zabel@pengutronix.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: Tue, 11 Apr 2017 17:50:58 -0700	[thread overview]
Message-ID: <e7368555-1644-4e8f-f355-6b07dc020f90@gmail.com> (raw)
In-Reply-To: <20170404124732.GD3288@valkosipuli.retiisi.org.uk>



On 04/04/2017 05:47 AM, 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.

I would prefer to wait on this, and get what we have merged now so I can
unload all these patches first.

Also this is Philipp's driver, so again I would prefer to get this
merged as-is and then Philipp can address these issues in a future
patch. But I will add my comments below...


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

<snip>

>> +
>> +struct vidsw {
>> +	struct v4l2_subdev subdev;
>> +	unsigned int num_pads;
>
> You could use subdev.entity.num_pads instead of caching the value locally.

Agreed.

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

I think this whole if (vidsw->active >= 0) { ... } block should be
removed. This is left-over from the first implementation that tried
to propagate link setup upstream. This is not working yet, so for now
I think this should be removed.

<snip>

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

Agreed, I think this if statement should be removed, and...

>
>> +		return true;
>> +
>> +	rpp = of_graph_get_remote_port_parent(ep);
>> +	if (!rpp)
>> +		return true;

this if statement can also be removed, since that is
handled automatically by of_device_is_available() below.

>> +
>> +	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.
>
>> +{
>> +	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.
>
>> +{
>> +	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?

In the case of imx-media, the capture device calls set stream on the
whole pipeline in the start_streaming() callback. This subdev call is
actually a NOOP for imx-media, because the upstream entity has already
started streaming. Again I think this should be removed. It also
enforces a stream order that some MC drivers may have a problem with.

For the remaining comments I'll let Philipp respond.

Steve


>
> 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.
>
>> +}
>> +
>> +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.
>
>> +
>> +	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.
>
>> +	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. :-)
>
>> +
>> +	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 (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");
>

WARNING: multiple messages have this Message-ID (diff)
From: Steve Longerbeam <slongerbeam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>
Cc: 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,
	p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-me
Subject: Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Date: Tue, 11 Apr 2017 17:50:58 -0700	[thread overview]
Message-ID: <e7368555-1644-4e8f-f355-6b07dc020f90@gmail.com> (raw)
In-Reply-To: <20170404124732.GD3288-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>



On 04/04/2017 05:47 AM, 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.

I would prefer to wait on this, and get what we have merged now so I can
unload all these patches first.

Also this is Philipp's driver, so again I would prefer to get this
merged as-is and then Philipp can address these issues in a future
patch. But I will add my comments below...


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

<snip>

>> +
>> +struct vidsw {
>> +	struct v4l2_subdev subdev;
>> +	unsigned int num_pads;
>
> You could use subdev.entity.num_pads instead of caching the value locally.

Agreed.

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

I think this whole if (vidsw->active >= 0) { ... } block should be
removed. This is left-over from the first implementation that tried
to propagate link setup upstream. This is not working yet, so for now
I think this should be removed.

<snip>

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

Agreed, I think this if statement should be removed, and...

>
>> +		return true;
>> +
>> +	rpp = of_graph_get_remote_port_parent(ep);
>> +	if (!rpp)
>> +		return true;

this if statement can also be removed, since that is
handled automatically by of_device_is_available() below.

>> +
>> +	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.
>
>> +{
>> +	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.
>
>> +{
>> +	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?

In the case of imx-media, the capture device calls set stream on the
whole pipeline in the start_streaming() callback. This subdev call is
actually a NOOP for imx-media, because the upstream entity has already
started streaming. Again I think this should be removed. It also
enforces a stream order that some MC drivers may have a problem with.

For the remaining comments I'll let Philipp respond.

Steve


>
> 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.
>
>> +}
>> +
>> +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.
>
>> +
>> +	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.
>
>> +	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. :-)
>
>> +
>> +	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 (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");
>
--
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: slongerbeam@gmail.com (Steve Longerbeam)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Date: Tue, 11 Apr 2017 17:50:58 -0700	[thread overview]
Message-ID: <e7368555-1644-4e8f-f355-6b07dc020f90@gmail.com> (raw)
In-Reply-To: <20170404124732.GD3288@valkosipuli.retiisi.org.uk>



On 04/04/2017 05:47 AM, 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.

I would prefer to wait on this, and get what we have merged now so I can
unload all these patches first.

Also this is Philipp's driver, so again I would prefer to get this
merged as-is and then Philipp can address these issues in a future
patch. But I will add my comments below...


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

<snip>

>> +
>> +struct vidsw {
>> +	struct v4l2_subdev subdev;
>> +	unsigned int num_pads;
>
> You could use subdev.entity.num_pads instead of caching the value locally.

Agreed.

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

I think this whole if (vidsw->active >= 0) { ... } block should be
removed. This is left-over from the first implementation that tried
to propagate link setup upstream. This is not working yet, so for now
I think this should be removed.

<snip>

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

Agreed, I think this if statement should be removed, and...

>
>> +		return true;
>> +
>> +	rpp = of_graph_get_remote_port_parent(ep);
>> +	if (!rpp)
>> +		return true;

this if statement can also be removed, since that is
handled automatically by of_device_is_available() below.

>> +
>> +	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.
>
>> +{
>> +	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.
>
>> +{
>> +	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?

In the case of imx-media, the capture device calls set stream on the
whole pipeline in the start_streaming() callback. This subdev call is
actually a NOOP for imx-media, because the upstream entity has already
started streaming. Again I think this should be removed. It also
enforces a stream order that some MC drivers may have a problem with.

For the remaining comments I'll let Philipp respond.

Steve


>
> 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.
>
>> +}
>> +
>> +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.
>
>> +
>> +	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.
>
>> +	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. :-)
>
>> +
>> +	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 (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");
>

  reply	other threads:[~2017-04-12  0:51 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 [this message]
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
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=e7368555-1644-4e8f-f355-6b07dc020f90@gmail.com \
    --to=slongerbeam@gmail.com \
    --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=p.zabel@pengutronix.de \
    --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=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.