-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.05.2010 21:50, schrieb Mauro Carvalho Chehab: > Stefan Ringel wrote: > >>>> datagram from urb to videobuf >>>> >>>> urb copy to temp copy to 1. videobuf >>>> buffer 2. audiobuf >>>> 3. vbi >>>> 184 Packets -------> 184 * 3072 ----------> 4. etc. >>>> a 3072 bytes bytes >>>> 184 * 3072 * >>>> 3072 bytes 180 bytes >>>> (184 bytes - 4 bytes >>>> header ) >>> In order to receive 184 packets with 3072 bytes each, the USB code will >>> try to allocate the next power-of-two memory block capable of receiving >>> such data block. As: 184 * 3072 = 565248, the kernel allocator will seek >>> for a continuous block of 1 MB, that can do DMA transfers (required by >>> ehci driver). On a typical machine, due to memory fragmentation, >>> in general, there aren't many of such blocks. So, this will increase the >>> probability of not having any such large block available, causing an >> horrible >>> dump at kernel, plus a -ENOMEM on the driver, generally requiring a reboot >>> if you want to run the driver again. >>> >> And direct copy from urb to videobuf/alsa/vbi in 184 Bytes segments. >> >> urb 1. videobuf >> copy to 2. audiobuf >> 3. vbi >> 184 Packets -------> 4. etc. >> a 3072 bytes >> 180 Bytes (without headers) > > That's basically what that logic does. It preserves the header if you select > TM6000 format (so, no checks for the start of the block, etc), or copies > just the data, if you select YUY2 or UYUV. > >> or how can I copy 180 Bytes Data from 184 Bytes block with an >> anligment of 184 urb pipe (184 * 3072 Bytes)? > > A 184 x 3072 URB pipe is a big problem. We used a large pipe in the past, and this > won't work. For example, on a notebook I used to run some tests with 1 GB of > ram after starting X and do anything (like opening a browser), the URB > allocation used to fail, as there weren't any available 1MB segment at > the DMA area. Even without starting X, after a few tests, it would eventually > have fragmented the memory and the driver stops working. > > and 3072 * 46 = 141312 bytes and it can through 184 ! it's 1/4 smaller. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL4HxUAAoJEAWtPFjxMvFGAa8H/2tnr0u9YCHUlpcltAlKggcQ hXyZ3KiyBVe6K1cc/xEh1sMOscytJ4XS8ho9QHDh9AAObYq5J0zkXV5nBEJ2veIi a8fn9LgtsHLbgXhLxaToXgy3GY5HW/RANh0qhBqbPY1VRcvq8wmrKMO89qBr64NI 5thzzTAV9emxc6mASIw2dksqF0IFIciDEKygbMcHNm1Y1n/b0VkBInnjpz06vUex yKaigZRPHtIG8xnNKzcKIURfJ18T8GvpYSTipvZkqMOP6Latah6fYc6WYilMSk3n opYXS6iPL7qZkh3nWDXNQQLC1FBKoitsYhgWlope6wabiBYTAwnCtg5LFKo11Jc= =khUE -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
