There are several left overs with my old email address.
Remove their occurrences and add myself at CREDITS, to
allow people to be able to reach me on my new addresses.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Commit e63b009d6e "em28xx-i2c: Fix error code for I2C error transfers"
changed the code to return -ETIMEDOUT on all unknown errors.
But the proper error code for unknown errors is -EIO.
So only report -ETIMEDOUT in case of the errors 0x02 and 0x04, which
are according to Mauro Carvalho Chehab's tests related to i2c clock
stretching and return -EIO for the rest.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Commit d845fb3ae5 "em28xx-i2c: add timeout debug information if i2c_debug enabled"
has added wrong error descriptions for -ENXIO.
The strings are also missing terminating newline characters, which breaks the
output format.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
This avoids the unnecessary temporary registration of a dummy V4L2 clock.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Since commit e63b009d6e the returned error code in case of not connected/responding
i2c clients is ENXIO isntead of ENODEV, which causes several error messages on
sensor probing.
Fix the i2c return value checks on sensor probing to silence these warnings.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Otherwiese the core refuses to unregister the clock and the following warning
appears in the system log:
"WARNING: ... at drivers/media/v4l2-core/v4l2-clk.c:231 v4l2_clk_unregister+0x8a/0x90 [videodev]()
v4l2_clk_unregister(): Refusing to unregister ref-counted 11-0030:mclk clock!"
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
dev->adev.users always needs to be increased when snd_em28xx_capture_open() is
called and succeeds.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Fix sparse warning:
drivers/media/usb/em28xx/em28xx-cards.c:69:1: sparse: symbol 'em28xx_devused' was not declared. Should it be static?
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
usb_free_coherent() is safe with NULL addr and this check is
not required.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Instead of just saying:
[ 1646.412419] em2882/3 #0: submit of audio urb failed
Print the reason why it failed, to help debugging and fixing it.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Previously, we've been assuming that the video endpoints are always at usb
interface 0. Hence, if vendor audio endpoints are provided at a separate
interface, they were supposed to be at interface number > 0.
Instead of checking for (interface number > 0) to determine if an interface
is a pure audio interface, dev->is_audio_only should be checked.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The current code assumes that the analog + digital video endpoints are always at
interface number 0 when changing the alternate setting.
This seems to work fine for most existing devices.
However, at least the SpeedLink VAD Laplace webcam has the video endpoint on
interface number 3 (which fortunately doesn't cause any trouble because ist uses
bulk transfers only).
We already consider the actual interface number for audio endpoints, so
rename the the audio_ifnum variable and use it for all device types.
Also get get rid of a pointless (ifnum < 0) in em28xx-audio.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/media/usb/em28xx/em28xx-video.c:1151:28: sparse: symbol 'em28xx_ctrl_ops' was not declared. Should it be static?
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
If something bad happens during init, we free the card data.
However, we still keep it initialized, causing some dependent
code to be called at .fini.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The option to load firmware asynchronously were added due to
a requirement with a few versions of udev. It turns that this was
a bad idea and caused regressions on drxk-based devices.
So, we end by only letting the firmware to be loaded syncronously
everywhere.
So, let's remove the bad code.
This patch partially reverts the changeset 8e30783b0b.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
While the current hardcoded period is ok for the current values,
we may latter change the driver to work with different bit rates
or with different latencies than 64ms.
So, adust the period size at runtime.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Now that everything is extension, the usb disconnect logic should
be the same.
While here, fix the device name.
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
That helps to identify if something fails and explain why em28xx
struct is not freed (if it ever happens).
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
URBs might be in usage. Disconnect the device before freeing
them.
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Alsa has an special non-negative return code to indicate device removal
at snd_em28xx_capture_pointer(). Use it, instead of an error code.
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Remove some dead code from em28xx_v4l2_fini() and fix the leaking of the video,
vbi and radio video_device struct memories.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
When the usb device is disconnected, the resources are no longer available,
so there is no reason to keep them registered.
This will also fix the various sysfs group removal warnings which we can see
since kernel 3.13.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
v4l2_ctrl_handler_free() and v4l2_device_unregister() are currently only called
when the last user closes the device and the device is already disconnected.
But that's wrong, we need to call these functions whenever the em28xx-v4l
extension is closed and we can already do this if the device is still opened
by some users.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
- bail out on unsupported VFL_TYPE
- em28xx_set_mode() needs to be called for VBI and radio mode, too
- em28xx_wake_i2c() needs to be called for VBI and radio mode, too
- em28xx_resolution_set() also needs to be called for VBI
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Now that em28xx can be compiled without V4L support, we should
call em28xx_setup_xc3028() on both em28xx-v4l and em28xx-dvb
modules.
Reported-by: Chris Lee <updatelee@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The URB calculus code may eventually be moved to some other
place, like at pcm open, if it ends by needing more setups, like
working with different bit rates, or different audio latency.
So, move it into a separate routine. That also makes the code
more readable.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Pulseaudio has the bad habit of stopping a streaming audio if
a device, opened in non-block mode, waits.
It is impossible to avoid em28xx to wait, as it will send commands
via I2C, and other I2C operations may be happening (firmware
transfers, Remote Controller polling, etc). Yet, as each em28xx
subdriver locks em28xx-dev to protect the access to the hardware,
it is possible to minimize the audio glitches by returning -EAGAIN
to pulseaudio, if the lock is already taken by another subdriver.
Reported-by: Antti Palosaari <crope@iki.fi>
Tested-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
If the period size is wrong, userspace will assume a wrong delay
any may negociate an inadequate value.
The em28xx devices use 8 for URB interval, in microframes,
and the driver programs it to have 64 packets.
That means that the IRQ sampling period is 125 * 8 * 64,
with is equal to 64 ms.
So, that's the minimal latency with the current settings. It is
possible to program a lower latency, by using less than 64 packets,
but that increases the amount of bandwitdh used, and the number of
IRQ events per second.
In any case, in order to support it, the driver logic should be
changed to fill those parameters in realtime.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The current code hardcodes the number of audio URBs, the number
of packets per URB and the maximum URB size.
This is not a good idea, as it:
- wastes more bandwidth than necessary, by using a very
large number of packets;
- those constants are bound to an specific scenario, with
a bandwidth of 48 kHz;
- don't take the maximum endpoint size into account;
- with urb->interval = 1 on xHCI, those constraints cause a "funny"
setup: URBs with 64 packets inside, with only 24 bytes total. E. g.
a complete waste of space.
Change the code to do dynamic URB audio calculus and allocation.
For now, use the same constraints as used before this patch, to
avoid regressions.
A good scenario (tested) seems to use those defines, instead:
#define EM28XX_MAX_AUDIO_BUFS 8
#define EM28XX_MIN_AUDIO_PACKETS 2
But let's not do such change here, letting the optimization to
happen on latter patches, after more tests.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Just filling urb->interval with 1 is wrong, and causes a different
behaviour with xHCI.
With EHCI, the URB size is typically 192 bytes. However, as
xHCI specifies intervals in microframes, the URB size becomes
too short (24 bytes).
With this patch, the interval will be properly initialized, and
the device will behave the same if connected into a xHCI or an
EHCI device port.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
If i2c_debug is enabled, we splicitly want to know when a
device fails with timeout.
If i2c_debug==2, this is already provided, for each I2C transfer
that fails.
However, most of the time, we don't need to go that far. We just
want to know that I2C transfers fail.
So, add such errors for normal (ret == 0x10) I2C aborted timeouts.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The I2C output messages is too polluted. Clean it a little
bit, by:
- use the proper core support for memory dumps;
- hide most stuff under the i2c_debug umbrella;
- add the missing KERN_CONT where needed;
- use 2 levels or verbosity. Only the second one
will show the I2C transfer data.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Follow the error codes for I2C as described at Documentation/i2c/fault-codes.
In the case of the I2C status register (0x05), this is mapped into:
- ENXIO - when reg 05 returns 0x10
- ETIMEDOUT - when the device is not temporarily not responding
(e. g. reg 05 returning something not 0x10 or 0x00)
- EIO - for generic I/O errors that don't fit into the above.
In the specific case of 0-byte reads, used only during I2C device
probing, it keeps returning -ENODEV.
TODO: return EBUSY when reg 05 returns 0x20 on em2874 and upper.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
In the lack of a better spec, let's assume the timeout
values compatible with SMBus spec:
http://smbus.org/specs/smbus110.pdf
at chapter 8 - Electrical Characteristics of SMBus devices
Ok, SMBus is a subset of I2C, and not all devices will be
following it, but the timeout value before this patch was not
even following the spec.
So, while we don't have a better guess for it, use 35 + 1
ms as the timeout.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
This macro is used by all em28xx devices, and not just em2800.
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The I2C wait completion/timeout logic currently assumes that
msleep(5) will wait exaclty 5 ms. This is not true at all,
as it depends on CONFIG_HZ.
Convert it to use jiffies, in order to not wait for more time
than needed.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Instead of assuming that msleep() is precise, use a jiffies
based code to wait for AC97 to be available.
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Instead of allocating/deallocating URBs and transfer buffers
every time stream is started/stopped, just do it once.
That reduces the memory allocation pressure and makes the
code that start/stop streaming a way simpler.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Instead of allocating transfer buffers with kmalloc() use
usb_alloc_coherent().
This patch should make it work also with ARM CPUs.
Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The audio configuration in chip config register 0x00 and eeprom are always
consistent. But currently the audio configuration #defines for the chip config
register say 0x20 means 3 sample rates and 0x30 5 sample rates, while the eeprom
info output says 0x20 means 1 sample rate and 0x30 3 sample rates.
I've checked the datasheet excerpts I have and it seems that the meaning of
these bits is different for em2820/40 (1 and 3 sample rates) and em2860+
(3 and 5 smaple rates).
I have also checked my Hauppauge WinTV USB 2 (em2840) and the chip/eeprom
audio config 0x20 matches the sample rates reproted by the USB device
descriptor (32k only).
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Mauro Carvalho Chehab