On Sat, 05 Apr 2008 09:52:33 +0200, Hans de Goede <j.w.r.degoede@xxxxxx> wrote: > The current code doesn't allow simultanious opens, so this can become only 0 or 1 . I see... > > 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 > bits. 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. -- Pete _______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
