linux-toradex.git/drivers/media, branch v3.14.24

media: tda7432: Fix setting TDA7432_MUTE bit for TDA7432_RF register

2014-11-14T16:59:54+00:00

commit 91ba0e59babdb3c7aca836a65f1095b3eaff7b06 upstream.

Fix a copy-paste bug when converting to the control framework.

Fixes: commit 5d478e0de871 ("[media] tda7432: convert to the control framework")

Signed-off-by: Axel Lin 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: ds3000: fix LNB supply voltage on Tevii S480 on initialization

2014-11-14T16:59:54+00:00

commit 8c5bcded11cb607b1bb5920de3b9c882136d27db upstream.

The Tevii S480 outputs 18V on startup for the LNB supply voltage and does not
automatically power down. This blocks other receivers connected
to a satellite channel router (EN50494), since the receivers can not send the
required DiSEqC sequences when the Tevii card is connected to a the same SCR.

This patch switches off the LNB supply voltage on initialization of the frontend.

[mchehab@osg.samsung.com: add a comment about why we're explicitly
 turning off voltage at device init]
Signed-off-by: Ulrich Eckhardt 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: em28xx-v4l: give back all active video buffers to the vb2 core properly on streaming stop

2014-11-14T16:59:54+00:00

commit 627530c32a43283474e9dd3e954519410ffa033a upstream.

When a new video frame is started, the driver takes the next video buffer from
the list of active buffers and moves it to dev->usb_ctl.vid_buf / dev->usb_ctl.vbi_buf
for further processing.

On streaming stop we currently only give back the pending buffers from the list
but not the ones which are currently processed.

This causes the following warning from the vb2 core since kernel 3.15:

...
 ------------[ cut here ]------------
 WARNING: CPU: 1 PID: 2284 at drivers/media/v4l2-core/videobuf2-core.c:2115 __vb2_queue_cancel+0xed/0x150 [videobuf2_core]()
 [...]
 Call Trace:
  [] dump_stack+0x48/0x69
  [] warn_slowpath_common+0x79/0x90
  [] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
  [] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
  [] warn_slowpath_null+0x1d/0x20
  [] __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
  [] vb2_internal_streamoff+0x35/0x90 [videobuf2_core]
  [] vb2_streamoff+0x35/0x60 [videobuf2_core]
  [] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core]
  [] v4l_streamoff+0x15/0x20 [videodev]
  [] __video_do_ioctl+0x23d/0x2d0 [videodev]
  [] ? video_ioctl2+0x20/0x20 [videodev]
  [] video_usercopy+0x203/0x5a0 [videodev]
  [] ? video_ioctl2+0x20/0x20 [videodev]
  [] ? fsnotify+0x1e7/0x2b0
  [] video_ioctl2+0x12/0x20 [videodev]
  [] ? video_ioctl2+0x20/0x20 [videodev]
  [] v4l2_ioctl+0xee/0x130 [videodev]
  [] ? v4l2_open+0xf0/0xf0 [videodev]
  [] do_vfs_ioctl+0x2e2/0x4d0
  [] ? vfs_write+0x13c/0x1c0
  [] ? vfs_writev+0x2f/0x50
  [] SyS_ioctl+0x58/0x80
  [] sysenter_do_call+0x12/0x12
 ---[ end trace 5545f934409f13f4 ]---
...

Many thanks to Hans Verkuil, whose recently added check in the vb2 core unveiled
this long standing issue and who has investigated it further.

Signed-off-by: Frank Schäfer 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: m88ts2022: fix 32bit overflow on filter calc

2014-11-14T16:59:54+00:00

commit f538e085138e519e25ae0828bd6c6e7492ce8ca4 upstream.

Maximum satellite symbol rate used is 45000000Sps which overflows
when multiplied by 135. As final calculation result is fraction,
we could use mult_frac macro in order to keep calculation inside
32 bit number limits and prevent overflow.

Original bug and fix was provided by Nibble Max. I decided to
implement it differently as it is now.

Reported-by: Nibble Max 
Tested-by: Nibble Max 
Signed-off-by: Antti Palosaari 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: em28xx: check if a device has audio earlier"

2014-11-14T16:59:53+00:00

commit fb91bde9d3664dd879655f3a1013c0b5728e7a09 upstream.

GIT_AUTHOR_DATE=1409603039
This reverts

commit b99f0aadd33fad269c8e62b5bec8b5c012a44a56
Author: Mauro Carvalho Chehab 

    [media] em28xx: check if a device has audio earlier

    Better to split chipset detection from the audio setup. So, move the
    detection code to em28xx_init_dev().

It broke analog audio of the Hauppauge winTV HVR 900 and very likely many other
em28xx devices.

Background:
The local variable has_audio in em28xx_usb_probe() describes if the currently
probed _usb_interface_ has an audio endpoint, while dev->audio_mode.has_audio
means that the _device_ as a whole provides analog audio.
Hence it is wrong to set dev->audio_mode.has_audio = has_audio in em28xx_usb_probe().
As result, audio support is no longer detected and configured on devices which
have the audio endpoint on a separate interface, because em28xx_audio_setup()
bails out immediately at the beginning.

Revert the faulty commit to restore the old audio detection procedure, which checks
the chip configuration register to determine if the device has analog audio.

Cc: 	# 3.14 to 3.16
Reported-by: Oravecz Csaba 
Tested-by: Oravecz Csaba 
Signed-off-by: Frank Schäfer 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: usb: uvc: add a quirk for Dell XPS M1330 webcam

2014-11-14T16:59:53+00:00

commit 62ea864f84fed6e04dd033d500d4c9183a83d590 upstream.

As reported on [1], this device needs this quirk to be able to
reliably initialise the webcam.

[1] http://ubuntuforums.org/showthread.php?t=2145996

Cc: stable@vger.kernel.org
Signed-off-by: Paul Fertser 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: v4l2-common: fix overflow in v4l_bound_align_image()

2014-11-14T16:59:53+00:00

commit 3bacc10cd4a85bc70bc0b6c001d3bf995c7fe04c upstream.

Fix clamp_align() used in v4l_bound_align_image() to prevent overflow
when passed large value like UINT32_MAX.

 In the current implementation:
    clamp_align(UINT32_MAX, 8, 8192, 3)

returns 8, because in line:

    x = (x + (1 << (align - 1))) & mask;

x overflows to (-1 + 4) & 0x7 = 3, while expected value is 8192.

v4l_bound_align_image() is heavily used in VIDIOC_S_FMT and
VIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter
explicitly states that:

"The modified format should be as close as possible to the original
request."
  -- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html

Thus one would expect, that passing UINT32_MAX as format width and
height will result in setting maximum possible resolution for the
device. Particularly, when the driver doesn't support
VIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase.

Fixes changeset: b0d3159be9a3

Signed-off-by: Maciej Matraszek 
Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: vb2: fix VBI/poll regression

2014-10-09T19:21:27+00:00

commit 58d75f4b1ce26324b4d809b18f94819843a98731 upstream.

The recent conversion of saa7134 to vb2 unconvered a poll() bug that
broke the teletext applications alevt and mtt. These applications
expect that calling poll() without having called VIDIOC_STREAMON will
cause poll() to return POLLERR. That did not happen in vb2.

This patch fixes that behavior. It also fixes what should happen when
poll() is called when STREAMON is called but no buffers have been
queued. In that case poll() will also return POLLERR, but only for
capture queues since output queues will always return POLLOUT
anyway in that situation.

This brings the vb2 behavior in line with the old videobuf behavior.

Signed-off-by: Hans Verkuil 
Acked-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: adv7604: fix inverted condition

2014-10-05T21:52:23+00:00

commit 77639ff2b3404a913b8037d230a384798b854bae upstream.

The log_status function should show HDMI information, but the test checking for
an HDMI input was inverted. Fix this.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

media: cx18: fix kernel oops with tda8290 tuner

2014-10-05T21:52:23+00:00

commit 6a03dc92cc2edfa2257502557b9f714893987383 upstream.

This was caused by an uninitialized setup.config field.

Based on a suggestion from Devin Heitmueller.

Signed-off-by: Hans Verkuil 
Thanks-to: Devin Heitmueller 
Reported-by: Scott Robinson 
Tested-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman