This config option is strictly speaking independent of the
media subsystem since it can be used by drm as well.

Besides, it looks odd when drivers select CEC_CORE and
MEDIA_CEC_NOTIFIER, that's inconsistent naming.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The CEC framework is used by both drm and media. That makes it tricky
to get the dependencies right.

This patch moves the CEC_CORE and MEDIA_CEC_NOTIFIER config options
out of the media menu and instead drivers that want to use CEC should
select CEC_CORE and MEDIA_CEC_NOTIFIER (if needed).
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

exit_loop is not being initialized, so it contains garbage. Ensure it is
initialized to false.

Detected by CoverityScan, CID#1436409 ("Uninitialized scalar variable")

Fixes: ea6a69de ("[media] rainshadow-cec: avoid -Wmaybe-uninitialized warning")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Add these misspellings to scripts/spelling.txt too

Link: http://lkml.kernel.org/r/962aace119675e5fe87be2a88ddac1a5486f8e60.1490931810.git.joe@perches.comSigned-off-by: NJoe Perches <joe@perches.com>
Acked-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It is not needed there anymore. All places needing it are
fixed.
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

devm_gpiod_get_optional() can return -ENOSYS if GPIOLIB is
disabled, causing probe to fail. Warn the user if this
happens.
Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The philips.txt file were at the wrong place: it should be,
instead, at Documentation/media.

Move and convert it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The OMAP IOMMU driver has added the support for IOMMU groups internally,
and the ISP device is automatically linked to the appropriate IOMMU group.
So, remove the explicit function calls that creates/deletes an iommu_group
and adds the ISP device to this group.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSuman Anna <s-anna@ti.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/media/.
Suggested-by: NAlan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
cc: mjpeg-users@lists.sourceforge.net
cc: linux-media@vger.kernel.org

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.htmlSigned-off-by: NLogan Gunthorpe <logang@deltatee.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1492630570-879-1-git-send-email-logang@deltatee.com

Initialize the pointer 'fmt' before the start of
the loop.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NSongjun Wu <songjun.wu@microchip.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Enabling vflip currently causes wrong colors.
It seems that (at least with the current sensor setup) REG04_VFLIP_IMG only
changes the vertical readout direction.
Because pixels are arranged RGRG... in odd lines and GBGB... in even lines,
either a one line shift or even/odd line swap is required, too, but
apparently this doesn't happen.

I finally figured out that this can be done manually by setting
REG04_VREF_EN.
Looking at hflip, it turns out that bit REG04_HREF_EN is set there
permanetly, but according to my tests has no effect on the pixel readout
order.
So my conclusion is that the current documentation of sensor register 0x04
is wrong (has changed after preliminary datasheet version 2.2).

I'm pretty sure that automatic vertical line shift/switch can be enabled,
too, but until anyone finds ot how this works, we have to stick with manual
switching.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

ov2640_select_win() returns height and width values as part of struct
ov2640_win_size, so there is no point in modifying the passed height and
width parameters, too.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

HSIZE and VSIZE bits 0 to 2 and HSIZE bit 11 are encoded in DSP register
SIZEL.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

According to ov2640 software application notes, there are two Automatic
White Balance (AWB) modes, which are selected by DSP register 0xc7:

1) Simple AWB: assumes the average color is gray
   + independent from lens
   - doesn't work well if captured area contains unbalanced colors
     (e.g. large blue background)

2) Advanced AWB: uses color temperature information
   + more accurate, works with all image contents
   - lens specific, requires calibration
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

- add missing initialisation of sensor register COM25 (2 MSBs of banding
  filter AEC values)
- add macros for setting the banding filter AEC values
- add definitions for sensor register 0x5a, which is documented in
  Omnivisions software application notes
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

While we are at it, remove a misleading comment (copy/paste mistake)
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

As warned by kbuild test robot:
	warning: (VIDEO_EM28XX_V4L2) selects VIDEO_OV2640 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_V4L2 && I2C && GPIOLIB && MEDIA_CAMERA_SUPPORT)

The em28xx driver can use ov2640, but it doesn't depend
(or use) the GPIOLIB in order to power off/on the sensor.

So, as we want to allow both usages with and without
GPIOLIB, make its dependency optional.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Trivial fix to spelling mistake on calibration, make Self lowercase
and re-join multiple lined printk since checkpatch allows this
coding style.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Fix kernel Oops NULL pointer deference
Call dev_dbg_obj only after checking if gobj->mdev is not NULL
Signed-off-by: NHelen Koike <helen.koike@collabora.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

i2c_mux_add_adapter already logs a message on failure.
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Reviewed-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NPeter Rosin <peda@axentia.se>

Remove those gcc warnings:

	drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
	drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
	   mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
	                                                   ^

By adding braces.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The h.264 standard allows up to 16 reference frame for the high profile
and we need one additional internal framebuffer when the VDOA is in use.

Lift the current maximum of 8 internal framebuffers to allow playback
of those video streams.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Driver is stable. Remove DEBUG definition from driver.

There are debug message in /var/log/messages if DEBUG is defined,
such as:
[MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
[MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
[MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
Signed-off-by: NMinghsiu Tsai <minghsiu.tsai@mediatek.com>
Acked-by: NTiffany Lin <Tiffany.lin@mediatek.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Otherwise the i2c transfer functions can read or write beyond the end of
stack or heap buffers.
Signed-off-by: NAlyssa Milburn <amilburn@zall.org>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and
heap buffers.
Signed-off-by: NAlyssa Milburn <amilburn@zall.org>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Add an explicit config option to select whether the CEC remote control
messages are to be passed on to the RC subsystem or not.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Drop the separate cec-edid.h header and merge it into cec.h.

There was really no need to have a separate header for this.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The Kconfig options for the CEC subsystem were a bit messy. In
addition there were two cec sources (cec-edid.c and cec-notifier.c)
that were outside of the media/cec directory, which was weird.

Move those sources to media/cec as well.

The cec-edid and cec-notifier functionality is now part of the cec
module and these are no longer separate modules.

Also remove the MEDIA_CEC_EDID config option and include it with the
main CEC config option (which defined CEC_EDID anyway).

Added static inlines to cec-edid.h for dummy functions when CEC_CORE
isn't defined.

CEC drivers should now depend on CEC_CORE.

CEC drivers that need the cec-notifier functionality must explicitly
select CEC_NOTIFIER.

The s5p-cec and stih-cec drivers depended on VIDEO_DEV instead of
CEC_CORE, fix that as well.
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Acked-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

This code copies actual_length-128 bytes from the header, which will
underflow if the received buffer is too small.
Signed-off-by: NAlyssa Milburn <amilburn@zall.org>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Return an error rather than memcpy()ing beyond the end of the buffer.
Internal callers use appropriate sizes, but digitv_i2c_xfer may not.
Signed-off-by: NAlyssa Milburn <amilburn@zall.org>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The Kconfig currently makes no reference to the snd-usb-audio
driver, which supports audio capture for this type of devices.
Just in case, let's make sure the requirement is mentioned
in the description.
Signed-off-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Fixes "w_scan -f c" complaining with

  This dvb driver is *buggy*: the symbol rate limits are undefined - please
  report to linuxtv.org)
Signed-off-by: NDaniel Scheller <d.scheller@gmx.net>
Acked-by: NAbylay Ospan <aospan@netup.ru>
Cc: stable@vger.kernel.org
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Since when we got rid of usbfs, the /proc/bus/usb is now
elsewhere. Fix references for it.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: NSerge Hallyn <serge@hallyn.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Adding support for SRGGB8 is as simple as adding a new entry at
struct em28xx_fmt.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

CbYCrY has been identified by looking into the tvp5150 driver and the
saa7115 datasheet.
YUV formats have been verified with em2765 + ov2640 (VAD Laplace webcam).
RGB8 formats have been verified with em2710/em2820 + mt9v011 (Silvercrest
webcam 1.3mpix).
I also did some cross-checking with these two camera devices and 0x08-0x0b
are at least 16 bits per pixel formats on em2710/em2820, too, and
0x0c-0x0f are at least 8 bits per pixel formats on em2765, too.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

With an unknown sensor, norm_maxw() and norm_maxh() return 0 as max.
height and width values, which causes a devide by zero in size_to_scale().
Of course we could use speculative default values for unknown sensors,
but the chance that the device works at this resolution without any
driver/setup is very low and therefore not worth the efforts.
Instead, just don't treat the device as camera.
A message will then be printed to the log that the device isn't supported.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

With MEDIA_SUBDRV_AUTOSELECT enabled in the kernel config, the em28xx
driver currently does't select some used subdrivers.
Fix this by adding the missing auto-selections to the Kconfig file.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

The v4l2 dummy clock has been added with commit fc5d0f8a
("V4L2: em28xx: register a V4L2 clock source") to be able to use the ov2640
soc_camera driver.
Since commit 46796cfc ("ov2640: use standard clk and enable it") it is
no longer required.
Signed-off-by: NFrank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>