Re: [PATCH 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On 02/08/13 17:03, 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 arc...@ti.com --- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile |2 + drivers/media/platform/ti-vpe/vpe.c | 1763 ++ drivers/media/platform/ti-vpe/vpe_regs.h | 496 + 4 files changed, 2271 insertions(+) create mode 100644 drivers/media/platform/ti-vpe/vpe.c create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h Just two quick comments, the same as to an earlier patch: consts for tables, and write instead of insert. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/6] v4l: ti-vpe: Add VPE mem to mem driver
Hi Archit,
I've got a few comments:
On 08/02/2013 04:03 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 arc...@ti.com
---
drivers/media/platform/Kconfig | 10 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/ti-vpe/vpe.c | 1763
++
drivers/media/platform/ti-vpe/vpe_regs.h | 496 +
4 files changed, 2271 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
...
+/*
+ * video ioctls
+ */
+static int vpe_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
+ strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
+ strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING |
+ V4L2_CAP_VIDEO_CAPTURE_MPLANE |
+ V4L2_CAP_VIDEO_OUTPUT_MPLANE;
That should be: V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
No CAPTURE/OUTPUT_MPLANE.
+ cap-capabilities = cap-device_caps | V4L2_CAP_DEVICE_CAPS;
+ return 0;
+}
+
+static int __enum_fmt(struct v4l2_fmtdesc *f, u32 type)
+{
+ int i, index;
+ struct vpe_fmt *fmt = NULL;
+
+ index = 0;
+ for (i = 0; i ARRAY_SIZE(vpe_formats); ++i) {
+ if (vpe_formats[i].types type) {
+ if (index == f-index) {
+ fmt = vpe_formats[i];
+ break;
+ }
+ index++;
+ }
+ }
+
+ if (!fmt)
+ return -EINVAL;
+
+ strncpy(f-description, fmt-name, sizeof(f-description) - 1);
+ f-pixelformat = fmt-fourcc;
+ return 0;
+}
+
+static int vpe_enum_fmt(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (V4L2_TYPE_IS_OUTPUT(f-type))
+ return __enum_fmt(f, VPE_FMT_TYPE_OUTPUT);
+ else
+ return __enum_fmt(f, VPE_FMT_TYPE_CAPTURE);
+}
+
+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
Re: [PATCH 3/6] v4l: ti-vpe: Add VPE mem to mem driver
Hi Hans,
Thanks for the comments. Some replies below.
On Friday 02 August 2013 08:06 PM, Hans Verkuil wrote:
Hi Archit,
I've got a few comments:
On 08/02/2013 04:03 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 arc...@ti.com
---
drivers/media/platform/Kconfig | 10 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/ti-vpe/vpe.c | 1763 ++
drivers/media/platform/ti-vpe/vpe_regs.h | 496 +
4 files changed, 2271 insertions(+)
create mode 100644 drivers/media/platform/ti-vpe/vpe.c
create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h
...
+/*
+ * video ioctls
+ */
+static int vpe_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ strncpy(cap-driver, VPE_MODULE_NAME, sizeof(cap-driver) - 1);
+ strncpy(cap-card, VPE_MODULE_NAME, sizeof(cap-card) - 1);
+ strlcpy(cap-bus_info, VPE_MODULE_NAME, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING |
+ V4L2_CAP_VIDEO_CAPTURE_MPLANE |
+ V4L2_CAP_VIDEO_OUTPUT_MPLANE;
That should be: V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
No CAPTURE/OUTPUT_MPLANE.
Sure, I'll fix this.
snip
+
+ if (pix-field == V4L2_FIELD_ANY)
+ pix-field = V4L2_FIELD_NONE;
+ else if (V4L2_FIELD_NONE != pix-field)
+ return -EINVAL;
No, TRY_FMT should map field to a valid field type. In this case it is simple:
just set field to V4L2_FIELD_NONE.
Okay, I'll correct this.
I saw your comment on the de-interlacer patch. The de-interlacer can be
bypassed, so for both ouput buffer type and capture buffer type, we can
have interlaced and progressive content, so I guess NONE and ALTERNATE
are possible for both.
+
+ 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 ?
+ V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M;
+
+
+ for (i = 0; i pix-num_planes; i++) {
+ int depth;
+
+ plane_fmt = pix-plane_fmt[i];
+ depth = fmt-vpdma_fmt[i]-depth;
+
+ if (i == VPE_LUMA)
+ plane_fmt-bytesperline =
+ round_up((pix-width * depth) 3,
+ 1 L_ALIGN);
+ else
+ plane_fmt-bytesperline = pix-width;
+
+ plane_fmt-sizeimage =
+ (pix-height * pix-width * depth) 3;
+ }
+
+ return 0;
+}
+
+static int vpe_try_fmt(struct file *file, void *priv, struct v4l2_format *f)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_fmt *fmt = find_format(f);
+
+ if (V4L2_TYPE_IS_OUTPUT(f-type))
+ return __vpe_try_fmt(ctx, f, fmt, VPE_FMT_TYPE_OUTPUT);
+ else
+ return __vpe_try_fmt(ctx, f, fmt,
