All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Hans Verkuil <hverkuil@xs4all.nl>
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, 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,
	Steve Longerbeam <steve_longerbeam@mentor.com>
Subject: Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
Date: Mon, 08 May 2017 11:36:47 +0200	[thread overview]
Message-ID: <1494236207.3029.66.camel@pengutronix.de> (raw)
In-Reply-To: <0632df59-10e7-1e03-c0f6-eb7c90b83c0d@xs4all.nl>

Hi Hans,

On Mon, 2017-05-08 at 10:27 +0200, Hans Verkuil wrote:
> Hi Philipp,
> 
> Sorry for the very long delay, but I finally had some time to think about this.

Thank you for your thoughts.

> On 04/06/2017 03:55 PM, Philipp Zabel wrote:
> > If the the field order is set to ANY in set_fmt, choose the currently
> > set field order. If the colorspace is set to DEFAULT, choose the current
> > colorspace.  If any of xfer_func, ycbcr_enc or quantization are set to
> > DEFAULT, either choose the current setting, or the default setting for the
> > new colorspace, if non-DEFAULT colorspace was given.
> > 
> > This allows to let field order and colorimetry settings be propagated
> > from upstream by calling media-ctl on the upstream entity source pad,
> > and then call media-ctl on the sink pad to manually set the input frame
> > interval, without changing the already set field order and colorimetry
> > information.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> > This is based on imx-media-staging-md-v14, and it is supposed to allow
> > configuring the pipeline with media-ctl like this:
> > 
> > 1) media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY8_1X16/1920x1080]"
> > 2) media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY8_1X16/1920x108]"
> > 3) media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080]"
> > 4) media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080@1/60]"
> > 5) media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080@1/30]"
> > 
> > Without having step 4) overwrite the colorspace and field order set on
> > 'ipu1_csi0':0 by the propagation in step 3).
> > ---
> >  drivers/staging/media/imx/imx-media-csi.c | 34 +++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> > 
> > diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
> > index 64dc454f6b371..d94ce1de2bf05 100644
> > --- a/drivers/staging/media/imx/imx-media-csi.c
> > +++ b/drivers/staging/media/imx/imx-media-csi.c
> > @@ -1325,6 +1325,40 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
> >  	csi_try_fmt(priv, sensor, cfg, sdformat, crop, compose, &cc);
> >  
> >  	fmt = __csi_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
> > +
> > +	/* Retain current field setting as default */
> > +	if (sdformat->format.field == V4L2_FIELD_ANY)
> > +		sdformat->format.field = fmt->field;
> 
> This is OK.

Would this be a "may" or a "should"? As in,
"If SUBDEV_S_FMT is called with field == ANY, the driver may/should set
field to the previously configured interlacing field order".

What would be the correct place to document this behaviour?
Documentation/media/uapi/v4l/vidioc-subdev-g-fmt.rst?

> > +	/* Retain current colorspace setting as default */
> > +	if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
> > +		sdformat->format.colorspace = fmt->colorspace;
> > +		if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT)
> > +			sdformat->format.xfer_func = fmt->xfer_func;
> > +		if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT)
> > +			sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
> > +		if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT)
> > +			sdformat->format.quantization = fmt->quantization;
> 
> If sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT, then you can just copy
> all four fields from fmt to sdformat->format. The other three fields are meaningless
> when colorspace == V4L2_COLORSPACE_DEFAULT.

Ok, good. Ignoring the transfer function / YCbCr encoding / quantization
range fields when colorspace is DEFAULT would simplify this part to:

	if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
		sdformat->format.colorspace = fmt->colorspace;
		sdformat->format.xfer_func = fmt->xfer_func;
		sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
		sdformat->format.quantization = fmt->quantization;
	}

Is that expectation already written down somewhere? If not, should we
add it to Documentation/media/uapi/v4l/pixfmt-006.rst?

> > +	} else {
> > +		if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT) {
> > +			sdformat->format.xfer_func =
> > +				V4L2_MAP_XFER_FUNC_DEFAULT(
> > +						sdformat->format.colorspace);
> > +		}
> > +		if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT) {
> > +			sdformat->format.ycbcr_enc =
> > +				V4L2_MAP_YCBCR_ENC_DEFAULT(
> > +						sdformat->format.colorspace);
> > +		}
> > +		if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT) {
> > +			sdformat->format.quantization =
> > +				V4L2_MAP_QUANTIZATION_DEFAULT(
> > +						cc->cs != IPUV3_COLORSPACE_YUV,
> > +						sdformat->format.colorspace,
> > +						sdformat->format.ycbcr_enc);
> > +		}
> 
> Is this needed for validation? Currently these fields play no role in the
> default link validation. Which I think is actually the right thing to do,
> unless the subdev can do actual colorspace conversion.

The CSI subdevice can't do colorspace conversion, but exactly the same
applies to the IC subdevices, which can. Also I'd like this information
to be correct, as the /dev/videoX capture device takes its colorspace
information from the CSI source pad.

The problem I wanted to solve here initially was that if the colorspace
information was previously set correctly:

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080@1/60 colorspace:rec709 xfer:709 ycbcr:709 quantization:lim-range]"
    ->
	V4L2_COLORSPACE_REC709
	V4L2_XFER_FUNC_709
	V4L2_YCBCR_ENC_709
	V4L2_QUANTIZATION_LIMITED_RANGE

A later media-ctl call to just change the frame interval would overwrite the colorspace information:

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080@1/30]"
    ->
	V4L2_COLORSPACE_DEFAULT
	V4L2_XFER_FUNC_DEFAULT
	V4L2_YCBCR_ENC_DEFAULT
	V4L2_QUANTIZATION_DEFAULT

> I would just drop the whole 'else' here.

That would allow to set the actual colorspace information reported by
SUBDEV_G_FMT on both sink and source pads (and by extension, the
colorspace information reported by G_FMT on /dev/videoX) to
V4L2_{XFER_FUNC,YCBCR_ENC,QUANTIZATION}_DEFAULT.

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 colorspace:rec709]"
    ->
	V4L2_COLORSPACE_REC709
	V4L2_XFER_FUNC_DEFAULT
	V4L2_YCBCR_ENC_DEFAULT
	V4L2_QUANTIZATION_DEFAULT

I suppose that is acceptable as given the colorspace, the other DEFAULT
values have a unique meaning, but wouldn't it be nicer to show userspace
what these default inputs actually map to?

> Actually, wouldn't it be better to always just copy this information from
> fmt? This subdev doesn't do any colorspace conversion, it just passes on
> this information. I.e., you can't set it in any meaningful way.

csi_set_fmt on the sink pad is the function that actually sets fmt in
the first place. If we always copy colorspace information from fmt, it
can't be set to the correct value at all.

regards
Philipp

WARNING: multiple messages have this Message-ID (diff)
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
To: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@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,
	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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-medi
Subject: Re: [PATCH] [media] imx: csi: retain current field order and colorimetry setting as default
Date: Mon, 08 May 2017 11:36:47 +0200	[thread overview]
Message-ID: <1494236207.3029.66.camel@pengutronix.de> (raw)
In-Reply-To: <0632df59-10e7-1e03-c0f6-eb7c90b83c0d-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>

Hi Hans,

On Mon, 2017-05-08 at 10:27 +0200, Hans Verkuil wrote:
> Hi Philipp,
> 
> Sorry for the very long delay, but I finally had some time to think about this.

Thank you for your thoughts.

> On 04/06/2017 03:55 PM, Philipp Zabel wrote:
> > If the the field order is set to ANY in set_fmt, choose the currently
> > set field order. If the colorspace is set to DEFAULT, choose the current
> > colorspace.  If any of xfer_func, ycbcr_enc or quantization are set to
> > DEFAULT, either choose the current setting, or the default setting for the
> > new colorspace, if non-DEFAULT colorspace was given.
> > 
> > This allows to let field order and colorimetry settings be propagated
> > from upstream by calling media-ctl on the upstream entity source pad,
> > and then call media-ctl on the sink pad to manually set the input frame
> > interval, without changing the already set field order and colorimetry
> > information.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> > This is based on imx-media-staging-md-v14, and it is supposed to allow
> > configuring the pipeline with media-ctl like this:
> > 
> > 1) media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY8_1X16/1920x1080]"
> > 2) media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY8_1X16/1920x108]"
> > 3) media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080]"
> > 4) media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080@1/60]"
> > 5) media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080@1/30]"
> > 
> > Without having step 4) overwrite the colorspace and field order set on
> > 'ipu1_csi0':0 by the propagation in step 3).
> > ---
> >  drivers/staging/media/imx/imx-media-csi.c | 34 +++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> > 
> > diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
> > index 64dc454f6b371..d94ce1de2bf05 100644
> > --- a/drivers/staging/media/imx/imx-media-csi.c
> > +++ b/drivers/staging/media/imx/imx-media-csi.c
> > @@ -1325,6 +1325,40 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
> >  	csi_try_fmt(priv, sensor, cfg, sdformat, crop, compose, &cc);
> >  
> >  	fmt = __csi_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
> > +
> > +	/* Retain current field setting as default */
> > +	if (sdformat->format.field == V4L2_FIELD_ANY)
> > +		sdformat->format.field = fmt->field;
> 
> This is OK.

Would this be a "may" or a "should"? As in,
"If SUBDEV_S_FMT is called with field == ANY, the driver may/should set
field to the previously configured interlacing field order".

What would be the correct place to document this behaviour?
Documentation/media/uapi/v4l/vidioc-subdev-g-fmt.rst?

> > +	/* Retain current colorspace setting as default */
> > +	if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
> > +		sdformat->format.colorspace = fmt->colorspace;
> > +		if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT)
> > +			sdformat->format.xfer_func = fmt->xfer_func;
> > +		if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT)
> > +			sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
> > +		if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT)
> > +			sdformat->format.quantization = fmt->quantization;
> 
> If sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT, then you can just copy
> all four fields from fmt to sdformat->format. The other three fields are meaningless
> when colorspace == V4L2_COLORSPACE_DEFAULT.

Ok, good. Ignoring the transfer function / YCbCr encoding / quantization
range fields when colorspace is DEFAULT would simplify this part to:

	if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
		sdformat->format.colorspace = fmt->colorspace;
		sdformat->format.xfer_func = fmt->xfer_func;
		sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
		sdformat->format.quantization = fmt->quantization;
	}

Is that expectation already written down somewhere? If not, should we
add it to Documentation/media/uapi/v4l/pixfmt-006.rst?

> > +	} else {
> > +		if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT) {
> > +			sdformat->format.xfer_func =
> > +				V4L2_MAP_XFER_FUNC_DEFAULT(
> > +						sdformat->format.colorspace);
> > +		}
> > +		if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT) {
> > +			sdformat->format.ycbcr_enc =
> > +				V4L2_MAP_YCBCR_ENC_DEFAULT(
> > +						sdformat->format.colorspace);
> > +		}
> > +		if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT) {
> > +			sdformat->format.quantization =
> > +				V4L2_MAP_QUANTIZATION_DEFAULT(
> > +						cc->cs != IPUV3_COLORSPACE_YUV,
> > +						sdformat->format.colorspace,
> > +						sdformat->format.ycbcr_enc);
> > +		}
> 
> Is this needed for validation? Currently these fields play no role in the
> default link validation. Which I think is actually the right thing to do,
> unless the subdev can do actual colorspace conversion.

The CSI subdevice can't do colorspace conversion, but exactly the same
applies to the IC subdevices, which can. Also I'd like this information
to be correct, as the /dev/videoX capture device takes its colorspace
information from the CSI source pad.

The problem I wanted to solve here initially was that if the colorspace
information was previously set correctly:

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080@1/60 colorspace:rec709 xfer:709 ycbcr:709 quantization:lim-range]"
    ->
	V4L2_COLORSPACE_REC709
	V4L2_XFER_FUNC_709
	V4L2_YCBCR_ENC_709
	V4L2_QUANTIZATION_LIMITED_RANGE

A later media-ctl call to just change the frame interval would overwrite the colorspace information:

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080@1/30]"
    ->
	V4L2_COLORSPACE_DEFAULT
	V4L2_XFER_FUNC_DEFAULT
	V4L2_YCBCR_ENC_DEFAULT
	V4L2_QUANTIZATION_DEFAULT

> I would just drop the whole 'else' here.

That would allow to set the actual colorspace information reported by
SUBDEV_G_FMT on both sink and source pads (and by extension, the
colorspace information reported by G_FMT on /dev/videoX) to
V4L2_{XFER_FUNC,YCBCR_ENC,QUANTIZATION}_DEFAULT.

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 colorspace:rec709]"
    ->
	V4L2_COLORSPACE_REC709
	V4L2_XFER_FUNC_DEFAULT
	V4L2_YCBCR_ENC_DEFAULT
	V4L2_QUANTIZATION_DEFAULT

I suppose that is acceptable as given the colorspace, the other DEFAULT
values have a unique meaning, but wouldn't it be nicer to show userspace
what these default inputs actually map to?

> Actually, wouldn't it be better to always just copy this information from
> fmt? This subdev doesn't do any colorspace conversion, it just passes on
> this information. I.e., you can't set it in any meaningful way.

csi_set_fmt on the sink pad is the function that actually sets fmt in
the first place. If we always copy colorspace information from fmt, it
can't be set to the correct value at all.

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] [media] imx: csi: retain current field order and colorimetry setting as default
Date: Mon, 08 May 2017 11:36:47 +0200	[thread overview]
Message-ID: <1494236207.3029.66.camel@pengutronix.de> (raw)
In-Reply-To: <0632df59-10e7-1e03-c0f6-eb7c90b83c0d@xs4all.nl>

Hi Hans,

On Mon, 2017-05-08 at 10:27 +0200, Hans Verkuil wrote:
> Hi Philipp,
> 
> Sorry for the very long delay, but I finally had some time to think about this.

Thank you for your thoughts.

> On 04/06/2017 03:55 PM, Philipp Zabel wrote:
> > If the the field order is set to ANY in set_fmt, choose the currently
> > set field order. If the colorspace is set to DEFAULT, choose the current
> > colorspace.  If any of xfer_func, ycbcr_enc or quantization are set to
> > DEFAULT, either choose the current setting, or the default setting for the
> > new colorspace, if non-DEFAULT colorspace was given.
> > 
> > This allows to let field order and colorimetry settings be propagated
> > from upstream by calling media-ctl on the upstream entity source pad,
> > and then call media-ctl on the sink pad to manually set the input frame
> > interval, without changing the already set field order and colorimetry
> > information.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> > This is based on imx-media-staging-md-v14, and it is supposed to allow
> > configuring the pipeline with media-ctl like this:
> > 
> > 1) media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY8_1X16/1920x1080]"
> > 2) media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY8_1X16/1920x108]"
> > 3) media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY8_1X16/1920x1080]"
> > 4) media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 at 1/60]"
> > 5) media-ctl --set-v4l2 "'ipu1_csi0':2[fmt:AYUV32/1920x1080 at 1/30]"
> > 
> > Without having step 4) overwrite the colorspace and field order set on
> > 'ipu1_csi0':0 by the propagation in step 3).
> > ---
> >  drivers/staging/media/imx/imx-media-csi.c | 34 +++++++++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> > 
> > diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
> > index 64dc454f6b371..d94ce1de2bf05 100644
> > --- a/drivers/staging/media/imx/imx-media-csi.c
> > +++ b/drivers/staging/media/imx/imx-media-csi.c
> > @@ -1325,6 +1325,40 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
> >  	csi_try_fmt(priv, sensor, cfg, sdformat, crop, compose, &cc);
> >  
> >  	fmt = __csi_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
> > +
> > +	/* Retain current field setting as default */
> > +	if (sdformat->format.field == V4L2_FIELD_ANY)
> > +		sdformat->format.field = fmt->field;
> 
> This is OK.

Would this be a "may" or a "should"? As in,
"If SUBDEV_S_FMT is called with field == ANY, the driver may/should set
field to the previously configured interlacing field order".

What would be the correct place to document this behaviour?
Documentation/media/uapi/v4l/vidioc-subdev-g-fmt.rst?

> > +	/* Retain current colorspace setting as default */
> > +	if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
> > +		sdformat->format.colorspace = fmt->colorspace;
> > +		if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT)
> > +			sdformat->format.xfer_func = fmt->xfer_func;
> > +		if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT)
> > +			sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
> > +		if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT)
> > +			sdformat->format.quantization = fmt->quantization;
> 
> If sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT, then you can just copy
> all four fields from fmt to sdformat->format. The other three fields are meaningless
> when colorspace == V4L2_COLORSPACE_DEFAULT.

Ok, good. Ignoring the transfer function / YCbCr encoding / quantization
range fields when colorspace is DEFAULT would simplify this part to:

	if (sdformat->format.colorspace == V4L2_COLORSPACE_DEFAULT) {
		sdformat->format.colorspace = fmt->colorspace;
		sdformat->format.xfer_func = fmt->xfer_func;
		sdformat->format.ycbcr_enc = fmt->ycbcr_enc;
		sdformat->format.quantization = fmt->quantization;
	}

Is that expectation already written down somewhere? If not, should we
add it to Documentation/media/uapi/v4l/pixfmt-006.rst?

> > +	} else {
> > +		if (sdformat->format.xfer_func == V4L2_XFER_FUNC_DEFAULT) {
> > +			sdformat->format.xfer_func =
> > +				V4L2_MAP_XFER_FUNC_DEFAULT(
> > +						sdformat->format.colorspace);
> > +		}
> > +		if (sdformat->format.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT) {
> > +			sdformat->format.ycbcr_enc =
> > +				V4L2_MAP_YCBCR_ENC_DEFAULT(
> > +						sdformat->format.colorspace);
> > +		}
> > +		if (sdformat->format.quantization == V4L2_QUANTIZATION_DEFAULT) {
> > +			sdformat->format.quantization =
> > +				V4L2_MAP_QUANTIZATION_DEFAULT(
> > +						cc->cs != IPUV3_COLORSPACE_YUV,
> > +						sdformat->format.colorspace,
> > +						sdformat->format.ycbcr_enc);
> > +		}
> 
> Is this needed for validation? Currently these fields play no role in the
> default link validation. Which I think is actually the right thing to do,
> unless the subdev can do actual colorspace conversion.

The CSI subdevice can't do colorspace conversion, but exactly the same
applies to the IC subdevices, which can. Also I'd like this information
to be correct, as the /dev/videoX capture device takes its colorspace
information from the CSI source pad.

The problem I wanted to solve here initially was that if the colorspace
information was previously set correctly:

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 at 1/60 colorspace:rec709 xfer:709 ycbcr:709 quantization:lim-range]"
    ->
	V4L2_COLORSPACE_REC709
	V4L2_XFER_FUNC_709
	V4L2_YCBCR_ENC_709
	V4L2_QUANTIZATION_LIMITED_RANGE

A later media-ctl call to just change the frame interval would overwrite the colorspace information:

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 at 1/30]"
    ->
	V4L2_COLORSPACE_DEFAULT
	V4L2_XFER_FUNC_DEFAULT
	V4L2_YCBCR_ENC_DEFAULT
	V4L2_QUANTIZATION_DEFAULT

> I would just drop the whole 'else' here.

That would allow to set the actual colorspace information reported by
SUBDEV_G_FMT on both sink and source pads (and by extension, the
colorspace information reported by G_FMT on /dev/videoX) to
V4L2_{XFER_FUNC,YCBCR_ENC,QUANTIZATION}_DEFAULT.

  media-ctl --set-v4l2 "'ipu1_csi0':0[fmt:UYVY8_1X16/1920x1080 colorspace:rec709]"
    ->
	V4L2_COLORSPACE_REC709
	V4L2_XFER_FUNC_DEFAULT
	V4L2_YCBCR_ENC_DEFAULT
	V4L2_QUANTIZATION_DEFAULT

I suppose that is acceptable as given the colorspace, the other DEFAULT
values have a unique meaning, but wouldn't it be nicer to show userspace
what these default inputs actually map to?

> Actually, wouldn't it be better to always just copy this information from
> fmt? This subdev doesn't do any colorspace conversion, it just passes on
> this information. I.e., you can't set it in any meaningful way.

csi_set_fmt on the sink pad is the function that actually sets fmt in
the first place. If we always copy colorspace information from fmt, it
can't be set to the correct value at all.

regards
Philipp

  reply	other threads:[~2017-05-08  9:37 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
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 [this message]
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=1494236207.3029.66.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=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.