vidioc_s_fmt_vbi_cap() is a 100% duplicate of vidioc_g_fmt_vbi_cap() and
therefore can be removed.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The em28xx driver doesn't support the VIDIOC_G_CROP and VIDIOC_S_CROP ioctls,
so VIDIOC_CROPCAP is useless and has the potential to confuse applications,
because it can be interpreted as indicator for cropping support.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the current code V4L2_BUF_TYPE_VIDEO_CAPTURE is accepted only, but for VBI
devices only buffer type V4L2_BUF_TYPE_VBI_CAPTURE is used/valid.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
VIDIOC_S_PARM doesn't make sense for VBI device nodes, because we don't support
selecting the number of read buffers to use.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of checking the device type and returning -ENOTTY inside the ioctl
function, use v4l2_disable_ioctl() to disable the ioctl VIDIOC_S_PARM if the
device is not a camera.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of checking the device type and returning -EINVAL inside the ioctl
functions, use v4l2_disable_ioctl() to disable the ioctls VIDIOC_G_AUDIO and
VIDIOC_S_AUDIO if the device doesn't support audio.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Disable the ioctls VIDIOC_G_TUNER, VIDIOC_S_TUNER, VIDIOC_G_FREQUENCY and
VIDIOC_S_FREQUENCY for video and VBI devices without tuner.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of checking the device type and returning -ENOTTY inside the ioctl
functions, use v4l2_disable_ioctl() to disable the ioctls VIDIOC_QUERYSTD,
VIDIOC_G_STD and VIDIOC_S_STD if the device is a camera.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Seems to work just the same as older revisions.
Signed-off-by: Roland Scheidegger <rscheidegger_lists@hispeed.ch>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the conversion to videobuf2, some unnecessary calls of
em28xx_set_alternate() have been removed. It is now called at analog streaming
start only.
This has unveiled a bug that causes USB bulk transfers to fail with all urbs
having status -EVOERFLOW.
The reason is, that for bulk transfers usb_set_interface() needs to be called
even if the previous alt setting was the same (side note: bulk transfers seem
to work only with alt=0).
While it seems to be NOT necessary for isoc transfers, it's reasonable to just
call usb_set_interface() unconditionally in em28xx_set_alternate().
Also add a comment that explains the issue to prevent regressions in the future.
Cc: stable@vger.kernel.org # for 3.8
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The bytesperline calculation was incorrect: it used the old width instead of
the provided width. Fixed.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- move the bit shifting of width+height values inside the function
- fix the debug message format and output values
- add comment about the size limit (e.g. EM277x supports >2MPix)
- make void, because error checking is incomplete and we never check the
returned value (we would continue anyway)
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove em28xx_i2c_ir_work() and check the device type in the common callback
function em28xx_ir_work() instead. Simplifies em28xx_ir_start().
Reduces the code size with a minor performance drawback.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Set up the i2c_client locally in em28xx_i2c_ir_handle_key().
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We already have the key polling functions and the polling infrastructure in
em28xx-input, so we can easily get rid of the dependency on module ir-kbd-i2c.
For maximum safety, do not touch the key reporting mechanism for those devices.
Code size could be improved further but would have minor peformance impacts.
Tested with device "Terratec Cinergy 200 USB" (EM2800_BOARD_TERRATEC_CINERGY_200)
[mchehab@redhat.com: Fix two checkpatch.pl warnings:
ERROR: "foo * bar" should be "foo *bar" (line 465)
WARNING: kfree(NULL) is safe this check is probably not required (line 725)]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We don't report any key/scan codes or errors inside the key polling functions
for internal IR RC devices, just in the key handling fucntions.
Do the same for external devices.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Field 'old' of struct IR_i2c is used nowhere in module ir-kbd-i2c.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remy Blank reported that audio over USB can be made working for the television
input if .amux is changed from EM28XX_AMUX_LINE_IN to EM28XX_AMUX_VIDEO.
An examination of his devices shows, that it is indeed supplied with an EM202
AC97 audio IC. We also use this setting for the Cinergy 200.
Remy Blank also provided the original version of this patch (many thanks !).
Fixes bug 14126 (see bug report for further device details).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Remy Blank <remy.blank@pobox.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Now that it uses videobuf2, em28xx can support DMABUF.
Tested with an HVR-950 on analog mode and a 2gen i5core machine
with an i915 graphics adapter.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
That fixes the following warning:
drivers/media/usb/em28xx/em28xx-video.c:611:5: warning: no previous prototype for 'em28xx_stop_streaming' [-Wmissing-prototypes]
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
EEPROMs are currently read in blocks of 16 bytes, but the em2800 is limited
to 4 bytes per read. All other chip variants support reading of max. 64 bytes
at once (according to the em258x datasheet; also verified with em2710, em2882,
and em28174).
Since em2800_i2c_recv_bytes() has been fixed to return with -EOPNOTSUPP when
more than 4 bytes are requested, EEPROM reading with this chip is broken.
It was actually broken before that change, too, it just didn't throw an error
because the i2c adapter silently returned trash data (for all reads >1 byte !).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
- do not pass USB specific error codes to userspace/i2c-subsystem
- unify the returned error codes and make them compliant with
the i2c subsystem spec
- check number of actually transferred bytes (via USB) everywehere
- fix/improve debug messages
- improve code comments
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
I2C_FUNC_SMBUS_EMUL includes flag I2C_FUNC_SMBUS_WRITE_BLOCK_DATA which signals
that up to 31 data bytes can be written to the ic2 client.
But the EM2800 supports only i2c messages with max. 4 data bytes.
I2C_FUNC_IC2 should be set if a master_xfer function pointer is provided in
struct i2c_algorithm.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Function em2800_i2c_recv_bytes() has 2 severe bugs:
1) It does not wait for the i2c read to complete before reading the received message content from the bridge registers.
2) Reading more than 1 byte doesn't work
The former can result in data corruption, the latter always does.
The rewritten code also superseds the content of function
em2800_i2c_check_for_device().
Tested with device "Terratec Cinergy 200 USB".
[mchehab@redhat.com: Fix CodingStyle issues]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The em2800 can transfer up to 4 bytes per i2c message.
All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per message.
I2C adapters should never split messages transferred via the I2C subsystem
into multiple message transfers, because the result will almost always NOT be
the same as when the whole data is transferred to the I2C client in a single
message.
If the message size exceeds the capabilities of the I2C adapter, -EOPNOTSUPP
should be returned.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The get_key functions are independent from the selected protocol, so assign
them once only at device initialization.
[mchehab@redhat.com: fix a merge conflict]
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The main purpose of this patch is to move the call of em28xx_release_resources()
after the call of em28xx_close_extension().
This is necessary, because some resources might be needed/used by the extensions
fini() functions when they get closed.
Also mark the device as disconnected earlier in this function and unify the
em28xx_uninit_usb_xfer() calls for analog and digital mode.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
DEV_INITIALIZED of enum em28xx_dev_state state is used nowhere and there is no
need for DEV_MISCONFIGURED, so remove this enum and use a boolean field
'disconnected' in the device struct instead.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch converts the em28xx driver over to videobuf2. It is
likely that em28xx_fh can go away entirely, but that will come in
a separate patch.
[mchehab@redhat.com: fix a non-trivial merge conflict with some VBI
patches; CodingStyle fixes]
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The sliced VBI support in the tvp5150 is completely broken. And there is no
support for the saa7115 sliced VBI implementation in the em28xx driver. So
we remove the sliced VBI support completely.
It should be possible to get it to work with the tvp5150, but that will
require someone to really dig into that driver.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
When in webcam mode the STD API shouldn't be implemented.
When changing the standard the resolution wasn't updated, and there was no
check against streaming-in-progress.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
g/s_parm should fill in readbuffers.
For non-webcams s_parm should return -ENOTTY instead of -EINVAL.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
v4l2-compliance found problems with frequency clamping that wasn't
reported correctly and missing tuner index checks.
Also removed unnecessary tuner type checks (these are now done by the
v4l2 core).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Radio devices should not implement those ioctls.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The ir-i2c-kbd already adds I2C IR before the name. The way it is,
the devices are named as:
"i2c IR (i2c IR (EM2840 Hauppaug"
With is ugly and incorrect. After this patch, it is now properly
displayed as:
"i2c IR (WinTV USB2)"
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
If the device has an I2C IR, em28xx-rc should be loaded by default,
except if the user explicitly requested to not load, via modprobe
option.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The em28xx-input is used by 3 different types of input devices:
- devices with buttons (like cameras and grabber devices);
- devices with I2C remotes;
- em2860 or latter chips with RC support embedded.
When the device has an I2C remote, all it needs to do is to call
the proper I2C driver (ir-i2c-kbd), passing the proper data to
it, and just leave the code.
Also, button devices have its own init code that doesn't depend on
having an IR or not (as a general rule, they don't have).
So, move its init code to fix bugs introduced by earlier patches
that prevent them to work.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since we have now 3 modes (auto/isoc/bulk), usb_xfer_mode is more suitable than prefer_bulk.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Using bulk mode allows more than one webcam, as the maximum fps
is low at 640x480 resolution. So, prefer it, if the device is
a webcam.
Tested with Silvercrest 1.3 Mpixel webcam (em2710) on both bulk and isoc
modes.
Tested analog with HVR-950 model 65201/A1C0 (em2883), where only ISOC
endpoints are available for both DVB and Analog.
Tested on Hauppauge WinTV USB 2 (em2840) on both bulk and isoc modes.
It should be noticed that enabling bulk mode by default with TV boards
is a bad idea; what happens is that, while with ISOC the USB logic will
prevent the concurrent usage of two devices that spends more than 100%
of the USB2 traffic, it doesn't care with bulk transfers.
On my tests, I started two streams, one with a WinTV at 640x480x30fps
and the other one with a Silvercrest webcam at 640x480, on a lower fps)
both on bulk mode. One of the streams always silently failed.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In order to make easier to analize the logs when multiple devices
are plugged, change the device name accordingly with the chip
version.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
