cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Aug 23 05:00:13 CEST 2018 media-tree git hash:da2048b7348a0be92f706ac019e022139e29495e media_build git hash: baf45935ffad914f33faf751ad9f4d0dd276c021 v4l-utils git hash: 015ca7524748fa7cef296102c68b631b078b63c6 edid-decode git hash: b2da1516df3cc2756bfe8d1fa06d7bf2562ba1f4 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.17.0-1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-i686: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-i686: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-i686: OK linux-2.6.39.4-x86_64: OK linux-3.0.101-i686: OK linux-3.0.101-x86_64: OK linux-3.1.10-i686: OK linux-3.1.10-x86_64: OK linux-3.2.102-i686: OK linux-3.2.102-x86_64: OK linux-3.3.8-i686: OK linux-3.3.8-x86_64: OK linux-3.4.113-i686: OK linux-3.4.113-x86_64: OK linux-3.5.7-i686: OK linux-3.5.7-x86_64: OK linux-3.6.11-i686: OK linux-3.6.11-x86_64: OK linux-3.7.10-i686: OK linux-3.7.10-x86_64: OK linux-3.8.13-i686: OK linux-3.8.13-x86_64: OK linux-3.9.11-i686: OK linux-3.9.11-x86_64: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.115-i686: OK linux-3.18.115-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.18-i686: OK linux-4.18-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [RFC] Request API and V4L2 capabilities
Le mercredi 22 août 2018 à 16:52 +0200, Paul Kocialkowski a écrit : > Hi, > > On Wed, 2018-08-15 at 09:57 -0400, Nicolas Dufresne wrote: > > Le lundi 06 août 2018 à 10:16 +0200, Paul Kocialkowski a écrit : > > > Hi Hans and all, > > > > > > On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote: > > > > Hi all, > > > > > > > > While the Request API patch series addresses all the core API issues, > > > > there > > > > are some high-level considerations as well: > > > > > > > > 1) How can the application tell that the Request API is supported and > > > > for > > > >which buffer types (capture/output) and pixel formats? > > > > > > > > 2) How can the application tell if the Request API is required as > > > > opposed to being > > > >optional? > > > > > > > > 3) Some controls may be required in each request, how to let userspace > > > > know this? > > > >Is it even necessary to inform userspace? > > > > > > > > 4) (For bonus points): How to let the application know which streaming > > > > I/O modes > > > >are available? That's never been possible before, but it would be > > > > very nice > > > >indeed if that's made explicit. > > > > > > Thanks for bringing up these considerations and questions, which perhaps > > > cover the last missing bits for streamlined use of the request API by > > > userspace. I would suggest another item, related to 3): > > > > > > 5) How can applications tell whether the driver supports a specific > > > codec profile/level, not only for encoding but also for decoding? It's > > > common for low-end embedded hardware to not support the most advanced > > > profiles (e.g. H264 high profile). > > > > Hi Paul, after some discussion with Philip, he sent a proposal patch > > that enables profile/level extended CID support to decoders too. The > > control is made read-only, the point is not really the CID get/set but > > that the controls allow enumerating the supported values. This seems > > quite straightforward and easy to use. > > > > This enumeration is already provided this way some of the existing > > sate-full encoders. > > Sounds great, thanks for looking into it! I looked for the patch in the > list, but couldn't find it off-hand. Do you have a link to it? I would > like to bind it to the Cedrus VPU driver eventually. I believe it is that one: https://patchwork.kernel.org/patch/10494379/ > > Cheers, > > Paul > > > > > Since the Request API associates data with frame buffers it makes sense > > > > to expose > > > > this as a new capability field in struct v4l2_requestbuffers and struct > > > > v4l2_create_buffers. > > > > > > > > The first struct has 2 reserved fields, the second has 8, so it's not a > > > > problem to > > > > take one for a capability field. Both structs also have a buffer type, > > > > so we know > > > > if this is requested for a capture or output buffer type. The pixel > > > > format is known > > > > in the driver, so HAS/REQUIRES_REQUESTS can be set based on that. I > > > > doubt we'll have > > > > drivers where the request caps would actually depend on the pixel > > > > format, but it > > > > theoretically possible. For both ioctls you can call them with count=0 > > > > at the start > > > > of the application. REQBUFS has of course the side-effect of deleting > > > > all buffers, > > > > but at the start of your application you don't have any yet. > > > > CREATE_BUFS has no > > > > side-effects. > > > > > > My initial thoughts on this point were to have flags exposed in > > > v4l2_capability, but now that you're saying it, it does make sense for > > > the flag to be associated with a buffer rather than the global device. > > > > > > In addition, I've heard of cases (IIRC it was some Rockchip platforms) > > > where the platform has both stateless and stateful VPUs (I think it was > > > stateless up to H264 and stateful for H265). This would allow supporting > > > these two hardware blocks under the same video device (if that makes > > > sense anyway). And even if there's no immediate need, it's always good > > > to have this level of granularity (with little drawbacks). > > > > > > > I propose adding these capabilities: > > > > > > > > #define V4L2_BUF_CAP_HAS_REQUESTS 0x0001 > > > > #define V4L2_BUF_CAP_REQUIRES_REQUESTS 0x0002 > > > > #define V4L2_BUF_CAP_HAS_MMAP 0x0100 > > > > #define V4L2_BUF_CAP_HAS_USERPTR0x0200 > > > > #define V4L2_BUF_CAP_HAS_DMABUF 0x0400 > > > > > > > > If REQUIRES_REQUESTS is set, then HAS_REQUESTS is also set. > > > > > > > > At this time I think that REQUIRES_REQUESTS would only need to be set > > > > for the > > > > output queue of stateless codecs. > > > > > > > > If capabilities is 0, then it's from an old kernel and all you know is > > > > that > > > > requests are certainly not supported, and that MMAP is supported. > > > > Whether USERPTR > > > > or DMABUF are supported isn't known in that case (just try it
Re: [RFC] Request API and V4L2 capabilities
On Wed, 2018-08-22 at 16:10 +0200, Paul Kocialkowski wrote: > Hi, > > On Tue, 2018-08-21 at 17:52 +0900, Tomasz Figa wrote: > > Hi Hans, Paul, > > > > On Mon, Aug 6, 2018 at 6:29 PM Paul Kocialkowski > > wrote: > > > > > > On Mon, 2018-08-06 at 11:23 +0200, Hans Verkuil wrote: > > > > On 08/06/2018 11:13 AM, Paul Kocialkowski wrote: > > > > > Hi, > > > > > > > > > > On Mon, 2018-08-06 at 10:32 +0200, Hans Verkuil wrote: > > > > > > On 08/06/2018 10:16 AM, Paul Kocialkowski wrote: > > > > > > > On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote: > > > > > > > > Regarding point 3: I think this should be documented next to > > > > > > > > the pixel format. I.e. > > > > > > > > the MPEG-2 Slice format used by the stateless cedrus codec > > > > > > > > requires the request API > > > > > > > > and that two MPEG-2 controls (slice params and quantization > > > > > > > > matrices) must be present > > > > > > > > in each request. > > > > > > > > > > > > > > > > I am not sure a control flag (e.g. > > > > > > > > V4L2_CTRL_FLAG_REQUIRED_IN_REQ) is needed here. > > > > > > > > It's really implied by the fact that you use a stateless codec. > > > > > > > > It doesn't help > > > > > > > > generic applications like v4l2-ctl or qv4l2 either since in > > > > > > > > order to support > > > > > > > > stateless codecs they will have to know about the details of > > > > > > > > these controls anyway. > > > > > > > > > > > > > > > > So I am inclined to say that it is not necessary to expose this > > > > > > > > information in > > > > > > > > the API, but it has to be documented together with the pixel > > > > > > > > format documentation. > > > > > > > > > > > > > > I think this is affected by considerations about codec > > > > > > > profile/level > > > > > > > support. More specifically, some controls will only be required > > > > > > > for > > > > > > > supporting advanced codec profiles/levels, so they can only be > > > > > > > explicitly marked with appropriate flags by the driver when the > > > > > > > target > > > > > > > profile/level is known. And I don't think it would be sane for > > > > > > > userspace > > > > > > > to explicitly set what profile/level it's aiming at. As a result, > > > > > > > I > > > > > > > don't think we can explicitly mark controls as required or > > > > > > > optional. > > > > I'm not sure this is entirely true. The hardware may need to be > > explicitly told what profile the video is. It may even not be the > > hardware, but the driver itself too, given that the profile may imply > > the CAPTURE pixel format, e.g. for VP9 profiles: > > > > profile 0 > > color depth: 8 bit/sample, chroma subsampling: 4:2:0 > > profile 1 > > color depth: 8 bit, chroma subsampling: 4:2:0, 4:2:2, 4:4:4 > > profile 2 > > color depth: 10–12 bit, chroma subsampling: 4:2:0 > > profile 3 > > color depth: 10–12 bit, chroma subsampling: 4:2:0, 4:2:2, 4:4:4 > > > > (reference: https://en.wikipedia.org/wiki/VP9#Profiles) > > I think it would be fair to expect userspace to select the right > destination format (and maybe have the driver error if there's a > mismatch with the meta-data) instead of having the driver somewhat > expose what format should be used. > > But maybe this would be an API violation, since all the enumerated > formats are probably supposed to be selectable? > > We could also look at it the other way round and consider that selecting > an exposed format is always legit, but that it implies passing a > bitstream that matches it or the driver will error (because of an > invalid bitstream passed, not because of a "wrong" selected format). > The API requires the user to negotiate via TRY_FMT/S_FMT. The driver usually does not return error on invalid formats, and simply return a format it can work with. I think the kernel-user contract has to guarantee if the driver accepted a given format, it won't fail to encoder or decode. I think that's why it makes sense for stateless drivers to set the profile/levels for a given job, in order to properly negotiate the input and output formats (for both encoders and decoders). [1] https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-fmt.html
[PATCH v3 7/7] 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/media/platform/Kconfig| 13 + drivers/media/platform/Makefile | 1 + drivers/media/platform/rockchip/vpu/Makefile | 9 + .../platform/rockchip/vpu/rk3288_vpu_hw.c | 123 .../rockchip/vpu/rk3288_vpu_hw_jpege.c| 123 .../platform/rockchip/vpu/rk3288_vpu_regs.h | 442 + .../platform/rockchip/vpu/rk3399_vpu_hw.c | 124 .../rockchip/vpu/rk3399_vpu_hw_jpege.c| 151 + .../platform/rockchip/vpu/rk3399_vpu_regs.h | 601 + .../platform/rockchip/vpu/rockchip_vpu.h | 362 +++ .../rockchip/vpu/rockchip_vpu_common.h| 37 ++ .../platform/rockchip/vpu/rockchip_vpu_drv.c | 549 .../platform/rockchip/vpu/rockchip_vpu_enc.c | 607 ++ .../platform/rockchip/vpu/rockchip_vpu_hw.h | 65 ++ 15 files changed, 3214 insertions(+) create mode 100644 drivers/media/platform/rockchip/vpu/Makefile create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_hw_jpege.c create mode 100644 drivers/media/platform/rockchip/vpu/rk3288_vpu_regs.h create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_hw.c create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_hw_jpege.c create mode 100644 drivers/media/platform/rockchip/vpu/rk3399_vpu_regs.h create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu.h create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_common.h create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_drv.c create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_enc.c create mode 100644 drivers/media/platform/rockchip/vpu/rockchip_vpu_hw.h diff --git a/MAINTAINERS b/MAINTAINERS index da68e6da9981..e99b49c8dcf2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12272,6 +12272,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/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/media/platform/Kconfig b/drivers/media/platform/Kconfig index b25c8d3c1c31..87eb854cf7cb 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -448,6 +448,19 @@ config VIDEO_ROCKCHIP_RGA To compile this driver as a module choose m here. +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. + config VIDEO_TI_VPE tristate "TI VPE (Video Processing Engine) driver" depends on VIDEO_DEV && VIDEO_V4L2 diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index 08640ba87fc2..9b93f6a6b6e2 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/ obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/ +obj-$(CONFIG_VIDEO_ROCKCHIP_VPU)+= rockchip/vpu/ obj-y += omap/ diff --git a/drivers/media/platform/rockchip/vpu/Makefile b/drivers/media/platform/rockchip/vpu/Makefile new file mode 100644 index ..f717dfda1d42 --- /dev/null +++ b/drivers/media/platform/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_jpege.o \ + rk3399_vpu_hw.o \ + rk3399_vpu_hw_jpege.o diff --git a/drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c b/drivers/media/platform/rockchip/vpu/rk3288_vpu_hw.c new file mode 100644 index ..474e1ec758df --- /dev/null +++ b/drivers/media/platform/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. + * Jeffy Chen + */ + +#include + +#include "rockchip_vpu.h" +#include
[PATCH v3 4/7] v4l2-ctrls: Support dimensions override for standard controls
Pass the v4l2_ctrl_config->dims array to v4l2_ctrl_fill, so the
dimensions can be overridden for standard controls. This will
be used to fill V4L2_CID_JPEG_LUMA_QUANTIZATION and
V4L2_CID_JPEG_CHROMA_QUANTIZATION.
Signed-off-by: Ezequiel Garcia
---
drivers/media/v4l2-core/v4l2-common.c | 2 +-
drivers/media/v4l2-core/v4l2-ctrls.c | 17 ++---
include/media/v4l2-ctrls.h| 2 +-
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index b518b92d6d96..7b6353dab8a5 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -90,7 +90,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
_min, s32 _max, s32 _
s64 def = _def;
v4l2_ctrl_fill(qctrl->id, , >type,
- , , , , >flags);
+ , , , , NULL, >flags);
if (name == NULL)
return -EINVAL;
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 599c1cbff3b9..6ab15f4a0fea 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1068,7 +1068,7 @@ const char *v4l2_ctrl_get_name(u32 id)
EXPORT_SYMBOL(v4l2_ctrl_get_name);
void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
- s64 *min, s64 *max, u64 *step, s64 *def, u32 *flags)
+ s64 *min, s64 *max, u64 *step, s64 *def, u32 *dims, u32
*flags)
{
*name = v4l2_ctrl_get_name(id);
*flags = 0;
@@ -2244,10 +2244,13 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
s64 max = cfg->max;
u64 step = cfg->step;
s64 def = cfg->def;
+ u32 dims[V4L2_CTRL_MAX_DIMS];
+
+ memcpy(dims, cfg->dims, sizeof(dims));
if (name == NULL)
v4l2_ctrl_fill(cfg->id, , , , , ,
- , );
+ , dims, );
is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU ||
cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU);
@@ -2266,7 +2269,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
ctrl = v4l2_ctrl_new(hdl, cfg->ops, cfg->type_ops, cfg->id, name,
type, min, max,
is_menu ? cfg->menu_skip_mask : step, def,
- cfg->dims, cfg->elem_size,
+ dims, cfg->elem_size,
flags, qmenu, qmenu_int, priv);
if (ctrl)
ctrl->is_private = cfg->is_private;
@@ -2283,7 +2286,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_std(struct
v4l2_ctrl_handler *hdl,
enum v4l2_ctrl_type type;
u32 flags;
- v4l2_ctrl_fill(id, , , , , , , );
+ v4l2_ctrl_fill(id, , , , , , , NULL, );
if (type == V4L2_CTRL_TYPE_MENU ||
type == V4L2_CTRL_TYPE_INTEGER_MENU ||
type >= V4L2_CTRL_COMPOUND_TYPES) {
@@ -2312,7 +2315,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
v4l2_ctrl_handler *hdl,
u64 step;
u32 flags;
- v4l2_ctrl_fill(id, , , , , , , );
+ v4l2_ctrl_fill(id, , , , , , , NULL, );
if (type == V4L2_CTRL_TYPE_MENU)
qmenu = v4l2_ctrl_get_menu(id);
@@ -2350,7 +2353,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(struct
v4l2_ctrl_handler *hdl,
return NULL;
}
- v4l2_ctrl_fill(id, , , , , , , );
+ v4l2_ctrl_fill(id, , , , , , , NULL, );
if (type != V4L2_CTRL_TYPE_MENU || qmenu == NULL) {
handler_set_err(hdl, -EINVAL);
return NULL;
@@ -2375,7 +2378,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct
v4l2_ctrl_handler *hdl,
s64 def = _def;
u32 flags;
- v4l2_ctrl_fill(id, , , , , , , );
+ v4l2_ctrl_fill(id, , , , , , , NULL, );
if (type != V4L2_CTRL_TYPE_INTEGER_MENU) {
handler_set_err(hdl, -EINVAL);
return NULL;
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index f615ba1b29dd..55ab01d97c12 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -370,7 +370,7 @@ struct v4l2_ctrl_config {
*control framework this function will no longer be exported.
*/
void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
- s64 *min, s64 *max, u64 *step, s64 *def, u32 *flags);
+ s64 *min, s64 *max, u64 *step, s64 *def, u32 *dims, u32
*flags);
/**
--
2.18.0
[PATCH v3 5/7] 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 d382e7a5c38e..4dffe40097f2 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 5d1a3685bea9..f271048c89c4 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 v3 6/7] media: Add controls for JPEG quantization tables
From: Shunqian Zheng
Add V4L2_CID_JPEG_LUMA/CHROMA_QUANTIZATION controls to allow userspace
configure the JPEG quantization tables.
Signed-off-by: Shunqian Zheng
Signed-off-by: Ezequiel Garcia
---
Documentation/media/uapi/v4l/extended-controls.rst | 13 +
drivers/media/v4l2-core/v4l2-ctrls.c | 13 +
include/uapi/linux/v4l2-controls.h | 3 +++
3 files changed, 29 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
b/Documentation/media/uapi/v4l/extended-controls.rst
index 9f7312bf3365..1189750a022c 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -3354,6 +3354,19 @@ 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_LUMA_QUANTIZATION (__u8 matrix)``
+Sets the luma quantization table to be used for encoding
+or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. This table is
+a 8x8-byte matrix, and it's expected to be in JPEG zigzag order,
+as per the JPEG specification.
+
+``V4L2_CID_JPEG_CHROMA_QUANTIZATION (__u8 matrix)``
+Sets the chroma quantization table to be used for encoding
+or decoding a V4L2_PIX_FMT_JPEG_RAW format buffer. This table is
+a 8x8-byte matrix, and it's expected to be in JPEG zigzag order,
+as per the JPEG specification.
.. flat-table::
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 6ab15f4a0fea..677af8069bfc 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -999,6 +999,8 @@ 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_LUMA_QUANTIZATION: return "Luminance Quantization
Matrix";
+ case V4L2_CID_JPEG_CHROMA_QUANTIZATION: return "Chrominance
Quantization Matrix";
/* Image source controls */
/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1286,6 +1288,17 @@ 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_LUMA_QUANTIZATION:
+ case V4L2_CID_JPEG_CHROMA_QUANTIZATION:
+ *min = *def = 0;
+ *max = 0xff;
+ *step = 1;
+ *type = V4L2_CTRL_TYPE_U8;
+ if (dims) {
+ memset(dims, 0, V4L2_CTRL_MAX_DIMS * sizeof(dims[0]));
+ dims[0] = dims[1] = 8;
+ }
+ break;
case V4L2_CID_DETECT_MD_THRESHOLD_GRID:
*type = V4L2_CTRL_TYPE_U16;
break;
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index e4ee10ee917d..a466acf40625 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -987,6 +987,9 @@ enum v4l2_jpeg_chroma_subsampling {
#defineV4L2_JPEG_ACTIVE_MARKER_DQT (1 << 17)
#defineV4L2_JPEG_ACTIVE_MARKER_DHT (1 << 18)
+#define V4L2_CID_JPEG_LUMA_QUANTIZATION
(V4L2_CID_JPEG_CLASS_BASE + 5)
+#define V4L2_CID_JPEG_CHROMA_QUANTIZATION (V4L2_CID_JPEG_CLASS_BASE + 6)
+
/* Image source controls */
#define V4L2_CID_IMAGE_SOURCE_CLASS_BASE (V4L2_CTRL_CLASS_IMAGE_SOURCE |
0x900)
--
2.18.0
[PATCH v3 3/7] 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 6ba438427515..5dd840b3deb1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1231,6 +1231,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>;
@@ -1238,8 +1250,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 v3 2/7] 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 d7e49d29ace5..093f941ae273 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -1209,6 +1209,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>;
@@ -1216,8 +1228,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
[PATCH v3 1/7] 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.18.0
[PATCH v3 0/7] Add Rockchip VPU JPEG encoder
This series adds support for JPEG encoding via the VPU block
present in Rockchip platforms. Currently, support for RK3288
and RK3399 is included.
The hardware produces a Raw JPEG format (i.e. works as a
JPEG accelerator). It requires quantization tables provided
by the application, and uses standard huffman tables,
as recommended by the JPEG specification.
In order to support this, the series introduces a new pixel format,
and a new pair of controls, V4L2_CID_JPEG_{LUMA,CHROMA}_QUANTIZATION
allowing userspace to specify the quantization tables.
Userspace is then responsible to add the required headers
and tables to the produced raw payload, to produce a JPEG image.
Compliance
==
v4l2-compliance SHA: d0f4ea7ddab6d0244c4fe1e960bb2aaeefb911b9, 64 bits
Compliance test for device /dev/video0:
Driver Info:
Driver name : rockchip-vpu
Card type: rockchip,rk3399-vpu-enc
Bus info : platform: rockchip-vpu
Driver version : 4.18.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : rockchip-vpu
Model: rockchip-vpu
Serial :
Bus info :
Media version: 4.18.0
Hardware revision: 0x (0)
Driver version : 4.18.0
Interface Info:
ID : 0x030c
Type : V4L Video
Entity Info:
ID : 0x0001 (1)
Name : rockchip,rk3399-vpu-enc-source
Function : V4L2 I/O
Pad 0x0102 : Source
Link 0x0208: to remote pad 0x105 of entity
'rockchip,rk3399-vpu-enc-proc': Data, Enabled, Immutable
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second /dev/video0 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 2 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test 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
test MMAP: OK
test USERPTR: OK (Not Supported)
test DMABUF: Cannot test, specify --expbuf-device
Total: 48, Succeeded: 48, Failed: 0, Warnings: 0
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
Team for mobile apps
Do you have needs for mobile apps design? We are the one who can help you. We are an India based software company. What we focus is mobile apps development. We have 125 staffs in office and have created over 350 apps so far. We work on many different platforms, such as iOS, Android and others. Please reply if interested, we will send you our portfolios. Thanks, Ray Charles
Re: [RFC] Request API and V4L2 capabilities
Hi, On Wed, 2018-08-15 at 09:57 -0400, Nicolas Dufresne wrote: > Le lundi 06 août 2018 à 10:16 +0200, Paul Kocialkowski a écrit : > > Hi Hans and all, > > > > On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote: > > > Hi all, > > > > > > While the Request API patch series addresses all the core API issues, > > > there > > > are some high-level considerations as well: > > > > > > 1) How can the application tell that the Request API is supported and for > > >which buffer types (capture/output) and pixel formats? > > > > > > 2) How can the application tell if the Request API is required as opposed > > > to being > > >optional? > > > > > > 3) Some controls may be required in each request, how to let userspace > > > know this? > > >Is it even necessary to inform userspace? > > > > > > 4) (For bonus points): How to let the application know which streaming > > > I/O modes > > >are available? That's never been possible before, but it would be very > > > nice > > >indeed if that's made explicit. > > > > Thanks for bringing up these considerations and questions, which perhaps > > cover the last missing bits for streamlined use of the request API by > > userspace. I would suggest another item, related to 3): > > > > 5) How can applications tell whether the driver supports a specific > > codec profile/level, not only for encoding but also for decoding? It's > > common for low-end embedded hardware to not support the most advanced > > profiles (e.g. H264 high profile). > > Hi Paul, after some discussion with Philip, he sent a proposal patch > that enables profile/level extended CID support to decoders too. The > control is made read-only, the point is not really the CID get/set but > that the controls allow enumerating the supported values. This seems > quite straightforward and easy to use. > > This enumeration is already provided this way some of the existing > sate-full encoders. Sounds great, thanks for looking into it! I looked for the patch in the list, but couldn't find it off-hand. Do you have a link to it? I would like to bind it to the Cedrus VPU driver eventually. Cheers, Paul > > > Since the Request API associates data with frame buffers it makes sense > > > to expose > > > this as a new capability field in struct v4l2_requestbuffers and struct > > > v4l2_create_buffers. > > > > > > The first struct has 2 reserved fields, the second has 8, so it's not a > > > problem to > > > take one for a capability field. Both structs also have a buffer type, so > > > we know > > > if this is requested for a capture or output buffer type. The pixel > > > format is known > > > in the driver, so HAS/REQUIRES_REQUESTS can be set based on that. I doubt > > > we'll have > > > drivers where the request caps would actually depend on the pixel format, > > > but it > > > theoretically possible. For both ioctls you can call them with count=0 at > > > the start > > > of the application. REQBUFS has of course the side-effect of deleting all > > > buffers, > > > but at the start of your application you don't have any yet. CREATE_BUFS > > > has no > > > side-effects. > > > > My initial thoughts on this point were to have flags exposed in > > v4l2_capability, but now that you're saying it, it does make sense for > > the flag to be associated with a buffer rather than the global device. > > > > In addition, I've heard of cases (IIRC it was some Rockchip platforms) > > where the platform has both stateless and stateful VPUs (I think it was > > stateless up to H264 and stateful for H265). This would allow supporting > > these two hardware blocks under the same video device (if that makes > > sense anyway). And even if there's no immediate need, it's always good > > to have this level of granularity (with little drawbacks). > > > > > I propose adding these capabilities: > > > > > > #define V4L2_BUF_CAP_HAS_REQUESTS 0x0001 > > > #define V4L2_BUF_CAP_REQUIRES_REQUESTS0x0002 > > > #define V4L2_BUF_CAP_HAS_MMAP 0x0100 > > > #define V4L2_BUF_CAP_HAS_USERPTR 0x0200 > > > #define V4L2_BUF_CAP_HAS_DMABUF 0x0400 > > > > > > If REQUIRES_REQUESTS is set, then HAS_REQUESTS is also set. > > > > > > At this time I think that REQUIRES_REQUESTS would only need to be set for > > > the > > > output queue of stateless codecs. > > > > > > If capabilities is 0, then it's from an old kernel and all you know is > > > that > > > requests are certainly not supported, and that MMAP is supported. Whether > > > USERPTR > > > or DMABUF are supported isn't known in that case (just try it :-) ). > > > > Sounds good to me! > > > > > Strictly speaking we do not need these HAS_MMAP/USERPTR/DMABUF caps, but > > > it is very > > > easy to add if we create a new capability field anyway, and it has always > > > annoyed > > > the hell out of me that we didn't have a good way to let userspace know > > > what > > > streaming I/O modes we support. And with vb2 it's
Apps Design
Do you have needs for mobile apps design? We are the one who can help you. We are an India based software company. What we focus is mobile apps development. We have 125 staffs in office and have created over 350 apps so far. We work on many different platforms, such as iOS, Android and others. Please reply if interested, we will send you our portfolios. Thanks, Ray Charles
Apps Design
Do you have needs for mobile apps design? We are the one who can help you. We are an India based software company. What we focus is mobile apps development. We have 125 staffs in office and have created over 350 apps so far. We work on many different platforms, such as iOS, Android and others. Please reply if interested, we will send you our portfolios. Thanks, Ray Charles
Re: [RFC] Request API and V4L2 capabilities
Hi, On Tue, 2018-08-21 at 17:52 +0900, Tomasz Figa wrote: > Hi Hans, Paul, > > On Mon, Aug 6, 2018 at 6:29 PM Paul Kocialkowski > wrote: > > > > On Mon, 2018-08-06 at 11:23 +0200, Hans Verkuil wrote: > > > On 08/06/2018 11:13 AM, Paul Kocialkowski wrote: > > > > Hi, > > > > > > > > On Mon, 2018-08-06 at 10:32 +0200, Hans Verkuil wrote: > > > > > On 08/06/2018 10:16 AM, Paul Kocialkowski wrote: > > > > > > On Sat, 2018-08-04 at 15:50 +0200, Hans Verkuil wrote: > > > > > > > Regarding point 3: I think this should be documented next to the > > > > > > > pixel format. I.e. > > > > > > > the MPEG-2 Slice format used by the stateless cedrus codec > > > > > > > requires the request API > > > > > > > and that two MPEG-2 controls (slice params and quantization > > > > > > > matrices) must be present > > > > > > > in each request. > > > > > > > > > > > > > > I am not sure a control flag (e.g. > > > > > > > V4L2_CTRL_FLAG_REQUIRED_IN_REQ) is needed here. > > > > > > > It's really implied by the fact that you use a stateless codec. > > > > > > > It doesn't help > > > > > > > generic applications like v4l2-ctl or qv4l2 either since in order > > > > > > > to support > > > > > > > stateless codecs they will have to know about the details of > > > > > > > these controls anyway. > > > > > > > > > > > > > > So I am inclined to say that it is not necessary to expose this > > > > > > > information in > > > > > > > the API, but it has to be documented together with the pixel > > > > > > > format documentation. > > > > > > > > > > > > I think this is affected by considerations about codec profile/level > > > > > > support. More specifically, some controls will only be required for > > > > > > supporting advanced codec profiles/levels, so they can only be > > > > > > explicitly marked with appropriate flags by the driver when the > > > > > > target > > > > > > profile/level is known. And I don't think it would be sane for > > > > > > userspace > > > > > > to explicitly set what profile/level it's aiming at. As a result, I > > > > > > don't think we can explicitly mark controls as required or optional. > > I'm not sure this is entirely true. The hardware may need to be > explicitly told what profile the video is. It may even not be the > hardware, but the driver itself too, given that the profile may imply > the CAPTURE pixel format, e.g. for VP9 profiles: > > profile 0 > color depth: 8 bit/sample, chroma subsampling: 4:2:0 > profile 1 > color depth: 8 bit, chroma subsampling: 4:2:0, 4:2:2, 4:4:4 > profile 2 > color depth: 10–12 bit, chroma subsampling: 4:2:0 > profile 3 > color depth: 10–12 bit, chroma subsampling: 4:2:0, 4:2:2, 4:4:4 > > (reference: https://en.wikipedia.org/wiki/VP9#Profiles) I think it would be fair to expect userspace to select the right destination format (and maybe have the driver error if there's a mismatch with the meta-data) instead of having the driver somewhat expose what format should be used. But maybe this would be an API violation, since all the enumerated formats are probably supposed to be selectable? We could also look at it the other way round and consider that selecting an exposed format is always legit, but that it implies passing a bitstream that matches it or the driver will error (because of an invalid bitstream passed, not because of a "wrong" selected format). As far as I understood, the profile/level information is there to indicate a set of supported features by the decoder, not as an information used for the decoding process. Each corresponding feature is enabled or not in the bitstream meta-data and that's all the information the decoder really needs. This is why I think that setting the profile/level explicitly is not justified by the nature of the process and adding it only for convenience or marking whether controls are optional doesn't seem justified at this point, in my opinion. > > > > > > I also like the idea that it should instead be implicit and that the > > > > > > documentation should detail which specific stateless metadata > > > > > > controls > > > > > > are required for a given profile/level. > > > > > > > > > > > > As for controls validation, the approach followed in the Cedrus > > > > > > driver > > > > > > is to check that the most basic controls are filled and allow having > > > > > > missing controls for those that match advanced profiles. > > > > > > > > > > > > Since this approach feels somewhat generic enough to be applied to > > > > > > all > > > > > > stateless VPU drivers, maybe this should be made a helper in the > > > > > > framework? > > > > > > > > > > Sounds reasonable. Not sure if it will be in the first version, but > > > > > it is > > > > > easy to add later. > > > > > > > > Definitely, I don't think this is such a high priority for now either. > > > > > > We may want to put strict requirements on what controls are provided > for given codec+profile/level. Otherwise we might get some user space > that doesn't
Re: [RFC] Request API and V4L2 capabilities
On Wed, Aug 22, 2018 at 10:21 PM Paul Kocialkowski wrote: > > Hi, > > [...] > > On Wed, 2018-08-15 at 14:51 +0200, Maxime Jourdan wrote: > > Hi Paul, I think we need to go deeper than just exposing the supported > > profiles/levels and also include a way to query the CAPTURE pixel > > formats that are supported for each profile. > > > > Maybe HEVC Main produces yuv420p but HEVC Main10 gives you > > yuv420p10le. Maybe H.264 HiP produces NV12 but H.264 Hi422P produces > > YUYV while also supporting down-sampling to NV12. > > Well, I think we're looking at this backwards. Userspace certainly known > what destination format is relevant for the video, so it shouldn't have > to query the driver about it except to check that the format is indeed > supported. Typically the profile itself only defines the sub-sampling and sample size, but not the exact set of formats supported by the hardware. VP9 profile 0 is expected to decode into YUV 4:2:0 8-bit, but whether that would be NV12, YUV420, NV21 or maybe some hw-specific tiled format (like NV12MT), is entirely up to the hardware/driver. Userspace will definitely need to know if the decoder can decode the video into a format, which it can later use (display). > > > I don't know the specifics of each platform and the only example I can > > think of is the Amlogic HEVC decoder that can produce NV12 for Main, > > but only outputs a compressed proprietary format for Main10. > > > > I unfortunately don't have an idea about how to implement that, but > > I'll think about it. > > On the first generations of Allwinner platforms, we also have a vendor- > specific format as output, that we expose with a dedicated format. > There's no particular interfacing issue with that. Only that userspace > has to be aware of the format and how to deal with it. > Typically a decode operates as a part of a pipeline with other components. If your display doesn't let you display format X on an overlay plane, you may want to use a post-processor hardware to convert it to format Y. Or maybe use GPU to blit the video into the primary plane? Or maybe you need to do both, because format X is a decoder-specific tiled format and the GPU can't deal with it and all the overlay planes are occupied with some other surfaces? Or maybe it's just cheaper to do software decode rather than the conversion+GPU blit? This is something that normally needs to be queried before the video playback is initialized. Best regards, Tomasz
Re: [RFC] Request API and V4L2 capabilities
Hi, [...] On Wed, 2018-08-15 at 14:51 +0200, Maxime Jourdan wrote: > Hi Paul, I think we need to go deeper than just exposing the supported > profiles/levels and also include a way to query the CAPTURE pixel > formats that are supported for each profile. > > Maybe HEVC Main produces yuv420p but HEVC Main10 gives you > yuv420p10le. Maybe H.264 HiP produces NV12 but H.264 Hi422P produces > YUYV while also supporting down-sampling to NV12. Well, I think we're looking at this backwards. Userspace certainly known what destination format is relevant for the video, so it shouldn't have to query the driver about it except to check that the format is indeed supported. > I don't know the specifics of each platform and the only example I can > think of is the Amlogic HEVC decoder that can produce NV12 for Main, > but only outputs a compressed proprietary format for Main10. > > I unfortunately don't have an idea about how to implement that, but > I'll think about it. On the first generations of Allwinner platforms, we also have a vendor- specific format as output, that we expose with a dedicated format. There's no particular interfacing issue with that. Only that userspace has to be aware of the format and how to deal with it. Cheers, Paul > > Cheers, > > > > Paul > > > > -- > > Paul Kocialkowski, Bootlin (formerly Free Electrons) > > Embedded Linux and kernel engineering > > https://bootlin.com -- Paul Kocialkowski, Bootlin (formerly Free Electrons) Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: This is a digitally signed message part
Re: [PATCH 4/4] venus: firmware: register separate platform_device for firmware loader
Hi Vikash,
Could you give a try below patch on your environment? You should keep
your 1/4 to 3/4 patches and replace your 4/4 with the below one.
You have to drop the compatible string in firmware DT subnode (keep only
iommus).
On 08/22/2018 03:34 PM, Stanimir Varbanov wrote:
> This registers a firmware platform_device and associate it with
> video-firmware DT subnode. Then calls dma configure to initialize
> dma and iommu.
>
> Signed-off-by: Stanimir Varbanov
> ---
> .../devicetree/bindings/media/qcom,venus.txt | 13 +-
> drivers/media/platform/qcom/venus/core.c | 14 +--
> drivers/media/platform/qcom/venus/firmware.c | 49
> ++
> drivers/media/platform/qcom/venus/firmware.h | 2 +
> 4 files changed, 73 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt
> b/Documentation/devicetree/bindings/media/qcom,venus.txt
> index 00d0d1bf7647..7e045862c3fe 100644
> --- a/Documentation/devicetree/bindings/media/qcom,venus.txt
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -53,7 +53,7 @@
>
> * Subnodes
> The Venus video-codec node must contain two subnodes representing
> -video-decoder and video-encoder.
> +video-decoder and video-encoder, and one optional firmware subnode.
>
> Every of video-encoder or video-decoder subnode should have:
>
> @@ -79,6 +79,13 @@ Every of video-encoder or video-decoder subnode should
> have:
> power domain which is responsible for collapsing
> and restoring power to the subcore.
>
> +The firmware subnode must have:
> +
> +- iommus:
> + Usage: required
> + Value type:
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> * An Example
> video-codec@1d0 {
> compatible = "qcom,msm8916-venus";
> @@ -105,4 +112,8 @@ Every of video-encoder or video-decoder subnode should
> have:
> clock-names = "core";
> power-domains = < VENUS_CORE1_GDSC>;
> };
> +
> + video-firmware {
> + iommus = <_iommu 0x10b2 0x0>;
> + };
> };
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index 393994ecab26..3bd3b8ab1f82 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -284,6 +284,14 @@ static int venus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err_runtime_disable;
>
> + ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
> + if (ret)
> + goto err_runtime_disable;
> +
> + ret = venus_firmware_init(core);
> + if (ret)
> + goto err_runtime_disable;
> +
> ret = venus_boot(core);
> if (ret)
> goto err_runtime_disable;
> @@ -308,10 +316,6 @@ static int venus_probe(struct platform_device *pdev)
> if (ret)
> goto err_core_deinit;
>
> - ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
> - if (ret)
> - goto err_dev_unregister;
> -
> ret = pm_runtime_put_sync(dev);
> if (ret)
> goto err_dev_unregister;
> @@ -347,6 +351,8 @@ static int venus_remove(struct platform_device *pdev)
> venus_shutdown(core);
> of_platform_depopulate(dev);
>
> + venus_firmware_deinit(core);
> +
> pm_runtime_put_sync(dev);
> pm_runtime_disable(dev);
>
> diff --git a/drivers/media/platform/qcom/venus/firmware.c
> b/drivers/media/platform/qcom/venus/firmware.c
> index 80c3d1362c04..2a9fcbb71216 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -228,3 +229,51 @@ int venus_shutdown(struct venus_core *core)
>
> return ret;
> }
> +
> +int venus_firmware_init(struct venus_core *core)
> +{
> + struct platform_device_info info;
> + struct platform_device *pdev;
> + struct device_node *np;
> + int ret;
> +
> + np = of_get_child_by_name(core->dev->of_node, "video-firmware");
> + if (!np)
> + return 0;
> +
> + memset(, 0, sizeof(info));
> + info.fwnode = >fwnode;
> + info.parent = core->dev;
> + info.name = np->name;
> + info.dma_mask = DMA_BIT_MASK(32);
> +
> + pdev = platform_device_register_full();
> + if (IS_ERR(pdev)) {
> + of_node_put(np);
> + return PTR_ERR(pdev);
> + }
> +
> + pdev->dev.of_node = np;
> +
> + ret = of_dma_configure(>dev, np);
> + if (ret)
> + dev_err(core->dev, "dma configure fail\n");
> +
> + of_node_put(np);
> +
> + if (ret)
> + return ret;
> +
> + core->no_tz = true;
> + core->fw.dev = >dev;
> +
> + return 0;
> +}
> +
> +void
[PATCH 4/4] venus: firmware: register separate platform_device for firmware loader
This registers a firmware platform_device and associate it with
video-firmware DT subnode. Then calls dma configure to initialize
dma and iommu.
Signed-off-by: Stanimir Varbanov
---
.../devicetree/bindings/media/qcom,venus.txt | 13 +-
drivers/media/platform/qcom/venus/core.c | 14 +--
drivers/media/platform/qcom/venus/firmware.c | 49 ++
drivers/media/platform/qcom/venus/firmware.h | 2 +
4 files changed, 73 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt
b/Documentation/devicetree/bindings/media/qcom,venus.txt
index 00d0d1bf7647..7e045862c3fe 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus.txt
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -53,7 +53,7 @@
* Subnodes
The Venus video-codec node must contain two subnodes representing
-video-decoder and video-encoder.
+video-decoder and video-encoder, and one optional firmware subnode.
Every of video-encoder or video-decoder subnode should have:
@@ -79,6 +79,13 @@ Every of video-encoder or video-decoder subnode should have:
power domain which is responsible for collapsing
and restoring power to the subcore.
+The firmware subnode must have:
+
+- iommus:
+ Usage: required
+ Value type:
+ Definition: A list of phandle and IOMMU specifier pairs.
+
* An Example
video-codec@1d0 {
compatible = "qcom,msm8916-venus";
@@ -105,4 +112,8 @@ Every of video-encoder or video-decoder subnode should have:
clock-names = "core";
power-domains = < VENUS_CORE1_GDSC>;
};
+
+ video-firmware {
+ iommus = <_iommu 0x10b2 0x0>;
+ };
};
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 393994ecab26..3bd3b8ab1f82 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -284,6 +284,14 @@ static int venus_probe(struct platform_device *pdev)
if (ret < 0)
goto err_runtime_disable;
+ ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+ if (ret)
+ goto err_runtime_disable;
+
+ ret = venus_firmware_init(core);
+ if (ret)
+ goto err_runtime_disable;
+
ret = venus_boot(core);
if (ret)
goto err_runtime_disable;
@@ -308,10 +316,6 @@ static int venus_probe(struct platform_device *pdev)
if (ret)
goto err_core_deinit;
- ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
- if (ret)
- goto err_dev_unregister;
-
ret = pm_runtime_put_sync(dev);
if (ret)
goto err_dev_unregister;
@@ -347,6 +351,8 @@ static int venus_remove(struct platform_device *pdev)
venus_shutdown(core);
of_platform_depopulate(dev);
+ venus_firmware_deinit(core);
+
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 80c3d1362c04..2a9fcbb71216 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -228,3 +229,51 @@ int venus_shutdown(struct venus_core *core)
return ret;
}
+
+int venus_firmware_init(struct venus_core *core)
+{
+ struct platform_device_info info;
+ struct platform_device *pdev;
+ struct device_node *np;
+ int ret;
+
+ np = of_get_child_by_name(core->dev->of_node, "video-firmware");
+ if (!np)
+ return 0;
+
+ memset(, 0, sizeof(info));
+ info.fwnode = >fwnode;
+ info.parent = core->dev;
+ info.name = np->name;
+ info.dma_mask = DMA_BIT_MASK(32);
+
+ pdev = platform_device_register_full();
+ if (IS_ERR(pdev)) {
+ of_node_put(np);
+ return PTR_ERR(pdev);
+ }
+
+ pdev->dev.of_node = np;
+
+ ret = of_dma_configure(>dev, np);
+ if (ret)
+ dev_err(core->dev, "dma configure fail\n");
+
+ of_node_put(np);
+
+ if (ret)
+ return ret;
+
+ core->no_tz = true;
+ core->fw.dev = >dev;
+
+ return 0;
+}
+
+void venus_firmware_deinit(struct venus_core *core)
+{
+ if (!core->fw.dev)
+ return;
+
+ platform_device_unregister(to_platform_device(core->fw.dev));
+}
diff --git a/drivers/media/platform/qcom/venus/firmware.h
b/drivers/media/platform/qcom/venus/firmware.h
index f41b615b96f1..119a9a4fc1a2 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -16,6 +16,8 @@
struct device;
+int
V4L2 analogue gain contol
Hi, I've been looking at various image sensor drivers to see how they expose gains, in particular analogue ones. What I found in 4.18 looks like a mess to me. In particular, my interest is about separation of analogue vs digital gain and an understanding of what effect a change in gain has on the brightness of an image. The latter is characterized in the following table in the "linear" column. driver | CID | register name | min | max | def | linear | comments +-+-+-+--+-++- adv7343 | G | ADV7343_DAC2_OUTPUT_LEVEL | -64 | 64 | 0 || adv7393 | G | ADV7393_DAC123_OUTPUT_LEVEL | -64 | 64 | 0 || imx258 | A | IMX258_REG_ANALOG_GAIN | 0 | 8191 | 0 || imx274 | G | multiple| | | | yes| [1] mt9m032 | G | MT9M032_GAIN_ALL| 0 | 127 | 64 | no | [2] mt9m111 | G | GLOBAL_GAIN | 0 | 252 | 32 | no | [3] mt9p031 | G | MT9P031_GLOBAL_GAIN | 8 | 1024 | 8 | no | [4] mt9v011 | G | multiple| 0 | 4063 | 32 || mt9v032 | G | MT9V032_ANALOG_GAIN | 16 | 64 | 16 | no | [5] ov13858 | A | OV13858_REG_ANALOG_GAIN | 0 | 8191 | 128 || ov2685 | A | OV2685_REG_GAIN | 0 | 2047 | 54 || ov5640 | G | OV5640_REG_AEC_PK_REAL_GAIN | 0 | 1023 | 0 || ov5670 | A | OV5670_REG_ANALOG_GAIN | 0 | 8191 | 128 || ov5695 | A | OV5695_REG_ANALOG_GAIN | 16 | 248 | 248 || mt9m001 | G | MT9M001_GLOBAL_GAIN | 0 | 127 | 64 | no | mt9v022 | G | MT9V022_ANALOG_GAIN | 0 | 127 | 64 || CID: A -> V4L2_CID_ANALOGUE_GAIN G -> V4L2_CID_GAIN, no V4L2_CID_ANALOGUE_GAIN present step: always 1 comments: [1] controls a product of analogue and digital gain, value scales roughly linear [2] code comments contradict data sheet [3] it is not clear whether it also controls a digital gain. [4] controls a combination of analogue and digital gain [5] analogue only The documentation (extended-controls.rst) says that the digital gain is supposed to be a linear fixed-point number with 0x100 meaning factor 1. The situation for analogue is much less precise. Typically, the number of analogue gains is much smaller than the number of digital gains. No driver exposes more than 13 bit for the analogue gain and half of them use at most 8 bits. Can we give more structure to the analogue gain as exposed by V4L2? Ideally, I'd like to query a driver for the possible gain values if there are few (say < 256) and their factors (which are often given in data sheets). The nature of gains though is that they are often similar to floating point numbers (2 ** exp * (1 + mant / precision)), which makes it difficult to represent them using min/max/step/default. Would it be reasonable to add a new V4L2_CID_ANALOGUE_GAIN_MENU that claims linearity and uses fixed-point numbers like V4L2_CID_DIGITAL_GAIN? There already is the integer menu V4L2_CID_AUTO_EXPOSURE_BIAS, but it also affects the exposure. An important application is implementing a custom gain control when the built-in auto exposure is not applicable. Helmut
We design apps
Do you have needs for mobile apps design? We are the one who can help you. We are an India based software company. What we focus is mobile apps development. We have 125 staffs in office and have created over 350 apps so far. We work on many different platforms, such as iOS, Android and others. Please reply if interested, we will send you our portfolios. Thanks, Ray Charles
Waiting for the photos
Do you have needs to change or cut out background for you photos? Do you have needs to retouch or enhance your photos? We are an image team of 10 editors, who can help you for those photo work needs. Please contact us for further info. Thanks, Lucy Karlson
Re: [PATCH v1 2/2] v4l: Document Intel IPU3 meta data uAPI
Hi Mauro, On Mon, Aug 13, 2018 at 05:50:00PM -0300, Mauro Carvalho Chehab wrote: ... > > > + > > > +/*** ipu3_uapi_stats_3a ***/ > > > + > > > +#define IPU3_UAPI_MAX_STRIPES2 > > > +#define IPU3_UAPI_MAX_BUBBLE_SIZE10 > > > + > > > +#define IPU3_UAPI_GRID_START_MASK(BIT(12) - 1) > > > +#define IPU3_UAPI_GRID_Y_START_ENBIT(15) > > > + > > > +/* controls generation of meta_data (like FF enable/disable) */ > > > +#define IPU3_UAPI_AWB_RGBS_THR_B_EN BIT(14) > > > +#define IPU3_UAPI_AWB_RGBS_THR_B_INCL_SATBIT(15) > > > + > > > +/** > > > + * struct ipu3_uapi_grid_config - Grid plane config > > > + * > > > + * @width: Grid horizontal dimensions, in number of grid > > > blocks(cells). > > > + * @height: Grid vertical dimensions, in number of grid cells. > > > + * @block_width_log2:Log2 of the width of each cell in pixels. > > > + * for (2^3, 2^4, 2^5, 2^6, 2^7), values [3, 7]. > > What are you meaning by [3, 7] here? From some comment you had later, > I guess you're meaning that only 3 or 7 are the valid values. This is a notation for a closed interval. Please see: https://en.wikipedia.org/wiki/Interval_(mathematics)> > > Yet, you're listing from 2^3 to 2^7, and that's confusing. Perhaps > you want to say, instead, that the valid values are at the 3..7 range? > If so, please use something like "values at the [3..7] range". I'd prefer either 3..7 or [3, 7], but the latter is formal. Whether a range is closed or (partially) open matters less with integers though. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [RFP] Media Summit: Complex cameras
Hi Mauro, On Thu, Aug 16, 2018 at 10:58 PM Mauro Carvalho Chehab wrote: > > I expect that we could have something to discuss there about complex > cameras. So, I'd reserve a 50 mins slot for it. > > The idea is to discuss about the undergoing work with complex camera > development is happening. > > As we're working to merge request API, another topic for discussion is > how to add support for requests on it (or on a separate but related > library). I need to recheck, but I might not be able to attend in person. Do you think it would be possible to join remotely, by using Hangouts (or anything else)? Best regards, Tomasz
RE: [PATCH] media: i2c: max2175: convert to SPDX identifiers
Hi Morimoto-san, Thank you for the patch. > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Acked-by: Ramesh Shanmugasundaram Thanks, Ramesh > --- > drivers/media/i2c/max2175.c | 10 +- > drivers/media/i2c/max2175.h | 12 ++-- > 2 files changed, 3 insertions(+), 19 deletions(-) > > diff --git a/drivers/media/i2c/max2175.c b/drivers/media/i2c/max2175.c > index 008a082..85a3fdf 100644 > --- a/drivers/media/i2c/max2175.c > +++ b/drivers/media/i2c/max2175.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * Maxim Integrated MAX2175 RF to Bits tuner driver > * > @@ -6,15 +7,6 @@ > * > * Copyright (C) 2016 Maxim Integrated Products > * Copyright (C) 2017 Renesas Electronics Corporation > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 > - * as published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > > #include > diff --git a/drivers/media/i2c/max2175.h b/drivers/media/i2c/max2175.h > index eb43373..1ece587 100644 > --- a/drivers/media/i2c/max2175.h > +++ b/drivers/media/i2c/max2175.h > @@ -1,4 +1,5 @@ > -/* > +/* SPDX-License-Identifier: GPL-2.0 > + * > * Maxim Integrated MAX2175 RF to Bits tuner driver > * > * This driver & most of the hard coded values are based on the reference > @@ -6,15 +7,6 @@ > * > * Copyright (C) 2016 Maxim Integrated Products > * Copyright (C) 2017 Renesas Electronics Corporation > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 > - * as published by the Free Software Foundation. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > */ > > #ifndef __MAX2175_H__ > -- > 2.7.4
Re: Question regarding optimizing pipeline in Vimc
On 08/22/2018 05:35 AM, Helen Koike wrote: > Hello, > > One of the discussions we had when developing Vimc, was regarding > optimizing image generation. > The ideia was to generate the images directly in the capture instead > of propagating through the pipeline (to make things faster). > But my question is: if this optimization is on, and if there is a > greyscaler filter in the middle of the pipeline, do you expect to see > a grey image with this optimization? Yes. > Or if we just generate a dummy > image (with the right size format) at the end of the pipeline, would > it be ok? (I am asking because it doesn't sound that simple to > propagate the image transformation made by each entity in the pipe) No, that would not be OK. My basic idea was that you use a TPG state structure that contains the desired output: the sensor starts with e.g. 720p using some bayer pixelformat, the debayer module replaces the pixelformat with e.g. PIX_FMT_RGB32, a grayscale filter replaces it with PI_FMT_GREY, and that's what the TPG for the video device eventually will use to generate the video. This assumes of course that all the vimc blocks only do operations that can be handled by the TPG. Depending on what the blocks will do the TPG might need to be extended if a feature is missing. Regards, Hans > Or do you have any other thing in mind? > > Thanks > Helen >
I NEED A TRUSTWORTHY PARTNER.
-- Dear Friend, Greetings! I am confidence you are good with your family. Please may I request your urgent assistance in transferring the sum of ($10.7M) to your account? It is 100% risk free and you will receive 35% of the total sum for your kind assistance. On confirmation of your interest I will send more details. With Regards, Mr. Simon Kafando
