On Fri, 13 Nov 2009, Greg KH wrote:
On Fri, Nov 13, 2009 at 09:35:55PM -0600, Theodore Kilgore wrote:
Having written a GSPCA webcam driver on a machine where everything worked
perfectly, I tried it on another machine. On the second machine, it did
not work so well. The decisive difference between the two machines seemed
to be that the first one uses the OHCI driver for basic USB support, and
the second machine uses UHCI. So I decided to test on more hardware.
Do you happen to send data to the USB core off the stack instead of the
heap?
Greg, you got me there. I don't know. The driver is supposed to be working
as part of gspca, and are these things not supposed to be taken care of at
a lower level?
Any pointers to the driver code itself?
Sure. You can find the code at the Mercurial tree of Hans de Goede, at
http://linuxtv.org/hg/~hgoede/gspca
and the particular cameras which are causing the trouble are supported in
linux/drivers/media/video/gspca/mr97310a.c.
Now, there is another thing which will help you understand that code. I
think you would see for yourself, but it is perhaps more efficient if I
explain first.
The cameras with mr97310a controller chip come in several different
sub-varieties. There are CIF (max resolution 352x288) and there are VGA
cameras (max resolution 640x480). Each of these sets is split into two
parts, apparently due to different sensor chips installed in the camera.
Thus, there are CIF "type 0" cameras and CIF "type 1" cameras, also VGA
type 0 and VGA type 2 cameras, requiring the initialization routine for
the camera to be chosen from a list of four initialization routines.
All but one of the known CIF cameras have got the same USB Vendor:Product
ID of 0x093a:0x010e and under that number there are both type 0 and type 1
cameras. So let us use these as an example, and they are the ones where
the problem comes up, about all of them working on OHCI machines and only
some of them working on UHCI machines.
Type 0 and type 1 CIF cameras require different sensor initialization
strings before they can be made to stream. Before the initialization is
attempted, the camera's sensor type has to be detected. This detection is
performed in mr97310a.c in sd_config(). The method of detection is to send
a query to the camera, which gets a different answer depending on which
type it is. The right query had to be discovered by trial and error. No
OEM driver for that other OS ever uses such a query. Instead, the sellers
rely upon sending out the right driver CD corresponding to the camera, and
sometimes they send out the wrong CD. Sometimes even the same "brand" and
"model" can switch sensors. For example, I own a Vivitar Mini which is
type 1, and Hans de Goede owns a Vivitar Mini which is type 0.
OK, so this is the background, which is both interesting in itself and
relevant.
Now, what is happening is that all of the supported cameras work
beautifully when hooked to a machine which is using OHCI. Most of them
also work beautifully when hooked up to a machine which is using UHCI. But
the CIF type 1 cameras fail to work properly if hooked to a machine
running UHCI. They are detected correctly, and apparently are initialized
correctly (I have looked at a bit of dmesg output, usbmon output and such,
by now) but when they are asked to emit a stream across the isochronous
endpoint the stream is not forthcoming.
I have tested now on six machines, as I said. Three of them are OHCI
type machines, and all of the cameras run. Three of them are UHCI type
machines, and the CIF type 1 cameras do not run. Of course, the problem
could be local to the driver code itself. But with a consistent pattern
like that one does begin to wonder.
Theodore Kilgore
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
