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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
