On Sat, 23 Nov 2002, Mark McClelland wrote: | Duncan Haldane wrote: | | >On 18-Nov-2002 Mark McClelland wrote: | > | > | >>Duncan Haldane wrote: | >> | >> >If two cameras are registered, one on /dev/video0 and one on /dev/video1, | >> >and I use e.g. xawtv or gqcam to monitor them, I cannot open /dev/video1 | >> >when /dev/video0 is open and vice-versa. This happens for two cpia | >> >devices and one cpia + one ov511 device.
This is when both devices are on the same USB host controller, right? Should be OK when they are on different host controllers. | >>That's because both cameras are trying to use nearly all of the USB's | >>bandwidth. Or, more precisely, each is trying to schedule an ISO packet Yes, there's really not enough bandwidth on one host controller for 2 USB cameras unless they are operating at low (video rectangle ?) size or low frame rates. | >Yes, this seems correct: I have now traced the problem to disruption of | >communication of commands to/from the cpia cam (ReadPacket() in cpia_usb.c/ | >cpia_usb_transferCmd()). This eventually causes de/re-registration of | >the camera, leaving a frozen viewer window that needs a reboot to clear | >it.... (incomplete cleanup ?) -- nasty. | > | | OK, that makes sense. I've seen that with ov511 too occasionally, but I | have yet to find the exact cause. | | >Is there any kind of locking that cpia_usb_transferCmd could use to | >temporarily grab the full usb bandwidth for camera control (so this takes | >precedence over data transfer by other devices?) | > | | Not that I know of. This issue was discussed briefly on linux-usb-devel | recently, but nothing came of it. (I'm CCing that list) None that I know of either. Duncan, why do you say "for camera control"? Is this still for isoc video data? | CONFIG_USB_BANDWIDTH might help if it can prevent the second camera from | submitting the ISO URB, but in my experience it causes more problems | than it solves. CONFIG_USB_BANDWIDTH is an incomplete implementation and needs to be reworked, as has been discussed several times. For now, I wouldn't recommend using it. | >At the very least I would hope to prevent hanging that requires a reboot!. | > | Agreed. I'm not sure why that happens, but I suspect the cpia driver is | at fault since lots of drivers have no problem with random disconnects. | It's possibly something to do with the synchronous calls (eg. | usb_control_msg()) being active when disconnect() gets called. There's | no solution to that currently, other than to use the async calls (ie. | usb_submit_urb()) and implement the necessary locking yourself. I'd also | check all of the codepaths that handle signals (eg. interrupted | syscalls), and check for function returns that don't drop all held | locks. I looked it over briefly, and nothing jumps out at me. | | If you can't find anything, put a ton of printks in disconnect() and | close() and see where it hangs :) | | <snip> | | >>Check the descriptors. As long as there's an alternate setting where | >>MxPS <= 1023 / 2 then you should be in business. You can either have the | >>packet size or alternate number be a module param, or you can do a | >>"cams" thing like ov511. Or, you can allow the frame rate to be set | >>somewhere, and have the driver automatically choose the minimum possible | >>packet size that can still sustain that frame rate. Oh yeah, about what I said above, but more precise. | >Mark, I attach a bzipped copy of cpia_usb.c, could you cast your experienced | >eye over it to see where a setting like this could be controlled, and point | >me at it? I gather that your ov511 code originally derived somewhat from | >cpia driver code, maybe you can recognize something? | > | My idea about auto-adjusting the alternate setting based on the | framerate is probably too difficult for a driver this complex, since | features like compression make it difficult to know the minimum | necessary bandwidth. I recommend doing what ov511 does instead (allow | user to input the number of cameras in /proc or as a module param, | determine a packet size based on that, and set the corresponding | alternate setting in cpia_usb_open()). That sounds reasonable. -- ~Randy ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
