--
Kedves E Mail felhasználói:
Túllépte a határt 23.432 tárolás postafiók beállítva a WEB SERVICE /
Administrator, és akkor problémái küldöttés a bejövo üzenetek Amíg ezt
újból érvényesíti. Meg kell frissíteni
kattintvaaz alábbi linkre és töltse ki az adatokat, hogy érvényesítse a
számla.
Am 10.01.2014 09:33, schrieb Mauro Carvalho Chehab:
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
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,
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
Am 10.01.2014 09:33, schrieb Mauro Carvalho Chehab:
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
Am 10.01.2014 09:33, schrieb Mauro Carvalho Chehab:
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
Am 10.01.2014 19:45, schrieb Mauro Carvalho Chehab:
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
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
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
On Fri, 2014-01-10 at 14:06 +0100, Hans Verkuil wrote:
Also CC to linux-media and Andy Walls who maintains this driver.
Regards,
Hans
On 01/06/14 16:07, Ethan Zhao wrote:
cx18_i2c_register() is called in cx18_init_subdevs() with index
greater than length of hw_bus array, that
On Fri, 2014-01-10 at 10:55 -0600, Scott Robinson wrote:
I did the bisect. My results are as follows:
Hi Scott,
Thank you! for doing a bisection. It is a non-trivial investment in
time.
Ondrej and Mike,
The change Scott isolated below breaks cx18 driver use of the TDA8290.
See the Ooops in
Em Sat, 11 Jan 2014 13:29:49 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.01.2014 09:33, schrieb Mauro Carvalho Chehab:
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:
Em Sat, 11 Jan 2014 14:09:44 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.01.2014 09:33, schrieb Mauro Carvalho Chehab:
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
Em Sat, 11 Jan 2014 14:14:38 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.01.2014 09:33, schrieb Mauro Carvalho Chehab:
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
Em Sat, 11 Jan 2014 14:37:30 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.01.2014 19:45, schrieb Mauro Carvalho Chehab:
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
On Wed, Jan 8, 2014 at 1:26 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
Hi Tim,
On Wed, Jan 8, 2014 at 12:12 AM, Tim Mester tmes...@ieee.org wrote:
Commit 2e68a75990011ccd looks interesting. It makes sense to me
that if we are gating the clock, and it is possible that we are
Hello,
in current wiki entries it is documented that HVR-939C-HD identifies
with usbId 2040:b130. Some days ago I bought a model that identifies
with id 2040:b131. Does anyone know more about that difference? Is
b131 compatible to b130? Can the new patches from Matthias Schwarzott
be applied
typo in message body: 939C should be HVR-930C-HD
2014/1/12 Christoph Lutz chrl...@gmail.com:
Hello,
in current wiki entries it is documented that HVR-939C-HD identifies with
usbId 2040:b130. Some days ago I bought a model that identifies with id
2040:b131. Does anyone know more about that
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sun Jan 12 04:00:16 CET 2014
git branch: test
git hash: d20e4ed6d30c6ecee315eea0efb3449c3591d09e
gcc
--
Kedves E Mail felhasználói:
Túllépte a határt 23.432 tárolás postafiók beállítva a WEB SERVICE /
Administrator, és akkor problémái küldöttés a bejövo üzenetek Amíg ezt
újból érvényesíti. Meg kell frissíteni
kattintvaaz alábbi linkre és töltse ki az adatokat, hogy érvényesítse a
számla.
20 matches
Mail list logo
