On Sat, 05 Apr 2008 09:52:33 +0200, Hans de Goede <j.w.r.degoede(a)hhs.nl> wrote:
The current code doesn't allow simultanious opens, so this can
become only 0 or 1 .
> I think that placing buffers into the lower 4GB is a senseless
> limitation to build into a library. Although today the only system
> which can run DMA between memory above 4GB and USB is Opteron,
> with XHCI it's going to change.
Actually this isn't used for dma at all, so the _32_ can indeed go away.
I figured it out but I thought you wanted to do it eventually.
> Why are you using usb_buffer_alloc here? Why not use kmalloc?
I took this from gspca, and I believe this is necessary to get a
buffer will at
all the proper attributes for being able todo a dma transfer to it.
No, kmalloc is good enough on all architectures. The only time
to use usb_buffer_alloc is when you have lots of small buffers,
or attempt to do some kind of zero copy transfer. It saves you
the MMU setup costs in that case. The USB stack hackers are
trying to de-emphasize its use because it conflicts with usbmon
(also it eats MMU resources, but this is not a big deal unless
you're on SPARC).
> What is this +1 business, anyway?
The pac207 (and sn109c bayer compression code uses variable length bit
patterns, the decoder always reads 8 bits and the looks this up in a table
which tells it amongst other things how much bits where actually used. So if
the last pixel in a row is coded in say 2 bits, and it happens to also be at
the end of a packet 6 additional bits will get read (and ignored).
So the buffer gets allocated 1 byte too large to allow safe reading of these 6
If I understand you correctly, you don't need to allocate
(psz+1) * NUM_ISO then. You could allocate psz*NUM_ISO + 1. So,
I thought it was necessary to force an empty DATA IN token due to
a device quirk... Some people said on linux-usb list that asking
for anything other than an integral number of packets did not
work with their ISO device, which is exact opposite of what
you're doing. But if your webcam works, then by all means
continue. I'm just wondering if you're going to step on it when
you add a next webcam into usbvideo2 framework.