date:20091123

Re: IR Receiver on an Tevii S470

2009-11-23 Thread Jean Delvare

On Sun, 22 Nov 2009 19:17:59 -0500, Andy Walls wrote:
On Sun, 2009-11-22 at 21:32 +0100, Jean Delvare wrote:
The fact that 0x30-0x37 and 0x50-0x5f all reply suggest that the bus
driver erroneously returns success to SMBus receive byte transactions
even when no device acks. This is a bug which should get fixed. If you
point me to the I2C adapter driver code, I can take a look.

Although Igor's information makes the original need for this moot, here
is the i2c adapter driver code:

http://linuxtv.org/hg/v4l-dvb/file/8bff7e6c44d4/linux/drivers/media/video/cx23885/cx23885-i2c.c

The results are not surprising: i2c_slave_did_ack() is only called for
zero-length transactions. For all other transactions, no check is done.
This is incorrect.

I have written 3 patches for cx23885-i2c.c, the second one should fix
this particular issue. The other two are cleanups. Patches are there if
you want to take a look / give them a try:
http://khali.linux-fr.org/devel/misc/cx23885/

These are totally untested, and I don't know anything about the
hardware, so they might need some more work. But at least you should
get the idea of what's missing.

Note the CX2388[578] chips have 3 I2C masters, 2 for external buses, and
1 internal on silicon bus which the driver sets up as the 3rd bus.
The internal bus should at least have devices at 0x44 and 0x4c as
confirmed above. I'll note the comment in this file, that indicates the
on silicon I2C bus runs at 1.95 MHz:

http://linuxtv.org/hg/v4l-dvb/file/8bff7e6c44d4/linux/drivers/media/video/cx23885/cx23885-core.c

This is strange. For one thing, 1.95 MHz wouldn't be standard I2C but
high-speed mode I2C. But more importantly, I fail to see how you could
reach such speeds with a software-driven, byte-by-byte implementation.
You need hardware buffers to reach high speeds on I2C.

The TeVii S470 card had what looked like at serial I2C EEPROM with the
A0, A1, and A2 pins all grounded, so I assume it is at 0x50 on one of
the CX23885's external I2C buses.

Probably. Hopefully my patches will show you where it is.

--
Jean Delvare
--
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: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher


Hi Mario,

On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:


Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:


On Sat, 7 Nov 2009, Mario Bachmann wrote:


Hi there,

I tried linux-2.6.31.5 and tuning still does not work:
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  |
status 00 | signal  | snr  | ber 001f | unc  |
status 00 | signal  | snr  | ber 001f | unc  |
status 04 | signal  | snr  | ber 001f | unc  |

With some changes for the following file it works again:
/usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c

diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c

--- dibusb-common.c-ORIGINAL2009-11-07 10:30:43.705344308 +0100
+++ dibusb-common.c 2009-11-07 10:33:49.969345253 +0100
@@ -133,17 +133,14 @@

for (i = 0; i  num; i++) {
/* write/read request */
-   if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
-  (msg[i+1].flags  I2C_M_RD)) {
+   if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len)  0)
break;
i++;
-   } else if ((msg[i].flags  I2C_M_RD) == 0) {
+   } else
if (dibusb_i2c_msg(d, msg[i].addr, 
msg[i].buf,msg[i].len,NULL,0)  0)
break;
-   } else
-   break;
}


Doing it is reverting a fix which avoids that uncontrolled i2c-access from
userspace is destroying the USB-eeprom.

I understand that this is breaking the tuning for your board. I'm just not
understanding why.

If you have some time to debug this issue, could you please try the
following:

One of the devices for your board is trying to do an I2c access which is
falling into the last 'else'-branch - can you add a printk to find out
which one it is? The access must be wrongly constructed and must be fixed
in that driver.

thanks,

PS: if you don't have time to do it, please tell so.

--

Patrick
http://www.kernellabs.com/


I do not understand exactly. printk what? Could you please give me a
complete piece of code with the printk command? Would be great!

My printk-tries ends up in an Oops.


There is a
} else
break;

sequence in dibusb_i2c_xfer

instead of break, please add something like

printk(KERN_ERR - hello stupid I2C access \n);

recompile and load the new module, then check whether the line is 
appearing in /var/log/messages or /var/log/syslog when you tune the board.


If this is the case, try to identify which device is issuing the access by 
printing the i2c-address of struct i2c_msg.


HTH,
--

Patrick
http://www.kernellabs.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

flicker/jumpy at the bottom of the video

2009-11-23 Thread Purushottam R S

Hi ,

I am using latest gspca driver from dvb for camera driver. But I see bottom of 
the video has flickering/jumping effect.

I have Zippys web camera, which is from Z-Star.  I have loaded the following 
drivers.
1. gspca_zc3xx 44832 0 - Live 0xbf01f000
2. gspca_main 23840 1 gspca_zc3xx, Live 0xbf014000
3. videodev 36672 1 gspca_main, Live 0xbf006000
4. v4l1_compat 14788 1 videodev, Live 0xbf00

But otherwise there is no issue with video.

I tested using gst-launch pipeline.

regards
Purush



  The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. 
http://in.yahoo.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

[PATCH] dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame

2009-11-23 Thread Ang Way Chuang

ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.

This patch was generated and tested against v2.6.32-rc8. Similar patch
was applied and tested using 2.6.27 which is similar to the latest
dvb_net.c, except for network device statistical data structure. I
suspect that this bug was introduced in kernel version 2.6.15, but had
not verified it.

Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code for I always produces buggy code.

Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 0241a7c..7e0db86 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
   field: %u.\n, 
priv-ts_count, *from_where);

/* Drop partly decoded SNDU, 
reset state, resync on PUSI. */
-   if (priv-ule_skb) {
-   dev_kfree_skb( 
priv-ule_skb );
+   if (priv-ule_skb || 
priv-ule_sndu_remain) {
+   if (priv-ule_skb)
+   dev_kfree_skb( 
priv-ule_skb );
dev-stats.rx_errors++;

dev-stats.rx_frame_errors++;
}
@@ -533,6 +534,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
from_where += 2;
}

+   priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
 * State of current TS:
 *   ts_remain (remaining bytes in the current TS cell)
@@ -542,6 +544,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
 */
switch (ts_remain) {
case 1:
+   priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]  
8;
priv-ule_sndu_type_1 = 1; /* first 
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -555,6 +558,7 @@ static void dvb_net_ule( struct net_device *dev,
const u8 *buf, size_t buf_len )
default: /* complete ULE header is present in 
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+   priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |= 
from_where[0];
from_where += 1; /* points to 
payload start. */
ts_remain -= 1;
--
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: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Mario Bachmann

Am Mon, 23 Nov 2009 10:01:36 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:

 Hi Mario,
 
 On Sat, 21 Nov 2009, grafgrim...@gmx.de wrote:
 
  Am Thu, 19 Nov 2009 16:37:18 +0100 (CET)
  schrieb Patrick Boettcher pboettc...@kernellabs.com:
 
  On Sat, 7 Nov 2009, Mario Bachmann wrote:
 
  Hi there,
 
  I tried linux-2.6.31.5 and tuning still does not work:
  tuning to 73800 Hz
  video pid 0x0131, audio pid 0x0132
  status 00 | signal  | snr  | ber 001f | unc  |
  status 00 | signal  | snr  | ber 001f | unc  |
  status 00 | signal  | snr  | ber 001f | unc  |
  status 04 | signal  | snr  | ber 001f | unc  |
 
  With some changes for the following file it works again:
  /usr/src/linux/drivers/media/dvb/dvb-usb/dibusb-common.c
 
  diff -Naur dibusb-common.c-ORIGINAL dibusb-common.c
 
  --- dibusb-common.c-ORIGINAL  2009-11-07 10:30:43.705344308 +0100
  +++ dibusb-common.c   2009-11-07 10:33:49.969345253 +0100
  @@ -133,17 +133,14 @@
 
for (i = 0; i  num; i++) {
/* write/read request */
  - if (i+1  num  (msg[i].flags  I2C_M_RD) == 0
  -(msg[i+1].flags  I2C_M_RD)) {
  + if (i+1  num  (msg[i+1].flags  I2C_M_RD)) {
if (dibusb_i2c_msg(d, msg[i].addr, 
  msg[i].buf,msg[i].len,
msg[i+1].buf,msg[i+1].len)  0)
break;
i++;
  - } else if ((msg[i].flags  I2C_M_RD) == 0) {
  + } else
if (dibusb_i2c_msg(d, msg[i].addr, 
  msg[i].buf,msg[i].len,NULL,0)  0)
break;
  - } else
  - break;
}
 
  Doing it is reverting a fix which avoids that uncontrolled i2c-access from
  userspace is destroying the USB-eeprom.
 
  I understand that this is breaking the tuning for your board. I'm just not
  understanding why.
 
  If you have some time to debug this issue, could you please try the
  following:
 
  One of the devices for your board is trying to do an I2c access which is
  falling into the last 'else'-branch - can you add a printk to find out
  which one it is? The access must be wrongly constructed and must be fixed
  in that driver.
 
  thanks,
 
  PS: if you don't have time to do it, please tell so.
 
  --
 
  Patrick
  http://www.kernellabs.com/
 
  I do not understand exactly. printk what? Could you please give me a
  complete piece of code with the printk command? Would be great!
 
  My printk-tries ends up in an Oops.
 
 There is a
   } else
   break;
 
 sequence in dibusb_i2c_xfer
 
 instead of break, please add something like
 
 printk(KERN_ERR - hello stupid I2C access \n);
 
 recompile and load the new module, then check whether the line is 
 appearing in /var/log/messages or /var/log/syslog when you tune the board.
 
 If this is the case, try to identify which device is issuing the access by 
 printing the i2c-address of struct i2c_msg.
 
 HTH,
 --
 
 Patrick
 http://www.kernellabs.com/

Hello Patrick, 

I tried it with Kernel 2.6.31.6 (same as before). 

I made the printk-change, recompiled and reloaded the modules and pluged in my 
Twinhan Magic Box...
It definately jumps in the last else-branch and shows hello stupid I2C 
access, but no KERN_ERR ?!

dmesg
usb 4-2: new full speed USB device using ohci_hcd and address 4
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in cold state, will try to load a firmware
usb 4-2: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw
dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw'
usbcore: registered new interface driver dvb_usb_dibusb_mb
usb 4-2: USB disconnect, address 4
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 4-2: new full speed USB device using ohci_hcd and address 5
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 16).
DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA 
USB1.1 DVB-T device)
DVB: registering adapter 0 frontend 0 (DiBcom 3000M-B DVB-T)...
dibusb: This device has the Thomson Cable onboard. Which is default.
- hello stupid I2C access 
input: IR-receiver inside an USB DVB receiver as 
/devices/pci:00/:00:04.0/usb4/4-2/input/input5
dvb-usb: schedule remote query interval to 150 msecs.
dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device 
successfully initialized and connected.

tail -30 /var/log/messages
Nov 23 11:49:46 x2 kernel: usb 4-2: new full speed USB device using ohci_hcd 
and address 4
Nov 23 11:49:46 x2 kernel: usb 4-2: configuration #1 chosen from 1 choice
Nov 23 11:49:46 x2 kernel: dvb-usb:

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher


On Mon, 23 Nov 2009, Mario Bachmann wrote:

sequence in dibusb_i2c_xfer

instead of break, please add something like

printk(KERN_ERR - hello stupid I2C access \n);

recompile and load the new module, then check whether the line is
appearing in /var/log/messages or /var/log/syslog when you tune the board.

If this is the case, try to identify which device is issuing the access by
printing the i2c-address of struct i2c_msg.

HTH,
--

Patrick
http://www.kernellabs.com/


Hello Patrick,

I tried it with Kernel 2.6.31.6 (same as before).

I made the printk-change, recompiled and reloaded the modules and pluged in my 
Twinhan Magic Box...
It definately jumps in the last else-branch and shows hello stupid I2C 
access, but no KERN_ERR ?!


KERN_ERR is a prefix for printk to define the message priority to high. 
(to have it in syslog or messages)



dibusb: This device has the Thomson Cable onboard. Which is default.
- hello stupid I2C access 


Hmm... where is this coming from:

can you write it like that:

else {
printk(...);
dump_stack();
}


Hey, without the break-command, tuning seems to work:
$ tzap pro7 -r
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
reading channels from file '/home/grafrotz/.tzap/channels.conf'
tuning to 73800 Hz
video pid 0x0131, audio pid 0x0132
status 00 | signal  | snr  | ber 001f | unc  |
status 1f | signal 0b20 | snr 008d | ber 001f | unc  | FE_HAS_LOCK
status 1f | signal f4dd | snr 0077 | ber 0770 | unc  | FE_HAS_LOCK
status 1f | signal  | snr 008c | ber 0770 | unc  | FE_HAS_LOCK


We are close to identify the drivers in charge for the stupid I2c access.

--

Patrick Boettcher - Kernel Labs
http://www.kernellabs.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: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread grafgrimm77

Am Mon, 23 Nov 2009 12:11:40 +0100 (CET)
schrieb Patrick Boettcher pboettc...@kernellabs.com:

 On Mon, 23 Nov 2009, Mario Bachmann wrote:
  sequence in dibusb_i2c_xfer
 
  instead of break, please add something like
 
  printk(KERN_ERR - hello stupid I2C access \n);
 
  recompile and load the new module, then check whether the line is
  appearing in /var/log/messages or /var/log/syslog when you tune the board.
 
  If this is the case, try to identify which device is issuing the access by
  printing the i2c-address of struct i2c_msg.
 
  HTH,
  --
 
  Patrick
  http://www.kernellabs.com/
 
  Hello Patrick,
 
  I tried it with Kernel 2.6.31.6 (same as before).
 
  I made the printk-change, recompiled and reloaded the modules and pluged in 
  my Twinhan Magic Box...
  It definately jumps in the last else-branch and shows hello stupid I2C 
  access, but no KERN_ERR ?!
 
 KERN_ERR is a prefix for printk to define the message priority to high. 
 (to have it in syslog or messages)
 
  dibusb: This device has the Thomson Cable onboard. Which is default.
  - hello stupid I2C access 
 
 Hmm... where is this coming from:
 
 can you write it like that:
 
 else {
   printk(...);
   dump_stack();
 }
 
  Hey, without the break-command, tuning seems to work:
  $ tzap pro7 -r
  using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
  reading channels from file '/home/grafrotz/.tzap/channels.conf'
  tuning to 73800 Hz
  video pid 0x0131, audio pid 0x0132
  status 00 | signal  | snr  | ber 001f | unc  |
  status 1f | signal 0b20 | snr 008d | ber 001f | unc  | 
  FE_HAS_LOCK
  status 1f | signal f4dd | snr 0077 | ber 0770 | unc  | 
  FE_HAS_LOCK
  status 1f | signal  | snr 008c | ber 0770 | unc  | 
  FE_HAS_LOCK
 
 We are close to identify the drivers in charge for the stupid I2c access.
 
 --
 
 Patrick Boettcher - Kernel Labs
 http://www.kernellabs.com/

I use this code now:
} else
printk(KERN_ERR - hello stupid I2C access \n);
dump_stack();
}

dmesg
dvb-usb: TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T device 
successfully deinitialized and disconnected.
usbcore: deregistering interface driver dvb_usb_dibusb_mb
usb 4-2: new full speed USB device using ohci_hcd and address 6
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in cold state, will try to load a firmware
usb 4-2: firmware: requesting dvb-usb-dibusb-5.0.0.11.fw
dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw'
usbcore: registered new interface driver dvb_usb_dibusb_mb
usb 4-2: USB disconnect, address 6
dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
usb 4-2: new full speed USB device using ohci_hcd and address 7
usb 4-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA USB1.1 DVB-T 
device' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 16).
DVB: registering new adapter (TwinhanDTV USB-Ter USB1.1 / Magic Box I / HAMA 
USB1.1 DVB-T device)
Pid: 255, comm: khubd Tainted: P   A   2.6.31.6 #1
Call Trace:
 [a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
 [81341dc1] ? i2c_transfer+0x91/0xe0
 [a0059c23] ? dib3000_read_reg+0x63/0x80 [dib3000mb]
 [a005ad52] ? dib3000mb_attach+0x52/0xd4 [dib3000mb]
 [a0073268] ? dibusb_dib3000mb_frontend_attach+0x28/0x50 
[dvb_usb_dibusb_mb]
 [a0034ef3] ? dvb_usb_adapter_frontend_init+0x13/0x100 [dvb_usb]
 [a0034837] ? dvb_usb_device_init+0x357/0x630 [dvb_usb]
 [81314021] ? usb_match_one_id+0x31/0xb0
 [a0073050] ? dibusb_probe+0x20/0xa0 [dvb_usb_dibusb_mb]
 [81314962] ? usb_probe_interface+0xa2/0x170
 [812b0e40] ? __device_attach+0x0/0x60
 [812b0ca0] ? driver_probe_device+0x80/0x180
 [812b0e69] ? __device_attach+0x29/0x60
 [812b0e40] ? __device_attach+0x0/0x60
 [812b013c] ? bus_for_each_drv+0x5c/0x90
 [812b0f55] ? device_attach+0x85/0x90
 [812aff45] ? bus_probe_device+0x25/0x40
 [812ae879] ? device_add+0x4d9/0x5a0
 [81313af0] ? usb_set_configuration+0x4a0/0x670
 [812b0e40] ? __device_attach+0x0/0x60
 [8131c1cf] ? generic_probe+0x2f/0xb0
 [812b0ca0] ? driver_probe_device+0x80/0x180
 [812b0e69] ? __device_attach+0x29/0x60
 [812b0e40] ? __device_attach+0x0/0x60
 [812b013c] ? bus_for_each_drv+0x5c/0x90
 [812b0f55] ? device_attach+0x85/0x90
 [812aff45] ? bus_probe_device+0x25/0x40
 [812ae879] ? device_add+0x4d9/0x5a0
 [8130ceda] ? usb_new_device+0x5a/0xd0
 [8130e220] ? hub_thread+0x7e0/0x1040
 [810564c6] ? dequeue_task_fair+0x46/0x190
 [81074e70] ?

Re: V4L-DVB modules not loading

2009-11-23 Thread Philip Downer


Stacey wrote:

I've built the module okay. It installed correctly and copied the files
into /lib/modules/2.6.31-14-generic/kernel/drivers/media/dvb/dvb-usb.
After that I rebooted (since it was easier for me). Then I got to the
If the Modules load correctly section to find that nothing has worked
at all.

I've checked my system log and it's recognising the USB device when I
enter it but it isn't doing anything with it. The tutorial says you
should be able to see the modules in /proc/modules but the modules
folder doesn't even exist. The /dev/dvb/ folder has not been created
either.


Could you post the output of dmesg (just run the command 'dmesg' from a 
terminal) to the list, that should give us an idea of what is going on. 
You might want to do this after a clean reboot (with the adapter plugged 
in) so that there isn't too much information to wade through.


Phil
--
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: cx18: Reprise of YUV frame alignment improvements

2009-11-23 Thread Andy Walls

On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote:
 On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls awa...@radix.net wrote:
  OK, here's my second attempt at getting rid of cx18 YUV frame alignment
  and tearing issues.
 
 http://linuxtv.org/hg/~awalls/cx18-yuv2
 
 Hi Andy,
 
 I did some testing of your tree, using the following command
 
 mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:ntsc
 
 and then in parallel run a series of make commands of the v4l-dvb tree
 
 make -j2  make unload  make -j2  make unload  make -j2  make
 unload  make -j2  make unload
 
 I was definitely seeing the corruption by doing this test before your
 patches (both frame alignment and colorspace problems as PCI frames
 were being dropped).  After your change, I no longer see those
 problems.  The picture never became misaligned.

Great.  Thanks for the test.


  However, it would
 appear that some sort of regression may have been introduced with the
 buffer handling.
 
 I was seeing a continuous reporting of the following in dmesg, even
 *after* I stopped generating the load by running the make commands.
 
 [ 5175.703811] cx18-0: Could not find MDL 106 for stream encoder YUV
 [ 5175.737380] cx18-0: Could not find MDL 111 for stream encoder YUV
 [ 5175.804317] cx18-0: Skipped encoder YUV, MDL 96, 3 times - it must
 have dropped out of rotation
 [ 5175.804324] cx18-0: Skipped encoder YUV, MDL 101, 3 times - it must
 have dropped out of rotation
 [ 5175.904500] cx18-0: Skipped encoder YUV, MDL 96, 2 times - it must
 have dropped out of rotation
 [ 5176.204507] cx18-0: Skipped encoder YUV, MDL 101, 1 times - it must
 have dropped out of rotation
 [ 5176.204513] cx18-0: Skipped encoder YUV, MDL 96, 1 times - it must
 have dropped out of rotation
 [ 5176.204518] cx18-0: Could not find MDL 111 for stream encoder YUV

Congratulations, you're seeing my buffer notification consistency check
and sweep-up code in action.

In the early days of cx18 maintenance by me, the driver would stop
capturing a stream after anywhere from an hour to an hour and a half -
black screen in MythTV.  The original (current?) problem had a few
components:

1. There is only *one* CPU2EPU mailbox and all DMA_DONE notifications
come through it.

2. The CX23418 firmware does not wait long, at all, for you to pick up
and acknowledge the CPU2EPU mailbox.  It is a shorter window when you
have multiple streams running.

3. If you cleanly miss an MDL notification, you don't know which MDL you
missed and you don't know how many bytes were used in it.  You drop it.

4. If you get a half written mailbox, like in your MDL 111 message
above, then you have a mailbox consistency problem which is logged, but
you also drop the MDL.

5. If you don't give an MDL back to the firmware, it never uses it
again.  That's why you see the sweep-up log messages.  As soon as an MDL
is skipped *on the order of the depth* of q_busy times, when looking for
the currently DMA_DONE'd MDL, that skipped MDL must have been dropped.
It is picked up and put back into rotation then.


I will note that skipping an MDL 1 time and sweeping it up indicates the
CX23418 firmware (q_busy) doesn't have a lot of MDLs to work with for
that stream.  You need to devote more memory to that stream or have the
application read them off faster (so the MDL goes from q_full to q_free
to q_busy).



 I would expect to see frame drops while the system was under high
 load, but I would expect that the errors would stop once the load fell
 back to something reasonable.  However, they continue to accumulate
 even after the make commands stop and the only thing running on the
 system is mplayer (with a CPU load of around 10%).

You likely have:

1. a system-level interrupt handler latency problem

and/or

2. the cx18-NN-out/M workrer threads aren't being woken up often enough
to give MDL's back to the CX23418 firmware fast enough.


For #1, if there is a linux driver sharing the CX23418 interrupt line
(as shown by cat /proc/interrupts) then try unloading that driver,
moving the CX23418 to another PCI slot, or somehow else keeping some
other linux device driver from masking the CX23418's IRQ line for too
long.  The ahci disk controller driver is a known culprit with a time
consuming error path in the top half of its IRQ handler.

The easy solution to #2 is give enough memory for a few more MDLs for
that stream with module parameters.


 I think this tree is definitely on the right track, but it looks like
 some edge case has been missed.

What you see is normal.  I can take a look at things, but it's generally
a system level issue.  One thing that can be done in the cx18 driver is
to optimize the paths called by the out_work_handler, so that MDLs get
back to the firmware with a minimum of delay. 

It's never been a big deal, with lots of MDLs for a stream, to have one
or two MDLs tied up.  With YUV only having very few MDLs, having an MDL
tied up, not being given back to the firmware

Re: dibusb-common.c FE_HAS_LOCK problem

2009-11-23 Thread Patrick Boettcher


On Mon, 23 Nov 2009, grafgrim...@gmx.de wrote:

[..]
- hello stupid I2C access 
Pid: 255, comm: khubd Tainted: P   A   2.6.31.6 #1
Call Trace:
[a0042292] ? dibusb_i2c_xfer+0xe2/0x130 [dvb_usb_dibusb_common]
[81341dc1] ? i2c_transfer+0x91/0xe0
[a0059081] ? dib3000_write_reg+0x51/0x70 [dib3000mb]
[a00855c9] ? dvb_pll_attach+0xa9/0x238 [dvb_pll]
[..]


Voila.

This is the access with makes the dvb-pll-driver not create the tuner 
driver.


This is (I forgot the correct name) read-without-write-i2caccess. It is 
bad handled by the dibusb-driver and it can destroy the eeprom on the USB 
side.


Please try whether the attached patch fixes the whole situation for you.

If so, please send back a line like this:

Tested-by: Your name email

thanks,
--

Patrick
http://www.kernellabs.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: cx18: Reprise of YUV frame alignment improvements

2009-11-23 Thread Andy Walls

On Mon, 2009-11-23 at 07:12 -0500, Andy Walls wrote:
 On Sun, 2009-11-22 at 22:04 -0500, Devin Heitmueller wrote:
  On Tue, Nov 10, 2009 at 11:31 PM, Andy Walls awa...@radix.net wrote:
   OK, here's my second attempt at getting rid of cx18 YUV frame alignment
   and tearing issues.
  
  http://linuxtv.org/hg/~awalls/cx18-yuv2
  
  Hi Andy,
  
  I did some testing of your tree, using the following command
  
  mplayer /dev/video32 -demuxer rawvideo -rawvideo 
  w=720:h=480:format=hm12:ntsc
  
  and then in parallel run a series of make commands of the v4l-dvb tree
  
  make -j2  make unload  make -j2  make unload  make -j2  make
  unload  make -j2  make unload
  
  I was definitely seeing the corruption by doing this test before your
  patches (both frame alignment and colorspace problems as PCI frames
  were being dropped).  After your change, I no longer see those
  problems.  The picture never became misaligned.
 
 Great.  Thanks for the test.
 
 
   However, it would
  appear that some sort of regression may have been introduced with the
  buffer handling.
  
  I was seeing a continuous reporting of the following in dmesg, even
  *after* I stopped generating the load by running the make commands.
  
  [ 5175.703811] cx18-0: Could not find MDL 106 for stream encoder YUV
  [ 5175.737380] cx18-0: Could not find MDL 111 for stream encoder YUV
  [ 5175.804317] cx18-0: Skipped encoder YUV, MDL 96, 3 times - it must
  have dropped out of rotation
  [ 5175.804324] cx18-0: Skipped encoder YUV, MDL 101, 3 times - it must
  have dropped out of rotation
  [ 5175.904500] cx18-0: Skipped encoder YUV, MDL 96, 2 times - it must
  have dropped out of rotation
  [ 5176.204507] cx18-0: Skipped encoder YUV, MDL 101, 1 times - it must
  have dropped out of rotation
  [ 5176.204513] cx18-0: Skipped encoder YUV, MDL 96, 1 times - it must
  have dropped out of rotation
  [ 5176.204518] cx18-0: Could not find MDL 111 for stream encoder YUV
 
 Congratulations, you're seeing my buffer notification consistency check
 and sweep-up code in action.
 
 In the early days of cx18 maintenance by me, the driver would stop
 capturing a stream after anywhere from an hour to an hour and a half -
 black screen in MythTV.  The original (current?) problem had a few
 components:
 
 1. There is only *one* CPU2EPU mailbox and all DMA_DONE notifications
 come through it.
 
 2. The CX23418 firmware does not wait long, at all, for you to pick up
 and acknowledge the CPU2EPU mailbox.  It is a shorter window when you
 have multiple streams running.
 
 3. If you cleanly miss an MDL notification, you don't know which MDL you
 missed and you don't know how many bytes were used in it.  You drop it.
 
 4. If you get a half written mailbox, like in your MDL 111 message
 above, then you have a mailbox consistency problem which is logged, but
 you also drop the MDL.
 
 5. If you don't give an MDL back to the firmware, it never uses it
 again.  That's why you see the sweep-up log messages.  As soon as an MDL
 is skipped *on the order of the depth* of q_busy times, when looking for
 the currently DMA_DONE'd MDL, that skipped MDL must have been dropped.
 It is picked up and put back into rotation then.
 
 
 I will note that skipping an MDL 1 time and sweeping it up indicates the
 CX23418 firmware (q_busy) doesn't have a lot of MDLs to work with for
 that stream.  You need to devote more memory to that stream or have the
 application read them off faster (so the MDL goes from q_full to q_free
 to q_busy).
 
 
 
  I would expect to see frame drops while the system was under high
  load, but I would expect that the errors would stop once the load fell
  back to something reasonable.  However, they continue to accumulate
  even after the make commands stop and the only thing running on the
  system is mplayer (with a CPU load of around 10%).
 
 You likely have:
 
 1. a system-level interrupt handler latency problem
 
 and/or
 
 2. the cx18-NN-out/M workrer threads aren't being woken up often enough
 to give MDL's back to the CX23418 firmware fast enough.

One other possibility:

3. Once mplayer got behind, it stayed behind to render frames on a
smooth timeline.  That means more MDLs are intentionally being held on
q_full by the application.


 For #1, if there is a linux driver sharing the CX23418 interrupt line
 (as shown by cat /proc/interrupts) then try unloading that driver,
 moving the CX23418 to another PCI slot, or somehow else keeping some
 other linux device driver from masking the CX23418's IRQ line for too
 long.  The ahci disk controller driver is a known culprit with a time
 consuming error path in the top half of its IRQ handler.
 
 The easy solution to #2 is give enough memory for a few more MDLs for
 that stream with module parameters.


For number 3, for the YUV stream, we can make the assumption we can
steal the 2nd MDL from the front of q_full and give it back to q_busy in
low depth of q_busy situations.  That will result in a forceably

[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2009-11-23 Thread Jean-Francois Moine

Hi Mauro,

Maybe my previous mail was lost..

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following 8 changesets:

01/08: gspca - pac7302: Remove redundant stream off command.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=1551c621e75f

02/08: gspca - pac7311/pac7302: Propagate error to higher level
software.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=225a5744acf3

03/08: gspca - sonixj: Optimize code and add some comments.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=f174339c63cf

04/08: gspca - pac7302: Add red and blue balance control.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=4ddc02bee41d

05/08: gspca - main: Change version to 2.8.0.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=63484417ba70

06/08: gspca - main: Fix a compilation warning.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=da92c97c33c4

07/08: gspca - pac7302: Add white balance control.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=aa28984b1f48

08/08: gspca - pac7302: Handle return values in sd_start().
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=3fd924da7091


 gspca.c   |6 -
 pac7302.c |  346
 +++---
 pac7311.c |  161 ++-- sonixj.c  |  163
 ++--- 4 files changed, 480 insertions(+), 196
 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

86 matches

Mail list logo