Re: [PATCH v2] media: rockchip vpu: remove some unused vars
On Wed, 2018-12-05 at 19:01 -0500, Mauro Carvalho Chehab wrote:
> As complained by gcc:
>
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c: In
> function 'rk3288_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:70:10:
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:69:10:
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c: In
> function 'rk3399_vpu_jpeg_enc_set_qtable':
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:101:10:
> warning: variable 'chroma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *chroma_qtable_p;
> ^~~
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:100:10:
> warning: variable 'luma_qtable_p' set but not used [-Wunused-but-set-
> variable]
> __be32 *luma_qtable_p;
> ^
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
> 'rockchip_vpu_queue_setup':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:522:33: warning:
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
>^~~
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c: In function
> 'rockchip_vpu_buf_prepare':
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:560:33: warning:
> variable 'vpu_fmt' set but not used [-Wunused-but-set-variable]
> const struct rockchip_vpu_fmt *vpu_fmt;
> ^~~
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Ezequiel Garcia
Thanks!
> ---
> drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 5 -
> drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 5 -
> drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c | 6 --
> 3 files changed, 16 deletions(-)
>
> diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> index e27c10855de5..5282236d1bb1 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
> @@ -66,13 +66,8 @@ rk3288_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev
> *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> index 5f75e4d11d76..dbc86d95fe3b 100644
> --- a/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
> @@ -97,13 +97,8 @@ rk3399_vpu_jpeg_enc_set_qtable(struct rockchip_vpu_dev
> *vpu,
> unsigned char *luma_qtable,
> unsigned char *chroma_qtable)
> {
> - __be32 *luma_qtable_p;
> - __be32 *chroma_qtable_p;
> u32 reg, i;
>
> - luma_qtable_p = (__be32 *)luma_qtable;
> - chroma_qtable_p = (__be32 *)chroma_qtable;
> -
> for (i = 0; i < VEPU_JPEG_QUANT_TABLE_COUNT; i++) {
> reg = get_unaligned_be32(_qtable[i]);
> vepu_write_relaxed(vpu, reg, VEPU_REG_JPEG_LUMA_QUAT(i));
> diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> index 038a7136d5d1..ab0fb2053620 100644
> --- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> +++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
> @@ -519,17 +519,14 @@ rockchip_vpu_queue_setup(struct vb2_queue *vq,
>struct device *alloc_devs[])
> {
> struct rockchip_vpu_ctx *ctx = vb2_get_drv_priv(vq);
> - const struct rockchip_vpu_fmt *vpu_fmt;
> struct v4l2_pix_format_mplane *pixfmt;
> int
[PATCH v3] v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields
Make the core set the reserved fields to zero in
vv4l2_pix_format_mplane.4l2_plane_pix_format,
for _MPLANE queue types.
Moving this to the core avoids having to do so in each
and every driver.
Suggested-by: Tomasz Figa
Signed-off-by: Ezequiel Garcia
Acked-by: Sakari Ailus
--
v3:
* s/int/unsigned int, suggested by Sakari
v2:
* Drop unneeded clear in g_fmt.
The sturct was already being cleared here.
* Only zero plane_fmt reserved fields.
* Use CLEAR_FIELD_MACRO.
drivers/media/v4l2-core/v4l2-ioctl.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e384142d2826..7e8e7915c041 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1512,6 +1512,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
struct v4l2_format *p = arg;
struct video_device *vfd = video_devdata(file);
int ret = check_fmt(file, p->type);
+ unsigned int i;
if (ret)
return ret;
@@ -1536,6 +1537,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
@@ -1564,6 +1567,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_out_overlay))
@@ -1604,6 +1609,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
{
struct v4l2_format *p = arg;
int ret = check_fmt(file, p->type);
+ unsigned int i;
if (ret)
return ret;
@@ -1623,6 +1629,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_overlay))
@@ -1651,6 +1659,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_out_overlay))
--
2.20.0.rc1
Re: [GIT PULL FOR v4.21] Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:37 -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Dec 2018 16:34:04 -0200
> Mauro Carvalho Chehab escreveu:
>
> > Em Wed, 5 Dec 2018 17:29:38 +0100
> > Hans Verkuil escreveu:
> >
> > > Note regarding the first 'Revert' patch: that is this patch:
> > >
> > > https://patchwork.linuxtv.org/patch/52869/
> > >
> > > It is currently pending for 4.20 as a fix, but since it is not merged
> > > upstream
> > > yet, our master branch still has those old bindings.
> > >
> > > I decided to first apply the Revert patch, then add the new patch on top.
> > >
> > > Regards,
> > >
> > > Hans
> > >
> > > The following changes since commit
> > > da2c94c8f9739e4099ea3cfefc208fc721b22a9c:
> > >
> > > media: v4l2: async: remove locking when initializing async notifier
> > > (2018-12-05 06:51:28 -0500)
> > >
> > > are available in the Git repository at:
> > >
> > > git://linuxtv.org/hverkuil/media_tree.git tags/br-rkjpeg2
> > >
> > > for you to fetch changes up to 7f608cfd52c08e7d84bd38438e330c26263eddcb:
> > >
> > > media: add Rockchip VPU JPEG encoder driver (2018-12-05 17:18:46 +0100)
> > >
> > >
> > > Tag branch
> > >
> > >
> > > Ezequiel Garcia (3):
> > > Revert "media: dt-bindings: Document the Rockchip VPU bindings"
> > > media: dt-bindings: Document the Rockchip VPU bindings
> > > media: add Rockchip VPU JPEG encoder driver
> >
> > Checkpatch produces a few warnings:
> >
> > # CHECK: Alignment should match open parenthesis
> > # #385: FILE:
> > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c:109:
> > # + rk3288_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # CHECK: Alignment should match open parenthesis
> > # #1124: FILE:
> > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c:140:
> > # + rk3399_vpu_jpeg_enc_set_qtable(vpu,
> > # + rockchip_vpu_jpeg_get_qtable(_ctx, 0),
> > #
> > # WARNING: DT compatible string "rockchip,rk3399-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2359: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:326:
> > # + { .compatible = "rockchip,rk3399-vpu", .data = _vpu_variant, },
> > #
> > # WARNING: DT compatible string "rockchip,rk3288-vpu" appears un-documented
> > -- check ./Documentation/devicetree/bindings/
> > # #2360: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c:327:
> > # + { .compatible = "rockchip,rk3288-vpu", .data = _vpu_variant, },
> > #
> > # CHECK: Unnecessary parentheses around 'formats[i].codec_mode !=
> > RK_VPU_MODE_NONE'
> > # #2721: FILE: drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c:145:
> > # + if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
> > #
> > # total: 0 errors, 2 warnings, 3 checks, 3469 lines checked
> >
Please note that this last one is a false positive,
the code needs those parenthesis.
Thanks!
Ezequiel
[PATCH v12] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- Changes from v11: * Fix buffer timecode * Add a comment explaining dma attributes * Fix wrong parenthesis * Remove unneeded error message MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 13 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 .../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 537 ++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 14 + 19 files changed, 3454 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index 2894fb9893a6..a86a0cd90514 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12748,6 +12748,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..9a6fc1378242 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,13 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. diff --git a/drive
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
Hi Hans,
On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote:
> On 11/30/18 18:34, Ezequiel Garcia wrote:
> > Add a mem2mem driver for the VPU available on Rockchip SoCs.
> > Currently only JPEG encoding is supported, for RK3399 and RK3288
> > platforms.
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
>
>
>
[..]
>
>
> Unless something unexpected happens, then v12 should be the final
> version and I'll make a pull request for it. Note that it will
> probably won't make 4.20, unless you manage to do it within the next
> hour :-)
>
Thanks for the review. Here are the changes that will be on v12.
Besides your feedback, I found a missing parenthesis issue,
which seems to have sneaked into v11! Apparently, v11 had
last minute changes and I failed to run v4l2-compliance.
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
index f2752a0c71c0..962412c79b91 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
@@ -60,11 +60,13 @@ static void rockchip_vpu_job_finish(struct rockchip_vpu_dev
*vpu,
dst->sequence = ctx->sequence_cap++;
dst->field = src->field;
- if (dst->flags & V4L2_BUF_FLAG_TIMECODE)
+ if (src->flags & V4L2_BUF_FLAG_TIMECODE)
dst->timecode = src->timecode;
dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
- dst->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
- dst->flags |= src->flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+ dst->flags &= ~(V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+ V4L2_BUF_FLAG_TIMECODE);
+ dst->flags |= src->flags & (V4L2_BUF_FLAG_TSTAMP_SRC_MASK |
+ V4L2_BUF_FLAG_TIMECODE);
avail_size = vb2_plane_size(>vb2_buf, 0) -
ctx->vpu_dst_fmt->header_size;
@@ -151,6 +153,12 @@ enc_queue_init(void *priv, struct vb2_queue *src_vq,
struct vb2_queue *dst_vq)
src_vq->drv_priv = ctx;
src_vq->ops = _vpu_enc_queue_ops;
src_vq->mem_ops = _dma_contig_memops;
+
+ /*
+* Driver does mostly sequential access, so sacrifice TLB efficiency
+* for faster allocation. Also, no CPU access on the source queue,
+* so no kernel mapping needed.
+*/
src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
DMA_ATTR_NO_KERNEL_MAPPING;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
@@ -197,8 +205,6 @@ static int rockchip_vpu_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->jpeg_quality = ctrl->val;
break;
default:
- vpu_err("Invalid control id = %d, val = %d\n",
- ctrl->id, ctrl->val);
return -EINVAL;
}
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
index 6aadd194e999..3dbd15d5fabe 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c
@@ -142,7 +142,7 @@ rockchip_vpu_get_default_fmt(struct rockchip_vpu_ctx *ctx,
bool bitstream)
formats = dev->variant->enc_fmts;
num_fmts = dev->variant->num_enc_fmts;
for (i = 0; i < num_fmts; i++) {
- if (bitstream == formats[i].codec_mode != RK_VPU_MODE_NONE)
+ if (bitstream == (formats[i].codec_mode != RK_VPU_MODE_NONE))
return [i];
}
return NULL;
Re: [PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
On Wed, 2018-12-05 at 16:01 +0100, Hans Verkuil wrote: > Unless something unexpected happens, then v12 should be the final > version and I'll make a pull request for it. Note that it will > probably won't make 4.20, unless you manage to do it within the next > hour :-) Challenge accepted!
[PATCH v11 2/4] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Reviewed-by: Tomasz Figa
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.20.0.rc1
[PATCH v11 4/4] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 13 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 .../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 531 ++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 14 + 19 files changed, 3448 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index 2894fb9893a6..a86a0cd90514 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12748,6 +12748,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..9a6fc1378242 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,13 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..e9d733bb7632 --- /dev/
[PATCH v11 0/4] Add Rockchip VPU JPEG encoder
Nothing like sending a new round on a Friday,
so people can test and review during the weekend! ;-)
As before, this series is based on Mauro's master branch,
with the following patch applied:
https://patchwork.kernel.org/patch/10676149/
On this new round, I've addressed all the feedback
provided by Tomasz on v10.
As always, any additional feedback is well received.
This patchset has been tested on RK3288 and RK3399
using bleeding-edge Gstreamer, with these pipelines:
function gst_kms {
gst-launch-1.0 -v videotestsrc num-buffers=${4} !
video/x-raw,width=${1},height=${2},format=${3}! v4l2jpegenc
extra-controls="c,compression_quality=100" ! jpegdec ! videoconvert !
video/x-raw,format=BGRx ! queue leaky=1 ! kmssink sync=0
}
gst_kms 640 480 YUY2 30
gst_kms 640 480 NV12 30
gst_kms 640 480 I420 30
(and more sizes)
There are a few warnings after running check_patch.pl --strict,
but I've chosen not to address them, as it would reducely
readability.
Also, v4l2-compliance -s passes on both platforms, as has
been the case for the past submissions.
v11:
* Update TODO file
* Make macroblock alignment codec specific
* Rename VEPU_REG_ADDR_IN_LUMA,CR,CB to
VEPU_REG_ADDR_IN_PLANE_0,12,
* Only write plane address (VEPU_REG_ADDR_IN_PLANE_0,1,2)
when needed.
* s/rockchip_vpu_jpeg_render/rockchip_vpu_jpeg_header_assemble
* Drop wmb() and use a writel, which has an implicit barrier.
* Added missing documentation for all structs.
* Removed unused struct fields.
* Simplified xfer_func et al usage.
* Reworked vepu_debug for i/o
* Explicitly enabled/disabled clocks before/after work,
instead of via the PM runtime infra.
* Copy buffer timecode only when required
* Bound check the amount of bytes transferred by the hardware.
* Remove useless void * cast.
* Fix race condition between top half and watchdog .
* Drop redundant check for v4l2_ctrl errors.
* Add rounding up in fill_fmt helpers.
* Remove unneeded DMA alignment implementation (needed only for
* USERPTR).
* Add check for different width and height in CAPTURE S_FMT.
* Remove check for peer busy queue in OUTPUT S_FMT.
* Remove double whitespace.
* Multi-line comments fixed.
* Google copyright fixed.
* Typos fixed.
v10:
* Fix SPDX syntax
* Add missing patch with binding documentation
* Remove white line in Kconfig
v9:
* Address some style comments from Hans.
* Fix TODO file
v8:
* Drop new JPEG_RAW format.
* Drop quantization table user controls.
* Add JPEG headers to produce JPEG frames.
Ezequiel Garcia (4):
media: dt-bindings: Document the Rockchip VPU bindings
ARM: dts: rockchip: add VPU device node for RK3288
arm64: dts: rockchip: add VPU device node for RK3399
media: add Rockchip VPU JPEG encoder driver
.../bindings/media/rockchip-vpu.txt | 29 +
MAINTAINERS | 7 +
arch/arm/boot/dts/rk3288.dtsi | 14 +-
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile| 1 +
drivers/staging/media/rockchip/vpu/Kconfig| 13 +
drivers/staging/media/rockchip/vpu/Makefile | 10 +
drivers/staging/media/rockchip/vpu/TODO | 13 +
.../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++
.../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 130
.../media/rockchip/vpu/rk3288_vpu_regs.h | 442
.../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++
.../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 164 +
.../media/rockchip/vpu/rk3399_vpu_regs.h | 600
.../staging/media/rockchip/vpu/rockchip_vpu.h | 232 ++
.../media/rockchip/vpu/rockchip_vpu_common.h | 29 +
.../media/rockchip/vpu/rockchip_vpu_drv.c | 531 ++
.../media/rockchip/vpu/rockchip_vpu_enc.c | 676 ++
.../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++
.../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290
.../media/rockchip/vpu/rockchip_vpu_jpeg.h| 14 +
22 files changed, 3503 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig
create mode 100644 drivers/staging/media/rockchip/vpu/Makefile
create mode 100644 drivers/staging/media/rockchip/vpu/TODO
create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c
create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h
create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c
create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c
create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h
create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h
create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h
create mode 1006
[PATCH v11 3/4] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Reviewed-by: Tomasz Figa
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..040d3080565f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1226,6 +1226,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.20.0.rc1
[PATCH v11 1/4] media: dt-bindings: Document the Rockchip VPU bindings
Add devicetree binding documentation for Rockchip Video Processing
Unit IP.
Reviewed-by: Rob Herring
Signed-off-by: Ezequiel Garcia
---
.../bindings/media/rockchip-vpu.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
new file mode 100644
index ..35dc464ad7c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
@@ -0,0 +1,29 @@
+device-tree bindings for rockchip VPU codec
+
+Rockchip (Video Processing Unit) present in various Rockchip platforms,
+such as RK3288 and RK3399.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-vpu";
+ "rockchip,rk3399-vpu";
+- interrupts: encoding and decoding interrupt specifiers
+- interrupt-names: should be "vepu" and "vdpu"
+- clocks: phandle to VPU aclk, hclk clocks
+- clock-names: should be "aclk" and "hclk"
+- power-domains: phandle to power domain node
+- iommus: phandle to a iommu node
+
+Example:
+SoC-specific DT entry:
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
--
2.20.0.rc1
Re: [PATCH v10 4/4] media: add Rockchip VPU JPEG encoder driver
On Tue, 2018-11-27 at 19:09 +0900, Tomasz Figa wrote:
> On Fri, Nov 23, 2018 at 5:24 AM Ezequiel Garcia
> wrote:
> [snip]
> > > > +const struct rockchip_vpu_variant rk3288_vpu_variant = {
> > > > + .enc_offset = 0x0,
> > > > + .enc_fmts = rk3288_vpu_enc_fmts,
> > > > + .num_enc_fmts = ARRAY_SIZE(rk3288_vpu_enc_fmts),
> > > > + .codec_ops = rk3288_vpu_codec_ops,
> > > > + .codec = RK_VPU_CODEC_JPEG,
> > > > + .vepu_irq = rk3288_vepu_irq,
> > > > + .init = rk3288_vpu_hw_init,
> > > > + .clk_names = {"aclk", "hclk"},
> > >
> > > nit: Spaces inside the brackets.
> > >
> >
> > You mean you this style is prefered?
> >
> > .clk_names = { "aclk", "hclk" },
> >
> > Grepping thru sources, it seems there is no convention on this,
> > so it's your call.
> >
>
> I thought this is a part of CodingStyle, but it doesn't seem to
> mention it. I personally prefer to have the spaces there, but we can
> go with your personal preferences here. :)
OK.
> [snip]
> > > > +* by .vidioc_s_fmt_vid_cap_mplane() callback
> > > > +*/
> > > > + reg = VEPU_REG_IN_IMG_CTRL_ROW_LEN(pix_fmt->width);
> > > > + vepu_write_relaxed(vpu, reg, VEPU_REG_INPUT_LUMA_INFO);
> > > > +
> > > > + reg = VEPU_REG_IN_IMG_CTRL_OVRFLR_D4(0) |
> > > > + VEPU_REG_IN_IMG_CTRL_OVRFLB(0);
> > >
> > > For reference, this register controls the input crop, as the offset
> > > from the right/bottom within the last macroblock. The offset from the
> > > right must be divided by 4 and so the crop must be aligned to 4 pixels
> > > horizontally.
> > >
> >
> > OK, I'll add a comment.
> >
>
> I meant to refer to the comment Hans had, about input images of
> resolutions that are not of full macroblocks, so the comment would
> probably go to the TODO file together with Hans's note.
Got it.
> [snip]
> > > > +static inline u32 vepu_read(struct rockchip_vpu_dev *vpu, u32 reg)
> > > > +{
> > > > + u32 val = readl(vpu->enc_base + reg);
> > > > +
> > > > + vpu_debug(6, "MARK: get reg[%03d]: %08x\n", reg / 4, val);
> > >
> > > I remember seeing this "MARK" in the logs when debugging. I don't
> > > think it's desired here.
> > >
> > > How about printing "%s(%03d) = %08x\n" for reads and "%s(%08x,
> > > %03d)\n" for writes?
>
> Actually, I missed the 0x prefix for hex values and possibly also
> changing the decimal register offset to hexadecimal:
> "%s(0x%04x) = 0x%08x\n"
>
> >
> > Makes sense, but why a %s string format?
> >
>
> For __func__, so that we end up with messages like:
>
> vepu_write(0x12345678, 0x0123)
> vepu_read(0x0123) = 0x12345678
>
vepu_debug already uses __func__, so it would look like this:
[ 27.125090] vepu_write_relaxed:215: 0x001f = 0x01010101
[ 27.127413] vepu_write:221: 0x0069 = 0xfc00
[ 27.129673] vepu_write_relaxed:215: 0x0036 = 0x1000
[ 27.132079] vepu_write:221: 0x0067 = 0x00f01461
[ 27.135042] vepu_read:229: 0x006d = 0x1003
[ 27.137450] vepu_read:229: 0x0035 = 0x00020318
[ 27.139778] vepu_write:221: 0x006d = 0x
[ 27.142144] vepu_write:221: 0x0036 = 0x
Unless we use a different debug macro for i/o access.
> [snip]
> > > > + dst->field = src->field;
> > > > + dst->timecode = src->timecode;
> > >
> > > Time code is only valid if the buffer has V4L2_BUF_FLAG_TIMECODE set.
> > > I don't think there is any use case for mem2mem devices for it.
> > >
> >
> > Right. Other mem2mem drivers seem to pass thru the timecode like this:
> >
> > if (in_vb->flags & V4L2_BUF_FLAG_TIMECODE)
> > out_vb->timecode = in_vb->timecode;
> >
> > It fails a v4l2-compliance test without it.
> >
>
> Hmm, I don't see the spec defining it to be copied by a mem2mem device
> and I wonder if it's actually of any use for those. Hans, could you
> comment on this?
>
I asked Hans about this and he said timecode should behave as timestamp,
and be carried from the output queue to the capture queue.
This helper will take care of it: https://patchwork.linuxtv.org/patch/52961/
> > > > + dst->vb2_buf.timestamp = src->vb2_buf.timestamp;
> > > > + dst->flags
[PATCH v2] v4l2-ioctl: Zero v4l2_plane_pix_format reserved fields
Make the core set the reserved fields to zero in
vv4l2_pix_format_mplane.4l2_plane_pix_format,
for _MPLANE queue types.
Moving this to the core avoids having to do so in each
and every driver.
Suggested-by: Tomasz Figa
Signed-off-by: Ezequiel Garcia
--
v2:
* Drop unneeded clear in g_fmt.
The sturct was already being cleared here.
* Only zero plane_fmt reserved fields.
* Use CLEAR_FIELD_MACRO.
drivers/media/v4l2-core/v4l2-ioctl.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index e384142d2826..2506b602481f 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1512,6 +1512,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
struct v4l2_format *p = arg;
struct video_device *vfd = video_devdata(file);
int ret = check_fmt(file, p->type);
+ int i;
if (ret)
return ret;
@@ -1536,6 +1537,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
@@ -1564,6 +1567,8 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_out_overlay))
@@ -1604,6 +1609,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
{
struct v4l2_format *p = arg;
int ret = check_fmt(file, p->type);
+ int i;
if (ret)
return ret;
@@ -1623,6 +1629,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_cap_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_overlay))
@@ -1651,6 +1659,8 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_try_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ CLEAR_AFTER_FIELD(p,
fmt.pix_mp.plane_fmt[i].bytesperline);
return ops->vidioc_try_fmt_vid_out_mplane(file, fh, arg);
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_try_fmt_vid_out_overlay))
--
2.19.1
Re: [PATCH] v4l2-ioctl: Zero v4l2_pix_format_mplane reserved fields
On Tue, 2018-11-27 at 16:59 +0900, Tomasz Figa wrote:
> On Tue, Nov 27, 2018 at 8:29 AM Ezequiel Garcia
> wrote:
> > On Mon, 2018-11-26 at 13:14 +0900, Tomasz Figa wrote:
> > > Hi Ezequiel,
> > >
> > > On Sat, Nov 24, 2018 at 2:20 AM Ezequiel Garcia
> > > wrote:
> > > > Make the core set the reserved fields to zero in
> > > > v4l2_pix_format_mplane and v4l2_plane_pix_format structs,
> > > > for _MPLANE queue types.
> > > >
> > > > Moving this to the core avoids having to do so in each
> > > > and every driver.
> > > >
> > > > Suggested-by: Tomasz Figa
> > > > Signed-off-by: Ezequiel Garcia
> > > > ---
> > > > drivers/media/v4l2-core/v4l2-ioctl.c | 51
> > > > 1 file changed, 45 insertions(+), 6 deletions(-)
> > > >
> > >
> > > Thanks for the patch. Please see my comments inline.
> > >
> > > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > index 10b862dcbd86..3858fffc3e68 100644
> > > > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > > > @@ -1420,6 +1420,7 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops
> > > > *ops,
> > > > {
> > > > struct v4l2_format *p = arg;
> > > > int ret = check_fmt(file, p->type);
> > > > + int i;
> > > >
> > > > if (ret)
> > > > return ret;
> > > > @@ -1458,7 +1459,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops
> > > > *ops,
> > > > p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
> > > > return ret;
> > > > case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> > > > - return ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
> > > > + ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
> > > > + memset(p->fmt.pix_mp.reserved, 0,
> > > > + sizeof(p->fmt.pix_mp.reserved));
> > > > + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> > > > + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> > > > +
> > > > sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
> > > > + return ret;
> > > > case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> > > > return ops->vidioc_g_fmt_vid_overlay(file, fh, arg);
> > > > case V4L2_BUF_TYPE_VBI_CAPTURE:
> > > > @@ -1474,7 +1481,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops
> > > > *ops,
> > > > p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
> > > > return ret;
> > > > case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > > > - return ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
> > > > + ret = ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
> > > > + memset(p->fmt.pix_mp.reserved, 0,
> > > > + sizeof(p->fmt.pix_mp.reserved));
> > > > + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> > > > + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> > > > +
> > > > sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
> > > > + return ret;
> > >
> > > I wonder if we need this for G_FMT. The driver can just memset() the
> > > whole struct itself and then just initialize the fields it cares
> > > about, but actually in many cases the driver will just include an
> > > instance of the pix_fmt(_mp) struct in its internal state (which has
> > > the reserved fields already zeroed) and just copy it to the target
> > > struct in the callback.
> > >
> >
> > Perhaps in many cases, but from code inspection it seems not
> > all of them (randomly opened vicodec & mtk-jpeg and both need
> > a memset!).
> >
> > I'm thinkig it'd best to keep it this way for consistency
> > and to avoid having the worry at all about this in the drivers.
>
> I guess it makes sense indeed. The structure isn't terribly big, so
> there shouldn't be any significant performance penalty I suppose.
Actually, after some experiments, I realized the entire v4l2_format struct
is already being memset to 0 in v4l_g_fmt.
Thanks,
Eze
Re: [PATCH] v4l2-ioctl: Zero v4l2_pix_format_mplane reserved fields
On Mon, 2018-11-26 at 13:14 +0900, Tomasz Figa wrote:
> Hi Ezequiel,
>
> On Sat, Nov 24, 2018 at 2:20 AM Ezequiel Garcia
> wrote:
> > Make the core set the reserved fields to zero in
> > v4l2_pix_format_mplane and v4l2_plane_pix_format structs,
> > for _MPLANE queue types.
> >
> > Moving this to the core avoids having to do so in each
> > and every driver.
> >
> > Suggested-by: Tomasz Figa
> > Signed-off-by: Ezequiel Garcia
> > ---
> > drivers/media/v4l2-core/v4l2-ioctl.c | 51
> > 1 file changed, 45 insertions(+), 6 deletions(-)
> >
>
> Thanks for the patch. Please see my comments inline.
>
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 10b862dcbd86..3858fffc3e68 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1420,6 +1420,7 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
> > {
> > struct v4l2_format *p = arg;
> > int ret = check_fmt(file, p->type);
> > + int i;
> >
> > if (ret)
> > return ret;
> > @@ -1458,7 +1459,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops
> > *ops,
> > p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
> > return ret;
> > case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
> > - return ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
> > + ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
> > + memset(p->fmt.pix_mp.reserved, 0,
> > + sizeof(p->fmt.pix_mp.reserved));
> > + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> > + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> > + sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
> > + return ret;
> > case V4L2_BUF_TYPE_VIDEO_OVERLAY:
> > return ops->vidioc_g_fmt_vid_overlay(file, fh, arg);
> > case V4L2_BUF_TYPE_VBI_CAPTURE:
> > @@ -1474,7 +1481,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops
> > *ops,
> > p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
> > return ret;
> > case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
> > - return ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
> > + ret = ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
> > + memset(p->fmt.pix_mp.reserved, 0,
> > + sizeof(p->fmt.pix_mp.reserved));
> > + for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
> > + memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
> > + sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
> > + return ret;
>
> I wonder if we need this for G_FMT. The driver can just memset() the
> whole struct itself and then just initialize the fields it cares
> about, but actually in many cases the driver will just include an
> instance of the pix_fmt(_mp) struct in its internal state (which has
> the reserved fields already zeroed) and just copy it to the target
> struct in the callback.
>
Perhaps in many cases, but from code inspection it seems not
all of them (randomly opened vicodec & mtk-jpeg and both need
a memset!).
I'm thinkig it'd best to keep it this way for consistency
and to avoid having the worry at all about this in the drivers.
Should we use CLEAR_AFTER_FIELD here as well?
> > case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
> > return ops->vidioc_g_fmt_vid_out_overlay(file, fh, arg);
> > case V4L2_BUF_TYPE_VBI_OUTPUT:
> > @@ -1512,6 +1525,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
> > struct v4l2_format *p = arg;
> > struct video_device *vfd = video_devdata(file);
> > int ret = check_fmt(file, p->type);
> > + int i;
> >
> > if (ret)
> > return ret;
> > @@ -1536,7 +1550,13 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops
> > *ops,
> > if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
> > break;
> > CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
> > - return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
> > + ret = ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
> > + memset(p->fmt.pix_mp.reserved, 0,
[PATCH] v4l2-ioctl: Zero v4l2_pix_format_mplane reserved fields
Make the core set the reserved fields to zero in
v4l2_pix_format_mplane and v4l2_plane_pix_format structs,
for _MPLANE queue types.
Moving this to the core avoids having to do so in each
and every driver.
Suggested-by: Tomasz Figa
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-ioctl.c | 51
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 10b862dcbd86..3858fffc3e68 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1420,6 +1420,7 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
{
struct v4l2_format *p = arg;
int ret = check_fmt(file, p->type);
+ int i;
if (ret)
return ret;
@@ -1458,7 +1459,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
return ret;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
- return ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
+ ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh, arg);
+ memset(p->fmt.pix_mp.reserved, 0,
+ sizeof(p->fmt.pix_mp.reserved));
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
+ sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
+ return ret;
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
return ops->vidioc_g_fmt_vid_overlay(file, fh, arg);
case V4L2_BUF_TYPE_VBI_CAPTURE:
@@ -1474,7 +1481,13 @@ static int v4l_g_fmt(const struct v4l2_ioctl_ops *ops,
p->fmt.pix.priv = V4L2_PIX_FMT_PRIV_MAGIC;
return ret;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
- return ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
+ ret = ops->vidioc_g_fmt_vid_out_mplane(file, fh, arg);
+ memset(p->fmt.pix_mp.reserved, 0,
+ sizeof(p->fmt.pix_mp.reserved));
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
+ sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
+ return ret;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
return ops->vidioc_g_fmt_vid_out_overlay(file, fh, arg);
case V4L2_BUF_TYPE_VBI_OUTPUT:
@@ -1512,6 +1525,7 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
struct v4l2_format *p = arg;
struct video_device *vfd = video_devdata(file);
int ret = check_fmt(file, p->type);
+ int i;
if (ret)
return ret;
@@ -1536,7 +1550,13 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_cap_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
- return ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
+ ret = ops->vidioc_s_fmt_vid_cap_mplane(file, fh, arg);
+ memset(p->fmt.pix_mp.reserved, 0,
+ sizeof(p->fmt.pix_mp.reserved));
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
+ sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
+ return ret;
case V4L2_BUF_TYPE_VIDEO_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_overlay))
break;
@@ -1564,7 +1584,13 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops,
if (unlikely(!ops->vidioc_s_fmt_vid_out_mplane))
break;
CLEAR_AFTER_FIELD(p, fmt.pix_mp.xfer_func);
- return ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
+ ret = ops->vidioc_s_fmt_vid_out_mplane(file, fh, arg);
+ memset(p->fmt.pix_mp.reserved, 0,
+ sizeof(p->fmt.pix_mp.reserved));
+ for (i = 0; i < p->fmt.pix_mp.num_planes; i++)
+ memset(p->fmt.pix_mp.plane_fmt[i].reserved, 0,
+ sizeof(p->fmt.pix_mp.plane_fmt[i].reserved));
+ return ret;
case V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY:
if (unlikely(!ops->vidioc_s_fmt_vid_out_overlay))
break;
@@ -1604,6 +1630,7 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
{
struct v4l2_format *p = arg;
int ret = check_fmt(file, p->type);
+ int i;
if (ret)
return ret;
@@ -1623,7 +1650,13 @@ static int v4l_try_fmt(const struct v4l2_ioctl_ops *ops,
Re: [PATCH v10 4/4] media: add Rockchip VPU JPEG encoder driver
On Thu, 2018-11-22 at 19:20 +0900, Tomasz Figa wrote:
> Hi Ezequiel,
>
> On Thu, Nov 22, 2018 at 4:59 AM Ezequiel Garcia
> wrote:
> > Add a mem2mem driver for the VPU available on Rockchip SoCs.
> > Currently only JPEG encoding is supported, for RK3399 and RK3288
> > platforms.
> >
> > Signed-off-by: Ezequiel Garcia
>
> Sorry for being late to the party. Please see my comments inline.
>
No problem! Thanks for the detailed review.
> [snip]
> > diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
> > b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
> > new file mode 100644
> > index ..75b7abbd3aca
> > --- /dev/null
> > +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c
> > @@ -0,0 +1,118 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Rockchip VPU codec driver
> > + *
> > + * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
> > + * Jeffy Chen
> > + */
> > +
> > +#include
> > +
> > +#include "rockchip_vpu.h"
> > +#include "rockchip_vpu_jpeg.h"
> > +#include "rk3288_vpu_regs.h"
> > +
> > +#define RK3288_ACLK_MAX_FREQ (400 * 1000 * 1000)
> > +
> > +/*
> > + * Supported formats.
> > + */
> > +
> > +static const struct rockchip_vpu_fmt rk3288_vpu_enc_fmts[] = {
> > + {
> > + .fourcc = V4L2_PIX_FMT_YUV420M,
> > + .codec_mode = RK_VPU_MODE_NONE,
> > + .enc_fmt = RK3288_VPU_ENC_FMT_YUV420P,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_NV12M,
> > + .codec_mode = RK_VPU_MODE_NONE,
> > + .enc_fmt = RK3288_VPU_ENC_FMT_YUV420SP,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_YUYV,
> > + .codec_mode = RK_VPU_MODE_NONE,
> > + .enc_fmt = RK3288_VPU_ENC_FMT_YUYV422,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_UYVY,
> > + .codec_mode = RK_VPU_MODE_NONE,
> > + .enc_fmt = RK3288_VPU_ENC_FMT_UYVY422,
> > + },
> > + {
> > + .fourcc = V4L2_PIX_FMT_JPEG,
> > + .codec_mode = RK_VPU_MODE_JPEG_ENC,
> > + .max_depth = 2,
> > + .header_size = JPEG_HEADER_SIZE,
> > + .frmsize = {
> > + .min_width = 96,
> > + .max_width = 8192,
> > + .step_width = MB_DIM,
> > + .min_height = 32,
> > + .max_height = 8192,
> > + .step_height = MB_DIM,
> > + },
> > + },
> > +};
> > +
> > +static irqreturn_t rk3288_vepu_irq(int irq, void *dev_id)
> > +{
> > + struct rockchip_vpu_dev *vpu = dev_id;
> > + enum vb2_buffer_state state;
> > + u32 status, bytesused;
> > +
> > + status = vepu_read(vpu, VEPU_REG_INTERRUPT);
> > + bytesused = vepu_read(vpu, VEPU_REG_STR_BUF_LIMIT) / 8;
> > + state = (status & VEPU_REG_INTERRUPT_FRAME_RDY) ?
> > + VB2_BUF_STATE_DONE : VB2_BUF_STATE_ERROR;
> > +
> > + vepu_write(vpu, 0, VEPU_REG_INTERRUPT);
> > + vepu_write(vpu, 0, VEPU_REG_AXI_CTRL);
> > +
> > + rockchip_vpu_irq_done(vpu, bytesused, state);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int rk3288_vpu_hw_init(struct rockchip_vpu_dev *vpu)
> > +{
> > + /* Bump ACLK to max. possible freq. to improve performance. */
> > + clk_set_rate(vpu->clocks[0].clk, RK3288_ACLK_MAX_FREQ);
> > + return 0;
> > +}
> > +
> > +static void rk3288_vpu_enc_reset(struct rockchip_vpu_ctx *ctx)
> > +{
> > + struct rockchip_vpu_dev *vpu = ctx->dev;
> > +
> > + vepu_write(vpu, VEPU_REG_INTERRUPT_DIS_BIT, VEPU_REG_INTERRUPT);
> > + vepu_write(vpu, 0, VEPU_REG_ENC_CTRL);
> > + vepu_write(vpu, 0, VEPU_REG_AXI_CTRL);
> > +}
> > +
> > +/*
> > + * Supported codec ops.
> > + */
> > +
> > +static const struct rockchip_vpu_codec_ops rk3288_vpu_codec_ops[] = {
> > + [RK_VPU_MODE_JPEG_ENC] = {
> > + .run = rk3288_vpu_jpeg_enc_run,
> > + .reset = rk3288_vpu_enc_reset,
> > + },
> > +};
> > +
> > +/*
> > + * VPU variant.
> > + */
> > +
> > +const struct rockchip_vpu_var
[PATCH v10 4/4] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 6 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 702 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 14 + 19 files changed, 3475 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index a8588dedc683..e5a294453393 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12742,6 +12742,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..9a6fc1378242 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,13 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..e9d733bb7632 --- /dev/
[PATCH v10 3/4] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..040d3080565f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1226,6 +1226,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.19.1
[PATCH v10 0/4] Add Rockchip VPU JPEG encoder
This series is based on Mauro's master branch, with the following patch applied: https://patchwork.kernel.org/patch/10676149/ Hans, If you think the driver is now ready, I'd like to merge only patches 1/4 and 4/4 (the driver per-se) via the media tree. The devicetree changes could go via Heiko's tree. v10: * Fix SPDX syntax * Add missing patch with binding documentation * Remove white line in Kconfig v9: * Address some style comments from Hans. * Fix TODO file v8: * Drop new JPEG_RAW format. * Drop quantization table user controls. * Add JPEG headers to produce JPEG frames. Ezequiel Garcia (4): media: dt-bindings: Document the Rockchip VPU bindings ARM: dts: rockchip: add VPU device node for RK3288 arm64: dts: rockchip: add VPU device node for RK3399 media: add Rockchip VPU JPEG encoder driver .../bindings/media/rockchip-vpu.txt | 29 + MAINTAINERS | 7 + arch/arm/boot/dts/rk3288.dtsi | 14 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +- drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 6 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 702 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 290 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 14 + 22 files changed, 3530 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h -- 2.19.1
[PATCH v10 1/4] media: dt-bindings: Document the Rockchip VPU bindings
Add devicetree binding documentation for Rockchip Video Processing
Unit IP.
Reviewed-by: Rob Herring
Signed-off-by: Ezequiel Garcia
---
.../bindings/media/rockchip-vpu.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
new file mode 100644
index ..35dc464ad7c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
@@ -0,0 +1,29 @@
+device-tree bindings for rockchip VPU codec
+
+Rockchip (Video Processing Unit) present in various Rockchip platforms,
+such as RK3288 and RK3399.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-vpu";
+ "rockchip,rk3399-vpu";
+- interrupts: encoding and decoding interrupt specifiers
+- interrupt-names: should be "vepu" and "vdpu"
+- clocks: phandle to VPU aclk, hclk clocks
+- clock-names: should be "aclk" and "hclk"
+- power-domains: phandle to power domain node
+- iommus: phandle to a iommu node
+
+Example:
+SoC-specific DT entry:
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
--
2.19.1
[PATCH v10 2/4] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.19.1
[PATCH v9 3/3] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 14 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 6 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 702 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 +++ .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + 19 files changed, 3473 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index a8588dedc683..e5a294453393 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12742,6 +12742,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..fa65c03d65bf --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,14 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. + diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..e9d733bb7632 --- /dev/
[PATCH v9 2/3] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..040d3080565f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1226,6 +1226,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.19.1
[PATCH v9 1/3] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.19.1
[PATCH v9 0/3] Add Rockchip VPU JPEG encoder
test VIDIOC_EXPBUF: OK Test input 0: Streaming ioctls: test read/write: OK (Not Supported) test blocking wait: OK Video Capture Multiplanar: Captured 57 buffers test MMAP: OK test USERPTR: OK (Not Supported) test DMABUF: Cannot test, specify --expbuf-device Total: 48, Succeeded: 48, Failed: 0, Warnings: 0 Ezequiel Garcia (3): ARM: dts: rockchip: add VPU device node for RK3288 arm64: dts: rockchip: add VPU device node for RK3399 media: add Rockchip VPU JPEG encoder driver MAINTAINERS | 7 + arch/arm/boot/dts/rk3288.dtsi | 14 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +- drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 14 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 6 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 702 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 +++ .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + 21 files changed, 3499 insertions(+), 2 deletions(-) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h -- 2.19.1
Re: [PATCH v8 3/3] media: add Rockchip VPU JPEG encoder driver
On Tue, 2018-11-20 at 14:52 +0100, Hans Verkuil wrote: > On 11/19/2018 04:29 PM, Ezequiel Garcia wrote: > > Add a mem2mem driver for the VPU available on Rockchip SoCs. > > Currently only JPEG encoding is supported, for RK3399 and RK3288 > > platforms. > > > > Signed-off-by: Ezequiel Garcia > > --- > > MAINTAINERS | 7 + > > drivers/staging/media/Kconfig | 2 + > > drivers/staging/media/Makefile| 1 + > > drivers/staging/media/rockchip/vpu/Kconfig| 14 + > > drivers/staging/media/rockchip/vpu/Makefile | 10 + > > drivers/staging/media/rockchip/vpu/TODO | 9 + > > .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ > > .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 > > .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ > > .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ > > .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 > > .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ > > .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ > > .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + > > .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + > > .../media/rockchip/vpu/rockchip_vpu_enc.c | 701 ++ > > .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ > > .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 > > .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + > > 19 files changed, 3475 insertions(+) > > create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig > > create mode 100644 drivers/staging/media/rockchip/vpu/Makefile > > create mode 100644 drivers/staging/media/rockchip/vpu/TODO > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c > > create mode 100644 > > drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c > > create mode 100644 > > drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c > > create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index a8588dedc683..e5a294453393 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -12742,6 +12742,13 @@ S: Maintained > > F: drivers/media/platform/rockchip/rga/ > > F: Documentation/devicetree/bindings/media/rockchip-rga.txt > > > > +ROCKCHIP VPU CODEC DRIVER > > +M: Ezequiel Garcia > > +L: linux-media@vger.kernel.org > > +S: Maintained > > +F: drivers/staging/media/platform/rockchip/vpu/ > > +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt > > + > > ROCKER DRIVER > > M: Jiri Pirko > > L: net...@vger.kernel.org > > diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig > > index b3620a8f2d9f..c6f3404dea43 100644 > > --- a/drivers/staging/media/Kconfig > > +++ b/drivers/staging/media/Kconfig > > @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" > > > > source "drivers/staging/media/omap4iss/Kconfig" > > > > +source "drivers/staging/media/rockchip/vpu/Kconfig" > > + > > source "drivers/staging/media/sunxi/Kconfig" > > > > source "drivers/staging/media/tegra-vde/Kconfig" > > diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile > > index 42948f805548..43c7bee1fc8c 100644 > > --- a/drivers/staging/media/Makefile > > +++ b/drivers/staging/media/Makefile > > @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ > > obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ > > obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ > > obj-$(CONFIG_VIDEO_ZORAN) += zoran/ > > +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ > > diff --git a/drivers/staging/media/rockchip/vpu/Kconfig > > b/drivers
Re: [ANN] Edinburgh Media Summit 2018 meeting report
Hello everyone, And thanks for the detailed report! On Mon, 2018-11-19 at 13:09 +0900, Tomasz Figa wrote: > On Sun, Nov 18, 2018 at 7:45 AM Sakari Ailus wrote: > > Hello everyone, > > > > > > Here's the report on the Media Summit held on 25th October in Edinburgh. > > The report is followed by the stateless codec discussion two days earlier. > > > > Note: this is bcc'd to the meeting attendees plus a few others. I didn't > > use cc as the list servers tend to reject messages with too many > > recipients in cc / to headers. > > > > Most presenters used slides some of which are already available here > > (expect more in the near future): > > > > https://www.linuxtv.org/downloads/presentations/media_summit_2018/> > > > > The original announcement for the meeting is here: > > > > https://www.spinics.net/lists/linux-media/msg141095.html> > > > > The raw notes can be found here: > > > > http://www.retiisi.org.uk/~sailus/v4l2/notes/osseu18-media.html> > > Thanks Sakari for editing the notes. Let me share my thoughts inline. > > [snip] > > Automated testing - Ezequiel Garcia > > --- > > > > Ideal Continuous Integration process consists of the following steps: > > > > 1. patch submission > > 2. review and approval > > 3. merge > > > > The core question is "what level of quality standards do we want to > > enforce". The maintenance process should be modelled around this question, > > and not the other way around. Automated testing can be a part of enforcing > > the quality standards. > > > > There are three steps: > > > > 1. Define the quality standard > > 2. Define how to quantify quality in respect to the standard > > 3. Define how to enforce the standards > > > > On the tooling side, an uAPI test tool exists. It's called v4l2-compliance, > > and new drivers are required to pass the v4l2-compliance test. > > It has quite a few favourable properties: > > > > - Complete in terms of the uAPI coverage > > - Quick and easy to run > > - Nice output format for humans & scripts > > > > There are some issues as well: > > > > - No codec support (stateful or stateless) > > - No SDR or touch support > > - Frequently updated (distribution shipped v4l2-compliance useless) > > - Only one contributor > > > > Ezequiel noted that some people think that v4l2-compliance is changing too > > often but Hans responded that this is a necessity. The API gets amended > > occasionally and the existing API gets new tests. Mauro proposed moving > > v4l2-compliance to the kernel source tree but Hans preferred keeping it > > separate. That way it's easier to develop it. > > > > To address the problem of only a single contributor, it was suggested that > > people implementing new APIs would need to provide the tests for > > v4l2-compliance as well. To achieve this, the v4l2-compliance codebase > > needs some cleanup to make it easier to contribute. The codebase is larger > > and there is no documentation. > > > > V4l2-compliance also covers MC, V4L2 and V4L2 sub-device uAPIs. > > > > DVB will require its own test tooling; it is not covered by > > v4l2-compliance. In order to facilitate automated testing, a virtual DVB > > driver would be useful as well. The task was added to the list of projects > > needing volunteers: > > > > https://linuxtv.org/wiki/index.php/Media_Open_Source_Projects:_Looking_for_Volunteers> > > > > There are some other test tools that could cover V4L2 but at the moment it > > seems somewhat far-fetched any of them would be used to test V4L2 in the > > near future: > > > > - kselftest > > - kunit > > - gst-validate > > - ktf (https://github.com/oracle/ktf, > > http://heim.ifi.uio.no/~knuto/ktf/) > > > > KernelCI is a test automation system that supports automated compile and > > boot testing. As a newly added feature, additional tests may be > > implemented. This is what Collabora has implemented, effectively the > > current demo system runs v4l2-compliance on virtual drivers in a virtual > > machines (LAVA slaves). > > > > A sample of the current test report is here: > > > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg135787.html> > > > > The established way to run KernelCI tests is off the head of the branches of > > the stable a
Re: [PATCH] videobuf2-v4l2: drop WARN_ON in vb2_warn_zero_bytesused()
On Mon, 2018-11-19 at 16:33 +0100, Hans Verkuil wrote:
> Userspace shouldn't set bytesused to 0 for output buffers.
> vb2_warn_zero_bytesused() warns about this (only once!), but it also
> calls WARN_ON(1), which is confusing since it is not immediately clear
> that it warns about a 0 value for bytesused.
>
> Just drop the WARN_ON as it serves no purpose.
>
> Signed-off-by: Hans Verkuil
Acked-by: Ezequiel Garcia
> ---
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index a17033ab2c22..713326ef4e72 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -158,7 +158,6 @@ static void vb2_warn_zero_bytesused(struct vb2_buffer *vb)
> return;
>
> check_once = true;
> - WARN_ON(1);
>
> pr_warn("use of bytesused == 0 is deprecated and will be removed in the
> future,\n");
> if (vb->vb2_queue->allow_zero_bytesused)
[PATCH v8 3/3] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 14 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 9 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 701 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + 19 files changed, 3475 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h diff --git a/MAINTAINERS b/MAINTAINERS index a8588dedc683..e5a294453393 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12742,6 +12742,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..fa65c03d65bf --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,14 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select VIDEOBUF2_VMALLOC + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. + diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..e9d733bb7632 --- /dev/
[PATCH v8 2/3] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 99e7f65c1779..040d3080565f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1226,6 +1226,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1233,8 +1245,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.19.1
[PATCH v8 1/3] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.19.1
[PATCH v8 0/3] Add Rockchip VPU JPEG encoder
Composing: OK (Not Supported) test Scaling: OK Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Test input 0: Streaming ioctls: test read/write: OK (Not Supported) test blocking wait: OK Video Capture Multiplanar: Captured 57 buffers test MMAP: OK test USERPTR: OK (Not Supported) test DMABUF: Cannot test, specify --expbuf-device Total: 48, Succeeded: 48, Failed: 0, Warnings: 0 Ezequiel Garcia (3): ARM: dts: rockchip: add VPU device node for RK3288 arm64: dts: rockchip: add VPU device node for RK3399 media: add Rockchip VPU JPEG encoder driver MAINTAINERS | 7 + arch/arm/boot/dts/rk3288.dtsi | 14 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +- drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 14 + drivers/staging/media/rockchip/vpu/Makefile | 10 + drivers/staging/media/rockchip/vpu/TODO | 9 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 133 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 +++ .../media/rockchip/vpu/rk3399_vpu_hw.c| 118 +++ .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 160 .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 +++ .../staging/media/rockchip/vpu/rockchip_vpu.h | 237 ++ .../media/rockchip/vpu/rockchip_vpu_common.h | 29 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 535 + .../media/rockchip/vpu/rockchip_vpu_enc.c | 701 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 58 ++ .../media/rockchip/vpu/rockchip_vpu_jpeg.c| 289 .../media/rockchip/vpu/rockchip_vpu_jpeg.h| 12 + 21 files changed, 3501 insertions(+), 2 deletions(-) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_jpeg.h -- 2.19.1
[PATCH] v4l2-compliance: Remove spurious error messages
Get rid of a couple confusing error messages, namely:
test VIDIOC_G_FMT: OK
fail: v4l2-test-formats.cpp(464): pix_mp.plane_fmt[0].reserved
not zeroed
fail: v4l2-test-formats.cpp(752): Video Output Multiplanar is
valid, but TRY_FMT failed to return a format
test VIDIOC_TRY_FMT: FAIL
fail: v4l2-test-formats.cpp(464): pix_mp.plane_fmt[0].reserved
not zeroed
fail: v4l2-test-formats.cpp(1017): Video Output Multiplanar is
valid, but no S_FMT was implemented
test VIDIOC_S_FMT: FAI
Where only the first message "pix_mp.plane_fmt[0].reserved not zeroed"
is accurate.
Signed-off-by: Ezequiel Garcia
---
utils/v4l2-compliance/v4l2-test-formats.cpp | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/utils/v4l2-compliance/v4l2-test-formats.cpp
b/utils/v4l2-compliance/v4l2-test-formats.cpp
index 2fb811ad5eb4..006cc3222c65 100644
--- a/utils/v4l2-compliance/v4l2-test-formats.cpp
+++ b/utils/v4l2-compliance/v4l2-test-formats.cpp
@@ -748,8 +748,7 @@ int testTryFormats(struct node *node)
}
ret = testFormatsType(node, ret, type, fmt, true);
if (ret)
- return fail("%s is valid, but TRY_FMT failed to return
a format\n",
- buftype2s(type).c_str());
+ return ret;
}
memset(, 0, sizeof(fmt));
@@ -1013,8 +1012,7 @@ int testSetFormats(struct node *node)
}
ret = testFormatsType(node, ret, type, fmt_set, true);
if (ret)
- return fail("%s is valid, but no S_FMT was
implemented\n",
- buftype2s(type).c_str());
+ return ret;
fmt_set = fmt;
ret = doioctl(node, VIDIOC_S_FMT, _set);
--
2.19.1
Re: [PATCH v5 0/5] Make sure .device_run is always called in non-atomic context
On Mon, 12 Nov 2018 at 13:52, Paul Kocialkowski wrote: > > Hi, > > On Sun, 2018-11-11 at 18:26 -0300, Ezequiel Garcia wrote: > > On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote: > > > This series goal is to avoid drivers from having ad-hoc code > > > to call .device_run in non-atomic context. Currently, .device_run > > > can be called via v4l2_m2m_job_finish(), not only running > > > in interrupt context, but also creating a nasty re-entrant > > > path into mem2mem drivers. > > > > > > The proposed solution is to add a per-device worker that is scheduled > > > by v4l2_m2m_job_finish, which replaces drivers having a threaded interrupt > > > or similar. > > > > > > This change allows v4l2_m2m_job_finish() to be called in interrupt > > > context, separating .device_run and v4l2_m2m_job_finish() contexts. > > > > > > It's worth mentioning that v4l2_m2m_cancel_job() doesn't need > > > to flush or cancel the new worker, because the job_spinlock > > > synchronizes both and also because the core prevents simultaneous > > > jobs. Either v4l2_m2m_cancel_job() will wait for the worker, or the > > > worker will be unable to run a new job. > > > > > > Patches apply on top of Request API and the Cedrus VPU > > > driver. > > > > > > Tested with cedrus driver using v4l2-request-test and > > > vicodec driver using gstreamer. > > > > > > Ezequiel Garcia (4): > > > mem2mem: Require capture and output mutexes to match > > > v4l2-ioctl.c: Simplify locking for m2m devices > > > v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish > > > media: cedrus: Get rid of interrupt bottom-half > > > > > > Sakari Ailus (1): > > > v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule > > > > > > drivers/media/v4l2-core/v4l2-ioctl.c | 47 + > > > drivers/media/v4l2-core/v4l2-mem2mem.c| 66 --- > > > .../staging/media/sunxi/cedrus/cedrus_hw.c| 26 ++-- > > > 3 files changed, 51 insertions(+), 88 deletions(-) > > > > > > > Hans, Maxime: > > > > Any feedback for this? > > I just tested the whole series with the cedrus driver and everything > looks good! > Good! So this means we can add a Tested-by for the entire series? > Removing the interrupt bottom-half in favor of a workqueue in the core > seems like a good way to simplify m2m driver development by avoiding > per-driver workqueues or threaded irqs. > Thanks for the test! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar
Re: [PATCH v5 0/5] Make sure .device_run is always called in non-atomic context
On Thu, 2018-10-18 at 15:02 -0300, Ezequiel Garcia wrote: > This series goal is to avoid drivers from having ad-hoc code > to call .device_run in non-atomic context. Currently, .device_run > can be called via v4l2_m2m_job_finish(), not only running > in interrupt context, but also creating a nasty re-entrant > path into mem2mem drivers. > > The proposed solution is to add a per-device worker that is scheduled > by v4l2_m2m_job_finish, which replaces drivers having a threaded interrupt > or similar. > > This change allows v4l2_m2m_job_finish() to be called in interrupt > context, separating .device_run and v4l2_m2m_job_finish() contexts. > > It's worth mentioning that v4l2_m2m_cancel_job() doesn't need > to flush or cancel the new worker, because the job_spinlock > synchronizes both and also because the core prevents simultaneous > jobs. Either v4l2_m2m_cancel_job() will wait for the worker, or the > worker will be unable to run a new job. > > Patches apply on top of Request API and the Cedrus VPU > driver. > > Tested with cedrus driver using v4l2-request-test and > vicodec driver using gstreamer. > > Ezequiel Garcia (4): > mem2mem: Require capture and output mutexes to match > v4l2-ioctl.c: Simplify locking for m2m devices > v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish > media: cedrus: Get rid of interrupt bottom-half > > Sakari Ailus (1): > v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule > > drivers/media/v4l2-core/v4l2-ioctl.c | 47 + > drivers/media/v4l2-core/v4l2-mem2mem.c| 66 --- > .../staging/media/sunxi/cedrus/cedrus_hw.c| 26 ++-- > 3 files changed, 51 insertions(+), 88 deletions(-) > Hans, Maxime: Any feedback for this? Thanks, Eze
Re: [RFC v2 1/4] media: Introduce helpers to fill pixel format structs
On Fri, 2018-11-02 at 12:52 -0300, Ezequiel Garcia wrote:
> Add two new API helpers, v4l2_fill_pixfmt and v4l2_fill_pixfmt_mp,
> to be used by drivers to calculate plane sizes and bytes per lines.
>
> Note that driver-specific paddig and alignment are not yet
> taken into account.
>
> Signed-off-by: Ezequiel Garcia
> ---
Heads-up: I plan to submit a new version of this patch, as part of
the VPU JPEG patchset.
Thanks,
Ezequiel
> drivers/media/v4l2-core/Makefile | 2 +-
> drivers/media/v4l2-core/v4l2-common.c | 66 +++
> drivers/media/v4l2-core/v4l2-fourcc.c | 93 +++
> include/media/v4l2-common.h | 5 ++
> include/media/v4l2-fourcc.h | 53 +++
> 5 files changed, 218 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/v4l2-core/v4l2-fourcc.c
> create mode 100644 include/media/v4l2-fourcc.h
>
> diff --git a/drivers/media/v4l2-core/Makefile
> b/drivers/media/v4l2-core/Makefile
> index 9ee57e1efefe..bc23c3407c17 100644
> --- a/drivers/media/v4l2-core/Makefile
> +++ b/drivers/media/v4l2-core/Makefile
> @@ -7,7 +7,7 @@ tuner-objs:= tuner-core.o
>
> videodev-objs:= v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o
> \
> v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
> - v4l2-async.o
> + v4l2-async.o v4l2-fourcc.o
> ifeq ($(CONFIG_COMPAT),y)
>videodev-objs += v4l2-compat-ioctl32.o
> endif
> diff --git a/drivers/media/v4l2-core/v4l2-common.c
> b/drivers/media/v4l2-core/v4l2-common.c
> index 50763fb42a1b..97bb51d15188 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -61,6 +61,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -455,3 +456,68 @@ int v4l2_s_parm_cap(struct video_device *vdev,
> return ret;
> }
> EXPORT_SYMBOL_GPL(v4l2_s_parm_cap);
> +
> +void v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, int
> pixelformat, int width, int height)
> +{
> + const struct v4l2_format_info *info;
> + struct v4l2_plane_pix_format *plane;
> + int i;
> +
> + info = v4l2_format_info(pixelformat);
> + if (!info)
> + return;
> +
> + pixfmt->width = width;
> + pixfmt->height = height;
> + pixfmt->pixelformat = pixelformat;
> +
> + if (info->has_contiguous_planes) {
> + pixfmt->num_planes = 1;
> + plane = >plane_fmt[0];
> + plane->bytesperline = info->is_compressed ?
> + 0 : width * info->cpp[0];
> + plane->sizeimage = info->header_size;
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int hsub = (i == 0) ? 1 : info->hsub;
> + unsigned int vsub = (i == 0) ? 1 : info->vsub;
> +
> + plane->sizeimage += width * height * info->cpp[i] /
> (hsub * vsub);
> + }
> + } else {
> + pixfmt->num_planes = info->num_planes;
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int hsub = (i == 0) ? 1 : info->hsub;
> + unsigned int vsub = (i == 0) ? 1 : info->vsub;
> +
> + plane = >plane_fmt[i];
> + plane->bytesperline = width * info->cpp[i] / hsub;
> + plane->sizeimage = width * height * info->cpp[i] /
> (hsub * vsub);
> + }
> + }
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_mp);
> +
> +void v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, int pixelformat, int
> width, int height)
> +{
> + const struct v4l2_format_info *info;
> + char name[32];
> + int i;
> +
> + pixfmt->width = width;
> + pixfmt->height = height;
> + pixfmt->pixelformat = pixelformat;
> +
> + info = v4l2_format_info(pixelformat);
> + if (!info)
> + return;
> + pixfmt->bytesperline = info->is_compressed ? 0 : width * info->cpp[0];
> +
> + pixfmt->sizeimage = info->header_size;
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int hsub = (i == 0) ? 1 : info->hsub;
> + unsigned int vsub = (i == 0) ? 1 : info->vsub;
> +
> + pixfmt->sizeimage += width * height * info->cpp[i] / (hsub *
> vsub);
> + }
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt);
> diff --git a/drivers/media/v4l2-core/v4l2-fourcc.c
> b/drivers/media/v4l2-core/v4l2-
Re: [PATCH v4l-utils] Introduce v4l2-get-device tool
On Sat, 2018-11-10 at 12:09 +0100, Hans Verkuil wrote: > On 11/10/2018 12:01 PM, Ezequiel Garcia wrote: > > On Sat, 2018-11-10 at 11:29 +0100, Hans Verkuil wrote: > > > On 11/09/2018 10:52 PM, Ezequiel Garcia wrote: > > > > This tool allows to find a device by driver name, > > > > this is useful for scripts to be written in a generic way. > > > > > > Why not add support for this to v4l2-sysfs-path? And improve it at the > > > same > > > time (swradio devices do not show up when I run v4l2-sysfs-path, I also > > > suspect > > > v4l-touch devices aren't recognized. Ditto for media devices. > > > > > > > I can add the functionality to v4l2-sysfs-path, and we can document > > the rest in some TODO list, as I don't think we need to get everything > > solved right now :-) > > I agree with that. > Great! About adding it to v4l2-sysfs-path, is there any scenario where we'll want to use udev-based scanning instead of sysfs-based? Maybe we can rename the tool, and still install a v4l2-sysfs-path alias? > > > > Usage: > > > > > > > > v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE > > > > /dev/video0 > > > > /dev/video2 > > > > > > > > Signed-off-by: Ezequiel Garcia > > > > --- > > > > configure.ac| 1 + > > > > utils/Makefile.am | 1 + > > > > utils/v4l2-get-device/.gitignore| 1 + > > > > utils/v4l2-get-device/Makefile.am | 4 + > > > > utils/v4l2-get-device/v4l2-get-device.c | 147 > > > > v4l-utils.spec.in | 1 + > > > > 6 files changed, 155 insertions(+) > > > > create mode 100644 utils/v4l2-get-device/.gitignore > > > > create mode 100644 utils/v4l2-get-device/Makefile.am > > > > create mode 100644 utils/v4l2-get-device/v4l2-get-device.c > > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index 5cc34c248fbf..918cb59704b9 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile > > > > utils/v4l2-compliance/Makefile > > > > utils/v4l2-ctl/Makefile > > > > utils/v4l2-dbg/Makefile > > > > + utils/v4l2-get-device/Makefile > > > > utils/v4l2-sysfs-path/Makefile > > > > utils/qv4l2/Makefile > > > > utils/cec-ctl/Makefile > > > > diff --git a/utils/Makefile.am b/utils/Makefile.am > > > > index 2d5070288c13..2b2b27107d13 100644 > > > > --- a/utils/Makefile.am > > > > +++ b/utils/Makefile.am > > > > @@ -9,6 +9,7 @@ SUBDIRS = \ > > > > v4l2-compliance \ > > > > v4l2-ctl \ > > > > v4l2-dbg \ > > > > + v4l2-get-device \ > > > > v4l2-sysfs-path \ > > > > cec-ctl \ > > > > cec-compliance \ > > > > diff --git a/utils/v4l2-get-device/.gitignore > > > > b/utils/v4l2-get-device/.gitignore > > > > new file mode 100644 > > > > index ..b222144c9f4e > > > > --- /dev/null > > > > +++ b/utils/v4l2-get-device/.gitignore > > > > @@ -0,0 +1 @@ > > > > +v4l2-get-device > > > > diff --git a/utils/v4l2-get-device/Makefile.am > > > > b/utils/v4l2-get-device/Makefile.am > > > > new file mode 100644 > > > > index ..2e5a6e0ba32f > > > > --- /dev/null > > > > +++ b/utils/v4l2-get-device/Makefile.am > > > > @@ -0,0 +1,4 @@ > > > > +bin_PROGRAMS = v4l2-get-device > > > > +v4l2_get_device_SOURCES = v4l2-get-device.c > > > > +v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la > > > > +v4l2_get_device_LDFLAGS = $(ARGP_LIBS) > > > > diff --git a/utils/v4l2-get-device/v4l2-get-device.c > > > > b/utils/v4l2-get-device/v4l2-get-device.c > > > > new file mode 100644 > > > > index ..f9cc323b7057 > > > > --- /dev/null > > > > +++ b/utils/v4l2-get-device/v4l2-get-device.c > > > > @@ -0,0 +1,147 @@ > > > > +/* > > > > + * Copyright © 2018 Collabora, Ltd. > > > > + * > > > > + * Based on v4l2-sysfs-path by Mauro Carvalho Chehab: > > > > + * > > > > + * Copyright © 2011 Red Hat,
Re: [PATCH v4l-utils] Introduce v4l2-get-device tool
On Sat, 2018-11-10 at 11:29 +0100, Hans Verkuil wrote: > On 11/09/2018 10:52 PM, Ezequiel Garcia wrote: > > This tool allows to find a device by driver name, > > this is useful for scripts to be written in a generic way. > > Why not add support for this to v4l2-sysfs-path? And improve it at the same > time (swradio devices do not show up when I run v4l2-sysfs-path, I also > suspect > v4l-touch devices aren't recognized. Ditto for media devices. > I can add the functionality to v4l2-sysfs-path, and we can document the rest in some TODO list, as I don't think we need to get everything solved right now :-) > > Usage: > > > > v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE > > /dev/video0 > > /dev/video2 > > > > Signed-off-by: Ezequiel Garcia > > --- > > configure.ac| 1 + > > utils/Makefile.am | 1 + > > utils/v4l2-get-device/.gitignore| 1 + > > utils/v4l2-get-device/Makefile.am | 4 + > > utils/v4l2-get-device/v4l2-get-device.c | 147 > > v4l-utils.spec.in | 1 + > > 6 files changed, 155 insertions(+) > > create mode 100644 utils/v4l2-get-device/.gitignore > > create mode 100644 utils/v4l2-get-device/Makefile.am > > create mode 100644 utils/v4l2-get-device/v4l2-get-device.c > > > > diff --git a/configure.ac b/configure.ac > > index 5cc34c248fbf..918cb59704b9 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile > > utils/v4l2-compliance/Makefile > > utils/v4l2-ctl/Makefile > > utils/v4l2-dbg/Makefile > > + utils/v4l2-get-device/Makefile > > utils/v4l2-sysfs-path/Makefile > > utils/qv4l2/Makefile > > utils/cec-ctl/Makefile > > diff --git a/utils/Makefile.am b/utils/Makefile.am > > index 2d5070288c13..2b2b27107d13 100644 > > --- a/utils/Makefile.am > > +++ b/utils/Makefile.am > > @@ -9,6 +9,7 @@ SUBDIRS = \ > > v4l2-compliance \ > > v4l2-ctl \ > > v4l2-dbg \ > > + v4l2-get-device \ > > v4l2-sysfs-path \ > > cec-ctl \ > > cec-compliance \ > > diff --git a/utils/v4l2-get-device/.gitignore > > b/utils/v4l2-get-device/.gitignore > > new file mode 100644 > > index ..b222144c9f4e > > --- /dev/null > > +++ b/utils/v4l2-get-device/.gitignore > > @@ -0,0 +1 @@ > > +v4l2-get-device > > diff --git a/utils/v4l2-get-device/Makefile.am > > b/utils/v4l2-get-device/Makefile.am > > new file mode 100644 > > index ..2e5a6e0ba32f > > --- /dev/null > > +++ b/utils/v4l2-get-device/Makefile.am > > @@ -0,0 +1,4 @@ > > +bin_PROGRAMS = v4l2-get-device > > +v4l2_get_device_SOURCES = v4l2-get-device.c > > +v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la > > +v4l2_get_device_LDFLAGS = $(ARGP_LIBS) > > diff --git a/utils/v4l2-get-device/v4l2-get-device.c > > b/utils/v4l2-get-device/v4l2-get-device.c > > new file mode 100644 > > index ..f9cc323b7057 > > --- /dev/null > > +++ b/utils/v4l2-get-device/v4l2-get-device.c > > @@ -0,0 +1,147 @@ > > +/* > > + * Copyright © 2018 Collabora, Ltd. > > + * > > + * Based on v4l2-sysfs-path by Mauro Carvalho Chehab: > > + * > > + * Copyright © 2011 Red Hat, Inc. > > + * > > + * Permission to use, copy, modify, distribute, and sell this software > > + * and its documentation for any purpose is hereby granted without > > + * fee, provided that the above copyright notice appear in all copies > > + * and that both that copyright notice and this permission notice > > + * appear in supporting documentation, and that the name of Red Hat > > + * not be used in advertising or publicity pertaining to distribution > > + * of the software without specific, written prior permission. Red > > + * Hat makes no representations about the suitability of this software > > + * for any purpose. It is provided "as is" without express or implied > > + * warranty. > > + * > > + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, > > + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN > > + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR > > + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS > > + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, > > + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN > > + * CONNECTION WITH THE USE OR PERFORMANCE OF
[PATCH v4l-utils] Introduce v4l2-get-device tool
This tool allows to find a device by driver name,
this is useful for scripts to be written in a generic way.
Usage:
v4l2-get-device -d uvcvideo -c V4L2_CAP_VIDEO_CAPTURE
/dev/video0
/dev/video2
Signed-off-by: Ezequiel Garcia
---
configure.ac| 1 +
utils/Makefile.am | 1 +
utils/v4l2-get-device/.gitignore| 1 +
utils/v4l2-get-device/Makefile.am | 4 +
utils/v4l2-get-device/v4l2-get-device.c | 147
v4l-utils.spec.in | 1 +
6 files changed, 155 insertions(+)
create mode 100644 utils/v4l2-get-device/.gitignore
create mode 100644 utils/v4l2-get-device/Makefile.am
create mode 100644 utils/v4l2-get-device/v4l2-get-device.c
diff --git a/configure.ac b/configure.ac
index 5cc34c248fbf..918cb59704b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -31,6 +31,7 @@ AC_CONFIG_FILES([Makefile
utils/v4l2-compliance/Makefile
utils/v4l2-ctl/Makefile
utils/v4l2-dbg/Makefile
+ utils/v4l2-get-device/Makefile
utils/v4l2-sysfs-path/Makefile
utils/qv4l2/Makefile
utils/cec-ctl/Makefile
diff --git a/utils/Makefile.am b/utils/Makefile.am
index 2d5070288c13..2b2b27107d13 100644
--- a/utils/Makefile.am
+++ b/utils/Makefile.am
@@ -9,6 +9,7 @@ SUBDIRS = \
v4l2-compliance \
v4l2-ctl \
v4l2-dbg \
+ v4l2-get-device \
v4l2-sysfs-path \
cec-ctl \
cec-compliance \
diff --git a/utils/v4l2-get-device/.gitignore b/utils/v4l2-get-device/.gitignore
new file mode 100644
index ..b222144c9f4e
--- /dev/null
+++ b/utils/v4l2-get-device/.gitignore
@@ -0,0 +1 @@
+v4l2-get-device
diff --git a/utils/v4l2-get-device/Makefile.am
b/utils/v4l2-get-device/Makefile.am
new file mode 100644
index ..2e5a6e0ba32f
--- /dev/null
+++ b/utils/v4l2-get-device/Makefile.am
@@ -0,0 +1,4 @@
+bin_PROGRAMS = v4l2-get-device
+v4l2_get_device_SOURCES = v4l2-get-device.c
+v4l2_get_device_LDADD = ../libmedia_dev/libmedia_dev.la
+v4l2_get_device_LDFLAGS = $(ARGP_LIBS)
diff --git a/utils/v4l2-get-device/v4l2-get-device.c
b/utils/v4l2-get-device/v4l2-get-device.c
new file mode 100644
index ..f9cc323b7057
--- /dev/null
+++ b/utils/v4l2-get-device/v4l2-get-device.c
@@ -0,0 +1,147 @@
+/*
+ * Copyright © 2018 Collabora, Ltd.
+ *
+ * Based on v4l2-sysfs-path by Mauro Carvalho Chehab:
+ *
+ * Copyright © 2011 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of Red Hat
+ * not be used in advertising or publicity pertaining to distribution
+ * of the software without specific, written prior permission. Red
+ * Hat makes no representations about the suitability of this software
+ * for any purpose. It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
+ * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
+ * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+ * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "../libmedia_dev/get_media_devices.h"
+
+const char *argp_program_version = "v4l2-get-device " V4L_UTILS_VERSION;
+const char *argp_program_bug_address = "Ezequiel Garcia
";
+
+struct args {
+ const char *driver;
+ unsigned int device_caps;
+};
+
+static const struct argp_option options[] = {
+ {"driver", 'd', "DRIVER", 0, "device driver name", 0},
+ {"v4l2-device-caps", 'c', "CAPS", 0, "v4l2 device capabilities", 0},
+ { 0 }
+};
+
+static unsigned int parse_capabilities(const char *arg)
+{
+ char *s, *str = strdup(arg);
+ unsigned int caps = 0;
+
+ s = strtok (str,",");
+ while (s != NULL) {
+ if (!strcmp(s, "V4L2_CAP_VIDEO_CAPTURE"))
+ caps |= V4L2_CAP_VIDEO_CAPTURE;
+ else if (!strcmp(s, "V4L2_CAP_VIDEO_OUTPUT"))
+ caps |= V4L2_CAP_VIDEO_OUTPUT;
+ else if (!strcmp(s, "V4L2_CAP_VIDEO_OVERLAY"))
+ caps |= V4L2_CAP_VIDEO_OVERLAY;
+ else if (!strcmp(s, "V4L2_CAP_VBI_CAPTURE"))
+ caps |= V4L2_CAP_VBI_CAPT
[PATCH] Revert "media: dt-bindings: Document the Rockchip VPU bindings"
This reverts commit e4183d3256e3cd668e899d06af66da5aac3a51af.
The commit was picked by mistake, as the Rockchip VPU driver
is not ready for inclusion yet, and it's still under discussion.
Signed-off-by: Ezequiel Garcia
---
.../bindings/media/rockchip-vpu.txt | 29 ---
1 file changed, 29 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
deleted file mode 100644
index 35dc464ad7c8..
--- a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-device-tree bindings for rockchip VPU codec
-
-Rockchip (Video Processing Unit) present in various Rockchip platforms,
-such as RK3288 and RK3399.
-
-Required properties:
-- compatible: value should be one of the following
- "rockchip,rk3288-vpu";
- "rockchip,rk3399-vpu";
-- interrupts: encoding and decoding interrupt specifiers
-- interrupt-names: should be "vepu" and "vdpu"
-- clocks: phandle to VPU aclk, hclk clocks
-- clock-names: should be "aclk" and "hclk"
-- power-domains: phandle to power domain node
-- iommus: phandle to a iommu node
-
-Example:
-SoC-specific DT entry:
- vpu: video-codec@ff9a {
- compatible = "rockchip,rk3288-vpu";
- reg = <0x0 0xff9a 0x0 0x800>;
- interrupts = ,
-;
- interrupt-names = "vepu", "vdpu";
- clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
- clock-names = "aclk", "hclk";
- power-domains = < RK3288_PD_VIDEO>;
- iommus = <_mmu>;
- };
--
2.19.1
Re: [Outreachy kernel] [PATCH vicodec v4 0/3] Add support to more pixel formats in vicodec
On Thu, 8 Nov 2018 at 14:54, Sasha Levin wrote: > > On Thu, Nov 08, 2018 at 10:10:10AM +0200, Dafna Hirschfeld wrote: > >On Thu, Nov 8, 2018 at 2:51 AM Ezequiel Garcia < > >ezequ...@vanguardiasur.com.ar> wrote: > > > >> Hello Dafna, > >> > >> Thanks for the patches. > >> > >> Just out of curiosity. Why these patches havent't been submitted to > >> the media mailing list? > >> > >> Hi, > >I wasn't sure if I should send it to the media mailing list, since this > >part of outreachy application. > > In general, for any patch you send to any subsystem please Cc all the > relevant mailing lists and maintainers. For Outreachy application you > already did that (by Cc'ing Greg), you just need to keep doing the same > as you continue your work on other parts of the kernel. > Let's Cc the mailing list now, as these patches look good, and the test scripts look pretty decent too ;-) > >Also, how are you testing these changes? > >> > > > >Based on Helen's decoder: > >https://gitlab.collabora.com/koike/v4l2-codec > > > >I extended it to include encoders and decoders for the new supported > >formats. > > > >testing formats with alpha plane: > >https://github.com/kamomil/outreachy/blob/master/argb-and-abgr-full-example.sh > > > >testing greyscale: > >https://github.com/kamomil/outreachy/blob/master/greyscale-full-example.sh > > It's awesome seeing these testsuites, it gives reviewers confidence that > your patch is well tested and they can focus on other parts of the > review process rather than check for the basic correctness of the patch. > > Please include links such as these and indicate how you tested your code > in your future patches. > +1 Thanks! -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar
Re: [RFC] Create test script(s?) for regression testing
On Wed, 2018-11-07 at 09:05 +0100, Hans Verkuil wrote: > On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > > Hi Hans, > > > > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > > > On 11/06/18 14:12, Laurent Pinchart wrote: > > > > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > > > > > On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > > > > > > Hi all, > > > > > > > > > > > > After the media summit (heavy on test discussions) and the V4L2 > > > > > > event > > > > > > regression we just found it is clear we need to do a better job with > > > > > > testing. > > > > > > > > > > > > All the pieces are in place, so what is needed is to combine it and > > > > > > create a script that anyone of us as core developers can run to > > > > > > check > > > > > > for regressions. The same script can be run as part of the kernelci > > > > > > regression testing. > > > > > > > > > > I'd say that *some* pieces are in place. Of course, the more there is, > > > > > the better. > > > > > > > > > > The more there are tests, the more important it would be they're > > > > > automated, preferrably without the developer having to run them on > > > > > his/ > > > > > her own machine. > > > > > > > > From my experience with testing, it's important to have both a core set > > > > of > > > > tests (a.k.a. smoke tests) that can easily be run on developers' > > > > machines, > > > > and extended tests that can be offloaded to a shared testing > > > > infrastructure (but possibly also run locally if desired). > > > > > > That was my idea as well for the longer term. First step is to do the > > > basic > > > smoke tests (i.e. run compliance tests, do some (limited) streaming test). > > > > > > There are more extensive (and longer running) tests that can be done, but > > > that's something to look at later. > > > > > > > > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The > > > > > > last > > > > > > one is IMHO not quite good enough yet for testing: it is not fully > > > > > > compliant to the upcoming stateful codec spec. Work for that is > > > > > > planned > > > > > > as part of an Outreachy project. > > > > > > > > > > > > My idea is to create a script that is maintained as part of > > > > > > v4l-utils > > > > > > that loads the drivers and runs v4l2-compliance and possibly other > > > > > > tests > > > > > > against the virtual drivers. > > > > > > > > > > How about spending a little time to pick a suitable framework for > > > > > running > > > > > the tests? It could be useful to get more informative reports than > > > > > just > > > > > pass / fail. > > > > > > > > We should keep in mind that other tests will be added later, and the > > > > test > > > > framework should make that easy. > > > > > > Since we want to be able to run this on kernelci.org, I think it makes > > > sense > > > to let the kernelci folks (Hi Ezequiel!) decide this. > > > > KernelCI isn't the only test infrastructure out there, so let's not forget > > about the other ones. > > True, but they are putting time and money into this, so they get to choose as > far as I am concerned :-) > Well, we are also resource-constrained, so my idea for the first iteration is to pick the simplest yet useful setup. We plan to leverage existing tests only. Currently xxx-compliance tools are what cover more. I believe that CI and tests should be independent components. > If others are interested and willing to put up time and money, they should let > themselves be known. > > I'm not going to work on such an integration, although I happily accept > patches. > > > > As a developer all I need is a script to run smoke tests so I can catch > > > most > > > regressions (you never catch all). > > > > > > I'm happy to work with them to make any changes to compliance tools and > > > scripts so they fit better into their test framework. > > > > > > The one key requirement to all this is that you should be able to run > > > these > > > tests without dependencies to all sorts of external packages/libraries. > > > > v4l-utils already has a set of dependencies, but those are largely > > manageable. > > For v4l2-compliance we'll install libv4l, which depends on libjpeg. > > That's already too much. You can manually build v4l2-compliance with no > dependencies > whatsoever, but we're missing a Makefile target for that. It's been useful for > embedded systems with poor cross-compile environments. > > It is really very useful to be able to compile those core utilities with no > external libraries other than glibc. You obviously will loose some > functionality > when you compile it that way. > > These utilities are not like a typical application. I really don't care how > many > libraries are linked in by e.g. qv4l2, xawtv, etc. But for v4l2-ctl, > v4l2-compliance, > cec-ctl/follower/compliance (and probably a few others as well) you want a > minimum > of dependencies so you can run
Re: [RFC] Create test script(s?) for regression testing
On Tue, 2018-11-06 at 09:37 +0100, Hans Verkuil wrote: > Hi all, > > After the media summit (heavy on test discussions) and the V4L2 event > regression > we just found it is clear we need to do a better job with testing. > > All the pieces are in place, so what is needed is to combine it and create a > script that anyone of us as core developers can run to check for regressions. > The same script can be run as part of the kernelci regression testing. > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one > is IMHO not quite good enough yet for testing: it is not fully compliant to > the > upcoming stateful codec spec. Work for that is planned as part of an Outreachy > project. > > My idea is to create a script that is maintained as part of v4l-utils that > loads the drivers and runs v4l2-compliance and possibly other tests against > the virtual drivers. > > It should be simple to use and require very little in the way of dependencies. > Ideally no dependencies other than what is in v4l-utils so it can easily be > run > on an embedded system as well. > > For a 64-bit kernel it should run the tests both with 32-bit and 64-bit > applications. > > It should also test with both single and multiplanar modes where available. > > Since vivid emulates CEC as well, it should run CEC tests too. > > As core developers we should have an environment where we can easily test > our patches with this script (I use a VM for that). > It's quite trivial to setup a qemu environment for this, e.g. you can use virtme [1] and set it up so that it runs a script after booting. > I think maintaining the script (or perhaps scripts) in v4l-utils is best since > that keeps it in sync with the latest kernel and v4l-utils developments. > > Comments? Ideas? > Sounds great. I think it makes a lot of sense to have a script for CIs and developers to run. I guess we can start simple, with just a bash script? > Regards, > > Hans [1] https://www.collabora.com/news-and-blog/blog/2018/09/18/virtme-the-kernel-developers-best-friend/
[PATCH v2 2/4] vicodec: Use pixel format helpers
Now that we've introduced the pixel format helpers, use them
in vicodec driver, and get rid of driver specific pixel
format specifiers.
Signed-off-by: Ezequiel Garcia
---
.../media/platform/vicodec/codec-v4l2-fwht.c | 42
.../media/platform/vicodec/codec-v4l2-fwht.h | 3 -
drivers/media/platform/vicodec/vicodec-core.c | 95 ++-
3 files changed, 48 insertions(+), 92 deletions(-)
diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
index e5b68fb38aac..42cf64dccaba 100644
--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.c
+++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.c
@@ -11,27 +11,27 @@
#include "codec-v4l2-fwht.h"
static const struct v4l2_fwht_pixfmt_info v4l2_fwht_pixfmts[] = {
- { V4L2_PIX_FMT_YUV420, 1, 3, 2, 1, 1, 2, 2 },
- { V4L2_PIX_FMT_YVU420, 1, 3, 2, 1, 1, 2, 2 },
- { V4L2_PIX_FMT_YUV422P, 1, 2, 1, 1, 1, 2, 1 },
- { V4L2_PIX_FMT_NV12,1, 3, 2, 1, 2, 2, 2 },
- { V4L2_PIX_FMT_NV21,1, 3, 2, 1, 2, 2, 2 },
- { V4L2_PIX_FMT_NV16,1, 2, 1, 1, 2, 2, 1 },
- { V4L2_PIX_FMT_NV61,1, 2, 1, 1, 2, 2, 1 },
- { V4L2_PIX_FMT_NV24,1, 3, 1, 1, 2, 1, 1 },
- { V4L2_PIX_FMT_NV42,1, 3, 1, 1, 2, 1, 1 },
- { V4L2_PIX_FMT_YUYV,2, 2, 1, 2, 4, 2, 1 },
- { V4L2_PIX_FMT_YVYU,2, 2, 1, 2, 4, 2, 1 },
- { V4L2_PIX_FMT_UYVY,2, 2, 1, 2, 4, 2, 1 },
- { V4L2_PIX_FMT_VYUY,2, 2, 1, 2, 4, 2, 1 },
- { V4L2_PIX_FMT_BGR24, 3, 3, 1, 3, 3, 1, 1 },
- { V4L2_PIX_FMT_RGB24, 3, 3, 1, 3, 3, 1, 1 },
- { V4L2_PIX_FMT_HSV24, 3, 3, 1, 3, 3, 1, 1 },
- { V4L2_PIX_FMT_BGR32, 4, 4, 1, 4, 4, 1, 1 },
- { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 4, 4, 1, 1 },
- { V4L2_PIX_FMT_RGB32, 4, 4, 1, 4, 4, 1, 1 },
- { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 4, 4, 1, 1 },
- { V4L2_PIX_FMT_HSV32, 4, 4, 1, 4, 4, 1, 1 },
+ { V4L2_PIX_FMT_YUV420, 1, 1, 2, 2 },
+ { V4L2_PIX_FMT_YVU420, 1, 1, 2, 2 },
+ { V4L2_PIX_FMT_YUV422P, 1, 1, 2, 1 },
+ { V4L2_PIX_FMT_NV12,1, 2, 2, 2 },
+ { V4L2_PIX_FMT_NV21,1, 2, 2, 2 },
+ { V4L2_PIX_FMT_NV16,1, 2, 2, 1 },
+ { V4L2_PIX_FMT_NV61,1, 2, 2, 1 },
+ { V4L2_PIX_FMT_NV24,1, 2, 1, 1 },
+ { V4L2_PIX_FMT_NV42,1, 2, 1, 1 },
+ { V4L2_PIX_FMT_YUYV,2, 4, 2, 1 },
+ { V4L2_PIX_FMT_YVYU,2, 4, 2, 1 },
+ { V4L2_PIX_FMT_UYVY,2, 4, 2, 1 },
+ { V4L2_PIX_FMT_VYUY,2, 4, 2, 1 },
+ { V4L2_PIX_FMT_BGR24, 3, 3, 1, 1 },
+ { V4L2_PIX_FMT_RGB24, 3, 3, 1, 1 },
+ { V4L2_PIX_FMT_HSV24, 3, 3, 1, 1 },
+ { V4L2_PIX_FMT_BGR32, 4, 4, 1, 1 },
+ { V4L2_PIX_FMT_XBGR32, 4, 4, 1, 1 },
+ { V4L2_PIX_FMT_RGB32, 4, 4, 1, 1 },
+ { V4L2_PIX_FMT_XRGB32, 4, 4, 1, 1 },
+ { V4L2_PIX_FMT_HSV32, 4, 4, 1, 1 },
};
const struct v4l2_fwht_pixfmt_info *v4l2_fwht_find_pixfmt(u32 pixelformat)
diff --git a/drivers/media/platform/vicodec/codec-v4l2-fwht.h
b/drivers/media/platform/vicodec/codec-v4l2-fwht.h
index 162465b78067..298a13732406 100644
--- a/drivers/media/platform/vicodec/codec-v4l2-fwht.h
+++ b/drivers/media/platform/vicodec/codec-v4l2-fwht.h
@@ -10,9 +10,6 @@
struct v4l2_fwht_pixfmt_info {
u32 id;
- unsigned int bytesperline_mult;
- unsigned int sizeimage_mult;
- unsigned int sizeimage_div;
unsigned int luma_step;
unsigned int chroma_step;
/* Chroma plane subsampling */
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index 1eb9132bfc85..dbc8b68894e7 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -43,25 +43,14 @@ MODULE_PARM_DESC(debug, " activates debug info");
#define MIN_WIDTH 640U
#define MAX_HEIGHT 2160U
#define MIN_HEIGHT 480U
+#define DEF_WIDTH 1280U
+#define DEF_HEIGHT 720U
#define dprintk(dev, fmt, arg...) \
v4l2_dbg(1, debug, >v4l2_dev, "%s: " fmt, __func__, ## arg)
-
-struct pixfmt_info {
- u32 id;
- unsigned int bytesperline_mult;
- unsigned int sizeimage_mult;
- unsigned int sizeimage_div;
- unsigned int luma_step;
- unsigned int chroma_step;
- /* Chroma plane subsampling */
- unsigned int width_div;
- unsigned int height_div;
-};
-
static const struct v4l2_fwht_pixfmt_info pixfmt_fwht = {
- V4L2_PIX_FMT_FWHT, 0, 3, 1, 1, 1, 1, 1
+ V4L2_PIX_FMT_FWHT, 1, 1, 1, 1
};
static void vicodec_dev_release(struct device *dev)
@@ -466,12 +455,8 @@ static int vidioc_g_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
if (multiplanar)
return -EINVAL;
pix = >fmt.pix;
- pix->width = q_data->width;
-
[PATCH v2 3/4] vicodec: Propagate changes to the CAPTURE queue
For stateful codecs, width and height values set
on the OUTPUT queue, must be propagated to the CAPTURE queue.
This is not enough to fully comply with the specification,
which would require to properly support stream resolution
changes detection and notification.
However, it's a relatively small change, which fixes behavior
required by some applications such as gstreamer.
With this change, it's possible to run a simple T(T⁻¹) pipeline:
gst-launch-1.0 videotestsrc ! v4l2fwhtenc ! v4l2fwhtdec ! fakevideosink
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vicodec/vicodec-core.c | 22 +++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index dbc8b68894e7..cffd41c3fc17 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -636,6 +636,17 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
q_data->width = pix->width;
q_data->height = pix->height;
q_data->sizeimage = pix->sizeimage;
+
+ /* Propagate changes to CAPTURE queue */
+ if (V4L2_TYPE_IS_OUTPUT(f->type)) {
+ struct v4l2_pix_format dst_pix;
+
+ v4l2_fill_pixfmt(_pix,
ctx->q_data[V4L2_M2M_DST].info->id,
+ pix->width, pix->height);
+ ctx->q_data[V4L2_M2M_DST].width = pix->width;
+ ctx->q_data[V4L2_M2M_DST].height = pix->height;
+ ctx->q_data[V4L2_M2M_DST].sizeimage = dst_pix.sizeimage;
+ }
break;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
@@ -656,6 +667,17 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
q_data->width = pix_mp->width;
q_data->height = pix_mp->height;
q_data->sizeimage = pix_mp->plane_fmt[0].sizeimage;
+
+ /* Propagate changes to CAPTURE queue */
+ if (V4L2_TYPE_IS_OUTPUT(f->type)) {
+ struct v4l2_pix_format_mplane dst_pix;
+
+ v4l2_fill_pixfmt_mp(_pix,
ctx->q_data[V4L2_M2M_DST].info->id,
+ pix_mp->width, pix_mp->height);
+ ctx->q_data[V4L2_M2M_DST].width = pix_mp->width;
+ ctx->q_data[V4L2_M2M_DST].height = pix_mp->height;
+ ctx->q_data[V4L2_M2M_DST].sizeimage =
dst_pix.plane_fmt[0].sizeimage;
+ }
break;
default:
return -EINVAL;
--
2.19.1
[PATCH v2 0/4] vicodec: a couple fixes towards spec compliancy
Given the stateful codec specification is still a moving target, it doesn't make any sense to try to comply fully with it. On the other side, we can still comply with some basic userspace expectations, with just a couple small changes. This series implements proper resolution changes propagation, and fixes the CMD_STOP so it actually works. The intention of this series is to be able to test this driver using already existing userspace, gstreamer in particular. With this changes, it's possible to construct variations of this pipeline: gst-launch-1.0 videotestsrc ! v4l2fwhtenc ! v4l2fwhtdec ! fakevideosink Also, as discussed in v1 feedback [1,2], I'm including pixel format helpers, as RFC for now. Hans, Tomasz: is this what you had in mind? [1] https://www.spinics.net/lists/linux-media/msg141912.html [2] https://www.spinics.net/lists/linux-media/msg142099.html v2: * Add more info to commit logs * Propagate changes on both encoders and decoders * Add pixel format helpers Ezequiel Garcia (4): media: Introduce helpers to fill pixel format structs vicodec: Use pixel format helpers vicodec: Propagate changes to the CAPTURE queue vicodec: Implement spec-compliant stop command .../media/platform/vicodec/codec-v4l2-fwht.c | 42 ++-- .../media/platform/vicodec/codec-v4l2-fwht.h | 3 - drivers/media/platform/vicodec/vicodec-core.c | 197 +- drivers/media/v4l2-core/Makefile | 2 +- drivers/media/v4l2-core/v4l2-common.c | 66 ++ drivers/media/v4l2-core/v4l2-fourcc.c | 93 + include/media/v4l2-common.h | 5 + include/media/v4l2-fourcc.h | 53 + 8 files changed, 332 insertions(+), 129 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-fourcc.c create mode 100644 include/media/v4l2-fourcc.h -- 2.19.1
[RFC v2 1/4] media: Introduce helpers to fill pixel format structs
Add two new API helpers, v4l2_fill_pixfmt and v4l2_fill_pixfmt_mp,
to be used by drivers to calculate plane sizes and bytes per lines.
Note that driver-specific paddig and alignment are not yet
taken into account.
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/Makefile | 2 +-
drivers/media/v4l2-core/v4l2-common.c | 66 +++
drivers/media/v4l2-core/v4l2-fourcc.c | 93 +++
include/media/v4l2-common.h | 5 ++
include/media/v4l2-fourcc.h | 53 +++
5 files changed, 218 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/v4l2-core/v4l2-fourcc.c
create mode 100644 include/media/v4l2-fourcc.h
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 9ee57e1efefe..bc23c3407c17 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -7,7 +7,7 @@ tuner-objs := tuner-core.o
videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o v4l2-fh.o \
v4l2-event.o v4l2-ctrls.o v4l2-subdev.o v4l2-clk.o \
- v4l2-async.o
+ v4l2-async.o v4l2-fourcc.o
ifeq ($(CONFIG_COMPAT),y)
videodev-objs += v4l2-compat-ioctl32.o
endif
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 50763fb42a1b..97bb51d15188 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
@@ -455,3 +456,68 @@ int v4l2_s_parm_cap(struct video_device *vdev,
return ret;
}
EXPORT_SYMBOL_GPL(v4l2_s_parm_cap);
+
+void v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, int
pixelformat, int width, int height)
+{
+ const struct v4l2_format_info *info;
+ struct v4l2_plane_pix_format *plane;
+ int i;
+
+ info = v4l2_format_info(pixelformat);
+ if (!info)
+ return;
+
+ pixfmt->width = width;
+ pixfmt->height = height;
+ pixfmt->pixelformat = pixelformat;
+
+ if (info->has_contiguous_planes) {
+ pixfmt->num_planes = 1;
+ plane = >plane_fmt[0];
+ plane->bytesperline = info->is_compressed ?
+ 0 : width * info->cpp[0];
+ plane->sizeimage = info->header_size;
+ for (i = 0; i < info->num_planes; i++) {
+ unsigned int hsub = (i == 0) ? 1 : info->hsub;
+ unsigned int vsub = (i == 0) ? 1 : info->vsub;
+
+ plane->sizeimage += width * height * info->cpp[i] /
(hsub * vsub);
+ }
+ } else {
+ pixfmt->num_planes = info->num_planes;
+ for (i = 0; i < info->num_planes; i++) {
+ unsigned int hsub = (i == 0) ? 1 : info->hsub;
+ unsigned int vsub = (i == 0) ? 1 : info->vsub;
+
+ plane = >plane_fmt[i];
+ plane->bytesperline = width * info->cpp[i] / hsub;
+ plane->sizeimage = width * height * info->cpp[i] /
(hsub * vsub);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt_mp);
+
+void v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, int pixelformat, int
width, int height)
+{
+ const struct v4l2_format_info *info;
+ char name[32];
+ int i;
+
+ pixfmt->width = width;
+ pixfmt->height = height;
+ pixfmt->pixelformat = pixelformat;
+
+ info = v4l2_format_info(pixelformat);
+ if (!info)
+ return;
+ pixfmt->bytesperline = info->is_compressed ? 0 : width * info->cpp[0];
+
+ pixfmt->sizeimage = info->header_size;
+ for (i = 0; i < info->num_planes; i++) {
+ unsigned int hsub = (i == 0) ? 1 : info->hsub;
+ unsigned int vsub = (i == 0) ? 1 : info->vsub;
+
+ pixfmt->sizeimage += width * height * info->cpp[i] / (hsub *
vsub);
+ }
+}
+EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt);
diff --git a/drivers/media/v4l2-core/v4l2-fourcc.c
b/drivers/media/v4l2-core/v4l2-fourcc.c
new file mode 100644
index ..4e8a15525b58
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-fourcc.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright (c) 2018 Collabora, Ltd.
+ *
+ * Based on drm-fourcc:
+ * Copyright (c) 2016 Laurent Pinchart
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distrib
[PATCH v2 4/4] vicodec: Implement spec-compliant stop command
Currently on a V4L2_ENC_CMD_STOP command, the driver sets
V4L2_BUF_FLAG_LAST to the destination buffer, but only if
there's no source buffer.
This alone has no effects, because .device_run never
gets to run (there is no source buffer), therefore destination
buffer is never dequeued.
Fix this by setting up a statically-allocated, dummy buffer to
be used as flush buffer, used to signal a encoding (or decoding) stop.
This works by queueing the flush buffer to the OUTPUT queue,
so the driver will send an V4L2_EVENT_EOS event, and
mark the CAPTURE buffer with V4L2_BUF_FLAG_LAST.
Once the buffer is marked as V4L2_BUF_FLAG_LAST, the kernel
returns -EPIPE on a VIDIOC_DQBUF. Applications can use
this error to detect the stop condition.
With this change, it's possible to run a pipeline to completion:
gst-launch-1.0 videotestsrc num-buffers=10 ! v4l2fwhtenc ! v4l2fwhtdec !
fakevideosink
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vicodec/vicodec-core.c | 80 ++-
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index cffd41c3fc17..b973833e21f5 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -102,7 +102,7 @@ struct vicodec_ctx {
struct v4l2_ctrl_handler hdl;
struct vb2_v4l2_buffer *last_src_buf;
- struct vb2_v4l2_buffer *last_dst_buf;
+ struct vb2_v4l2_buffer flush_buf;
/* Source and destination queue data */
struct vicodec_q_data q_data[2];
@@ -209,6 +209,7 @@ static void device_run(void *priv)
struct vicodec_dev *dev = ctx->dev;
struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct vicodec_q_data *q_out;
+ bool flushing;
u32 state;
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
@@ -216,26 +217,36 @@ static void device_run(void *priv)
q_out = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
state = VB2_BUF_STATE_DONE;
- if (device_process(ctx, src_buf, dst_buf))
+
+ flushing = (src_buf == >flush_buf);
+ if (!flushing && device_process(ctx, src_buf, dst_buf))
state = VB2_BUF_STATE_ERROR;
- ctx->last_dst_buf = dst_buf;
spin_lock(ctx->lock);
- if (!ctx->comp_has_next_frame && src_buf == ctx->last_src_buf) {
+ if (!flushing) {
+ if (!ctx->comp_has_next_frame && src_buf == ctx->last_src_buf) {
+ dst_buf->flags |= V4L2_BUF_FLAG_LAST;
+ v4l2_event_queue_fh(>fh, _event);
+ }
+
+ if (ctx->is_enc) {
+ src_buf->sequence = q_out->sequence++;
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, state);
+ } else if (vb2_get_plane_payload(_buf->vb2_buf, 0)
+ == ctx->cur_buf_offset) {
+ src_buf->sequence = q_out->sequence++;
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, state);
+ ctx->cur_buf_offset = 0;
+ ctx->comp_has_next_frame = false;
+ }
+ } else {
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ vb2_set_plane_payload(_buf->vb2_buf, 0, 0);
dst_buf->flags |= V4L2_BUF_FLAG_LAST;
v4l2_event_queue_fh(>fh, _event);
}
- if (ctx->is_enc) {
- src_buf->sequence = q_out->sequence++;
- src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_buf_done(src_buf, state);
- } else if (vb2_get_plane_payload(_buf->vb2_buf, 0) ==
ctx->cur_buf_offset) {
- src_buf->sequence = q_out->sequence++;
- src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_buf_done(src_buf, state);
- ctx->cur_buf_offset = 0;
- ctx->comp_has_next_frame = false;
- }
v4l2_m2m_buf_done(dst_buf, state);
ctx->comp_size = 0;
ctx->comp_magic_cnt = 0;
@@ -282,6 +293,8 @@ static int job_ready(void *priv)
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
if (!src_buf)
return 0;
+ if (src_buf == >flush_buf)
+ return 1;
p_out = vb2_plane_vaddr(_buf->vb2_buf, 0);
sz = vb2_get_plane_payload(_buf->vb2_buf, 0);
p = p_out + ctx->cur_buf_offset;
@@ -740,21 +753,6 @@ static int vidioc_s_fmt_vid_out(struct file *file, void
*priv,
return ret;
}
-static void vicodec_mark_last_buf(struct vicodec_ctx *ctx)
-{
- static const struct v4l2
Re: RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)
On Fri, 2018-10-19 at 09:06 +0200, Hans Verkuil wrote: > On 10/18/2018 09:23 PM, Ezequiel Garcia wrote: > > Hi everyone, > > > > In Collabora, and as part of our kernelci work, we are doing > > research on kernel functional testing with kernelci. > > > > For those new to kernelci, see > > https://github.com/kernelci/kernelci-doc/wiki/KernelCI > > and https://kernelci.org/. > > > > The goal is to lay down the infrastructure required to make > > automated test coverage an integral part of our feature > > and bugfix development process. > > > > So, as a first attempt, we've decided to extend kernelci test > > v4l2 plan support, leading the way to extending > > other subsystems' test plans. > > > > Currently, kernelci looks for a list of branches every hour and > > see if anything changed. For any branch that has changed, it triggers > > builds, boots, tests and reports for each branch that had some changes > > since last time it ran. > > > > For this pilot, we've decided to target just a few devices: > > qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq > > with uvc. > > It's running v4l2-compliance, right? > Exactly. > Looking at the test cases, they appear in the reverse order that > v4l2-compliance > performs them, that's a bit odd. > That's something to check in the parser. I'm sure it's fixable if you find it annoying. > And if we include uvc in the testing, then I need to prioritize the work I > started for uvc to remove the last FAILs. > Well, we can run anything. We decided to go for uvc and vivid, just too pick two popular examples, but there are really no restrictions. Thanks, Ezequiel
Re: [PATCH 2/2] vicodec: Implement spec-compliant stop command
Hi Nicolas, On Fri, 2018-10-19 at 07:41 -0400, Nicolas Dufresne wrote: > Le vendredi 19 octobre 2018 à 07:35 -0400, Nicolas Dufresne a écrit : > > Le vendredi 19 octobre 2018 à 09:28 +0200, Hans Verkuil a écrit : > > > On 10/18/2018 06:08 PM, Ezequiel Garcia wrote: > > > > Set up a statically-allocated, dummy buffer to > > > > be used as flush buffer, which signals > > > > a encoding (or decoding) stop. > > > > > > > > When the flush buffer is queued to the OUTPUT queue, > > > > the driver will send an V4L2_EVENT_EOS event, and > > > > mark the CAPTURE buffer with V4L2_BUF_FLAG_LAST. > > > > > > I'm confused. What is the current driver doing wrong? It is already > > > setting the LAST flag AFAIK. I don't see why a dummy buffer is > > > needed. > > > > I'm not sure of this patch either. It seems to trigger the legacy > > "empty payload" buffer case. Driver should mark the last buffer, and > > then following poll should return EPIPE. Maybe it's the later that > > isn't respected ? > > Sorry, I've send this too fast. The following poll should not block, > and DQBUF should retunr EPIPE. > > In GStreamer we currently ignore the LAST flag and wait for EPIPE. The > reason is that not all driver can set the LAST flag. Exynos firmware > tells you it's done later and we don't want to introduce any latency in > the driver. The last flag isn't that useful in fact, but it can be use > with RTP to set the marker bit. > Yeah, I know that gstreamer ignores the LAST flag. > In previous discussion, using a buffer with payload 0 was not liked. > There might be codec where an empty buffer is valid, who knows ? > The goal of this patch is for the driver to mark the dst buf as V4L2_BUF_FLAG_DONE and V4L2_BUF_FLAG_LAST, so videobuf2 core returns EPIPE on a DQBUF. Sorry for not being clear in the commit log. Thanks, Ezequiel
Re: [PATCH 2/2] vicodec: Implement spec-compliant stop command
On Fri, 2018-10-19 at 09:28 +0200, Hans Verkuil wrote: > On 10/18/2018 06:08 PM, Ezequiel Garcia wrote: > > Set up a statically-allocated, dummy buffer to > > be used as flush buffer, which signals > > a encoding (or decoding) stop. > > > > When the flush buffer is queued to the OUTPUT queue, > > the driver will send an V4L2_EVENT_EOS event, and > > mark the CAPTURE buffer with V4L2_BUF_FLAG_LAST. > > I'm confused. What is the current driver doing wrong? It is already > setting the LAST flag AFAIK. The driver seems to be setting V4L2_BUF_FLAG_LAST to the dst buf, if there's no src buf. IIRC, that alone is has no effects, because .device_run never gets to run (after all, there is no src buf), and the dst buf is never marked as done and dequeued... > I don't see why a dummy buffer is needed. > ... and that is why I took the dummy buffer idea (from some other driver), which seemed an easy way to artificially run device_run to dequeue the dst buf. What do you think? Thanks, Ezequiel
Re: [PATCH 1/2] vicodec: Have decoder propagate changes to the CAPTURE queue
On Fri, 2018-10-19 at 09:14 +0200, Hans Verkuil wrote:
> On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > The decoder interface (not yet merged) specifies that
> > width and height values set on the OUTPUT queue, must
> > be propagated to the CAPTURE queue.
> >
> > This is not enough to comply with the specification,
> > which would require to properly support stream resolution
> > changes detection and notification.
> >
> > However, it's a relatively small change, which fixes behavior
> > required by some applications such as gstreamer.
> >
> > With this change, it's possible to run a simple T(T⁻¹) pipeline:
> >
> > gst-launch-1.0 videotestsrc ! v4l2fwhtenc ! v4l2fwhtdec ! fakevideosink
> >
> > Signed-off-by: Ezequiel Garcia
> > ---
> > drivers/media/platform/vicodec/vicodec-core.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/media/platform/vicodec/vicodec-core.c
> > b/drivers/media/platform/vicodec/vicodec-core.c
> > index 1eb9132bfc85..a2c487b4b80d 100644
> > --- a/drivers/media/platform/vicodec/vicodec-core.c
> > +++ b/drivers/media/platform/vicodec/vicodec-core.c
> > @@ -673,6 +673,13 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx,
> > struct v4l2_format *f)
> > q_data->width = pix->width;
> > q_data->height = pix->height;
> > q_data->sizeimage = pix->sizeimage;
> > +
> > + /* Propagate changes to CAPTURE queue */
> > + if (!ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type)) {
>
> Do we need !ctx->is_enc? Isn't this the same for both decoder and encoder?
>
Well, I wasn't really sure about this. The decoder document clearly
says that changes has to be propagated to the capture queue, but that statement
is not in the encoder spec.
Since gstreamer didn't needs this, I decided not to add it.
Perhaps it's something to correct in the encoder spec?
> > + ctx->q_data[V4L2_M2M_DST].width = pix->width;
> > + ctx->q_data[V4L2_M2M_DST].height = pix->height;
> > + ctx->q_data[V4L2_M2M_DST].sizeimage = pix->sizeimage;
>
> This is wrong: you are copying the sizeimage for the compressed format as the
> sizeimage for the raw format, which is quite different.
>
Doh, you are right.
> I think you need to make a little helper function that can update the
> width/height
> of a particular queue and that can calculate the sizeimage correctly.
>
Sounds good.
Thanks for the review,
Ezequiel
RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)
Hi everyone, In Collabora, and as part of our kernelci work, we are doing research on kernel functional testing with kernelci. For those new to kernelci, see https://github.com/kernelci/kernelci-doc/wiki/KernelCI and https://kernelci.org/. The goal is to lay down the infrastructure required to make automated test coverage an integral part of our feature and bugfix development process. So, as a first attempt, we've decided to extend kernelci test v4l2 plan support, leading the way to extending other subsystems' test plans. Currently, kernelci looks for a list of branches every hour and see if anything changed. For any branch that has changed, it triggers builds, boots, tests and reports for each branch that had some changes since last time it ran. For this pilot, we've decided to target just a few devices: qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq with uvc. We'd like to get some early feedback on this, so we are sending an example of how a kernelci report would look like, to trigger some discussion around the direction this should take. Thanks! === Test results for: Tree:gtucker Branch: kernelci-media Kernel: gtucker-kernelci-media-002-2-gaa27eb0392c7 URL: https://gitlab.collabora.com/gtucker/linux.git Commit: aa27eb0392c70adec713e911a9b5267a1d853624 Test plans: v4l2 Summary --- 3 test groups results 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 4 FAIL 28 SKIP 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 4 FAIL 28 SKIP 3 | v4l2 | qemu | arm64 | 168 total: 102 PASS 0 FAIL 66 SKIP Tests - 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 4 FAIL 28 SKIP Config: defconfig Lab Name:lab-collabora-dev Date:2018-10-18 18:48:52.426000 TXT log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev /v4l2-rk3399-gru-kevin.txt HTML log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev /v4l2-rk3399-gru-kevin.html Rootfs: http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//arm64/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2 Test cases: * MMAP: FAIL * blocking-wait: PASS * read/write: SKIP * read/write: SKIP * read/write: SKIP * VIDIOC_EXPBUF: PASS * VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: PASS * VIDIOC_TRY_DECODER_CMD: SKIP * VIDIOC_G_ENC_INDEX: SKIP * VIDIOC_TRY_ENCODER_CMD: SKIP * Scaling: SKIP * Composing: SKIP * Cropping: SKIP * VIDIOC_G_SLICED_VBI_CAP: SKIP * VIDIOC_S_FMT: PASS * VIDIOC_TRY_FMT: PASS * VIDIOC_G_FMT: PASS * VIDIOC_G_FBUF: SKIP * VIDIOC_G/S_PARM: FAIL * VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: PASS * VIDIOC_G/S_JPEGCOMP: SKIP * VIDIOC_UNSUBSCRIBE_EVENT/DQEVENT: PASS * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL * VIDIOC_G/S_CTRL: PASS * VIDIOC_QUERYCTRL: PASS * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL * VIDIOC_G/S_EDID: SKIP * VIDIOC_DV_TIMINGS_CAP: SKIP * VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: SKIP * VIDIOC_ENUM/G/S/QUERY_STD: SKIP * VIDIOC_G/S_AUDOUT: SKIP * VIDIOC_G/S/ENUMOUTPUT: SKIP * VIDIOC_ENUMAUDOUT: SKIP * VIDIOC_G/S_FREQUENCY: SKIP * VIDIOC_G/S_MODULATOR: SKIP * VIDIOC_G/S_AUDIO: SKIP * VIDIOC_G/S/ENUMINPUT: PASS * VIDIOC_ENUMAUDIO: SKIP * VIDIOC_S_HW_FREQ_SEEK: SKIP * VIDIOC_G/S_FREQUENCY: SKIP * VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: SKIP * VIDIOC_LOG_STATUS: SKIP * VIDIOC_DBG_G/S_REGISTER: SKIP * for-unlimited-opens: PASS * VIDIOC_G/S_PRIORITY: PASS * VIDIOC_QUERYCAP: PASS * second-/dev/video0-open: PASS * VIDIOC_QUERYCAP: PASS * MC-information-see-Media-Driver-Info-above: PASS 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 4 FAIL 28 SKIP Config: multi_v7_defconfig Lab Name:lab-collabora-dev Date:2018-10-18 17:00:41.724000 TXT log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm/multi_v7_defconfig/lab-collab ora-dev/v4l2-rk3288-veyron-jaq.txt HTML log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm/multi_v7_defconfig/lab-collab ora-dev/v4l2-rk3288-veyron-jaq.html Rootfs: http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//armhf/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2 Test cases: * MMAP: FAIL * blocking-wait: PASS * read/write: SKIP * read/write: SKIP * read/write: SKIP * VIDIOC_EXPBUF: PASS *
[PATCH] media: Rename vb2_m2m_request_queue -> v4l2_m2m_request_queue
To be consistent with the rest of the mem2mem helpers,
rename vb2_m2m_request_queue to v4l2_m2m_request_queue.
This is just a cosmetic change.
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vim2m.c | 2 +-
drivers/media/v4l2-core/v4l2-mem2mem.c | 4 ++--
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
include/media/v4l2-mem2mem.h| 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/vim2m.c b/drivers/media/platform/vim2m.c
index af150a0395df..d82db738f174 100644
--- a/drivers/media/platform/vim2m.c
+++ b/drivers/media/platform/vim2m.c
@@ -1009,7 +1009,7 @@ static const struct v4l2_m2m_ops m2m_ops = {
static const struct media_device_ops m2m_media_ops = {
.req_validate = vb2_request_validate,
- .req_queue = vb2_m2m_request_queue,
+ .req_queue = v4l2_m2m_request_queue,
};
static int vim2m_probe(struct platform_device *pdev)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index d7806db222d8..1ed2465972ac 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -953,7 +953,7 @@ void v4l2_m2m_buf_queue(struct v4l2_m2m_ctx *m2m_ctx,
}
EXPORT_SYMBOL_GPL(v4l2_m2m_buf_queue);
-void vb2_m2m_request_queue(struct media_request *req)
+void v4l2_m2m_request_queue(struct media_request *req)
{
struct media_request_object *obj, *obj_safe;
struct v4l2_m2m_ctx *m2m_ctx = NULL;
@@ -997,7 +997,7 @@ void vb2_m2m_request_queue(struct media_request *req)
if (m2m_ctx)
v4l2_m2m_try_schedule(m2m_ctx);
}
-EXPORT_SYMBOL_GPL(vb2_m2m_request_queue);
+EXPORT_SYMBOL_GPL(v4l2_m2m_request_queue);
/* Videobuf2 ioctl helpers */
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c
b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 82558455384a..dd121f66fa2d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -253,7 +253,7 @@ static const struct v4l2_m2m_ops cedrus_m2m_ops = {
static const struct media_device_ops cedrus_m2m_media_ops = {
.req_validate = cedrus_request_validate,
- .req_queue = vb2_m2m_request_queue,
+ .req_queue = v4l2_m2m_request_queue,
};
static int cedrus_probe(struct platform_device *pdev)
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 58c1ecf3d648..5467264771ec 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -624,7 +624,7 @@ v4l2_m2m_dst_buf_remove_by_idx(struct v4l2_m2m_ctx
*m2m_ctx, unsigned int idx)
/* v4l2 request helper */
-void vb2_m2m_request_queue(struct media_request *req);
+void v4l2_m2m_request_queue(struct media_request *req);
/* v4l2 ioctl helpers */
--
2.19.1
[PATCH v5 1/5] mem2mem: Require capture and output mutexes to match
Currently, all the mem2mem driver either use a single mutex
to lock the capture and output videobuf2 queues, or don't
set any mutex.
This means the mutexes match, and so the mem2mem framework
is able to set the m2m context lock.
Enforce this by making it mandatory for drivers to set
the same capture and output mutex, or not set any mutex at all.
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index d7806db222d8..bc72243eb91d 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -908,12 +908,14 @@ struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct
v4l2_m2m_dev *m2m_dev,
if (ret)
goto err;
/*
-* If both queues use same mutex assign it as the common buffer
-* queues lock to the m2m context. This lock is used in the
-* v4l2_m2m_ioctl_* helpers.
+* Both queues should use same the mutex to lock the m2m context.
+* This lock is used in some v4l2_m2m_* helpers.
*/
- if (out_q_ctx->q.lock == cap_q_ctx->q.lock)
- m2m_ctx->q_lock = out_q_ctx->q.lock;
+ if (WARN_ON(out_q_ctx->q.lock != cap_q_ctx->q.lock)) {
+ ret = -EINVAL;
+ goto err;
+ }
+ m2m_ctx->q_lock = out_q_ctx->q.lock;
return m2m_ctx;
err:
--
2.19.1
[PATCH v5 5/5] media: cedrus: Get rid of interrupt bottom-half
Now that the mem2mem framework guarantees that .device_run
won't be called from interrupt context, it is safe to call
v4l2_m2m_job_finish directly in the top-half.
So this means the bottom-half is no longer needed and we
can get rid of it.
Signed-off-by: Ezequiel Garcia
---
.../staging/media/sunxi/cedrus/cedrus_hw.c| 26 ---
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index 32adbcbe6175..493e65b17b30 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -98,23 +98,6 @@ void cedrus_dst_format_set(struct cedrus_dev *dev,
}
}
-static irqreturn_t cedrus_bh(int irq, void *data)
-{
- struct cedrus_dev *dev = data;
- struct cedrus_ctx *ctx;
-
- ctx = v4l2_m2m_get_curr_priv(dev->m2m_dev);
- if (!ctx) {
- v4l2_err(>v4l2_dev,
-"Instance released before the end of transaction\n");
- return IRQ_HANDLED;
- }
-
- v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
-
- return IRQ_HANDLED;
-}
-
static irqreturn_t cedrus_irq(int irq, void *data)
{
struct cedrus_dev *dev = data;
@@ -165,7 +148,9 @@ static irqreturn_t cedrus_irq(int irq, void *data)
spin_unlock_irqrestore(>irq_lock, flags);
- return IRQ_WAKE_THREAD;
+ v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
+
+ return IRQ_HANDLED;
}
int cedrus_hw_probe(struct cedrus_dev *dev)
@@ -187,9 +172,8 @@ int cedrus_hw_probe(struct cedrus_dev *dev)
return irq_dec;
}
- ret = devm_request_threaded_irq(dev->dev, irq_dec, cedrus_irq,
- cedrus_bh, 0, dev_name(dev->dev),
- dev);
+ ret = devm_request_irq(dev->dev, irq_dec, cedrus_irq,
+ 0, dev_name(dev->dev), dev);
if (ret) {
v4l2_err(>v4l2_dev, "Failed to request IRQ\n");
--
2.19.1
[PATCH v5 3/5] v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule
From: Sakari Ailus
The __v4l2_m2m_try_schedule function acquires and releases multiple
spinlocks. Simplify unlocking the job lock by adding labels to unlock
the lock and exit the function.
Signed-off-by: Sakari Ailus
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 29 --
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index bc72243eb91d..0665a97ed89e 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -297,51 +297,48 @@ static void __v4l2_m2m_try_queue(struct v4l2_m2m_dev
*m2m_dev,
/* If the context is aborted then don't schedule it */
if (m2m_ctx->job_flags & TRANS_ABORT) {
- spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("Aborted context\n");
- return;
+ goto job_unlock;
}
if (m2m_ctx->job_flags & TRANS_QUEUED) {
- spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("On job queue already\n");
- return;
+ goto job_unlock;
}
spin_lock_irqsave(_ctx->out_q_ctx.rdy_spinlock, flags_out);
if (list_empty(_ctx->out_q_ctx.rdy_queue)
&& !m2m_ctx->out_q_ctx.buffered) {
- spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock,
- flags_out);
- spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("No input buffers available\n");
- return;
+ goto out_unlock;
}
spin_lock_irqsave(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
if (list_empty(_ctx->cap_q_ctx.rdy_queue)
&& !m2m_ctx->cap_q_ctx.buffered) {
- spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock,
- flags_cap);
- spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock,
- flags_out);
- spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("No output buffers available\n");
- return;
+ goto cap_unlock;
}
spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock, flags_out);
if (m2m_dev->m2m_ops->job_ready
&& (!m2m_dev->m2m_ops->job_ready(m2m_ctx->priv))) {
- spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
dprintk("Driver not ready\n");
- return;
+ goto job_unlock;
}
list_add_tail(_ctx->queue, _dev->job_queue);
m2m_ctx->job_flags |= TRANS_QUEUED;
spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
+ return;
+
+cap_unlock:
+ spin_unlock_irqrestore(_ctx->cap_q_ctx.rdy_spinlock, flags_cap);
+out_unlock:
+ spin_unlock_irqrestore(_ctx->out_q_ctx.rdy_spinlock, flags_out);
+job_unlock:
+ spin_unlock_irqrestore(_dev->job_spinlock, flags_job);
}
/**
--
2.19.1
[PATCH v5 2/5] v4l2-ioctl.c: Simplify locking for m2m devices
Now that the mutexes for output and capture vb2 queues match,
it is possible to refer to the context q_lock as the
m2m lock for a given m2m context.
Remove the output/capture lock selection.
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-ioctl.c | 47 ++--
1 file changed, 2 insertions(+), 45 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index c63746968fa3..54919c227bc1 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2679,45 +2679,6 @@ static bool v4l2_is_known_ioctl(unsigned int cmd)
return v4l2_ioctls[_IOC_NR(cmd)].ioctl == cmd;
}
-#if IS_ENABLED(CONFIG_V4L2_MEM2MEM_DEV)
-static bool v4l2_ioctl_m2m_queue_is_output(unsigned int cmd, void *arg)
-{
- switch (cmd) {
- case VIDIOC_CREATE_BUFS: {
- struct v4l2_create_buffers *cbufs = arg;
-
- return V4L2_TYPE_IS_OUTPUT(cbufs->format.type);
- }
- case VIDIOC_REQBUFS: {
- struct v4l2_requestbuffers *rbufs = arg;
-
- return V4L2_TYPE_IS_OUTPUT(rbufs->type);
- }
- case VIDIOC_QBUF:
- case VIDIOC_DQBUF:
- case VIDIOC_QUERYBUF:
- case VIDIOC_PREPARE_BUF: {
- struct v4l2_buffer *buf = arg;
-
- return V4L2_TYPE_IS_OUTPUT(buf->type);
- }
- case VIDIOC_EXPBUF: {
- struct v4l2_exportbuffer *expbuf = arg;
-
- return V4L2_TYPE_IS_OUTPUT(expbuf->type);
- }
- case VIDIOC_STREAMON:
- case VIDIOC_STREAMOFF: {
- int *type = arg;
-
- return V4L2_TYPE_IS_OUTPUT(*type);
- }
- default:
- return false;
- }
-}
-#endif
-
static struct mutex *v4l2_ioctl_get_lock(struct video_device *vdev,
struct v4l2_fh *vfh, unsigned int cmd,
void *arg)
@@ -2727,12 +2688,8 @@ static struct mutex *v4l2_ioctl_get_lock(struct
video_device *vdev,
#if IS_ENABLED(CONFIG_V4L2_MEM2MEM_DEV)
if (vfh && vfh->m2m_ctx &&
(v4l2_ioctls[_IOC_NR(cmd)].flags & INFO_FL_QUEUE)) {
- bool is_output = v4l2_ioctl_m2m_queue_is_output(cmd, arg);
- struct v4l2_m2m_queue_ctx *ctx = is_output ?
- >m2m_ctx->out_q_ctx : >m2m_ctx->cap_q_ctx;
-
- if (ctx->q.lock)
- return ctx->q.lock;
+ if (vfh->m2m_ctx->q_lock)
+ return vfh->m2m_ctx->q_lock;
}
#endif
if (vdev->queue && vdev->queue->lock &&
--
2.19.1
[PATCH v5 4/5] v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish
v4l2_m2m_job_finish() is typically called when
DMA operations complete, in interrupt handlers or DMA
completion callbacks. Calling .device_run from v4l2_m2m_job_finish
creates a nasty re-entrancy path into the driver.
Moreover, some implementation of .device_run might need to sleep,
as is the case for drivers supporting the Request API,
where controls are applied via v4l2_ctrl_request_setup,
which takes the ctrl handler mutex.
This commit adds a deferred context that calls v4l2_m2m_try_run,
and gets scheduled by v4l2_m2m_job_finish().
Before this change, device_run would be called from these
paths:
vb2_m2m_request_queue, or
v4l2_m2m_streamon, or
v4l2_m2m_qbuf
v4l2_m2m_try_schedule
v4l2_m2m_try_run
.device_run
v4l2_m2m_job_finish
v4l2_m2m_try_run
.device_run
After this change, the latter is now gone and instead:
v4l2_m2m_device_run_work
v4l2_m2m_try_run
.device_run
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 0665a97ed89e..2b250fd10531 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -87,6 +87,7 @@ static const char * const m2m_entity_name[] = {
* @curr_ctx: currently running instance
* @job_queue: instances queued to run
* @job_spinlock: protects job_queue
+ * @job_work: worker to run queued jobs.
* @m2m_ops: driver callbacks
*/
struct v4l2_m2m_dev {
@@ -103,6 +104,7 @@ struct v4l2_m2m_dev {
struct list_headjob_queue;
spinlock_t job_spinlock;
+ struct work_struct job_work;
const struct v4l2_m2m_ops *m2m_ops;
};
@@ -244,6 +246,9 @@ EXPORT_SYMBOL(v4l2_m2m_get_curr_priv);
* @m2m_dev: per-device context
*
* Get next transaction (if present) from the waiting jobs list and run it.
+ *
+ * Note that this function can run on a given v4l2_m2m_ctx context,
+ * but call .device_run for another context.
*/
static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev)
{
@@ -362,6 +367,18 @@ void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
}
EXPORT_SYMBOL_GPL(v4l2_m2m_try_schedule);
+/**
+ * v4l2_m2m_device_run_work() - run pending jobs for the context
+ * @work: Work structure used for scheduling the execution of this function.
+ */
+static void v4l2_m2m_device_run_work(struct work_struct *work)
+{
+ struct v4l2_m2m_dev *m2m_dev =
+ container_of(work, struct v4l2_m2m_dev, job_work);
+
+ v4l2_m2m_try_run(m2m_dev);
+}
+
/**
* v4l2_m2m_cancel_job() - cancel pending jobs for the context
* @m2m_ctx: m2m context with jobs to be canceled
@@ -421,7 +438,12 @@ void v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
/* This instance might have more buffers ready, but since we do not
* allow more than one job on the job_queue per instance, each has
* to be scheduled separately after the previous one finishes. */
- v4l2_m2m_try_schedule(m2m_ctx);
+ __v4l2_m2m_try_queue(m2m_dev, m2m_ctx);
+
+ /* We might be running in atomic context,
+* but the job must be run in non-atomic context.
+*/
+ schedule_work(_dev->job_work);
}
EXPORT_SYMBOL(v4l2_m2m_job_finish);
@@ -863,6 +885,7 @@ struct v4l2_m2m_dev *v4l2_m2m_init(const struct
v4l2_m2m_ops *m2m_ops)
m2m_dev->m2m_ops = m2m_ops;
INIT_LIST_HEAD(_dev->job_queue);
spin_lock_init(_dev->job_spinlock);
+ INIT_WORK(_dev->job_work, v4l2_m2m_device_run_work);
return m2m_dev;
}
--
2.19.1
[PATCH v5 0/5] Make sure .device_run is always called in non-atomic context
This series goal is to avoid drivers from having ad-hoc code to call .device_run in non-atomic context. Currently, .device_run can be called via v4l2_m2m_job_finish(), not only running in interrupt context, but also creating a nasty re-entrant path into mem2mem drivers. The proposed solution is to add a per-device worker that is scheduled by v4l2_m2m_job_finish, which replaces drivers having a threaded interrupt or similar. This change allows v4l2_m2m_job_finish() to be called in interrupt context, separating .device_run and v4l2_m2m_job_finish() contexts. It's worth mentioning that v4l2_m2m_cancel_job() doesn't need to flush or cancel the new worker, because the job_spinlock synchronizes both and also because the core prevents simultaneous jobs. Either v4l2_m2m_cancel_job() will wait for the worker, or the worker will be unable to run a new job. Patches apply on top of Request API and the Cedrus VPU driver. Tested with cedrus driver using v4l2-request-test and vicodec driver using gstreamer. Ezequiel Garcia (4): mem2mem: Require capture and output mutexes to match v4l2-ioctl.c: Simplify locking for m2m devices v4l2-mem2mem: Avoid calling .device_run in v4l2_m2m_job_finish media: cedrus: Get rid of interrupt bottom-half Sakari Ailus (1): v4l2-mem2mem: Simplify exiting the function in __v4l2_m2m_try_schedule drivers/media/v4l2-core/v4l2-ioctl.c | 47 + drivers/media/v4l2-core/v4l2-mem2mem.c| 66 --- .../staging/media/sunxi/cedrus/cedrus_hw.c| 26 ++-- 3 files changed, 51 insertions(+), 88 deletions(-) -- 2.19.1
[PATCH 0/2] vicodec: a couple fixes towards spec compliancy
Given the stateful codec specification is still a moving target, it doesn't make any sense to try to comply fully with it. On the other side, we can still comply with some basic userspace expectations, with just a couple small changes. This series implements proper resolution changes propagation, and fixes the CMD_STOP so it actually works. The intention of this series is to be able to test this driver using already existing userspace, gstreamer in particular. With this changes, it's possible to construct variations of this pipeline: gst-launch-1.0 videotestsrc ! v4l2fwhtenc ! v4l2fwhtdec ! fakevideosink Ezequiel Garcia (2): vicodec: Have decoder propagate changes to the CAPTURE queue vicodec: Implement spec-compliant stop command drivers/media/platform/vicodec/vicodec-core.c | 95 --- 1 file changed, 59 insertions(+), 36 deletions(-) -- 2.19.1
[PATCH 1/2] vicodec: Have decoder propagate changes to the CAPTURE queue
The decoder interface (not yet merged) specifies that
width and height values set on the OUTPUT queue, must
be propagated to the CAPTURE queue.
This is not enough to comply with the specification,
which would require to properly support stream resolution
changes detection and notification.
However, it's a relatively small change, which fixes behavior
required by some applications such as gstreamer.
With this change, it's possible to run a simple T(T⁻¹) pipeline:
gst-launch-1.0 videotestsrc ! v4l2fwhtenc ! v4l2fwhtdec ! fakevideosink
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vicodec/vicodec-core.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index 1eb9132bfc85..a2c487b4b80d 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -673,6 +673,13 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
q_data->width = pix->width;
q_data->height = pix->height;
q_data->sizeimage = pix->sizeimage;
+
+ /* Propagate changes to CAPTURE queue */
+ if (!ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type)) {
+ ctx->q_data[V4L2_M2M_DST].width = pix->width;
+ ctx->q_data[V4L2_M2M_DST].height = pix->height;
+ ctx->q_data[V4L2_M2M_DST].sizeimage = pix->sizeimage;
+ }
break;
case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
@@ -693,6 +700,14 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
q_data->width = pix_mp->width;
q_data->height = pix_mp->height;
q_data->sizeimage = pix_mp->plane_fmt[0].sizeimage;
+
+ /* Propagate changes to CAPTURE queue */
+ if (!ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type)) {
+ ctx->q_data[V4L2_M2M_DST].width = pix_mp->width;
+ ctx->q_data[V4L2_M2M_DST].height = pix_mp->height;
+ ctx->q_data[V4L2_M2M_DST].sizeimage =
+ pix_mp->plane_fmt[0].sizeimage;
+ }
break;
default:
return -EINVAL;
--
2.19.1
[PATCH 2/2] vicodec: Implement spec-compliant stop command
Set up a statically-allocated, dummy buffer to
be used as flush buffer, which signals
a encoding (or decoding) stop.
When the flush buffer is queued to the OUTPUT queue,
the driver will send an V4L2_EVENT_EOS event, and
mark the CAPTURE buffer with V4L2_BUF_FLAG_LAST.
With this change, it's possible to run a pipeline to completion:
gst-launch-1.0 videotestsrc num-buffers=10 ! v4l2fwhtenc ! v4l2fwhtdec !
fakevideosink
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vicodec/vicodec-core.c | 80 ++-
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index a2c487b4b80d..4ed4dae10e30 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -113,7 +113,7 @@ struct vicodec_ctx {
struct v4l2_ctrl_handler hdl;
struct vb2_v4l2_buffer *last_src_buf;
- struct vb2_v4l2_buffer *last_dst_buf;
+ struct vb2_v4l2_buffer flush_buf;
/* Source and destination queue data */
struct vicodec_q_data q_data[2];
@@ -220,6 +220,7 @@ static void device_run(void *priv)
struct vicodec_dev *dev = ctx->dev;
struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct vicodec_q_data *q_out;
+ bool flushing;
u32 state;
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
@@ -227,26 +228,36 @@ static void device_run(void *priv)
q_out = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
state = VB2_BUF_STATE_DONE;
- if (device_process(ctx, src_buf, dst_buf))
+
+ flushing = (src_buf == >flush_buf);
+ if (!flushing && device_process(ctx, src_buf, dst_buf))
state = VB2_BUF_STATE_ERROR;
- ctx->last_dst_buf = dst_buf;
spin_lock(ctx->lock);
- if (!ctx->comp_has_next_frame && src_buf == ctx->last_src_buf) {
+ if (!flushing) {
+ if (!ctx->comp_has_next_frame && src_buf == ctx->last_src_buf) {
+ dst_buf->flags |= V4L2_BUF_FLAG_LAST;
+ v4l2_event_queue_fh(>fh, _event);
+ }
+
+ if (ctx->is_enc) {
+ src_buf->sequence = q_out->sequence++;
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, state);
+ } else if (vb2_get_plane_payload(_buf->vb2_buf, 0)
+ == ctx->cur_buf_offset) {
+ src_buf->sequence = q_out->sequence++;
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, state);
+ ctx->cur_buf_offset = 0;
+ ctx->comp_has_next_frame = false;
+ }
+ } else {
+ src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
+ vb2_set_plane_payload(_buf->vb2_buf, 0, 0);
dst_buf->flags |= V4L2_BUF_FLAG_LAST;
v4l2_event_queue_fh(>fh, _event);
}
- if (ctx->is_enc) {
- src_buf->sequence = q_out->sequence++;
- src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_buf_done(src_buf, state);
- } else if (vb2_get_plane_payload(_buf->vb2_buf, 0) ==
ctx->cur_buf_offset) {
- src_buf->sequence = q_out->sequence++;
- src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- v4l2_m2m_buf_done(src_buf, state);
- ctx->cur_buf_offset = 0;
- ctx->comp_has_next_frame = false;
- }
v4l2_m2m_buf_done(dst_buf, state);
ctx->comp_size = 0;
ctx->comp_magic_cnt = 0;
@@ -293,6 +304,8 @@ static int job_ready(void *priv)
src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
if (!src_buf)
return 0;
+ if (src_buf == >flush_buf)
+ return 1;
p_out = vb2_plane_vaddr(_buf->vb2_buf, 0);
sz = vb2_get_plane_payload(_buf->vb2_buf, 0);
p = p_out + ctx->cur_buf_offset;
@@ -770,21 +783,6 @@ static int vidioc_s_fmt_vid_out(struct file *file, void
*priv,
return ret;
}
-static void vicodec_mark_last_buf(struct vicodec_ctx *ctx)
-{
- static const struct v4l2_event eos_event = {
- .type = V4L2_EVENT_EOS
- };
-
- spin_lock(ctx->lock);
- ctx->last_src_buf = v4l2_m2m_last_src_buf(ctx->fh.m2m_ctx);
- if (!ctx->last_src_buf && ctx->last_dst_buf) {
- ctx->last_dst_buf->flags |= V4L2_BUF_FLAG_LAST;
- v4l2_event_queue_fh(>fh, _event);
- }
- spin_unlock(ctx->lock);
-}
-
static int vicodec_try_encoder_cmd(struct file *file,
Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables
On Fri, 2018-10-12 at 22:00 +0200, Paul Kocialkowski wrote: > Hi, > > Le mercredi 19 septembre 2018 à 13:28 +0900, Tomasz Figa a écrit : > > On Thu, Sep 13, 2018 at 9:15 PM Paul Kocialkowski wrote: > > > Hi, > > > > > > On Wed, 2018-09-05 at 19:00 -0300, Ezequiel Garcia wrote: > > > > From: Shunqian Zheng > > > > > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > > > configure the JPEG quantization tables. > > > > > > > > Signed-off-by: Shunqian Zheng > > > > Signed-off-by: Ezequiel Garcia > > > > --- > > > > .../media/uapi/v4l/extended-controls.rst | 31 +++ > > > > .../media/videodev2.h.rst.exceptions | 1 + > > > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++ > > > > include/uapi/linux/v4l2-controls.h| 12 +++ > > > > include/uapi/linux/videodev2.h| 1 + > > > > 5 files changed, 55 insertions(+) > > > > > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > > > b/Documentation/media/uapi/v4l/extended-controls.rst > > > > index 9f7312bf3365..1335d27d30f3 100644 > > > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > > > @@ -3354,7 +3354,38 @@ JPEG Control IDs > > > > Specify which JPEG markers are included in compressed stream. This > > > > control is valid only for encoders. > > > > > > > > +.. _jpeg-quant-tables-control: > > > > > > I just had a look at how the Allwinner VPU handles JPEG decoding and it > > > seems to require the following information (in addition to > > > quantization): > > > > I assume the hardware doesn't have the ability to parse those from the > > stream and so they need to be parsed by user space and given to the > > driver? > > That's correct, we are also dealing with a stateless decoder here. It's > actually the same hardware engine that's used for MPEG2 decoding, only > configured differently. > > So we will need to introduce a pixfmt for compressed JPEG data without > headers, reuse JPEG controls that apply and perhaps introduce new ones > too if needed. > > I am also wondering about how MJPEG support should fit into this. As > far as I understood, it shouldn't be very different from JPEG so we > might want to have common controls for both. > We've recently discussed this and we were proposing to just drop MJPEG and stick to JPEG. The reason is that MJPEG is not clearly defined. Note that others treat MJPEG and JPEG as aliases. See "Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG". Also, I'll be adding support for spec-compliant JPEG frames in rockchip JPEG encoder. This will allow to use the driver with already available userspace. IOW, we don't absolutely need a new pixelformat for encoders. Decoders, on the other side, would be a different story, as parsing headers in the kernel can raise some safety concerns. Regards, Ezequiel
Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs
On Mon, 2018-10-08 at 13:53 +0200, Hans Verkuil wrote: > Hi all, > > I would like to meet up somewhere during the ELCE to discuss userspace support > for stateless (and perhaps stateful as well?) codecs. > > It is also planned as a topic during the summit, but I would prefer to prepare > for that in advance, esp. since I myself do not have any experience writing > userspace SW for such devices. > > Nicolas, it would be really great if you can participate in this meeting > since you probably have the most experience with this by far. > > Looking through the ELCE program I found two timeslots that are likely to work > for most of us (because the topics in the program appear to be boring for us > media types!): > > Tuesday from 10:50-15:50 > > or: > > Monday from 15:45 onward > > My guess is that we need 2-3 hours or so. Hard to predict. > > The basic question that I would like to have answered is what the userspace > component should look like? libv4l-like plugin or a library that userspace can > link with? Do we want more general support for stateful codecs as well that > deals > with resolution changes and the more complex parts of the codec API? > > I've mailed this directly to those that I expect are most interested in this, > but if someone want to join in let me know. > > I want to keep the group small though, so you need to bring relevant > experience > to the table. > No preference for me either. Thanks!
Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder
On Fri, 2018-10-05 at 13:49 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 05 Oct 2018 12:37:43 -0300
> Ezequiel Garcia escreveu:
>
> > On Fri, 2018-10-05 at 09:10 -0300, Mauro Carvalho Chehab wrote:
> > > Em Thu, 04 Oct 2018 20:39:31 -0300
> > > Ezequiel Garcia escreveu:
> > >
> > > > On Mon, 2018-10-01 at 14:54 -0300, Ezequiel Garcia wrote:
> > > > > On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> > > > > > On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > > > > > > This series adds support for JPEG encoding via the VPU block
> > > > > > > present in Rockchip platforms. Currently, support for RK3288
> > > > > > > and RK3399 is included.
> > > > > > >
> > > > > > > Please, see the previous versions of this cover letter for
> > > > > > > more information.
> > > > > > >
> > > > > > > Compared to v5, the only change is in the
> > > > > > > V4L2_CID_JPEG_QUANTIZATION
> > > > > > > control. We've decided to support only baseline profile,
> > > > > > > and only add 8-bit luma and chroma tables.
> > > > > > >
> > > > > > > struct v4l2_ctrl_jpeg_quantization {
> > > > > > >__u8luma_quantization_matrix[64];
> > > > > > >__u8chroma_quantization_matrix[64];
> > > > > > > };
> > > > > > >
> > > > > > > By doing this, it's clear that we don't currently support anything
> > > > > > > but baseline.
> > > > > > >
> > > > > > > This series should apply cleanly on top of
> > > > > > >
> > > > > > > git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> > > > > > >
> > > > > > > If everyone is happy with this series, I'd like to route the
> > > > > > > devicetree
> > > > > > > changes through the rockchip tree, and the rest via the media
> > > > > > > subsystem.
> > > > > >
> > > > > > OK, so I have what is no doubt an annoying question: do we really
> > > > > > need
> > > > > > a JPEG_RAW format?
> > > > > >
> > > > >
> > > > > Not annoying, as it helps clarify a few things :-)
> > > > > I think we do need the JPEG_RAW format. The way I see it, using
> > > > > JPEG opens a can of worms...
> > > > >
> > > > > > The JPEG header is really easy to parse for a decoder and really
> > > > > > easy to
> > > > > > prepend to the compressed image for the encoder.
> > > > > >
> > > > > > The only reason I can see for a JPEG_RAW is if the image must start
> > > > > > at
> > > > > > some specific address alignment. Although even then you can just
> > > > > > pad the
> > > > > > JPEG header that you will add according to the alignment
> > > > > > requirements.
> > > > > >
> > > > > > I know I am very late with this question, but I never looked all
> > > > > > that
> > > > > > closely at what a JPEG header looks like. But this helped:
> > > > > >
> > > > > > https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
> > > > > >
> > > > > > and it doesn't seem difficult at all to parse or create the header.
> > > > > >
> > > > > >
> > > > >
> > > > > ... I think that having JPEG_RAW as the compressed format
> > > > > is much more clear for userspace, as it explicitly specifies
> > > > > what is expected.
> > > > >
> > > > > This way, for a stateless encoder, applications are required
> > > > > to set quantization and/or entropy tables, and are then in
> > > > > charge of using the compressed JPEG_RAW payload in whatever form
> > > > > they want. Stupid simple.
> > > > >
> > > > > On the other side, if the stateless encoder driver supports
> > > > > JPEG (creating headers in-kernel), it means that:
> > > > >
> > > > > *) applications should pas
Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder
On Fri, 2018-10-05 at 09:10 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 04 Oct 2018 20:39:31 -0300
> Ezequiel Garcia escreveu:
>
> > On Mon, 2018-10-01 at 14:54 -0300, Ezequiel Garcia wrote:
> > > On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> > > > On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > > > > This series adds support for JPEG encoding via the VPU block
> > > > > present in Rockchip platforms. Currently, support for RK3288
> > > > > and RK3399 is included.
> > > > >
> > > > > Please, see the previous versions of this cover letter for
> > > > > more information.
> > > > >
> > > > > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > > > > control. We've decided to support only baseline profile,
> > > > > and only add 8-bit luma and chroma tables.
> > > > >
> > > > > struct v4l2_ctrl_jpeg_quantization {
> > > > >__u8luma_quantization_matrix[64];
> > > > >__u8chroma_quantization_matrix[64];
> > > > > };
> > > > >
> > > > > By doing this, it's clear that we don't currently support anything
> > > > > but baseline.
> > > > >
> > > > > This series should apply cleanly on top of
> > > > >
> > > > > git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> > > > >
> > > > > If everyone is happy with this series, I'd like to route the
> > > > > devicetree
> > > > > changes through the rockchip tree, and the rest via the media
> > > > > subsystem.
> > > >
> > > > OK, so I have what is no doubt an annoying question: do we really need
> > > > a JPEG_RAW format?
> > > >
> > >
> > > Not annoying, as it helps clarify a few things :-)
> > > I think we do need the JPEG_RAW format. The way I see it, using
> > > JPEG opens a can of worms...
> > >
> > > > The JPEG header is really easy to parse for a decoder and really easy to
> > > > prepend to the compressed image for the encoder.
> > > >
> > > > The only reason I can see for a JPEG_RAW is if the image must start at
> > > > some specific address alignment. Although even then you can just pad the
> > > > JPEG header that you will add according to the alignment requirements.
> > > >
> > > > I know I am very late with this question, but I never looked all that
> > > > closely at what a JPEG header looks like. But this helped:
> > > >
> > > > https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
> > > >
> > > > and it doesn't seem difficult at all to parse or create the header.
> > > >
> > > >
> > >
> > > ... I think that having JPEG_RAW as the compressed format
> > > is much more clear for userspace, as it explicitly specifies
> > > what is expected.
> > >
> > > This way, for a stateless encoder, applications are required
> > > to set quantization and/or entropy tables, and are then in
> > > charge of using the compressed JPEG_RAW payload in whatever form
> > > they want. Stupid simple.
> > >
> > > On the other side, if the stateless encoder driver supports
> > > JPEG (creating headers in-kernel), it means that:
> > >
> > > *) applications should pass a quality control, if supported,
> > > and the driver will use hardcoded tables or...
> > >
> > > *) applications pass quantization control and, if supported,
> > > entropy control. The kernel uses them to create the JPEG frame.
> > > But also, some drivers (e.g. Rockchip), use default entropy
> > > tables, which should now be in the kernel.
> > >
> > > So the application would have to query controls to find out
> > > what to do. Not exactly hard, but I think having the JPEG_RAW
> > > is much simpler and more clear.
> > >
> > > Now, for stateless decoders, supporting JPEG_RAW means
> > > the application has to pass quantization and entropy
> > > controls, probably using the Request API.
> > > Given the application has parsed the JPEG,
> > > it knows the width and height and can request
> > > buffers accordingly.
> > >
> > > The hardware is stateless, and so is the driver.
> > >
> > > On the other
Re: [PATCH v7 4/6] media: Add JPEG_RAW format
On Fri, 2018-10-05 at 08:09 -0300, Mauro Carvalho Chehab wrote: > Em Thu, 4 Oct 2018 21:12:24 -0300 > Ezequiel Garcia escreveu: > > > From: Shunqian Zheng > > > > Add V4L2_PIX_FMT_JPEG_RAW format that does not contain > > JPEG header in the output frame. > > > > Signed-off-by: Shunqian Zheng > > Signed-off-by: Ezequiel Garcia > > --- > > Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 + > > drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > > include/uapi/linux/videodev2.h | 1 + > > 3 files changed, 11 insertions(+) > > > > diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst > > b/Documentation/media/uapi/v4l/pixfmt-compressed.rst > > index ba0f6c49d9bf..ad73076276ec 100644 > > --- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst > > +++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst > > @@ -23,6 +23,15 @@ Compressed Formats > >- 'JPEG' > >- TBD. See also :ref:`VIDIOC_G_JPEGCOMP `, > > :ref:`VIDIOC_S_JPEGCOMP `. > > +* .. _V4L2-PIX-FMT-JPEG-RAW: > > + > > + - ``V4L2_PIX_FMT_JPEG_RAW`` > > + - 'Raw JPEG' > > + - Raw JPEG bitstream, containing a compressed payload. This format > > +contains an image scan, i.e. without any metadata or headers. > > +The user is expected to set the needed metadata such as > > +quantization and entropy encoding tables, via ``V4L2_CID_JPEG`` > > +controls, see :ref:`jpeg-control-id`. > > IMO, it is not very clear when someone should use V4L2_CID_JPEG or > V4L2_PIX_FMT_JPEG_RAW. Some drivers do add a JPEG header internally. > For device drivers, if the hardware can parse JPEG frames, then V4L2_PIX_FMT_JPEG should be used. Otherwise, if the hardware can only accept a parsed JPEG (i.e. payload and tables), then only V4L2_PIX_FMT_JPEG_RAW should be supported. Parsing headers in the driver is discouraged by the stateful codec API specification. With the Request API in place, and the stateful and stateless specs, device driver writers should be now using the right model for each type of hardware. There are exceptions, though. If the hardware handles full JPEG frames, but requires some extra parsing on the OS side, then the driver should be using V4L2_PIX_FMT_JPEG, and doing some extra parsing. For instance, mtk-jpeg seems to work like this. > Also, if we're now starting to accept headerless JPEG images, you should > very patch libv4l as well, in order to accept this new format. > Right. Thanks, Eze
[PATCH v7 6/6] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 9 + drivers/staging/media/rockchip/vpu/TODO | 9 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 125 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 127 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../media/rockchip/vpu/rk3399_vpu_hw.c| 125 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 155 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 + .../staging/media/rockchip/vpu/rockchip_vpu.h | 278 .../media/rockchip/vpu/rockchip_vpu_common.h | 31 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 527 +++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 606 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ 17 files changed, 3122 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h diff --git a/MAINTAINERS b/MAINTAINERS index 6d69f3ad1aa9..f0dc5dfcfae4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12459,6 +12459,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Kconfig b/drivers/staging/media/rockchip/vpu/Kconfig new file mode 100644 index ..12bb79fd69f9 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Kconfig @@ -0,0 +1,13 @@ +config VIDEO_ROCKCHIP_VPU + tristate "Rockchip VPU driver" + depends on ARCH_ROCKCHIP || COMPILE_TEST + depends on VIDEO_DEV && VIDEO_V4L2 && MEDIA_CONTROLLER + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + default n + help + Support for the Video Processing Unit present on Rockchip SoC, + which accelerates video and image encoding and decoding. + To compile this driver as a module, choose M here: the module + will be called rockchip-vpu. + diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..2fb99adfbdb9 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Makefile @@ -0,0 +1,9 @@ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip-vpu.o + +rockchip-vpu-y += \ + rockchip_vpu_drv.o \ + rockchip_vpu_enc.o \ + rk3288_vpu_hw.o \ + rk3288_vpu_hw_jpeg_enc.o
[PATCH v7 4/6] media: Add JPEG_RAW format
From: Shunqian Zheng
Add V4L2_PIX_FMT_JPEG_RAW format that does not contain
JPEG header in the output frame.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
index ba0f6c49d9bf..ad73076276ec 100644
--- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
@@ -23,6 +23,15 @@ Compressed Formats
- 'JPEG'
- TBD. See also :ref:`VIDIOC_G_JPEGCOMP `,
:ref:`VIDIOC_S_JPEGCOMP `.
+* .. _V4L2-PIX-FMT-JPEG-RAW:
+
+ - ``V4L2_PIX_FMT_JPEG_RAW``
+ - 'Raw JPEG'
+ - Raw JPEG bitstream, containing a compressed payload. This format
+contains an image scan, i.e. without any metadata or headers.
+The user is expected to set the needed metadata such as
+quantization and entropy encoding tables, via ``V4L2_CID_JPEG``
+controls, see :ref:`jpeg-control-id`.
* .. _V4L2-PIX-FMT-MPEG:
- ``V4L2_PIX_FMT_MPEG``
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index c148c44caffb..5eab42277f47 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1301,6 +1301,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
/* Max description length mask: descr =
"0123456789012345678901234567890" */
case V4L2_PIX_FMT_MJPEG:descr = "Motion-JPEG"; break;
case V4L2_PIX_FMT_JPEG: descr = "JFIF JPEG"; break;
+ case V4L2_PIX_FMT_JPEG_RAW: descr = "Raw JPEG"; break;
case V4L2_PIX_FMT_DV: descr = "1394"; break;
case V4L2_PIX_FMT_MPEG: descr = "MPEG-1/2/4"; break;
case V4L2_PIX_FMT_H264: descr = "H.264"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 7412a255d9ce..1c7b5df4eb83 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -627,6 +627,7 @@ struct v4l2_pix_format {
/* compressed formats */
#define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG
*/
#define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
*/
+#define V4L2_PIX_FMT_JPEG_RAW v4l2_fourcc('J', 'P', 'G', 'R') /* JFIF JPEG RAW
without headers */
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
start codes */
--
2.19.0.rc2
[PATCH v7 2/6] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.19.0.rc2
[PATCH v7 5/6] media: Add controls for JPEG quantization tables
From: Shunqian Zheng
Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace
configure the JPEG quantization tables.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
.../media/uapi/v4l/extended-controls.rst | 25 +++
.../media/videodev2.h.rst.exceptions | 1 +
drivers/media/v4l2-core/v4l2-ctrls.c | 8 ++
include/uapi/linux/v4l2-controls.h| 10
include/uapi/linux/videodev2.h| 1 +
5 files changed, 45 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
b/Documentation/media/uapi/v4l/extended-controls.rst
index 65a1d873196b..6effae175be1 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3530,7 +3530,32 @@ JPEG Control IDs
Specify which JPEG markers are included in compressed stream. This
control is valid only for encoders.
+.. _jpeg-quant-tables-control:
+``V4L2_CID_JPEG_QUANTIZATION (struct)``
+Specifies the luma and chroma quantization matrices for encoding
+or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer.
+This control supports 8-bit quantization coefficients, for
+the baseline profile, as specified by :ref:`itu-t81`.
+Coefficients must be set in JPEG zigzag scan order.
+
+
+.. c:type:: struct v4l2_ctrl_jpeg_quantization
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_jpeg_quantization
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - __u8
+ - ``luma_quantization_matrix[64]``
+ - Sets the luma quantization table.
+
+* - __u8
+ - ``chroma_quantization_matrix[64]``
+ - Sets the chroma quantization table.
.. flat-table::
:header-rows: 0
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index 30ba0d6f546f..bd210f7d0afc 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -131,6 +131,7 @@ replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTIZATION :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type`
# V4L2 capability defines
replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 65e3cf838ac7..a8612ad42010 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1001,6 +1001,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers";
+ case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization
Tables";
/* Image source controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1288,6 +1289,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DETECT_MD_REGION_GRID:
*type = V4L2_CTRL_TYPE_U8;
break;
+ case V4L2_CID_JPEG_QUANTIZATION:
+ *type = V4L2_CTRL_TYPE_JPEG_QUANTIZATION;
+ break;
case V4L2_CID_DETECT_MD_THRESHOLD_GRID:
*type = V4L2_CTRL_TYPE_U16;
break;
@@ -1667,6 +1671,7 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32
idx,
return 0;
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
+ case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
return 0;
default:
@@ -2249,6 +2254,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
elem_size = sizeof(struct v4l2_ctrl_mpeg2_quantization);
break;
+ case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
+ elem_size = sizeof(struct v4l2_ctrl_jpeg_quantization);
+ break;
default:
if (type < V4L2_CTRL_COMPOUND_TYPES)
elem_size = sizeof(s32);
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 51b095898f4b..5a8bdb732cfe 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -990,6 +990,16 @@ enum v4l2_jpeg_chroma_subsampling {
#defineV4L2_JPEG_ACTIVE_MARKER_DQT (1 << 17)
#defineV4L2_JPEG_ACTIVE_MARKER_DHT (1 << 18)
+#define V4L2_CID_JPEG_QUANTIZATION (V4L2_CID_JPEG_CLASS_BASE + 5)
+struct v4l2_ctrl_jpeg_quantization {
+ /* ITU-T.81 specifie
[PATCH v7 0/6] Add Rockchip VPU JPEG encoder
as requested by Hans. - Get rid of all the unused leftover code. - Move driver to staging. The driver will support video encoding, via the request API. So let's use staging until the controls are stabilized. v4: - Change luma and chroma array controls, with a compound control, as suggested by Paul. v3: - Refactor driver to allow a more elegant integration with other codec modes (h264 decoding, jpeg decoding, etc). Each variant can now be encoders, decoders or both. - Register driver in the media controller framework, in preparation for the Request API. - Set values for JPEG quantization controls in the core, as suggested by Tomasz and Hans. - Move pm_runtime_get/put to run/done, reducing power consumption. This was possible thanks to Miouyouyou, who pointed out the power domains missing [1]. - Use bulk clock API for simpler code. v2: - Add devicetree binding documentation and devicetree changes - Add documentation to added pixel format and controls - Address Hans' review comments - Get rid of unused running_ctx field - Fix wrong planar pixel format depths - Other minor changes for v4l2-compliance - Drop .crop support, we will add support for the selector API later, if needed. [1] https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.18/DTS/0026-ARM-DTSI-rk3288-Set-the-VPU-MMU-power-domains.patch Ezequiel Garcia (4): dt-bindings: Document the Rockchip VPU bindings ARM: dts: rockchip: add VPU device node for RK3288 arm64: dts: rockchip: add VPU device node for RK3399 media: add Rockchip VPU JPEG encoder driver Shunqian Zheng (2): media: Add JPEG_RAW format media: Add controls for JPEG quantization tables .../bindings/media/rockchip-vpu.txt | 29 + .../media/uapi/v4l/extended-controls.rst | 25 + .../media/uapi/v4l/pixfmt-compressed.rst | 9 + .../media/videodev2.h.rst.exceptions | 1 + MAINTAINERS | 7 + arch/arm/boot/dts/rk3288.dtsi | 14 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +- drivers/media/v4l2-core/v4l2-ctrls.c | 8 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Kconfig| 13 + drivers/staging/media/rockchip/vpu/Makefile | 9 + drivers/staging/media/rockchip/vpu/TODO | 9 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 125 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 127 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../media/rockchip/vpu/rk3399_vpu_hw.c| 125 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 155 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 600 + .../staging/media/rockchip/vpu/rockchip_vpu.h | 278 .../media/rockchip/vpu/rockchip_vpu_common.h | 31 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 527 +++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 606 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ include/uapi/linux/v4l2-controls.h| 10 + include/uapi/linux/videodev2.h| 2 + 27 files changed, 3233 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt create mode 100644 drivers/staging/media/rockchip/vpu/Kconfig create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h -- 2.19.0.rc2
[PATCH v7 3/6] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index c88e603396f6..5efb124e5c3a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1198,6 +1198,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1205,8 +1217,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.19.0.rc2
[PATCH v7 1/6] dt-bindings: Document the Rockchip VPU bindings
Add devicetree binding documentation for Rockchip Video Processing
Unit IP.
Reviewed-by: Rob Herring
Signed-off-by: Ezequiel Garcia
---
.../bindings/media/rockchip-vpu.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
new file mode 100644
index ..35dc464ad7c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
@@ -0,0 +1,29 @@
+device-tree bindings for rockchip VPU codec
+
+Rockchip (Video Processing Unit) present in various Rockchip platforms,
+such as RK3288 and RK3399.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-vpu";
+ "rockchip,rk3399-vpu";
+- interrupts: encoding and decoding interrupt specifiers
+- interrupt-names: should be "vepu" and "vdpu"
+- clocks: phandle to VPU aclk, hclk clocks
+- clock-names: should be "aclk" and "hclk"
+- power-domains: phandle to power domain node
+- iommus: phandle to a iommu node
+
+Example:
+SoC-specific DT entry:
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
--
2.19.0.rc2
Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder
On Mon, 2018-10-01 at 14:54 -0300, Ezequiel Garcia wrote:
> On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> > On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > > This series adds support for JPEG encoding via the VPU block
> > > present in Rockchip platforms. Currently, support for RK3288
> > > and RK3399 is included.
> > >
> > > Please, see the previous versions of this cover letter for
> > > more information.
> > >
> > > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > > control. We've decided to support only baseline profile,
> > > and only add 8-bit luma and chroma tables.
> > >
> > > struct v4l2_ctrl_jpeg_quantization {
> > >__u8luma_quantization_matrix[64];
> > >__u8chroma_quantization_matrix[64];
> > > };
> > >
> > > By doing this, it's clear that we don't currently support anything
> > > but baseline.
> > >
> > > This series should apply cleanly on top of
> > >
> > > git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> > >
> > > If everyone is happy with this series, I'd like to route the devicetree
> > > changes through the rockchip tree, and the rest via the media subsystem.
> >
> > OK, so I have what is no doubt an annoying question: do we really need
> > a JPEG_RAW format?
> >
>
> Not annoying, as it helps clarify a few things :-)
> I think we do need the JPEG_RAW format. The way I see it, using
> JPEG opens a can of worms...
>
> > The JPEG header is really easy to parse for a decoder and really easy to
> > prepend to the compressed image for the encoder.
> >
> > The only reason I can see for a JPEG_RAW is if the image must start at
> > some specific address alignment. Although even then you can just pad the
> > JPEG header that you will add according to the alignment requirements.
> >
> > I know I am very late with this question, but I never looked all that
> > closely at what a JPEG header looks like. But this helped:
> >
> > https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
> >
> > and it doesn't seem difficult at all to parse or create the header.
> >
> >
>
> ... I think that having JPEG_RAW as the compressed format
> is much more clear for userspace, as it explicitly specifies
> what is expected.
>
> This way, for a stateless encoder, applications are required
> to set quantization and/or entropy tables, and are then in
> charge of using the compressed JPEG_RAW payload in whatever form
> they want. Stupid simple.
>
> On the other side, if the stateless encoder driver supports
> JPEG (creating headers in-kernel), it means that:
>
> *) applications should pass a quality control, if supported,
> and the driver will use hardcoded tables or...
>
> *) applications pass quantization control and, if supported,
> entropy control. The kernel uses them to create the JPEG frame.
> But also, some drivers (e.g. Rockchip), use default entropy
> tables, which should now be in the kernel.
>
> So the application would have to query controls to find out
> what to do. Not exactly hard, but I think having the JPEG_RAW
> is much simpler and more clear.
>
> Now, for stateless decoders, supporting JPEG_RAW means
> the application has to pass quantization and entropy
> controls, probably using the Request API.
> Given the application has parsed the JPEG,
> it knows the width and height and can request
> buffers accordingly.
>
> The hardware is stateless, and so is the driver.
>
> On the other hand, supporting JPEG would mean that
> drivers will have to parse the image, extracting
> the quantization and entropy tables.
>
> Format negotiation is now more complex,
> either we follow the stateful spec, introducing a little
> state machine in the driver... or we use the Request API,
> but that means parsing on both sides kernel and application.
>
> Either way, using JPEG_RAW is just waaay simpler and puts
> things where they belong.
>
As discussed on IRC, I'm sending a v7 for this series,
fixing only the checkpatch issues and the extra line in the
binding document.
We've agreed to move forward with JPEG_RAW, for the reasons
stated above.
Plus, we've agreed to keep this in staging until the userspace
support for JPEG_RAW format is clear.
Regards,
Ezequiel
Re: [PATCH v6 1/6] dt-bindings: Document the Rockchip VPU bindings
On Fri, 2018-09-28 at 13:53 +0200, Hans Verkuil wrote:
> On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > Add devicetree binding documentation for Rockchip Video Processing
> > Unit IP.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Ezequiel Garcia
> > ---
> > .../bindings/media/rockchip-vpu.txt | 30 +++
> > 1 file changed, 30 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> > b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> > new file mode 100644
> > index ..5e0d421301ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
> > @@ -0,0 +1,30 @@
> > +device-tree bindings for rockchip VPU codec
> > +
> > +Rockchip (Video Processing Unit) present in various Rockchip platforms,
> > +such as RK3288 and RK3399.
> > +
> > +Required properties:
> > +- compatible: value should be one of the following
> > + "rockchip,rk3288-vpu";
> > + "rockchip,rk3399-vpu";
> > +- interrupts: encoding and decoding interrupt specifiers
> > +- interrupt-names: should be "vepu" and "vdpu"
> > +- clocks: phandle to VPU aclk, hclk clocks
> > +- clock-names: should be "aclk" and "hclk"
> > +- power-domains: phandle to power domain node
> > +- iommus: phandle to a iommu node
> > +
> > +Example:
> > +SoC-specific DT entry:
> > + vpu: video-codec@ff9a {
> > + compatible = "rockchip,rk3288-vpu";
> > + reg = <0x0 0xff9a 0x0 0x800>;
> > + interrupts = ,
> > +;
> > + interrupt-names = "vepu", "vdpu";
> > + clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
> > + clock-names = "aclk", "hclk";
> > + power-domains = < RK3288_PD_VIDEO>;
> > + iommus = <_mmu>;
> > + };
> > +
> >
>
> Please remove this empty last line to avoid this warning:
>
> .git/rebase-apply/patch:41: new blank line at EOF.
>
>
Will fix.
Thanks,
Eze
Re: [PATCH v6 0/6] Add Rockchip VPU JPEG encoder
On Fri, 2018-09-28 at 14:33 +0200, Hans Verkuil wrote:
> On 09/17/2018 07:30 PM, Ezequiel Garcia wrote:
> > This series adds support for JPEG encoding via the VPU block
> > present in Rockchip platforms. Currently, support for RK3288
> > and RK3399 is included.
> >
> > Please, see the previous versions of this cover letter for
> > more information.
> >
> > Compared to v5, the only change is in the V4L2_CID_JPEG_QUANTIZATION
> > control. We've decided to support only baseline profile,
> > and only add 8-bit luma and chroma tables.
> >
> > struct v4l2_ctrl_jpeg_quantization {
> >__u8luma_quantization_matrix[64];
> >__u8chroma_quantization_matrix[64];
> > };
> >
> > By doing this, it's clear that we don't currently support anything
> > but baseline.
> >
> > This series should apply cleanly on top of
> >
> > git://linuxtv.org/hverkuil/media_tree.git br-cedrus tag.
> >
> > If everyone is happy with this series, I'd like to route the devicetree
> > changes through the rockchip tree, and the rest via the media subsystem.
>
> OK, so I have what is no doubt an annoying question: do we really need
> a JPEG_RAW format?
>
Not annoying, as it helps clarify a few things :-)
I think we do need the JPEG_RAW format. The way I see it, using
JPEG opens a can of worms...
> The JPEG header is really easy to parse for a decoder and really easy to
> prepend to the compressed image for the encoder.
>
> The only reason I can see for a JPEG_RAW is if the image must start at
> some specific address alignment. Although even then you can just pad the
> JPEG header that you will add according to the alignment requirements.
>
> I know I am very late with this question, but I never looked all that
> closely at what a JPEG header looks like. But this helped:
>
> https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format
>
> and it doesn't seem difficult at all to parse or create the header.
>
>
... I think that having JPEG_RAW as the compressed format
is much more clear for userspace, as it explicitly specifies
what is expected.
This way, for a stateless encoder, applications are required
to set quantization and/or entropy tables, and are then in
charge of using the compressed JPEG_RAW payload in whatever form
they want. Stupid simple.
On the other side, if the stateless encoder driver supports
JPEG (creating headers in-kernel), it means that:
*) applications should pass a quality control, if supported,
and the driver will use hardcoded tables or...
*) applications pass quantization control and, if supported,
entropy control. The kernel uses them to create the JPEG frame.
But also, some drivers (e.g. Rockchip), use default entropy
tables, which should now be in the kernel.
So the application would have to query controls to find out
what to do. Not exactly hard, but I think having the JPEG_RAW
is much simpler and more clear.
Now, for stateless decoders, supporting JPEG_RAW means
the application has to pass quantization and entropy
controls, probably using the Request API.
Given the application has parsed the JPEG,
it knows the width and height and can request
buffers accordingly.
The hardware is stateless, and so is the driver.
On the other hand, supporting JPEG would mean that
drivers will have to parse the image, extracting
the quantization and entropy tables.
Format negotiation is now more complex,
either we follow the stateful spec, introducing a little
state machine in the driver... or we use the Request API,
but that means parsing on both sides kernel and application.
Either way, using JPEG_RAW is just waaay simpler and puts
things where they belong.
> I also think there are more drivers (solo6x10) that
> manipulate the JPEG header.
Well, I've always thought this was kind of suboptimal.
Thanks,
Ezequiel
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
Hi Hans, Thanks for looking into. I remember MJPEG vs. JPEG being a source of confusion for me a few years ago, so clarification is greatly welcome :-) On Mon, 2018-10-01 at 15:03 +0300, Laurent Pinchart wrote: > Hi Hans, > > On Monday, 1 October 2018 14:54:29 EEST Hans Verkuil wrote: > > On 10/01/2018 01:48 PM, Laurent Pinchart wrote: > > > On Monday, 1 October 2018 11:43:04 EEST Hans Verkuil wrote: > > > > It turns out that we have both JPEG and Motion-JPEG pixel formats > > > > defined. > > > > > > > > Furthermore, some drivers support one, some the other and some both. > > > > > > > > These pixelformats both mean the same. > > > > > > Do they ? I thought MJPEG was JPEG using fixed Huffman tables that were > > > not included in the JPEG headers. > > > > I'm not aware of any difference. If there is one, then it is certainly not > > documented. > > What I can tell for sure is that many UVC devices don't include Huffman > tables > in their JPEG headers. > > > Ezequiel, since you've been working with this recently, do you know anything > > about this? > > JPEG frames must include huffman and quantization tables, as per the standard. AFAIK, there's no MJPEG specification per-se and vendors specify its own way of conveying a Motion JPEG stream. For instance, omiting the huffman table seems to be a vendor thing. Microsoft explicitly omits the huffman tables from each frame: https://www.fileformat.info/format/bmp/spec/b7c72ebab8064da48ae5ed0c053c67a4/view.htm Others could be following the same things. Like I mentioned before, Gstreamer always check for missing huffman table and adds one if missing. Gstreamer has other quirks for missing markers, e.g. deal with a missing EOI: https://github.com/GStreamer/gst-plugins-good/commit/10ff3c8e14e8fba9e0a5d696dce0bea27de644d7 I think Hans suggestion of settling on JPEG makes sense and it would be consistent with Gstreamer. Otherwise, we should specify exactly what we understand by MJPEG, but I don't think it's worth it. Thanks, Ezequiel
Re: [RFC] V4L2_PIX_FMT_MJPEG vs V4L2_PIX_FMT_JPEG
On Mon, 2018-10-01 at 08:42 -0400, Nicolas Dufresne wrote: > Hello Hans, > > Le lundi 01 octobre 2018 à 10:43 +0200, Hans Verkuil a écrit : > > It turns out that we have both JPEG and Motion-JPEG pixel formats defined. > > > > Furthermore, some drivers support one, some the other and some both. > > > > These pixelformats both mean the same. > > > > I propose that we settle on JPEG (since it seems to be used most often) and > > add JPEG support to those drivers that currently only use MJPEG. > > Thanks for looking into this. As per GStreamer code, I see 3 alias for > JPEG. V4L2_PIX_FMT_MJPEG/JPEG/PJPG. I don't know the context, this code > was written before I knew GStreamer existed. It's possible there is a > subtle difference, I have never looked at it, but clearly all our JPEG > decoder handle these as being the same. > > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l2object.c#n956 > To add more data points on the gstreamer side, there's really no difference between gstreamer's types image/jpeg and video/x-jpeg. Notably, jpegdec element just stuffs a huffman table if one is missing, for any jpeg: https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/ext/jpeg/gstjpegdec.c#n584 > > > > We also need to update the V4L2_PIX_FMT_JPEG documentation since it just > > says > > TBD: > > > > https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-compressed.html > > > > $ git grep -l V4L2_PIX_FMT_MJPEG > > drivers/media/pci/meye/meye.c > > drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c > > drivers/media/platform/sti/delta/delta-cfg.h > > drivers/media/platform/sti/delta/delta-mjpeg-dec.c > > drivers/media/usb/cpia2/cpia2_v4l.c > > drivers/media/usb/go7007/go7007-driver.c > > drivers/media/usb/go7007/go7007-fw.c > > drivers/media/usb/go7007/go7007-v4l2.c > > drivers/media/usb/s2255/s2255drv.c > > drivers/media/usb/uvc/uvc_driver.c > > drivers/staging/media/zoran/zoran_driver.c > > drivers/staging/vc04_services/bcm2835-camera/bcm2835-camera.c > > drivers/usb/gadget/function/uvc_v4l2.c > > > > It looks like s2255 and cpia2 support both already, so that would leave > > 8 drivers that need to be modified, uvc being the most important of the > > lot. > > > > Any comments? > > > > Regards, > > > > Hans > >
[PATCH v6 6/6] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Makefile | 9 + drivers/staging/media/rockchip/vpu/TODO | 5 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 123 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 126 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../media/rockchip/vpu/rk3399_vpu_hw.c| 123 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 154 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 601 + .../staging/media/rockchip/vpu/rockchip_vpu.h | 292 + .../media/rockchip/vpu/rockchip_vpu_common.h | 31 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 528 +++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 604 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ 16 files changed, 3113 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h diff --git a/MAINTAINERS b/MAINTAINERS index 9812ae1a1a40..44a043019d0e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12462,6 +12462,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index b3620a8f2d9f..c6f3404dea43 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/sunxi/Kconfig" source "drivers/staging/media/tegra-vde/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 42948f805548..43c7bee1fc8c 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_VIDEO_SUNXI) += sunxi/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..2fb99adfbdb9 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Makefile @@ -0,0 +1,9 @@ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip-vpu.o + +rockchip-vpu-y += \ + rockchip_vpu_drv.o \ + rockchip_vpu_enc.o \ + rk3288_vpu_hw.o \ + rk3288_vpu_hw_jpeg_enc.o \ + rk3399_vpu_hw.o \ + rk3399_vpu_hw_jpeg_enc.o diff --git a/drivers/staging/media/rockchip/vpu/TODO b/drivers/staging/media/rockchip/vpu/TODO new file mode 100644 index ..99bd1add7628 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/TODO @@ -0,0 +1,5 @@ +This driver is in staging until the V4L controls stabilize. + +Given the V4L controls are part of the uABI, it's better +to have the driver in staging, so users are aware of this +driver having an unstable interface. diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c new file mode 100644 index ..ccb5cd0d88a7 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c @@ -0,0 +1,123 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Rockchip VPU codec driver + * + * Copyright (C) 2018 Rockchip Electronics Co., Ltd.
[PATCH v6 5/6] media: Add controls for JPEG quantization tables
From: Shunqian Zheng
Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace
configure the JPEG quantization tables.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
.../media/uapi/v4l/extended-controls.rst | 25 +++
.../media/videodev2.h.rst.exceptions | 1 +
drivers/media/v4l2-core/v4l2-ctrls.c | 8 ++
include/uapi/linux/v4l2-controls.h| 10
include/uapi/linux/videodev2.h| 1 +
5 files changed, 45 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
b/Documentation/media/uapi/v4l/extended-controls.rst
index 65a1d873196b..6effae175be1 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3530,7 +3530,32 @@ JPEG Control IDs
Specify which JPEG markers are included in compressed stream. This
control is valid only for encoders.
+.. _jpeg-quant-tables-control:
+``V4L2_CID_JPEG_QUANTIZATION (struct)``
+Specifies the luma and chroma quantization matrices for encoding
+or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer.
+This control supports 8-bit quantization coefficients, for
+the baseline profile, as specified by :ref:`itu-t81`.
+Coefficients must be set in JPEG zigzag scan order.
+
+
+.. c:type:: struct v4l2_ctrl_jpeg_quantization
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_jpeg_quantization
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - __u8
+ - ``luma_quantization_matrix[64]``
+ - Sets the luma quantization table.
+
+* - __u8
+ - ``chroma_quantization_matrix[64]``
+ - Sets the chroma quantization table.
.. flat-table::
:header-rows: 0
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index 1c043d552313..fbdd827e4229 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -131,6 +131,7 @@ replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_MPEG2_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_MPEG2_QUANTIZATION :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type`
# V4L2 capability defines
replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index dfdc31edb1dd..7b913a461b2e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1001,6 +1001,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers";
+ case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization
Tables";
/* Image source controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1288,6 +1289,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DETECT_MD_REGION_GRID:
*type = V4L2_CTRL_TYPE_U8;
break;
+ case V4L2_CID_JPEG_QUANTIZATION:
+ *type = V4L2_CTRL_TYPE_JPEG_QUANTIZATION;
+ break;
case V4L2_CID_DETECT_MD_THRESHOLD_GRID:
*type = V4L2_CTRL_TYPE_U16;
break;
@@ -1667,6 +1671,7 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32
idx,
return 0;
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
+ case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
return 0;
default:
@@ -2249,6 +2254,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
case V4L2_CTRL_TYPE_MPEG2_QUANTIZATION:
elem_size = sizeof(struct v4l2_ctrl_mpeg2_quantization);
break;
+ case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
+ elem_size = sizeof(struct v4l2_ctrl_jpeg_quantization);
+ break;
default:
if (type < V4L2_CTRL_COMPOUND_TYPES)
elem_size = sizeof(s32);
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 51b095898f4b..5a8bdb732cfe 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -990,6 +990,16 @@ enum v4l2_jpeg_chroma_subsampling {
#defineV4L2_JPEG_ACTIVE_MARKER_DQT (1 << 17)
#defineV4L2_JPEG_ACTIVE_MARKER_DHT (1 << 18)
+#define V4L2_CID_JPEG_QUANTIZATION (V4L2_CID_JPEG_CLASS_BASE + 5)
+struct v4l2_ctrl_jpeg_quantization {
+ /* ITU-T.81 specifie
[PATCH v6 4/6] media: Add JPEG_RAW format
From: Shunqian Zheng
Add V4L2_PIX_FMT_JPEG_RAW format that does not contain
JPEG header in the output frame.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
index ba0f6c49d9bf..ad73076276ec 100644
--- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
@@ -23,6 +23,15 @@ Compressed Formats
- 'JPEG'
- TBD. See also :ref:`VIDIOC_G_JPEGCOMP `,
:ref:`VIDIOC_S_JPEGCOMP `.
+* .. _V4L2-PIX-FMT-JPEG-RAW:
+
+ - ``V4L2_PIX_FMT_JPEG_RAW``
+ - 'Raw JPEG'
+ - Raw JPEG bitstream, containing a compressed payload. This format
+contains an image scan, i.e. without any metadata or headers.
+The user is expected to set the needed metadata such as
+quantization and entropy encoding tables, via ``V4L2_CID_JPEG``
+controls, see :ref:`jpeg-control-id`.
* .. _V4L2-PIX-FMT-MPEG:
- ``V4L2_PIX_FMT_MPEG``
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index c63746968fa3..945efb2894d0 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1301,6 +1301,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
/* Max description length mask: descr =
"0123456789012345678901234567890" */
case V4L2_PIX_FMT_MJPEG:descr = "Motion-JPEG"; break;
case V4L2_PIX_FMT_JPEG: descr = "JFIF JPEG"; break;
+ case V4L2_PIX_FMT_JPEG_RAW: descr = "Raw JPEG"; break;
case V4L2_PIX_FMT_DV: descr = "1394"; break;
case V4L2_PIX_FMT_MPEG: descr = "MPEG-1/2/4"; break;
case V4L2_PIX_FMT_H264: descr = "H.264"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index b133e69ad5ce..4c979886e8b2 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -627,6 +627,7 @@ struct v4l2_pix_format {
/* compressed formats */
#define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG
*/
#define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
*/
+#define V4L2_PIX_FMT_JPEG_RAW v4l2_fourcc('J', 'P', 'G', 'R') /* JFIF JPEG RAW
without headers */
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
start codes */
--
2.19.0.rc2
[PATCH v6 3/6] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index c88e603396f6..5efb124e5c3a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1198,6 +1198,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1205,8 +1217,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.19.0.rc2
[PATCH v6 2/6] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.19.0.rc2
[PATCH v6 0/6] Add Rockchip VPU JPEG encoder
the quantization control to support only strict baseline JPEGs, with 8-bit coefficients. v5: - Make coefficients 2-byte wide, to support 8-bit and 16-bit precision coefficient. Also, add a 'precision' field, to allow the user to specifiy the coefficient precision. - Minor style changes as requested by Hans. - Get rid of all the unused leftover code. - Move driver to staging. The driver will support video encoding, via the request API. So let's use staging until the controls are stabilized. v4: - Change luma and chroma array controls, with a compound control, as suggested by Paul. v3: - Refactor driver to allow a more elegant integration with other codec modes (h264 decoding, jpeg decoding, etc). Each variant can now be encoders, decoders or both. - Register driver in the media controller framework, in preparation for the Request API. - Set values for JPEG quantization controls in the core, as suggested by Tomasz and Hans. - Move pm_runtime_get/put to run/done, reducing power consumption. This was possible thanks to Miouyouyou, who pointed out the power domains missing [1]. - Use bulk clock API for simpler code. v2: - Add devicetree binding documentation and devicetree changes - Add documentation to added pixel format and controls - Address Hans' review comments - Get rid of unused running_ctx field - Fix wrong planar pixel format depths - Other minor changes for v4l2-compliance - Drop .crop support, we will add support for the selector API later, if needed. [1] https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.18/DTS/0026-ARM-DTSI-rk3288-Set-the-VPU-MMU-power-domains.patch Ezequiel Garcia (4): dt-bindings: Document the Rockchip VPU bindings ARM: dts: rockchip: add VPU device node for RK3288 arm64: dts: rockchip: add VPU device node for RK3399 media: add Rockchip VPU JPEG encoder driver Shunqian Zheng (2): media: Add JPEG_RAW format media: Add controls for JPEG quantization tables .../bindings/media/rockchip-vpu.txt | 30 + .../media/uapi/v4l/extended-controls.rst | 25 + .../media/uapi/v4l/pixfmt-compressed.rst | 9 + .../media/videodev2.h.rst.exceptions | 1 + MAINTAINERS | 7 + arch/arm/boot/dts/rk3288.dtsi | 14 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +- drivers/media/v4l2-core/v4l2-ctrls.c | 8 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Makefile | 9 + drivers/staging/media/rockchip/vpu/TODO | 5 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 123 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 126 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../media/rockchip/vpu/rk3399_vpu_hw.c| 123 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 154 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 601 + .../staging/media/rockchip/vpu/rockchip_vpu.h | 292 + .../media/rockchip/vpu/rockchip_vpu_common.h | 31 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 528 +++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 604 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ include/uapi/linux/v4l2-controls.h| 10 + include/uapi/linux/videodev2.h| 2 + 26 files changed, 3225 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h -- 2.19.0.rc2
[PATCH v6 1/6] dt-bindings: Document the Rockchip VPU bindings
Add devicetree binding documentation for Rockchip Video Processing
Unit IP.
Reviewed-by: Rob Herring
Signed-off-by: Ezequiel Garcia
---
.../bindings/media/rockchip-vpu.txt | 30 +++
1 file changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.txt
b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
new file mode 100644
index ..5e0d421301ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-vpu.txt
@@ -0,0 +1,30 @@
+device-tree bindings for rockchip VPU codec
+
+Rockchip (Video Processing Unit) present in various Rockchip platforms,
+such as RK3288 and RK3399.
+
+Required properties:
+- compatible: value should be one of the following
+ "rockchip,rk3288-vpu";
+ "rockchip,rk3399-vpu";
+- interrupts: encoding and decoding interrupt specifiers
+- interrupt-names: should be "vepu" and "vdpu"
+- clocks: phandle to VPU aclk, hclk clocks
+- clock-names: should be "aclk" and "hclk"
+- power-domains: phandle to power domain node
+- iommus: phandle to a iommu node
+
+Example:
+SoC-specific DT entry:
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
--
2.19.0.rc2
Re: [PATCH 2/2] vicodec: set state->info before calling the encode/decode funcs
On Mon, 2018-09-10 at 13:16 -0400, Nicolas Dufresne wrote: > Le lundi 10 septembre 2018 à 12:37 -0300, Ezequiel Garcia a écrit : > > On Mon, 2018-09-10 at 17:00 +0200, Hans Verkuil wrote: > > > From: Hans Verkuil > > > > > > state->info was NULL since I completely forgot to set state->info. > > > Oops. > > > > > > Reported-by: Ezequiel Garcia > > > Signed-off-by: Hans Verkuil > > > > For both patches: > > > > Tested-by: Ezequiel Garcia > > > > With these changes, now this gstreamer pipeline no longer > > crashes: > > > > gst-launch-1.0 -v videotestsrc num-buffers=30 ! video/x- > > raw,width=1280,height=720 ! v4l2fwhtenc capture-io-mode=mmap output- > > io-mode=mmap ! v4l2fwhtdec > > capture-io-mode=mmap output-io-mode=mmap ! fakesink > > > > A few things: > > > > * You now need to mark "[PATCH] vicodec: fix sparse warning" as > > invalid. > > * v4l2fwhtenc/v4l2fwhtdec elements are not upstream yet. > > * Gstreamer doesn't end properly; and it seems to negotiate > > Is the driver missing CMD_STOP implementation ? (draining flow) > I think that's the case. Gstreamer debug log, right before it stalls: 0:00:16.929785442 180 0x5593bcbd18a0 DEBUG v4l2videodec gstv4l2videodec.c:375:gst_v4l2_video_dec_finish: Finishing decoding 0:00:16.931866009 180 0x5593bcbd18a0 DEBUG v4l2videodec gstv4l2videodec.c:340:gst_v4l2_decoder_cmd: sending v4l2 decoder command 1 with flags 0 0:00:16.934260349 180 0x5593bcbd18a0 DEBUG v4l2videodec gstv4l2videodec.c:384:gst_v4l2_video_dec_finish: Waiting for decoder stop [stalls here] Regards, Ezequiel
Re: [PATCH 1/2] vicodec: Drop unneeded symbol dependency
On Mon, 2018-09-10 at 17:23 +0200, Hans Verkuil wrote: > On 09/10/2018 05:21 PM, Ezequiel Garcia wrote: > > The vicodec doesn't use the Subdev API, so drop the dependency. > > > > Signed-off-by: Ezequiel Garcia > > --- > > drivers/media/platform/vicodec/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/media/platform/vicodec/Kconfig > > b/drivers/media/platform/vicodec/Kconfig > > index 2503bcb1529f..ad13329e3461 100644 > > --- a/drivers/media/platform/vicodec/Kconfig > > +++ b/drivers/media/platform/vicodec/Kconfig > > @@ -1,6 +1,6 @@ > > config VIDEO_VICODEC > > tristate "Virtual Codec Driver" > > - depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API > > But it definitely needs the MEDIA_CONTROLLER. That's what it should depend on. > Does it really? The code have proper ifdefs.
Re: [PATCH 2/2] vicodec: set state->info before calling the encode/decode funcs
On Mon, 2018-09-10 at 17:00 +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> state->info was NULL since I completely forgot to set state->info.
> Oops.
>
> Reported-by: Ezequiel Garcia
> Signed-off-by: Hans Verkuil
For both patches:
Tested-by: Ezequiel Garcia
With these changes, now this gstreamer pipeline no longer
crashes:
gst-launch-1.0 -v videotestsrc num-buffers=30 !
video/x-raw,width=1280,height=720 ! v4l2fwhtenc capture-io-mode=mmap
output-io-mode=mmap ! v4l2fwhtdec
capture-io-mode=mmap output-io-mode=mmap ! fakesink
A few things:
* You now need to mark "[PATCH] vicodec: fix sparse warning" as invalid.
* v4l2fwhtenc/v4l2fwhtdec elements are not upstream yet.
* Gstreamer doesn't end properly; and it seems to negotiate
different sizes for encoded and decoded unless explicitly set.
Thanks!
> drivers/media/platform/vicodec/vicodec-core.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/vicodec/vicodec-core.c
> b/drivers/media/platform/vicodec/vicodec-core.c
> index fdd77441a47b..5d42a8414283 100644
> --- a/drivers/media/platform/vicodec/vicodec-core.c
> +++ b/drivers/media/platform/vicodec/vicodec-core.c
> @@ -176,12 +176,15 @@ static int device_process(struct vicodec_ctx *ctx,
> }
>
> if (ctx->is_enc) {
> - unsigned int size = v4l2_fwht_encode(state, p_in, p_out);
> -
> - vb2_set_plane_payload(_vb->vb2_buf, 0, size);
> + state->info = q_out->info;
> + ret = v4l2_fwht_encode(state, p_in, p_out);
> + if (ret < 0)
> + return ret;
> + vb2_set_plane_payload(_vb->vb2_buf, 0, ret);
> } else {
> + state->info = q_cap->info;
> ret = v4l2_fwht_decode(state, p_in, p_out);
> - if (ret)
> + if (ret < 0)
> return ret;
> vb2_set_plane_payload(_vb->vb2_buf, 0, q_cap->sizeimage);
> }
[PATCH 2/2] vicodec: Drop unused job_abort()
The vicodec does not use the aborting field. In fact, this driver
can't really cancel any work, since it performs all the work
in device_run().
Signed-off-by: Ezequiel Garcia
---
drivers/media/platform/vicodec/vicodec-core.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index bbc48fcaa563..8d455c42163e 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -112,8 +112,6 @@ struct vicodec_ctx {
struct v4l2_ctrl_handler hdl;
- /* Abort requested by m2m */
- int aborting;
struct vb2_v4l2_buffer *last_src_buf;
struct vb2_v4l2_buffer *last_dst_buf;
@@ -376,14 +374,6 @@ static int job_ready(void *priv)
return 1;
}
-static void job_abort(void *priv)
-{
- struct vicodec_ctx *ctx = priv;
-
- /* Will cancel the transaction in the next interrupt handler */
- ctx->aborting = 1;
-}
-
/*
* video ioctls
*/
@@ -1268,7 +1258,6 @@ static const struct video_device vicodec_videodev = {
static const struct v4l2_m2m_ops m2m_ops = {
.device_run = device_run,
- .job_abort = job_abort,
.job_ready = job_ready,
};
--
2.19.0.rc2
[PATCH 1/2] vicodec: Drop unneeded symbol dependency
The vicodec doesn't use the Subdev API, so drop the dependency. Signed-off-by: Ezequiel Garcia --- drivers/media/platform/vicodec/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/vicodec/Kconfig b/drivers/media/platform/vicodec/Kconfig index 2503bcb1529f..ad13329e3461 100644 --- a/drivers/media/platform/vicodec/Kconfig +++ b/drivers/media/platform/vicodec/Kconfig @@ -1,6 +1,6 @@ config VIDEO_VICODEC tristate "Virtual Codec Driver" - depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + depends on VIDEO_DEV && VIDEO_V4L2 select VIDEOBUF2_VMALLOC select V4L2_MEM2MEM_DEV default n -- 2.19.0.rc2
Re: [PATCH v5 5/6] media: Add controls for JPEG quantization tables
Hi Hans, Thanks for the review. On Mon, 2018-09-10 at 14:42 +0200, Hans Verkuil wrote: > On 09/06/2018 12:00 AM, Ezequiel Garcia wrote: > > From: Shunqian Zheng > > > > Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace > > configure the JPEG quantization tables. > > > > Signed-off-by: Shunqian Zheng > > Signed-off-by: Ezequiel Garcia > > --- > > .../media/uapi/v4l/extended-controls.rst | 31 +++ > > .../media/videodev2.h.rst.exceptions | 1 + > > drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++ > > include/uapi/linux/v4l2-controls.h| 12 +++ > > include/uapi/linux/videodev2.h| 1 + > > 5 files changed, 55 insertions(+) > > > > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst > > b/Documentation/media/uapi/v4l/extended-controls.rst > > index 9f7312bf3365..1335d27d30f3 100644 > > --- a/Documentation/media/uapi/v4l/extended-controls.rst > > +++ b/Documentation/media/uapi/v4l/extended-controls.rst > > @@ -3354,7 +3354,38 @@ JPEG Control IDs > > Specify which JPEG markers are included in compressed stream. This > > control is valid only for encoders. > > > > +.. _jpeg-quant-tables-control: > > > > +``V4L2_CID_JPEG_QUANTIZATION (struct)`` > > +Specifies the luma and chroma quantization matrices for encoding > > +or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81` > > +specification allows 8-bit quantization coefficients for > > +baseline profile images, and 8-bit or 16-bit for extended profile > > +images. Supporting or not 16-bit precision coefficients is > > driver-specific. > > +Coefficients must be set in JPEG zigzag scan order. > > + > > + > > +.. c:type:: struct v4l2_ctrl_jpeg_quantization > > + > > +.. cssclass:: longtable > > + > > +.. flat-table:: struct v4l2_ctrl_jpeg_quantization > > +:header-rows: 0 > > +:stub-columns: 0 > > +:widths: 1 1 2 > > + > > +* - __u8 > > + - ``precision`` > > + - Specifies the coefficient precision. User shall set 0 > > +for 8-bit, and 1 for 16-bit. > > So does specifying 1 here switch the HW encoder to use extended profile? > What if the HW only supports baseline? The rockchip driver doesn't appear > to check the precision field at all... > The driver is missing to check that, when the user sets this control. > I think this needs a bit more thought. > > I am not at all sure that this is the right place for the precision field. > This is really about JPEG profiles, so I would kind of expect a JPEG PROFILE > control (just like other codec profiles), or possibly a new pixelformat for > extended profiles. > > And based on that the driver would interpret these matrix values as 8 or > 16 bits. > Right, the JPEG profile control is definitely needed. I haven't add it because it wouldn't be used, since this VPU can only do baseline. However, the problem is that some JPEGs in the wild have with 8-bit data and 16-bit quantization coefficients, as per [1] and [2]: [1] https://github.com/martinhath/jpeg-rust/issues/1 [2] https://github.com/libjpeg-turbo/libjpeg-turbo/pull/90 So, in order to support decoding of these images, I've added the precision field to the quantization control. The user would be able to set a baseline or extended profile thru a (future) profile control, and if 16-bit tables are found, and if the hardware supports them, the driver would be able to support them. Another option, which might be even better, is have explicit baseline and extended quantization tables controls, e.g.: V4L2_CID_JPEG_QUANT and V4L2_CID_JPEG_EXT_QUANT. Thanks, Ezequiel
[PATCH v5 6/6] media: add Rockchip VPU JPEG encoder driver
Add a mem2mem driver for the VPU available on Rockchip SoCs. Currently only JPEG encoding is supported, for RK3399 and RK3288 platforms. Signed-off-by: Ezequiel Garcia --- MAINTAINERS | 7 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Makefile | 9 + drivers/staging/media/rockchip/vpu/TODO | 5 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 123 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 129 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../media/rockchip/vpu/rk3399_vpu_hw.c| 123 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 157 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 601 + .../staging/media/rockchip/vpu/rockchip_vpu.h | 296 + .../media/rockchip/vpu/rockchip_vpu_common.h | 31 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 528 +++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 604 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ 16 files changed, 3123 insertions(+) create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h diff --git a/MAINTAINERS b/MAINTAINERS index a5b256b25905..7612029cd960 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12452,6 +12452,13 @@ S: Maintained F: drivers/media/platform/rockchip/rga/ F: Documentation/devicetree/bindings/media/rockchip-rga.txt +ROCKCHIP VPU CODEC DRIVER +M: Ezequiel Garcia +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/staging/media/platform/rockchip/vpu/ +F: Documentation/devicetree/bindings/media/rockchip-vpu.txt + ROCKER DRIVER M: Jiri Pirko L: net...@vger.kernel.org diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index db5cf67047ad..c7091dc3897a 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -31,6 +31,8 @@ source "drivers/staging/media/mt9t031/Kconfig" source "drivers/staging/media/omap4iss/Kconfig" +source "drivers/staging/media/rockchip/vpu/Kconfig" + source "drivers/staging/media/tegra-vde/Kconfig" source "drivers/staging/media/zoran/Kconfig" diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 503fbe47fa58..236aa1061534 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -7,3 +7,4 @@ obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/ obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip/vpu/ diff --git a/drivers/staging/media/rockchip/vpu/Makefile b/drivers/staging/media/rockchip/vpu/Makefile new file mode 100644 index ..2fb99adfbdb9 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/Makefile @@ -0,0 +1,9 @@ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU) += rockchip-vpu.o + +rockchip-vpu-y += \ + rockchip_vpu_drv.o \ + rockchip_vpu_enc.o \ + rk3288_vpu_hw.o \ + rk3288_vpu_hw_jpeg_enc.o \ + rk3399_vpu_hw.o \ + rk3399_vpu_hw_jpeg_enc.o diff --git a/drivers/staging/media/rockchip/vpu/TODO b/drivers/staging/media/rockchip/vpu/TODO new file mode 100644 index ..99bd1add7628 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/TODO @@ -0,0 +1,5 @@ +This driver is in staging until the V4L controls stabilize. + +Given the V4L controls are part of the uABI, it's better +to have the driver in staging, so users are aware of this +driver having an unstable interface. diff --git a/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c new file mode 100644 index ..ccb5cd0d88a7 --- /dev/null +++ b/drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c @@ -0,0 +1,123 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Rockchip VPU codec driver + * + * Copyright (C) 2018 Rockchip Electron
[PATCH v5 0/6] Add Rockchip VPU JPEG encoder
now be encoders, decoders or both. - Register driver in the media controller framework, in preparation for the Request API. - Set values for JPEG quantization controls in the core, as suggested by Tomasz and Hans. - Move pm_runtime_get/put to run/done, reducing power consumption. This was possible thanks to Miouyouyou, who pointed out the power domains missing [1]. - Use bulk clock API for simpler code. v2: - Add devicetree binding documentation and devicetree changes - Add documentation to added pixel format and controls - Address Hans' review comments - Get rid of unused running_ctx field - Fix wrong planar pixel format depths - Other minor changes for v4l2-compliance - Drop .crop support, we will add support for the selector API later, if needed. [1] https://github.com/Miouyouyou/RockMyy/blob/master/patches/kernel/v4.18/DTS/0026-ARM-DTSI-rk3288-Set-the-VPU-MMU-power-domains.patch Ezequiel Garcia (4): dt-bindings: Document the Rockchip VPU bindings ARM: dts: rockchip: add VPU device node for RK3288 arm64: dts: rockchip: add VPU device node for RK3399 media: add Rockchip VPU JPEG encoder driver Shunqian Zheng (2): media: Add JPEG_RAW format media: Add controls for JPEG quantization tables .../bindings/media/rockchip-vpu.txt | 30 + .../media/uapi/v4l/extended-controls.rst | 31 + .../media/uapi/v4l/pixfmt-compressed.rst | 9 + .../media/videodev2.h.rst.exceptions | 1 + MAINTAINERS | 7 + arch/arm/boot/dts/rk3288.dtsi | 14 +- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +- drivers/media/v4l2-core/v4l2-ctrls.c | 10 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + drivers/staging/media/Kconfig | 2 + drivers/staging/media/Makefile| 1 + drivers/staging/media/rockchip/vpu/Makefile | 9 + drivers/staging/media/rockchip/vpu/TODO | 5 + .../media/rockchip/vpu/rk3288_vpu_hw.c| 123 .../rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c | 129 .../media/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../media/rockchip/vpu/rk3399_vpu_hw.c| 123 .../rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c | 157 + .../media/rockchip/vpu/rk3399_vpu_regs.h | 601 + .../staging/media/rockchip/vpu/rockchip_vpu.h | 296 + .../media/rockchip/vpu/rockchip_vpu_common.h | 31 + .../media/rockchip/vpu/rockchip_vpu_drv.c | 528 +++ .../media/rockchip/vpu/rockchip_vpu_enc.c | 604 ++ .../media/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ include/uapi/linux/v4l2-controls.h| 12 + include/uapi/linux/videodev2.h| 2 + 26 files changed, 3245 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/rockchip-vpu.txt create mode 100644 drivers/staging/media/rockchip/vpu/Makefile create mode 100644 drivers/staging/media/rockchip/vpu/TODO create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_hw_jpeg_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/staging/media/rockchip/vpu/rockchip_vpu_hw.h -- 2.18.0
[PATCH v5 5/6] media: Add controls for JPEG quantization tables
From: Shunqian Zheng
Add V4L2_CID_JPEG_QUANTIZATION compound control to allow userspace
configure the JPEG quantization tables.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
.../media/uapi/v4l/extended-controls.rst | 31 +++
.../media/videodev2.h.rst.exceptions | 1 +
drivers/media/v4l2-core/v4l2-ctrls.c | 10 ++
include/uapi/linux/v4l2-controls.h| 12 +++
include/uapi/linux/videodev2.h| 1 +
5 files changed, 55 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
b/Documentation/media/uapi/v4l/extended-controls.rst
index 9f7312bf3365..1335d27d30f3 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3354,7 +3354,38 @@ JPEG Control IDs
Specify which JPEG markers are included in compressed stream. This
control is valid only for encoders.
+.. _jpeg-quant-tables-control:
+``V4L2_CID_JPEG_QUANTIZATION (struct)``
+Specifies the luma and chroma quantization matrices for encoding
+or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. The :ref:`itu-t81`
+specification allows 8-bit quantization coefficients for
+baseline profile images, and 8-bit or 16-bit for extended profile
+images. Supporting or not 16-bit precision coefficients is driver-specific.
+Coefficients must be set in JPEG zigzag scan order.
+
+
+.. c:type:: struct v4l2_ctrl_jpeg_quantization
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_ctrl_jpeg_quantization
+:header-rows: 0
+:stub-columns: 0
+:widths: 1 1 2
+
+* - __u8
+ - ``precision``
+ - Specifies the coefficient precision. User shall set 0
+for 8-bit, and 1 for 16-bit.
+
+* - __u16
+ - ``luma_quantization_matrix[64]``
+ - Sets the luma quantization table.
+
+* - __u16
+ - ``chroma_quantization_matrix[64]``
+ - Sets the chroma quantization table.
.. flat-table::
:header-rows: 0
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index ca9f0edc579e..a0a38e92bf38 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -129,6 +129,7 @@ replace symbol V4L2_CTRL_TYPE_STRING
:c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_U16 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_U32 :c:type:`v4l2_ctrl_type`
replace symbol V4L2_CTRL_TYPE_U8 :c:type:`v4l2_ctrl_type`
+replace symbol V4L2_CTRL_TYPE_JPEG_QUANTIZATION :c:type:`v4l2_ctrl_type`
# V4L2 capability defines
replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 599c1cbff3b9..305bd7a9b7f1 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -999,6 +999,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_JPEG_RESTART_INTERVAL:return "Restart Interval";
case V4L2_CID_JPEG_COMPRESSION_QUALITY: return "Compression Quality";
case V4L2_CID_JPEG_ACTIVE_MARKER: return "Active Markers";
+ case V4L2_CID_JPEG_QUANTIZATION:return "JPEG Quantization
Tables";
/* Image source controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1286,6 +1287,9 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DETECT_MD_REGION_GRID:
*type = V4L2_CTRL_TYPE_U8;
break;
+ case V4L2_CID_JPEG_QUANTIZATION:
+ *type = V4L2_CTRL_TYPE_JPEG_QUANTIZATION;
+ break;
case V4L2_CID_DETECT_MD_THRESHOLD_GRID:
*type = V4L2_CTRL_TYPE_U16;
break;
@@ -1612,6 +1616,9 @@ static int std_validate(const struct v4l2_ctrl *ctrl, u32
idx,
return -ERANGE;
return 0;
+ case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
+ return 0;
+
default:
return -EINVAL;
}
@@ -2133,6 +2140,9 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
case V4L2_CTRL_TYPE_U32:
elem_size = sizeof(u32);
break;
+ case V4L2_CTRL_TYPE_JPEG_QUANTIZATION:
+ elem_size = sizeof(struct v4l2_ctrl_jpeg_quantization);
+ break;
default:
if (type < V4L2_CTRL_COMPOUND_TYPES)
elem_size = sizeof(s32);
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index e4ee10ee917d..856b3325052f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -987,6 +987,18 @@ enum v4l2_jpeg_chroma_subsampling {
#defineV4L2_JPEG_ACTIVE_MARKER_DQT (1 << 17)
#define
[PATCH v5 3/6] arm64: dts: rockchip: add VPU device node for RK3399
Add the Video Processing Unit node for the RK3399 SoC.
Also, fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index c88e603396f6..5efb124e5c3a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1198,6 +1198,18 @@
status = "disabled";
};
+ vpu: video-codec@ff65 {
+ compatible = "rockchip,rk3399-vpu";
+ reg = <0x0 0xff65 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3399_PD_VCODEC>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff650800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff650800 0x0 0x40>;
@@ -1205,8 +1217,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3399_PD_VCODEC>;
#iommu-cells = <0>;
- status = "disabled";
};
vdec_mmu: iommu@ff660480 {
--
2.18.0
[PATCH v5 4/6] media: Add JPEG_RAW format
From: Shunqian Zheng
Add V4L2_PIX_FMT_JPEG_RAW format that does not contain
JPEG header in the output frame.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
Documentation/media/uapi/v4l/pixfmt-compressed.rst | 9 +
drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+)
diff --git a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
index d04b18adac33..39222091a87c 100644
--- a/Documentation/media/uapi/v4l/pixfmt-compressed.rst
+++ b/Documentation/media/uapi/v4l/pixfmt-compressed.rst
@@ -23,6 +23,15 @@ Compressed Formats
- 'JPEG'
- TBD. See also :ref:`VIDIOC_G_JPEGCOMP `,
:ref:`VIDIOC_S_JPEGCOMP `.
+* .. _V4L2-PIX-FMT-JPEG-RAW:
+
+ - ``V4L2_PIX_FMT_JPEG_RAW``
+ - 'Raw JPEG'
+ - Raw JPEG bitstream, containing a compressed payload. This format
+contains an image scan, i.e. without any metadata or headers.
+The user is expected to set the needed metadata such as
+quantization and entropy encoding tables, via ``V4L2_CID_JPEG``
+controls, see :ref:`jpeg-control-id`.
* .. _V4L2-PIX-FMT-MPEG:
- ``V4L2_PIX_FMT_MPEG``
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 54afc9c7ee6e..0dcd95f4bdf1 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1301,6 +1301,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
/* Max description length mask: descr =
"0123456789012345678901234567890" */
case V4L2_PIX_FMT_MJPEG:descr = "Motion-JPEG"; break;
case V4L2_PIX_FMT_JPEG: descr = "JFIF JPEG"; break;
+ case V4L2_PIX_FMT_JPEG_RAW: descr = "Raw JPEG"; break;
case V4L2_PIX_FMT_DV: descr = "1394"; break;
case V4L2_PIX_FMT_MPEG: descr = "MPEG-1/2/4"; break;
case V4L2_PIX_FMT_H264: descr = "H.264"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 622f0479d668..f9f3ae5b489e 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -627,6 +627,7 @@ struct v4l2_pix_format {
/* compressed formats */
#define V4L2_PIX_FMT_MJPEGv4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG
*/
#define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG
*/
+#define V4L2_PIX_FMT_JPEG_RAW v4l2_fourcc('J', 'P', 'G', 'R') /* JFIF JPEG RAW
without headers */
#define V4L2_PIX_FMT_DV v4l2_fourcc('d', 'v', 's', 'd') /* 1394
*/
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
start codes */
--
2.18.0
[PATCH v5 2/6] ARM: dts: rockchip: add VPU device node for RK3288
Add the Video Processing Unit node for RK3288 SoC.
Fix the VPU IOMMU node, which was disabled and lacking
its power domain property.
Signed-off-by: Ezequiel Garcia
---
arch/arm/boot/dts/rk3288.dtsi | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0840ffb3205c..40d203cdca09 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1223,6 +1223,18 @@
};
};
+ vpu: video-codec@ff9a {
+ compatible = "rockchip,rk3288-vpu";
+ reg = <0x0 0xff9a 0x0 0x800>;
+ interrupts = ,
+;
+ interrupt-names = "vepu", "vdpu";
+ clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
+ clock-names = "aclk", "hclk";
+ power-domains = < RK3288_PD_VIDEO>;
+ iommus = <_mmu>;
+ };
+
vpu_mmu: iommu@ff9a0800 {
compatible = "rockchip,iommu";
reg = <0x0 0xff9a0800 0x0 0x100>;
@@ -1230,8 +1242,8 @@
interrupt-names = "vpu_mmu";
clocks = < ACLK_VCODEC>, < HCLK_VCODEC>;
clock-names = "aclk", "iface";
+ power-domains = < RK3288_PD_VIDEO>;
#iommu-cells = <0>;
- status = "disabled";
};
hevc_mmu: iommu@ff9c0440 {
--
2.18.0
