Re: tm6000 calculating urb buffer

[Stefan Ringel <stefan.ringel@arcor.de>]

-----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-----