All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <a0393947@ti.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: <linux-media@vger.kernel.org>,
	<laurent.pinchart@ideasonboard.com>, <linux-omap@vger.kernel.org>,
	<tomi.valkeinen@ti.com>
Subject: Re: [PATCH v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Date: Mon, 7 Oct 2013 20:04:09 +0530	[thread overview]
Message-ID: <5252C661.3040608@ti.com> (raw)
In-Reply-To: <5252BEE9.9020200@xs4all.nl>

On Monday 07 October 2013 07:32 PM, Hans Verkuil wrote:
> On 10/07/2013 12:22 PM, Archit Taneja wrote:
>> On Monday 07 October 2013 03:04 PM, Hans Verkuil wrote:
>>> On 10/07/2013 11:16 AM, Archit Taneja wrote:
>>>> On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:
>>>>> Hi Archit,
>>>>>
>>>>> I've got a few comments below...
>>>>>
>>>>> On 09/06/2013 12:12 PM, Archit Taneja wrote:
>>>>>> VPE is a block which consists of a single memory to memory path which can
>>>>>> perform chrominance up/down sampling, de-interlacing, scaling, and color space
>>>>>> conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
>>>>>> interleaved video formats.
>>>>>>
>>>>>> We create a mem2mem driver based primarily on the mem2mem-testdev example.
>>>>>> The de-interlacer, scaler and color space converter are all bypassed for now
>>>>>> to keep the driver simple. Chroma up/down sampler blocks are implemented, so
>>>>>> conversion beteen different YUV formats is possible.
>>>>>>
>>>>>> Each mem2mem context allocates a buffer for VPE MMR values which it will use
>>>>>> when it gets access to the VPE HW via the mem2mem queue, it also allocates
>>>>>> a VPDMA descriptor list to which configuration and data descriptors are added.
>>>>>>
>>>>>> Based on the information received via v4l2 ioctls for the source and
>>>>>> destination queues, the driver configures the values for the MMRs, and stores
>>>>>> them in the buffer. There are also some VPDMA parameters like frame start and
>>>>>> line mode which needs to be configured, these are configured by direct register
>>>>>> writes via the VPDMA helper functions.
>>>>>>
>>>>>> The driver's device_run() mem2mem op will add each descriptor based on how the
>>>>>> source and destination queues are set up for the given ctx, once the list is
>>>>>> prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
>>>>>> upload MMR registers, start DMA of video buffers on the various input and output
>>>>>> clients/ports.
>>>>>>
>>>>>> When the list is parsed completely(and the DMAs on all the output ports done),
>>>>>> an interrupt is generated which we use to notify that the source and destination
>>>>>> buffers are done.
>>>>>>
>>>>>> The rest of the driver is quite similar to other mem2mem drivers, we use the
>>>>>> multiplane v4l2 ioctls as the HW support coplanar formats.
>>>>>>
>>>>>> Signed-off-by: Archit Taneja <archit@ti.com>
>>>>>> ---
>>>>>>     drivers/media/platform/Kconfig           |   16 +
>>>>>>     drivers/media/platform/Makefile          |    2 +
>>>>>>     drivers/media/platform/ti-vpe/Makefile   |    5 +
>>>>>>     drivers/media/platform/ti-vpe/vpe.c      | 1750 ++++++++++++++++++++++++++++++
>>>>>>     drivers/media/platform/ti-vpe/vpe_regs.h |  496 +++++++++
>>>>>>     include/uapi/linux/v4l2-controls.h       |    4 +
>>>>>>     6 files changed, 2273 insertions(+)
>>>>>>     create mode 100644 drivers/media/platform/ti-vpe/Makefile
>>>>>>     create mode 100644 drivers/media/platform/ti-vpe/vpe.c
>>>>>>     create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
>>>>>>
>>>>>
>>>>> <snip>
>>>>>
>>>>>> +
>>>>>> +static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
>>>>>> +{
>>>>>> +	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
>>>>>> +	struct vpe_ctx *ctx = file2ctx(file);
>>>>>> +	struct vb2_queue *vq;
>>>>>> +	struct vpe_q_data *q_data;
>>>>>> +	int i;
>>>>>> +
>>>>>> +	vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
>>>>>> +	if (!vq)
>>>>>> +		return -EINVAL;
>>>>>> +
>>>>>> +	q_data = get_q_data(ctx, f->type);
>>>>>> +
>>>>>> +	pix->width = q_data->width;
>>>>>> +	pix->height = q_data->height;
>>>>>> +	pix->pixelformat = q_data->fmt->fourcc;
>>>>>> +	pix->colorspace = q_data->colorspace;
>>>>>> +	pix->num_planes = q_data->fmt->coplanar ? 2 : 1;
>>>>>> +
>>>>>> +	for (i = 0; i < pix->num_planes; i++) {
>>>>>> +		pix->plane_fmt[i].bytesperline = q_data->bytesperline[i];
>>>>>> +		pix->plane_fmt[i].sizeimage = q_data->sizeimage[i];
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
>>>>>> +		       struct vpe_fmt *fmt, int type)
>>>>>> +{
>>>>>> +	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
>>>>>> +	struct v4l2_plane_pix_format *plane_fmt;
>>>>>> +	int i;
>>>>>> +
>>>>>> +	if (!fmt || !(fmt->types & type)) {
>>>>>> +		vpe_err(ctx->dev, "Fourcc format (0x%08x) invalid.\n",
>>>>>> +			pix->pixelformat);
>>>>>> +		return -EINVAL;
>>>>>> +	}
>>>>>> +
>>>>>> +	pix->field = V4L2_FIELD_NONE;
>>>>>> +
>>>>>> +	v4l_bound_align_image(&pix->width, MIN_W, MAX_W, W_ALIGN,
>>>>>> +			      &pix->height, MIN_H, MAX_H, H_ALIGN,
>>>>>> +			      S_ALIGN);
>>>>>> +
>>>>>> +	pix->num_planes = fmt->coplanar ? 2 : 1;
>>>>>> +	pix->pixelformat = fmt->fourcc;
>>>>>> +	pix->colorspace = fmt->fourcc == V4L2_PIX_FMT_RGB24 ?
>>>>>
>>>>> You do this only for capture. Output sets the colorspace, so try_fmt should
>>>>> leave the colorspace field untouched for the output direction.
>>>>>
>>>>>> +			V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
>>>>
>>>> The input to the VPE block can be various YUV formats, and the VPE can
>>>> generate both RGB and YUV formats.
>>>>
>>>> So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has
>>>> choice only to set V4L2_COLORSPACE_SMPTE170M. And in the
>>>> capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both
>>>> SRG and SMPTE170M options.
>>>>
>>>> One thing I am not clear about is whether the userspace application has
>>>> to set the colorspace in the v4l2 format for OUTPUT or CAPTURE or both?
>>>
>>> The spec today says that the colorspace field is filled in by the driver.
>>> It does not differentiate between output and capture. This is patently wrong,
>>> since for output it should be set by the application since that's who is
>>> telling the driver what colorspace the image has. The driver may change it
>>> if it doesn't support that colorspace, but otherwise it should leave it as
>>> is.
>>>
>>> A mem-to-mem device that doesn't care about the colorspace should just copy
>>> the colorspace field from the output value into the capture.
>>>
>>> What is missing in today's API is a way to do colorspace conversion in a m2m
>>> device since there is no way today to tell the driver the desired colorspace
>>> that it should get back from the m2m device.
>>>
>>>>
>>>>    From what I understood, the code should be as below.
>>>>
>>>> For output:
>>>>
>>>> if (!pix->colorspace)
>>>> 	pix->colorspace = V4L2_COLORSPACE_SMPTE170M;
>>>
>>> I would leave off the 'if' part. If this colorspace is all you support on the
>>> output, then always set it.
>>>
>>> However, since it can convert YUV to RGB, doesn't the hardware have to know
>>> about the various YUV colorspaces? SDTV and HDTV have different colorspaces.
>>>
>>>>
>>>> And for capture:
>>>> 	pix->colorspace = fmt->fourcc == V4L2_PIX_FMT_RGB24 ?
>>>> 		V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
>>>>
>>>> Does this look correct?
>>>
>>> Yes, unless the hardware can take SDTV/HDTV YUV colorspaces into account. In
>>> that case I need to think how the API should be improved.
>>
>> The hardware can't convert one YUV color space to another. But it has a
>> programmable CSC block for YUV->RGB conversion in which we can program
>> coefficients based on the input YUV color space.
>>
>> The color space conversion block isn't implemented by the driver yet. So
>> I didn't look too much into it.
>>
>> I guess it will be eventually important to consider the output
>> colorspace. It doesn't need to be only SMPTE170M, it could be REC709 or
>> SMPTE240M based on what the user says.
>>
>> When the color space conversion block is implemented and the capture
>> colorspace is RGB, the driver should see the input colorspace and choose
>> the coefficients accordingly.
>>
>> With this new information about the hardware (:)), I guess it should be
>> as below for now:
>>
>> output:
>> /* inserted this check back since multiple YUV spaces supported */
>> if (!pix->colorspace)	
>> 	pix->colorspace = V4L2_COLORSPACE_SMPTE170M;
>>
>> capture:
>> /* removed SRGB sicne we don't support CSC yet */
>> pix->colorspace = s_q_data->colorspace;
>>
>> However, the above would imply that we need to s_fmt ioctl is called for
>> OUTPUT first, followed by s_fmt for CAPTURE. I don't think that's
>> something necessary according to the v4l spec.
>
> Well, s_fmt(OUTPUT) influences the colorspace field returned by *_fmt(CAPTURE).
> Which I think is OK. You can use either order, but to see the actual colorspace
> used by capture you will have to call g_fmt(CAPTURE) after calling s_fmt(OUTPUT).
>
> It's the logical order anyway for a m2m device to start with the output first.

Okay, that makes sense.

>
>> Besides this, I noticed a series "V4L2 mem-to-mem ioctl helpers" which I
>> should take use of. Do you suggest I base my patches over that?
>
> I don't know when that will be merged. It might be easier to just add a new
> patch converting the driver to the helpers, then we can apply all patches except
> that last one if the helpers aren't merged yet.

That's a good idea. Will add a new patch in the next version.

Thanks for the review.

Archit


WARNING: multiple messages have this Message-ID (diff)
From: Archit Taneja <a0393947@ti.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com,
	linux-omap@vger.kernel.org, tomi.valkeinen@ti.com
Subject: Re: [PATCH v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver
Date: Mon, 7 Oct 2013 20:04:09 +0530	[thread overview]
Message-ID: <5252C661.3040608@ti.com> (raw)
In-Reply-To: <5252BEE9.9020200@xs4all.nl>

On Monday 07 October 2013 07:32 PM, Hans Verkuil wrote:
> On 10/07/2013 12:22 PM, Archit Taneja wrote:
>> On Monday 07 October 2013 03:04 PM, Hans Verkuil wrote:
>>> On 10/07/2013 11:16 AM, Archit Taneja wrote:
>>>> On Monday 07 October 2013 01:25 PM, Hans Verkuil wrote:
>>>>> Hi Archit,
>>>>>
>>>>> I've got a few comments below...
>>>>>
>>>>> On 09/06/2013 12:12 PM, Archit Taneja wrote:
>>>>>> VPE is a block which consists of a single memory to memory path which can
>>>>>> perform chrominance up/down sampling, de-interlacing, scaling, and color space
>>>>>> conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
>>>>>> interleaved video formats.
>>>>>>
>>>>>> We create a mem2mem driver based primarily on the mem2mem-testdev example.
>>>>>> The de-interlacer, scaler and color space converter are all bypassed for now
>>>>>> to keep the driver simple. Chroma up/down sampler blocks are implemented, so
>>>>>> conversion beteen different YUV formats is possible.
>>>>>>
>>>>>> Each mem2mem context allocates a buffer for VPE MMR values which it will use
>>>>>> when it gets access to the VPE HW via the mem2mem queue, it also allocates
>>>>>> a VPDMA descriptor list to which configuration and data descriptors are added.
>>>>>>
>>>>>> Based on the information received via v4l2 ioctls for the source and
>>>>>> destination queues, the driver configures the values for the MMRs, and stores
>>>>>> them in the buffer. There are also some VPDMA parameters like frame start and
>>>>>> line mode which needs to be configured, these are configured by direct register
>>>>>> writes via the VPDMA helper functions.
>>>>>>
>>>>>> The driver's device_run() mem2mem op will add each descriptor based on how the
>>>>>> source and destination queues are set up for the given ctx, once the list is
>>>>>> prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
>>>>>> upload MMR registers, start DMA of video buffers on the various input and output
>>>>>> clients/ports.
>>>>>>
>>>>>> When the list is parsed completely(and the DMAs on all the output ports done),
>>>>>> an interrupt is generated which we use to notify that the source and destination
>>>>>> buffers are done.
>>>>>>
>>>>>> The rest of the driver is quite similar to other mem2mem drivers, we use the
>>>>>> multiplane v4l2 ioctls as the HW support coplanar formats.
>>>>>>
>>>>>> Signed-off-by: Archit Taneja <archit@ti.com>
>>>>>> ---
>>>>>>     drivers/media/platform/Kconfig           |   16 +
>>>>>>     drivers/media/platform/Makefile          |    2 +
>>>>>>     drivers/media/platform/ti-vpe/Makefile   |    5 +
>>>>>>     drivers/media/platform/ti-vpe/vpe.c      | 1750 ++++++++++++++++++++++++++++++
>>>>>>     drivers/media/platform/ti-vpe/vpe_regs.h |  496 +++++++++
>>>>>>     include/uapi/linux/v4l2-controls.h       |    4 +
>>>>>>     6 files changed, 2273 insertions(+)
>>>>>>     create mode 100644 drivers/media/platform/ti-vpe/Makefile
>>>>>>     create mode 100644 drivers/media/platform/ti-vpe/vpe.c
>>>>>>     create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
>>>>>>
>>>>>
>>>>> <snip>
>>>>>
>>>>>> +
>>>>>> +static int vpe_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
>>>>>> +{
>>>>>> +	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
>>>>>> +	struct vpe_ctx *ctx = file2ctx(file);
>>>>>> +	struct vb2_queue *vq;
>>>>>> +	struct vpe_q_data *q_data;
>>>>>> +	int i;
>>>>>> +
>>>>>> +	vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
>>>>>> +	if (!vq)
>>>>>> +		return -EINVAL;
>>>>>> +
>>>>>> +	q_data = get_q_data(ctx, f->type);
>>>>>> +
>>>>>> +	pix->width = q_data->width;
>>>>>> +	pix->height = q_data->height;
>>>>>> +	pix->pixelformat = q_data->fmt->fourcc;
>>>>>> +	pix->colorspace = q_data->colorspace;
>>>>>> +	pix->num_planes = q_data->fmt->coplanar ? 2 : 1;
>>>>>> +
>>>>>> +	for (i = 0; i < pix->num_planes; i++) {
>>>>>> +		pix->plane_fmt[i].bytesperline = q_data->bytesperline[i];
>>>>>> +		pix->plane_fmt[i].sizeimage = q_data->sizeimage[i];
>>>>>> +	}
>>>>>> +
>>>>>> +	return 0;
>>>>>> +}
>>>>>> +
>>>>>> +static int __vpe_try_fmt(struct vpe_ctx *ctx, struct v4l2_format *f,
>>>>>> +		       struct vpe_fmt *fmt, int type)
>>>>>> +{
>>>>>> +	struct v4l2_pix_format_mplane *pix = &f->fmt.pix_mp;
>>>>>> +	struct v4l2_plane_pix_format *plane_fmt;
>>>>>> +	int i;
>>>>>> +
>>>>>> +	if (!fmt || !(fmt->types & type)) {
>>>>>> +		vpe_err(ctx->dev, "Fourcc format (0x%08x) invalid.\n",
>>>>>> +			pix->pixelformat);
>>>>>> +		return -EINVAL;
>>>>>> +	}
>>>>>> +
>>>>>> +	pix->field = V4L2_FIELD_NONE;
>>>>>> +
>>>>>> +	v4l_bound_align_image(&pix->width, MIN_W, MAX_W, W_ALIGN,
>>>>>> +			      &pix->height, MIN_H, MAX_H, H_ALIGN,
>>>>>> +			      S_ALIGN);
>>>>>> +
>>>>>> +	pix->num_planes = fmt->coplanar ? 2 : 1;
>>>>>> +	pix->pixelformat = fmt->fourcc;
>>>>>> +	pix->colorspace = fmt->fourcc == V4L2_PIX_FMT_RGB24 ?
>>>>>
>>>>> You do this only for capture. Output sets the colorspace, so try_fmt should
>>>>> leave the colorspace field untouched for the output direction.
>>>>>
>>>>>> +			V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
>>>>
>>>> The input to the VPE block can be various YUV formats, and the VPE can
>>>> generate both RGB and YUV formats.
>>>>
>>>> So, I guess the output(V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) side has
>>>> choice only to set V4L2_COLORSPACE_SMPTE170M. And in the
>>>> capture(V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) capture side we have both
>>>> SRG and SMPTE170M options.
>>>>
>>>> One thing I am not clear about is whether the userspace application has
>>>> to set the colorspace in the v4l2 format for OUTPUT or CAPTURE or both?
>>>
>>> The spec today says that the colorspace field is filled in by the driver.
>>> It does not differentiate between output and capture. This is patently wrong,
>>> since for output it should be set by the application since that's who is
>>> telling the driver what colorspace the image has. The driver may change it
>>> if it doesn't support that colorspace, but otherwise it should leave it as
>>> is.
>>>
>>> A mem-to-mem device that doesn't care about the colorspace should just copy
>>> the colorspace field from the output value into the capture.
>>>
>>> What is missing in today's API is a way to do colorspace conversion in a m2m
>>> device since there is no way today to tell the driver the desired colorspace
>>> that it should get back from the m2m device.
>>>
>>>>
>>>>    From what I understood, the code should be as below.
>>>>
>>>> For output:
>>>>
>>>> if (!pix->colorspace)
>>>> 	pix->colorspace = V4L2_COLORSPACE_SMPTE170M;
>>>
>>> I would leave off the 'if' part. If this colorspace is all you support on the
>>> output, then always set it.
>>>
>>> However, since it can convert YUV to RGB, doesn't the hardware have to know
>>> about the various YUV colorspaces? SDTV and HDTV have different colorspaces.
>>>
>>>>
>>>> And for capture:
>>>> 	pix->colorspace = fmt->fourcc == V4L2_PIX_FMT_RGB24 ?
>>>> 		V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
>>>>
>>>> Does this look correct?
>>>
>>> Yes, unless the hardware can take SDTV/HDTV YUV colorspaces into account. In
>>> that case I need to think how the API should be improved.
>>
>> The hardware can't convert one YUV color space to another. But it has a
>> programmable CSC block for YUV->RGB conversion in which we can program
>> coefficients based on the input YUV color space.
>>
>> The color space conversion block isn't implemented by the driver yet. So
>> I didn't look too much into it.
>>
>> I guess it will be eventually important to consider the output
>> colorspace. It doesn't need to be only SMPTE170M, it could be REC709 or
>> SMPTE240M based on what the user says.
>>
>> When the color space conversion block is implemented and the capture
>> colorspace is RGB, the driver should see the input colorspace and choose
>> the coefficients accordingly.
>>
>> With this new information about the hardware (:)), I guess it should be
>> as below for now:
>>
>> output:
>> /* inserted this check back since multiple YUV spaces supported */
>> if (!pix->colorspace)	
>> 	pix->colorspace = V4L2_COLORSPACE_SMPTE170M;
>>
>> capture:
>> /* removed SRGB sicne we don't support CSC yet */
>> pix->colorspace = s_q_data->colorspace;
>>
>> However, the above would imply that we need to s_fmt ioctl is called for
>> OUTPUT first, followed by s_fmt for CAPTURE. I don't think that's
>> something necessary according to the v4l spec.
>
> Well, s_fmt(OUTPUT) influences the colorspace field returned by *_fmt(CAPTURE).
> Which I think is OK. You can use either order, but to see the actual colorspace
> used by capture you will have to call g_fmt(CAPTURE) after calling s_fmt(OUTPUT).
>
> It's the logical order anyway for a m2m device to start with the output first.

Okay, that makes sense.

>
>> Besides this, I noticed a series "V4L2 mem-to-mem ioctl helpers" which I
>> should take use of. Do you suggest I base my patches over that?
>
> I don't know when that will be merged. It might be easier to just add a new
> patch converting the driver to the helpers, then we can apply all patches except
> that last one if the helpers aren't merged yet.

That's a good idea. Will add a new patch in the next version.

Thanks for the review.

Archit


  reply	other threads:[~2013-10-07 14:34 UTC|newest]

Thread overview: 138+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-02 14:03 [PATCH 0/6] v4l: VPE mem to mem driver Archit Taneja
2013-08-02 14:03 ` Archit Taneja
2013-08-02 14:03 ` [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library Archit Taneja
2013-08-02 14:03   ` Archit Taneja
2013-08-05  8:13   ` Tomi Valkeinen
2013-08-05  8:13     ` Tomi Valkeinen
2013-08-05 11:26     ` Archit Taneja
2013-08-05 11:26       ` Archit Taneja
2013-08-05 12:26       ` Tomi Valkeinen
2013-08-05 12:26         ` Tomi Valkeinen
2013-08-08 21:35       ` Laurent Pinchart
2013-08-14 10:19         ` Archit Taneja
2013-08-14 10:19           ` Archit Taneja
2013-08-08 22:04   ` Laurent Pinchart
2013-08-14 10:57     ` Archit Taneja
2013-08-14 10:57       ` Archit Taneja
2013-08-20 11:39       ` Laurent Pinchart
2013-08-20 12:51         ` Archit Taneja
2013-08-20 12:51           ` Archit Taneja
2013-08-20 13:16         ` Archit Taneja
2013-08-20 13:16           ` Archit Taneja
2013-08-20 13:56           ` Laurent Pinchart
2013-08-21  6:47             ` Archit Taneja
2013-08-21  6:47               ` Archit Taneja
2013-08-02 14:03 ` [PATCH 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors Archit Taneja
2013-08-02 14:03   ` Archit Taneja
2013-08-05  9:11   ` Tomi Valkeinen
2013-08-05  9:11     ` Tomi Valkeinen
2013-08-05 12:05     ` Archit Taneja
2013-08-05 12:05       ` Archit Taneja
2013-08-05 13:03       ` Tomi Valkeinen
2013-08-05 13:03         ` Tomi Valkeinen
2013-08-02 14:03 ` [PATCH 3/6] v4l: ti-vpe: Add VPE mem to mem driver Archit Taneja
2013-08-02 14:03   ` Archit Taneja
2013-08-02 14:36   ` Hans Verkuil
2013-08-02 14:55     ` Archit Taneja
2013-08-02 14:55       ` Archit Taneja
2013-08-05  9:18   ` Tomi Valkeinen
2013-08-05  9:18     ` Tomi Valkeinen
2013-08-02 14:03 ` [PATCH 4/6] v4l: ti-vpe: Add de-interlacer support in VPE Archit Taneja
2013-08-02 14:03   ` Archit Taneja
2013-08-02 14:40   ` Hans Verkuil
2013-08-02 14:03 ` [PATCH 5/6] arm: dra7xx: hwmod data: add VPE hwmod data and ocp_if info Archit Taneja
2013-08-02 14:03   ` Archit Taneja
2013-08-02 14:03 ` [PATCH 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE Archit Taneja
2013-08-02 14:03   ` Archit Taneja
2013-08-08 22:11   ` Laurent Pinchart
2013-10-25 10:35     ` Archit Taneja
2013-10-25 10:35       ` Archit Taneja
2013-12-03 10:08     ` Archit Taneja
2013-12-03 10:08       ` Archit Taneja
2013-08-20 11:00 ` [PATCH v2 0/6] v4l: VPE mem to mem driver Archit Taneja
2013-08-20 11:00   ` Archit Taneja
2013-08-20 11:00   ` [PATCH v2 1/6] v4l: ti-vpe: Create a vpdma helper library Archit Taneja
2013-08-20 11:00     ` Archit Taneja
2013-08-20 11:00   ` [PATCH v2 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors Archit Taneja
2013-08-20 11:00     ` Archit Taneja
2013-08-20 11:00   ` [PATCH v2 3/6] v4l: ti-vpe: Add VPE mem to mem driver Archit Taneja
2013-08-20 11:00     ` Archit Taneja
2013-08-20 11:00   ` [PATCH v2 4/6] v4l: ti-vpe: Add de-interlacer support in VPE Archit Taneja
2013-08-20 11:00     ` Archit Taneja
2013-08-20 11:00   ` [PATCH v2 5/6] arm: dra7xx: hwmod data: add VPE hwmod data and ocp_if info Archit Taneja
2013-08-20 11:00     ` Archit Taneja
2013-08-20 11:00   ` [PATCH v2 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE Archit Taneja
2013-08-20 11:00     ` Archit Taneja
2013-08-29 12:32   ` [PATCH v3 0/6] v4l: VPE mem to mem driver Archit Taneja
2013-08-29 12:32     ` Archit Taneja
2013-08-29 12:32     ` [PATCH v3 1/6] v4l: ti-vpe: Create a vpdma helper library Archit Taneja
2013-08-29 12:32       ` Archit Taneja
2013-08-29 12:32     ` [PATCH v3 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors Archit Taneja
2013-08-29 12:32       ` Archit Taneja
2013-08-29 12:32     ` [PATCH v3 3/6] v4l: ti-vpe: Add VPE mem to mem driver Archit Taneja
2013-08-29 12:32       ` Archit Taneja
2013-08-29 13:28       ` Hans Verkuil
2013-08-30  6:47         ` Archit Taneja
2013-08-30  6:47           ` Archit Taneja
2013-08-30  7:07           ` Hans Verkuil
2013-08-30 10:05             ` Archit Taneja
2013-08-30 10:05               ` Archit Taneja
2013-08-30 10:44               ` Hans Verkuil
2013-09-05  5:56         ` Archit Taneja
2013-09-05  5:56           ` Archit Taneja
2013-08-29 12:32     ` [PATCH v3 4/6] v4l: ti-vpe: Add de-interlacer support in VPE Archit Taneja
2013-08-29 12:32       ` Archit Taneja
2013-08-29 12:32     ` [PATCH v3 5/6] arm: dra7xx: hwmod data: add VPE hwmod data and ocp_if info Archit Taneja
2013-08-29 12:32       ` Archit Taneja
2013-08-29 12:42       ` Rajendra Nayak
2013-08-29 12:42         ` Rajendra Nayak
2013-08-29 13:42         ` Archit Taneja
2013-08-29 13:42           ` Archit Taneja
2013-08-29 12:32     ` [PATCH v3 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE Archit Taneja
2013-08-29 12:32       ` Archit Taneja
2013-09-06 10:12   ` [PATCH v4 0/4] v4l: VPE mem to mem driver Archit Taneja
2013-09-06 10:12     ` Archit Taneja
2013-09-06 10:12     ` [PATCH v4 1/4] v4l: ti-vpe: Create a vpdma helper library Archit Taneja
2013-09-06 10:12       ` Archit Taneja
2013-10-07  7:46       ` Hans Verkuil
2013-09-06 10:12     ` [PATCH v4 2/4] v4l: ti-vpe: Add helpers for creating VPDMA descriptors Archit Taneja
2013-09-06 10:12       ` Archit Taneja
2013-10-07  7:46       ` Hans Verkuil
2013-09-06 10:12     ` [PATCH v4 3/4] v4l: ti-vpe: Add VPE mem to mem driver Archit Taneja
2013-09-06 10:12       ` Archit Taneja
2013-10-07  7:55       ` Hans Verkuil
2013-10-07  9:16         ` Archit Taneja
2013-10-07  9:16           ` Archit Taneja
2013-10-07  9:34           ` Hans Verkuil
2013-10-07 10:22             ` Archit Taneja
2013-10-07 10:22               ` Archit Taneja
2013-10-07 14:02               ` Hans Verkuil
2013-10-07 14:34                 ` Archit Taneja [this message]
2013-10-07 14:34                   ` Archit Taneja
2013-09-06 10:12     ` [PATCH v4 4/4] v4l: ti-vpe: Add de-interlacer support in VPE Archit Taneja
2013-09-06 10:12       ` Archit Taneja
2013-10-07  7:57       ` Hans Verkuil
2013-09-16  6:59     ` [PATCH v4 0/4] v4l: VPE mem to mem driver Archit Taneja
2013-09-16  6:59       ` Archit Taneja
2013-10-07  6:39       ` Archit Taneja
2013-10-07  6:39         ` Archit Taneja
2013-10-09 14:29     ` [PATCH v5 3/4] v4l: ti-vpe: Add " Archit Taneja
2013-10-09 14:29       ` Archit Taneja
2013-10-11  7:46       ` Hans Verkuil
2013-10-15 13:47         ` Archit Taneja
2013-10-15 13:47           ` Archit Taneja
2013-10-15 13:51           ` Hans Verkuil
2013-10-15 14:13             ` Kamil Debski
2013-10-15 15:54             ` Kamil Debski
2013-10-16  5:08               ` Archit Taneja
2013-10-16  5:08                 ` Archit Taneja
2013-10-16  5:36     ` [PATCH v5 0/4] v4l: " Archit Taneja
2013-10-16  5:36       ` Archit Taneja
2013-10-16  5:36       ` [PATCH v5 1/4] v4l: ti-vpe: Create a vpdma helper library Archit Taneja
2013-10-16  5:36         ` Archit Taneja
2013-10-16  5:36       ` [PATCH v5 2/4] v4l: ti-vpe: Add helpers for creating VPDMA descriptors Archit Taneja
2013-10-16  5:36         ` Archit Taneja
2013-10-16  5:36       ` [PATCH v5 3/4] v4l: ti-vpe: Add VPE mem to mem driver Archit Taneja
2013-10-16  5:36         ` Archit Taneja
2013-10-16  5:36       ` [PATCH v5 4/4] v4l: ti-vpe: Add de-interlacer support in VPE Archit Taneja
2013-10-16  5:36         ` Archit Taneja

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=5252C661.3040608@ti.com \
    --to=a0393947@ti.com \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tomi.valkeinen@ti.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.