media: Revert "staging: imgu: Address a compiler warning on alignment"

This reverts commit c9d52c114a9fcc61c30512c7f810247a9f2812af.

The patch being reverted changed the memory layout of struct
ipu3_uapi_acc_param. Revert it, and address the compiler warning issues in
further patches.

Fixes: commit c9d52c114a9f ("media: staging: imgu: Address a compiler warning on alignment")
Reported-by: Tomasz Figa <tfiga@chromium.org>
Tested-by: Bingbu Cao <bingbu.cao@intel.com>
Cc: stable@vger.kernel.org # for v5.3 and up
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: MAINTAINERS: ipu3-imgu: Add Tian Shu and Bingbu as reviewers

Add Bingbu Cao and Tian Shu Qiu as reviewers for the IPU3 ImgU driver.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Bingbu Cao <bingbu.cao@intel.com>
Cc: Tian Shu Qiu <tian.shu.qiu@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: ipu3.rst: add explanation for running mode

Add some explanation of the ImgU running mode and add more information
about firmware selection and running mode usage.

Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: ipu3: Fix stale list entries on parameter queue failure

When queuing parameters fails, current code bails out without deleting
the corresponding vb2 buffer from the driver buffer list, but the buffer
is returned to vb2. This leads to stale list entries and a crash when
the driver stops streaming:

[  224.935561] ipu3-imgu 0000:00:05.0: set parameters failed.
[  224.998932] ipu3-imgu 0000:00:05.0: set parameters failed.
[  225.064430] ipu3-imgu 0000:00:05.0: set parameters failed.
[  225.128534] ipu3-imgu 0000:00:05.0: set parameters failed.
[  225.194945] ipu3-imgu 0000:00:05.0: set parameters failed.
[  225.360363] ------------[ cut here ]------------
[  225.360372] WARNING: CPU: 0 PID: 6704 at
drivers/media/common/videobuf2/videobuf2-core.c:927
vb2_buffer_done+0x20f/0x21a [videobuf2_common]
[  225.360374] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
veth bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header cmac rfcomm uinput
ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common
videobuf2_dma_sg videobuf2_memops ov13858 ov5670 v4l2_fwnode dw9714
acpi_als xt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring
cros_ec_light_prox cros_ec_sensors cros_ec_sensors_core
industrialio_triggered_buffer kfifo_buf industrialio
cros_ec_sensorsupport cdc_ether btusb btrtl btintel btbcm usbnet
bluetooth ecdh_generic ecc hid_google_hammer iwlmvm iwl7000_mac80211
r8152 mii lzo_rle lzo_compress iwlwifi zram cfg80211 joydev
[  225.360400] CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G
C        5.4.30 #5
[  225.360402] Hardware name: HP Soraka/Soraka, BIOS
Google_Soraka.10431.106.0 12/03/2019
[  225.360405] RIP: 0010:vb2_buffer_done+0x20f/0x21a [videobuf2_common]
[  225.360408] Code: 5e 41 5f 5d e9 e0 16 5a d4 41 8b 55 08 48 c7 c7 8f
8b 5c c0 48 c7 c6 36 9a 5c c0 44 89 f9 31 c0 e8 a5 1c 5b d4 e9 53 fe ff
ff <0f> 0b eb a3 e8 12 d7 43 d4 eb 97 0f 1f 44 00 00 55 48 89 e5 41 56
[  225.360410] RSP: 0018:ffff9468ab32fba8 EFLAGS: 00010297
[  225.360412] RAX: ffff8aa7a51577a8 RBX: dead000000000122 RCX:
ffff8aa7a51577a8
[  225.360414] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
ffff8aa7a5157400
[  225.360416] RBP: ffff9468ab32fbd8 R08: ffff8aa64e47e600 R09:
0000000000000000
[  225.360418] R10: 0000000000000000 R11: ffffffffc06036e6 R12:
dead000000000100
[  225.360420] R13: ffff8aa7820f1940 R14: ffff8aa7a51577a8 R15:
0000000000000006
[  225.360422] FS:  00007c1146ffd700(0000) GS:ffff8aa7baa00000(0000)
knlGS:0000000000000000
[  225.360424] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  225.360426] CR2: 00007aea3473a000 CR3: 00000000537d6004 CR4:
00000000003606f0
[  225.360427] Call Trace:
[  225.360434]  imgu_return_all_buffers+0x6f/0x8e [ipu3_imgu]
[  225.360438]  imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu]
[  225.360441]  __vb2_queue_cancel+0x33/0x22d [videobuf2_common]
[  225.360443]  vb2_core_streamoff+0x16/0x78 [videobuf2_common]
[  225.360448]  __video_do_ioctl+0x33d/0x42a
[  225.360452]  video_usercopy+0x34a/0x615
[  225.360455]  ? video_ioctl2+0x16/0x16
[  225.360458]  v4l2_ioctl+0x46/0x53
[  225.360462]  do_vfs_ioctl+0x50a/0x787
[  225.360465]  ksys_ioctl+0x58/0x83
[  225.360468]  __x64_sys_ioctl+0x1a/0x1e
[  225.360470]  do_syscall_64+0x54/0x68
[  225.360474]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  225.360476] RIP: 0033:0x7c118030f497
[  225.360479] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48
[  225.360480] RSP: 002b:00007c1146ffa5a8 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[  225.360483] RAX: ffffffffffffffda RBX: 00007c1140010018 RCX:
00007c118030f497
[  225.360484] RDX: 00007c114001019c RSI: 0000000040045613 RDI:
000000000000004c
[  225.360486] RBP: 00007c1146ffa700 R08: 00007c1140010048 R09:
0000000000000000
[  225.360488] R10: 0000000000000000 R11: 0000000000000246 R12:
00007c11400101b0
[  225.360489] R13: 00007c1140010200 R14: 00007c1140010048 R15:
0000000000000001
[  225.360492] ---[ end trace 73625ecfbd1c930e ]---
[  225.360498] general protection fault: 0000 [#1] PREEMPT SMP PTI
[  225.360501] CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G
WC        5.4.30 #5
[  225.360502] Hardware name: HP Soraka/Soraka, BIOS
Google_Soraka.10431.106.0 12/03/2019
[  225.360505] RIP: 0010:imgu_return_all_buffers+0x52/0x8e [ipu3_imgu]
[  225.360507] Code: d4 49 8b 85 70 0a 00 00 49 81 c5 70 0a 00 00 49 39
c5 74 3b 49 bc 00 01 00 00 00 00 ad de 49 8d 5c 24 22 4c 8b 30 48 8b 48
08 <49> 89 4e 08 4c 89 31 4c 89 20 48 89 58 08 48 8d b8 58 fc ff ff 44
[  225.360509] RSP: 0018:ffff9468ab32fbe8 EFLAGS: 00010293
[  225.360511] RAX: ffff8aa7a51577a8 RBX: dead000000000122 RCX:
dead000000000122
[  225.360512] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
ffff8aa7a5157400
[  225.360514] RBP: ffff9468ab32fc18 R08: ffff8aa64e47e600 R09:
0000000000000000
[  225.360515] R10: 0000000000000000 R11: ffffffffc06036e6 R12:
dead000000000100
[  225.360517] R13: ffff8aa7820f1940 R14: dead000000000100 R15:
0000000000000006
[  225.360519] FS:  00007c1146ffd700(0000) GS:ffff8aa7baa00000(0000)
knlGS:0000000000000000
[  225.360521] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  225.360523] CR2: 00007aea3473a000 CR3: 00000000537d6004 CR4:
00000000003606f0
[  225.360525] Call Trace:
[  225.360528]  imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu]
[  225.360531]  __vb2_queue_cancel+0x33/0x22d [videobuf2_common]
[  225.360534]  vb2_core_streamoff+0x16/0x78 [videobuf2_common]
[  225.360537]  __video_do_ioctl+0x33d/0x42a
[  225.360540]  video_usercopy+0x34a/0x615
[  225.360542]  ? video_ioctl2+0x16/0x16
[  225.360546]  v4l2_ioctl+0x46/0x53
[  225.360548]  do_vfs_ioctl+0x50a/0x787
[  225.360551]  ksys_ioctl+0x58/0x83
[  225.360554]  __x64_sys_ioctl+0x1a/0x1e
[  225.360556]  do_syscall_64+0x54/0x68
[  225.360559]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  225.360561] RIP: 0033:0x7c118030f497
[  225.360563] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48
[  225.360565] RSP: 002b:00007c1146ffa5a8 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[  225.360567] RAX: ffffffffffffffda RBX: 00007c1140010018 RCX:
00007c118030f497
[  225.360569] RDX: 00007c114001019c RSI: 0000000040045613 RDI:
000000000000004c
[  225.360570] RBP: 00007c1146ffa700 R08: 00007c1140010048 R09:
0000000000000000
[  225.360572] R10: 0000000000000000 R11: 0000000000000246 R12:
00007c11400101b0
[  225.360574] R13: 00007c1140010200 R14: 00007c1140010048 R15:
0000000000000001
[  225.360576] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
veth bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header cmac rfcomm uinput
ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common
videobuf2_dma_sg videobuf2_memops ov13858 ov567

Fix this by moving the list_del() call just below the list_first_entry()
call when the buffer no longer needs to be in the list.

Fixes: 8ecc7c9da013 ("media: staging/intel-ipu3: parameter buffer refactoring")
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: venc,vdec: Return EBUSY on S_FMT while streaming

According to the v4l spec s_fmt must return EBUSY while the
particular queue is streaming. Add such check in encoder and
decoder s_fmt methods.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: Mark last capture buffer

According to stateful Codec API the decoder will process all
remaining buffers from before the source change event in
dynamic-resolution-change state and mark the last buffer with
V4L2_BUF_FLAG_LAST.

In Venus case the firmware doesn't mark that last buffer and
some mechanism have to be created in v4l decoder driver.
Fortunately the firmware interface (HFI) claims that the
decoder output buffers will be returned to v4l decoder
driver before it send the insufficient event.

In order to do that we save last queued in the driver capture
buffer in the event_notify and issue flush on output firmware
buffers queue. Once the saved buffer is returned (as a result of
flush command) we mark it as LAST. For all that possible we
extend HFI flush command with one more argument and one more
flush_done HFI driver callback.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: vdec: Init registered list unconditionally

Presently the list initialization is done only in
dynamic-resolution-change state, which leads to list corruptions
and use-after-free. Init list_head unconditionally in
vdec_stop_capture called by vb2 stop_streaming without takeing
into account current codec state.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: vdec: Mark flushed buffers with error state

Once the hfi_session_flush is issued by the vdec all queued
buffers to firmware should be returned to the v4l driver. Some
of those buffers are not processed at the time of flush command,
those buffers has filled len zero (no data). Catch that in
buffer_done callback and mark not filled capture buffers with
error state so that client can discard them.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: helpers: Done buffers per queue type

Currently calling venus_helper_buffers_done() will return buffers to
user for both capture and output queues in the same call. This is
wrong because both queues are really separate and calling
stop_streaming on one queue shouldn't return buffers for the other.
Solve this by add a new queue type argument and fix the clients of
the helper function.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: core: Constify codec frequency data array

The array is not changed in the code, so make it const.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: core: Fix mutex destroy in remove

The hfi_destroy function is called too early in remove method. It
destroys a mutex which is used later in the .remove from pmruntime.
Solve the issue by moving hfi_destroy after last usage of the mutex.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: core: Add missing mutex destroy

This adds missing mutex_destroy in remove method of venus core driver.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrls.h: clarify the p_def argument of v4l2_ctrl_new_std_compound

It was not sufficiently clear how to create and use p_def.
Improve the documentation.

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

media: cec-gpio: handle gpiod_get_value errors correctly

gpiod_get_value() can return negative values if an error occurs.
In several places this error code was ignored.

Ensure that errors codes are handled correctly throughout the CEC
pin framework and CEC pin drivers.

The return code of the cec_pin_ops read() callback had to be changed
from 'bool' to 'int', which mean the prototype of that callback in the
sun4i drm driver also had to be changed.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vidioc-reqbufs/create-bufs.rst: fix typo

any others capabilities -> any other capabilities

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

media: MAINTAINERS: adjust entries to moving CEC USB drivers

Commit a81068181aad ("media: move CEC USB drivers to a separate directory")
moved drivers/media/usb/{pulse8,rainshadow}-cec to
drivers/media/cec/usb/{rainshadow,pulse8}, but did not adjust the entries
in MAINTAINERS.

Since then, ./scripts/get_maintainer.pl --self-test=patterns complains:

  warning: no file matches F: drivers/media/usb/pulse8-cec/*
  warning: no file matches F: drivers/media/usb/rainshadow-cec/*

Update the MAINTAINERS entries to the new file locations.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vimc: cap: Report a colorspace

The colorspace reported by a video nodes should not be
V4L2_COLORSPACE_DEFAULT. Instead a default colorspace should be picked
by the driver if V4L2_COLORSPACE_DEFAULT is given by userspace to
{G,S,TRY}_FMT.

The colorspace V4L2_COLORSPACE_SRGB is arbitrary chosen as the vimc
default format to report as it's used for most webcams.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: ensure wait_status is initialized

smatch reports wait_status is uninitialized, because smatch cannot assume
the loop body is ever executed.

Clarify the code so that wait_status is retrieved at least once.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rc: no need for decoder state if decoder not enabled

One struct ir_raw_event_ctrl is allocated per raw IR device; reduce the
amount allocated if not all decoders are enabled.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: m88ds3103: error in set_frontend is swallowed and not reported

Bail out if registers can not be updated.

Addresses-Coverity-ID: 1461655 ("Code maintainability issues")

Reported-by: coverity-bot <keescook+coverity-bot@chromium.org>
Fixes: e6089feca460 ("media: m88ds3103: Add support for ds3103b demod")
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: Kconfig: fix some dvb-usb-v2 dependencies

There are some tuners used by a few pure DVB boards that use
internally V4L2 function calls. Due to that, such drivers now
depends on v4l2 core support, and can't be auto-selected
if !VIDEO_V4L2:

WARNING: unmet direct dependencies detected for DVB_RTL2832_SDR
  Depends on [n]: MEDIA_SUPPORT [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_CORE [=y] && I2C [=y] && I2C_MUX [=y] && VIDEO_V4L2 [=n] && MEDIA_SDR_SUPPORT [=y] && USB [=y]
  Selected by [y]:
  - DVB_USB_RTL28XXU [=y] && USB [=y] && MEDIA_SUPPORT [=y] && MEDIA_USB_SUPPORT [=y] && I2C [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_USB_V2 [=y] && I2C_MUX [=y] && MEDIA_SUBDRV_AUTOSELECT [=y] && MEDIA_SDR_SUPPORT [=y]

WARNING: unmet direct dependencies detected for MEDIA_TUNER_E4000
  Depends on [n]: (MEDIA_ANALOG_TV_SUPPORT [=y] || MEDIA_DIGITAL_TV_SUPPORT [=y] || MEDIA_RADIO_SUPPORT [=y] || MEDIA_SDR_SUPPORT [=y]) && MEDIA_SUPPORT [=y] && I2C [=y] && VIDEO_V4L2 [=n]
  Selected by [y]:
  - DVB_USB_RTL28XXU [=y] && USB [=y] && MEDIA_SUPPORT [=y] && MEDIA_USB_SUPPORT [=y] && I2C [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_USB_V2 [=y] && I2C_MUX [=y] && MEDIA_SUBDRV_AUTOSELECT [=y]

WARNING: unmet direct dependencies detected for MEDIA_TUNER_FC2580
  Depends on [n]: (MEDIA_ANALOG_TV_SUPPORT [=y] || MEDIA_DIGITAL_TV_SUPPORT [=y] || MEDIA_RADIO_SUPPORT [=y] || MEDIA_SDR_SUPPORT [=y]) && MEDIA_SUPPORT [=y] && I2C [=y] && VIDEO_V4L2 [=n]
  Selected by [y]:
  - DVB_USB_RTL28XXU [=y] && USB [=y] && MEDIA_SUPPORT [=y] && MEDIA_USB_SUPPORT [=y] && I2C [=y] && MEDIA_DIGITAL_TV_SUPPORT [=y] && DVB_USB_V2 [=y] && I2C_MUX [=y] && MEDIA_SUBDRV_AUTOSELECT [=y]

Detected via randconfig builds.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: platform: fix VIA_CAMERA dependencies

As detected by a randconfig:

WARNING: unmet direct dependencies detected for VIDEO_OV7670
  Depends on [n]: MEDIA_SUPPORT [=y] && I2C [=y] && VIDEO_V4L2 [=n]
  Selected by [y]:
  - VIDEO_VIA_CAMERA [=y] && MEDIA_SUPPORT [=y] && MEDIA_PLATFORM_SUPPORT [=y] && V4L_PLATFORM_DRIVERS [=y] && FB_VIA [=y]

There's a missing dependency on VIDEO_V4L2 for VIA_CAMERA.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: tuners: Kconfig: add some missing VIDEO_V4L2 dependencies

There are three tuners that depend on some functions inside
V4L2 core:

$ git grep -l -E 'v4l2_[0-9a-zA-Z_]+\(' drivers/media/tuners/
drivers/media/tuners/e4000.c
drivers/media/tuners/fc2580.c
drivers/media/tuners/msi001.c

Make them dependent of VIDEO_V4L2, as otherwise, this would happen:

on x86_64:
CONFIG_VIDEO_V4L2=m
CONFIG_MEDIA_TUNER_E4000=y

ld: drivers/media/tuners/e4000.o: in function `e4000_remove':
e4000.c:(.text+0x34): undefined reference to `v4l2_ctrl_handler_free'
ld: drivers/media/tuners/e4000.o: in function `e4000_probe':
e4000.c:(.text+0x16c1): undefined reference to `v4l2_ctrl_handler_init_class'
ld: e4000.c:(.text+0x16eb): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x1731): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x1762): undefined reference to `v4l2_ctrl_auto_cluster'
ld: e4000.c:(.text+0x178c): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x17d6): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x1804): undefined reference to `v4l2_ctrl_auto_cluster'
ld: e4000.c:(.text+0x182e): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x1878): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x18a6): undefined reference to `v4l2_ctrl_auto_cluster'
ld: e4000.c:(.text+0x18d0): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x191a): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x1948): undefined reference to `v4l2_ctrl_auto_cluster'
ld: e4000.c:(.text+0x1972): undefined reference to `v4l2_ctrl_new_std'
ld: e4000.c:(.text+0x19a6): undefined reference to `v4l2_ctrl_handler_free'
ld: e4000.c:(.text+0x1a2a): undefined reference to `v4l2_i2c_subdev_init'

Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

MAINTAINERS: reorder media attributes

Some media entry attributes got out of the order after the
bug was split into 3. Also, as reported by Johan, the
Rockchip VPU entry also had their attributes at the wrong
order.

As those entries weren't merged yet upstream, let's reorder
them with:

./scripts/parse-maintainers.pl --input=MAINTAINERS --output=MAINTAINERS --order

Reported-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: MAINTAINERS: Fix Hantro, Rga and Rkvdec entries

It seems recent merges introduced a couple issues
here, so let's fix them all. Also, reorder Rockchip
video decoder as per parse-maintainers.pl script
and add linux-rockchip mailing list.

Reported-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rkisp1: fix missing mbus.type -> mbus_type conversion

There was one missing sensor->mbus.type to sensor->mbus_type
conversion which broke the build.

I suspect this was due to a merge conflict that was incorrectly resolved.

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

media: admin-guide: split driver-specific indexes to new files

In order to better organize the main admin-guide index,
place the driver-specific indexes on separate files.

This ensures a more consistent numbering at the main index.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: reorganize the guide

Separate the generic documentation from the driver-specific
parts, and use a better title for the documentation.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: bt8xx.rst: fix a broken cross-reference

The old cards.rst file doesn't exist anymore. Also, it is not
the right reference there, as it should be pointing to the
bttv-specific cardlist.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add test-drivers

While test drivers is probably something that normal users
won't bother, it doesn't hurt to add them to the card list.

This way, all drivers, except for the ones under staging,
would be listed there.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add card lists for radio and firewire

Document the supported radio devices, plus document the
firewire driver.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add SPI cards to platform drivers

The SPI cards are also under the concept of "platform" drivers
as defined at the section introduction.

So, add a SPI card list there.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a list of I2C drivers

For completeness, let's add a list of I2C drivers.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a list of platform drivers

There's no reason why to keep platform drivers out of the
card list. Add them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a table with USB drivers

Having a table with a list of all USB drivers seems worth,
and it comes almost for free, as we can just use Kconfig
descriptions (with some adjustments).

So, add a table for that.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a list of media PCI cards

Instead of listing "other" PCI card list, just add a list with
the existing drivers (not including sub-drivers).

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: replace the frontend drivers list

The frontend drivers list is incomplete. Update it from
what's there at the Kernel Kconfig files.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: split DVB cards.rst

The DVB cards.rst file is old and outdated. It also contains
data that are contained on other cardlists. Remove the
duplicated information and split frontends and PCI cards on
separate files.

As all USB cards already have their own card lists, just drop
the old USB data there.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a cardlist for all other USB cards

There are several other USB cards. Most of them support just
one device. The only exception is the "pwc" driver. But, as
updates to it are not frequent, let's just place everything
manually into a single file.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a card list for the Siano driver

The siano driver looks like em28xx, except that its cards
are split on 3 drivers.

Add a card list for it.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add support for the remaining dvb-usb boards

Add documentation for the remaining dvb-usb boards.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add dibusb-mb and dibusb-mc card lists

Document the supported dib0300 boards.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add cardlist for dib0700 driver

Document the cards supported by dib0700 driver.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add dvb-usb-v2 card lists

Include cardlist documentation for the sub-drivers supported by
dvb-usb-v2 core.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: improve cardlist.rst documentation

The cardlist section is important for some boards, because they
may require extra modprobe parameters.

Improve the docs to mention that.

Thanks-to: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for providing me some PCI IDs
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a generic building guide

Several of the existing documents under the media admin-guide
contain build procedures.

Add an specific chapter describing it. This document was
partially inspired on the modifications I made to the bttv.rst
file.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: Add an introduction chapter

The media's admin guide is currently just a group of
not-connected docs.

Add an introduction chapter for it to start making sense
to a random reader.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: update em28xx cardlist

A new em28xx card was added upstream. Update cards list
accordingly.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: admin-guide: add a card list for cx231xx boards

It is interesting to have a card list also for cx231xx
driver, as it currently supports 27 different boards.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: pwc-if: place USB device list on numberical order

It seems easier to maintain the list if the USB_DEVICE
is ordered.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: pwc-if.c: Update comments about each pwc supported model

The USB_DEVICE() list contain some of the product names, but
some are missing, and others are different than the message
printed during device detection.

Update the comments in order to match what the driver prints.

That makes easier to discover what model matches what physical
device.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dvb-usb-v2: use DVB_USB_DEVICE() macro

Instead of using USB_DEVICE() macro directly, use the
DVB_USB_DEVICE() one, as other dvb-usb-v2 devices.

The usage of the new macro makes cleaner and easier to
parse the supported device names in a way that it would
be easily parseable to generate cardlists.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dvb-usb-ids.h: fix an USB PID name

The USB_PID_ALINK_DTU is a Product ID, not a vendor ID.

Fix that.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: rockchip-rga: add power-domains property

In the old txt situation we add/describe only properties that are used
by the driver/hardware itself. With yaml it also filters things in a
node that are used by other drivers like 'power-domains' for rk3399,
so add it to 'rockchip-rga.yaml'.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: media: convert rockchip rga bindings to yaml

Current dts files for Rockchip with 'rga' nodes
are manually verified. In order to automate this process
rockchip-rga.txt has to be converted to yaml.

Changed:
  Add missing reg property

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: cap: support uv swapped planar formats

Planar formats with the u and v planes swapped can be
supported by swapping the address of the cb and cr buffers.

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

media: staging: rkisp1: cap: support uv swap only for semiplanar formats

The register RKISP1_CIF_MI_XTD_FORMAT_CTRL is relevant only
for semiplanar formats, therefore the uv swap can be supported
through this register only for semiplanar formats.

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

media: staging: rkisp1: cap: change the logic for writing to uv swap register

The register RKISP1_CIF_MI_XTD_FORMAT_CTRL is currently written
with "on" only if the u,v streams need to be swapped. This patch
also write to it with "off" if they don't need to be swapped.

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

media: staging: rkisp1: cap: fix value written to uv swap register in selfpath

The value RKISP1_CIF_MI_XTD_FMT_CTRL_SP_CB_CR_SWAP should be
set to the register instead of masking with ~BIT(1)

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

media: staging: rkisp1: cap: cleanup in mainpath config for uv swap format

The value RKISP1_CIF_MI_XTD_FMT_CTRL_MP_CB_CR_SWAP equals BIT(0),
Therefore when writing it to the register there is no need to mask
it first with ~BIT(0).

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-image-sizes: add HD and Full-HD definitions

Add common (Full-)HD definitions also known as 720p and 1080p.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: coda: add RC enable controls

Currently the encoder enables the rate control algorithms if the bitrate
control is non-zero. Implement the V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE
and V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE controls to allow userspace to
choose frame-level or macroblock-level rate control updates, or to
explicitly disable rate control. Both controls are initially enabled to
keep the current behavior.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: replace the call to v4l2_async_notifier_parse_fwnode_endpoints_by_port

don't call 'v4l2_async_notifier_parse_fwnode_endpoints_by_port'
in order to register async subdevices. Instead call
'v4l2_fwnode_endpoint_parse' to parse the remote endpoints
and then register each async subdev with
'v4l2_async_notifier_add_fwnode_remote_subdev'

Also remove the relevant item in the TODO file

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

media: staging: rkisp1: remove mbus field from rkisp1_sensor_async

'struct v4l2_mbus_config' is a legacy struct that should not be used
in new drivers. So replace it with the fields:

enum v4l2_mbus_type mbus_type;
unsigned int mbus_flags;

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

media: staging: rkisp1: cap: serialize start/stop stream

In order to support simultaneous streaming from both capture devices,
start/stop vb2 calls need to be serialized to allow multiple concurrent
calls.

Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: cap: fix return values from pm functions

If no errors occurs, pm functions return usage counters, so they can
return positive numbers.
This happens when streaming from multiple capture devices (mainpath and
selfpath).

Fix simultaneous streaming from mainpath and selfpath by not failing
when pm usage counters returns a positive number.

Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrls: add __v4l2_ctrl_s_ctrl_compound()

Rather than creating new compound control helpers for each new
type, create one generic function and just create defines on
top.

Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Tested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-ctrls: v4l2_ctrl_g/s_ctrl*(): don't continue when WARN_ON

If the v4l2_ctrl_g_ctrl*() or __v4l2_ctrl_s_ctrl*() functions
are called for the wrong control type then they call WARN_ON
since that is a driver error. But they still continue, potentially
overwriting data. Change this to return an error (s_ctrl) or 0
(g_ctrl), just to be safe.

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

media: iguanair: rc drivers no longer need to do locking

Since commit 4957133fe32f ("media: lirc: improve locking"), drivers
do not need to do any of their own locking.

During suspend and resume, no processes are running so no locking is
needed.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cx25840: Register labeling, chip specific correction

Remove vbi_regs_offset from a group of registers that are 888 specific,
include those registers names. Sources used for reference are 885 and 888
datasheets.

Add labels to some undocumented registers.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: lgdt3306a: Add CNR v5 stat

The CNR is already calculated, so populate DVBv5 CNR stat
during read_status.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: add on-demand rf strength func

Add get_rf_strength callback to get RSSI from the tuner. DVBv5
stat cache is updated. get_rf_strength is called by tuner_core
for analog tuners and is also used by some bridge drivers to
obtain RSSI directly from the tuner.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cx231xx: Add i2c device analog tuner support

The boards listed below use i2c device drivers and have
tuner_type equal TUNER_ABSENT. This means additional support
is required to enable the analog tuning capability, a case
statement is used to identify these models.

Models with analog tuning enabled:
- CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx (tested)
- CX231XX_BOARD_HAUPPAUGE_935C (tested)
- CX231XX_BOARD_HAUPPAUGE_955Q (tested)
- CX231XX_BOARD_HAUPPAUGE_975 (tested)
- CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD (untested)

The EvroMedia model was added, since it uses the si2157
tuner and the board profile claims it has analog inputs.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cx23885: Add i2c device analog tuner support

Hauppauge QuadHD/1265/5525 boards all use i2c device drivers and
have tuner_type equal TUNER_ABSENT. This means additional support
is required to enable the analog tuning capability, a case
statement is used to identify these models.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cx23885: Add analog frontend to HVR5525

Enables the analog tuning frontend for Hauppauge HVR-5525.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cx23885: Add analog frontend to 1265_K4

Enables the analog tuning frontend for Hauppauge HVR-1265_K4.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cx23885: Add analog frontend to Hauppauge QuadHD

Add analog tuner frontend to 888 Hauppauge QuadHD boards

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: module debug option to wait on signal lock

In some debugging cases it is useful to know how long it took
signal lock to happen after tuning. This can help diagnose
line issues.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: Briefly wait for tuning operation to complete

To detect errors in the tuning operation, this waits up 40ms for operation
completion status. This allows for error detection and prevents issuing
additional commands to the tuner before it is finished.

Tuning typically completes in 20-30ms.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: Add analog tuning related functions

Include set_analog_params, get_frequency, and get_bandwidth.

Tested with NTSC and PAL standards via ch3/4 generator. Other standards
are included, but are untested due to lack of generator.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: Better check for running tuner in init

Getting the Xtal trim property to check if running is less error prone.
Reset if_frequency if state is unknown.

Replaces the previous "garbage check".

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: Check error status bit on cmd execute

Check error status bit on command execute, if error bit is
set return -EAGAIN. Ignore -EAGAIN in probe during device check.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: si2157: Enable tuner status flags

Enable flags to get status of commands sent to the tuner.

Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rkvdec: Add the rkvdec driver

The rockchip vdec block is a stateless decoder that's able to decode
H264, HEVC and VP9 content. This commit adds the core infrastructure
and the H264 backend. Support for VP9 and HEVS will be added later on.

[mchehab+huawei@kernel.org: select MEDIA_CONTROLLER and REQUEST_API]
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: dt-bindings: rockchip: Document RK3399 Video Decoder bindings

Document the Rockchip RK3399 Video Decoder bindings.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: hantro: h264: Use the generic H264 reflist builder

Now that the core provides generic reflist builders, we can use them
instead of implementing our own.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-core: Add helpers to build the H264 P/B0/B1 reflists

Building those list is a standard procedure described in section
'8.2.4 Decoding process for reference picture lists construction' of
the H264 specification.

We already have 2 drivers needing the same logic (hantro and rkvdec) and
I suspect we will soon have more.

Let's provide generic helpers to create those lists.

Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rkisp1: Fix wrong PHY config dependency

Instead of depending on the Rockchip PHY driver the ISP driver
should really depend on CONFIG_GENERIC_PHY_MIPI_DPHY,
given all it needs is the phy_mipi_dphy_get_default_config() symbol.

Fix it.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: phy-rockchip-dphy-rx0: Drop unneeded CONFIG_OF dependency

The driver is perfectly capable of being built without CONFIG_OF.
Remove this dependency, which is useful for compile-only tests.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rkisp1: Get rid of unused variable warning

If CONFIG_OF is not selected, the compiler will complain:

drivers/staging/media/rkisp1/rkisp1-dev.c: In function ‘rkisp1_probe’:
drivers/staging/media/rkisp1/rkisp1-dev.c:457:22: warning: unused variable ‘node’ [-Wunused-variable]
  457 |  struct device_node *node = pdev->dev.of_node;

Rework the code slightly and make the compiler happy.

Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: v4l2-fh: define v4l2_fh struct regardless of condition

v4l2_fh struct define differently by CONFIG_V4L2_MEM2MEM_DEV.
If some vendors use CONFIG_V4L2_MEM2MEM_DEV by module,
it can make the mismatch of v4l2_fh sturct.

By the mismatch, the following error occurs.
===============================
[    7.533506] v4l2_mem2mem: disagrees about version of symbol video_devdata
[    7.533594] v4l2_mem2mem: Unknown symbol video_devdata (err -22)
[    7.535319] v4l2_mem2mem: disagrees about version of symbol v4l2_event_pending
[    7.542532] v4l2_mem2mem: Unknown symbol v4l2_event_pending (err -22)
===============================

So v4l2_fh struct is modified to does not have dependency
for CONFIG_V4L2_MEM2MEM_DEV.

Signed-off-by: Seungchul Kim <sc377.kim@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: change fields names from fmt_type to pixel_enc

The fields 'fmt_type' in the structs
'rkisp1_rsz_config', 'rkisp1_isp_mbus_info' are of type
'v4l2_pixel_encoding' so it is nicer to change their name to
'pixel_enc'. Also change the define 'RKISP1_DEF_FMT_TYPE' to
'RKISP1_DEF_PIXEL_ENC'

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: staging: rkisp1: cap: remove field fmt_type from struct rkisp1_capture_fmt_cfg

The pixel encoding can be retrieved from the cap->pix.info.
Therefore the field fmt_type can be removed from the
struct rkisp1_capture_fmt_cfg.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: replace rkisp1_fmt_pix_type with v4l2_pixel_encoding

The enum rkisp1_fmt_pix_type that holds the pixel format
which is one of RGB, YUV, BAYER, can be replace by the
v4l2 enum v4l2_pixel_encoding.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: platform: fcp: Set appropriate DMA parameters

Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will
enable extra validation on DMA operations ensuring that the size
restraints are met.

When using the FCP in conjunction with the VSP1/DU, and display frames,
the size of the DMA operations is larger than the default maximum
segment size reported by the DMA core (64K). With the DMA debug enabled,
this produces a warning such as the following:

"DMA-API: rcar-fcp fea27000.fcp: mapping sg segment longer than device
claims to support [len=3145728] [max=65536]"

We have no specific limitation on the segment size which isn't already
handled by the VSP1/DU which actually handles the DMA allcoations and
buffer management, so define a maximum segment size of up to 4GB (a 32
bit mask).

Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: 7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver")
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: staging: rkisp1: remove TODO item - uapi structs compatibility

remove the TODO item:

* Make sure uapi structs have the same size and layout in 32 and 62 bits,
and that there are no holes in the structures (pahole is a utility that
can be used to test this).

It was tested with pahole and found compatible.

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: vicodec: Fix error codes in probe function

If these functions fail then we return success, but we should instead
preserve negative error code and return that.

Fixes: fde649b418d1 ("media: vicodec: Register another node for stateless decoder")
Fixes: c022a4a95722 ("media: vicodec: add struct for encoder/decoder instance")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: imx.rst: Provide streaming examples for imx6q-sabresd

Improve the documentation by providing examples on how to test camera
capture on imx6q-sabresd via v4l2-ctl and Gstreamer.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Steve Longerbeam<slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: imx.rst: Provide the OV560 module part number

In order to improve the documentation, provide the OV5640 MIPI module
part number that is used on the imx6q-sabresd board.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: imx.rst: Provide an example for unprocessed video capture

The current example for imx6q-sabresd is for a direct conversion pipeline.

Provide an extra example using unprocessed video capture for completeness.

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Steve Longerbeam <slongerbeam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>