* The em28xx driver error
@ 2012-11-11 4:46 Michael Yang
2012-11-14 16:58 ` Frank Schäfer
0 siblings, 1 reply; 6+ messages in thread
From: Michael Yang @ 2012-11-11 4:46 UTC (permalink / raw)
To: linux-media
Hi I am using a v4l2 usb video capturer (em28xx based) on the TI-DM3730 board
I used the default driver ,the video can't be captured. I solve this issue by
change the em28xx driver :
linux-stable/drivers/media/video/em28xx/em28xx-core.c
/* FIXME: this only function read values from dev */
int em28xx_resolution_set(struct em28xx *dev)
{
int width, height;
width = norm_maxw(dev);
height = norm_maxh(dev);
/* Properly setup VBI */
dev->vbi_width = 720;
if (dev->norm & V4L2_STD_525_60)
dev->vbi_height = 12;
else
dev->vbi_height = 18;
if (!dev->progressive)
height >>= norm_maxh(dev) ;//change to" height = norm_maxh(dev) >> 1 ;"
em28xx_set_outfmt(dev);
Then I can capture the video.But about 3 minutes later, the os throw out
errors:
Read a frame, the size is:325
Read a frame, the size is:304
ehci-omap ehci-omap.0: request c15b1000 would overflow (3898+63 >= 3936) //the
video shut up
ehci-omap ehci-omap.0: request c15b0000 would overflow (3906+63 >= 3936)
ehci-omap ehci-omap.0: request c1558800 would overflow (3915+63 >= 3936)
ehci-omap ehci-omap.0: request c15b0800 would overflow (3924+63 >= 3936)
Read a frame, the size is:253
ehci-omap ehci-omap.0: request c143f800 would overflow (3909+63 >= 3936)
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
usb 1-2.2: kworker/0:2 timed out on ep0in len=8/1
............
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
usb 1-2.2: kworker/0:2 timed out on ep0in len=8/1
^Cusb 1-2.2: test_h264 timed out on ep0in len=0/1
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
^Cusb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
^Cusb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
^C
usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
^Cusb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
usb 1-2.2: test_h264 timed out on ep0out len=8/0
em28xx #0: cannot change alternate number to 0 (error=-110)
Then I try TI OMAP-3530 ,after change the em28xx-driver , the image can be
captured but throw the same error after about 3 minutes
em28xx #0: cannot change alternate number to 0 (error=-110)
This driver source about this error is
int em28xx_set_alternate(struct em28xx *dev)
{
int errCode, prev_alt = dev->alt;
int i;
unsigned int min_pkt_size = dev->width * 2 + 4;
/*
* alt = 0 is used only for control messages, so, only values
* greater than 0 can be used for streaming.
*/
if (alt && alt < dev->num_alt) {
em28xx_coredbg("alternate forced to %d\n", dev->alt);
dev->alt = alt;
goto set_alt;
}
/* When image size is bigger than a certain value,
the frame size should be increased, otherwise, only
green screen will be received.
*/
if (dev->width * 2 * dev->height > 720 * 240 * 2)
min_pkt_size *= 2;
for (i = 0; i < dev->num_alt; i++) {
/* stop when the selected alt setting offers enough bandwidth */
if (dev->alt_max_pkt_size[i] >= min_pkt_size) {
dev->alt = i;
break;
/* otherwise make sure that we end up with the maximum bandwidth
because the min_pkt_size equation might be wrong...
*/
} else if (dev->alt_max_pkt_size[i] >
dev->alt_max_pkt_size[dev->alt])
dev->alt = i;
}
set_alt:
if (dev->alt != prev_alt) {
em28xx_coredbg("minimum isoc packet size: %u (alt=%d)\n",
min_pkt_size, dev->alt);
dev->max_pkt_size = dev->alt_max_pkt_size[dev->alt];
em28xx_coredbg("setting alternate %d with wMaxPacketSize=%u\n",
dev->alt, dev->max_pkt_size);
errCode = usb_set_interface(dev->udev, 0, dev->alt);
if (errCode < 0) {
em28xx_errdev("cannot change alternate number to %d (error=%i)\n",
dev->alt, errCode);
return errCode;
}
}
return 0;
}
How can I solve this problem ? Or is there some other USBDVR can work well on
the TI DM3730?
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: The em28xx driver error
2012-11-11 4:46 The em28xx driver error Michael Yang
@ 2012-11-14 16:58 ` Frank Schäfer
2012-11-14 17:05 ` Devin Heitmueller
0 siblings, 1 reply; 6+ messages in thread
From: Frank Schäfer @ 2012-11-14 16:58 UTC (permalink / raw)
To: Michael Yang; +Cc: linux-media, Mauro Carvalho Chehab
Am 11.11.2012 05:46, schrieb Michael Yang:
> Hi I am using a v4l2 usb video capturer (em28xx based) on the TI-DM3730 board
> I used the default driver ,the video can't be captured. I solve this issue by
> change the em28xx driver :
>
> linux-stable/drivers/media/video/em28xx/em28xx-core.c
>
> /* FIXME: this only function read values from dev */
> int em28xx_resolution_set(struct em28xx *dev)
> {
> int width, height;
> width = norm_maxw(dev);
> height = norm_maxh(dev);
>
> /* Properly setup VBI */
> dev->vbi_width = 720;
> if (dev->norm & V4L2_STD_525_60)
> dev->vbi_height = 12;
> else
> dev->vbi_height = 18;
>
> if (!dev->progressive)
> height >>= norm_maxh(dev) ;//change to" height = norm_maxh(dev) >> 1 ;"
This looks indeed like a bug.
a >>= b means a = a >> b, which in this case means shifting height 480
or 576 bits to the right...
height >> 1 means height /= 2 which seems to be sane for interlaced devices.
OTOH, I wonder why it seems to be working on other platforms !?
Unfortunately I don't have an interlaced device here for testing. :(
> em28xx_set_outfmt(dev);
>
>
>
> Then I can capture the video.But about 3 minutes later, the os throw out
> errors:
>
> Read a frame, the size is:325
> Read a frame, the size is:304
> ehci-omap ehci-omap.0: request c15b1000 would overflow (3898+63 >= 3936) //the
> video shut up
> ehci-omap ehci-omap.0: request c15b0000 would overflow (3906+63 >= 3936)
> ehci-omap ehci-omap.0: request c1558800 would overflow (3915+63 >= 3936)
> ehci-omap ehci-omap.0: request c15b0800 would overflow (3924+63 >= 3936)
> Read a frame, the size is:253
> ehci-omap ehci-omap.0: request c143f800 would overflow (3909+63 >= 3936)
Couldn't this be an ehci-omap issue ?
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> usb 1-2.2: kworker/0:2 timed out on ep0in len=8/1
> ............
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> usb 1-2.2: kworker/0:2 timed out on ep0in len=8/1
> ^Cusb 1-2.2: test_h264 timed out on ep0in len=0/1
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> ^Cusb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> ^Cusb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
>
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
>
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> ^C
> usb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> ^Cusb 1-2.2: kworker/0:2 timed out on ep0in len=0/1
> usb 1-2.2: test_h264 timed out on ep0out len=8/0
> em28xx #0: cannot change alternate number to 0 (error=-110)
This means usb_set_interface() failed with -ETIMEDOUT. No idea what that
means.
I also wonder why the driver tries to switch to alternate setting 0...
Could you please post the output of lsusb -v for this device ?
Regards,
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: The em28xx driver error
2012-11-14 16:58 ` Frank Schäfer
@ 2012-11-14 17:05 ` Devin Heitmueller
2012-11-15 16:31 ` Frank Schäfer
0 siblings, 1 reply; 6+ messages in thread
From: Devin Heitmueller @ 2012-11-14 17:05 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Michael Yang, linux-media, Mauro Carvalho Chehab
On Wed, Nov 14, 2012 at 11:58 AM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
> This looks indeed like a bug.
> a >>= b means a = a >> b, which in this case means shifting height 480
> or 576 bits to the right...
> height >> 1 means height /= 2 which seems to be sane for interlaced devices.
> OTOH, I wonder why it seems to be working on other platforms !?
> Unfortunately I don't have an interlaced device here for testing. :(
It's definitely a bug. I think Mauro put a patch in for 3.7 or 3.8.
The reason it works under x86 is because shifting an arbitrary number
of bits > 32 causes indeterminate behavior, and out of dumb luck it
has no effect on x86.
But yeah, I changed the code to shift by one bit and it's been working
fine on ARM for months in my environment (DM3730).
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The em28xx driver error
2012-11-14 17:05 ` Devin Heitmueller
@ 2012-11-15 16:31 ` Frank Schäfer
2012-11-15 16:35 ` Devin Heitmueller
0 siblings, 1 reply; 6+ messages in thread
From: Frank Schäfer @ 2012-11-15 16:31 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: Michael Yang, linux-media, Mauro Carvalho Chehab
Am 14.11.2012 18:05, schrieb Devin Heitmueller:
> On Wed, Nov 14, 2012 at 11:58 AM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> This looks indeed like a bug.
>> a >>= b means a = a >> b, which in this case means shifting height 480
>> or 576 bits to the right...
>> height >> 1 means height /= 2 which seems to be sane for interlaced devices.
>> OTOH, I wonder why it seems to be working on other platforms !?
>> Unfortunately I don't have an interlaced device here for testing. :(
> It's definitely a bug. I think Mauro put a patch in for 3.7 or 3.8.
> The reason it works under x86 is because shifting an arbitrary number
> of bits > 32 causes indeterminate behavior, and out of dumb luck it
> has no effect on x86.
>
> But yeah, I changed the code to shift by one bit and it's been working
> fine on ARM for months in my environment (DM3730).
>
> Devin
Hmm... I've made some experiments to find out what gcc does on x86 and
it seems to ignore bit shifting > 32.
I also noticed that this line has been removed in 3.7-rc.
So we do NOT want to halve the height for interlaced devices here, right ?
Regards,
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The em28xx driver error
2012-11-15 16:31 ` Frank Schäfer
@ 2012-11-15 16:35 ` Devin Heitmueller
2012-11-15 16:58 ` Frank Schäfer
0 siblings, 1 reply; 6+ messages in thread
From: Devin Heitmueller @ 2012-11-15 16:35 UTC (permalink / raw)
To: Frank Schäfer; +Cc: Michael Yang, linux-media, Mauro Carvalho Chehab
On Thu, Nov 15, 2012 at 11:31 AM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
> Hmm... I've made some experiments to find out what gcc does on x86 and
> it seems to ignore bit shifting > 32.
> I also noticed that this line has been removed in 3.7-rc.
> So we do NOT want to halve the height for interlaced devices here, right ?
Even with the datasheets, it was never clear to me what role the
accumulator size played. It appeared to work regardless of whether it
was halved (although making it zero obviously caused problems).
Hence, since we couldn't see any visible difference, Mauro just
removed the code. My guess is that it effects the on-chip internal
buffering hence it's possible that performance/reliability could be
effected under extreme load or some edge case, but I don't have any
data to back up that assertion at this time.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: The em28xx driver error
2012-11-15 16:35 ` Devin Heitmueller
@ 2012-11-15 16:58 ` Frank Schäfer
0 siblings, 0 replies; 6+ messages in thread
From: Frank Schäfer @ 2012-11-15 16:58 UTC (permalink / raw)
To: Devin Heitmueller; +Cc: Michael Yang, linux-media, Mauro Carvalho Chehab
Am 15.11.2012 17:35, schrieb Devin Heitmueller:
> On Thu, Nov 15, 2012 at 11:31 AM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Hmm... I've made some experiments to find out what gcc does on x86 and
>> it seems to ignore bit shifting > 32.
>> I also noticed that this line has been removed in 3.7-rc.
>> So we do NOT want to halve the height for interlaced devices here, right ?
> Even with the datasheets, it was never clear to me what role the
> accumulator size played. It appeared to work regardless of whether it
> was halved (although making it zero obviously caused problems).
>
> Hence, since we couldn't see any visible difference, Mauro just
> removed the code. My guess is that it effects the on-chip internal
> buffering hence it's possible that performance/reliability could be
> effected under extreme load or some edge case, but I don't have any
> data to back up that assertion at this time.
>
> Devin
>
Interesting.
As the buggy line seemed to have no effect on x86 and the driver was
working fine, it makes indeed sense to stay with the full height to
avoid regressions.
Regards,
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-11-15 16:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-11 4:46 The em28xx driver error Michael Yang
2012-11-14 16:58 ` Frank Schäfer
2012-11-14 17:05 ` Devin Heitmueller
2012-11-15 16:31 ` Frank Schäfer
2012-11-15 16:35 ` Devin Heitmueller
2012-11-15 16:58 ` Frank Schäfer
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.