* Re: tm6000 calculating urb buffer [not found] ` <4BDB3017.9070101@arcor.de> @ 2010-05-04 15:38 ` Stefan Ringel 2010-05-04 18:25 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 6+ messages in thread From: Stefan Ringel @ 2010-05-04 15:38 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List [-- Attachment #1: Type: text/plain, Size: 698 bytes --] Am 30.04.2010 21:31, schrieb Stefan Ringel: > Am 30.04.2010 18:34, schrieb Stefan Ringel: > >> Hi Mauro, >> >> Today I'm writing directly to you, because it doesn't work the mailing >> list. I thought over the calculating urb buffer and I have follow idea: >> >> buffer = endpoint fifo size (3072 Bytes) * block size (184 Bytes) >> >> The actually calculating is a video frame size (image = width * hight * >> 2 Bytes/Pixel), so that this buffer has to begin and to end an >> uncomplete block. followed blocks are setting the logic to an err_mgs >> block, so that going to lost frames. >> >> >> > I forgot a log with old calculating. > > -- Stefan Ringel <stefan.ringel@arcor.de> [-- Attachment #2: datagram_urb_to_videobuf --] [-- Type: text/plain, Size: 2238 bytes --] tm6000 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 ) step 1 copy from urb to temp buffer snip ---- for (i = 0; i < urb->number_of_packets; i++) { int status = urb->iso_frame_desc[i].status; if (status<0) { print_err_status (dev,i,status); continue; } len=urb->iso_frame_desc[i].actual_length; memcpy (t_buf[i*len], urb->transfer_buffer[i*len], len); copied += len; if (copied >= size || !buf) break; } if (!urb->iso_frame_desc[i].status) { if ((buf->fmt->fourcc)==V4L2_PIX_FMT_TM6000) { rc=copy_multiplexed(t_buf, outp, len, urb, &buf); if (rc<=0) return rc; } else { copy_streams(t_buf, outp, len, urb, &buf); } } --- snip step 2 copy from temp buffer into videobuffer snip --- for (i=0;i<3072;i++) { switch(cmd) { case TM6000_URB_MSG_VIDEO: /* Fills video buffer */ memcpy(&out_p[(line << 1 + field) * block * 180], ptr[(i*184)+4], 180); printk (KERN_INFO "cmd=%s, size=%d\n", tm6000_msg_type[cmd],size); break; case TM6000_URB_MSG_PTS: printk (KERN_INFO "cmd=%s, size=%d\n", tm6000_msg_type[cmd],size); break; case TM6000_URB_MSG_AUDIO: /* Need some code to process audio */ printk ("%ld: cmd=%s, size=%d\n", jiffies, tm6000_msg_type[cmd],size); break; default: dprintk (dev, V4L2_DEBUG_ISOC, "cmd=%s, size=%d\n", printk (KERN_INFO "cmd=%s, size=%d\n", tm6000_msg_type[cmd],size); } } } --- snip This is a schemata to copy in videobuf. temp_buf = fifo size * block size viodeobuf = hight * wight * 2 Questions 1. Is it right if I copy the block without header to videobufer? 2. Can I full the videobuffer have more temp_bufs? 3. How are the actually data schema from urb to videobuffer? ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tm6000 calculating urb buffer 2010-05-04 15:38 ` tm6000 calculating urb buffer Stefan Ringel @ 2010-05-04 18:25 ` Mauro Carvalho Chehab 2010-05-04 19:13 ` Stefan Ringel 0 siblings, 1 reply; 6+ messages in thread From: Mauro Carvalho Chehab @ 2010-05-04 18:25 UTC (permalink / raw) To: Stefan Ringel; +Cc: Linux Media Mailing List Hi Stefan, Stefan Ringel wrote: > Am 30.04.2010 21:31, schrieb Stefan Ringel: >> Am 30.04.2010 18:34, schrieb Stefan Ringel: >> >>> Hi Mauro, >>> >>> Today I'm writing directly to you, because it doesn't work the mailing >>> list. I thought over the calculating urb buffer and I have follow idea: >>> >>> buffer = endpoint fifo size (3072 Bytes) * block size (184 Bytes) >>> >>> The actually calculating is a video frame size (image = width * hight * >>> 2 Bytes/Pixel), so that this buffer has to begin and to end an >>> uncomplete block. followed blocks are setting the logic to an err_mgs >>> block, so that going to lost frames. >>> >>> >>> >> I forgot a log with old calculating. >> >> > > > > 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. > > > step 1 > > copy from urb to temp buffer Why do you want to do triple buffering? This is a very bad idea. If you do it at the wrong way, by handling the copy at interrupt time, you're eating more power (and batteries, on notebooks), and reducing the machine speed. If you split it into two halves, you'll need a larger buffer area, since kernel will eventually join a few consecutive workqueue tasks into one, to avoid damaging other kernel process. Also, it will risk loosing frames or introduce a high delay. It is already bad enough to have a double buffering with those usb devices. Just as an example, the last time I've measured em28xx driver performance, after doing lots of optimization at the code, it were still consuming about 30% of CPU time of the machine I used for test (a typical mono-core Intel CPU). I know that the code would be simpler if we use a temporary buffer, but this way, we save CPU time. Also, if we do triple buffering, you'll likely add some delay when syncing between audio and video, due to the workqueue time. So, in summary, what we need to do is to validate the code and simplify it to be faster. If you take a look at tm6000-video.c, you'll see that I've tried already some different approaches. The one that is currently working is the first approach I did. As the newer solutions didn't solve the loss of data, but introduced newer bugs, I did a rollback to the code. At the time I stopped working on tm6000, I was about to write a new (simpler) approach, but still avoiding the double buffering. > > snip > ---- > for (i = 0; i < urb->number_of_packets; i++) { > int status = urb->iso_frame_desc[i].status; > > if (status<0) { > print_err_status (dev,i,status); > continue; > } > > len=urb->iso_frame_desc[i].actual_length; > > memcpy (t_buf[i*len], urb->transfer_buffer[i*len], len); > copied += len; > if (copied >= size || !buf) > break; > > } > > if (!urb->iso_frame_desc[i].status) { > if ((buf->fmt->fourcc)==V4L2_PIX_FMT_TM6000) { > rc=copy_multiplexed(t_buf, outp, len, urb, &buf); copy_multiplexed() is about what you want: It just copies everything (except for the URB headers), into a buffer, allowing decoding the data on userspace. There's an userspace application that gets those data, at v4l-utils tree. With this approach, you may add a decoder at libv4l for TM6000 format, and let userspace to do the audio/video/TS decoding. > if (rc<=0) > return rc; > } else { > copy_streams(t_buf, outp, len, urb, &buf); > } > } > --- > snip > > step 2 > > copy from temp buffer into videobuffer > > snip > --- > > for (i=0;i<3072;i++) { Doesn't work: nothing warrants that the device will start with a frame. > switch(cmd) { > case TM6000_URB_MSG_VIDEO: > /* Fills video buffer */ > memcpy(&out_p[(line << 1 + field) * block * 180], > ptr[(i*184)+4], 180); > printk (KERN_INFO "cmd=%s, size=%d\n", > tm6000_msg_type[cmd],size); > break; > case TM6000_URB_MSG_PTS: > printk (KERN_INFO "cmd=%s, size=%d\n", > tm6000_msg_type[cmd],size); > break; > case TM6000_URB_MSG_AUDIO: > /* Need some code to process audio */ > printk ("%ld: cmd=%s, size=%d\n", jiffies, > tm6000_msg_type[cmd],size); > break; > default: > dprintk (dev, V4L2_DEBUG_ISOC, "cmd=%s, size=%d\n", > printk (KERN_INFO "cmd=%s, size=%d\n", > tm6000_msg_type[cmd],size); > } > } > } > > --- > snip > > This is a schemata to copy in videobuf. > > temp_buf = fifo size * block size > > viodeobuf = hight * wight * 2 > > > Questions > > 1. Is it right if I copy the block without header to videobufer? > 2. Can I full the videobuffer have more temp_bufs? > 3. How are the actually data schema from urb to videobuffer? -- Cheers, Mauro ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tm6000 calculating urb buffer 2010-05-04 18:25 ` Mauro Carvalho Chehab @ 2010-05-04 19:13 ` Stefan Ringel 2010-05-04 19:50 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 6+ messages in thread From: Stefan Ringel @ 2010-05-04 19:13 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 04.05.2010 20:25, schrieb Mauro Carvalho Chehab: > Hi Stefan, > > Stefan Ringel wrote: >> Am 30.04.2010 21:31, schrieb Stefan Ringel: >>> Am 30.04.2010 18:34, schrieb Stefan Ringel: >>> >>>> Hi Mauro, >>>> >>>> Today I'm writing directly to you, because it doesn't work the mailing >>>> list. I thought over the calculating urb buffer and I have follow idea: >>>> >>>> buffer = endpoint fifo size (3072 Bytes) * block size (184 Bytes) >>>> >>>> The actually calculating is a video frame size (image = width * hight * >>>> 2 Bytes/Pixel), so that this buffer has to begin and to end an >>>> uncomplete block. followed blocks are setting the logic to an err_mgs >>>> block, so that going to lost frames. >>>> >>>> >>>> >>> I forgot a log with old calculating. >>> >>> >> >> >> >> 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) or how can I copy 180 Bytes Data from 184 Bytes block with an anligment of 184 urb pipe (184 * 3072 Bytes)? >> >> >> step 1 >> >> copy from urb to temp buffer > > Why do you want to do triple buffering? This is a very bad idea. > If you do it at the wrong way, by handling the copy at interrupt time, > you're eating more power (and batteries, on notebooks), and reducing > the machine speed. If you split it into two halves, you'll need a larger > buffer area, since kernel will eventually join a few consecutive workqueue tasks > into one, to avoid damaging other kernel process. Also, it will risk loosing > frames or introduce a high delay. > > It is already bad enough to have a double buffering with those usb devices. > Just as an example, the last time I've measured em28xx driver performance, > after doing lots of optimization at the code, it were still consuming > about 30% of CPU time of the machine I used for test (a typical > mono-core Intel CPU). > > I know that the code would be simpler if we use a temporary buffer, > but this way, we save CPU time. Also, if we do triple buffering, you'll > likely add some delay when syncing between audio and video, due to > the workqueue time. > > So, in summary, what we need to do is to validate the code and simplify > it to be faster. If you take a look at tm6000-video.c, you'll see that I've > tried already some different approaches. The one that is currently working > is the first approach I did. As the newer solutions didn't solve the loss > of data, but introduced newer bugs, I did a rollback to the code. At the time > I stopped working on tm6000, I was about to write a new (simpler) approach, > but still avoiding the double buffering. > >> >> snip >> ---- >> for (i = 0; i < urb->number_of_packets; i++) { >> int status = urb->iso_frame_desc[i].status; >> >> if (status<0) { >> print_err_status (dev,i,status); >> continue; >> } >> >> len=urb->iso_frame_desc[i].actual_length; >> >> memcpy (t_buf[i*len], urb->transfer_buffer[i*len], len); >> copied += len; >> if (copied >= size || !buf) >> break; >> >> } >> >> if (!urb->iso_frame_desc[i].status) { >> if ((buf->fmt->fourcc)==V4L2_PIX_FMT_TM6000) { >> rc=copy_multiplexed(t_buf, outp, len, urb, &buf); > > copy_multiplexed() is about what you want: It just copies everything > (except for the URB headers), into a buffer, allowing decoding the > data on userspace. There's an userspace application that gets those > data, at v4l-utils tree. With this approach, you may add a decoder > at libv4l for TM6000 format, and let userspace to do the audio/video/TS > decoding. > >> if (rc<=0) >> return rc; >> } else { >> copy_streams(t_buf, outp, len, urb, &buf); >> } >> } >> --- >> snip >> >> step 2 >> >> copy from temp buffer into videobuffer >> >> snip >> --- >> >> for (i=0;i<3072;i++) { > > Doesn't work: nothing warrants that the device will start with a frame. > >> switch(cmd) { >> case TM6000_URB_MSG_VIDEO: >> /* Fills video buffer */ >> memcpy(&out_p[(line << 1 + field) * block * 180], >> ptr[(i*184)+4], 180); >> printk (KERN_INFO "cmd=%s, size=%d\n", >> tm6000_msg_type[cmd],size); >> break; >> case TM6000_URB_MSG_PTS: >> printk (KERN_INFO "cmd=%s, size=%d\n", >> tm6000_msg_type[cmd],size); >> break; >> case TM6000_URB_MSG_AUDIO: >> /* Need some code to process audio */ >> printk ("%ld: cmd=%s, size=%d\n", jiffies, >> tm6000_msg_type[cmd],size); >> break; >> default: >> dprintk (dev, V4L2_DEBUG_ISOC, "cmd=%s, size=%d\n", >> printk (KERN_INFO "cmd=%s, size=%d\n", >> tm6000_msg_type[cmd],size); >> } >> } >> } >> >> --- >> snip >> >> This is a schemata to copy in videobuf. >> >> temp_buf = fifo size * block size >> >> viodeobuf = hight * wight * 2 >> >> >> Questions >> >> 1. Is it right if I copy the block without header to videobufer? >> 2. Can I full the videobuffer have more temp_bufs? >> 3. How are the actually data schema from urb to videobuffer? > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL4HHCAAoJEDX/lZlmjdJlnfwIAKTVHHCMCha0GH5qJUUkJPY2 OJtHYpiJzYo8v/k4fT24vJpy/nT74i3ssrKk8sS7Y1yj+1HwPnuUBgny1hqS/O3B 2D43eiFCN1riKnDkxIlTs+tbo3wvKOBOrY1rdRgOrC6FhAvFyQ5WS3PdraYt5oaQ 5oAAI6QT3lCfyQ6LSLfuw64BAtohRZ1jNVp5rh5CBr0gWsfrQrQsset0F6w6o0O9 Gj02w6HqMJJdZBKImMhgkbgY11jN9476JsyRoh2me1Hhf18kWt30Cjyccvfydo2U tdc5EelrAXseu8HmdBZlMgYrarWvL0AHXXH/hJfxzt7sW/d2Mw/XuSJD+BMh7rk= =Zx8V -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tm6000 calculating urb buffer 2010-05-04 19:13 ` Stefan Ringel @ 2010-05-04 19:50 ` Mauro Carvalho Chehab 2010-05-04 19:58 ` Stefan Ringel 0 siblings, 1 reply; 6+ messages in thread From: Mauro Carvalho Chehab @ 2010-05-04 19:50 UTC (permalink / raw) To: Stefan Ringel; +Cc: Linux Media Mailing List 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. -- Cheers, Mauro ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tm6000 calculating urb buffer 2010-05-04 19:50 ` Mauro Carvalho Chehab @ 2010-05-04 19:58 ` Stefan Ringel 2010-05-05 6:07 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 6+ messages in thread From: Stefan Ringel @ 2010-05-04 19:58 UTC (permalink / raw) To: Mauro Carvalho Chehab; +Cc: Linux Media Mailing List -----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----- ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: tm6000 calculating urb buffer 2010-05-04 19:58 ` Stefan Ringel @ 2010-05-05 6:07 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 6+ messages in thread From: Mauro Carvalho Chehab @ 2010-05-05 6:07 UTC (permalink / raw) To: Stefan Ringel; +Cc: Linux Media Mailing List Stefan Ringel wrote: > -----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. It is a worthy trial to use this value for the number of packets. Yet, as someone might have run the device on windows before, it will still need to seek for the segment start. Cheers, Mauro ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-05 6:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4BDB067E.4070501@arcor.de>
[not found] ` <4BDB3017.9070101@arcor.de>
2010-05-04 15:38 ` tm6000 calculating urb buffer Stefan Ringel
2010-05-04 18:25 ` Mauro Carvalho Chehab
2010-05-04 19:13 ` Stefan Ringel
2010-05-04 19:50 ` Mauro Carvalho Chehab
2010-05-04 19:58 ` Stefan Ringel
2010-05-05 6:07 ` Mauro Carvalho Chehab
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.