media: atomisp: get rid of -Wsuggest-attribute=format warnings

There are some warnings reported by gcc:
drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:164:2: warning: function ‘atomisp_css2_dbg_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:170:2: warning: function ‘atomisp_css2_dbg_ftrace_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:170:2: warning: function ‘atomisp_css2_dbg_ftrace_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
drivers/staging/media/atomisp//pci/atomisp_compat_css20.c:176:2: warning: function ‘atomisp_css2_err_print’ might be a candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
drivers/staging/media/atomisp/pci/sh_css.c:1685:16: warning: assignment left-hand side might be a candidate for a format attribute [-Wsuggest-attribute=format]

That are due to the usage of printf-like messages without
enabling the error checking logic.

Add the proper attributes in order to shut up such warnings.

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

media: atomisp: move a static constant out of a header file

Gcc reports that input_formatter_alignment is not used:

In file included from ./drivers/staging/media/atomisp//pci/hive_isp_css_include/input_formatter.h:34,
                 from drivers/staging/media/atomisp//pci/runtime/debug/src/ia_css_debug.c:55:
./drivers/staging/media/atomisp//pci/hive_isp_css_common/host/input_formatter_local.h:118:27: warning: ‘input_formatter_alignment’ defined but not used [-Wunused-const-variable=]

However, it is, but only inside input_formatter.c.

So, move it out of the header file.

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

media: atomisp: get rid of unused vars

There are several vars declared and set but unused:

drivers/staging/media/atomisp//pci/sh_css_param_shading.c:239:4: warning: variable ‘padded_width’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:1366:24: warning: variable ‘stream’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:2702:22: warning: variable ‘capture_pipe’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:2831:7: warning: variable ‘continuous’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:3534:15: warning: variable ‘num_output_pins’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:3937:55: warning: variable ‘vf_pp_binary’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:3937:38: warning: variable ‘preview_binary’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:3937:24: warning: variable ‘copy_binary’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:3936:26: warning: variable ‘me’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:5749:24: warning: variable ‘copy_binary’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:6013:7: warning: variable ‘continuous’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:6012:7: warning: variable ‘memory’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:7329:24: warning: variable ‘copy_binary’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:7459:26: warning: variable ‘num_vf_pp_stage’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css.c:10420:22: warning: variable ‘pipe_id’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css_params.c:1099:36: warning: variable ‘row_padding’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/sh_css_mipi.c:410:27: warning: variable ‘mipi_intermediate_info’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/atomisp_cmd.c:2814:31: warning: variable ‘stream_config’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/atomisp_cmd.c:2893:31: warning: variable ‘stream_config’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/isp/kernels/dvs/dvs_1.0/ia_css_dvs.host.c:237:31: warning: variable ‘isp_data_ptr’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c:119:28: warning: variable ‘ver_num_isp’ set but not used [-Wunused-but-set-variable]
drivers/staging/media/atomisp//pci/isp/kernels/sdis/sdis_2/ia_css_sdis2.host.c:119:15: warning: variable ‘hor_num_isp’ set but not used [-Wunused-but-set-variable]

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

media: atomisp: print a warning if error while setting downscaler

As warned by gcc:

    drivers/staging/media/atomisp//pci/isp/kernels/dvs/dvs_1.0/ia_css_dvs.host.c:237:31: warning: variable ‘isp_data_ptr’ set but not used [-Wunused-but-set-variable]

ia_css_vf_configure() logic has an error var that detects troubles
when setting the kernel for downscaling. The driver just ignores
it, without producing any warning. Add at least a warning message
on such cases.

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

media: atomisp: get rid of some cleanup leftovers

The code that used to check for ISP2400/2401 version were
using the revision number in order to decide wheather
version should be used. With the new version, the code
doesn't need to check anymore for ISP version.

Fixes: ca133c395f2f ("media: atomisp: improve device detection code")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: vivid: fix error path

If something fails after calling v4l2_device_register(),
it should call v4l2_device_put().

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

media: vivid: move the devnode creation logic to a separate function

In order to reduce even further the size of the big
vivid_create_instance() function, let's place the part of the
logic which creates the device nodes into a separate function.

    With this and the past patches, those warnings finally
    vanishes:

            drivers/media/test-drivers/vivid/vivid-core.c: drivers/media/test-drivers/vivid/vivid-core.c:1189 vivid_create_instance() parse error: turning off implications after 60 seconds
            drivers/media/test-drivers/vivid/vivid-core.c: drivers/media/test-drivers/vivid/vivid-core.c:1257 vivid_create_instance() parse error: __split_smt: function too hairy.  Giving up after 303 seconds

The init code also seems more organized after breaking the long
function into a smaller set.

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

media: vivid: move the create queues to a separate function

Instead of placing everything inside vivid_create_instance(),
we can move the part which creates per-type video queues
into a separate function.

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

media: vivid: place dt timings init code on a separate function

Move those out of the big vivid_create_instance() function.

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

media: vivid: move set_capabilities logic to a separate function

Move such logic from vivid_create_instance(), as otherwise
smatch takes forever.

The vivid_create_instance() is still a too big for my taste.
So, further cleanups are still needed.

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

media: vivid: place the logic which disables ioctl on a separate function

Move this code out of the long vivid_create_instance() function.

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

media: vivid: move the detection part out of vivid_create_instance

The vivid_create_instance() function is too harry. Smatch can't
process it, because it takes too long.

The detection part is an important piece of it. As such, there
are even comments before and after such block.

So, it makes sense to just move it to a separate function.

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

media: rc: rename ir_lirc_* functions to lirc_*

Remove pointless ir_ prefix.

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

media: rc: harmonize infrared durations to microseconds

rc-core kapi uses nanoseconds for infrared durations for receiving, and
microseconds for sending. The uapi already uses microseconds for both,
so this patch does not change the uapi.

Infrared durations do not need nanosecond resolution. IR protocols do not
have durations shorter than about 100 microseconds. Some IR hardware offers
250 microseconds resolution, which is sufficient for most protocols.
Better hardware has 50 microsecond resolution and is enough for every
protocol I am aware off.

Unify on microseconds everywhere. This simplifies the code since less
conversion between microseconds and nanoseconds needs to be done.

This affects:
 - rx_resolution member of struct rc_dev
 - timeout member of struct rc_dev
 - duration member in struct ir_raw_event

Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Patrick Lerda <patrick9876@free.fr>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: "David Härdeman" <david@hardeman.nu>
Cc: Benjamin Valentin <benpicco@googlemail.com>
Cc: Antti Palosaari <crope@iki.fi>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rc: rename lirc char dev region to "lirc"

BaseRemoteCtl is not descriptive.

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

media: dvb_usb_pctv452e: use ISL6423 voltage regulator per default

Both TT-connect S2-3600 and Pinnacle PCTV Sat HDTV are using
Intersil ISL6423 as LNB voltage regulator. This makes
TT-connect S2-3650 CI the only device which uses STM LNBP22 regulator
which is currently used for all devices driven by pctv452e driver.

This patch fixes this by creating an exception for TT-connect S2-3650 CI
to continue to use STM LNBP22 while all others now using correct ISL6423
driver which makes DiSEqC/EN50494 comands which involve voltage changes
now working on the other devices (which didn't work before).

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

media: mxl5xx: remove unused including <linux/version.h>

Fix the following versioncheck warning:

drivers/media/dvb-frontends/mxl5xx.c:30:1: unused including
<linux/version.h>

Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: cleanup isys_irq headers

Don't need to declare those functions with extern:
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:51:35:  warning: function 'isys_irqc_state_dump' with external linkage has definition
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:68:35:  warning: function 'isys_irqc_reg_store' with external linkage has definition
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq_private.h:85:39:  warning: function 'isys_irqc_reg_load' with external linkage has definition
drivers/staging/media/atomisp/pci/css_2401_system/host/isys_irq.c:31:35:  warning: function 'isys_irqc_status_enable' with external linkage has definition

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

media: atomisp: fix some bad indents

As smatch reports, there are several bad indents:

    drivers/staging/media/atomisp/pci/hmm/hmm.c:271 hmm_alloc() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/bufq/src/bufq.c:390 ia_css_bufq_enqueue_psys_event() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/debug/src/ia_css_debug.c:2132 ia_css_debug_dump_isys_state() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:246 sh_css_binary_get_sc_requirements() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/runtime/binary/src/binary.c:565 ia_css_binary_get_shading_info_type_1() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/sh_css.c:5109 sh_css_pipes_stop() warn: inconsistent indenting
    drivers/staging/media/atomisp/pci/sh_css.c:8791 ia_css_pipe_create() warn: inconsistent indenting

Some of them are due to ifdefs. Get rid of them by either getting
a common code that would work for both ISP2400 and ISP2401 or
by creating separate functions, one for each ISP version.

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

media: atomisp: remove compile-time tests from input_system_global.h

Now that there's no duplication between ISP2400 and ISP2401
input system functions, we can include both at the system
global.

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

media: atomisp: reorder functions at pixelgen_private.h

Reorder functions in order to declare before usage.

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

media: atomisp: de-duplicate names at *_input_system_global.h

There are some duplicated names between the ISP2401 and ISP2400
for the input system, with different meanings.

In order to avoid ubiquity, let's prepend those with the
name of the ISP.

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

media: atomisp: unify INPUT error return type

There is a typedef for INPUT errors. This is different between
ISP2401 and ISP2400. Place both at the same struct, at the
global header file.

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

media: atomisp: don't check for ISP version for includes

As there aren't duplicated names anymore, and the end goal
is to do runtime checks between ISP2400 and ISP2401,
remove the part of the Makefile which changes the include
places based on the compile-time version.

This shouldn't cause any effect, but it will make easier
for further patches meant to remove conditional compiler
decisions between ISP versions to be replaced by
runtime ones.

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

media: atomisp: get rid of ibuf_ctrl abstraction

Just move the stuff there to the places where this header is
included.

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

media: atomisp: get rid of isys_dma.h and isys_dma_local.h

There aren't much on this abstraction. Just move the defines
to isys_dma_private.h and isys_dma_public.h, cleaning up
the includes.

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

media: atomisp: get rid of version-dependent globals

Replace all occurrences along the atomisp tree for the conditional
compilation macros found at system_global.h, replacing them by
tests wheather ISP2401 is defined or not.

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

media: atomisp: cleanup ifdefs from ia_css_debug.c

There are lots of code dependency there. Get rid of most of
them.

We can't remove everything, as there are some structs that
are conditionally built if ISP2401. So, keep ifdefs only
on such cases.

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

media: atomisp: get rid of some unused code

Now that the defines which are common for both ISP2400 and ISP2401
are at system_global.h, we can get rid of the code not used by
those versions.

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

media: atomisp: csi_rx.c: add missing includes

Due to that, smatch warns with:

drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:18:11:  warning: symbol 'N_SHORT_PACKET_LUT_ENTRIES' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:24:11:  warning: symbol 'N_LONG_PACKET_LUT_ENTRIES' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:30:11:  warning: symbol 'N_CSI_RX_FE_CTRL_DLANES' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/csi_rx.c:37:11:  warning: symbol 'N_CSI_RX_BE_SID_WIDTH' was not declared. Should it be static?
drivers/staging/media/atomisp/pci/css_2401_system/host/ibuf_ctrl.c:19:11:  warning: symbol 'N_IBUF_CTRL_PROCS' was not declared. Should it be static?

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

media: atomisp: atomisp_gmin_platform: check before use

solve this smatch warning:
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c:842 gmin_v1p8_ctrl() warn: variable dereferenced before check 'gs' (see line 832)

By moving the check to happen before its usage.

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

media: atomisp: fix casts at atomisp_compat_ioctl32.c

There are several warnings reported by sparse with regards to wrong
typecasts:

    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13:     expected void *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:73:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:247:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:248:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:249:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:250:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30:  warning: incorrect type in argument 2 (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30:     expected void const *from
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:282:30:     got struct atomisp_3a_statistics [noderef] __user *kp
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:308:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13:     expected void [noderef] __user *effective_width
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:327:13:     got unsigned int [usertype] *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13:     expected void [noderef] __user *effective_width
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:348:13:     got unsigned int [usertype] *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13:     expected unsigned int [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:372:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13:     expected struct v4l2_framebuffer *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:433:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13:     expected void [noderef] __user *frame
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:462:13:     got struct v4l2_framebuffer *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13:     expected unsigned short *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:496:13:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13:     expected void [noderef] __user *calb_grp_values
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:511:13:     got unsigned short *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21:     expected unsigned short [usertype] *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:630:21:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:  warning: cast removes address space '__user' of expression
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:  warning: incorrect type in initializer (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:     expected struct <noident> [noderef] __user *karg
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:715:27:     got void *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:721:39:  warning: cast removes address space '__user' of expression
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21:  warning: incorrect type in argument 1 (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21:     expected void const volatile [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:21:     got unsigned int [usertype] *src
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43:     expected void *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:725:43:     got void [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21:     expected struct atomisp_shading_table *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:741:21:     got struct atomisp_shading_table [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21:     expected struct atomisp_morph_table *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:747:21:     got struct atomisp_morph_table [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21:     expected struct atomisp_dis_coefficients *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:753:21:     got struct atomisp_dis_coefficients [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14:     expected struct atomisp_dvs_6axis_config *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:760:14:     got struct atomisp_dvs_6axis_config [noderef] __user *
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13:  warning: incorrect type in assignment (different address spaces)
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13:     expected struct atomisp_sensor_ae_bracketing_lut_entry *__pu_val
    drivers/staging/media/atomisp/pci/atomisp_compat_ioctl32.c:817:13:     got void [noderef] __user *

Use the same strategies used at v4l2-compat32.c, in order to
solve them and avoid warnings.

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

media: saa7134: avoid a shift overflow

As reported by smatch:
drivers/media/pci/saa7134//saa7134-tvaudio.c:686 saa_dsp_writel() warn: should 'reg << 2' be a 64 bit type?

On a 64-bits Kernel, the shift might be bigger than 32 bits.

In real, this should never happen, but let's shut up the warning.

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

media: dvb-ttusb-budget: cleanup printk logic

Instead of calling printk(), use pr_foo() macros.

While here, do some cleanup at the printed messages, as some
has __func__, while others have the module name (sometimes
spelled as "ttusb_dvb").

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

media: dvb-ttusb-budget: don't use stack for USB transfers

As reported by smatch:

    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:311 ttusb_boot_dsp() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:321 ttusb_boot_dsp() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:330 ttusb_boot_dsp() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:351 ttusb_set_channel() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:361 ttusb_del_channel() error: doing dma on the stack (b)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:412 ttusb_init_controller() error: doing dma on the stack (b0)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:416 ttusb_init_controller() error: doing dma on the stack (b1)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:422 ttusb_init_controller() error: doing dma on the stack (b2)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:425 ttusb_init_controller() error: doing dma on the stack (b3)
    drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:430 ttusb_init_controller() error: doing dma on the stack (get_version)

This driver still uses the USB stack for DMA transfers,
which is broken for a long time. I almost dropped this driver,
as there's a high chance that nobody is using it with upstream
Kernels, as we didn't receive any bug reports.

As fixing this won't be hard, I ended opting to fix.

While here, I dropped an ugly hack that implemented read via
a separate function that was just doing a memcpy().

It should be noticed that, during the init phase, there's
a "b4" register that were never initialized, as its buffer
were used just to store the results of "b3" initialization.

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

media: saa7134-alsa.c: number of pages should be unsigned long

As reported by smatch:

drivers/media/pci/saa7134/saa7134-alsa.c:267 saa7134_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.

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

media: cx88-alsa: number of pages should be unsigned long

As reported by smatch:

drivers/media/pci/cx88/cx88-alsa.c:286 cx88_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.

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

media: cx23885-alsa: number of pages should be unsigned long

As reported by smatch:

drivers/media//pci/cx23885/cx23885-alsa.c:83 cx23885_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.

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

media: cx25821-alsa: number of pages should be unsigned long

As reported by smatch:

drivers/media/pci/cx25821/cx25821-alsa.c:146 cx25821_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?

the number of patches should be unsigned long.

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

media: videobuf-dma-sg: number of pages should be unsigned long

As reported by smatch:

drivers/media/v4l2-core/videobuf-dma-sg.c:245 videobuf_dma_init_kernel() warn: should 'nr_pages << 12' be a 64 bit type?

The printk should not be using %d for the number of pages.

After looking better, the real problem here is that the
number of pages should be long int.

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

media: serial_ir: use the right type for a dma address

As warned by smatch:
drivers/media/rc/serial_ir.c:550 serial_ir_probe() warn: should '8 << ioshift' be a 64 bit type?

the "8" constant should be unsigned long.

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

media: tda10021: avoid casts when using symbol_rate

The usage of castings and float point when checking for
the setup based at the symbol_rate cause those warnings
with smatch:

drivers/media/dvb-frontends/tda10021.c:153 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:155 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:157 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:159 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.

While the code should work with gcc, as it will evaluate the
values into a constant before compiling, other compilers
could do otherwise. So, get rid of float pointing math on it,
avoiding the need of doing typecasts.

While here, cleanup some coding style issues at the related
code.

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

media: venus: place extern venus_fw_debug on a header file

Sparse warns about this symbol:

drivers/media/platform/qcom/venus/hfi_venus.c:133:5:  warning: symbol 'venus_fw_debug' was not declared. Should it be static?

Because hfi_venus.c doesn't include a header file with the
extern. So, move it to core.h, with is included by both
hfi_venus.c and dbgfs.c.

This way, if something changes with it, warnings or errors
will be produced.

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

media: wl128x: get rid of a potential spectre issue

As reported by smatch:
drivers/media/radio/wl128x/fmdrv_common.c:736 fm_irq_handle_rdsdata_getcmd_resp() warn: potential spectre issue 'rds_fmt.data.groupdatabuff.buff>

Address it by using array_index_nospec().

While here, reorder the linux/ includes.

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

media: av7110_v4l: avoid a typecast

While smatch reports an issue there:

drivers/media/pci/ttpci/av7110_v4l.c:163 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.
drivers/media/pci/ttpci/av7110_v4l.c:165 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.

The logic is actually fine. Yet, removing the typecast
shuts up smatch and makes the code more readable.

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

media: qt1010: fix usage of unititialized value

As pointed by smatch:

drivers/media/tuners/qt1010.c:239 qt1010_init_meas1() error: uninitialized symbol 'val2'.
drivers/media/tuners/qt1010.c:273 qt1010_init_meas2() error: uninitialized symbol 'val'.

The logic is ok, but it is hard for static analyzers
to parse it, as it depends on a value read in the middle
of a loop.

Also, it takes a while for humans to verify.

Re-write the first function to use a more direct way.

At the second one, I opted to just initialize the read var,
in order to shut up the report.

While here, address a few coding style issues at the
function code.

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

media: tda10086: cleanup symbol_rate setting logic

The original logic had an integer to unsigned integer
conversion, plus a float-point math. While gcc should be
able to do the match at compile time, other compilers might
not do the same. Also, those produce the following warnings
with static code analyzers:

drivers/media/dvb-frontends/tda10086.c:300 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:303 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:306 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:309 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:312 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:315 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:318 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:321 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:324 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:327 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.

Change the logic to declare the reference constant as unsigned
and to not use float point math.

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

media: atomisp: fix "dubious: !x | !y" sparse warning

Upon running Sparse, "warning: dubious: !x | !y" is brought to notice
for this file.  Logical and bitwise OR are basically the same in this
context, so it doesn't cause a runtime bug.  But let's change it to
logical OR to make it a little bit cleaner and silence the Sparse
warning.

Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: Avoid comma separated statements

Use semicolons and braces.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix memleak in ia_css_stream_create

When aspect_ratio_crop_init() fails, curr_stream needs
to be freed just like what we've done in the following
error paths. However, current code is returning directly
and ends up leaking memory.

Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix spelling mistake "unsupport" -> "unsupported"

There are spelling mistakes in some dev_err messages. Fix these.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: move null check to earlier point

`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.

In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:

  /* Acquired here --------v */
  struct gmin_subdev *gs = find_gmin_subdev(subdev);

  /*  v------Dereferenced here */
  if (gs->v2p8_gpio >= 0) {
      ...
  }

With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.

Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: mt9m114: replace fixed function names

There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.

Replace them:

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+       v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");

WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+       v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");

Signed-off-by: Juan Antonio Aldea-Armenteros <juant.aldea@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix code style issues

Fix warnings and errors generated after running checkpatch.pl on pci/sh_css_firmware.c.

Signed-off-by: Rohit K Bharadwaj <bharadwaj.rohit8@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: Replace deprecated MSI APIs

Replace deprecated MSI IRQ enabler and disabler
with pci_alloc_irq_vectors and pci_free_irq_vectors respectively.
And as a result handle the returned error as appropriate.
Compile tested.

[mchehab: solved a merge conflict that renamed dev->pdev]

Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fix identation at I2C Kconfig menu

There are several bad whitespacing usage there. Remove them.

While here, place all Kconfig options for sensors at the
same place.

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

media: atomisp: fix a brace coding sytle issue

Removed braces in 'if else' condition as it only consists of
one line each and according to coding style rules , in this case
the braces are not required.

Signed-off-by: Ankit Baluni <b18007@students.iitmandi.ac.in>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: Fix braces placement coding style errors

Fix braces placement errors as reported by checkpatch.pl

Signed-off-by: Aditya Jain <aditya.jainadityajain.jain@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: fixed a brace coding sytle issue

Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.

Signed-off-by: Ankit Baluni <b18007@students.iitmandi.ac.in>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: coding style: correct multiline comments

This fixes some coding style issues of multiline comments to
correct a few checkpatch.pl warnings.

Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: atomisp: coding style: remove beginning whitespaces

This removes whitespaces at the beginning of a few lines to fix
some checkpatch.pl warnings.

Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: open.rst: document mc-centric and video-node-centric

When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node.

Yet, we have never clearly documented in the V4L2 specification
the differences between the two types.

Let's document them based on the the current implementation.

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

media: docs: add glossary.rst with common terms used at V4L2 spec

Add a glossary of terms used within the media userspace API
documentation, as several concepts are complex enough to cause
misunderstandings.

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

media: open.rst: remove the minor number range

minor numbers use to range between 0 to 255, but that
was changed a long time ago. While it still applies when
CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is
dynamically allocated, this may not be true. In any case,
this is not relevant, as udev will take care of it.

So, remove this useless misinformation.

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: open.rst: better document device node naming

Right now, only kAPI documentation describes the device naming.
However, such description is needed at the uAPI too. Add it,
and describe how to get an unique identifier for a given device.

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: docs: use SPDX GPL-2.0 OR GFDL-1.1 instead of text on *.svg files

There are some files that are dual licensed GPL and GFDL.

As SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

Let's remove the dual license text, replacing them by:

SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later

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

media: docs: use SPDX GPL-2.0 OR GFDL-1.1 instead of text on *.rst files

There are some files that are dual licensed GPL and GFDL.

As SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

Let's remove the dual license text, replacing them by:

SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later

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

media: docs: use the new SPDX header for GFDL-1.1 on *.svg files

SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

So, remove the license text, replacing them by this new SPDX license.

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

media: docs: use the new SPDX header for GFDL-1.1 on *.rst files

SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

So, remove the license text, replacing them by this new SPDX
license.

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

media: venus: Make debug infrastructure more flexible

Here we introduce debug prefixes for dev_dbg groups by level of
importance - Venus{Low,Med,High,FW} Enabling the particular level
will be done by dynamic debug.

For example to enable debug messages with low level:
echo 'format "VenusLow" +p' > debugfs/dynamic_debug/control

If you want to enable all levels:
echo 'format "Venus" +p' > debugfs/dynamic_debug/control

All the features which dynamic debugging provide are preserved.

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

media: venus: Add debugfs interface to set firmware log level

This will be useful when debugging specific issues related to
firmware HFI interface.

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

media: docs: Deprecate mfc frame skip control

Deprecate mfc private frame skip mode control for new
clients and use the standard one instead.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: s5p-mfc: Use standard frame skip mode control

Use the standard menu control for frame skip mode in the MFC
driver. The legacy private menu control is kept for backward
compatibility.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: venc: Add support for frame-skip mode v4l2 control

This adds support for frame-skip-mode standard v4l2 control in
encoder driver. The control is implemented based on the
combination of client selected bitrate-mode and frame-skip-mode.
Once The client selected bitrate-mode (constant or variable) and
the frame-skip-mode is not disabled we set variable framerate for
rate controller.

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

media: v4l2-ctrl: Add frame-skip std encoder control

Adds encoders standard v4l2 control for frame-skip. The control
is a copy of a custom encoder control so that other v4l2 encoder
drivers can use it.

Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: venc: Add support for constant quality control

Adds implementation of V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY v4l
control when the bitrate mode is CQ.

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

media: v4l2-ctrls: Add encoder constant quality control

When V4L2_CID_MPEG_VIDEO_BITRATE_MODE value is
V4L2_MPEG_VIDEO_BITRATE_MODE_CQ, encoder will produce
constant quality output indicated by
V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY control value.
Encoder will choose appropriate quantization parameter
and bitrate to produce requested frame quality level.

Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: venus: Add new interface queues reinit

Presently the recovery mechanism is using two hfi functions
to destroy and create interface queues. For the purpose of
recovery we don't need to free and allocate the memory used
for interface message queues, that's why we introduce new
function which just reinit the queues.  Also this will give
to the recovery procedure one less reason to fail (if for
some reason we couldn't allocate memory).

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

media: venus: Rework recovery mechanism

After power domains and clock restructuring the recovery for
sdm845 and v4 did not work properly. Fix that by reworking the
recovery function and the sequence.

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

media: venus: parser: Prepare parser for multiple invocations

Presently the hfi_parser has been called only once during driver
probe. To prepare the parser function to be called multiple times
from recovery we need to initialize few variables which are used
during parsing time.

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

media: venus: Fix reported frame intervals

On dragonboard-410c (apq8016) with HFI_VERSION_1XX, the reported
framerate is in unit of 1/65535 fps (for fine grained control).
So the current reported supported frame intervals is wrong (max
is 1/65535 fps), leading to encoding issues or format negotiation
failures with gstreamer.

Fix that by setting the framerate denominator to coherent value
based on the the framerate factor.

The factor is not always the same, e.g. with db820c (apq8096) HFI
reports framerate in fps unit. So only apply that for HFI_VERSION_1XX.

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

media: venus: fixes for list corruption

There are few list handling issues while adding and deleting
node in the registered buf list in the driver.
1. list addition - buffer added into the list during buf_init
while not deleted during cleanup.
2. list deletion - In capture streamoff, the list was reinitialized.
As a result, if any node was present in the list, it would
lead to issue while cleaning up that node during buf_cleanup.

Corresponding call traces below:
[  165.751014] Call trace:
[  165.753541]  __list_add_valid+0x58/0x88
[  165.757532]  venus_helper_vb2_buf_init+0x74/0xa8 [venus_core]
[  165.763450]  vdec_buf_init+0x34/0xb4 [venus_dec]
[  165.768271]  __buf_prepare+0x598/0x8a0 [videobuf2_common]
[  165.773820]  vb2_core_qbuf+0xb4/0x334 [videobuf2_common]
[  165.779298]  vb2_qbuf+0x78/0xb8 [videobuf2_v4l2]
[  165.784053]  v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem]
[  165.789067]  v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem]
[  165.794624]  v4l_qbuf+0x48/0x58

[ 1797.556001] Call trace:
[ 1797.558516]  __list_del_entry_valid+0x88/0x9c
[ 1797.562989]  vdec_buf_cleanup+0x54/0x228 [venus_dec]
[ 1797.568088]  __buf_prepare+0x270/0x8a0 [videobuf2_common]
[ 1797.573625]  vb2_core_qbuf+0xb4/0x338 [videobuf2_common]
[ 1797.579082]  vb2_qbuf+0x78/0xb8 [videobuf2_v4l2]
[ 1797.583830]  v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem]
[ 1797.588843]  v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem]
[ 1797.594389]  v4l_qbuf+0x48/0x58

Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cedrus: Use H264_SCALING_MATRIX only when required

Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.

To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.

Implement this on cedrus, which has hardware support for this
case.

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: Use H264_SCALING_MATRIX only when required

Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.

To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.

Implement this on hantro, which has hardware support for this
case.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rkvdec: Use H264_SCALING_MATRIX only when required

Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.

To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.

Implement this on rkvdec, which has hardware support for this
case.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: rkvdec: Drop unneeded per_request driver-specific control flag

Currently, the drivers makes no distinction between per_request
and mandatory, as both are used in the same request validate check.

The driver only cares to know if a given control is
required to be part of a request, so only one flag is needed.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cedrus: h264: Fix frame list construction

Current frame list construction algorithm assumes that decoded image
will be output into its own buffer. That is true for progressive content
but not for interlaced where each field is decoded separately into same
buffer.

Fix that by checking if capture buffer is listed in DPB. If it is, reuse
it.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: cedrus: h264: Properly configure reference field

When interlaced H264 content is being decoded, references must indicate
which field is being referenced. Currently this was done by checking
capture buffer flags. However, that is not correct because capture
buffer may hold both fields.

Fix this by checking newly introduced flags in reference lists.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-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: rkvdec: Don't require unneeded H264_SLICE_PARAMS

Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: hantro: Don't require unneeded H264_SLICE_PARAMS

Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Rename and clarify PPS_FLAG_SCALING_MATRIX_PRESENT

Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX
if a non-flat scaling matrix applies to the picture. This is the case if
SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag
are set, and should be handled by applications.

On one hand, the PPS bitstream syntax element signals the presence of a
Picture scaling matrix modifying the Sequence (SPS) scaling matrix.
On the other hand, our flag should indicate if the scaling matrix
V4L2 control is applicable to this request.

Rename the flag from PPS_FLAG_PIC_SCALING_MATRIX_PRESENT to
PPS_FLAG_SCALING_MATRIX_PRESENT, to avoid mixing this flag with
bitstream syntax element pic_scaling_matrix_present_flag,
and clarify the meaning of our flag.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Clean slice invariants syntax elements

The H.264 specification requires in section 7.4.3 "Slice header semantics",
that the following values shall be the same in all slice headers:

  pic_parameter_set_id
  frame_num
  field_pic_flag
  bottom_field_flag
  idr_pic_id
  pic_order_cnt_lsb
  delta_pic_order_cnt_bottom
  delta_pic_order_cnt[ 0 ]
  delta_pic_order_cnt[ 1 ]
  sp_for_switch_flag
  slice_group_change_cycle

These bitstream fields are part of the slice header, and therefore
passed redundantly on each slice. The purpose of the redundancy
is to make the codec fault-tolerant in network scenarios.

This is of course not needed to be reflected in the V4L2 controls,
given the bitstream has already been parsed by applications.
Therefore, move the redundant fields to the per-frame decode
parameters control (DECODE_PARAMS).

Field 'pic_parameter_set_id' is simply removed in this case,
because the PPS control must currently contain the active PPS.

Syntax elements dec_ref_pic_marking() and those related
to pic order count, remain invariant as well, and therefore,
the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size
are also common to all slices.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Clarify SLICE_BASED mode

Currently, the SLICE_BASED and FRAME_BASED modes documentation
is misleading and not matching the intended use-cases.

Drop non-required fields SLICE_PARAMS 'start_byte_offset' and
DECODE_PARAMS 'num_slices' and clarify the decoding modes in the
documentation.

On SLICE_BASED mode, a single slice is expected per OUTPUT buffer,
and therefore 'start_byte_offset' is not needed (since the offset
to the slice is the start of the buffer).

This mode requires the use of CAPTURE buffer holding, and so
the number of slices shall not be required.

On FRAME_BASED mode, the devices are expected to take care of slice
parsing. Neither SLICE_PARAMS are required (and shouldn't be
exposed by frame-based drivers), nor the number of slices.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Drop SLICE_PARAMS 'size' field

The SLICE_PARAMS control is intended for slice-based
devices. In this mode, the OUTPUT buffer contains
a single slice, and so the buffer's plane payload size
can be used to query the slice size.

To reduce the API surface drop the size from the
SLICE_PARAMS control.

A follow-up change will remove other members in SLICE_PARAMS
so we don't need to add padding fields here.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Increase size of DPB entry pic_num

DPB entry PicNum maximum value is 2*MaxFrameNum for interlaced
content (field_pic_flag=1).

As specified, MaxFrameNum is 2^(log2_max_frame_num_minus4 + 4)
and log2_max_frame_num_minus4 is in the range of 0 to 12,
which means pic_num should be a 32-bit field.

The v4l2_h264_dpb_entry struct needs to be padded to avoid a hole,
which might be also useful to allow future uAPI extensions.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Clean DPB entry interface

As discussed recently, the current interface for the
Decoded Picture Buffer is not enough to properly
support field coding.

This commit introduces enough semantics to support
frame and field coding, and to signal how DPB entries
are "used for reference".

Reserved fields will be added by a follow-up commit.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Increase size of 'first_mb_in_slice' field

Slice header syntax element 'first_mb_in_slice' can point
to the last macroblock, currently the field can only reference
65536 macroblocks which is insufficient for 8K videos.

Although unlikely, a 8192x4320 video (where macroblocks are 16x16),
would contain 138240 macroblocks on a frame.

As per the H264 specification, 'first_mb_in_slice' can be up to
PicSizeInMbs - 1, so increase the size of the field to 32-bits.

Note that v4l2_ctrl_h264_slice_params struct will be modified
in a follow-up commit, and so we defer its 64-bit padding.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Clarify pic_order_cnt_bit_size field

Since pic_order_cnt_bit_size is not a syntax element itself, explicitly
state that it is the total size in bits of the pic_order_cnt_lsb,
delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
delta_pic_order_cnt[1] syntax elements contained in the slice.

[Ezequiel: rebase]

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Split prediction weight parameters

The prediction weight parameters are only required under
certain conditions, which depend on slice header parameters.

As specified in section 7.3.3 Slice header syntax, the prediction
weight table is present if:

((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \
(weighted_bipred_idc == 1 && slice_type == B))

Given its size, it makes sense to move this table to its control,
so applications can avoid passing it if the slice doesn't specify it.

Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes.
With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight
is 772 bytes.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

media: uapi: h264: Further clarify scaling lists order

Commit 0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.

This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>