media: test-drivers: Stop direct calls to queue num_buffers field

Use vb2_get_num_buffers() to avoid using queue num_buffers field directly.
This allows us to change how the number of buffers is computed in the
future.
If 'min_buffers_needed' is set remove useless checks in queue setup
functions.

Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
CC: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

media: vivid: Extend FPS rates offered by simulated webcam

This adds an option for higher frame rates from a simulated webcam.

Currently, vivid emulates (amongst other things) a webcam with somewhat
limited bandwidth - higher resolutions deliver fewer frames per second.

$ yavta --enum-formats -c /dev/video0
Device /dev/video0 opened.
Device `vivid' on `platform:vivid-000' (driver 'vivid') supports video, capture, without mplanes.
- Available formats:
Format 0: YUYV (56595559)
Type: Video capture (1)
Name: YUYV 4:2:2
Frame size: 320x180 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30, 1/40, 1/50, 1/60)
Frame size: 640x360 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30, 1/40)
Frame size: 640x480 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25)
Frame size: 1280x720 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25)
Frame size: 1920x1080 (1/1, 1/2, 1/4, 1/5)
Frame size: 3840x2160 (1/1, 1/2)

In some test cases, it is useful to allow for higher frame rates, as
configurations such as 720p@30 FPS have become commonplace now.

This patch allows:
0- 719p - 120fps
720-1079p - 60fps
1080-2159p - 30fps
2160p - 15fps

$ yavta --enum-formats -c /dev/video0
Device /dev/video0 opened.
Device `vivid' on `platform:vivid-000' (driver 'vivid') supports video, capture, without mplanes.
- Available formats:
Format 0: YUYV (56595559)
Type: Video capture (1)
Name: YUYV 4:2:2
Frame size: 320x180 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30, 1/40, 1/50, 1/60, 1/120)
Frame size: 640x360 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30, 1/40, 1/50, 1/60, 1/120)
Frame size: 640x480 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30, 1/40, 1/50, 1/60, 1/120)
Frame size: 1280x720 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30, 1/40, 1/50, 1/60)
Frame size: 1920x1080 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15, 1/25, 1/30)
Frame size: 3840x2160 (1/1, 1/2, 1/4, 1/5, 1/10, 2/25, 1/15)

Passes: v4l2-compliance 1.25.0-5039 from v4l-utils git ccc08732823f

Signed-off-by: Max Staudt <mstaudt@chromium.org>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[hverkuil: unsigned -> unsigned int]

media: vivid: drop overlay support

Destructive overlay support (i.e. where the video frame is DMA-ed
straight into a framebuffer) is effectively dead. It was a
necessary evil in the early days when computers were not fast enough
to copy SDTV video frames around, but today that's no longer a problem.

It requires access to the framebuffer memory, which is a bad idea and
very hard to do safely. In addition, in drm it is today almost
impossible to get hold of the framebuffer address.

So drop support for this.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

media: vivid: fix compose size exceed boundary

syzkaller found a bug:

BUG: unable to handle page fault for address: ffffc9000a3b1000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:memcpy_erms+0x6/0x10
[...]
Call Trace:
<TASK>
? tpg_fill_plane_buffer+0x856/0x15b0
vivid_fillbuff+0x8ac/0x1110
vivid_thread_vid_cap_tick+0x361/0xc90
vivid_thread_vid_cap+0x21a/0x3a0
kthread+0x143/0x180
ret_from_fork+0x1f/0x30
</TASK>

This is because we forget to check boundary after adjust compose->height
int V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problem
for this case.

Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts")
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

media: vivid: fix control handler mutex deadlock

vivid_update_format_cap() can be called from an s_ctrl callback.
In that case (keep_controls == true) no control framework functions
can be called that take the control handler mutex.

The new call to v4l2_ctrl_modify_dimensions() did exactly that.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 6bc7643d1b9c (media: vivid: add pixel_array test control)
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

media: vivid: dev->bitmap_cap wasn't freed in all cases

Whenever the compose width/height values change, the dev->bitmap_cap
vmalloc'ed array must be freed and dev->bitmap_cap set to NULL.

This was done in some places, but not all. This is only an issue if
overlay support is enabled and the bitmap clipping is used.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: ef834f7836ec ([media] vivid: add the video capture and output parts)
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

media: vivid: s_fbuf: add more sanity checks

VIDIOC_S_FBUF is by definition a scary ioctl, which is why only root
can use it. But at least check if the framebuffer parameters match that
of one of the framebuffer created by vivid, and reject anything else.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: ef834f7836ec ([media] vivid: add the video capture and output parts)
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

media: vivid: add pixel_array test control

This control will change dimensions according to the source resolution.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

media: v4l2: allocate v4l2_clip objects early

The v4l2_format based ioctls can have an indirect pointer to an array
of v4l2_clip structures for overlay mode, depending on the 'type' member.
There are only five drivers that use the overlay mode and copy the
data through the __user pointer.

Change the five drivers to use memcpy() instead, and copy the data
in common code using the check_array_args() helpers. This allows
for a subsequent patch that use the same mechanism for compat
ioctl handlers.

Note that there is another pointer for a 'bitmap' that is only
used in the 'vivid' driver and nowhere else. There is no easy
way to use the same trick without adding complexity to the
common code, so this remains a __user pointer.

[hverkuil: fix: CHECK: spaces preferred around that '*' (ctx:VxV)]
[hverkuil: fix: CHECK: Alignment should match open parenthesis]

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vivid: Add support to the CSC API

The CSC API (Colorspace conversion) allows userspace to try
to configure the colorspace, transfer function, Y'CbCr/HSV encoding
and the quantization for capture devices. This patch adds support
to the CSC API in vivid.
Using the CSC API, userspace is allowed to do the following:

- Set the colorspace.
- Set the xfer_func.
- Set the ycbcr_enc function for YUV formats.
- Set the hsv_enc function for HSV formats
- Set the quantization for YUV and RGB formats.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: media/test_drivers: rename to test-drivers

We never use _ in directory names in the media subsystem, so
rename to test-drivers instead for consistency.

Also update MAINTAINERS with the new path.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>