GitHub/moto-9609/android_kernel_motorola_exynos9610.git
8 years ago[media] cec: fix race between configuring and unconfiguring
Hans Verkuil [Fri, 9 Dec 2016 14:00:49 +0000 (12:00 -0200)]
[media] cec: fix race between configuring and unconfiguring

This race was discovered by running cec-compliance -A with the cec module debug
parameter set to 2: suddenly the test would fail.

It turns out that this happens when the test configures the adapter in
non-blocking mode, then it waits for the CEC_EVENT_STATE_CHANGE event and once
the event is received it unconfigures the adapter.

What happened was that the unconfigure was executed while the configure was
still transmitting the Report Features and Report Physical Address messages.
This messed up the internal state of the cec_adapter.

The fix is to transmit those messages with the adap->lock mutex held (this will
just queue them up in the internal transmit queue, and not actually transmit
anything yet). Only unlock the mutex once everything is done. The main thread
will dequeue the messages from the internal transmit queue and transmit them
one by one, unless an unconfigure was done, and in that case any messages are
just dropped.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: move cec_report_phys_addr into cec_config_thread_func
Hans Verkuil [Fri, 9 Dec 2016 13:48:34 +0000 (11:48 -0200)]
[media] cec: move cec_report_phys_addr into cec_config_thread_func

It's only a small function and this makes it easier to switch to
transmitting the message with adap->lock held in the next patch.

Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: replace cec_report_features by cec_fill_msg_report_features
Hans Verkuil [Fri, 9 Dec 2016 13:36:03 +0000 (11:36 -0200)]
[media] cec: replace cec_report_features by cec_fill_msg_report_features

The fill function just fills in the cec_msg struct, it doesn't transmit
the message. This is now done explicitly.

This makes it possible to switch to transmitting this message with adap->lock
held.

Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: update log_addr[] before finishing configuration
Hans Verkuil [Fri, 9 Dec 2016 13:54:06 +0000 (11:54 -0200)]
[media] cec: update log_addr[] before finishing configuration

The loop that sets the unused logical addresses to INVALID should be
done before 'configured' is set to true. This ensures that cec_log_addrs
is consistent before it will be used.

Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2
Hans Verkuil [Fri, 9 Dec 2016 13:28:19 +0000 (11:28 -0200)]
[media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2

This is a 2.0 only message, so it should return Feature Abort if the
adapter is configured for CEC version 1.4.

Right now it does nothing, which means that the sender will time out.

Signed-off-by: Hans Verkuil <hansverk@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: when canceling a message, don't overwrite old status info
Hans Verkuil [Fri, 9 Dec 2016 13:14:32 +0000 (11:14 -0200)]
[media] cec: when canceling a message, don't overwrite old status info

When a pending message was canceled (e.g. due to a timeout), then the
old tx_status info was overwritten instead of ORed. The same happened
with the tx_error_cnt field. So just modify them instead of overwriting
them.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: fix report_current_latency
Hans Verkuil [Tue, 6 Dec 2016 13:17:12 +0000 (11:17 -0200)]
[media] cec: fix report_current_latency

In the (very) small print of the REPORT_CURRENT_LATENCY message there is a
line that says that the last byte of the message (audio out delay) is only
present if the 'audio out compensated' value is 3.

I missed this, and so if this message was sent with a total length of 6 (i.e.
without the audio out delay byte), then it was rejected by the framework
since a minimum length of 7 was expected.

Fix this minimum length check and update the wrappers in cec-funcs.h to do
the right thing based on the message length.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] smiapp: Make suspend and resume functions __maybe_unused
Sakari Ailus [Sat, 19 Nov 2016 21:50:10 +0000 (19:50 -0200)]
[media] smiapp: Make suspend and resume functions __maybe_unused

The smiapp_suspend() and smiapp_resume() functions will end up being unused
if CONFIG_PM is enabled but CONFIG_PM_SLEEP is disabled, causing a
compiler warning from both of the function definitions. Fix this by
marking the functions with __maybe_unused.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] smiapp: Implement power-on and power-off sequences without runtime PM
Sakari Ailus [Wed, 16 Nov 2016 14:21:19 +0000 (12:21 -0200)]
[media] smiapp: Implement power-on and power-off sequences without runtime PM

Power on the sensor when the module is loaded and power it off when it is
removed.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: tvp5150: Add missing break in set control handler
Laurent Pinchart [Thu, 8 Dec 2016 22:22:43 +0000 (20:22 -0200)]
[media] v4l: tvp5150: Add missing break in set control handler

A break is missing resulting in the hue control enabling or disabling
the decode completely. Fix it.

Fixes: c43875f66140 ("[media] tvp5150: replace MEDIA_ENT_F_CONN_TEST by a control")

Cc: stable@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: tvp5150: Don't inline the tvp5150_selmux() function
Laurent Pinchart [Thu, 8 Dec 2016 22:22:42 +0000 (20:22 -0200)]
[media] v4l: tvp5150: Don't inline the tvp5150_selmux() function

The function is large and called in several places, don't inline it.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: tvp5150: Compile tvp5150_link_setup out if !CONFIG_MEDIA_CONTROLLER
Laurent Pinchart [Thu, 8 Dec 2016 22:22:41 +0000 (20:22 -0200)]
[media] v4l: tvp5150: Compile tvp5150_link_setup out if !CONFIG_MEDIA_CONTROLLER

The function is only referenced as a handler in the tvp5150_sd_media_ops
structure, which is only used when CONFIG_MEDIA_CONTROLLER is set. Don't
define the function and the structure when the configuration option is
unset to avoid an unused function warning.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] em28xx: don't store usb_device at struct em28xx
Mauro Carvalho Chehab [Wed, 7 Dec 2016 16:34:22 +0000 (14:34 -0200)]
[media] em28xx: don't store usb_device at struct em28xx

Now that we're storing usb_interface at em28xx struct,
there's no good reason to keep storing usb_device, as we can
get it from usb_interface. So, get rid of it.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] em28xx: use usb_interface for dev_foo() calls
Mauro Carvalho Chehab [Wed, 7 Dec 2016 15:48:10 +0000 (13:48 -0200)]
[media] em28xx: use usb_interface for dev_foo() calls

The usb_device->dev is not the right device for dev_foo() calls.
Instead, it should use usb_interface->dev.

Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] em28xx: don't change the device's name
Mauro Carvalho Chehab [Wed, 7 Dec 2016 16:53:26 +0000 (14:53 -0200)]
[media] em28xx: don't change the device's name

Changing the device name, causes it to be unable to remove the
sysfs file, causing troubles if a device is removed and then
re-inserted.

[ 1010.310320] WARNING: CPU: 3 PID: 119 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x7b/0x90
[ 1010.310323] sysfs: cannot create duplicate filename '/bus/usb/devices/1-3.3'
[ 1010.310325] Modules linked in: lgdt330x em28xx_dvb dvb_core em28xx_alsa tuner_xc2028 tuner tvp5150 em28xx_v4l videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core em28xx tveeprom v4l2_common videodev media xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables cmac bnep cpufreq_powersave cpufreq_conservative cpufreq_userspace binfmt_misc parport_pc ppdev lp parport snd_hda_codec_hdmi iTCO_wdt snd_hda_codec_realtek iTCO_vendor_support snd_hda_codec_generic arc4 intel_rapl x86_pkg_temp_thermal iwlmvm intel_powerclamp coretemp kvm_intel mac80211 kvm i915
[ 1010.310383]  irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel iwlwifi pl2303 aesni_intel btusb aes_x86_64 usbserial lrw btrtl gf128mul glue_helper btbcm ablk_helper cryptd btintel bluetooth drm_kms_helper cfg80211 drm psmouse pcspkr i2c_i801 e1000e serio_raw snd_hda_intel snd_soc_rt5640 snd_hda_codec snd_soc_rl6231 snd_soc_ssm4567 mei_me i2c_smbus rfkill snd_hda_core ptp mei snd_soc_core ehci_pci sg lpc_ich shpchp mfd_core ehci_hcd pps_core snd_hwdep i2c_algo_bit snd_compress snd_pcm sdhci_acpi snd_timer battery snd sdhci elan_i2c snd_soc_sst_acpi mmc_core fjes dw_dmac i2c_hid soundcore snd_soc_sst_match i2c_designware_platform video i2c_designware_core acpi_pad acpi_als kfifo_buf tpm_tis button industrialio tpm_tis_core tpm ext4 crc16 jbd2 fscrypto mbcache dm_mod joydev evdev hid_logitech_hidpp
[ 1010.310449]  sd_mod hid_logitech_dj usbhid hid ahci libahci crc32c_intel libata xhci_pci xhci_hcd scsi_mod usbcore fan thermal
[ 1010.310464] CPU: 3 PID: 119 Comm: kworker/3:2 Not tainted 4.9.0-rc8+ #14
[ 1010.310466] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015
[ 1010.310487] Workqueue: usb_hub_wq hub_event [usbcore]
[ 1010.310490]  0000000000000000 ffffffff848f56c5 ffff8803b1f7f858 0000000000000000
[ 1010.310496]  ffffffff8414f8f8 ffff88030000001f ffffed00763eff07 ffff8803b1f7f8f0
[ 1010.310501]  ffff8803b3ea1e60 0000000000000001 ffffffffffffffef ffff8803b45c6840
[ 1010.310505] Call Trace:
[ 1010.310517]  [<ffffffff848f56c5>] ? dump_stack+0x5c/0x77
[ 1010.310522]  [<ffffffff8414f8f8>] ? __warn+0x168/0x1a0
[ 1010.310526]  [<ffffffff8414f9e4>] ? warn_slowpath_fmt+0xb4/0xf0
[ 1010.310529]  [<ffffffff8414f930>] ? __warn+0x1a0/0x1a0
[ 1010.310534]  [<ffffffff845436c6>] ? kasan_kmalloc+0xa6/0xd0
[ 1010.310539]  [<ffffffff846ec2fa>] ? kernfs_path_from_node+0x4a/0x60
[ 1010.310543]  [<ffffffff846f66eb>] ? sysfs_warn_dup+0x7b/0x90
[ 1010.310547]  [<ffffffff846f6f26>] ? sysfs_do_create_link_sd.isra.2+0xb6/0xd0
[ 1010.310553]  [<ffffffff84cd5a08>] ? bus_add_device+0x318/0x6b0
[ 1010.310557]  [<ffffffff846f8693>] ? sysfs_create_groups+0x83/0x110
[ 1010.310562]  [<ffffffff84ccff87>] ? device_add+0x777/0x1350
[ 1010.310567]  [<ffffffff84ccf810>] ? device_private_init+0x180/0x180
[ 1010.310583]  [<ffffffffc00c0f77>] ? usb_new_device+0x707/0x1030 [usbcore]
[ 1010.310598]  [<ffffffffc00c58c5>] ? hub_event+0x1d65/0x3280 [usbcore]
[ 1010.310604]  [<ffffffff841eb4ab>] ? account_entity_dequeue+0x30b/0x4a0
[ 1010.310618]  [<ffffffffc00c3b60>] ? hub_port_debounce+0x280/0x280 [usbcore]
[ 1010.310624]  [<ffffffff8407ccd0>] ? compat_start_thread+0x80/0x80
[ 1010.310629]  [<ffffffff851f5cb4>] ? __schedule+0x704/0x1770
[ 1010.310633]  [<ffffffff851f55b0>] ? io_schedule_timeout+0x390/0x390
[ 1010.310638]  [<ffffffff84541783>] ? cache_reap+0x173/0x200
[ 1010.310642]  [<ffffffff84197bed>] ? process_one_work+0x4ed/0xe60
[ 1010.310646]  [<ffffffff84198642>] ? worker_thread+0xe2/0xfd0
[ 1010.310650]  [<ffffffff8421f76c>] ? __wake_up_common+0xbc/0x160
[ 1010.310654]  [<ffffffff84198560>] ? process_one_work+0xe60/0xe60
[ 1010.310658]  [<ffffffff841a837c>] ? kthread+0x1cc/0x220
[ 1010.310663]  [<ffffffff841a81b0>] ? kthread_park+0x80/0x80
[ 1010.310667]  [<ffffffff841a81b0>] ? kthread_park+0x80/0x80
[ 1010.310671]  [<ffffffff841a81b0>] ? kthread_park+0x80/0x80
[ 1010.310675]  [<ffffffff852016f5>] ? ret_from_fork+0x25/0x30

Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] mn88472: fix chip id check on probe
Antti Palosaari [Thu, 1 Dec 2016 00:08:27 +0000 (22:08 -0200)]
[media] mn88472: fix chip id check on probe

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 94d0eaa41987 ("[media] mn88472: move out of staging to media")

Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] mn88473: fix chip id check on probe
Antti Palosaari [Wed, 30 Nov 2016 21:36:14 +0000 (19:36 -0200)]
[media] mn88473: fix chip id check on probe

A register used to identify chip during probe was overwritten during
firmware download and due to that later probe's for warm chip were
failing. Detect chip from the another register, which is located on
different register bank 2.

Fixes: 7908fad99a6c ("[media] mn88473: finalize driver")

Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] lirc: fix error paths in lirc_cdev_add()
Sean Young [Sat, 26 Nov 2016 21:31:24 +0000 (19:31 -0200)]
[media] lirc: fix error paths in lirc_cdev_add()

"c77d17c0 [media] lirc: use-after free" introduces two problems:
cdev_del() can be called with a NULL argument, and the kobject_put()
path will cause a double free.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Add support for MFC v8 available in Exynos 5433 SoCs
Marek Szyprowski [Wed, 16 Nov 2016 09:04:58 +0000 (07:04 -0200)]
[media] s5p-mfc: Add support for MFC v8 available in Exynos 5433 SoCs

Exynos5433 SoC has MFC v8 hardware module, but it has more
complex clock hierarchy, so a new compatible is added.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Rework clock handling
Marek Szyprowski [Wed, 16 Nov 2016 09:04:57 +0000 (07:04 -0200)]
[media] s5p-mfc: Rework clock handling

This patch changes the code for handling clocks. Now clocks are defined
per each device variant, what is a preparation for adding support for
Exynos 5433 MFC V8, which has more clocks than all previous versions.
Also use devm_clk_get() to simplify cleanup path.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Don't keep clock prepared all the time
Marek Szyprowski [Wed, 16 Nov 2016 09:04:56 +0000 (07:04 -0200)]
[media] s5p-mfc: Don't keep clock prepared all the time

This patch moves preparation of clocks from s5p_mfc_init_pm()
(driver probe) to s5p_mfc_power_on() (start of device operation).
This change will allow to use runtime power usage optimization
on newer Samsung Exynos platforms (for example Exynos 5433).

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Kill all IS_ERR_OR_NULL in clocks management code
Marek Szyprowski [Wed, 16 Nov 2016 09:04:55 +0000 (07:04 -0200)]
[media] s5p-mfc: Kill all IS_ERR_OR_NULL in clocks management code

After commit "s5p-mfc: Fix clock management in s5p_mfc_release function"
all clocks related functions are called only when MFC device is really
available, so there is no additional check needed for NULL
gate clocks. This patch simplifies the code and kills IS_ERR_OR_NULL
macro usage.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Remove dead conditional code
Marek Szyprowski [Wed, 16 Nov 2016 09:04:54 +0000 (07:04 -0200)]
[media] s5p-mfc: Remove dead conditional code

CONFIG_PM is always enabled on Exynos platforms, so remove dead code
related to early development of MFC driver on platform without PM support.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Ensure that clock is disabled before turning power off
Marek Szyprowski [Wed, 16 Nov 2016 09:04:53 +0000 (07:04 -0200)]
[media] s5p-mfc: Ensure that clock is disabled before turning power off

Move clock disabling before turning power off.  This will enable later
to add calls to clk_prepare/unprepare in the s5p_mfc_power_off() function
to avoid keeping clocks prepared all the time when driver is bound.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Remove special clock rate management
Marek Szyprowski [Wed, 16 Nov 2016 09:04:52 +0000 (07:04 -0200)]
[media] s5p-mfc: Remove special clock rate management

The maximum rate of special clock depends on SoC variant and should
be set in device tree via assigned-clock-rates property, so remove
the code which forces special clock to 200MHz.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Use printk_ratelimited for reporting ioctl errors
Marek Szyprowski [Wed, 16 Nov 2016 09:04:51 +0000 (07:04 -0200)]
[media] s5p-mfc: Use printk_ratelimited for reporting ioctl errors

Some applications don't check error codes from QBUF/DQBUF ioctls,
so don't spam kernel log with errors if they fall into endless loop
trying to queue next buffer after a failure.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] s5p-mfc: Set DMA_ATTR_ALLOC_SINGLE_PAGES
Douglas Anderson [Wed, 16 Nov 2016 09:04:50 +0000 (07:04 -0200)]
[media] s5p-mfc: Set DMA_ATTR_ALLOC_SINGLE_PAGES

We do video allocation all the time and we need it to be fast.  Plus TLB
efficiency isn't terribly important for video.

That means we want to set DMA_ATTR_ALLOC_SINGLE_PAGES.

See also the previous change (commit 14d3ae2efeed "ARM: dma-mapping: Use
DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize allocation").

[m.szyprowski: rebased patch onto v4.9-rc1 and adapted changes
 to latest videbuf2 changes, this simplifies code changes to
 only set proper dma attribute flag and comment the reason
 for it, added commit id of arch/arm/mm patch]

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] vivid: Set color_enc on HSV formats
Ricardo Ribalda [Tue, 15 Nov 2016 12:06:25 +0000 (10:06 -0200)]
[media] vivid: Set color_enc on HSV formats

HSV formats were missing the color encoding, which leads to an invalid
ycbcr_enc value during get_fmt and try_fmt.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l2-tpg: Init hv_enc field with a valid value
Ricardo Ribalda [Tue, 15 Nov 2016 12:06:24 +0000 (10:06 -0200)]
[media] v4l2-tpg: Init hv_enc field with a valid value

Zero is not a valid value for hsv_enc. Set the field to a valid
initial value.

This is not a problem for vivid, because it sets the field to 180 via
tpg_s_hsv_enc() on the control initialization, but it might be a source
of errors for other drivers that use this code.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cec: pass parent device in register(), not allocate()
Hans Verkuil [Fri, 25 Nov 2016 08:23:34 +0000 (06:23 -0200)]
[media] cec: pass parent device in register(), not allocate()

The cec_allocate_adapter function doesn't need the parent device, only the
cec_register_adapter function needs it.

Drop the cec_devnode parent field, since devnode.dev.parent can be used
instead.

This change makes the framework consistent with other frameworks where the
parent device is not used until the device is registered.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] uvcvideo: freeing an error pointer
Dan Carpenter [Fri, 25 Nov 2016 10:28:35 +0000 (08:28 -0200)]
[media] uvcvideo: freeing an error pointer

A recent cleanup introduced a potential dereference of -EFAULT when we
call kfree(map->menu_info).

Fixes: 4cc5bed1caeb ("[media] uvcvideo: Use memdup_user() rather than duplicating its implementation")

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] DaVinci-VPFE-Capture: fix error handling
Arnd Bergmann [Tue, 22 Nov 2016 20:52:17 +0000 (18:52 -0200)]
[media] DaVinci-VPFE-Capture: fix error handling

A recent cleanup had the right idea to remove the initialization
of the error variable, but missed the actual benefit of that,
which is that we get warnings if there is a bug in it. Now
we get a warning about a bug that was introduced by this cleanup:

drivers/media/platform/davinci/vpfe_capture.c: In function 'vpfe_probe':
drivers/media/platform/davinci/vpfe_capture.c:1992:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This adds the missing initialization that the warning is about,
and another one that was preexisting and that we did not get
a warning for. That second bug has existed since the driver
was first added.

Fixes: efb74461f5a6 ("[media] DaVinci-VPFE-Capture: Delete an unnecessary variable initialisation in vpfe_probe()")
Fixes: 7da8a6cb3e5b ("V4L/DVB (12248): v4l: vpfe capture bridge driver for DM355 and DM6446")

[mchehab@s-opensource.com: fix a merge conflict]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] cx88: make checkpatch.pl happy
Mauro Carvalho Chehab [Sat, 19 Nov 2016 21:27:30 +0000 (19:27 -0200)]
[media] cx88: make checkpatch.pl happy

Usually, I don't like fixing coding style issues on non-staging
drivers, as it could be a mess pretty easy, and could become like
a snow ball. That's the case of recent changes on two changesets:
they disalign some statements. Yet, a care a lot with cx88 driver,
as it was the first driver I touched at the Kernel, and I've been
maintaining it since 2005. So, several of the coding style issues
were due to my code.

Per Andrey's suggestion, I ran checkpatch.pl in strict mode, with
fixed several other issues, did some function alinments, but broke
other alinments.

So, I had to manually apply another round of manual fixes to make
sure that everything is ok, and to make checkpatch happy with
this patch.

With this patch, checkpatch.pl is now happy when called with:
./scripts/checkpatch.pl -f --max-line-length=998 --ignore PREFER_PR_LEVEL

Also, the 80-cols violations that made sense were fixed.

Checkpatch would be happier if we convert it to use dev_foo(),
but this is a more complex change.

NOTE: there are some places with msleep(1). As this driver was
written at the time that the default was to sleep at least 10ms
on such calls (e. g. CONFIG_HZ=100), I replaced those calls by
usleep_range(10000, 20000), with should be safe to avoid breakages.

Fixes: 65bc2fe86e66 ("[media] cx88: convert it to use pr_foo() macros")
Fixes: 7b61ba8ff838 ("[media] cx88: make checkpatch happier")

Suggested-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Reviewed-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: rcar_fdp1: add FCP dependency
Arnd Bergmann [Fri, 18 Nov 2016 16:16:05 +0000 (14:16 -0200)]
[media] v4l: rcar_fdp1: add FCP dependency

Commit 4710b752e029 ("[media] v4l: Add Renesas R-Car FDP1 Driver") in the
v4l-dvb tree adds CONFIG_VIDEO_RENESAS_FDP1.

It calls into the FCP driver, but when there is no dependency, FCP might
be a module while FDP1 is built-in.

We have the same logic in VIDEO_RENESAS_VSP1, which also depends on
FCP not being a module when it is built-in itself.

drivers/media/platform/rcar_fdp1.o: In function `fdp1_pm_runtime_resume':
rcar_fdp1.c:(.text.fdp1_pm_runtime_resume+0x78): undefined reference to `rcar_fcp_enable'
drivers/media/platform/rcar_fdp1.o: In function `fdp1_pm_runtime_suspend':
rcar_fdp1.c:(.text.fdp1_pm_runtime_suspend+0x14): undefined reference to `rcar_fcp_disable'
drivers/media/platform/rcar_fdp1.o: In function `fdp1_probe':
rcar_fdp1.c:(.text.fdp1_probe+0x15c): undefined reference to `rcar_fcp_get'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: rcar_fdp1: mark PM functions as __maybe_unused
Arnd Bergmann [Fri, 18 Nov 2016 16:16:04 +0000 (14:16 -0200)]
[media] v4l: rcar_fdp1: mark PM functions as __maybe_unused

The new driver produces a warning when CONFIG_PM is disabled:

platform/rcar_fdp1.c:2408:12: error: 'fdp1_pm_runtime_resume' defined but not used [-Werror=unused-function]
platform/rcar_fdp1.c:2399:12: error: 'fdp1_pm_runtime_suspend' defined but not used [-Werror=unused-function]

This marks the two functions as __maybe_unused.

Fixes: 4710b752e029 ("[media] v4l: Add Renesas R-Car FDP1 Driver")

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: remove obsolete Media Device Managed resource interfaces
Shuah Khan [Wed, 16 Nov 2016 20:49:50 +0000 (18:49 -0200)]
[media] media: remove obsolete Media Device Managed resource interfaces

Remove obsolete media_device_get_devres(), media_device_find_devres(),
and media_device_release_devres() interfaces. These interfaces are now
obsolete.

Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] dvb-net: split the logic at dvb_net_ule() into other functions
Mauro Carvalho Chehab [Sat, 19 Nov 2016 14:56:59 +0000 (12:56 -0200)]
[media] dvb-net: split the logic at dvb_net_ule() into other functions

This function is too big and too complex, making really hard
to understand what's there.

Split it into sub-routines, in order to make it easier to be
understood, and to allow gcc to better parse it.

As a bonus, it gets rid of a goto in the middle of a routine.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] dvb_net: prepare to split a very complex function
Mauro Carvalho Chehab [Sat, 19 Nov 2016 14:56:58 +0000 (12:56 -0200)]
[media] dvb_net: prepare to split a very complex function

The dvb_net code has a really complex function, meant to handle
DVB network packages: it is long, has several loops and ifs
inside, and even cause warnings with gcc5.

Prepare it to be split into smaller functions by storing all
arguments and internal vars inside a struct.

Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] uvcvideo: Use memdup_user() rather than duplicating its implementation
Markus Elfring [Fri, 19 Aug 2016 08:50:05 +0000 (05:50 -0300)]
[media] uvcvideo: Use memdup_user() rather than duplicating its implementation

Reuse existing functionality from memdup_user() instead of keeping
duplicate source code.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] uvcvideo: Add bayer 16-bit format patterns
Edgar Thier [Tue, 15 Nov 2016 05:33:10 +0000 (03:33 -0200)]
[media] uvcvideo: Add bayer 16-bit format patterns

Those formats are implemented by The DFK 23UP1300, DFK 23UX249 and
DFK 23UX250 USB 3.0 industrial cameras from The Imaging Source.

Signed-off-by: Edgar Thier <info@edgarthier.net>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] doc-rst: Specify raw bayer format variant used in the examples
Sakari Ailus [Tue, 15 Nov 2016 21:49:43 +0000 (19:49 -0200)]
[media] doc-rst: Specify raw bayer format variant used in the examples

The documentation simply mentioned that one of the four pixel orders was
used in the example. Now specify the exact pixelformat instead.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: Add description of the Y8I, Y12I and Z16 formats
Laurent Pinchart [Tue, 15 Nov 2016 16:44:01 +0000 (14:44 -0200)]
[media] v4l: Add description of the Y8I, Y12I and Z16 formats

The formats have been added without a description, fix that.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: Add 16-bit raw bayer pixel formats
Sakari Ailus [Mon, 27 Jun 2016 13:46:16 +0000 (10:46 -0300)]
[media] v4l: Add 16-bit raw bayer pixel formats

The formats added by this patch are:

V4L2_PIX_FMT_SBGGR16
V4L2_PIX_FMT_SGBRG16
V4L2_PIX_FMT_SGRBG16

V4L2_PIX_FMT_SRGGB16 already existed before the patch. Rework the
documentation to match that of the other sample depths.

Also align the description of V4L2_PIX_FMT_SRGGB16 to match with other
similar formats.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] saa7146: Fix for while releasing video buffers
Andrey Utkin [Mon, 17 Oct 2016 19:25:59 +0000 (17:25 -0200)]
[media] saa7146: Fix for while releasing video buffers

Fix this bug:
"[BUG] process stuck when closing saa7146 [dvb_ttpci]"

Release queued DMA buffers when ending streaming, so that
videobuf_waiton() doesn't block forever.

As reported, this fixes avoids occasional lockup of process reading from
video device, which manifests in such log:

INFO: task ffmpeg:9864 blocked for more than 120 seconds.
      Tainted: P           O    4.6.7 #3
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ffmpeg          D ffff880177cc7b00     0  9864      1 0x00000000
 ffff880177cc7b00 0000000000000202 0000000000000202 ffffffff8180b4c0
 ffff88019d79e4c0 ffffffff81064050 ffff880177cc7ae0 ffff880177cc8000
 ffff880177cc7b18 ffff8801fd41d648 ffff8802307acca0 ffff8802307acc70
Call Trace:
 [<ffffffff81064050>] ? preempt_count_add+0x89/0xab
 [<ffffffff81477215>] schedule+0x86/0x9e
 [<ffffffff81477215>] ? schedule+0x86/0x9e
 [<ffffffffa0fe1c96>] videobuf_waiton+0x131/0x15e [videobuf_core]
 [<ffffffff8107727b>] ? wait_woken+0x6d/0x6d
 [<ffffffffa1017be9>] saa7146_dma_free+0x39/0x5b [saa7146_vv]
 [<ffffffffa10186c4>] buffer_release+0x2a/0x3e [saa7146_vv]
 [<ffffffffa0fee4a8>] videobuf_vm_close+0xd8/0x103 [videobuf_dma_sg]
 [<ffffffff8112049e>] remove_vma+0x25/0x4d
 [<ffffffff81121a32>] exit_mmap+0xce/0xf7
 [<ffffffff8104381d>] mmput+0x4e/0xe2
 [<ffffffff810491fd>] do_exit+0x372/0x920
 [<ffffffff81049813>] do_group_exit+0x3c/0x98
 [<ffffffff810522ef>] get_signal+0x4e8/0x56e
 [<ffffffff810710a5>] ? task_dead_fair+0xd/0xf
 [<ffffffff81017020>] do_signal+0x23/0x521
 [<ffffffff81479e82>] ? _raw_spin_unlock_irqrestore+0x13/0x25
 [<ffffffff8109710d>] ? hrtimer_try_to_cancel+0xd7/0x104
 [<ffffffff8109b306>] ? ktime_get+0x4c/0xa1
 [<ffffffff81096ea6>] ? update_rmtp+0x46/0x5b
 [<ffffffff81097ce0>] ? hrtimer_nanosleep+0xe4/0x10e
 [<ffffffff81096e3c>] ? hrtimer_init+0xeb/0xeb
 [<ffffffff810014f8>] exit_to_usermode_loop+0x4f/0x93
 [<ffffffff810019fe>] syscall_return_slowpath+0x3b/0x46
 [<ffffffff8147a355>] entry_SYSCALL_64_fastpath+0x8d/0x8f

Reported-by: Philipp Matthias Hahn <pmhahn+video@pmhahn.de>
Tested-by: Philipp Matthias Hahn <pmhahn+video@pmhahn.de>
Signed-off-by: Andrey Utkin <andrey_utkin@fastmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] extended-controls.rst: fix typo
Andrea Gelmini [Sat, 21 May 2016 11:35:26 +0000 (08:35 -0300)]
[media] extended-controls.rst: fix typo

Fix a typo on a word inside it.

Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: media: davinci_vpfe: unlock on error in vpfe_reqbufs()
Dan Carpenter [Fri, 18 Nov 2016 11:30:24 +0000 (09:30 -0200)]
[media] staging: media: davinci_vpfe: unlock on error in vpfe_reqbufs()

We should unlock before returning this error code in vpfe_reqbufs().

Fixes: 622897da67b3 ("[media] davinci: vpfe: add v4l2 video driver support")

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: media: davinci_vpfe: Fix indentation issue in vpfe_video.c
Leo Sperling [Sun, 23 Oct 2016 12:02:23 +0000 (10:02 -0200)]
[media] staging: media: davinci_vpfe: Fix indentation issue in vpfe_video.c

This is a patch to the vpfe_video.c file that fixes an indentation
warning reported by checkpatch.pl

Signed-off-by: Leo Sperling <leosperling97@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: media: davinci_vpfe: fix W=1 build warnings
Arnd Bergmann [Mon, 20 Jun 2016 15:47:56 +0000 (12:47 -0300)]
[media] staging: media: davinci_vpfe: fix W=1 build warnings

When building with "make W=1", we get multiple harmless build warnings
for the vpfe driver:

drivers/staging/media/davinci_vpfe/dm365_resizer.c:241:1: error: 'static' is not at beginning of declaration [-Werror=old-style-declaration]
drivers/staging/media/davinci_vpfe/dm365_resizer.c: In function 'resizer_set_defualt_configuration':
drivers/staging/media/davinci_vpfe/dm365_resizer.c:831:16: error: initialized field overwritten [-Werror=override-init]
drivers/staging/media/davinci_vpfe/dm365_resizer.c:831:16: note: (near initialization for 'rsz_default_config.rsz_rsc_param[0].h_typ_c')
drivers/staging/media/davinci_vpfe/dm365_resizer.c:849:16: error: initialized field overwritten [-Werror=override-init]
drivers/staging/media/davinci_vpfe/dm365_resizer.c:849:16: note: (near initialization for 'rsz_default_config.rsz_rsc_param[1].h_typ_c')

All of them are trivial to fix without changing the behavior of the
driver, as "static const" is interpreted the same as "const static",
and VPFE_RSZ_INTP_CUBIC is defined as zero, so the initializations
are not really needed.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: media: davinci_vfpe: allow modular build
Arnd Bergmann [Wed, 11 May 2016 13:29:44 +0000 (10:29 -0300)]
[media] staging: media: davinci_vfpe: allow modular build

It has never been possible to actually build this driver as
a loadable module, only built-in because the Makefile attempts
to build each file into its own module and fails:

ERROR: "mbus_to_pix" [drivers/staging/media/davinci_vpfe/vpfe_video.ko] undefined!
ERROR: "vpfe_resizer_register_entities" [drivers/staging/media/davinci_vpfe/vpfe_mc_capture.ko] undefined!
ERROR: "rsz_enable" [drivers/staging/media/davinci_vpfe/dm365_resizer.ko] undefined!
ERROR: "config_ipipe_hw" [drivers/staging/media/davinci_vpfe/dm365_ipipe.ko] undefined!
ERROR: "ipipe_set_lutdpc_regs" [drivers/staging/media/davinci_vpfe/dm365_ipipe.ko] undefined!

It took a long time to catch this bug with randconfig builds
because at least 14 other Kconfig symbols have to be enabled in
order to configure this one, and it was clearly only ever tested
as built-in with mainline kernels, if at all.

The solution is really easy: this patch changes the Makefile to
link all files into one module. As discussed previously, the
driver has never before used successfully as a loadable module,
but there is no reason to prevent that configuration.

Link: http://lkml.iu.edu/hypermail/linux/kernel/1512.1/02383.html
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: media: davinci_vpfe: Fix spelling error on a comment
Manuel Rodriguez [Tue, 8 Mar 2016 07:16:06 +0000 (04:16 -0300)]
[media] staging: media: davinci_vpfe: Fix spelling error on a comment

Fix spelling error on a comment, change 'wether' to 'whether'

Signed-off-by: Manuel Rodriguez <manuel2982@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: media: davinci_vpfe: dm365_resizer: Fix some spelling mistakes
Saatvik Arya [Wed, 3 Feb 2016 02:26:42 +0000 (00:26 -0200)]
[media] staging: media: davinci_vpfe: dm365_resizer: Fix some spelling mistakes

Fix spelling mistakes which referred to OUTPUT as OUPUT.

Signed-off-by: Saatvik Arya <aryasaatvik@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] mceusb: remove pointless mce_flush_rx_buffer function
Sean Young [Thu, 14 Apr 2016 20:42:50 +0000 (17:42 -0300)]
[media] mceusb: remove pointless mce_flush_rx_buffer function

This function just submits the urb much like mceusb_dev_resume; removing
it simplifies mce_request_packet.

Also add missing usb_kill_urb to mce_dev_probe.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] mceusb: remove useless debug message
Sean Young [Thu, 14 Apr 2016 20:42:49 +0000 (17:42 -0300)]
[media] mceusb: remove useless debug message

Such debug message has a logic to track the IR status,
but it doesn't provide much info. So, get rid of it.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: Update documentation for media_entity_notify
Shuah Khan [Mon, 14 Mar 2016 22:24:25 +0000 (19:24 -0300)]
[media] media: Update documentation for media_entity_notify

Update documentation for media_entity_notify to clearly state the usage
restrictions. This handler is intended for creating links between exiting
entities and should not used to create and register entities.

Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] Raise adapter number limit
Буди Романто, AreMa Inc [Tue, 5 Apr 2016 16:14:10 +0000 (13:14 -0300)]
[media] Raise adapter number limit

The current limit is too low for latest cards with 8+ tuners on a single slot.
IMHO, the most appropriate minimum default is 16.

Signed-off-by: Буди Романто, AreMa Inc <knightrider@are.ma>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] em28xx: only use mt9v011 if camera support is enabled
Arnd Bergmann [Tue, 26 Jan 2016 14:09:59 +0000 (12:09 -0200)]
[media] em28xx: only use mt9v011 if camera support is enabled

In randconfig builds that select VIDEO_EM28XX_V4L2 and
MEDIA_SUBDRV_AUTOSELECT, but not MEDIA_CAMERA_SUPPORT, we get
a Kconfig warning:

 warning: (VIDEO_EM28XX_V4L2) selects VIDEO_MT9V011 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT)

This avoids the warning by making that 'select' conditional on
MEDIA_CAMERA_SUPPORT. Alternatively we could mark EM28XX as
'depends on MEDIA_CAMERA_SUPPORT', but it does not seem to
have any real dependency on that itself.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] go7007: add MEDIA_CAMERA_SUPPORT dependency
Arnd Bergmann [Tue, 26 Jan 2016 14:10:01 +0000 (12:10 -0200)]
[media] go7007: add MEDIA_CAMERA_SUPPORT dependency

If MEDIA_SUBDRV_AUTOSELECT and VIDEO_GO7007 are both set, we
automatically select VIDEO_OV7640, but that depends on MEDIA_CAMERA_SUPPORT,
so we get a Kconfig warning if that is disabled:

warning: (VIDEO_GO7007) selects VIDEO_OV7640 which has unmet direct dependencies (MEDIA_SUPPORT && I2C && VIDEO_V4L2 && MEDIA_CAMERA_SUPPORT)

This adds another dependency so we don't accidentally select
it when it is unavailable.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] dvb: remove unused systime() function
Arnd Bergmann [Thu, 17 Sep 2015 21:19:33 +0000 (18:19 -0300)]
[media] dvb: remove unused systime() function

The systime function uses struct timespec, which we want to stop
using in the kernel because it overflows in 2038. Fortunately,
this use in dibx000_common is in a function that is never called,
so we can just remove it.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] stv090x: use lookup tables for carrier/noise ratio
Joerg Riechardt [Sat, 29 Aug 2015 15:02:57 +0000 (12:02 -0300)]
[media] stv090x: use lookup tables for carrier/noise ratio

The stv090x driver uses the lookup table for signal strength already,
with this patch we use the lookup tables for carrier/noise ratio as well.
This has the advantage, that values for DVB-S and DVB-S2 are now
corresponding, while before they were way off. The values are now
proportional to real carrier/noise ratio, while before they were
corresponding to register values. So now applications are able to give
the user real carrier/noise ratio.

Because the output has to be within 0x0000...0xFFFF the three negative
values for DVB-S2 are omitted. This is no significant loss, because
reception is lost at 7.5 dB already (TT S2-1600, Cine S2), so the
negative values are not really important, and also for DVB-S they don´t
exist.

Signed-off-by: Joerg Riechardt <j.riechardt@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] netup_unidvb: use module_pci_driver
Geliang Tang [Wed, 16 Nov 2016 13:00:56 +0000 (11:00 -0200)]
[media] netup_unidvb: use module_pci_driver

Use module_pci_driver() helper to simplify the code.

Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] stk-webcam: fix an endian bug in stk_camera_read_reg()
Dan Carpenter [Wed, 16 Nov 2016 11:11:54 +0000 (09:11 -0200)]
[media] stk-webcam: fix an endian bug in stk_camera_read_reg()

We pass an int pointer to stk_camera_read_reg() but only write to the
highest byte.  It's a bug on big endian systems and generally a nasty
thing to do and doesn't match the write function either.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] ir-hix5hd2: make hisilicon,power-syscon property deprecated
Ruqiang Ju [Tue, 15 Nov 2016 07:31:32 +0000 (05:31 -0200)]
[media] ir-hix5hd2: make hisilicon,power-syscon property deprecated

The clock of IR can be provided by the clock provider and controlled
by common clock framework APIs.

Signed-off-by: Ruqiang Ju <juruqiang@huawei.com>
Signed-off-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] mn88473: refactor and fix statistics
Antti Palosaari [Sun, 13 Nov 2016 07:25:54 +0000 (05:25 -0200)]
[media] mn88473: refactor and fix statistics

Remove DVB-T2 BER as it does not work at all and I didn't find
how to fix.

Fix DVB-T and DVB-C BER. It seems to return new some realistic
looking values.

Use (1 << 24) base for CNR calculations to keep it in line with
dvb logarithm functions.

Move all statistic logic to mn88473_read_status() function.

Use regmap_bulk_read() for reading multiple registers as a one go.

Many more and less minor changes.

Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] mn88473: add DVBv5 statistics support
Martin Blumenstingl [Sat, 24 Sep 2016 22:40:19 +0000 (19:40 -0300)]
[media] mn88473: add DVBv5 statistics support

Implement DVBv5 statistics support for DVB-T, DVB-T2 and DVB-C. All
information was taken from the LinuxTV wiki, where Benjamin Larsson has
documented all registers:
https://www.linuxtv.org/wiki/index.php/Panasonic_MN88472

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] staging: lirc: Improvement in code readability
Shailendra Verma [Thu, 10 Nov 2016 09:52:38 +0000 (07:52 -0200)]
[media] staging: lirc: Improvement in code readability

There is no need to call kfree() if memdup_user() fails, as no memory
was allocated and the error in the error-valued pointer should be returned.

Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] sanyo decoder: address was being truncated
Sean Young [Wed, 9 Nov 2016 16:13:34 +0000 (14:13 -0200)]
[media] sanyo decoder: address was being truncated

The address is 13 bits but it was stuffed in an u8, so 5 bits are
missing from the scancode.

Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] v4l: compat: Prevent allocating excessive amounts of memory
Sakari Ailus [Tue, 8 Nov 2016 16:06:44 +0000 (14:06 -0200)]
[media] v4l: compat: Prevent allocating excessive amounts of memory

get_v4l2_ext_controls32() is used to convert the 32-bit compat struct into
native 64-bit representation. The function multiplies the array length by
the entry length before validating size. Perform the size validation
first.

Also use unsigned values for size computation.

Make similar changes to get_v4l2_buffer32() for multi-plane buffers.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] ti-vpe: get rid of some smatch warnings
Mauro Carvalho Chehab [Tue, 22 Nov 2016 11:05:59 +0000 (09:05 -0200)]
[media] ti-vpe: get rid of some smatch warnings

When compiled on i386, it produces several warnings:

./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:457:22: warning: asm output is not an lvalue

I suspect that some gcc optimization could be causing the asm code to be
incorrectly generated. Splitting it into two macro calls fix the issues
and gets us rid of 6 smatch warnings, with is a good thing. As it should
not cause any troubles, as we're basically doing the same thing, let's
apply such change to vpe.c.

Cc: Benoit Parrot <bparrot@ti.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] vpdma: remove vpdma_enable_list_notify_irq()
Mauro Carvalho Chehab [Tue, 22 Nov 2016 10:15:15 +0000 (08:15 -0200)]
[media] vpdma: remove vpdma_enable_list_notify_irq()

Despite being exported, there's no prototype for it at the
headers, as warned by sparse:

Fixes this sparse warning:
drivers/media/platform/ti-vpe/vpdma.c:1000:6: warning: no previous prototype for 'vpdma_enable_list_notify_irq' [-Wmissing-prototypes]
 void vpdma_enable_list_notify_irq(struct vpdma_data *vpdma, int irq_num,
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Worse than that, it is not even used, as making it static it
would produce:

drivers/media/platform/ti-vpe/vpdma.c:1000:13: warning: 'vpdma_enable_list_notify_irq' defined but not used [-Wunused-function]
 static void vpdma_enable_list_notify_irq(struct vpdma_data *vpdma, int irq_num,
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

So, let's just get rid of the dead code. If needed in the future,
someone could re-add it.

Cc: Benoit Parrot <bparrot@ti.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] vpfe_capture: fix compiler warning
Hans Verkuil [Mon, 21 Nov 2016 13:59:20 +0000 (11:59 -0200)]
[media] vpfe_capture: fix compiler warning

davinci/vpfe_capture.c: In function 'vpfe_probe':
davinci/vpfe_capture.c:1992:9: warning: 'ret' may be used uninitialized
in this function [-Wmaybe-uninitialized]
   return ret;
          ^~~

This is indeed correct, so if the kmalloc fails set ret to -ENOMEM.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Add proper support single and multi-plane buffer
Benoit Parrot [Fri, 18 Nov 2016 23:20:45 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Add proper support single and multi-plane buffer

The VPE was restricting the number of plane per buffer based on
the fact that if a particular format had color separation it was
meant to need 2 planes.

However NV12/NV16 are color separate format which are meant to be
presented in a single contiguous buffer/plane.
It could also be presented in a multi-plane as well if need be.
So we must support both modes for more flexibility.

The number of plane requested by user space was previously ignored
and was therefore always overwritten.
The driver now use the requested num plane as hint to calculate needed
offset when required.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: csc: Add debug support for multi-instance
Benoit Parrot [Fri, 18 Nov 2016 23:20:44 +0000 (21:20 -0200)]
[media] media: ti-vpe: csc: Add debug support for multi-instance

Since there might be more then one instance it is better to
show the base address when dumping registers to help
with debugging.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: Make colorspace converter library into its own module
Benoit Parrot [Fri, 18 Nov 2016 23:20:43 +0000 (21:20 -0200)]
[media] media: ti-vpe: Make colorspace converter library into its own module

In preparation to add colorspace conversion support to VIP,
we need to turn csc.c into its own kernel module.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Add RAW8 and RAW16 data types
Benoit Parrot [Fri, 18 Nov 2016 23:20:42 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Add RAW8 and RAW16 data types

Add RAW8 and RAW16 data type to VPDMA.
To handle RAW format we are re-using the YUV CBY422
vpdma data type so that we use the vpdma to re-order
the incoming bytes, as the VIP parser assumes that the
first byte presented on the bus is the MSB of a 2
bytes value.

RAW8 handles from 1 to 8 bits.
RAW16 handles from 9 to 16 bits.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Make sure frame size dont exceed scaler capacity
Benoit Parrot [Fri, 18 Nov 2016 23:20:41 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Make sure frame size dont exceed scaler capacity

When scaler is to be used we need to make sure that the input and
output frame size do not exceed the maximum frame sizes that the
scaler h/w can handle otherwise streaming stall as the scaler
cannot proceed.

The scaler buffer is limited to 2047 pixels (i.e. 11 bits) when
attempting anything larger (2048 for example) the scaler stalls.

Realistically in an mem2mem device we can only check for this type
of issue when start_streaming is called. We can't do it during the
try_fmt/s_fmt because we do not have all of the info needed at that
point. So instead when start_streaming is called we need to check
that the input and output frames size do not exceed the scaler's
capability. The only time larger frame size are allowed is when
the input frame szie is the same as the output frame size.

Now in the case where we need to fail, start_streaming must return
all previously queued buffer back otherwise the vb2 framework
will issue kernel WARN messages.
In this case we also give an error message.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: scaler: Add debug support for multi-instance
Benoit Parrot [Fri, 18 Nov 2016 23:20:40 +0000 (21:20 -0200)]
[media] media: ti-vpe: scaler: Add debug support for multi-instance

Since there might be more then one instance it is better to
show the base address when dumping registers to help
with debugging.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: Make scaler library into its own module
Benoit Parrot [Fri, 18 Nov 2016 23:20:39 +0000 (21:20 -0200)]
[media] media: ti-vpe: Make scaler library into its own module

In preparation to add scaler support into VIP we need to
turn sc.c into its own kernel module.

Add support for multiple SC memory block as VIP contains
2 scaler instances.
This is done by passing the resource name to sc_create() and
modify the vpe invocation accordingly.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Enable DMABUF export
Benoit Parrot [Fri, 18 Nov 2016 23:20:38 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Enable DMABUF export

Allow VPE to be able to export DMA buffer.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Fix line stride for output motion vector
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:37 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Fix line stride for output motion vector

For deinterlacing operation, VPE hardware uses motion vectors.
MV calculated in the previous iteration are used for next interation.
Therefore driver allocates two motion vectors in ping-pong fashion.

For every transaction, one MV is DMAed in and one is DMAed out.
All the outbound DMAs (DMA to memory) use output parameters, but as
the motion vectors is generated purely out of input fields, it should
use the input parameters for DMA.

Fix the add_out_dtd to use source q_data for creating descriptor.
If the output size is greater than input stride, without this change,
MV DMA may overwrite the buffer causing memory corruption.

This CRITICAL fix ensures that the motion vector DMA descriptor is
created based on the attributes with which the buffer was allocated.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Use bidirectional cached buffers
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:36 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Use bidirectional cached buffers

VPDMA buffer will be used by CPU as well as by the VPDMA.
CPU will write/update the VPDMA descriptors containing data
about the video buffer DMA addresses.
VPDMA will write the "write descriptor" containing the
data about the DMA operation.

When mapping/unmapping the buffer, driver has to take care of
WriteBack and invalidation of the cache so that all the
coherency is maintained from both directions.

Use DMA_BIDIRECTIONAL to maintain coherency between CPU and VPDMA.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Fix race condition for firmware loading
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:35 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Fix race condition for firmware loading

vpdma_create API is supposed to allocated the struct vpdma_data and
return it to the driver. Also, it would call the callback function
when the VPDMA firmware is loaded.

Typically, VPE driver have following function call:
    dev->vpdma = vpdma_create(pdev, firmware_load_callback);
And the callback implementation would continue the probe further.
Also, the dev->vpdma is accessed from the callback implementation.

This may lead to race condition between assignment of dev->vpdma
and the callback function being triggered.
This would lead to kernel crash because of NULL pointer access.

Fix this by passing a driver wrapped &vpdma_data instead of allocating
inside vpdma_create.
Change the vpdma_create prototype accordingly and fix return paths.

Also, update the VPE driver to use the updated API and
initialize the dev->vpdma before hand so that the race condition
is avoided.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Fix vb2 buffer cleanup
Benoit Parrot [Fri, 18 Nov 2016 23:20:34 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Fix vb2 buffer cleanup

When stop_streaming is called we need to cleanup the queued
vb2 buffers properly.
This was not previously being done which caused kernel
warning when the application using the resources was killed.
Kernel warnings were also generated on successful completion
of a de-interlacing case as well as upon aborting a
conversion.

Make sure every vb2 buffers is properly handled in all cases.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: sc: Fix incorrect optimization
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:33 +0000 (21:20 -0200)]
[media] media: ti-vpe: sc: Fix incorrect optimization

Current scaler library implementation of sc_set_hs_coeffs and
sc_set_vs_coeffs tries to return immediately if the calculated
coefficient index is already being used.

As the same scaler block is going to be used for all the VPE contexts,
even if the calculated index is same, the parameters have to be
reconfigured for each of the context.

Because of this, when multiple contexts use the same coefficients,
all other contexts would have zero scaling coefficients.
Fix this and also remove the unnecessary hs_index and vs_index fields.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: RGB data type yield inverted data
Benoit Parrot [Fri, 18 Nov 2016 23:20:32 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: RGB data type yield inverted data

The VPDMA RGB data type definition have been updated
to match with Errata i839.

But some of the ARGB definition appeared to be wrong
in the document also. As they would yield RGBA instead.
They have been corrected based on experimentation.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Corrected YUV422 data type label
Benoit Parrot [Fri, 18 Nov 2016 23:20:31 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Corrected YUV422 data type label

The YUV data type definition below are taken from
both the TRM and i839 Errata information.
Use the correct data type considering byte
reordering of components.

Added the 2 missing YUV422 variant.
Also since the single use of "C" in the 422 case
to mean "Cr" (i.e. V component). It was decided
to explicitly label them CR to remove any confusion.
Bear in mind that the type label refer to the memory
packed order (LSB - MSB).

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Added MODULE_DEVICE_TABLE hint
Benoit Parrot [Fri, 18 Nov 2016 23:20:30 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Added MODULE_DEVICE_TABLE hint

ti_vpe module currently does not get loaded automatically.
Added MODULE_DEVICE_TABLE hint to the driver to assist.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: allocate and maintain hwlist
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:29 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: allocate and maintain hwlist

VPDMA block used in ti-vip and ti-vpe modules have support for
up to 8 hardware descriptor lists. A descriptor list can be
submitted to any of the 8 lists (as long as it's not busy).

When multiple clients want to transfer data in parallel, its easier
to allocate one list per client and let it use it. This way, the
list numbers need not be hard-coded into the driver.

Add support for allocating hwlist and maintain them with a priv data.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Add RGB565 and RGB5551 support
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:28 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Add RGB565 and RGB5551 support

VPE hardware can generate output in RGB565 or in RGB5551 format.
Add these formats in the supported format list for CAPTURE stream.
Also, for RGB5551 format, the alpha component is not processed,
so the alpha value is taken from the default color.
Set the default color to make alpha component full when the dst
format is of RGB color space.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Post next descriptor only for list complete IRQ
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:27 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Post next descriptor only for list complete IRQ

vpe_irq checks for the possible interrupt sources and prints the
errors for the DEI_ERROR and DS_UV interrupts. But it also post the
next descriptor list irrespective of whichever interrupt has occurred.

Because of this, driver may release the buffers even before DMA is
complete and also schedule next descriptor list.

Fix this by _actually_ handling the IRQ only when ListComplete IRQ
occurs.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Setup srcdst parameters in start_streaming
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:26 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Setup srcdst parameters in start_streaming

For deinterlacing operation, each operation needs 2 fields in the
history. This is achieved by holding three buffers in
ctx->src_vbs[0,1,2] (f,f-1,f-2)

This is achieved by using the ctx->sequence which gets reset via the
s_fmt ioctl.

These buffers are dequeued in stream OFF by calling free_vbs()
But the corresponding references aren't removed anywhere.

When application tries to stream ON and OFF continuously, s_fmt ioctl
won't be called and it won't setup the srcdst parameters.

Setting source/destination parameters in stream ON ioctl would make
sure that the context is re-initialized before it is being used by
the driver.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: configure line mode separately
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:25 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: configure line mode separately

Current driver configures the line mode of the DEI clients
from the open function directly. Even if the newly created context
is not yet scheduled, it updates some of the VPDMA registers.
This causes a problem in multi instance use case where just opening
the m2m device second time causes the running job to stall. This
happens especially if the source buffers used are NV12.

While all other configuration is being written to context specific
shadow registers, only line mode configuration is happening directly.

As there is no shadow register for line mode configuration, it's better
to separate the config_mode setting and line_mode setting. Call the
new "set_line_modes" functions only when actually loading the mmrs.
This makes sure that no non-running job will write to the registers
directly.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Clear IRQs for individual lists
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:24 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Clear IRQs for individual lists

VPDMA IRQs are registered for multiple lists
When clearing an IRQ for a list interrupt, all the
IRQs for the individual lists are to be cleared separately.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Make list post atomic operation
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:23 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Make list post atomic operation

Writing to the "VPDMA list attribute" register is considered as a list
post. This informs the VPDMA firmware to load the list from the address
which should be taken from the "VPDMA list address" register.

As these two register writes are dependent, it is important that the two
writes happen in atomic manner. This ensures multiple slices (which share
same VPDMA) can post lists asynchronously and all of them point to the
correct addresses.

Slightly modified to implementation for the original patch to use
spin_lock instead of mutex as the list post is also called from
interrupt context.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Add abort channel desc and cleanup APIs
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:22 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Add abort channel desc and cleanup APIs

Whenever VPDMA processes a data descriptor of a list, it processes it
and sets up the channel for the DMA transaction. List manager holds the
descriptor in the list until the DMA is complete. If sync_on_channel
descriptor, or another descriptor for the same channel is present in
the FIFO, list manager keeps them until the current channel is free.

When the capture stream is closed suddenly while there are pending
descriptors in the FIFO (streamON failed, application killed), it would
keep the VPDMA in a busy state. Any further list post would fail with
EBUSY.

To avoid this, drivers need to stop the current processing list and
cleanup all the resources VPDMA has taken and also clear the internal FSM
of list manager. The state machine is cleared by issuing channel specific
abort descriptor.

Therefore, the vpdma_list_cleanup accepts an array of channels for which
abort_channel descriptors should be posted. It is driver's responsibility
to post for all the channels or the channels which were used in the last
context.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpdma: Add support for setting max width height
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:21 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpdma: Add support for setting max width height

Add a helper function to be able to set the maximum
VPDMA transfer size to limit potential buffer overrun.

Added enums for max_width and max_height fields of the
outbound data descriptor.

Changed vpdma_add_out_dtd to accept two more arguments
for max width and height.

Make use of different max width & height sets for different
of capture module (i.e. slices).

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: Free vpdma buffers in vpe_release
Harinarayan Bhatta [Fri, 18 Nov 2016 23:20:20 +0000 (21:20 -0200)]
[media] media: ti-vpe: Free vpdma buffers in vpe_release

Free vpdma buffers in vpe_release. Otherwise it was generating random
backtrace.

Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
Signed-off-by: Somnath Mukherjee <somnath@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Return NULL for invalid buffer type
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:19 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Return NULL for invalid buffer type

get_q_data can be called with different values for type
e.g. vpe_try_crop calls it with the buffer type which gets passed
from user space

Framework doesn't check wheather its correct type or not
If user space passes wrong type, kernel should not crash.
Return NULL when the passed type is invalid.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: Increasing max buffer height and width
Harinarayan Bhatta [Fri, 18 Nov 2016 23:20:18 +0000 (21:20 -0200)]
[media] media: ti-vpe: Increasing max buffer height and width

Increasing max buffer height and width to allow for padded buffers.

Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: Add support for SEQ_TB buffers
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:17 +0000 (21:20 -0200)]
[media] media: ti-vpe: Add support for SEQ_TB buffers

The video source can generate the data in the SEQ_TB buffer format.
In the case of TI SoC, the IVA_HD can generate the interlaced content in
the SEQ_TB buffer format. This is the format where the top and bottom field
data can be contained in a single buffer. For example, for NV12, interlaced
format, the data in Y buffer will be arranged as Y-top followed by
Y-bottom. And likewise for UV plane.

Also, queuing one buffer of SEQ_TB is equivalent to queuing two different
buffers for top and bottom fields. Driver needs to take care of this when
handling source buffer lists.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
8 years ago[media] media: ti-vpe: vpe: Do not perform job transaction atomically
Nikhil Devshatwar [Fri, 18 Nov 2016 23:20:16 +0000 (21:20 -0200)]
[media] media: ti-vpe: vpe: Do not perform job transaction atomically

Current VPE driver does not start the job until all the buffers for
a transaction are queued. When running in multiple context, this might
increase the processing latency.

Alternate solution would be to try to continue the same context as long as
buffers for the transaction are ready; else switch the context. This may
increase number of context switches but it reduces latency significantly.

In this approach, the job_ready always succeeds as long as there are
buffers on the CAPTURE and OUTPUT stream. Processing may start immediately
as the first 2 iterations don't need extra source buffers. Shift all the
source buffers after each iteration and remove the oldest buffer.

Also, with this removes the constraint of pre buffering 3 buffers before
call to STREAMON in case of de-interlacing.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>