media: lgdt330x: print info when device gets probed

It is useful to know if the driver load succeded. So,
add a printk info there.

While here, improve the .init debug printed message.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: lgdt330x: use pr_foo() macros

Cleanup the usecases of dprintk() by using pr_fmt() and replace
printk by pr_foo().

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: lgdt330x: fix coding style issues

As we're about to convert this driver to use the new i2c
binding way, let's first solve most coding style issues,
in order to avoid mixing coding style changes with code
changes.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: lgdt330x: use kernel-doc instead of inlined comments

Change the lgdt330x_config documentation to use kernel-doc
style.

No functional changes.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: em28xx: fix a regression with HVR-950

Commit be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner
functionality") removed the logic with sets the alternate for the DVB
device. Without setting the right alternate, the device won't be
able to submit URBs, and userspace fails with -EMSGSIZE:

ERROR     DMX_SET_PES_FILTER failed (PID = 0x2000): 90 Message too long

Tested with Hauppauge HVR-950 model A1C0.

Fixes: be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner functionality")

Cc: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l2-core: get rid of videobuf-dvb

Videobuf has been replaced by videobuf2. Now, no drivers use
the videobuf-dvb helper module anymore. So, get rid of it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: cx231xx: get rid of videobuf-dvb dependency

This driver doesn't use videobuf-dvb. So, stop adding an
unused struct and unused header on it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dvb-usb-v2: stop using coherent memory for URBs

There's no need to use coherent buffers there. So, let the
DVB core do the allocation. That should give some performance
gain outside x86.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dvbsky: fix driver unregister logic

There's a user-after-free there, if the frontend is attached
via the new I2C way:

[  112.539806] usbcore: deregistering interface driver dvb_usb_dvbsky
[  112.568489] ==================================================================
[  112.568600] BUG: KASAN: use-after-free in dvb_unregister_frontend+0x18/0xb0 [dvb_core]
[  112.568610] Read of size 8 at addr ffff8803a6f61530 by task rmmod/2246

[  112.568622] CPU: 0 PID: 2246 Comm: rmmod Not tainted 4.16.0-rc4+ #103
[  112.568624] Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
[  112.568625] Call Trace:
[  112.568631]  dump_stack+0x5c/0x7c
[  112.568636]  print_address_description+0x6a/0x270
[  112.568640]  kasan_report+0x258/0x380
[  112.568657]  ? dvb_unregister_frontend+0x18/0xb0 [dvb_core]
[  112.568673]  dvb_unregister_frontend+0x18/0xb0 [dvb_core]
[  112.568681]  dvb_usbv2_exit+0x156/0x4a0 [dvb_usb_v2]
[  112.568689]  dvb_usbv2_disconnect+0xa0/0x140 [dvb_usb_v2]
[  112.568694]  usb_unbind_interface+0xd8/0x3f0
[  112.568700]  device_release_driver_internal+0x1ce/0x2f0
[  112.568705]  driver_detach+0x66/0xc0
[  112.568709]  bus_remove_driver+0x86/0x150
[  112.568713]  usb_deregister+0x90/0x180
[  112.568718]  SyS_delete_module+0x293/0x330
[  112.568721]  ? free_module+0x330/0x330
[  112.568725]  ? _cond_resched+0x16/0x50
[  112.568729]  ? task_work_run+0x7d/0xd0
[  112.568732]  ? mem_cgroup_handle_over_high+0x1c/0xc0
[  112.568736]  ? free_module+0x330/0x330
[  112.568740]  do_syscall_64+0xe7/0x250
[  112.568744]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  112.568747] RIP: 0033:0x7facafa272a7
[  112.568749] RSP: 002b:00007fffdea14cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[  112.568753] RAX: ffffffffffffffda RBX: 00007fffdea14d28 RCX: 00007facafa272a7
[  112.568755] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005599557337c8
[  112.568756] RBP: 0000559955733760 R08: 000000000000000a R09: 0000000000000000
[  112.568758] R10: 00007facafaa0280 R11: 0000000000000206 R12: 00007fffdea14ef0
[  112.568761] R13: 00007fffdea16eac R14: 0000559955733260 R15: 0000559955733760

[  112.568808] Allocated by task 638:
[  112.568816]  kasan_kmalloc+0xa0/0xd0
[  112.568820]  kmem_cache_alloc_trace+0x114/0x230
[  112.568826]  m88ds3103_probe+0x9a/0x643 [m88ds3103]
[  112.568830]  i2c_device_probe+0x2e9/0x3c0
[  112.568833]  driver_probe_device+0x46e/0x6a0
[  112.568836]  bus_for_each_drv+0xd6/0x130
[  112.568838]  __device_attach+0x166/0x1f0
[  112.568841]  bus_probe_device+0xea/0x110
[  112.568844]  device_add+0x6a3/0x9f0
[  112.568847]  i2c_new_device+0x28f/0x5c0
[  112.568861]  dvb_module_probe+0x91/0x110 [dvb_core]
[  112.568867]  dvbsky_s960c_attach+0x1c4/0x460 [dvb_usb_dvbsky]
[  112.568873]  dvb_usbv2_probe+0x1191/0x1950 [dvb_usb_v2]
[  112.568877]  usb_probe_interface+0x1b3/0x430
[  112.568880]  driver_probe_device+0x46e/0x6a0
[  112.568882]  __driver_attach+0xeb/0x110
[  112.568885]  bus_for_each_dev+0xe4/0x140
[  112.568888]  bus_add_driver+0x249/0x380
[  112.568891]  driver_register+0xc6/0x170
[  112.568893]  usb_register_driver+0xec/0x200
[  112.568896]  do_one_initcall+0x8f/0x1ee
[  112.568900]  do_init_module+0xde/0x320
[  112.568902]  load_module+0x3ed0/0x4850
[  112.568905]  SYSC_finit_module+0x192/0x1c0
[  112.568908]  do_syscall_64+0xe7/0x250
[  112.568911]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

[  112.568916] Freed by task 2246:
[  112.568923]  __kasan_slab_free+0x136/0x180
[  112.568925]  kfree+0xa5/0x1e0
[  112.568931]  m88ds3103_remove+0x42/0x60 [m88ds3103]
[  112.568934]  i2c_device_remove+0x72/0xd0
[  112.568937]  device_release_driver_internal+0x1ce/0x2f0
[  112.568940]  bus_remove_device+0x197/0x270
[  112.568942]  device_del+0x239/0x550
[  112.568945]  device_unregister+0x16/0x70
[  112.568949]  dvbsky_exit+0x4c/0x70 [dvb_usb_dvbsky]
[  112.568955]  dvb_usbv2_disconnect+0x98/0x140 [dvb_usb_v2]
[  112.568958]  usb_unbind_interface+0xd8/0x3f0
[  112.568961]  device_release_driver_internal+0x1ce/0x2f0
[  112.568964]  driver_detach+0x66/0xc0
[  112.568967]  bus_remove_driver+0x86/0x150
[  112.568970]  usb_deregister+0x90/0x180
[  112.568973]  SyS_delete_module+0x293/0x330
[  112.568976]  do_syscall_64+0xe7/0x250
[  112.568979]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2

[  112.568985] The buggy address belongs to the object at ffff8803a6f61100
                which belongs to the cache kmalloc-2048 of size 2048
[  112.568998] The buggy address is located 1072 bytes inside of
                2048-byte region [ffff8803a6f61100, ffff8803a6f61900)
[  112.569008] The buggy address belongs to the page:
[  112.569015] page:ffffea000e9bd800 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
[  112.569025] flags: 0x17ffe000008100(slab|head)
[  112.569034] raw: 0017ffe000008100 0000000000000000 0000000000000000 00000001000f000f
[  112.569044] raw: ffffea000ee2d000 0000000500000005 ffff880407002a80 0000000000000000
[  112.569053] page dumped because: kasan: bad access detected

[  112.569062] Memory state around the buggy address:
[  112.569070]  ffff8803a6f61400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  112.569079]  ffff8803a6f61480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  112.569088] >ffff8803a6f61500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  112.569095]                                      ^
[  112.569103]  ffff8803a6f61580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  112.569112]  ffff8803a6f61600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[  112.569119] ==================================================================
[  112.569127] Disabling lock debugging due to kernel taint
[  112.571161] dvb_usb_v2: 'DVBSky S960CI:2-2' successfully deinitialized and disconnected

Fix it by letting the dvb-usb-v2 core to know that the frontend
was already removed.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dvbsky: use the new dvb_module_probe() API

Instead of repeating countless times a complex logic, use
the new dvb_module_probe()/dvb_module_release(), simplifying
the module.

That reduced about 15% at the module's size:

   text    data     bss     dec     hex filename
   7083    1108      12    8203    200b old/drivers/media/usb/dvb-usb-v2/dvbsky.o
   5817    1108      12    6937    1b19 new/drivers/media/usb/dvb-usb-v2/dvbsky.o

Tested with a DVBSky S960C DVB-S2 tuner (0572:960c)

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: set driver version to 0.9.33-integrated

Set DDBRIDGE_VERSION in ddbridge.h to 0.9.33-integrated to reflect the
updated driver.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: recognize and attach the MaxSX8 cards

Add needed logic into dvb_input_attach(), ddb_port_probe() and
ddb_ports_init() to initialize and support these new cards.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: add hardware defs and PCI IDs for MCI cards

Add PCI IDs and ddb_info for the new MCI-based MaxSX8 cards. Also add
needed defines so the cards can be hooked up into ddbridge's probe and
attach handling.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge/max: implement MCI/MaxSX8 attach function

Implement frontend attachment as ddb_fe_attach_mci() into the
ddbridge-max module. The MaxSX8 MCI cards are part of the Max card series
and make use of the LNB controller driven by the already existing lnb
functionality, so here's where this code belongs to.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: initial support for MCI-based MaxSX8 cards

This adds initial support for the new MCI-based (micro-code interface)
DD cards, with the first one being the MaxSX8 eight-tuner DVB-S/S2/S2X
PCIe card. The MCI is basically a generalized interface implemented in
the card's FPGA firmware and usable for all kind of cards, without the
need to implement any demod/tuner drivers as this interface "hides" any
I2C interface to the actual ICs, in other words any required driver is
implemented in the card firmware.

At this stage, the MCI interface is quite rudimentary with things like
signal statistics reporting missing, but is already working to serve
DVB streams to DVB applications. Missing functionality will be enabled
over time.

This implements only the ddbridge-mci sub-object and hooks it up to the
Makefile so the object gets build. The upcoming commits hook this module
into all other ddbridge parts where required, including device IDs etc.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: support dummy tuners with 125MByte/s dummy data stream

The Octopus V3 and Octopus Mini devices support set up of a dummy tuner
mode on port 0 that will deliver a continuous data stream of 125MBytes
per second while raising IRQs and filling the DMA buffers, which comes
handy for some stress, PCIe link and IRQ handling testing. The dummy
frontend is registered using dvb_dummy_fe's QAM dummy frontend. Set
ddbridge.dummy_tuner to 1 to enable this on the supported cards.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: make DMA buffer count and size modparam-configurable

Make the number of DMA buffers and their size configurable using module
parameters. Being able to set these to a higher number might help on
busy systems when handling overall high data rates without having to
edit the driver sources and recompile things.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: set devid entry for link 0

Currently, /sys/class/ddbridgeX/devid always reports 0 due to devid not
being set at all. Set the devid field alongside while storing all other
hardware ID data.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: fix output buffer check

A 188 byte gap has to be left between the writer and the consumer. This
requires 2*188 bytes available to be able to write to the output buffers.
So, change ddb_output_free() to report free bytes according to this rule.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: use spin_lock_irqsave() in output_work()

Make sure to save IRQ states before taking the dma lock, as already done
in it's input_work() counterpart.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: improve separated MSI IRQ handling

Improve IRQ handling in the separated MSG/I2C and IO/TSDATA handlers by
applying a mask for recognized bits immediately upon reading the IRQ mask
from the hardware, so only the bits/IRQs that actually were set will be
acked.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: add macros to handle IRQs in nibble and byte blocks

Currently, each IRQ requires one IRQ_HANDLE() line to call each IRQ
handler that was set up. Add a IRQ_HANDLE_NIBBLE() and IRQ_HANDLE_BYTE()
macro to call all handlers in blocks of four (_NIBBLE) or eight (_BYTE)
handlers at a time, to make this construct more compact.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: add helper for IRQ handler setup

Introduce the ddb_irq_set() helper function (along with a matching
prototype in ddbridge.h) to improve the set up of the IRQ handlers
and handler_data, and rework storing this data into the ddb_link
using a new ddb_irq struct. This also does the necessary rework
of affected variables. And while at it, always do queue_work in
input_handler() as there's not much of a difference to directly
calling input_work if there's no ptr at input->redi, or queueing
this call.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: request/free_irq using pci_irq_vector, enable MSI-X

Instead of trying to manage IRQ numbers on itself, utilise the
pci_irq_vector() function to do this, which will take care of correct IRQ
numbering for MSI and non-MSI IRQs. While at it, request and enable MSI-X
interrupts for hardware (boards and cards) that support this.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: move MSI IRQ cleanup to a helper function

Introduce the ddb_msi_exit() helper to be used for cleaning up previously
allocated MSI IRQ vectors. Deduplicates code and makes things look
cleaner as for all cleanup work the CONFIG_PCI_MSI ifdeffery is only
needed in the helper now. Also, replace the call to the deprecated
pci_disable_msi() function with pci_free_irq_vectors().

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: move ddb_wq and the wq+class initialisation to -core

Move the ddbridge module initialisation and cleanup code to ddbridge-core
and set up the ddb_wq workqueue there, and create and destroy the ddb
device class there aswell. Due to this, the prototypes for ddb_wq,
ddb_class_create() and ddb_class_destroy() aren't required in ddbridge.h
anymore, so remove them. Also, declare ddb_wq and the ddb_class_*()
functions static.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ddbridge: move modparams to ddbridge-core.c

Besides the 'msi' module option, all options are used from within
ddbridge-core only, so move them over from ddbridge-main, and declare the
associated variables static. Since the prototypes in ddbridge.h aren't
necessary anymore now, remove them. As a side effect, this has the benefit
of aligning things more with the dddvb upstream.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dvb-frontends/stv0910: fix CNR reporting in read_snr()

The CNR value determined in read_snr() is reported via the wrong variable.
It uses FE_SCALE_DECIBEL, which implies the value to be reported in svalue
instead of uvalue. Fix this accordingly.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dvb-frontends/stv0910: add init values for TSINSDELM/L

The TSINSDEL registers were lacking initialisation in the stv0910 demod
driver. Initialise them (both demods) in the probe() function.

Picked up from the upstream dddvb-0.9.33 release.

Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: video-i2c: get rid of two gcc warnings

After adding this driver, gcc complains with:

drivers/media/i2c/video-i2c.c:55:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
 const static struct v4l2_fmtdesc amg88xx_format = {
 ^~~~~
drivers/media/i2c/video-i2c.c:59:1: warning: 'static' is not at beginning of declaration [-Wold-style-declaration]
 const static struct v4l2_frmsize_discrete amg88xx_size = {
 ^~~~~

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

media: omap2: allow building it with COMPILE_TEST && DRM_OMAP

Now that FB_OMAP has stubs, the omap2 media drivers can be
built on ARM with COMPILE_TEST && DRM_OMAP.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

Add stubs for omapfb_dss.h, in the case it is included by
some driver when CONFIG_FB_OMAP2 is not defined, with can
happen on ARM when DRM_OMAP is not 'n'.

That allows building such driver(s) with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: ipu3: allow building it with COMPILE_TEST on non-x86 archs

Despite depending on ACPI, this driver builds fine on non-x86
archtecture with COMPILE_TEST, as it doesn't depend on
ACPI-specific functions/structs.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: rc: allow build pnp-dependent drivers with COMPILE_TEST

The pnp header already provide enough stub to build those
drivers with COMPILE_TEST on non-x86 archs.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: sta2x11_vip: allow build with COMPILE_TEST

This driver doesn't use any weird API. So, allow building it
with COMPILE_TEST.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: radio: allow building ISA drivers with COMPILE_TEST

Several radio devices only build on i386, because they depend
on ISA. Allow them to build on other archs by adding a
COMPILE_TEST check.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: flexcop-i2c: get rid of KERN_CONT

Coverity complains about werid stuff at the debug logic:

CID 113542 (#1 of 1): Out-of-bounds access (ARRAY_VS_SINGLETON)10.
callee_ptr_arith: Passing buf to function flexcop_i2c_write4
which uses it as an array. This might corrupt or misinterpret
adjacent memory locations.

Instead of directly addressing the issue there, let's rework at
the logic there.

On newer kernels, KERN_CONT does nothing, as the previous message
won't wait for a continuation. Also, both flexcop_i2c_read4() and
flexcop_i2c_write4(), called by it, will print stuff if (debug &4).

So, the way it is is too buggy.

There are two kinds of debug stuff there: deb_i2c() and a code hidden
under #ifdef DUMP_I2C_MESSAGES, with can't be selected without touching
the source code.

Also, if both debug & 0x4 and DUMP_I2C_MESSAGES, flexcop_i2c_request()
will emit two debug messages per call with different data,
with sounds messy.

Simplify it by getting rid of DUMP_I2C_MESSAGES and adding a new
flag to debug (0x40), and making the debug logic there more
consistent.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: davinci: don't override the error code

As warned by Coverity:
CID 1415211 (#1 of 1): Unused value (UNUSED_VALUE)assigned_value:
Assigning value -22 to ret here, but that stored value is
overwritten before it can be used.

On all cases where the there's a goto 'unlock_out' or 'streamof',
ret was filled with a non-sero value. It toesn't make sense to override
such error code with a videobuf_streamoff() error.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: em28xx: Don't use ops->resume if NULL

Changeset  be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD
second tuner functionality") introduced a potential NULL pointer
dereference, as pointed by Coverity:

CID 1434731 (#1 of 1): Dereference after null check (FORWARD_NULL)16. var_deref_op: Dereferencing null pointer ops->resume.

var_compare_op: Comparing ops->resume to null implies that ops->resume might be null.
1174                if (ops->resume)
1175                        ops->resume(dev);
1176                if (dev->dev_next)
1177                        ops->resume(dev->dev_next);

Fixes: be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner functionality")

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: s5p-jpeg: don't return a value on a void function

Building this driver on arm64 gives this warning:
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos3250.c:430:16: error: return expression in void function

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: siano: be sure to not override devpath size

Right now, at siano driver, all places where devpath is
defined has sizeof(devpath) == 32. So, there's no practical
risc of going past devpath array anywhere.

Still, code changes might cause troubles. It also confuses
Coverity:
CID 139059 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
9. fixed_size_dest: You might overrun the 32-character
   fixed-size string entry->devpath by copying devpath
   without checking the length.
10. parameter_as_source: Note: This defect has an
    elevated risk because the source argument
    is a parameter of the current function.

So, explicitly limit strcmp() and strcpy() to ensure that the
devpath size (32) will be respected.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: siano: get rid of __le32/__le16 cast warnings

Those are all false-positives that appear with smatch when building for
arm:

  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:38:36: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:47:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:67:35: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:84:44: warning: cast to restricted __le32
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:98:26: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:99:28: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16
  drivers/media/common/siano/smsendian.c:100:27: warning: cast to restricted __le16

Get rid of them by adding explicit forced casts.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

drivers: omap2: Kconfig: make FB_OMAP2_DSS_INIT depend on OF

Commit 7378f1149884 ("media: omap2: omapfb: allow building it with
COMPILE_TEST") broke compilation without CONFIG_OF selected.
  CC      drivers/video/fbdev/core/fbmem.o
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c: In function ‘omapdss_update_prop’:
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c:68:2: error: implicit declaration of function ‘of_update_property’; did you mean ‘of_get_property’? [-Werror=implicit-function-declaration]
  of_update_property(node, prop);
  ^~~~~~~~~~~~~~~~~~
  of_get_property
cc1: some warnings being treated as errors
scripts/Makefile.build:312: recipe for target 'drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o' failed
make[7]: *** [drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.o] Error 1
scripts/Makefile.build:559: recipe for target 'drivers/video/fbdev/omap2/omapfb/dss' failed
make[6]: *** [drivers/video/fbdev/omap2/omapfb/dss] Error 2
make[6]: *** Waiting for unfinished jobs....

Add OF dependency in order to make all configurations work again.

of_update_property() has no inline stub, and that that could be added as
an alternative.

Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: rc: probe zilog transmitter when zilog receiver is found

Both Hauppauge WinTV 44981 (bt878) and the HVR 1110 (saa7134) have a Zilog
Z8F0811. The transmitter was not probed. Receive and transmit tested on
both cards.

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

media: rc: imon decoder: support the stick

The iMON PAD controller has a analog stick, which can be switched to
keyboard mode (cursor keys) or work as a crappy mouse.

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

media: rc: only register protocol for rc device if enabled

The raw_register function exists to create input devices associated with
that IR protocol.

If the mce_kbd module is loaded, then every rc device will have mce_kbd
input devices, even if the protocol is not enabled. Change this to call
the register function to when the protocol is enabled.

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

media: v4l: vsp1: Rename BRU to BRx

Some VSP instances have two blending units named BRU (Blend/ROP Unit)
and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU
with only two inputs, but otherwise offers similar features and offers
the same register interface. The BRU and BRS can be used exchangeably in
VSP pipelines (provided no more than two inputs are needed).

Due to historical reasons, the VSP1 driver implements support for both
the BRU and BRS through objects named vsp1_bru. The code uses the name
BRU to refer to either the BRU or the BRS, except in a few places where
noted explicitly. This creates confusion.

In an effort to avoid confusion, rename the vsp1_bru object and the
corresponding API to vsp1_brx, and use BRx to refer to blend unit
instances regardless of their type. The names BRU and BRS are retained
where reference to a particular blend unit type is needed, as well as in
hardware registers to stay close to the datasheet.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Add BRx dynamic assignment debugging messages

Dynamic assignment of the BRU and BRS to pipelines is prone to
regressions, add messages to make debugging easier. Keep it as a
separate commit to ease removal of those messages once the code will
deem to be completely stable.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Assign BRU and BRS to pipelines dynamically

The VSPDL variant drives two DU channels through two LIF and two
blenders, BRU and BRS. The DU channels thus share the five available
VSPDL inputs and expose them as five KMS planes.

The current implementation assigns the BRS to the second LIF and thus
artificially limits the number of planes for the second display channel
to two at most.

Lift this artificial limitation by assigning the BRU and BRS to the
display pipelines on demand based on the number of planes used by each
pipeline. When a display pipeline needs more than two inputs and the BRU
is already in use by the other pipeline, this requires reconfiguring the
other pipeline to free the BRU before processing, which can result in
frame drop on both pipelines.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Generalize detection of entity removal from DRM pipeline

When disabling a DRM plane, the corresponding RPF is only marked as
removed from the pipeline in the atomic update handler, with the actual
removal happening when configuring the pipeline at atomic commit time.
This is required as the RPF has to be disabled in the hardware, which
can't be done from the atomic update handler.

The current implementation is RPF-specific. Make it independent of the
entity type by using the entity's pipe pointer to mark removal from the
pipeline. This will allow using the mechanism to remove BRU instances.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Add per-display list internal completion notification support

Display list completion is already reported to the frame end handler,
but that mechanism is global to all display lists. In order to implement
BRU and BRS reassignment in DRM pipelines we will need to commit a
display list and wait for its completion internally, without reporting
it to the DRM driver. Extend the display list API to support such an
internal use of the display list.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Turn frame end completion status into a bitfield

We will soon need to return more than a boolean completion status from
the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a
bitfield to prepare for that. No functional change is introduced here.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Move DRM pipeline output setup code to a function

In order to make the vsp1_du_setup_lif() easier to read, and for
symmetry with the DRM pipeline input setup, move the pipeline output
setup code to a separate function.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Replace manual DRM pipeline input setup in vsp1_du_setup_lif

The vsp1_du_setup_lif() function sets up the DRM pipeline input
manually. This duplicates the code from the
vsp1_du_pipeline_setup_inputs() function. Replace the manual
implementation by a call to the function.

As the pipeline has no enabled input in vsp1_du_setup_lif(), the
vsp1_du_pipeline_setup_inputs() function will not setup any RPF, and
will thus not setup formats on the BRU sink pads. This isn't a problem
as all inputs are disabled, and the BRU sink pads will be reconfigured
from the atomic commit handler when inputs will be enabled.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Setup BRU at atomic commit time

To implement fully dynamic plane assignment to pipelines, we need to
reassign the BRU and BRS to the DRM pipelines in the atomic commit
handler. In preparation for this setup factor out the BRU source pad
code and call it both at LIF setup and atomic commit time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

The DRM pipeline setup code used at atomic commit time is similar to the
setup code used when enabling the pipeline. Move it to a separate
function in order to share it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Share duplicated DRM pipeline configuration code

Move the duplicated DRM pipeline configuration code to a function and
call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush().

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

The DRM pipeline handling code uses the entity's pipe list head to check
whether the entity is already included in a pipeline. This method is a
bit fragile in the sense that it uses list_empty() on a list_head that
is a list member. Replace it by a simpler check for the entity pipe
pointer.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Store pipeline pointer in vsp1_entity

Various types of objects subclassing vsp1_entity currently store a
pointer to the pipeline. Move the pointer to vsp1_entity to simplify the
code and avoid storing the pipeline in more entity subclasses later.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure

The vsp1_drm_pipeline enabled field is set but never used. Remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: vsp1: Don't start/stop media pipeline for DRM

The DRM support code manages a pipeline of VSP entities, each backed by
a media entity. When starting or stopping the pipeline, it starts and
stops the media pipeline through the media API in order to store the
pipeline pointer in every entity.

The driver doesn't use the pipe pointer in media entities, neither does
it rely on the other effects of the media_pipeline_start() and
media_pipeline_stop() functions. Furthermore, as the media links for the
DRM pipeline are never set up correctly, and as the pipeline can be
modified dynamically when enabling or disabling planes, the current
implementation is not correct. Remove the incorrect and unneeded code.

While at it remove the outdated comment that states that entities are
not started when the LIF is setup, as they now are.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: usbtv: Use the constant for supported standards

Use the USBTV_TV_STD define instead of repeating ourselves.

Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: usbtv: Enforce standard for color decoding

Depending on the chosen standard, configure the decoder to use the
appropriate color encoding standard (PAL-like, NTSC-like or SECAM).

Until now, the decoder was not configured for a specific color standard,
making it autodetect the color encoding.

While this may sound fine, it potentially causes the wrong image tuning
parameters to be applied (e.g. tuning parameters for NTSC are applied to
a PAL source), and may confuse users about what the actual standard is
in use.

This commit explicitly configures the color standard the decoder will
use, making it visually obvious if a wrong standard was chosen.

Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: usbtv: Keep norm parameter specific

The user-supplied norm value gets overwritten by the generic .norm
member from the norm_params. That way, we lose the specific norm the
user may want to set.

For instance, if the user specifies V4L2_STD_PAL_60, the value actually
used will be V4L2_STD_525_60, which in the end will be as if the user
had specified V4L2_STD_NTSC, since this is always the first bitfield we
match the norm value against before configuring the hardware.

The norm_params array is only there to match a norm with an output
resolution. The norm value itself should not be changed.

Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: usbtv: Use V4L2 defines to select capture resolution

Make use of the V4L2_STD_525_60 and V4L2_STD_625_50 defines to
determine the vertical resolution to use when capturing.

V4L2_STD_525_60 (resp. V4L2_STD_625_50) is the set of standards using
525 (resp. 625) lines per frame, independently of the color encoding.

Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: usbtv: Add SECAM support

Add support for the SECAM norm, using the "AVSECAM" decoder configuration
sequence found in Windows driver's .INF file.

For reference, the "AVSECAM" sequence in the .INF file is:
0x04,0x73,0xDC,0x72,0xA2,0x90,0x35,0x01,0x30,0x04,0x08,0x2D,0x28,0x08,
0x02,0x69,0x16,0x35,0x21,0x16,0x36

Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: usbtv: Use same decoder sequence as Windows driver

Re-format the register {address, value} pairs so they follow the same
order as the decoder configuration sequences in the Windows driver's .INF
file.

For instance, for PAL, the "AVPAL" sequence in the .INF file is:
0x04,0x68,0xD3,0x72,0xA2,0xB0,0x15,0x01,0x2C,0x10,0x20,0x2e,0x08,0x02,
0x02,0x59,0x16,0x35,0x17,0x16,0x36

Signed-off-by: Hugo Grostabussiat <bonstra@bonstra.fr.eu.org>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: video-i2c: add video-i2c driver

There are several thermal sensors that only have a low-speed bus
interface but output valid video data. This patchset enables support
for the AMG88xx "Grid-Eye" sensor family.

Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
[hans.verkuil@cisco.com: split up int ret = ...->xfer(); line]
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: dt-bindings: Add bindings for panasonic,amg88xx

Define the device tree bindings for the panasonic,amg88xx i2c
video driver.

Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: staging: tegra-vde: Correct included header

This is Open Firmware driver, hence 'of_device.h' should be included
instead of 'platform_device.h'. Right now OF headers happen to be included
indirectly and this may break in the future, so let's correct the header.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: staging: tegra-vde: Do not handle spurious interrupts

Do not handle interrupts if we haven't asked for them, potentially that
could happen if HW wasn't programmed properly.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: staging: tegra-vde: Correct minimum size of U/V planes

Stride of U/V planes must be aligned to 16 bytes (2 macroblocks). This
needs to be taken into account, otherwise it is possible to get a silent
memory corruption if dmabuf size is less than the size of decoded video
frame.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: staging: tegra-vde: Silence some of checkpatch warnings

Make all strings single line to make them grep'able and add a comment
to the memory barrier.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: staging: tegra-vde: Align bitstream size to 16K

I've noticed that decoding fails sometime if size of bitstream buffer
isn't aligned to 16K, probably because HW fetches data from memory in
a 16K granularity and if the last chunk of data isn't aligned, HW reads
garbage data beyond the dmabuf and tries to parse it.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

media: v4l: fwnode: Fix comment incorrectly mentioning v4l2_fwnode_parse_endpoint

It's called v4l2_fwnode_endpoint_parse, not v4l2_fwnode_parse_endpoint.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: tda1997x: Use bitwise or for setting subdev flags

Assigning subdev flags in probe() after v4l2_i2c_subdev_init() clears the
I2C flag set by that function. Fix this by using bitwise or instead.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: ov7740: Set subdev HAS_EVENT flag

The driver has event support implemented but fails to set the flag
enabling event support. Set the flag to enable control events.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: ov7740: Fix control handler error at the end of control init

Check that no error happened during adding controls to the driver's
control handler. Print an error message and bail out if there was one.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: ov7740: Check for possible NULL return value in control creation

Check that creating the control actually succeeded before accessing it.
A failure would lead to NULL pointer reference. Fix this.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: ov7740: Fix number of controls hint

The driver has 12 controls, not 2.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap3isp: make omap3isp_prev_csc and omap3isp_prev_rgbtorgb const

Make these const as they are only used as a copy operation.

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: v4l: omap3isp: make v4l2_file_operations const

Make this const as it is only stored in a const field of a
video_device structure.

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: sound, isapnp: allow building more drivers with COMPILE_TEST

Drivers that depend on ISAPNP currently can't be built with
COMPILE_TEST. However, looking at isapnp.h, there are already
stubs there to allow drivers to include it even when isa
PNP is not supported.

So, remove such dependencies when COMPILE_TEST.

Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: sound, media: allow building ISA drivers it with COMPILE_TEST

All sound drivers that don't depend on PNP can be safelly
build with COMPILE_TEST, as ISA provides function stubs to
be used for such purposes.

As a side effect, with this change, the radio-miropcm20
can now be built outside i386 with COMPILE_TEST.

It should be noticed that ISAPNP currently depends on ISA.
So, on drivers that depend on it, we need to add an
explicit dependency on ISA, at least until another patch
removes it.

Acked-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap3isp: Allow it to build with COMPILE_TEST

There aren't much things required for it to build with COMPILE_TEST.
It just needs to not compile the code that depends on arm-specific
iommu implementation.

Co-developed-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap3isp: Enable driver compilation on ARM with COMPILE_TEST

The omap3isp driver can't be compiled on non-ARM platforms but has no
compile-time dependency on OMAP. It however requires common clock
framework support, which isn't provided by all ARM platforms.

Drop the OMAP dependency when COMPILE_TEST is set and add ARM and
COMMON_CLK dependencies.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: omap: omap-iommu.h: allow building drivers with COMPILE_TEST

Drivers that depend on omap-iommu.h (currently, just omap3isp)
need a stub implementation in order to be built with COMPILE_TEST.

Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: enable support for r8a77970

Add the SoC specific information for Renesas r8a77970.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: enable support for r8a7796

Add the SoC specific information for Renesas r8a7796.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: enable support for r8a7795

Add the SoC specific information for Renesas r8a7795 ES1.x and ES2.0.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: extend {start, stop}_streaming to work with media controller

The procedure to start or stop streaming using the non-MC single
subdevice and the MC graph and multiple subdevices are quite different.
Create a new function to abstract which method is used based on which
mode the driver is running in and add logic to start the MC graph.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: add link notify for Gen3

Add the ability to process media device link change requests. Link
enabling is a bit complicated on Gen3, whether or not it's possible to
enable a link depends on what other links already are enabled. On Gen3
the 8 VINs are split into two subgroup's (VIN0-3 and VIN4-7) and from a
routing perspective these two groups are independent of each other.
Each subgroup's routing is controlled by the subgroup VIN master
instance (VIN0 and VIN4).

There are a limited number of possible route setups available for each
subgroup and the configuration of each setup is dictated by the
hardware. On H3 for example there are 6 possible route setups for each
subgroup to choose from.

This leads to the media device link notification code being rather large
since it will find the best routing configuration to try and accommodate
as many links as possible. When it's not possible to enable a new link
due to hardware constrains the link_notifier callback will return
-EMLINK.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: parse Gen3 OF and setup media graph

The parsing and registering CSI-2 subdevices with the v4l2 async
framework is a collaborative effort shared between the VIN instances
which are part of the group. When the last VIN in the group is probed it
asks all other VINs to parse its share of OF and record the async
subdevices it finds in the notifier belonging to the last probed VIN.

Once all CSI-2 subdevices in this notifier are bound proceed to register
all VIN video devices of the group and crate media device links between
all CSI-2 and VIN entities according to the SoC specific routing
configuration.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: add chsel information to rvin_info

Each Gen3 SoC has a limited set of predefined routing possibilities for
which CSI-2 device and channel can be routed to which VIN instance.
Prepare to store this information in the struct rvin_info.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: change name of video device

The rcar-vin driver needs to be part of a media controller to support
Gen3. Give each VIN instance a unique name so it can be referenced from
userspace.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: add group allocator functions

In media controller mode all VIN instances needs to be part of the same
media graph. There is also a need for each VIN instance to know about
and in some cases be able to communicate with other VIN instances.

Add an allocator framework where the first VIN instance to be probed
creates a shared data structure and registers a media device.
Consecutive VINs insert themself into the global group.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: prepare for media controller mode initialization

Prepare for media controller by calling a different initialization then
when running in device centric mode. Add trivial configuration of
the mbus and creation of the media pad for the video device entity.

While we are at it clearly mark the digital device centric notifier
functions with a comment.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: force default colorspace for media centric mode

The V4L2 specification clearly documents the colorspace fields as being
set by drivers for capture devices. Using the values supplied by
userspace thus wouldn't comply with the API. Until the API is updated to
allow for userspace to set these Hans wants the fields to be set by the
driver to fixed values.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: use different v4l2 operations in media controller mode

When the driver runs in media controller mode it should not directly
control the subdevice instead userspace will be responsible for
configuring the pipeline. To be able to run in this mode a different set
of v4l2 operations needs to be used.

Add a new set of v4l2 operations to support operation without directly
interacting with the source subdevice.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>

media: rcar-vin: add flag to switch to media controller mode

On Gen3 a media controller API needs to be used to allow userspace to
configure the subdevices in the pipeline instead of directly controlling
a single source subdevice, which is and will continue to be the mode of
operation on Gen2.

Prepare for these two modes of operation by adding a flag to struct
rvin_info which will control which mode to use.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>