Provide QAM/DVB-C signal strength in decibel scale. Values returned from
stv0367cab_get_rf_lvl() are good but need to be multiplied as they're in
1dBm precision.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Since the other statistics are read when fe_status conditions are TRUE,
change the ucblocks readout logic to match this aswell.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

While there's a test at the SNR calculus to avoid division by
zero, it will still follow the path that would do the division.
So, add a missing break there.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Add signal-to-noise-ratio as provided by the demodulator in decibel scale.
QAM/DVB-C needs some intlog calculation to have usable dB values, OFDM/
DVB-T values from the demod look alright already and are provided as-is.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

When the demod driver puts the demod into sleep or shutdown state and it's
status is then polled e.g. via "dvb-fe-tool -m", i2c errors are printed
to the kernel log. If the last delsys was DVB-T/T2:

  cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1
  cxd2841er: i2c rd failed=-5 addr=6c reg=26

and if it was DVB-C:

  cxd2841er: i2c wr failed=-5 addr=6c reg=00 len=1
  cxd2841er: i2c rd failed=-5 addr=6c reg=49

This happens when read_status unconditionally calls into the
read_signal_strength() function which triggers the read_agc_gain_*()
functions, where these registered are polled.

This isn't a critical thing since when the demod is active again, no more
such errors are logged, however this might make users suspecting defects.

Fix this by requiring STATE_ACTIVE_* in priv->state. If it isn't in any
active state, additionally set the strength scale to NOT_AVAILABLE.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Fixup

  commit d52786dd ("media: ddbridge: make (ddb)readl in while-loops fail-safe")

after/wrt

  commit 11e358bf ("media: ddbridge: use dev_* macros in favor of printk")
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Value assigned to variable _type_ at line 678 is overwritten at line 688
before it can be used. This makes such variable assignment useless.

Remove this variable assignment and fix some coding style issues.

Addresses-Coverity-ID: 1226968
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Remove unnecessary variable _ret_ and refactor the code.

Addresses-Coverity-ID: 1226934
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The read_snr() functions currently do some magic to return relative scale
values when called. Split out register readouts into separate functions
so the functionality can be reused in some other way.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This adds the basics to stv0367ddb_read_status() to be able to properly
provide signal statistics in DVBv5 format. Also adds UCB readout and
provides those values. Also, don't return -EINVAL in ddb_read_status()
if active_demod_state indicates no delivery system.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Use dev_dbg() in conjunction with the %*ph format macro to print the vmon
status debug, thus hiding continuous hexdumping from default log levels.
Also, change the attach success log line from error to info severity.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Acked-by: NAbylay Ospan <aospan@netup.ru>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The semaphore 'i2c_switch_mutex' is used as a simple mutex, so
it should be written as one. Semaphores are going away in the future.
Signed-off-by: NBinoy Jayan <binoy.jayan@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The semaphore 'stream_mutex' is used as a simple mutex, so
it should be written as one. Also moving the mutex_[lock/unlock]
to the caller as it is anyway locked at the beginning of the
callee thus avoiding repetition.
Signed-off-by: NBinoy Jayan <binoy.jayan@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The semaphore 'cmd_mutex' is used as a simple mutex, so
it should be written as one. Also, replace down with
mutex_destroy to ensure sane state when ngene_stop is
called.
Signed-off-by: NBinoy Jayan <binoy.jayan@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

As such macro will check if the expression is true, it may fall through, as
warned:

In file included from ./include/uapi/linux/stddef.h:1:0,
                 from ./include/linux/stddef.h:4,
                 from ./include/uapi/linux/posix_types.h:4,
                 from ./include/uapi/linux/types.h:13,
                 from ./include/linux/types.h:5,
                 from ./drivers/media/dvb-core/dvb_frontend.h:35,
                 from drivers/media/tuners/fc0011.h:4,
                 from drivers/media/tuners/fc0011.c:20:
drivers/media/tuners/fc0011.c: In function 'fc0011_set_params':
./include/linux/compiler.h:179:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
 # define unlikely(x) __builtin_expect(!!(x), 0)
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/asm-generic/bug.h:109:2: note: in expansion of macro 'unlikely'
  unlikely(__ret_warn_on);     \
  ^~~~~~~~
drivers/media/tuners/fc0011.c:344:3: note: in expansion of macro 'WARN_ON'
   WARN_ON(1);
   ^~~~~~~
drivers/media/tuners/fc0011.c:345:2: note: here
  case 0:
  ^~~~
In file included from ./include/uapi/linux/stddef.h:1:0,
                 from ./include/linux/stddef.h:4,
                 from ./include/uapi/linux/posix_types.h:4,
                 from ./include/uapi/linux/types.h:13,
                 from ./include/linux/types.h:5,
                 from ./include/linux/list.h:4,
                 from ./include/linux/module.h:9,
                 from drivers/media/pci/tw5864/tw5864-video.c:17:
drivers/media/pci/tw5864/tw5864-video.c: In function 'tw5864_fmt_vid_cap':
./include/linux/compiler.h:179:22: warning: this statement may fall through [-Wimplicit-fallthrough=]
 # define unlikely(x) __builtin_expect(!!(x), 0)
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
./include/asm-generic/bug.h:68:2: note: in expansion of macro 'unlikely'
  unlikely(__ret_warn_on);    \
  ^~~~~~~~
drivers/media/pci/tw5864/tw5864-video.c:547:3: note: in expansion of macro 'WARN_ON_ONCE'
   WARN_ON_ONCE(1);
   ^~~~~~~~~~~~
drivers/media/pci/tw5864/tw5864-video.c:548:2: note: here
  case STD_NTSC:
  ^~~~

On both cases, it means an error, so, let's return an error
code, to make gcc happy.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NMichael Büsch <m@bues.ch>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

DRX_S9TOS16 and DRX_S24TODRXFREQ are simply not used. Furthermore,
sign_extend32() should be used for sign extension. (Also, the comment
describing DRX_S24TODRXFREQ was wrong). So remove these macros.
Signed-off-by: NMartin Kepplinger <martink@posteo.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The dmaengine driver for sDMA now have support for interleaved transfer.
This trasnfer type was open coded with the legacy omap-dma API, but now
we can move it to dmaengine.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

While committing a change on em28xx, I got a warning of a
typo there. So, fix it on em28xx and on two other media drivers
with the same typo.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

There's a new version of Terratec H6 with uses USB ID
0ccd:10b2. This version is similar to the old one (with is
supported via the HTC entry), except that this one has the
eeprom on the second bus.

On this board, one side of this board is labeled with:
	dvbc v2.0
The other side with:
	94V-0, MO2, RK-4221 with huge digits: 1107

With those patches, the board is properly detected:

    em28xx 1-1.5:1.0: New device TERRATEC TERRATCE H5 MKII @ 480 Mbps (0ccd:10b2, interface 0, class 0)
    em28xx 1-1.5:1.0: Audio interface 0 found (Vendor Class)
    em28xx 1-1.5:1.0: Video interface 0 found: isoc
    em28xx 1-1.5:1.0: DVB interface 0 found: isoc
    em28xx 1-1.5:1.0: chip ID is em2884
    em28xx eeprom 00000000: 26 00 00 00 02 0b 0f e5 f5 64 01 60 09 e5 f5 64  &........d.`...d
    em28xx eeprom 00000010: 09 60 03 c2 c6 22 e5 f7 b4 03 13 e5 f6 b4 87 03  .`..."..........
    em28xx eeprom 00000020: 02 0a b9 e5 f6 b4 93 03 02 09 46 c2 c6 22 c2 c6  ..........F.."..
    em28xx eeprom 00000030: 22 00 60 00 ef 70 08 85 3d 82 85 3c 83 93 ff ef  ".`..p..=..<....
    em28xx eeprom 00000040: 60 19 85 3d 82 85 3c 83 e4 93 12 07 a3 12 0a fe  `..=..<.........
    em28xx eeprom 00000050: 05 3d e5 3d 70 02 05 3c 1f 80 e4 22 12 0b 06 02  .=.=p..<..."....
    em28xx eeprom 00000060: 07 e2 01 00 1a eb 67 95 cd 0c b2 10 f0 13 6b 03  ......g.......k.
    em28xx eeprom 00000070: 98 22 6a 1c 86 12 27 57 4e 16 29 00 60 00 00 00  ."j...'WN.).`...
    em28xx eeprom 00000080: 02 00 00 00 5e 00 13 00 f0 10 44 82 82 00 00 00  ....^.....D.....
    em28xx eeprom 00000090: 5b 81 c0 00 00 00 20 40 20 80 02 20 10 01 00 00  [..... @ .. ....
    em28xx eeprom 000000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    em28xx eeprom 000000b0: c6 40 00 00 81 00 00 00 00 00 00 00 00 c4 00 00  .@..............
    em28xx eeprom 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 03  ................
    em28xx eeprom 000000d0: 31 00 32 00 33 00 34 00 35 00 36 00 37 00 38 00  1.2.3.4.5.6.7.8.
    em28xx eeprom 000000e0: 39 00 41 00 42 00 43 00 44 00 12 03 54 00 45 00  9.A.B.C.D...T.E.
    em28xx eeprom 000000f0: 52 00 52 00 41 00 54 00 45 00 43 00 22 03 54 00  R.R.A.T.E.C.".T.
    em28xx 1-1.5:1.0: eeprom 000100: ... (skipped)
    em28xx 1-1.5:1.0: EEPROM ID = 26 00 00 00, EEPROM hash = 0xbcd5a8cf
    em28xx 1-1.5:1.0: EEPROM info:
    em28xx 1-1.5:1.0:	microcode start address = 0x0004, boot configuration = 0x00
    em28xx 1-1.5:1.0:	I2S audio, 5 sample rates
    em28xx 1-1.5:1.0:	500mA max power
    em28xx 1-1.5:1.0:	Table at offset 0x27, strings=0x2298, 0x1c6a, 0x1286
    em28xx 1-1.5:1.0: Identified as Terratec Cinergy H6 rev. 2 (card=101)
    em28xx 1-1.5:1.0: Currently, V4L2 is not supported on this model
    em28xx 1-1.5:1.0: dvb set to isoc mode.
    usbcore: registered new interface driver em28xx
    em28xx 1-1.5:1.0: Binding audio extension
    em28xx 1-1.5:1.0: em28xx-audio.c: Copyright (C) 2006 Markus Rechberger
    em28xx 1-1.5:1.0: em28xx-audio.c: Copyright (C) 2007-2016 Mauro Carvalho Chehab
    em28xx 1-1.5:1.0: Endpoint 0x83 high-speed on intf 0 alt 7 interval = 8, size 196
    em28xx 1-1.5:1.0: Number of URBs: 1, with 64 packets and 192 size
    em28xx 1-1.5:1.0: Audio extension successfully initialized
    em28xx: Registered (Em28xx Audio Extension) extension
    em28xx 1-1.5:1.0: Binding DVB extension
    drxk: status = 0x639260d9
    drxk: detected a drx-3926k, spin A3, xtal 20.250 MHz
    drxk: DRXK driver version 0.9.4300
    drxk: frontend initialized.
    tda18271 4-0060: creating new instance
    tda18271: TDA18271HD/C2 detected @ 4-0060
    dvbdev: DVB: registering new adapter (1-1.5:1.0)
    em28xx 1-1.5:1.0: DVB: registering adapter 0 frontend 0 (DRXK DVB-C DVB-T)...
    dvbdev: dvb_create_media_entity: media entity 'DRXK DVB-C DVB-T' registered.
    dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
    em28xx 1-1.5:1.0: DVB extension successfully initialized
    em28xx: Registered (Em28xx dvb Extension) extension
    em28xx 1-1.5:1.0: Registering input extension
    rc rc0: 1-1.5:1.0 IR as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/rc/rc0
    Registered IR keymap rc-nec-terratec-cinergy-xs
    input: 1-1.5:1.0 IR as /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5/1-1.5:1.0/rc/rc0/input0
    em28xx 1-1.5:1.0: Input extension successfully initalized
    em28xx: Registered (Em28xx Input Extension) extension
    tda18271: performing RF tracking filter calibration
    tda18271: RF tracking filter calibration complete
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

While testing support for Terratec H6 rev. 2, it was noticed
that reading from eeprom there causes a timeout error.

Apparently, this is due to the need of properly setting GPIOs.

In any case, the driver doesn't really require eeprom reading
to succeed, as this is currently used only for debug.

So, Ignore such errors.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Mostly this adds some unlocks to error paths.  But, if you see where
there were "break;" statements before, I changed those paths to return
error codes instead of returning success.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This patch mostly adds unlocks to error paths.  But one additional small
change is that I made the first "break;" a "goto unlock;" which means
that now we return failure instead of success on that path.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Values assigned to variables Fmax and Fmin at lines 2740 and 2741 are
overwritten at lines 2754 and 2755 before they can be used. This makes
such variable assignments useless.

Addresses-Coverity-ID: 1226952
Addresses-Coverity-ID: 1226953
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Avoid the following warning when building documentation:
	checking consistency... /devel/v4l/patchwork/Documentation/media/v4l-drivers/imx.rst:: WARNING: document isn't included in any toctree

While here, avoid placing all driver authors at just one line at
the html/pdf output.
Acked-by: NSteve Longerbeam <steve_longerbeam@mentor.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

It is not trivial to implement the logic that collects DVBv5
statistics. As we're seein lately too many implementations
that are not quite right when reviewing patchsets, add a
detailed explanation, adding a few examples about the right
thing to be done.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Side effect: KERN_DEBUG messages aren't written to the kernel log anymore.
This also improves the tda18212_ping reporting a bit so users know that if
pinging wasn't successful, bad things will happen.

Since in module_init_ddbridge() there's no dev yet, pr_info is used
instead.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Reported by smatch:

  drivers/media/pci/ddbridge/ddbridge-core.c:1246 input_tasklet() warn: this loop depends on readl() succeeding
  drivers/media/pci/ddbridge/ddbridge-core.c:1768 flashio() warn: this loop depends on readl() succeeding
  drivers/media/pci/ddbridge/ddbridge-core.c:1788 flashio() warn: this loop depends on readl() succeeding

Fix this by introducing safe_ddbreadl() which will wrap ddbreadl and checks
for all bits set in the return which indicates failure, and return 0 in
that case. Usable as drop-in-replacement in all affected while loops w/o
having to change the logic.
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

I would have liked the the picture run timeout error handler to be renamed to
something a bit more descriptive in the original commit fb2be08f ("[media]
coda: first step at error recovery").
Somehow v1 [1] was merged instead of v2 [2].

[1] https://patchwork.kernel.org/patch/9663965/
[2] https://patchwork.kernel.org/patch/9774239/Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The current pre-decrement is incorrect and should be replaced
with a post-decrement. Consider the case where the very first
clk_prepare_enable fails when i is 0; in this case the error
clean up will decrement the unsigned int which wraps to the
largest unsigned int value causing an array out of bounds read
on core->clks[i].

Detected by CoverityScan, CID#1446590 ("Out-of-bounds read")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Check return value from call to core->write(), so in case of
error print error message, jump to goto label fail and eventually
return.

Addresses-Coverity-ID: 1226943
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Back in April I created a patch to address a false-positive warning:

drivers/media/usb/rainshadow-cec/rainshadow-cec.c: In function 'rain_irq_work_handler':
drivers/media/usb/rainshadow-cec/rainshadow-cec.c:171:31: error: 'data' may be used uninitialized in this function [-Werror=maybe-uninitialized]

My patch was totally wrong and introduced a real bug, and Colin Ian King thankfully
noticed it now and fixed my mistake. Unfortunately, fixing the actual uninitialized
data in this case brought back the original bogus warning.

This is a new version of the patch, which simplifies the code to the point where
gcc notices the behavior is correct.

Fixes: ca33784b ("[media] rainshadow-cec: ensure exit_loop is intialized")
Fixes: ea6a69de ("[media] rainshadow-cec: avoid -Wmaybe-uninitialized warning")

Cc: Colin Ian King <colin.king@canonical.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Commit 680d87c0 ("[media] tuner-core: use pr_foo, instead of
internal printk macros") removed the use of PREFIX, remove the #define
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Convert STK_<LEVEL> to pr_<level> to use the typical kernel logging.
Add a define for pr_fmt.  No change in logging output.

Miscellanea:

o Remove now unused PREFIX and STK_<LEVEL> macros
o Realign arguments
o Use pr_<level>_ratelimited
o Add a few missing newlines to formats
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This fixes a smatch warning:

    drivers/media/platform/coda/coda-bit.c:415 coda_alloc_framebuffers()
    error: we previously assumed 'ctx->codec' could be null (see line 396)

coda_alloc_framebuffers() is called from coda_start_encoding() and
__coda_start_decoding(). Both dereference ctx->codec before calling
coda_alloc_framebuffers() in lines 935 and 1649, so ctx->codec can not
be NULL.
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This one got applied twice, causing a build error with clang:

drivers/media/i2c/et8ek8/et8ek8_driver.c:1499:1: error: redefinition of '__mod_of__et8ek8_of_table_device_table'

Fixes: 9ae05fd1 ("[media] et8ek8: Export OF device ID as module aliases")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Seven single characters (line breaks) should be put into a sequence.
Thus use the corresponding function "seq_putc".

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Drivers must not perform unbalanced calls to stop the entity pipeline,
however if they do they will fault in the core media code, as the
entity->pipe will be set as NULL. We handle this gracefully in the core
with a WARN for the developer.

Replace the erroneous check on zero streaming counts, with a check on
NULL pipe elements instead, as this is the symptom of unbalanced
media_pipeline_stop calls.
Signed-off-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: NLaurent Pinchart <laurent.pincharts@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Unfortunately the use of 'type' was inconsistent for multiplanar
buffer types. Starting with 4.13 both the normal and _MPLANE variants
are allowed, thus making it possible to write sensible code.

Yes, we messed up :-(
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
[hans.verkuil@cisco.com: 4.14 -> 4.13 since this would go in for 4.13 after all]
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The type field in struct v4l2_selection is supposed to never use the
_MPLANE variants. E.g. if the driver supports V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
then userspace should still pass V4L2_BUF_TYPE_VIDEO_CAPTURE.

The reasons for this are lost in the mists of time, but it is really
annoying. In addition, the exynos drivers didn't follow this rule and
instead expected the _MPLANE type.

To fix that code is added to the v4l2 core that maps the _MPLANE buffer
types to their regular equivalents before calling the driver.

Effectively this allows for userspace to use either _MPLANE or the regular
buffer type. This keeps backwards compatibility while making things easier
for userspace.

Since drivers now never see the _MPLANE buffer types the exynos drivers
had to be adapted as well.
Signed-off-by: NHans Verkuil <hansverk@cisco.com>
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>