[GIT PATCHES FOR 2.6.36] gspca for_2.6.36

2010-06-27 Thread Jean-Francois Moine 
Hi Mauro,

The following changes apply to the 'linuxtv/staging/gspca' branch.
Merge is needed for 2.6.36 (usb_buffer_alloc - usb_alloc_coherent
done in 2.6.35-rc3).

The following changes since commit
484cd5e6805f04c7381d73af4ace2fe221a76dea:

  V4L/DVB: gspca - main: Remove V4L1 compatibility (2010-06-26 10:24:44
  -0300)

are available in the git repository at:
  git://linuxtv.org/jfrancois/gspca.git for_2.6.36

Jean-François Moine (2):
  gspca - gl860: Fix a compilation warning.
  gspca - main: Simplify image building.

 drivers/media/video/gspca/cpia1.c  |   15 +++---
 drivers/media/video/gspca/gl860/gl860-mi2020.c |2 +-
 drivers/media/video/gspca/gspca.c  |   65
 +++-
 drivers/media/video/gspca/gspca.h  |5 +-
 drivers/media/video/gspca/m5602/m5602_core.c   |   12 ++---
 drivers/media/video/gspca/ov519.c  |6 +--
 drivers/media/video/gspca/ov534.c  |7 +--
 drivers/media/video/gspca/pac7302.c|   24 -
 drivers/media/video/gspca/pac7311.c|   24 -
 drivers/media/video/gspca/sonixb.c |6 +--
 drivers/media/video/gspca/vc032x.c |   13 ++--- 11 files
 changed, 80 insertions(+), 99 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function

2010-06-27 Thread Marko Ristola 

Hi

Here is an improved version of the original patch:
The original patch removed unnecessary copying for 204 sized packets only.
This patch improves performance for 188 sized packets too.

Unnecessary copying means: if dvb_dmx_swfilter(_204)() doesn't have to
modify
the source packet, the source packet is delivered for
dvb_dmx_swfilter_packet()
without copying.

This assumes, that a DMA transfer won't modify the accepted 188/204 sized
packet underneath while dvb_dmx_swfilter_packet() processes it.
The assumption is already in dvb_dmx_swfilter_packets().

With tasklets the risk for breaking the assumption is low. If there
would be
a normal thread instead of a tasklet, copying from the DMA buffer might
come too late.

Could someone test this patch who uses the dvb_dmx_swfilter() function
(188 sized)?

So _dvb_dmx_swfilter is now common for both 188 and 204 sized packet
parsing.
The measure was done during recording of H.264 steram under VDR,
using perf top -d 10

   PerfTop:  62 irqs/sec  kernel:80.6% [1000Hz cycles],  (all, 1 CPUs)

 samples  pcnt
functionDSO

  339.00 18.1%
dvb_dmx_swfilter_packet
[dvb_core]   
  315.00 16.9%
acpi_pm_read   
[kernel.kallsyms]
   70.00  3.7%
_ZN2SI5CRC325crc32EPKcij   
/usr/sbin/vdr
   53.00  2.8%
mantis_i2c_xfer
[mantis_core]
   53.00  2.8%
__mktime_internal  
/lib64/libc-2.12.so  
   39.00  2.1%
_ZN14cAudioRepacker6RepackEP17cRingBufferLinearPKhi
/usr/sbin/vdr
   33.00  1.8%
delay_tsc  
[kernel.kallsyms]
   30.00  1.6%
dvb_dmx_memcopy
[dvb_core]   
   28.00  1.5%
dvb_ringbuffer_write   
[dvb_core]   
   28.00  1.5%
_dvb_dmx_swfilter  
[dvb_core]   


diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
b/drivers/media/dvb/dvb-core/dvb_demux.c
index 977ddba..2dd 100644
--- a/drivers/media/dvb/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb/dvb-core/dvb_demux.c
@@ -478,95 +478,78 @@ void dvb_dmx_swfilter_packets(struct dvb_demux
*demux, const u8 *buf,
 
 EXPORT_SYMBOL(dvb_dmx_swfilter_packets);
 
-void dvb_dmx_swfilter(struct dvb_demux *demux, const u8 *buf, size_t count)
+static inline int findNextSyncByte(const u8 *buf, int pos, size_t
count, const int pktsize)
+{
+while(likely(pos  count)) {
+if (likely(buf[pos] == 0x47 || (pktsize == 204  buf[pos] ==
0xB8)))
+break;
+pos++;
+}
+
+return pos;
+}
+
+/* pktsize must be either 204 or 188. If pktsize is 204, 0xB8 must be
accepted for SYNC byte too, but then convert it into 0x47.
+ * Designed pktsize so, that compiler would remove 204 related code
during inlining. */
+static inline void _dvb_dmx_swfilter(struct dvb_demux *demux, const u8
*buf, size_t count, const int pktsize)
 {
 int p = 0, i, j;
+const u8 *q;
 
 spin_lock(demux-lock);
 
-if (demux-tsbufp) {
+if (likely(demux-tsbufp)) { /* tsbuf[0] is now 0x47. */
 i = demux-tsbufp;
-j = 188 - i;
-if (count  j) {
+j = pktsize - i;
+if (unlikely(count  j)) {
 memcpy(demux-tsbuf[i], buf, count);
 demux-tsbufp += count;
 goto bailout;
 }
 memcpy(demux-tsbuf[i], buf, j);
-if (demux-tsbuf[0] == 0x47)
+if (likely(demux-tsbuf[0] == 0x47)) /* double check */
 dvb_dmx_swfilter_packet(demux, demux-tsbuf);
 demux-tsbufp = 0;
 p += j;
 }
 
-while (p  count) {
-if (buf[p] == 0x47) {
-if (count - p = 188) {
-dvb_dmx_swfilter_packet(demux, buf[p]);
-p += 188;
-} else {
-i = count - p;
-memcpy(demux-tsbuf, buf[p], i);
-demux-tsbufp = i;
-goto bailout;
-}
-} else
-p++;
+while (likely((p = findNextSyncByte(buf, p, count, pktsize)) 
count)) {
+if (unlikely(count - p  pktsize))
+break;
+
+q = buf[p];
+
+if (unlikely(pktsize == 204  (*q == 0xB8))) {
+memcpy(demux-tsbuf, q, 188);
+demux-tsbuf[0] = 0x47;
+q = demux-tsbuf;
+}
+

Re: Correct way to do s_ctrl ioctl taking into account subdev framework?

2010-06-27 Thread Hans Verkuil 
On Saturday 26 June 2010 21:04:51 Devin Heitmueller wrote:
 On Sat, Jun 26, 2010 at 2:51 PM, Hans Verkuil hverk...@xs4all.nl wrote:
  There really is no good way at the moment to handle cases like this, or at
  least not without a lot of work.
 
 Ok, it's good to know I'm not missing something obvious.
 
  The plan is to have the framework merged in time for 2.6.36. My last patch
  series for the framework already converts a bunch of subdevs to use it. Your
  best bet is to take the patch series and convert any remaining subdevs used
  by em28xx and em28xx itself. I'd be happy to add those patches to my patch
  series, so that when I get the go ahead the em28xx driver will be fixed
  automatically.
 
  It would be useful for me anyway to have someone else use it: it's a good
  check whether my documentation is complete.
 
 Sure, could you please point me to the tree in question and I'll take a look?

http://git.linuxtv.org/hverkuil/v4l-dvb.git, branch ctrlfw5.

This tree is based on the latest v4l-dvb master.

Laurent, when you start working on moving UVC over to the control framework,
please use this new branch. The old patch series no longer applies cleanly
due to changes in the master.

Regards,

 Hans

 
 Given I've got applications failing, for the short term I will likely
 just submit a patch which makes the s_ctrl always return zero
 regardless of the subdev response, instead of returning 1.
 
 Thanks,
 
 Devin
 
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Correct way to do s_ctrl ioctl taking into account subdev framework?

2010-06-27 Thread Mauro Carvalho Chehab 
Em 27-06-2010 00:26, Devin Heitmueller escreveu:
 On Sat, Jun 26, 2010 at 9:34 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 would do the trick. Yet, the application is broken, as it is considering a 
 positive
 return as an error. A positive code should never be considered as an error. 
 So, we
 need to fix v4l2-ctl as well (ok, returning 1 is wrong as well, as this is a 
 non-v4l2
 compliance in this case).
 
 A strict interpretation of the spec would read that returning zero is
 success, -1 is an well-formed error condition, and *ANYTHING* else is
 a violation of the spec and an application used for testing compliance
 should complain very loudly (which is exactly what it does).
 
 In effect, the only patch I would consider valid for v4l2-ctl would be
 one that makes the error even more LOUD than it already is.

It should output it as an API violation, not as a failure on setting the value.
That's said, I think that a few ioctl calls used to return positive values under
certain special conditions. Not sure if this is a non-compliance or if the 
API allows it.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] ir-core: convert em28xx to not use ir-functions.c

2010-06-27 Thread Mauro Carvalho Chehab 
Em 07-06-2010 16:32, David Härdeman escreveu:
 Convert drivers/media/video/em28xx/em28xx-input.c to not use ir-functions.c
 
 Signed-off-by: David Härdeman da...@hardeman.nu

This patch caused a bad effect: if some key were pressed before loading the 
driver, it
causes endless repetitions of the last keycode:

[ 2126.019882] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
data=1e07
[ 2126.126629] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
data=1e07
[ 2126.233253] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
data=1e07
[ 2126.339875] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
data=1e07
[ 2126.446625] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
data=1e07

I'll try to fix it and apply a patch to solve it.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] ir-core: convert em28xx to not use ir-functions.c

2010-06-27 Thread Mauro Carvalho Chehab 
Em 27-06-2010 07:23, Mauro Carvalho Chehab escreveu:
 Em 07-06-2010 16:32, David Härdeman escreveu:
 Convert drivers/media/video/em28xx/em28xx-input.c to not use ir-functions.c

 Signed-off-by: David Härdeman da...@hardeman.nu
 
 This patch caused a bad effect: if some key were pressed before loading the 
 driver, it
 causes endless repetitions of the last keycode:
 
 [ 2126.019882] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
 data=1e07
 [ 2126.126629] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
 data=1e07
 [ 2126.233253] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
 data=1e07
 [ 2126.339875] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
 data=1e07
 [ 2126.446625] em28xx IR (em28xx #0)/ir: ir-get_key result tb=01 rc=01 lr=01 
 data=1e07
 
 I'll try to fix it and apply a patch to solve it.

Hmm.. in a matter of fact, the problem were in the printk... it were generating 
one line for
each poll interval.

After fixing it, your patch looks ok:

[ 3072.019846] em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, 
count: 1, key 0x1e01
[ 3072.028390] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e01 
keycode 0x02
[ 3072.036655] ir_keydown: em28xx IR (em28xx #0): key down event, key 0x0002, 
scancode 0x1e01
[ 3072.143218] em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, 
count: 2, key 0x1e01
[ 3072.151773] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e01 
keycode 0x02
[ 3072.409709] ir_keyup: keyup key 0x0002

Also, the test for read_count  0 is not needed, and, in fact, can cause 
loosing one key when
the 6-bits wide repetition counter reaches their maximum value:

[ 3484.999804] em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, 
count: 127, key 0x1e02
[ 3485.116431] em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, 
count: 0, key 0x1e02

---

em28xx-input: Don't generate one debug message for every get_key read

Instead of generating one printk for every IR read, prints it only when 
count is different from the last count.

While here, as this code is called on every 100ms during the runtime 
lifetime, do some performance optimization, assuming that, under normal 
circumstances, it is unlikely that the driver would get a new key/key
repeat on every poll.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/video/em28xx/em28xx-input.c 
b/drivers/media/video/em28xx/em28xx-input.c
index dd6d528..6759cd5 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -292,18 +292,15 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir)
 
/* read the registers containing the IR status */
result = ir-get_key(ir, poll_result);
-   if (result  0) {
+   if (unlikely(result  0)) {
dprintk(ir-get_key() failed %d\n, result);
return;
}
 
-   dprintk(ir-get_key result tb=%02x rc=%02x lr=%02x data=%02x%02x\n,
-   poll_result.toggle_bit, poll_result.read_count,
-   ir-last_readcount, poll_result.rc_address,
-   poll_result.rc_data[0]);
-
-   if (poll_result.read_count  0 
-   poll_result.read_count != ir-last_readcount) {
+   if (unlikely(poll_result.read_count != ir-last_readcount)) {
+   dprintk(%s: toggle: %d, count: %d, key 0x%02x%02x\n, __func__,
+   poll_result.toggle_bit, poll_result.read_count,
+   poll_result.rc_address, poll_result.rc_data[0]);
if (ir-full_code)
ir_keydown(ir-input,
   poll_result.rc_address  8 |
@@ -313,17 +310,17 @@ static void em28xx_ir_handle_key(struct em28xx_IR *ir)
ir_keydown(ir-input,
   poll_result.rc_data[0],
   poll_result.toggle_bit);
-   }
 
-   if (ir-dev-chip_id == CHIP_ID_EM2874)
-   /* The em2874 clears the readcount field every time the
-  register is read.  The em2860/2880 datasheet says that it
-  is supposed to clear the readcount, but it doesn't.  So with
-  the em2874, we are looking for a non-zero read count as
-  opposed to a readcount that is incrementing */
-   ir-last_readcount = 0;
-   else
-   ir-last_readcount = poll_result.read_count;
+   if (ir-dev-chip_id == CHIP_ID_EM2874)
+   /* The em2874 clears the readcount field every time the
+  register is read.  The em2860/2880 datasheet says 
that it
+  is supposed to clear the readcount, but it doesn't.  
So with
+  the em2874, we are looking for a non-zero read count 
as
+  opposed to a readcount that is incrementing */
+

Re: [PATCH 5/8] ir-core: partially convert bt8xx to not use ir-functions.c

2010-06-27 Thread Mauro Carvalho Chehab 
Em 07-06-2010 16:32, David Härdeman escreveu:
 Partially convert drivers/media/video/bt8xx/bttv-input.c to
 not use ir-functions.c.
 
 Since the last user is gone with this patch, also remove a
 bunch of code from ir-functions.c.

This patch breakd mceusb driver:

drivers/media/IR/mceusb.c: In function ‘mceusb_init_input_dev’:
drivers/media/IR/mceusb.c:774: error: invalid application of ‘sizeof’ to 
incomplete type ‘struct ir_input_state’ 
drivers/media/IR/mceusb.c:785: error: implicit declaration of function 
‘ir_input_init’
make[1]: ** [drivers/media/IR/mceusb.o] Erro 1
make[1]: ** Esperando que outros processos terminem.
make: ** [drivers/media/IR/] Erro 2

Also, the description is wrong, since it changes not only bttv, but also 
cx23885 and saa7134.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

tm6000 + audio

2010-06-27 Thread Stefan Ringel 
Mauro,

I have great problems with _tm6000_start_audio_dma if I started mencoder
or arecord. It creashed and after a while it frosts in. (It hasn't logged).

Stefan Ringel

-- 
Stefan Ringel stefan.rin...@arcor.de

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TS discontinuity with TT S-2300

2010-06-27 Thread Oliver Endriss 
Hi,

On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
 Hi,
 
 I'm loosing TS packets in my dual CAM premium TT S-2300 card (av7110+saa7146).
 
 Is it possible the problem is in firmware? Here is the description:
 
 04:00.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
 Subsystem: Technotrend Systemtechnik GmbH Technotrend/Hauppauge DVB 
 card rev2.3
 Flags: bus master, medium devsel, latency 32, IRQ 20
 Memory at fddff000 (32-bit, non-prefetchable) [size=512]
 Kernel driver in use: dvb
 
 dvb :04:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20
 IRQ 20/: IRQF_DISABLED is not guaranteed on shared IRQs
 saa7146: found saa7146 @ mem c90005248000 (revision 1, irq 20) 
 (0x13c2,0x000e).
 dvb :04:00.0: firmware: requesting dvb-ttpci-01.fw
 DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.3)
 adapter has MAC addr = 00:d0:5c:04:2e:ea
 dvb :04:00.0: firmware: requesting av7110/bootcode.bin
 dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 
 80f12623
 dvb-ttpci: firmware @ card 0 supports CI link layer interface
 
 I've tried also:
  dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 
 8000261a
  dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 
 80002622
 without any impact.
 
 SR of my signal is 27500, 2x official CAMs (videoguard).
 
 I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex,
 descramble them and stream them to network. Dvblast reports TS
 discontinuity across all video PIDs only (no audio) usually every
 1-3 minutes ~80 packets. But sometimes it goes well for tens of
 minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.
 
 Do you thing it is av7110 issue? Do you know any relevant limits of
 av7110? What should I test/try more? Thanks 

The full-featured cards are not able to deliver the full bandwidth of a
transponder. It is a limitaion of the board design, not a firmware or
driver issue.

You can fix this by applying the 'full-ts' hardware modification.
For more information follow the link in my signature.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] ir-core: partially convert bt8xx to not use ir-functions.c

2010-06-27 Thread Andy Walls 
On Sun, 2010-06-27 at 09:11 -0300, Mauro Carvalho Chehab wrote:
 Em 07-06-2010 16:32, David Härdeman escreveu:
  Partially convert drivers/media/video/bt8xx/bttv-input.c to
  not use ir-functions.c.
  
  Since the last user is gone with this patch, also remove a
  bunch of code from ir-functions.c.
 
 This patch breakd mceusb driver:
 
 drivers/media/IR/mceusb.c: In function ‘mceusb_init_input_dev’:
 drivers/media/IR/mceusb.c:774: error: invalid application of ‘sizeof’ to 
 incomplete type ‘struct ir_input_state’ 
 drivers/media/IR/mceusb.c:785: error: implicit declaration of function 
 ‘ir_input_init’
 make[1]: ** [drivers/media/IR/mceusb.o] Erro 1
 make[1]: ** Esperando que outros processos terminem.
 make: ** [drivers/media/IR/] Erro 2
 
 Also, the description is wrong, since it changes not only bttv, but also 
 cx23885 and saa7134.

Mauro,

I'll be removing the RC5 and NEC decoding from the cx23885 driver
hopefully by the end of the day.  That will make parts of David's patch
obsolete.

I'll be developing off of the v4l-dvb.git staging/rc branch.  Is that
the right branch to use?

Also the IR registration Ooops is not patched in staging/rc, so the
cx23885 driver Oops-es on load.  Is it OK if I pull in (fetch  merge)
the patch from some other branch, or would it be easier for you if I
just use an uncommitted patch in my working tree?

Regards,
Andy

Mauro



 Cheers,
 Mauro
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TS discontinuity with TT S-2300

2010-06-27 Thread Jaroslav Klaus 

On 27.6.2010, at 14:37, Oliver Endriss wrote:

 Hi,
 
 On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
 Hi,
 
 I'm loosing TS packets in my dual CAM premium TT S-2300 card 
 (av7110+saa7146).
 Do you thing it is av7110 issue? Do you know any relevant limits of
 av7110? What should I test/try more? Thanks 
 
 The full-featured cards are not able to deliver the full bandwidth of a
 transponder. It is a limitaion of the board design, not a firmware or
 driver issue.

I thought full bandwidth is impossible to process but I thought 4 TV channel 
should be ok. It's too much obviously. Especially when peaks of all TV channels 
meet in the same time.

 You can fix this by applying the 'full-ts' hardware modification.
 For more information follow the link in my signature.

Great link. This really make sense. Thanks

Jaroslav

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TS discontinuity with TT S-2300

2010-06-27 Thread Marko Ristola 
27.06.2010 15:37, Oliver Endriss wrote:
 Hi,

 On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:
   
 Hi,

 I'm loosing TS packets in my dual CAM premium TT S-2300 card 
 (av7110+saa7146).

 I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex,
 descramble them and stream them to network. Dvblast reports TS
 discontinuity across all video PIDs only (no audio) usually every
 1-3 minutes ~80 packets. But sometimes it goes well for tens of
 minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.

 
 The full-featured cards are not able to deliver the full bandwidth of a
 transponder. It is a limitaion of the board design, not a firmware or
 driver issue.
   
I noticed that saa7146 uses dvb_dmx_swfilter_packets().

I planned using of that function too for
Mantis 16K buffer delivery, but I found out that
hardware delivers sometimes additional bytes (corrupted partially lost
packets?)
between the full sized 204 byte packets:

Jun 26 16:20:37 koivu kernel: demux: skipped 49 bytes at position 3379
Jun 26 16:20:37 koivu kernel: demux: skipped 18 bytes at position 9868
Jun 26 16:20:37 koivu kernel: demux: skipped 30 bytes at position 10090
Jun 26 16:20:38 koivu kernel: demux: skipped 14 bytes at position 7208
Jun 26 16:20:38 koivu kernel: demux: skipped 114 bytes at position 7426

So dvb_dmx_swfilter(_204)() is needed to skip
these unwanted bytes. With simple usage of
dvb_dmx_swfilter_packets() the rest of the buffer
would have been lost. I wrote a faster version of these
functions, also for 188 sized packets today:
Re: [PATCH] Avoid unnecessary data copying inside
dvb_dmx_swfilter_204() function

CU
Marko


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

v4l-dvb bug report

2010-06-27 Thread matteo sisti sette 
Hi,

I am a newbee so please be patient with me. I have followed all the
instructions and I tried to compile the sources and got a lot of
errors. I don't think it's my fault but i may be wrong.

My system: Ubuntu 10.04 with kernel 2.6.32.22
I have the headers installed, not the full kernel source code
(shouldn't be required).

My dvb-t interface is an usb stick: Conceptronic CTVDIGUSB2, I believe
it has an afatech chipset. Here's the output from lsusb:
Bus 002 Device 007: ID 1b80:d393 Afatech

I downloaded the latest v4l-dvb source from
hg clone http://linuxtv.org/hg/v4l-dvb

I had a look at the daily test log and I don't see any test against 2.6.32.22

Here's the output from make:

t...@xxx:~/v4l-dvb$ sudo make
make -C /home/teo/v4l-dvb/v4l
make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
No version yet, using 2.6.32-22-generic
make[1]: Leaving directory `/home/teo/v4l-dvb/v4l'
make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
scripts/make_makefile.pl
Updating/Creating .config
Preparing to compile for kernel version 2.6.32

***WARNING:*** You do not have the full kernel sources installed.
This does not prevent you from building the v4l-dvb tree if you have the
kernel headers, but the full kernel source may be required in order to use
make menuconfig / xconfig / qconfig.

If you are experiencing problems building the v4l-dvb tree, please try
building against a vanilla kernel before reporting a bug.

Vanilla kernels are available at http://kernel.org.
On most distros, this will compile a newly downloaded kernel:

cp /boot/config-`uname -r` your kernel dir/.config
cd your kernel dir
make all modules_install install

Please see your distro's web site for instructions to build a new kernel.

V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33
VIDEO_TVP7002: Requires at least kernel 2.6.34
VIDEO_AK881X: Requires at least kernel 2.6.33
SOC_CAMERA: Requires at least kernel 2.6.33
SOC_CAMERA_MT9M001: Requires at least kernel 2.6.33
SOC_CAMERA_MT9M111: Requires at least kernel 2.6.33
SOC_CAMERA_MT9T031: Requires at least kernel 2.6.33
SOC_CAMERA_MT9V022: Requires at least kernel 2.6.33
SOC_CAMERA_TW9910: Requires at least kernel 2.6.33
SOC_CAMERA_PLATFORM: Requires at least kernel 2.6.33
SOC_CAMERA_OV772X: Requires at least kernel 2.6.33
RADIO_SAA7706H: Requires at least kernel 2.6.34
Created default (all yes) .config file
./scripts/make_myconfig.pl
make[1]: Leaving directory `/home/teo/v4l-dvb/v4l'
make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
perl scripts/make_config_compat.pl
/lib/modules/2.6.32-22-generic/build ./.myconfig ./config-compat.h
creating symbolic links...
ln -sf . oss
make -C firmware prep
make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware'
make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware'
make -C firmware
make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware'
 CC  ihex2fw
Generating vicam/firmware.fw
Generating dabusb/firmware.fw
Generating dabusb/bitstream.bin
Generating ttusb-budget/dspbootcode.bin
Generating cpia2/stv0672_vp4.bin
Generating av7110/bootcode.bin
make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware'
Kernel build directory is /lib/modules/2.6.32-22-generic/build
make -C /lib/modules/2.6.32-22-generic/build
SUBDIRS=/home/teo/v4l-dvb/v4l  modules
make[2]: Entering directory `/usr/src/linux-headers-2.6.32-22-generic'
 CC [M]  /home/teo/v4l-dvb/v4l/tuner-xc2028.o
 CC [M]  /home/teo/v4l-dvb/v4l/tuner-simple.o
 CC [M]  /home/teo/v4l-dvb/v4l/tuner-types.o
 CC [M]  /home/teo/v4l-dvb/v4l/mt20xx.o
 CC [M]  /home/teo/v4l-dvb/v4l/tda8290.o
 CC [M]  /home/teo/v4l-dvb/v4l/tea5767.o
 CC [M]  /home/teo/v4l-dvb/v4l/tea5761.o
 CC [M]  /home/teo/v4l-dvb/v4l/tda9887.o
 CC [M]  /home/teo/v4l-dvb/v4l/tda827x.o
 CC [M]  /home/teo/v4l-dvb/v4l/au0828-core.o
 CC [M]  /home/teo/v4l-dvb/v4l/au0828-i2c.o
 CC [M]  /home/teo/v4l-dvb/v4l/au0828-cards.o
 CC [M]  /home/teo/v4l-dvb/v4l/au0828-dvb.o
 CC [M]  /home/teo/v4l-dvb/v4l/au0828-video.o
 CC [M]  /home/teo/v4l-dvb/v4l/au8522_dig.o
 CC [M]  /home/teo/v4l-dvb/v4l/au8522_decoder.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-pci.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-usb.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-fe-tuner.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-i2c.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-sram.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-eeprom.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-misc.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-hw-filter.o
 CC [M]  /home/teo/v4l-dvb/v4l/flexcop-dma.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-driver.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-cards.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-if.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-risc.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-vbi.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-i2c.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-gpio.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-input.o
 CC [M]  /home/teo/v4l-dvb/v4l/bttv-audio-hook.o
 CC [M]  /home/teo/v4l-dvb/v4l/cpia2_v4l.o
 CC [M]  /home/teo/v4l-dvb/v4l/cpia2_usb.o
 CC [M]

Re: TS discontinuity with TT S-2300

2010-06-27 Thread Oliver Endriss 
On Sunday 27 June 2010 17:56:06 Marko Ristola wrote:
 27.06.2010 15:37, Oliver Endriss wrote:
  Hi,
 
  On Sunday 27 June 2010 01:05:57 Jaroslav Klaus wrote:

  Hi,
 
  I'm loosing TS packets in my dual CAM premium TT S-2300 card 
  (av7110+saa7146).
 
  I use dvblast to select 4 TV channels (~ 16 PIDs) from multiplex,
  descramble them and stream them to network. Dvblast reports TS
  discontinuity across all video PIDs only (no audio) usually every
  1-3 minutes ~80 packets. But sometimes it goes well for tens of
  minutes (up to 1-2hours). Everything seems to be ok with 3 TV channels.
 
  
  The full-featured cards are not able to deliver the full bandwidth of a
  transponder. It is a limitaion of the board design, not a firmware or
  driver issue.

 I noticed that saa7146 uses dvb_dmx_swfilter_packets().

Yes.

 I planned using of that function too for
 Mantis 16K buffer delivery, but I found out that
 hardware delivers sometimes additional bytes (corrupted partially lost
 packets?)
 between the full sized 204 byte packets:
 
 Jun 26 16:20:37 koivu kernel: demux: skipped 49 bytes at position 3379
 Jun 26 16:20:37 koivu kernel: demux: skipped 18 bytes at position 9868
 Jun 26 16:20:37 koivu kernel: demux: skipped 30 bytes at position 10090
 Jun 26 16:20:38 koivu kernel: demux: skipped 14 bytes at position 7208
 Jun 26 16:20:38 koivu kernel: demux: skipped 114 bytes at position 7426

Are you sure that Mantis driver delivers garbage, not partial packets?
Please note that the dvb_dmx_swfilter[_204]() routines must accept
partial packets, i.e. the rest of the packet will be dellivered with the
next call.

 So dvb_dmx_swfilter(_204)() is needed to skip
 these unwanted bytes. With simple usage of
 dvb_dmx_swfilter_packets() the rest of the buffer
 would have been lost. I wrote a faster version of these
 functions, also for 188 sized packets today:
 Re: [PATCH] Avoid unnecessary data copying inside
 dvb_dmx_swfilter_204() function

dvb_dmx_swfilter_packets() expects complete TS packets from the driver.
The saa7146 does so. It does not deliver garbage data. (Otherwise this
would have been noticed a long time ago. The ttpci drivers are the
oldest DVB drivers and are very well tested.)

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: v4l-dvb bug report

2010-06-27 Thread Villy Thomsen 
Hi Matteo,

I had the same problem a while ago. Short answer, the firedtv driver
needs full kernel source to compile. I think I ended up with the full
kernel source for other reasons (you need full source if you are going
to use make menuconfig/oldconfig/etc).

But if make menuconfig and/or the firedtv driver doesn't matter for
you - find your v4l-dvb/v4l/.config file, search for FIREDTV and set
those entries to =n instead of =m or =y and you should be in business.

Regards,

Villy

 I am a newbee so please be patient with me. I have followed all the
 instructions and I tried to compile the sources and got a lot of
 errors. I don't think it's my fault but i may be wrong.

 My system: Ubuntu 10.04 with kernel 2.6.32.22
 I have the headers installed, not the full kernel source code
 (shouldn't be required).

 My dvb-t interface is an usb stick: Conceptronic CTVDIGUSB2, I believe
 it has an afatech chipset. Here's the output from lsusb:
 Bus 002 Device 007: ID 1b80:d393 Afatech

 I downloaded the latest v4l-dvb source from
 hg clone http://linuxtv.org/hg/v4l-dvb

 I had a look at the daily test log and I don't see any test against 2.6.32.22

 Here's the output from make:

 t...@xxx:~/v4l-dvb$ sudo make
 make -C /home/teo/v4l-dvb/v4l
 make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
 No version yet, using 2.6.32-22-generic
 make[1]: Leaving directory `/home/teo/v4l-dvb/v4l'
 make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
 scripts/make_makefile.pl
 Updating/Creating .config
 Preparing to compile for kernel version 2.6.32

 ***WARNING:*** You do not have the full kernel sources installed.
 This does not prevent you from building the v4l-dvb tree if you have the
 kernel headers, but the full kernel source may be required in order to use
 make menuconfig / xconfig / qconfig.

 If you are experiencing problems building the v4l-dvb tree, please try
 building against a vanilla kernel before reporting a bug.

 Vanilla kernels are available at http://kernel.org.
 On most distros, this will compile a newly downloaded kernel:

 cp /boot/config-`uname -r` your kernel dir/.config
 cd your kernel dir
 make all modules_install install

 Please see your distro's web site for instructions to build a new kernel.

 V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33
 VIDEO_TVP7002: Requires at least kernel 2.6.34
 VIDEO_AK881X: Requires at least kernel 2.6.33
 SOC_CAMERA: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9M001: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9M111: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9T031: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9V022: Requires at least kernel 2.6.33
 SOC_CAMERA_TW9910: Requires at least kernel 2.6.33
 SOC_CAMERA_PLATFORM: Requires at least kernel 2.6.33
 SOC_CAMERA_OV772X: Requires at least kernel 2.6.33
 RADIO_SAA7706H: Requires at least kernel 2.6.34
 Created default (all yes) .config file
 ./scripts/make_myconfig.pl
 make[1]: Leaving directory `/home/teo/v4l-dvb/v4l'
 make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
 perl scripts/make_config_compat.pl
 /lib/modules/2.6.32-22-generic/build ./.myconfig ./config-compat.h
 creating symbolic links...
 ln -sf . oss
 make -C firmware prep
 make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware'
 make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware'
 make -C firmware
 make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware'
  CC  ihex2fw
 Generating vicam/firmware.fw
 Generating dabusb/firmware.fw
 Generating dabusb/bitstream.bin
 Generating ttusb-budget/dspbootcode.bin
 Generating cpia2/stv0672_vp4.bin
 Generating av7110/bootcode.bin
 make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware'
 Kernel build directory is /lib/modules/2.6.32-22-generic/build
 make -C /lib/modules/2.6.32-22-generic/build
 SUBDIRS=/home/teo/v4l-dvb/v4l  modules
 make[2]: Entering directory `/usr/src/linux-headers-2.6.32-22-generic'
  CC [M]  /home/teo/v4l-dvb/v4l/tuner-xc2028.o
  CC [M]  /home/teo/v4l-dvb/v4l/tuner-simple.o
  CC [M]  /home/teo/v4l-dvb/v4l/tuner-types.o
  CC [M]  /home/teo/v4l-dvb/v4l/mt20xx.o
  CC [M]  /home/teo/v4l-dvb/v4l/tda8290.o
  CC [M]  /home/teo/v4l-dvb/v4l/tea5767.o
  CC [M]  /home/teo/v4l-dvb/v4l/tea5761.o
  CC [M]  /home/teo/v4l-dvb/v4l/tda9887.o
  CC [M]  /home/teo/v4l-dvb/v4l/tda827x.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-core.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-i2c.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-cards.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-dvb.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-video.o
  CC [M]  /home/teo/v4l-dvb/v4l/au8522_dig.o
  CC [M]  /home/teo/v4l-dvb/v4l/au8522_decoder.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-pci.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-usb.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-fe-tuner.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-i2c.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-sram.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-eeprom.o
  CC [M]  /home/teo/v4l-dvb/v4l/flexcop-misc.o
  CC [M]  

Re: v4l-dvb bug report

2010-06-27 Thread matteo sisti sette 
Yeah, thank you, I have found the FIREDTV=n trick on some other forum
just a few minutes before I read your reply, and with that change it
has compiled fine :)

I'm not sure what firedtv is but I don't think I need it :)

By the way may I ask a newbie question? If you need the kernel sources
to compile v4l-dvb, it does not mean that you're recompiling the
kernel, does it? :$

Thanks
m.


2010/6/27 Villy Thomsen vill...@gmail.com:
 Hi Matteo,

 I had the same problem a while ago. Short answer, the firedtv driver
 needs full kernel source to compile. I think I ended up with the full
 kernel source for other reasons (you need full source if you are going
 to use make menuconfig/oldconfig/etc).

 But if make menuconfig and/or the firedtv driver doesn't matter for
 you - find your v4l-dvb/v4l/.config file, search for FIREDTV and set
 those entries to =n instead of =m or =y and you should be in business.

 Regards,

 Villy

 I am a newbee so please be patient with me. I have followed all the
 instructions and I tried to compile the sources and got a lot of
 errors. I don't think it's my fault but i may be wrong.

 My system: Ubuntu 10.04 with kernel 2.6.32.22
 I have the headers installed, not the full kernel source code
 (shouldn't be required).

 My dvb-t interface is an usb stick: Conceptronic CTVDIGUSB2, I believe
 it has an afatech chipset. Here's the output from lsusb:
 Bus 002 Device 007: ID 1b80:d393 Afatech

 I downloaded the latest v4l-dvb source from
 hg clone http://linuxtv.org/hg/v4l-dvb

 I had a look at the daily test log and I don't see any test against 2.6.32.22

 Here's the output from make:

 t...@xxx:~/v4l-dvb$ sudo make
 make -C /home/teo/v4l-dvb/v4l
 make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
 No version yet, using 2.6.32-22-generic
 make[1]: Leaving directory `/home/teo/v4l-dvb/v4l'
 make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
 scripts/make_makefile.pl
 Updating/Creating .config
 Preparing to compile for kernel version 2.6.32

 ***WARNING:*** You do not have the full kernel sources installed.
 This does not prevent you from building the v4l-dvb tree if you have the
 kernel headers, but the full kernel source may be required in order to use
 make menuconfig / xconfig / qconfig.

 If you are experiencing problems building the v4l-dvb tree, please try
 building against a vanilla kernel before reporting a bug.

 Vanilla kernels are available at http://kernel.org.
 On most distros, this will compile a newly downloaded kernel:

 cp /boot/config-`uname -r` your kernel dir/.config
 cd your kernel dir
 make all modules_install install

 Please see your distro's web site for instructions to build a new kernel.

 V4L2_MEM2MEM_DEV: Requires at least kernel 2.6.33
 VIDEO_TVP7002: Requires at least kernel 2.6.34
 VIDEO_AK881X: Requires at least kernel 2.6.33
 SOC_CAMERA: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9M001: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9M111: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9T031: Requires at least kernel 2.6.33
 SOC_CAMERA_MT9V022: Requires at least kernel 2.6.33
 SOC_CAMERA_TW9910: Requires at least kernel 2.6.33
 SOC_CAMERA_PLATFORM: Requires at least kernel 2.6.33
 SOC_CAMERA_OV772X: Requires at least kernel 2.6.33
 RADIO_SAA7706H: Requires at least kernel 2.6.34
 Created default (all yes) .config file
 ./scripts/make_myconfig.pl
 make[1]: Leaving directory `/home/teo/v4l-dvb/v4l'
 make[1]: Entering directory `/home/teo/v4l-dvb/v4l'
 perl scripts/make_config_compat.pl
 /lib/modules/2.6.32-22-generic/build ./.myconfig ./config-compat.h
 creating symbolic links...
 ln -sf . oss
 make -C firmware prep
 make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware'
 make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware'
 make -C firmware
 make[2]: Entering directory `/home/teo/v4l-dvb/v4l/firmware'
  CC  ihex2fw
 Generating vicam/firmware.fw
 Generating dabusb/firmware.fw
 Generating dabusb/bitstream.bin
 Generating ttusb-budget/dspbootcode.bin
 Generating cpia2/stv0672_vp4.bin
 Generating av7110/bootcode.bin
 make[2]: Leaving directory `/home/teo/v4l-dvb/v4l/firmware'
 Kernel build directory is /lib/modules/2.6.32-22-generic/build
 make -C /lib/modules/2.6.32-22-generic/build
 SUBDIRS=/home/teo/v4l-dvb/v4l  modules
 make[2]: Entering directory `/usr/src/linux-headers-2.6.32-22-generic'
  CC [M]  /home/teo/v4l-dvb/v4l/tuner-xc2028.o
  CC [M]  /home/teo/v4l-dvb/v4l/tuner-simple.o
  CC [M]  /home/teo/v4l-dvb/v4l/tuner-types.o
  CC [M]  /home/teo/v4l-dvb/v4l/mt20xx.o
  CC [M]  /home/teo/v4l-dvb/v4l/tda8290.o
  CC [M]  /home/teo/v4l-dvb/v4l/tea5767.o
  CC [M]  /home/teo/v4l-dvb/v4l/tea5761.o
  CC [M]  /home/teo/v4l-dvb/v4l/tda9887.o
  CC [M]  /home/teo/v4l-dvb/v4l/tda827x.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-core.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-i2c.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-cards.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-dvb.o
  CC [M]  /home/teo/v4l-dvb/v4l/au0828-video.o
  CC [M]  

Re: [PATCH] Avoid unnecessary data copying inside dvb_dmx_swfilter_204() function

2010-06-27 Thread Marko Ristola 

Hi

dvb_dmx_swfilter(_204) performance improvement, with packet recovery.

Remove unnecessary copying of 188 and 204 sized packets within
dvb_dmx_swfilter() and dvb_dmx_swfilter_204() functions.
Recover one packet by backtracking, when there is a short packet
with a correct SYNC byte in the middle.



This patch tries to recover with backtracking one 188 / 204
sized packet if some garbage is found.

The backtracking recovery case, DVB data:
Packet Num, Packet data
10x47 +  99 bytes garbage
20x47 + 187 bytes data
30x47 + 187 bytes data

Recovery algorithm:
First packet 1's 0x47 is found. Process it, advance 188 bytes.
Find next SYNC byte, packet 3 found.
Check packet 3 position - 188: is there a packet?
yes, return packet 2.
Advance 188 bytes, return packet 3.

Jun 27 20:44:59 koivu kernel: demux: backtracked 137 bytes into position 442
Jun 27 20:44:59 koivu kernel: demux: backtracked 28 bytes into position 2250
Jun 27 20:45:02 koivu kernel: demux: backtracked 35 bytes into position 2634
Jun 27 20:45:02 koivu kernel: demux: backtracked 12 bytes into position 1398
Jun 27 20:45:03 koivu kernel: demux: skipped 146 bytes at position 378: 
09 93 ...
Jun 27 20:45:03 koivu kernel: demux: backtracked 177 bytes into position 551
Jun 27 20:45:03 koivu kernel: demux: skipped 14 bytes at position 959: 
6c 1e ...
Jun 27 20:45:03 koivu kernel: demux: backtracked 191 bytes into position 986

Regards,
Marko Ristola

diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
b/drivers/media/dvb/dvb-core/dvb_demux.c
index 977ddba..b71d77d 100644
--- a/drivers/media/dvb/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb/dvb-core/dvb_demux.c
@@ -478,97 +478,96 @@ void dvb_dmx_swfilter_packets(struct dvb_demux
*demux, const u8 *buf,
 
 EXPORT_SYMBOL(dvb_dmx_swfilter_packets);
 
-void dvb_dmx_swfilter(struct dvb_demux *demux, const u8 *buf, size_t count)
+static inline int findNextPacket(const u8 *buf, int pos, size_t count,
+   const int pktsize)
 {
-int p = 0, i, j;
+int start = pos, lost;
 
-spin_lock(demux-lock);
-
-if (demux-tsbufp) {
-i = demux-tsbufp;
-j = 188 - i;
-if (count  j) {
-memcpy(demux-tsbuf[i], buf, count);
-demux-tsbufp += count;
-goto bailout;
-}
-memcpy(demux-tsbuf[i], buf, j);
-if (demux-tsbuf[0] == 0x47)
-dvb_dmx_swfilter_packet(demux, demux-tsbuf);
-demux-tsbufp = 0;
-p += j;
+while(likely(pos  count)) {
+if (likely(buf[pos] == 0x47 ||
+(pktsize == 204  buf[pos] == 0xB8)))
+break;
+pos++;
 }
 
-while (p  count) {
-if (buf[p] == 0x47) {
-if (count - p = 188) {
-dvb_dmx_swfilter_packet(demux, buf[p]);
-p += 188;
-} else {
-i = count - p;
-memcpy(demux-tsbuf, buf[p], i);
-demux-tsbufp = i;
-goto bailout;
-}
-} else
-p++;
+if (unlikely(lost = pos - start)) {
+/* This garbage is part of a valid packet? */
+int backtrack = pos - pktsize;
+if (backtrack = 0  (buf[backtrack] == 0x47 ||
+(pktsize == 204  buf[backtrack] == 0xB8))) {
+/* printk(demux: backtracked %d bytes
+ * \n, start - backtrack); */
+return backtrack;
+}
+/*printk(demux: skipped %d bytes at %d\n, lost, start); */
 }
 
-bailout:
-spin_unlock(demux-lock);
+return pos;
 }
 
-EXPORT_SYMBOL(dvb_dmx_swfilter);
-
-void dvb_dmx_swfilter_204(struct dvb_demux *demux, const u8 *buf,
size_t count)
+/* Filter all pktsize= 188 or 204 sized packets and skip garbage. */
+static inline void _dvb_dmx_swfilter(struct dvb_demux *demux, const u8
*buf,
+size_t count, const int pktsize)
 {
 int p = 0, i, j;
-u8 tmppack[188];
+const u8 *q;
 
 spin_lock(demux-lock);
 
-if (demux-tsbufp) {
+if (likely(demux-tsbufp)) { /* tsbuf[0] is now 0x47. */
 i = demux-tsbufp;
-j = 204 - i;
-if (count  j) {
+j = pktsize - i;
+if (unlikely(count  j)) {
 memcpy(demux-tsbuf[i], buf, count);
 demux-tsbufp += count;
 goto bailout;
 }
 memcpy(demux-tsbuf[i], buf, j);
-if ((demux-tsbuf[0] == 0x47) || (demux-tsbuf[0] == 0xB8)) {
-memcpy(tmppack, demux-tsbuf, 188);
-if (tmppack[0] == 0xB8)
-tmppack[0] = 0x47;
-dvb_dmx_swfilter_packet(demux, tmppack);
-}
+if (likely(demux-tsbuf[0] == 0x47)) /* double check */
+dvb_dmx_swfilter_packet(demux, demux-tsbuf);
 demux-tsbufp = 0;
 p += j;
 }
 
-while (p  count) {
-if ((buf[p] == 0x47) || (buf[p] == 0xB8)) {
-if (count - p = 204) {
-

[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-06-27 Thread Hans Verkuil 
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sun Jun 27 19:00:26 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14993:9652f85e688a
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-armv5: OK
linux-2.6.34-armv5: WARNINGS
linux-2.6.35-rc1-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-armv5-davinci: WARNINGS
linux-2.6.35-rc1-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-armv5-ixp: WARNINGS
linux-2.6.35-rc1-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-armv5-omap2: WARNINGS
linux-2.6.35-rc1-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.17-i686: ERRORS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-i686: OK
linux-2.6.34-i686: WARNINGS
linux-2.6.35-rc1-i686: ERRORS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: WARNINGS
linux-2.6.35-rc1-m32r: ERRORS
linux-2.6.32.6-mips: OK
linux-2.6.33-mips: OK
linux-2.6.34-mips: WARNINGS
linux-2.6.35-rc1-mips: ERRORS
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-powerpc64: OK
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35-rc1-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.17-x86_64: ERRORS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-x86_64: OK
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35-rc1-x86_64: ERRORS
linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bulk] v4l-dvb bug report

2010-06-27 Thread CityK 
Holy cow -- Ubuntu is still borked in regards to the firedtv stuff ?! 
What is that - something like 4 releases in a row now?

Anyway, well known problem, have a look here:
http://www.mail-archive.com/search?q=firedtv+Ubuntul=linux-media%40vger.kernel.org

first link will give you the easy fix to your compilation/build problem.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Bulk] Re: v4l-dvb bug report

2010-06-27 Thread CityK 
matteo sisti sette wrote:
 Yeah, thank you, I have found the FIREDTV=n trick on some other forum
 just a few minutes before I read your reply, and with that change it
 has compiled fine :)
   
oops, I just sent my reply before I saw that you already figured it out

 I'm not sure what firedtv is but I don't think I need it :)
   

its a driver for some firewire based DVB devices ... you won't need it.

 By the way may I ask a newbie question? If you need the kernel sources
 to compile v4l-dvb, it does not mean that you're recompiling the
 kernel, does it? :$

that's correct ... all you are doing is building the v4l-dvb drivers
against your specific kernel ...  after building them, you can then
install them, which effectively replaces the kernel supplied set of
v4l-dvb drivers with the set you just compiled/built
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

v4l-dvb unsupported device: Conceptronic CTVDIGUSB2 1b80:d393 (Afatech) - possibly similar to CTVCTVDIGRCU v3.0?

2010-06-27 Thread matteo sisti sette 
Hi,

I hope this is the right place for reporting this; if not, please
forgive and redirect me.

My DVB-T USB stick, a Conceptronic USB 2.0 Digital TV Receiver
CTVDIGUSB2 doesn't work after succesfully compiling and installing
v4l-dvb, and it seems it is not supported according to the device
list.

The ID is 1b80:d393

The name Conceptronic USB 2.0 is very similar to that of CTVDIGRCU,
which _is_ supported and the chipset seems to be indeed an Afatech as
the output of lsusb reports:
Bus 002 Device 007: ID 1b80:d393 Afatech
(or isn't that reliable?)

So I wonder whether this is one of the cases where the following applies:
The driver has to be aware that it's related to some hardware
(typically through the subsystem ID from the USB ID or PCI ID). If the
driver doesn't recognize/bind to your particular hardware, then the
module will probably load but then proceed to not do anything. In
other words, support for your device would have to be added to the
driver.

If I understand correctly (pleas correct me if I am wrong), IF that is
the case (which may be not), then making it work should be just a
matter of adding the id of the device to the source code of the driver
somewhere and recompiling it and it would work??

If so, is it something I may try following some step-by-step guide?

Thanks
m.

-- 
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteosistisette.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] ir-core: partially convert bt8xx to not use ir-functions.c

2010-06-27 Thread Jarod Wilson 
On Sun, Jun 27, 2010 at 8:11 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 07-06-2010 16:32, David Härdeman escreveu:
 Partially convert drivers/media/video/bt8xx/bttv-input.c to
 not use ir-functions.c.

 Since the last user is gone with this patch, also remove a
 bunch of code from ir-functions.c.

 This patch breakd mceusb driver:

 drivers/media/IR/mceusb.c: In function ‘mceusb_init_input_dev’:
 drivers/media/IR/mceusb.c:774: error: invalid application of ‘sizeof’ to 
 incomplete type ‘struct ir_input_state’
 drivers/media/IR/mceusb.c:785: error: implicit declaration of function 
 ‘ir_input_init’
 make[1]: ** [drivers/media/IR/mceusb.o] Erro 1
 make[1]: ** Esperando que outros processos terminem.
 make: ** [drivers/media/IR/] Erro 2

The mceusb driver doesn't actually need ir_input_state at all, and one
of my pending patches removes it.

https://patchwork.kernel.org/patch/106549/


-- 
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TS discontinuity with TT S-2300

2010-06-27 Thread Marko Ristola 
27.06.2010 21:25, Oliver Endriss wrote:
 Are you sure that Mantis driver delivers garbage, not partial packets?
 Please note that the dvb_dmx_swfilter[_204]() routines must accept
 partial packets, i.e. the rest of the packet will be dellivered with the
 next call.
   
Yes, I'm sure that the garbage comes from the PCI device itself:
garbage should be found at less than 204 byte position otherwise.

My latest mailed patch that I use makes sure 0x47 is found at
demux-tsbufp[0],
if there is at least one spared byte. Otherwise the resulting 188 sized
packet would be discarded eventually.

It would be good if Mauro would accept my patch for dvb_dmx_swfilter(_204)
functions some day. It increases robustness with garbage input, and
performance by avoiding unnecessary packet copying.

 dvb_dmx_swfilter_packets() expects complete TS packets from the driver.
 The saa7146 does so. It does not deliver garbage data. (Otherwise this
 would have been noticed a long time ago. The ttpci drivers are the
 oldest DVB drivers and are very well tested.)
   
I'm very sorry I even questioned ttpci's and the hardware's robustness.

I'm delighted to hear that ttpci is so well implemented and tested and
so long :)
I was very impressed in the quality of the code with
dvb_dmx_swfilter_packets():
so simple and efficient.

Unfortunately I have had lots of problems with Mantis.
But because of that, I've learned DVB driver programming.

H.264 works now mostly in one TV channel without crashing Xine with
remote vdr.
I had to modify streamdev plugin too for vdr.

CU
Marko

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] ir-core: partially convert bt8xx to not use ir-functions.c

2010-06-27 Thread Andy Walls 
On Sun, 2010-06-27 at 16:17 -0400, Jarod Wilson wrote:
 On Sun, Jun 27, 2010 at 8:11 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Em 07-06-2010 16:32, David Härdeman escreveu:
  Partially convert drivers/media/video/bt8xx/bttv-input.c to
  not use ir-functions.c.
 
  Since the last user is gone with this patch, also remove a
  bunch of code from ir-functions.c.
 
  This patch breakd mceusb driver:
 
  drivers/media/IR/mceusb.c: In function ‘mceusb_init_input_dev’:
  drivers/media/IR/mceusb.c:774: error: invalid application of ‘sizeof’ to 
  incomplete type ‘struct ir_input_state’
  drivers/media/IR/mceusb.c:785: error: implicit declaration of function 
  ‘ir_input_init’
  make[1]: ** [drivers/media/IR/mceusb.o] Erro 1
  make[1]: ** Esperando que outros processos terminem.
  make: ** [drivers/media/IR/] Erro 2
 
 The mceusb driver doesn't actually need ir_input_state at all, 

I just came to that conclusion 5 minutes ago for the cx23885 driver as
well.  Right now it does use it, but once I get this conversion
complete, it won't need it either AFAICT.

I guess Mauro's build never got to the cx23885 driver.

Regards,
Andy


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

MCEUSB memory leak and how to tell if ir_register_input() failure registered input_dev?

2010-06-27 Thread Andy Walls 

Jarrod,

Looking at the patches branch from your WIP git tree:

Is mceusb_init_input_dev() supposed to allocate a struct ir_input_dev?
It looks like ir_register_input() handles that, and it is trashing your
pointer (memory leak).

Mauro and Jarrod,

When ir_register_input() fails, it doesn't indicate whether or not it
was able to register the input_dev or not.  To me it looks like it can
return with failure with the input_dev either way depending on the case.
This makes proper cleanup of the input_dev in my cx23885_input_init()
function difficult in the failure case, since the input subsystem has
two different deallocators depending on if the device had been
registered or not.

Regards,
Andy


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] ir-core: partially convert bt8xx to not use ir-functions.c

2010-06-27 Thread Mauro Carvalho Chehab 
Em 27-06-2010 12:14, Andy Walls escreveu:
 On Sun, 2010-06-27 at 09:11 -0300, Mauro Carvalho Chehab wrote:
 Em 07-06-2010 16:32, David Härdeman escreveu:
 Partially convert drivers/media/video/bt8xx/bttv-input.c to
 not use ir-functions.c.

 Since the last user is gone with this patch, also remove a
 bunch of code from ir-functions.c.

 This patch breakd mceusb driver:

 drivers/media/IR/mceusb.c: In function ‘mceusb_init_input_dev’:
 drivers/media/IR/mceusb.c:774: error: invalid application of ‘sizeof’ to 
 incomplete type ‘struct ir_input_state’ 
 drivers/media/IR/mceusb.c:785: error: implicit declaration of function 
 ‘ir_input_init’
 make[1]: ** [drivers/media/IR/mceusb.o] Erro 1
 make[1]: ** Esperando que outros processos terminem.
 make: ** [drivers/media/IR/] Erro 2

 Also, the description is wrong, since it changes not only bttv, but also 
 cx23885 and saa7134.
 
 Mauro,
 
 I'll be removing the RC5 and NEC decoding from the cx23885 driver
 hopefully by the end of the day.  That will make parts of David's patch
 obsolete.

Ok. David, it is generally a good idea to break those patches into smaller 
ones, since,
when conflicts like this happens, we can just discard a patch at the series, or 
move it
to happen after another patch.

 I'll be developing off of the v4l-dvb.git staging/rc branch.  Is that
 the right branch to use?

Yes. I'll likely apply a few more patches there.
 
 Also the IR registration Ooops is not patched in staging/rc, so the
 cx23885 driver Oops-es on load.  Is it OK if I pull in (fetch  merge)
 the patch from some other branch, or would it be easier for you if I
 just use an uncommitted patch in my working tree?

Probably, it is ok if you send it with the fix pulled in.

I'll handle the conflicts when sending upstream.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT FIXES for 2.6.35] cx23885: Convert to use new in kernel IR decoders

2010-06-27 Thread Andy Walls 
Mauro,

Please pull the following changes which update the cx23885 driver to use
the new in kernel IR deocders for IR Rx.  This gets the basic conversion
done.  I did not commit the patch to fix the ir_input_register() Oops, I
just kept a local copy in my tree for testing. 

(I still have more I want to do with this driver, but I'm out of time
this weekend:
- multiple remotes received from 1 unit (the HVR-1850 can ship with an RC-5 or 
an RC-6 6A remote)
- hardware setup based on protocol and the change protocol callback
- fixing Tx hardware setup
- Tx callbacks
  etc, etc.)

Regards,
Andy


The following changes since commit bf12d8720a7a5827b586d6102ffa9e087f193920:
  Jarod Wilson (1):
IR/mceusb: give device a moment after issuing reset cmd

are available in the git repository at:

  ssh://linuxtv.org/git/awalls/v4l-dvb.git wilson-ir

Andy Walls (2):
  cx23885: Convert from struct card_ir to struct cx23885_ir_input for IR Rx
  cx23885: Convert cx23885-input to use new in kernel IR pulse decoders

 drivers/media/video/cx23885/cx23885-input.c |  317 +--
 drivers/media/video/cx23885/cx23885-ir.c|2 +-
 drivers/media/video/cx23885/cx23885.h   |   12 +-
 3 files changed, 121 insertions(+), 210 deletions(-)


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: MCEUSB memory leak and how to tell if ir_register_input() failure registered input_dev?

2010-06-27 Thread Jarod Wilson 
On Sun, Jun 27, 2010 at 7:17 PM, Andy Walls awa...@md.metrocast.net wrote:

 Jarrod,

 Looking at the patches branch from your WIP git tree:

 Is mceusb_init_input_dev() supposed to allocate a struct ir_input_dev?
 It looks like ir_register_input() handles that, and it is trashing your
 pointer (memory leak).

Eep, crap, you're right. Fixed locally (I think), will test it out and
ship off the patch probably tomorrow (exhausting weekend of watching
futbol and some heavy-duty bbq'ing, need to turn in early... ;).

Just double-checked, I actually cribbed that incorrectness from
imon.c, so I'll need to fix it there too. D'oh.

 Mauro and Jarrod,

 When ir_register_input() fails, it doesn't indicate whether or not it
 was able to register the input_dev or not.  To me it looks like it can
 return with failure with the input_dev either way depending on the case.
 This makes proper cleanup of the input_dev in my cx23885_input_init()
 function difficult in the failure case, since the input subsystem has
 two different deallocators depending on if the device had been
 registered or not.

Hm. I've done a double-take a few times now, but if
input_register_device is successful, and something later in
__ir_input_register fails, input_unregister_device *does* get called
within __ir_input_register, so all you should have to do is call
input_free_device in your init function's error path, no?

-- 
Jarod Wilson
ja...@wilsonet.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html