cron job: media_tree daily build: ERRORS
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: Sat Nov 3 05:00:13 CET 2018 media-tree git hash:dafb7f9aef2fd44991ff1691721ff765a23be27b media_build git hash: 0c8bb27f3aaa682b9548b656f77505c3d1f11e71 v4l-utils git hash: c36dbbdfa8b30b2badd4f893b59d0bd4f0bd12aa edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: WARNINGS linux-git-arm-stm32: WARNINGS linux-git-arm64: OK linux-git-i686: WARNINGS linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-sh: OK linux-git-x86_64: WARNINGS Check COMPILE_TEST: OK linux-3.10.108-i686: ERRORS linux-3.10.108-x86_64: ERRORS linux-3.11.10-i686: ERRORS linux-3.11.10-x86_64: ERRORS linux-3.12.74-i686: ERRORS linux-3.12.74-x86_64: ERRORS linux-3.13.11-i686: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.79-i686: ERRORS linux-3.14.79-x86_64: ERRORS linux-3.15.10-i686: ERRORS linux-3.15.10-x86_64: ERRORS linux-3.16.57-i686: ERRORS linux-3.16.57-x86_64: ERRORS linux-3.17.8-i686: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.123-i686: ERRORS linux-3.18.123-x86_64: ERRORS linux-3.19.8-i686: ERRORS linux-3.19.8-x86_64: ERRORS linux-4.0.9-i686: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.52-i686: ERRORS linux-4.1.52-x86_64: ERRORS linux-4.2.8-i686: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-i686: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.159-i686: ERRORS linux-4.4.159-x86_64: ERRORS linux-4.5.7-i686: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-i686: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.10-i686: ERRORS linux-4.7.10-x86_64: ERRORS linux-4.8.17-i686: ERRORS linux-4.8.17-x86_64: ERRORS linux-4.9.131-i686: ERRORS linux-4.9.131-x86_64: ERRORS linux-4.10.17-i686: ERRORS linux-4.10.17-x86_64: ERRORS linux-4.11.12-i686: ERRORS linux-4.11.12-x86_64: ERRORS linux-4.12.14-i686: ERRORS linux-4.12.14-x86_64: ERRORS linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-i686: OK linux-4.19-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Logs weren't copied as they are too large (1732 kB) The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH] Input: Add missing event codes for common IR remote buttons
The following patch adds event codes for common buttons found on various provider and universal remote controls. They represent functions not covered by existing event codes. Once added, rc_keymaps can be updated accordingly where applicable. Signed-off-by: Derek Kelly --- include/uapi/linux/input-event-codes.h | 13 + 1 file changed, 13 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 53fbae27b280..c68d022163e5 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -689,6 +689,19 @@ #define BTN_TRIGGER_HAPPY390x2e6 #define BTN_TRIGGER_HAPPY400x2e7 +/* Remote control buttons found across provider & universal remotes */ +#define KEY_LIVE_TV0x2e8 /* Jump to live tv viewing */ +#define KEY_OPTIONS0x2e9 /* Jump to options */ +#define KEY_INTERACTIVE0x2ea /* Jump to interactive system/menu/item */ +#define KEY_MIC_INPUT 0x2eb /* Trigger MIC input/listen mode */ +#define KEY_SCREEN_INPUT 0x2ec /* Open on-screen input system */ +#define KEY_SYSTEM 0x2ed /* Open systems menu/display */ +#define KEY_SERVICES 0x2ee /* Open services menu/display */ +#define KEY_DISPLAY_FORMAT 0x2ef /* Cycle display formats */ +#define KEY_PIP0x2f0 /* Toggle Picture-in-Picture on/off */ +#define KEY_PIP_SWAP 0x2f1 /* Swap contents between main view and PIP window */ +#define KEY_PIP_POSITION 0x2f2 /* Cycle PIP window position */ + /* We avoid low common keys in module aliases so they don't get huge. */ #define KEY_MIN_INTERESTINGKEY_MUTE #define KEY_MAX0x2ff -- 2.19.1
diffs in mn88473 & cxd2841er config structures
Hi all I am trying to add in support for the cxd2841er on the rtl28x usb devices. With mn88473 and others, the config structure has 'struct dvb_frontend **fe', but it's not in the cxd2841er config. Are there any plans to add it in? Should I change it and wherever else it is required, or should it be left in its current format? B
Re: [RFC v2 1/4] media: Introduce helpers to fill pixel format structs
Le vendredi 02 novembre 2018 à 12:52 -0300, Ezequiel Garcia a écrit :
> 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)
My first impression is that this code expects width/height to be
aligned to the sub-sampling. Hence, I don't think it works for odd
width/height. It would be nice to document the constraint, specially
that this will lead to under-allocation due to the lack of round up.
> +{
> + 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,
Re: VIVID/VIMC and media fuzzing
On Wed, Oct 31, 2018 at 12:01 PM, Sean Young wrote: > On Wed, Oct 31, 2018 at 11:05:10AM +0100, Hans Verkuil wrote: >> CC-ing Sean Young: please see question at the end. >> >> On 10/31/2018 10:46 AM, Hans Verkuil wrote: >> > On 10/30/2018 03:02 PM, Dmitry Vyukov wrote: >> >> Hello Helen and linux-media, >> >> >> >> I've attended your talk "Shifting Media App Development into High >> >> Gear" on OSS Summit last week and approached you with some questions >> >> if/how this can be used for kernel testing. Thanks, turn out to be a >> >> very useful talk! >> >> >> >> I am working on syzkaller/syzbot, continuous kernel fuzzing system: >> >> https://github.com/google/syzkaller >> >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md >> >> https://syzkaller.appspot.com >> >> >> >> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M, >> >> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in >> >> media subsystem in just 24 hours: >> >> >> >> KASAN: use-after-free Read in vb2_mmap >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ >> >> >> >> KASAN: use-after-free Write in __vb2_cleanup_fileio >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ >> >> >> >> WARNING in __vb2_queue_cancel >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ >> >> >> >> divide error in vivid_vid_cap_s_dv_timings >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ >> > >> > Should be fixed by https://patchwork.linuxtv.org/patch/52641/ >> > >> >> >> >> KASAN: use-after-free Read in wake_up_if_idle >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ >> >> >> >> KASAN: use-after-free Read in __vb2_perform_fileio >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ >> >> >> >> INFO: task hung in vivid_stop_generating_vid_cap >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ >> >> >> >> KASAN: null-ptr-deref Write in kthread_stop >> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ >> > >> > These last two should be fixed by >> > https://patchwork.linuxtv.org/patch/52640/ >> > >> > Haven't figured out the others yet (hope to get back to that next week). >> > >> >> >> >> Based on this I think if we put more effort into media fuzzing, it >> >> will be able to find dozens more. >> > >> > Yeah, this is good stuff. Thank you for setting this up. >> > >> >> >> >> syzkaller needs descriptions of kernel interfaces to efficiently cover >> >> a subsystem. For example, see: >> >> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt >> >> Hopefully you can read it without much explanation, it basically >> >> states that there is that node in /dev and here are ioctls and other >> >> syscalls that are relevant for this device and here are types of >> >> arguments and layout of involved data structures. >> >> >> >> Turned we actually have such descriptions for /dev/video* and >> >> /dev/v4l-subdev*: >> >> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt >> >> But we don't have anything for /dev/media*, fuzzer merely knows that >> >> it can open the device: >> >> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479 >> >> and then it will just blindly execute completely random workload on >> >> it, e.g. most likely it won't be able to come up with a proper complex >> >> structure layout for some ioctls. And I am actually not completely >> >> sure about completeness and coverage of video4linux.txt descriptions >> >> too as they were contributed by somebody interested in android >> >> testing. >> > >> > A quick look suggests that it is based on the 4.9 videodev2.h, which ain't >> > too bad. There are some differences between the 4.20 videodev2.h and the >> > 4.9, but not too many. >> > >> >> >> >> I wonder if somebody knowledgeable in /dev/media interface be willing >> >> to contribute additional descriptions? >> > >> > We'll have to wait for 4.20-rc1 to be released since there are important >> > additions to the media API. I can probably come up with something, I'm >> > just not sure when I get around to it. Ping me in three weeks time if you >> > haven't heard from me. >> >> While adding support for the media API I should also add support for the CEC >> API, since vivid can emulate a CEC device as well. >> >> It would be really neat to have similar support for DVB and RC as well, but >> we >> don't have virtual drivers for those. Although CEC can expose an RC input >> device >> if enabled by the kernel config. > > I've been looking at this (adding DVB and RC) as we discussed. I like this > idea, as it also helps me with getting started with DVB. > >> Sean, would that be a good starting point for fuzzing the RC API? Or do you >> think >> we really need proper RC emulation in
Re: VIVID/VIMC and media fuzzing
On Wed, Oct 31, 2018 at 10:46 AM, Hans Verkuil wrote: > On 10/30/2018 03:02 PM, Dmitry Vyukov wrote: >> Hello Helen and linux-media, >> >> I've attended your talk "Shifting Media App Development into High >> Gear" on OSS Summit last week and approached you with some questions >> if/how this can be used for kernel testing. Thanks, turn out to be a >> very useful talk! >> >> I am working on syzkaller/syzbot, continuous kernel fuzzing system: >> https://github.com/google/syzkaller >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md >> https://syzkaller.appspot.com >> >> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M, >> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in >> media subsystem in just 24 hours: >> >> KASAN: use-after-free Read in vb2_mmap >> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ >> >> KASAN: use-after-free Write in __vb2_cleanup_fileio >> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ >> >> WARNING in __vb2_queue_cancel >> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ >> >> divide error in vivid_vid_cap_s_dv_timings >> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ > > Should be fixed by https://patchwork.linuxtv.org/patch/52641/ > >> >> KASAN: use-after-free Read in wake_up_if_idle >> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ >> >> KASAN: use-after-free Read in __vb2_perform_fileio >> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ >> >> INFO: task hung in vivid_stop_generating_vid_cap >> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ >> >> KASAN: null-ptr-deref Write in kthread_stop >> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ > > These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/ This is great! This last one happens super frequently, so harms ability to find other bugs. > Haven't figured out the others yet (hope to get back to that next week). But note that syzbot added few more too! :) And there will be more, when I run syzkaller locally aimed only at these devices I got: general protection fault in vma_interval_tree_subtree_search WARNING in dev_watchdog BUG: unable to handle kernel paging request in tpg_print_str_6 kernel BUG at arch/x86/mm/physaddr.c:LINE! BUG: unable to handle kernel NULL pointer dereference in qlist_free_all INFO: rcu detected stall in corrupted general protection fault in debug_check_no_obj_freed KASAN: use-after-free Write in __vb2_cleanup_fileio INFO: task hung in vivid_stop_generating_vid_cap general protection fault in __bfs divide error in vivid_thread_vid_out KASAN: null-ptr-deref Write in kthread_stop lost connection to test machine general protection fault in __neigh_notify BUG: unable to handle kernel paging request in tpg_print_str_2 BUG: unable to handle kernel NULL pointer dereference in corrupted INFO: trying to register non-static key in corrupted divide error in vivid_vid_cap_s_dv_timings KASAN: null-ptr-deref Read in refcount_sub_and_test_checked KASAN: use-after-free Read in v4l2_ctrl_grab INFO: rcu detected stall in v4l2_ioctl kernel panic: stack-protector: Kernel stack is corrupted in: do_vfs_ioctl INFO: rcu detected stall in e1000_watchdog BUG: unable to handle kernel paging request in corrupted KASAN: use-after-free Read in vb2_mmap BUG: unable to handle kernel paging request in tpg_print_str_4 BUG: unable to handle kernel paging request in tpg_print_str_8 kernel BUG at mm/vmalloc.c:LINE! kernel panic: corrupted stack end detected inside scheduler KASAN: stack-out-of-bounds Read in __schedule WARNING in __vb2_queue_cancel general protection fault in corrupted KASAN: use-after-free Read in __vb2_perform_fileio BUG: unable to handle kernel NULL pointer dereference in kthread_stop general protection fault in fib_sync_down_dev BUG: pagefault on kernel address ADDR in non-whitelisted uaccess general protection fault in __vb2_queue_free INFO: rcu detected stall in do_signal INFO: task hung in corrupted kernel BUG at include/linux/mm.h:LINE! no output from test machine BUG: workqueue lockup KASAN: null-ptr-deref in kthread_stop INFO: rcu detected stall in tcp_keepalive_timer >> Based on this I think if we put more effort into media fuzzing, it >> will be able to find dozens more. > > Yeah, this is good stuff. Thank you for setting this up. > >> >> syzkaller needs descriptions of kernel interfaces to efficiently cover >> a subsystem. For example, see: >> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt >> Hopefully you can read it without much explanation, it basically >> states that there is that node in /dev and here are ioctls and other >> syscalls that are relevant for this device and here are types of >> arguments and layout of involved data structures. >> >> Turned we actually have such
Re: [RFC PATCH 10/11] v4l2-ioctl: remove unused vidioc_g/s_crop
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > Now that all drivers have dropped vidioc_g/s_crop we can remove > support for them in the V4L2 core. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
[PATCH] media: ov5640: Add RAW bayer format support
OV5640 sensor supports raw image output (bayer).
Configure ISP mux/format registers accordingly.
Signed-off-by: Loic Poulain
---
drivers/media/i2c/ov5640.c | 58 --
1 file changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 071f4bc..e38e05e 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -116,6 +116,15 @@ enum ov5640_frame_rate {
OV5640_NUM_FRAMERATES,
};
+enum ov5640_format_mux {
+ OV5640_FMT_MUX_YUV422 = 0,
+ OV5640_FMT_MUX_RGB,
+ OV5640_FMT_MUX_DITHER,
+ OV5640_FMT_MUX_RAW_DPC,
+ OV5640_FMT_MUX_SNR_RAW,
+ OV5640_FMT_MUX_RAW_CIP,
+};
+
struct ov5640_pixfmt {
u32 code;
u32 colorspace;
@@ -127,6 +136,10 @@ static const struct ov5640_pixfmt ov5640_formats[] = {
{ MEDIA_BUS_FMT_YUYV8_2X8, V4L2_COLORSPACE_SRGB, },
{ MEDIA_BUS_FMT_RGB565_2X8_LE, V4L2_COLORSPACE_SRGB, },
{ MEDIA_BUS_FMT_RGB565_2X8_BE, V4L2_COLORSPACE_SRGB, },
+ { MEDIA_BUS_FMT_SBGGR8_1X8, V4L2_COLORSPACE_SRGB, },
+ { MEDIA_BUS_FMT_SGBRG8_1X8, V4L2_COLORSPACE_SRGB, },
+ { MEDIA_BUS_FMT_SGRBG8_1X8, V4L2_COLORSPACE_SRGB, },
+ { MEDIA_BUS_FMT_SRGGB8_1X8, V4L2_COLORSPACE_SRGB, },
};
/*
@@ -1980,46 +1993,67 @@ static int ov5640_set_framefmt(struct ov5640_dev
*sensor,
struct v4l2_mbus_framefmt *format)
{
int ret = 0;
- bool is_rgb = false;
bool is_jpeg = false;
- u8 val;
+ u8 fmt, mux;
switch (format->code) {
case MEDIA_BUS_FMT_UYVY8_2X8:
/* YUV422, UYVY */
- val = 0x3f;
+ fmt = 0x3f;
+ mux = OV5640_FMT_MUX_YUV422;
break;
case MEDIA_BUS_FMT_YUYV8_2X8:
/* YUV422, YUYV */
- val = 0x30;
+ fmt = 0x30;
+ mux = OV5640_FMT_MUX_YUV422;
break;
case MEDIA_BUS_FMT_RGB565_2X8_LE:
/* RGB565 {g[2:0],b[4:0]},{r[4:0],g[5:3]} */
- val = 0x6F;
- is_rgb = true;
+ fmt = 0x6F;
+ mux = OV5640_FMT_MUX_RGB;
break;
case MEDIA_BUS_FMT_RGB565_2X8_BE:
/* RGB565 {r[4:0],g[5:3]},{g[2:0],b[4:0]} */
- val = 0x61;
- is_rgb = true;
+ fmt = 0x61;
+ mux = OV5640_FMT_MUX_RGB;
break;
case MEDIA_BUS_FMT_JPEG_1X8:
/* YUV422, YUYV */
- val = 0x30;
+ fmt = 0x30;
+ mux = OV5640_FMT_MUX_YUV422;
is_jpeg = true;
break;
+ case MEDIA_BUS_FMT_SBGGR8_1X8:
+ /* Raw, BGBG... / GRGR... */
+ fmt = 0x00;
+ mux = OV5640_FMT_MUX_RAW_DPC;
+ break;
+ case MEDIA_BUS_FMT_SGBRG8_1X8:
+ /* Raw bayer, GBGB... / RGRG... */
+ fmt = 0x01;
+ mux = OV5640_FMT_MUX_RAW_DPC;
+ break;
+ case MEDIA_BUS_FMT_SGRBG8_1X8:
+ /* Raw bayer, GRGR... / BGBG... */
+ fmt = 0x02;
+ mux = OV5640_FMT_MUX_RAW_DPC;
+ break;
+ case MEDIA_BUS_FMT_SRGGB8_1X8:
+ /* Raw bayer, RGRG... / GBGB... */
+ fmt = 0x03;
+ mux = OV5640_FMT_MUX_RAW_DPC;
+ break;
default:
return -EINVAL;
}
/* FORMAT CONTROL00: YUV and RGB formatting */
- ret = ov5640_write_reg(sensor, OV5640_REG_FORMAT_CONTROL00, val);
+ ret = ov5640_write_reg(sensor, OV5640_REG_FORMAT_CONTROL00, fmt);
if (ret)
return ret;
/* FORMAT MUX CONTROL: ISP YUV or RGB */
- ret = ov5640_write_reg(sensor, OV5640_REG_ISP_FORMAT_MUX_CTRL,
- is_rgb ? 0x01 : 0x00);
+ ret = ov5640_write_reg(sensor, OV5640_REG_ISP_FORMAT_MUX_CTRL, mux);
if (ret)
return ret;
--
2.7.4
Re: [RFC PATCH 08/11] exynos4-is: convert g/s_crop to g/s_selection
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > Replace g/s_crop by g/s_selection and set the V4L2_FL_QUIRK_INVERTED_CROP > flag since this is one of the old drivers that predates the selection > API. Those old drivers allowed g_crop when it really shouldn't have since > g_crop returns a compose rectangle instead of a crop rectangle for the > CAPTURE stream, and vice versa for the OUTPUT stream. > > Also drop the now unused vidioc_cropcap. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
Re: [RFC PATCH 09/11] s5p-g2d: convert g/s_crop to g/s_selection
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > Replace g/s_crop by g/s_selection and set the V4L2_FL_QUIRK_INVERTED_CROP > flag since this is one of the old drivers that predates the selection > API. Those old drivers allowed g_crop when it really shouldn't have since > g_crop returns a compose rectangle instead of a crop rectangle for the > CAPTURE stream, and vice versa for the OUTPUT stream. > > Also drop the now unused vidioc_cropcap. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
Re: [RFC PATCH 07/11] s5p_mfc_dec.c: convert g_crop to g_selection
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > The g_crop really implemented composition for the CAPTURE stream. > > Replace g_crop by g_selection and set the V4L2_FL_QUIRK_INVERTED_CROP > flag since this is one of the old drivers that predates the selection > API. Those old drivers allowed g_crop when it really shouldn't have > since g_crop returns a compose rectangle instead of a crop rectangle. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
Re: [RFC PATCH 06/11] exynos-gsc: replace v4l2_crop by v4l2_selection
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > Replace the use of struct v4l2_crop by struct v4l2_selection. > Also drop the unused gsc_g_crop function. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
Re: [RFC PATCH 03/11] v4l2-ioctl: add QUIRK_INVERTED_CROP
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > Some old Samsung drivers use the legacy crop API incorrectly: > the crop and compose targets are swapped. Normally VIDIOC_G_CROP > will return the CROP rectangle of a CAPTURE stream and the COMPOSE > rectangle of an OUTPUT stream. > > The Samsung drivers do the opposite. Note that these drivers predate > the selection API. > > If this 'QUIRK' flag is set, then the v4l2-ioctl core will swap > the CROP and COMPOSE targets as well. > > That way backwards compatibility is ensured and we can convert the > Samsung drivers to the selection API. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
Re: [RFC PATCH 01/11] v4l2-ioctl: don't use CROP/COMPOSE_ACTIVE
On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > Drop the deprecated _ACTIVE part. > > Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki
Re: [RFC PATCH 00/11] Convert last remaining g/s_crop/cropcap drivers
Hi Hans, On Fri, 5 Oct 2018 at 09:49, Hans Verkuil wrote: > > From: Hans Verkuil > > This patch series converts the last remaining drivers that use g/s_crop and > cropcap to g/s_selection. Thank you for this clean up! I remember attempting conversion of those remaining drivers to selection API long time ago but I didn't have a good idea then how to address that crop and compose target inversion mess so I abandoned that efforts then. -- Regards, Sylwester
[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;
- pix->height = q_data->height;
+
[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 distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about
[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_event eos_event = {
- .type = V4L2_EVENT_EOS
- };
-
- spin_lock(ctx->lock);
- ctx->last_src_buf =
Re: [PATCH v7 03/16] v4l: Add Intel IPU3 meta data uAPI
Hi Mauro,
On Fri, Nov 2, 2018 at 10:49 PM Mauro Carvalho Chehab
wrote:
>
> Em Mon, 29 Oct 2018 15:22:57 -0700
> Yong Zhi escreveu:
[snip]
> > +struct ipu3_uapi_awb_config_s {
> > + __u16 rgbs_thr_gr;
> > + __u16 rgbs_thr_r;
> > + __u16 rgbs_thr_gb;
> > + __u16 rgbs_thr_b;
> > + struct ipu3_uapi_grid_config grid;
> > +} __attribute__((aligned(32))) __packed;
>
> Hmm... Kernel defines a macro for aligned attribute:
>
> include/linux/compiler_types.h:#define __aligned(x)
> __attribute__((aligned(x)))
>
First, thanks for review!
Maybe I missed something, but last time I checked, it wasn't
accessible from UAPI headers in userspace.
> I'm not a gcc expert, but it sounds weird to first ask it to align
> with 32 bits and then have __packed (with means that pads should be
> removed).
>
> In other words, I *guess* is it should either be __packed
> or __aligned(32).
>
> Not that it would do any difference, in practice, as this
> specific struct has a size with is multiple of 32 bits, but
> let's do the right annotation here, not mixing two incompatible
> alignment requirements.
>
My understanding was that __packed makes the compiler not insert any
alignment between particular fields of the struct, while __aligned
makes the whole struct be aligned at given boundary, if placed in
another struct. If I didn't miss anything, having both should make
perfect sense here.
Best regards,
Tomasz
Re: [PATCH v7 03/16] v4l: Add Intel IPU3 meta data uAPI
Em Mon, 29 Oct 2018 15:22:57 -0700
Yong Zhi escreveu:
> These meta formats are used on Intel IPU3 ImgU video queues
> to carry 3A statistics and ISP pipeline parameters.
Just minor things. See below.
>
> V4L2_META_FMT_IPU3_3A
> V4L2_META_FMT_IPU3_PARAMS
>
> Signed-off-by: Yong Zhi
> Signed-off-by: Chao C Li
> Signed-off-by: Rajmohan Mani
> ---
> Documentation/media/uapi/v4l/meta-formats.rst |1 +
> .../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst | 181 ++
I would actually prefer to have those two changes merged together with
patch 1, as it makes easier for review.
> include/uapi/linux/intel-ipu3.h| 2819
>
This one makes sense to have a separate patch.
> 3 files changed, 3001 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> create mode 100644 include/uapi/linux/intel-ipu3.h
>
> diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> b/Documentation/media/uapi/v4l/meta-formats.rst
> index cf971d5..eafc534 100644
> --- a/Documentation/media/uapi/v4l/meta-formats.rst
> +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> @@ -12,6 +12,7 @@ These formats are used for the :ref:`metadata` interface
> only.
> .. toctree::
> :maxdepth: 1
>
> +pixfmt-meta-intel-ipu3
> pixfmt-meta-d4xx
> pixfmt-meta-uvc
> pixfmt-meta-vsp1-hgo
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> new file mode 100644
> index 000..23b945b
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> @@ -0,0 +1,181 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _intel-ipu3:
> +
> +**
> +V4L2_META_FMT_IPU3_PARAMS ('ip3p'), V4L2_META_FMT_IPU3_3A ('ip3s')
> +**
> +
> +.. c:type:: ipu3_uapi_stats_3a
> +
> +3A statistics
> +=
> +
> +For IPU3 ImgU, the 3A statistics accelerators collect different statistics
> over
> +an input bayer frame. Those statistics, defined in data struct
> +:c:type:`ipu3_uapi_stats_3a`, are meta output obtained from "ipu3-imgu 3a
> stat"
> +video node, which are then passed to user space for statistics analysis
> +using :c:type:`v4l2_meta_format` interface.
> +
> +The statistics collected are AWB (Auto-white balance) RGBS (Red, Green, Blue
> and
> +Saturation measure) cells, AWB filter response, AF (Auto-focus) filter
> response,
> +and AE (Auto-exposure) histogram.
> +
> +struct :c:type:`ipu3_uapi_4a_config` saves configurable parameters for all
> above.
> +
> +
> +.. code-block:: c
> +
> +
> + struct ipu3_uapi_stats_3a {
> + struct ipu3_uapi_awb_raw_buffer awb_raw_buffer
> + __attribute__((aligned(32)));
> + struct ipu3_uapi_ae_raw_buffer_aligned
> + ae_raw_buffer[IPU3_UAPI_MAX_STRIPES];
> + struct ipu3_uapi_af_raw_buffer af_raw_buffer;
> + struct ipu3_uapi_awb_fr_raw_buffer awb_fr_raw_buffer;
> + struct ipu3_uapi_4a_config stats_4a_config;
> + __u32 ae_join_buffers;
> + __u8 padding[28];
> + struct ipu3_uapi_stats_3a_bubble_info_per_stripe
> + stats_3a_bubble_per_stripe;
> + struct ipu3_uapi_ff_status stats_3a_status;
> + } __packed;
> +
> +
> +.. c:type:: ipu3_uapi_params
> +
> +Pipeline parameters
> +===
> +
> +IPU3 pipeline has a number of image processing stages, each of which takes a
> +set of parameters as input. The major stages of pipelines are shown here:
> +
> +Raw pixels -> Bayer Downscaling -> Optical Black Correction ->
> +
> +Linearization -> Lens Shading Correction -> White Balance / Exposure /
> +
> +Focus Apply -> Bayer Noise Reduction -> ANR -> Demosaicing -> Color
> +
> +Correction Matrix -> Gamma correction -> Color Space Conversion ->
> +
> +Chroma Down Scaling -> Chromatic Noise Reduction -> Total Color
> +
> +Correction -> XNR3 -> TNR -> DDR
> +
> +The table below presents a description of the above algorithms.
> +
> +
> ===
> +Name Description
> +
> ===
> +Optical Black Correction Optical Black Correction block subtracts a
> pre-defined
> + value from the respective pixel values to obtain better
> + image quality.
> + Defined in :c:type:`ipu3_uapi_obgrid_param`.
> +Linearization This algo block uses linearization parameters
> to
> + address non-linearity sensor effects. The Lookup table
> + table is defined in
> + :c:type:`ipu3_uapi_isp_lin_vmem_params`.
> +SHD Lens shading correction is used to correct spatial
> + non-uniformity of
Re: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats
Em Fri, 2 Nov 2018 09:59:31 -0300
Mauro Carvalho Chehab escreveu:
> Hi Zhi-san,
>
> Em Mon, 29 Oct 2018 15:22:55 -0700
> Yong Zhi escreveu:
>
> > Add IPU3-specific meta formats for parameter
> > processing and 3A, DVS statistics:
> >
> > V4L2_META_FMT_IPU3_PARAMS
> > V4L2_META_FMT_IPU3_STAT_3A
> >
> > Signed-off-by: Yong Zhi
> > ---
> > drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> > include/uapi/linux/videodev2.h | 4
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 6489f25..abff64b 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -1299,6 +1299,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> > case V4L2_META_FMT_VSP1_HGO:descr = "R-Car VSP1 1-D Histogram";
> > break;
> > case V4L2_META_FMT_VSP1_HGT:descr = "R-Car VSP1 2-D Histogram";
> > break;
> > case V4L2_META_FMT_UVC: descr = "UVC payload header metadata";
> > break;
> > + case V4L2_META_FMT_IPU3_PARAMS: descr = "IPU3 processing parameters";
> > break;
> > + case V4L2_META_FMT_IPU3_STAT_3A:descr = "IPU3 3A statistics";
> > break;
> >
> > default:
> > /* Compressed formats */
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index f0a968a..bdccd7a 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -718,6 +718,10 @@ struct v4l2_pix_format {
> > #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC
> > Payload Header metadata */
> > #define V4L2_META_FMT_D4XXv4l2_fourcc('D', '4', 'X', 'X') /* D4XX
> > Payload Header metadata */
> >
> > +/* Vendor specific - used for IPU3 camera sub-system */
> > +#define V4L2_META_FMT_IPU3_PARAMS v4l2_fourcc('i', 'p', '3', 'p') /* IPU3
> > params */
> > +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3
> > 3A statistics */
>
> Where's the documentation for those two new formats? The best is to
> always add the documentation bits for V4L2 uAPI stuff at the same
> patch, as it makes easier for us to review.
Found it. It is at patch 3.
>
> > +
> > /* priv field value to indicates that subsequent fields are valid. */
> > #define V4L2_PIX_FMT_PRIV_MAGIC0xfeedcafe
> >
>
>
>
> Thanks,
> Mauro
Thanks,
Mauro
Re: [PATCH v7 03/16] v4l: Add Intel IPU3 meta data uAPI
Hi Yong,
Thanks for the update! I went through this again... a few comments below
but I'd say they're mostly pretty minor issues.
On Mon, Oct 29, 2018 at 03:22:57PM -0700, Yong Zhi wrote:
> These meta formats are used on Intel IPU3 ImgU video queues
> to carry 3A statistics and ISP pipeline parameters.
>
> V4L2_META_FMT_IPU3_3A
> V4L2_META_FMT_IPU3_PARAMS
>
> Signed-off-by: Yong Zhi
> Signed-off-by: Chao C Li
> Signed-off-by: Rajmohan Mani
> ---
> Documentation/media/uapi/v4l/meta-formats.rst |1 +
> .../media/uapi/v4l/pixfmt-meta-intel-ipu3.rst | 181 ++
> include/uapi/linux/intel-ipu3.h| 2819
>
> 3 files changed, 3001 insertions(+)
> create mode 100644 Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> create mode 100644 include/uapi/linux/intel-ipu3.h
>
> diff --git a/Documentation/media/uapi/v4l/meta-formats.rst
> b/Documentation/media/uapi/v4l/meta-formats.rst
> index cf971d5..eafc534 100644
> --- a/Documentation/media/uapi/v4l/meta-formats.rst
> +++ b/Documentation/media/uapi/v4l/meta-formats.rst
> @@ -12,6 +12,7 @@ These formats are used for the :ref:`metadata` interface
> only.
> .. toctree::
> :maxdepth: 1
>
> +pixfmt-meta-intel-ipu3
> pixfmt-meta-d4xx
> pixfmt-meta-uvc
> pixfmt-meta-vsp1-hgo
> diff --git a/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> new file mode 100644
> index 000..23b945b
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-meta-intel-ipu3.rst
> @@ -0,0 +1,181 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _intel-ipu3:
Instead, to avoid a warning from Sphinx, replace the line with these:
.. _v4l2-meta-fmt-ipu3-params:
.. _v4l2-meta-fmt-ipu3-stat-3a:
> +
> +**
> +V4L2_META_FMT_IPU3_PARAMS ('ip3p'), V4L2_META_FMT_IPU3_3A ('ip3s')
> +**
> +
> +.. c:type:: ipu3_uapi_stats_3a
> +
> +3A statistics
> +=
> +
> +For IPU3 ImgU, the 3A statistics accelerators collect different statistics
> over
> +an input bayer frame. Those statistics, defined in data struct
> +:c:type:`ipu3_uapi_stats_3a`, are meta output obtained from "ipu3-imgu 3a
> stat"
> +video node, which are then passed to user space for statistics analysis
> +using :c:type:`v4l2_meta_format` interface.
> +
> +The statistics collected are AWB (Auto-white balance) RGBS (Red, Green, Blue
> and
Extra whitespace at the end of the line.
> +Saturation measure) cells, AWB filter response, AF (Auto-focus) filter
> response,
> +and AE (Auto-exposure) histogram.
> +
> +struct :c:type:`ipu3_uapi_4a_config` saves configurable parameters for all
> above.
> +
> +
> +.. code-block:: c
> +
> +
> + struct ipu3_uapi_stats_3a {
> + struct ipu3_uapi_awb_raw_buffer awb_raw_buffer
> + __attribute__((aligned(32)));
> + struct ipu3_uapi_ae_raw_buffer_aligned
> + ae_raw_buffer[IPU3_UAPI_MAX_STRIPES];
> + struct ipu3_uapi_af_raw_buffer af_raw_buffer;
> + struct ipu3_uapi_awb_fr_raw_buffer awb_fr_raw_buffer;
> + struct ipu3_uapi_4a_config stats_4a_config;
> + __u32 ae_join_buffers;
> + __u8 padding[28];
> + struct ipu3_uapi_stats_3a_bubble_info_per_stripe
> + stats_3a_bubble_per_stripe;
I think you could just unwrap these, even if it causes them to be over 80
characters per line. They display better in a web browser that way. Or
alternatively align the wrapped lines to the same column.
> + struct ipu3_uapi_ff_status stats_3a_status;
> + } __packed;
> +
> +
> +.. c:type:: ipu3_uapi_params
> +
> +Pipeline parameters
> +===
> +
> +IPU3 pipeline has a number of image processing stages, each of which takes a
> +set of parameters as input. The major stages of pipelines are shown here:
> +
> +Raw pixels -> Bayer Downscaling -> Optical Black Correction ->
> +
> +Linearization -> Lens Shading Correction -> White Balance / Exposure /
> +
> +Focus Apply -> Bayer Noise Reduction -> ANR -> Demosaicing -> Color
> +
> +Correction Matrix -> Gamma correction -> Color Space Conversion ->
> +
> +Chroma Down Scaling -> Chromatic Noise Reduction -> Total Color
> +
> +Correction -> XNR3 -> TNR -> DDR
> +
> +The table below presents a description of the above algorithms.
> +
> +
> ===
> +Name Description
> +
> ===
> +Optical Black Correction Optical Black Correction block subtracts a
> pre-defined
> + value from the respective pixel values to obtain better
> + image quality.
> + Defined in :c:type:`ipu3_uapi_obgrid_param`.
> +Linearization This algo block uses linearization
Re: [PATCH v7 01/16] v4l: Add Intel IPU3 meta buffer formats
Hi Zhi-san,
Em Mon, 29 Oct 2018 15:22:55 -0700
Yong Zhi escreveu:
> Add IPU3-specific meta formats for parameter
> processing and 3A, DVS statistics:
>
> V4L2_META_FMT_IPU3_PARAMS
> V4L2_META_FMT_IPU3_STAT_3A
>
> Signed-off-by: Yong Zhi
> ---
> drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
> include/uapi/linux/videodev2.h | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 6489f25..abff64b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -1299,6 +1299,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
> case V4L2_META_FMT_VSP1_HGO:descr = "R-Car VSP1 1-D Histogram";
> break;
> case V4L2_META_FMT_VSP1_HGT:descr = "R-Car VSP1 2-D Histogram";
> break;
> case V4L2_META_FMT_UVC: descr = "UVC payload header metadata";
> break;
> + case V4L2_META_FMT_IPU3_PARAMS: descr = "IPU3 processing parameters";
> break;
> + case V4L2_META_FMT_IPU3_STAT_3A:descr = "IPU3 3A statistics";
> break;
>
> default:
> /* Compressed formats */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index f0a968a..bdccd7a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -718,6 +718,10 @@ struct v4l2_pix_format {
> #define V4L2_META_FMT_UVC v4l2_fourcc('U', 'V', 'C', 'H') /* UVC
> Payload Header metadata */
> #define V4L2_META_FMT_D4XXv4l2_fourcc('D', '4', 'X', 'X') /* D4XX
> Payload Header metadata */
>
> +/* Vendor specific - used for IPU3 camera sub-system */
> +#define V4L2_META_FMT_IPU3_PARAMSv4l2_fourcc('i', 'p', '3', 'p') /* IPU3
> params */
> +#define V4L2_META_FMT_IPU3_STAT_3A v4l2_fourcc('i', 'p', '3', 's') /* IPU3
> 3A statistics */
Where's the documentation for those two new formats? The best is to
always add the documentation bits for V4L2 uAPI stuff at the same
patch, as it makes easier for us to review.
> +
> /* priv field value to indicates that subsequent fields are valid. */
> #define V4L2_PIX_FMT_PRIV_MAGIC 0xfeedcafe
>
Thanks,
Mauro
[PATCH] v4l2-controls: add a missing include
As warned by "make headers_check", the definition for the linux-specific
integer types is missing:
./usr/include/linux/v4l2-controls.h:1105: found __[us]{8,16,32,64} type
without #include
Fixes: c27bb30e7b6d ("media: v4l: Add definitions for MPEG-2 slice format and
metadata")
Reported-by: Linus Torvalds
Reported-by: Stephen Rothwell
Signed-off-by: Mauro Carvalho Chehab
---
include/uapi/linux/v4l2-controls.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 51b095898f4b..86a54916206f 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -47,6 +47,8 @@
* videodev2.h.
*/
+#include
+
#ifndef __LINUX_V4L2_CONTROLS_H
#define __LINUX_V4L2_CONTROLS_H
--
2.19.1
Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi Jean-Michel,
On Fri, Nov 02, 2018 at 09:09:42AM +0100, Jean-Michel Hautbois wrote:
> Hi Steve,
>
> Le mer. 31 oct. 2018 à 22:52, Steve Longerbeam a
> écrit :
> >
> > Hi Jean-Michel,
> >
> > We've done some work with another FPD-Link de-serializer (ds90ux940) and
> > IIRC we had some trouble figuring out how to coax the lanes into LP-11
> > state. But on the ds90ux940 it can be done by setting bit 7 in the CSI
> > Enable Port registers (offsets 0x13 and 0x14). But the "imx6-mipi-csi2:
> > clock lane timeout" message is something else and indicates the
> > de-serializer is not activating the clock lane during its s_stream(ON)
> > subdev call.
>
> I have been doing more work on the driver I have, and I had CSI
> enabled before the csi2_dphy_wait_stopstate() call for instance. Now,
> LP-11 state is ok.
> Then, in the s_stream subcall, I added a delay after enabling CSI (and
> the continuous clock) and it is better too, as the clock is seen
> correctly each time.
> But I still get into a EOF timeout, which sounds like another issue.
>
> FYI, I added the NFACK interrupt support in my local kernel just to
> see if New Frames are detected, and it is not the case either.
> Any reason for not using this interrupt (maybe in "debug" mode) ?
>
> Now, I used a scope (not very fast so I can't get into the very fast
> signals) and I can see some weird things.
> In a 1-lane configuration, and a 400MHz clock, I can get the following
> when looking at D0N and D0P (yellow and green, can't remember which
> color is which) :
> https://framapic.org/H65QXHvaWmao/qdyoARz12dNi.png
>
> The purple is the diff result.
>
> First I thought it was a start sequence (but with very bizarre things
> at the very beginning of the sequence) like described here :
> https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_Sync-Sequence-in-the-transmitted-pattern.jpg
>
> But Jacopo remarked that the 'starting sequence' is actually sent in
> HS mode, so we should not be able to see it at all.
> He thinks that what we are looking at is actually a bad LP-11 -> LP01
> -> LP00 transition.
>
> And it could be the "HS ZERO" :
> https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_HS-Burst-on-Data-Lane.jpg
Sorry, my wording was confusing maybe. I think that what we see in
your trace looks very similar to what the image above reports as "HS
ZERO" followed by "HS DATA". This confused me intially as I thought I
was looking at an "HS Sync Sequence" (as defined by D-PHY specs), while
as you reported, my understanding is that your trace shows LP signals,
before any HS data transmission happens (in the right
side of your trace, if I got this rigth) and we should see a stable
LP-11 state transitioning to LP01 and then LP00.
From my experience with ov5640 the i.MX6 seems more picky than other
devices on this. The ov5640 driver before commit:
aa4bb8b ("media: ov5640: Re-work MIPI startup sequence")
used to work fine on other platforms, while it failed on i.MX6 and
thus that patch.
This contrast with the fact that you now passes the:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
error you had reported in your initial email though :/
So please take my interpreation of that traces with a grain of salt, I
really don't want to mis-lead you to chase things that might actually
be correct.
Thanks
j
>
> What do you think of this ?
> We will conduce more complex measurements, with high speed analyzers
> in order to check everything, and we are right now focusing on a
> possible hardware issue (coule be the custom PCB which embeds the
> DS90UB954).
>
> Thanks,
> JM
signature.asc
Description: PGP signature
iMX.6: OV5640 internal jpeg encoder
Hello, I would like to know if someone successfully test the OV5640 internal jpeg encoder using MIPI-CSI2 on iMX.6 platform ? As I understand, jpeg format is currently supported by the camera but does the iMX6 IPU can handle it ? Thanks for your help ! Regards,
Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi Steve, Le mer. 31 oct. 2018 à 22:52, Steve Longerbeam a écrit : > > Hi Jean-Michel, > > We've done some work with another FPD-Link de-serializer (ds90ux940) and > IIRC we had some trouble figuring out how to coax the lanes into LP-11 > state. But on the ds90ux940 it can be done by setting bit 7 in the CSI > Enable Port registers (offsets 0x13 and 0x14). But the "imx6-mipi-csi2: > clock lane timeout" message is something else and indicates the > de-serializer is not activating the clock lane during its s_stream(ON) > subdev call. I have been doing more work on the driver I have, and I had CSI enabled before the csi2_dphy_wait_stopstate() call for instance. Now, LP-11 state is ok. Then, in the s_stream subcall, I added a delay after enabling CSI (and the continuous clock) and it is better too, as the clock is seen correctly each time. But I still get into a EOF timeout, which sounds like another issue. FYI, I added the NFACK interrupt support in my local kernel just to see if New Frames are detected, and it is not the case either. Any reason for not using this interrupt (maybe in "debug" mode) ? Now, I used a scope (not very fast so I can't get into the very fast signals) and I can see some weird things. In a 1-lane configuration, and a 400MHz clock, I can get the following when looking at D0N and D0P (yellow and green, can't remember which color is which) : https://framapic.org/H65QXHvaWmao/qdyoARz12dNi.png The purple is the diff result. First I thought it was a start sequence (but with very bizarre things at the very beginning of the sequence) like described here : https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_Sync-Sequence-in-the-transmitted-pattern.jpg But Jacopo remarked that the 'starting sequence' is actually sent in HS mode, so we should not be able to see it at all. He thinks that what we are looking at is actually a bad LP-11 -> LP01 -> LP00 transition. And it could be the "HS ZERO" : https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_HS-Burst-on-Data-Lane.jpg What do you think of this ? We will conduce more complex measurements, with high speed analyzers in order to check everything, and we are right now focusing on a possible hardware issue (coule be the custom PCB which embeds the DS90UB954). Thanks, JM
