From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Stefan Ringel <stefan.ringel@arcor.de>
Cc: linux-media@vger.kernel.org,
Devin Heitmueller <dheitmueller@kernellabs.com>
Subject: Re: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
Date: Wed, 27 Jan 2010 18:47:10 -0200 [thread overview]
Message-ID: <4B60A64E.3090106@redhat.com> (raw)
In-Reply-To: <4B6094DE.4000204@arcor.de>
Stefan Ringel wrote:
> Hi,
>
> I have a problem with usb bulk transfer. After a while, as I scan digital channel (it found a few channel), it wrote this in the log:
>
> Jan 26 21:58:35 linux-v5dy kernel: [ 548.756585] tm6000: status != 0
>
> I updated the tm6000_urb_received function so that I can read the Error code and it logged:
>
> Jan 27 17:41:28 linux-v5dy kernel: [ 3121.892793] tm6000: status = 0xffffffb5
Probablt it is this error:
#define EOVERFLOW 75 /* Value too large for defined data type */
It would be good to make it display the error as a signed int.
the tm6000-video error handler has some common causes for those status.
In this particular case:
case -EOVERFLOW:
errmsg = "Babble (bad cable?)";
break;
This looks the same kind of errors I was receiving during the development of the driver:
a large amount of frames are got broken, even if the device is programmed with the exact
values used on the original driver. On my tests, changing the URB size were changing
the position where such errors were occurring.
>
> Can you help me? Who I can calculate urb size?
Take a look on tm6000-video:
size = usb_maxpacket(dev->udev, pipe, usb_pipeout(pipe));
if (size > dev->max_isoc_in)
size = dev->max_isoc_in;
It depends on the alternate interface used. The driver should select an alternate
interface that is capable of receiving the entire size of a message. Maybe the tm6000
driver is missing the code that selects this size. Take a look on em28xx-core, at
em28xx_set_alternate() code for an example on how this should work.
The calculated size there assumes that each pixel has 16 bits, and has some magic that
were experimentally tested on that device.
Cheers,
Mauro.
next prev parent reply other threads:[~2010-01-27 20:47 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 15:31 Terratec Cinergy Hybrid XE (TM6010 Mediachip) Stefan Ringel
2010-01-18 15:43 ` Devin Heitmueller
2010-01-18 20:05 ` Stefan Ringel
2010-01-18 20:08 ` Devin Heitmueller
2010-01-25 14:35 ` Mauro Carvalho Chehab
2010-01-25 16:12 ` Stefan Ringel
[not found] ` <4B5DF134.7080603@redhat.com>
[not found] ` <4B5DF360.40808@arcor.de>
[not found] ` <4B5DF73F.9030807@redhat.com>
2010-01-25 21:02 ` Stefan Ringel
[not found] ` <4B6093E4.40706@arcor.de>
2010-01-27 19:32 ` Stefan Ringel
2010-01-27 20:47 ` Mauro Carvalho Chehab [this message]
2010-01-31 13:28 ` Stefan Ringel
-- strict thread matches above, loose matches on Subject: below --
2010-01-17 18:05 Stefan Ringel
2010-01-15 9:42 Stefan Ringel
2010-01-15 9:41 Stefan Ringel
2010-01-14 16:27 Stefan Ringel
2010-01-13 19:45 Stefan Ringel
2010-01-13 19:51 ` Devin Heitmueller
2010-01-10 19:04 Stefan Ringel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B60A64E.3090106@redhat.com \
--to=mchehab@redhat.com \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
--cc=stefan.ringel@arcor.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox