From: Stefan Ringel <stefan.ringel@arcor.de>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: linux-media@vger.kernel.org,
Devin Heitmueller <dheitmueller@kernellabs.com>
Subject: Re: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
Date: Sun, 31 Jan 2010 14:28:22 +0100 [thread overview]
Message-ID: <4B658576.5000904@arcor.de> (raw)
In-Reply-To: <4B60A64E.3090106@redhat.com>
Am 27.01.2010 21:47, schrieb Mauro Carvalho Chehab:
> 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.
>
>
I know why it's going to overflow. It's not usb pipe calculating, it's
numbers of feeds that it's used. But then I cannot use more than one
filter! It's bad!!
Cheers
Stefan Ringel
--
Stefan Ringel <stefan.ringel@arcor.de>
next prev parent reply other threads:[~2010-01-31 13:28 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
2010-01-31 13:28 ` Stefan Ringel [this message]
-- 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=4B658576.5000904@arcor.de \
--to=stefan.ringel@arcor.de \
--cc=dheitmueller@kernellabs.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.