[linux-dvb] digi vox mini II problems,

2007-03-01 Thread mowik 
Hello, i compiled the v4l-dvb driver with the patch posted at
http://www.mail-archive.com/linux-dvb@linuxtv.org/msg21957.html,

I have following dmesg.

dvb-usb: found a 'MSI DIGI VOX mini II DVB-T USB2.0' in warm state.
PM: Adding info for No Bus:i2c-3
dvb-usb: This USB2.0 device cannot be run on a USB1.1 port. (it lacks a
hardware PID filter)
PM: Removing info for No Bus:i2c-3
dvb-usb: MSI DIGI VOX mini II DVB-T USB2.0 error while loading driver (-19)
usbcore: registered new interface driver dvb_usb_m920x


any idea what is my problem.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects

2007-03-01 Thread Patrick Boettcher 
Hi Antti,

beside the XactErr which is not OK, there is maybe the chance to fix the 
disconnect issue:

Can you please try to increase the URB buffer size by 1KB?

in the define DIB0700_DEFAULT_STREAMING_CONFIG

you change .buffersize = 39480, to 40504.

thanks,
Patrick.

On Wed, 28 Feb 2007, Antti P Miettinen wrote:

 Antti P Miettinen [EMAIL PROTECTED] writes:
  But anyway - I'll be power cycling the machine real soon now :-)
 
 I'd say the dvb-usb-dib0700-02-rc2.fw makes the transaction errors
 more frequent for me me. Here's the latest kernel log:
 
 [17179744.028000] ehci_hcd :03:0c.2: XactErr, ep3in, token=8000cd08
 [17179788.896000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17179790.004000] ehci_hcd :03:0c.2: XactErr, ep2in, token=4d08
 [17179836.196000] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17179881.444000] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17179926.528000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17179927.636000] ehci_hcd :03:0c.2: XactErr, ep2in, token=cd08
 [17179972.716000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17179973.836000] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17180018.896000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180020.004000] ehci_hcd :03:0c.2: XactErr, ep2in, token=8000cd08
 [17180065.084000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180110.264000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180156.488000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180157.596000] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17180202.708000] ehci_hcd :03:0c.2: XactErr, ep0in, token=0d08
 [17180203.816000] ehci_hcd :03:0c.2: XactErr, ep2in, token=8000cd08
 [17180248.94] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180250.048000] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17180295.128000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180296.236000] ehci_hcd :03:0c.2: XactErr, ep2in, token=4d08
 [17180341.416000] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17180386.496000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180387.608000] ehci_hcd :03:0c.2: XactErr, ep2in, token=4d08
 [17180433.80] ehci_hcd :03:0c.2: XactErr, ep2in, token=80004d08
 [17180478.94] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180480.052000] ehci_hcd :03:0c.2: XactErr, ep2in, token=cd08
 [17180525.116000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8d08
 [17180526.228000] ehci_hcd :03:0c.2: XactErr, ep2in, token=4d08
 [17180571.42] ehci_hcd :03:0c.2: XactErr, ep2in, token=4d08
 [17180616.484000] ehci_hcd :03:0c.2: XactErr, ep0out, token=8e08
 [17180617.596000] ehci_hcd :03:0c.2: XactErr, ep2in, token=8000cd08
 [17180662.676000] ehci_hcd :03:0c.2: XactErr, ep3in, token=8038c948
 [17180662.676000] ehci_hcd :03:0c.2: XactErr, ep0out, token=80008148
 [17180662.676000] ehci_hcd :03:0c.2: devpath 1 ep0out 3strikes,t=80008148
 
 About usbmon logs. Does anyone know of tools for parsing them?
 Decoding by hand with the USB 2.0 spec is quite time consuming.
 
 Anyway - one way to find the disconnect is to look for transactions
 addressed to device one, endpoint zero, which is the control endpoint
 of the hub on the bus. For example:
 
 f7723ac0 30344798 S Ci:001:00 s a3 00  0001 0004 4 
 f7723ac0 30344798 C Ci:001:00 0 4 = 0105
 
 is a port status query. What seems to be in my logs before hub access
 is often a lot of (sometimes just a few) zero length callbacks with
 status -71 to submits with request length 39480 (which seems to be the
 dib0700 streaming buffer size) for endpoints 2 and 3. So is this -71 here
 -EPROTO? Is that normal? The pattern seems pretty consistent. Soon
 after starting to get -71 status callbacks, we will be talking to the
 hub (and logs that do not contain a disconnect do not contain -71
 status). Hmm.. looks like there is also always one callback with
 status -32 (-EPIPE?) before those -71 status callbacks. And the data
 length for those callbacks is 39424 which is 39480-56 and 56 is the
 transfer length in the token preceding the hard failure.. hmm..
 
 -- 
 http://www.iki.fi/~ananaza/
 
 
 ___
 linux-dvb mailing list
 linux-dvb@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
 


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] DVB-s card wont be detected

2007-03-01 Thread Matthias Fechner 
Hello Hartmut,

* e9hack [EMAIL PROTECTED] [28-02-07 22:30]:
 Sorry, this has nothing to do with the problem of the Cinergy 1200 DVB-C
 card. The patch will not help. You have to find out the manufacturer of
 the card. The sub vendor id 0xffc2 isn't known. The sub vendor id comes
 from the eeprom of the card. It may be a problem of the eeprom of this card.

hm, the card worked some time ago (I think 2-3 year qith the driver),
so really some messed up.

I checked the card and found the following on it:
Sat-DVB Rev.: 1.3
TTC99.04

On the receiver i found:
BSRV2-301A (two times)
932519A

I'm not sure if something on the card messed up or if the id is
removed from the driver.

Thx for help.

Best regards,
Matthias

-- 

Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning. --
Rich Cook

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Initial Support for Opera USB2.0 DVB-S Adapter

2007-03-01 Thread Patrick Boettcher 
On Sun, 25 Feb 2007, Marco wrote:

 Hi
 
 Attached is a patch for v4l-dvb , for the Opera DVB-S USB2.0 Adapter.
 It should work for the dvb stuff 100% and for RC-Stuff nearly 100%(slow 
 response to keys some times)
 3 firmware files are needed which can be found after a search with google (or 
 can i upload these files somwhere ?)
 
 
 Signed-of-by: Marci Gittler [EMAIL PROTECTED]
 Signed-of-by: Mario Hlawitschka [EMAIL PROTECTED]

Some comment about the driver:

In general you could cleanup the thing a little. There are some strange 
things which should be written differently to make it easier for others to 
read (and also to please kernel people). For buffers you should always u8 
not char.

[..]
+#include opera1.h
+
+static u32 last_key_pressed=-1;

You cannot do that, because if you plug two devices at the same time, they 
will both use the same global variable. Things like that have to go into 
a private struct allocated for each device. You can you the size_of_priv 
field in the dvb_usb_device_properties to let the dvb-usb-framework 
allocate it.

+static const char* xilinx_init=\x90\x6e\xc5\xfa\x32\xd0\x73\x23\x1e;
+static int opera1_xilinx_load_firmware(struct usb_device *dev, const char 
*filename);
+
+int dvb_usb_opera1_debug;

you can make this global static.

+module_param_named(debug,dvb_usb_opera1_debug, int, 0644);
+MODULE_PARM_DESC(debug, set debugging level 
(1=info,xfer=2,pll=4,ts=8,err=16,rc=32,fw=64 (or-able)). DVB_USB_DEBUG_STATUS);
+//struct mutex mymutex;
+
+int opera1_xilinx_rw(struct usb_device*dev, u8 request, u16 value, u8*data, 
u16 len,int flags){
+
+   int ret=0,t=0;
+   char r[10];
+   u8 u8buf[len];
+   unsigned int 
pipe=(flags==1)?usb_rcvctrlpipe(dev,0):usb_sndctrlpipe(dev,0);
+   u8 request_type=(flags==1)?USB_DIR_IN:USB_DIR_OUT;
+
+
+   //if (mutex_lock_interruptible(mymutex)){
+   //return -EAGAIN;
+   //}
+
+
+   if (flags==0)
+   memcpy(u8buf,data,len);
+   ret=usb_control_msg(dev, pipe,request, request_type| 
USB_TYPE_VENDOR,value, 0x0 /*index*/, u8buf,len, 2000);
+   //msleep(20);
+   if (request==OPERA_TUNER_REQ){
+   t=usb_control_msg(dev, usb_rcvctrlpipe(dev,0),
+   OPERA_TUNER_REQ, USB_DIR_IN|USB_TYPE_VENDOR, 0x01,0x0/*index*/, 
r, 10, 2000);
+   }
+   if (flags==1)
+   memcpy(data,u8buf,len);
+   //mutex_unlock(mymutex);
+   return ret;
+   
+}

You could use *data here to do the transfer. Use u8 for local buffers. 
Initialize buffers. Make all locally used functions static.

+int opera1_xilinx_read(struct usb_device*dev, u8 request, u16 value, u8*data, 
u16 len){
+return opera1_xilinx_rw(dev,request,value,data,len,1);
+}
+int opera1_xilinx_send(struct usb_device*dev, u8 request, u16 value, u8*data, 
u16 len){
+return opera1_xilinx_rw(dev,request,value,data,len,0);
+}
+
+/* I2C */
+
+static int opera1_usb_i2c_xfer(struct dvb_usb_device* dev,struct i2c_msg 
msg[],int num)
+{
+   int i;
+   u8 request;
+   u16 value;
+   //return 0;
+   if (dev==NULL){
+   info (no usb_device);
+   return -EINVAL;
+   }
+   if (mutex_lock_interruptible(dev-i2c_mutex)  0)
+   return -EAGAIN;
+   for (i = 0; i  num; i++) {
+   //READ
+   request=(msg[i].addr0xff00)  8;
+   if (!request)
+   request=0xb1;   
+   value=(msg[i].addr0xff);
+   if (msg[i].flags  I2C_M_RD){
+   value|=0x01;
+   }
+   if (request==0xa0)
+   value=0xe600;
+   if ((msg[i].flags  I2C_M_RD)) {
+   
opera1_xilinx_read(dev-udev,request,value,msg[i].buf,msg[i].len);
+   }else{//WRITE
+   
opera1_xilinx_send(dev-udev,request,value,msg[i].buf,msg[i].len);
+   }
+   }
+   mutex_unlock(dev-i2c_mutex);
+   return i;
+}

Do not abuse i2c_messages for doing USB-transfer. I2C is dedicated bus 
with a standardized interface (i2c_address, buffer). The I2C Adapter in 
the linux kernel should only be used to represent the real I2C-bus inside 
a device. 

+static int opera1_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int 
num)
+{
+   struct dvb_usb_device *d = i2c_get_adapdata(adap);
+   if (d)
+   return opera1_usb_i2c_xfer(d,msg,num);
+   return -EINVAL;
+}
+static u32 opera1_i2c_func(struct i2c_adapter *adapter)
+{
+   return I2C_FUNC_I2C;
+}
+
+static struct i2c_algorithm opera1_i2c_algo = {
+   .master_xfer   = opera1_i2c_xfer,
+   .functionality = opera1_i2c_func,
+};
+
+
+static int opera1_tuner_set_params(struct dvb_frontend *fe, struct 
dvb_frontend_parameters *params)
+{
+   int freq_add=0;
+   u8 tuner_buf[4];
+   struct dvb_usb_adapter* udev_adap=(struct 
dvb_usb_adapter*)(fe-dvb-priv);
+   
+   
+

Re: [linux-dvb] Re: [PATCH] Tuner calibration for some Nova-T devices

2007-03-01 Thread Jose Alberto Reguero 
El Miércoles, 20 de Diciembre de 2006, Patrick Boettcher escribió:
 Hi Olivier,

 On Fri, 15 Dec 2006, [EMAIL PROTECTED] wrote:
  Here is a patch for Hauppage Nova-T-Stick and Nova-T-500 users.
  It sets the MT2060 IF1 frequency according to the
  calibration values stored in the EEPROM.
 
  It is supposed to enhance the signal quality, but, hey,
  there is no guarantee.
  Feedbacks would be much appreciated, to know whether it
  deserves being applied.
 
  For those who have a MT2060 based device, very low signal
  levels and feel _very_ lucky,
  they can also activate MT2060_SPURCHECK in the mt2060_priv.h
  file. At worst case it will change nothing.
 
  Patrick, the (dib0700_state.mt2060_if1 field in dib0700.h
  becomes useless with this patch, is it right or shall I move
  the code to the frontend_attach functions ?)
 
  Signed-off-by: Olivier DANET [EMAIL PROTECTED]

 Thank you very much for taking a look at that.

 I inserted the mt2060_if1-field in the state, because I thought about
 adding a complete eeprom-parser...

 I'm wondering also if the eeprom-address for the if1-offset is always the
 same for each design. How did you find 0x48 and 0x49? Normally the
 addresses are dynamic, depending on the strings before (afaik).

 Furthermore the bristol-card has two mt2060-if1-offsets - one for each
 path.

 The best would be, but it will take some time, to write the eeprom-parser
 to always find the correct offset

 Would you have the time to do have a look at that?

 thanks again,
 Patrick.


In the NOVA-T 500 the if1 offsets are the two last valid values of the epprom. 
The rest are filled with 0xff, except byte 127. This patch work for me.

Jose Alberto



diff -r b238e85abb88 linux/drivers/media/dvb/dvb-usb/dib0700_devices.c
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c	Wed Feb 28 01:06:50 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c	Wed Feb 28 21:39:24 2007 +0100
@@ -88,12 +88,37 @@ static int bristol_frontend_attach(struc
 		(10 + adap-id)  1, bristol_dib3000mc_config[adap-id])) == NULL ? -ENODEV : 0;
 }
 
+static int eeprom_read(struct i2c_adapter *adap, u8 adrs, u8 *pval)
+{
+struct i2c_msg msg[2] = {
+{ .addr = 0x50, .flags = 0,.buf = adrs, .len = 1 },
+{ .addr = 0x50, .flags = I2C_M_RD, .buf = pval,  .len = 1 },
+};
+if (i2c_transfer(adap, msg, 2) != 2) return -EREMOTEIO;
+return 0;
+}
+
 static int bristol_tuner_attach(struct dvb_usb_adapter *adap)
 {
-	struct dib0700_state *st = adap-dev-priv;
+	struct i2c_adapter *prim_i2c = adap-dev-i2c_adap;
 	struct i2c_adapter *tun_i2c = dib3000mc_get_tuner_i2c_master(adap-fe, 1);
+	int if1=1220;
+	s8 a;
+	int i;
+	if (adap-dev-udev-descriptor.idVendor  == USB_VID_HAUPPAUGE 
+		adap-dev-udev-descriptor.idProduct == USB_PID_HAUPPAUGE_NOVA_T_500_2) {
+		i = 126;
+		do {
+			eeprom_read(prim_i2c, i, a);
+			i--;
+		} while ((u8)a == 0xff);
+		if (adap-id == 0)
+			eeprom_read(prim_i2c, i, a);
+		if1 = 1220 + a;
+ 
+	}
 	return dvb_attach(mt2060_attach,adap-fe, tun_i2c, bristol_mt2060_config[adap-id],
-		st-mt2060_if1[adap-id]) == NULL ? -ENODEV : 0;
+		if1) == NULL ? -ENODEV : 0;
 }
 
 /* STK7700P: Hauppauge Nova-T Stick, AVerMedia Volar */
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] digi vox mini II problems,

2007-03-01 Thread Michael Krufky 
[EMAIL PROTECTED] wrote:
 Hello, i compiled the v4l-dvb driver with the patch posted at
 http://www.mail-archive.com/linux-dvb@linuxtv.org/msg21957.html,
 
 any idea what is my problem.
 
 I have following dmesg.
 
 dvb-usb: found a 'MSI DIGI VOX mini II DVB-T USB2.0' in warm state.
 PM: Adding info for No Bus:i2c-3
 dvb-usb: This USB2.0 device cannot be run on a USB1.1 port. (it lacks a
 hardware PID filter)

^

I think the message is clear.

 PM: Removing info for No Bus:i2c-3
 dvb-usb: MSI DIGI VOX mini II DVB-T USB2.0 error while loading driver (-19)
 usbcore: registered new interface driver dvb_usb_m920x


Try it in a usb2.0 port.

-Mike

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] digi vox mini II problems,

2007-03-01 Thread Pierre Willenbrock 
[EMAIL PROTECTED] schrieb:
 Hello, i compiled the v4l-dvb driver with the patch posted at
 http://www.mail-archive.com/linux-dvb@linuxtv.org/msg21957.html,
 
 I have following dmesg.
 
 dvb-usb: found a 'MSI DIGI VOX mini II DVB-T USB2.0' in warm state.
 PM: Adding info for No Bus:i2c-3
 dvb-usb: This USB2.0 device cannot be run on a USB1.1 port. (it lacks a
 hardware PID filter)

Actually, the m9206 does have a pid filter - it was just disabled for
MSI DIGI VOX mini II. I just enabled it and checked that it works for
usb 1.1. Try the attached patch instead of my original one.

 PM: Removing info for No Bus:i2c-3
 dvb-usb: MSI DIGI VOX mini II DVB-T USB2.0 error while loading driver (-19)
 usbcore: registered new interface driver dvb_usb_m920x
 
 
 any idea what is my problem.

Regards,
  Pierre
diff -r 3556fab363b5 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h	Sat Feb 24 09:05:23 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h	Tue Feb 13 18:32:45 2007 +0100
@@ -37,6 +37,7 @@
 #define USB_VID_ULTIMA_ELECTRONIC		0x05d8
 #define USB_VID_UNIWILL0x1584
 #define USB_VID_WIDEVIEW			0x14aa
+#define USB_VID_ANUBIS_ELECTRONIC		0x10fd
 
 /* Product IDs */
 #define USB_PID_ADSTECH_USB2_COLD			0xa333
@@ -139,6 +140,7 @@
 #define USB_PID_GENPIX_8PSK_COLD			0x0200
 #define USB_PID_GENPIX_8PSK_WARM			0x0201
 #define USB_PID_SIGMATEK_DVB_110			0x6610
+#define USB_PID_ANUBIS_ELECTRONIC_MSI_DIGI_VOX_MINI_II  0x1513
 
 
 #endif
diff -r 3556fab363b5 linux/drivers/media/dvb/dvb-usb/m920x.c
--- a/linux/drivers/media/dvb/dvb-usb/m920x.c	Sat Feb 24 09:05:23 2007 -0200
+++ b/linux/drivers/media/dvb/dvb-usb/m920x.c	Thu Mar 01 14:50:25 2007 +0100
@@ -14,6 +14,8 @@
 #include mt352.h
 #include mt352_priv.h
 #include qt1010.h
+#include tda1004x.h
+#include tda827x.h
 
 /* debug */
 static int dvb_usb_m920x_debug;
@@ -44,14 +46,25 @@ static inline int m9206_read(struct usb_
 {
 	int ret;
 
+	deb_rc(m9206_read(..., %x, %x, %x, %p, %x)\n,
+	   request, value, index, data, size);
+
 	ret = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
 			  request, USB_TYPE_VENDOR | USB_DIR_IN,
 			  value, index, data, size, 2000);
-	if (ret  0)
-		return ret;
-
-	if (ret != size)
+	if (ret  0) {
+		printk(KERN_INFO m9206_read = error: %d\n, ret);
+		return ret;
+	}
+
+	if (ret != size) {
+		deb_rc(m9206_read = no data\n);
 		return -EIO;
+	}
+	
+
+	deb_rc(m9206_read = %x\n,
+	   ((unsigned char*)data)[0]);
 
 	return 0;
 }
@@ -60,10 +73,17 @@ static inline int m9206_write(struct usb
 			  u16 value, u16 index)
 {
 	int ret;
+
+	deb_rc(m9206_write(..., %x, %x, %x)=...\n,
+	   request, value, index);
 
 	ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 			  request, USB_TYPE_VENDOR | USB_DIR_OUT,
 			  value, index, NULL, 0, 2000);
+
+	deb_rc(m9206_write...=%d\n,
+	   ret);
+	
 	return ret;
 }
 
@@ -145,51 +165,72 @@ static int m9206_i2c_xfer(struct i2c_ada
 {
 	struct dvb_usb_device *d = i2c_get_adapdata(adap);
 	struct m9206_state *m = d-priv;
-	int i;
+	int i, j;
 	int ret = 0;
 
 	if (mutex_lock_interruptible(d-i2c_mutex)  0)
 		return -EAGAIN;
 
-	if (num  2)
-		return -EINVAL;
+/*
+sequences found in logs:
+[index value]
+0x80 write addr
+(0x00 out byte)*
+0x40 out byte
+
+0x80 write addr
+(0x00 out byte)*
+0x80 read addr
+(0x21 in byte)*
+0x60 in byte
+
+this sequence works:
+0x80 read addr
+(0x21 in byte)*
+0x60 in byte
+
+_my guess_:
+0x80: begin i2c transfer using address. value=address1|(reading?1:0)
+0x00: write byte
+0x21: read byte, more to follow
+0x40: write last byte of message sequence
+0x60: read last byte of message sequence
+ */
+
 
 	for (i = 0; i  num; i++) {
-		if ((ret = m9206_write(d-udev, M9206_I2C, msg[i].addr, 0x80)) != 0)
-			goto unlock;
-
-		if ((ret = m9206_write(d-udev, M9206_I2C, msg[i].buf[0], 0x0)) != 0)
-			goto unlock;
-
-		if (i + 1  num  msg[i + 1].flags  I2C_M_RD) {
-			int i2c_i;
-
-			for (i2c_i = 0; i2c_i  M9206_I2C_MAX; i2c_i++)
-if (msg[i].addr == m-i2c_r[i2c_i].addr)
-	break;
-
-			if (i2c_i = M9206_I2C_MAX) {
-deb_rc(No magic for i2c addr!\n);
-ret = -EINVAL;
+		if (msg[i].flags  I2C_M_RD) {
+
+			if ((ret = m9206_write(d-udev, M9206_I2C, msg[i].addr | 0x01, 0x80)) != 0)
 goto unlock;
+
+			for(j = 0; j  msg[i].len; j++) {
+if (j + 1 == msg[i].len  i + 1== num) {
+	if ((ret = m9206_read(d-udev, M9206_I2C, 0x0, 0x60, msg[i].buf[j], msg[i].len)) != 0)
+		goto unlock;
+} else {
+	if ((ret = m9206_read(d-udev, M9206_I2C, 0x0, 0x21, msg[i].buf[j], msg[i].len)) != 0)
+		goto unlock;
+}
 			}
 
-			if ((ret = m9206_write(d-udev, M9206_I2C, m-i2c_r[i2c_i].magic, 0x80)) != 0)
+		} else {
+			if ((ret = m9206_write(d-udev, M9206_I2C, msg[i].addr, 0x80)) != 0)
 goto unlock;
-
-			if ((ret = m9206_read(d-udev, M9206_I2C, 0x0, 0x60, msg[i + 1].buf, msg[i + 1].len)) != 0)
-goto unlock;
-
-			i++;
-		} else {
-			if (msg[i].len != 2)
-return

Re: R: [linux-dvb] How to handle multiple frontends?

2007-03-01 Thread Steven Toth 

Nico Sabbi wrote:

Ralph Metzler wrote:

  

In the HVR3000 case, do both frontends then use the same demux0?
So, if one can open only one at the same time, both should use 
demux0? 



please, NO!
it will be a hell to support in applications.
Please, do it simple and bind frontendN to demuxN and dvrN (and netN)

  

If one can open them at the same time, frontend 0
should use demux0 and the other demux1?
At least the latter is how I am doing it on dual-tuner cards with
independent inputs.




I'm trawling through old postings...

The hvr3000 patches create adapterN/fe{0,1} and demux{0,1}. It's my 
opinion that an adapter is a unit/path of delivery. Most/all of the 
current digital drivers register adapter{0,1,...} depending on their 
capabilities so the hvr3000 patches (with -EBUSY on the fe fops-open) 
appeared to be a good solution.


Steve



___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] patch 1 / 3: fix broken documentation for bt8xx cards

2007-03-01 Thread Uwe Bugla 
Hi folks,
although this patch is fine and necessary it has been blocked and ignored for 
months by the following so-called maintainers
who are a tall order and a shame for the whole linux community:
a. Manuel Abraham [EMAIL PROTECTED]
b. Mauro Carvalho Chehab [EMAIL PROTECTED]
I vote for excluding Manuel Abraham from maintainership, as we all need 
communicatable, reliable and accurate maintainers, no mismatches!
This patch fixes the documentation for dvb-bt8xx cards, synchronizing it to the 
actual state of kernel development.
Please sign-off or ack this only in connection with the DST deselection patch 
(i. e. patch 2 / 3)
Written and
Signed-off-by: Uwe Bugla [EMAIL PROTECTED]

--- a/Documentation/dvb/bt8xx.txt
+++ b/Documentation/dvb/bt8xx.txt
@@ -9,9 +9,33 @@
 Please see Documentation/dvb/cards.txt = o Cards based on the Conexant Bt8xx 
PCI bridge:
 
 Compiling kernel please enable:
-a.)Device drivers = Multimedia devices = Video For Linux = BT848 
Video For Linux
+a.)Device drivers = Multimedia devices = Video For Linux = Enable 
Video for Linux API 1 (DEPRECATED)
-b.)Device drivers = Multimedia devices = Digital Video Broadcasting 
Devices
- = DVB for Linux DVB Core Support Bt8xx based PCI Cards
+b.)Device drivers = Multimedia devices = Video For Linux = Video 
Capture Adapters = BT848 Video For Linux
+c.)Device drivers = Multimedia devices = Digital Video Broadcasting 
Devices = DVB for Linux DVB Core Support Bt8xx based PCI Cards
+
+Please use the following options with care as deselection of drivers which are 
in fact necessary
+may result in DVB devices that cannot be tuned due to lack of driver support:
+You can save RAM by deselecting every frontend or DST module that your DVB 
card does not need.
+
+First please remove the static dependency of DVB card drivers on all frontend 
modules for all possible card variants by enabling:
+d.) Device drivers = Multimedia devices = Digital Video Broadcasting 
Devices
+ = DVB for Linux DVB Core Support Load and attach frontend modules as 
needed
+
+If you know the frontend driver that your card needs please enable:
+e.)Device drivers = Multimedia devices = Digital Video Broadcasting 
Devices
+ = DVB for Linux DVB Core Support Customise DVB Frontends = Customise 
the frontend modules to build
+ Then please select your card-specific frontend module.
+
+Do you use one of the following cards?
+1. Twinhan DST (FTA and CI) family (DVB-S/C/T/ATSC)
+2. Pinnacle PCTV SAT CI
+3. Chaintech DST-1000
+4. DNTV Live !
+
+If not you can save additional RAM by enabling:
+f.)Device drivers = Multimedia devices = Digital Video Broadcasting 
Devices = DVB for Linux DVB Core Support
+ Bt8xx based PCI Cards = Customise DST support = Customise DST modules 
to build
+ Then please deselect DST module and DST CA module
 
 2) Loading Modules
 ==
@@ -68,7 +92,7 @@
$ modprobe dvb-bt8xx
 
 For a full list of card ID's please see 
Documentation/video4linux/CARDLIST.bttv.
-In case of further problems send questions to the mailing list: 
www.linuxdvb.org.
+In case of further problems please subscribe and send questions to the mailing 
list: [EMAIL PROTECTED]
 
 Authors: Richard Walker,
 Jamie Honan,

P. S.: There are two things that are infinite and endless: The human stupidity 
and the universe.
While I am sometimes doubting about the universe I am damn sure as far as the 
human stupidity is concerned.
ALBERT EINSTEIN

-- 
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] HVR-4000 DVB-S2 firmware

2007-03-01 Thread Steven Toth 


I can't post the actual firmware for the part. However,  if you need the 
firmware for the HVR-4000 under Linux...


ftp://167.206.143.11/outgoing/Oxford/88x_2_117_24275_1_INF.zip

Extract the zip and grab the firmware with dd:

dd if=hcw88bda.sys of=dvb-fe-cx24116.fw skip=81768 bs=1 count=32522

Regards,

Steve



___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] 2.6.21-rc1-git2 is incompilable

2007-03-01 Thread Uwe Bugla 
Hi folks,
trying to compile kernel 2.6.21-rc1-git2 is impossible. The broken module where 
the compiler gives up is /arch/i386/kernel/io_apic.c.

Regards

Uwe

P. S.: Wouldn't it be a good idea to test at least error-free compilation 
before stuff like this is being published?

-- 
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] patch 3 / 3: fix floppy mount bug in kernel 2.6.21-rc1

2007-03-01 Thread Uwe Bugla 
Hi folks,
this patch fixes the floppy mount bug (i. e. regression) in kernel 2.6.21-rc1. 
It was inspired by Stephane Eranian. It was tested on an Intel P4 1800 MHz
(Intel ICH4 chipset) and on an AMD Athlon XP 1800 MHz (Silicon Integrated 
Systems chipset 740, 5513).
My deep thanks and respect go to:
Stephane Eranian, Linus Torvalds, Jiri Slaby. You are truthfully real men and 
reliable, accurate, fine chaps. It feels great to have you in this world-wide 
community!
Would you still call the whole i386 architecture a small number of machines, 
Mister Andrew Morton? If yes, in how far please?

Signed-off-by: Uwe Bugla [EMAIL PROTECTED]

--- a/arch/i386/kernel/process.c
+++ b/arch/i386/kernel/process.c
@@ -154,6 +154,7 @@
current_thread_info()-status |= TS_POLLING;
} else {
/* loop is done by the caller */
+   local_irq_enable();
cpu_relax();
}
 }

-- 
Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Probs: Twinhan Starbox 2 on NSLU2 with kernel 2.6.20 and cvs driver

2007-03-01 Thread [EMAIL PROTECTED] 
Still nobody out there, who can
help mir here ?As soon as i start vdr the system
is kind of locked. The session stays until i remove the usb cable and
then i get the kernel oops. See attachmentSeems like this is a driver
problem.Would be great
if anybody can help me.Again on my debian ETCH system the
same installation is running fine.RegardsHubert---BeginMessage---
Is there nobody who can help me with the vp702x driver problem here?

I am trying to get a Twinhan Starbox 2 running on a NSLU2 with Debian
and VDR. I have compiled the v4l drivers from cvs and they are loaded
when i
plugin the usb cable of the Starbox2.

Feb 14 00:03:56 debianslug kernel: dvb-usb: found a 'TwinhanDTV StarBox
DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware
Feb 14 00:03:56 debianslug kernel: IXP4XX NPE driver Version 0.3.0
initialized
Feb 14 00:03:56 debianslug kernel: dvb-usb: downloading firmware from
file 'dvb-usb-vp702x-02.fw'
Feb 14 00:03:56 debianslug kernel: dvb-usb: found a 'TwinhanDTV StarBox
DVB-S USB2.0 (VP7021)' in warm state.
Feb 14 00:03:56 debianslug kernel: dvb-usb: will pass the complete MPEG2
transport stream to the software demuxer.
Feb 14 00:03:56 debianslug kernel: DVB: registering new adapter
(TwinhanDTV StarBox DVB-S USB2.0 (VP7021)).
Feb 14 00:03:56 debianslug kernel: vp702x: usb in operation failed.
(-71)
Feb 14 00:03:56 debianslug last message repeated 4 times
Feb 14 00:03:56 debianslug kernel: usb 3-2: USB disconnect, address 3
Feb 14 00:03:56 debianslug kernel: vp702x: usb in operation failed.
(-71)
Feb 14 00:03:56 debianslug kernel: dvb-usb: MAC address:
00:00:00:00:00:00
Feb 14 00:03:56 debianslug kernel: vp702x: usb out operation failed.
(-19)
Feb 14 00:03:56 debianslug kernel: vp702x: usb out operation failed.
(-19)
Feb 14 00:03:56 debianslug kernel: vp702x: usb in operation failed.
(-19)
Feb 14 00:03:56 debianslug kernel: dvb-usb: no frontend was attached by
'TwinhanDTV StarBox DVB-S USB2.0 (VP7021)'
Feb 14 00:03:56 debianslug kernel: input: IR-receiver inside an USB DVB
receiver as /class/input/input1
Feb 14 00:03:56 debianslug kernel: dvb-usb: schedule remote query
interval to 400 msecs.
Feb 14 00:03:56 debianslug kernel: dvb-usb: TwinhanDTV StarBox DVB-S
USB2.0 (VP7021) successfully initialized and connected.
Feb 14 00:03:56 debianslug kernel: dvb-usb: TwinhanDTV StarBox DVB-S
USB2.0 (VP7021) successfully deinitialized and disconnected.
Feb 14 00:03:56 debianslug kernel: usbcore: registered new interface
driver dvb_usb_vp702x
Feb 14 00:03:56 debianslug kernel: usb 3-2: new high speed USB device
using ehci_hcd and address 4
Feb 14 00:03:56 debianslug kernel: usb 3-2: configuration #1 chosen from
1 choice
Feb 14 00:03:56 debianslug kernel: dvb-usb: found a 'TwinhanDTV StarBox
DVB-S USB2.0 (VP7021)' in cold state, will try to load a firmware
Feb 14 00:03:56 debianslug kernel: dvb-usb: downloading firmware from
file 'dvb-usb-vp702x-02.fw'
Feb 14 00:03:56 debianslug kernel: dvb-usb: found a 'TwinhanDTV StarBox
DVB-S USB2.0 (VP7021)' in warm state.
Feb 14 00:03:56 debianslug kernel: dvb-usb: will pass the complete MPEG2
transport stream to the software demuxer.
Feb 14 00:03:56 debianslug kernel: DVB: registering new adapter
(TwinhanDTV StarBox DVB-S USB2.0 (VP7021)).
Feb 14 00:03:56 debianslug kernel: dvb-usb: MAC address:
00:08:ca:15:88:c7
Feb 14 00:03:56 debianslug kernel: vp702x: system string: USB702X
Feb 14 00:03:56 debianslug kernel: DVB: registering frontend 0 (Twinhan
DST-like frontend (VP7021/VP7020) DVB-S)...
Feb 14 00:03:56 debianslug kernel: input: IR-receiver inside an USB DVB
receiver as /class/input/input2
Feb 14 00:03:56 debianslug kernel: dvb-usb: schedule remote query
interval to 400 msecs.
Feb 14 00:03:56 debianslug kernel: dvb-usb: TwinhanDTV StarBox DVB-S
USB2.0 (VP7021) successfully initialized and connected.

After that when i start VDR the system frezes. Without loading the
drivers VDR is running ok.

Feb 14 00:04:12 debianslug vdr: [1976] VDR version 1.4.5-1 started
Feb 14 00:04:12 debianslug vdr: [1976] switched to user 'vdr'
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-yaepg.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-xineliboutput.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-svdrpext.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-vompserver.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-extrecmenu.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-streamdev-server.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-femon.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading plugin:
/usr/lib/vdr/plugins/libvdr-streamdev-client.so.1.4.5
Feb 14 00:04:12 debianslug vdr: [1976] loading /var/lib/vdr/setup.conf
Feb 14 00:04:12 debianslug vdr: [1976] [xine..put]

Re: [linux-dvb] 2.6.21-rc1-git2 is incompilable

2007-03-01 Thread Marcel Siegert 
On Thursday 01 March 2007, Uwe Bugla wrote:
 Hi folks,
 trying to compile kernel 2.6.21-rc1-git2 is impossible. The broken module 
 where the compiler gives up is /arch/i386/kernel/io_apic.c.
 
 Regards
 
 Uwe
 
 P. S.: Wouldn't it be a good idea to test at least error-free compilation 
 before stuff like this is being published?
 

hi uwe,

according to kernel.org 
2.6.21-rc2-git1 is an actual snapshot

but, those are iirc auto generated. thus not being able to compile can happen.
it also depends on your special .config

best regards
marcel

p.s. wouldn't it be a good idea to check your mail recipients instead of 
sending mails to e.g. linux-dvb that do 
  have no use with fixes of floppy drivers and or compile status in 
io_apic? :)

dont take it too hard man...

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] [GIT PULL] V4L/DVB fixes

2007-03-01 Thread Mauro Carvalho Chehab 
Linus,

We have some fixes for 2.6.21 on my -git tree.

There were also two newer drivers, one for zr364xx and another for ivtv.
Both drivers exists for some time out of kernel tree. 

The first one used to have, in the past, a mjpeg conversion routine at
kernel. His author removed this and cleaned up the driver according with
the best practices. It is contained just at the last patchset (V4L/DVB
5257) and just adds a newer driver, without touching on other files.

The second one is a very old driver (have about 2-3 years), long waited
to be on kernel, being maintained - until now - out of kernel tree. The
v4l development team, supported by the manufacturer, did a lot of
efforts to integrate it in kernel, generating several newer ABI
controls. 

This driver is for the very popular Hauppauge PVR hardware, supporting
maybe one of the most complex v4l/dvb device I've seen. There are
devices with IR decoding, IR encoding, MPEG decoding, MPEG encoding, TV
output, multiple tuners, as well as raw analog tv capture. Most of the
non-fix patches are adding some newer features at V4L2 and DVB API, to
allow controlling TVOut and mpeg encoding/decoding. Patchset V4L/DVB
5345 is a big one, just adding the driver itself.

I know we are late to submit this for 2.6.21, but I think this would be
interesting to be at kernel.

Just in case you don't agree with me, I've generated two different -git
trees. The first one with the two drivers. If you agree to pull it, it
is available at:
 ivtv branch (does contain the fixes also)
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git ivtv


otherwise, *if you nack* on pushing this too late, I've generated a tree
with just the required fixes for 2.6.21, available at:
 just the fixes branch
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git master


Both trees are compiling fine with allmodconfig.

Cheers,
Mauro.

===
ivtv branch does contain the following patches:
===

V4L/DVB (5255): Fix cx25840 firmware loading.
V4L/DVB (5304): Improve chip matching in v4l2_register
V4L/DVB (5295): Digitv: open nxt6000 i2c_gate for TDED4 tuner handling
V4L/DVB (5258): Cafe_ccic: fix compiler warning
V4L/DVB (5276): Cxusb: fix firmware patch for big endian systems
V4L/DVB (5268): Add support for three new MPEG controls.
V4L/DVB (5270): Add VIDIOC_G_ENC_INDEX ioctl
V4L/DVB (5271): Add VIDIOC_TRY_ENCODER_CMD and VIDIOC_ENCODER_CMD ioctls.
V4L/DVB (5272): Add V4L2_CAP_VIDEO_OUTPUT_POS capability
V4L/DVB (5305): Mark VIDIOC_DBG_S/G_REGISTER as experimental
V4L/DVB (5289): Add support for video output overlays.
V4L/DVB (5290): Add support for VIDIOC_INT_G/S_STD_OUTPUT
V4L/DVB (5307): Add support for the cx23415 MPEG decoding features.
V4L/DVB (5336): Cx23416 doc updates + rename CX2341X_ENC_UNKNOWN
V4L/DVB (5306): Add support for VIDIOC_G_CHIP_IDENT
V4L/DVB (5341): Add cx23415/6 chip idents.
V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoder
V4L/DVB (5257): USB: add zr364xx V4L2 driver

 .../video4linux/cx2341x/fw-encoder-api.txt |   19 
 Documentation/video4linux/zr364xx.txt  |   65 +
 MAINTAINERS|8 
 drivers/media/dvb/dvb-usb/cxusb.c  |4 
 drivers/media/dvb/dvb-usb/digitv.c |2 
 drivers/media/dvb/ttpci/av7110_av.c|   24 
 drivers/media/dvb/ttpci/av7110_hw.h|   10 
 drivers/media/video/Kconfig|   14 
 drivers/media/video/Makefile   |2 
 drivers/media/video/cafe_ccic.c|   12 
 drivers/media/video/cx2341x.c  |   72 +
 drivers/media/video/cx25840/cx25840-core.c |   15 
 drivers/media/video/cx25840/cx25840-core.h |3 
 drivers/media/video/cx25840/cx25840-firmware.c |2 
 drivers/media/video/cx88/cx88-video.c  |4 
 drivers/media/video/ivtv/Kconfig   |   26 
 drivers/media/video/ivtv/Makefile  |7 
 drivers/media/video/ivtv/ivtv-audio.c  |   74 +
 drivers/media/video/ivtv/ivtv-audio.h  |   23 
 drivers/media/video/ivtv/ivtv-cards.c  |  964 
 drivers/media/video/ivtv/ivtv-cards.h  |  207 +++
 drivers/media/video/ivtv/ivtv-controls.c   |  303 
 drivers/media/video/ivtv/ivtv-controls.h   |   21 
 drivers/media/video/ivtv/ivtv-driver.c | 1385 ++
 drivers/media/video/ivtv/ivtv-driver.h |  866 +++
 drivers/media/video/ivtv/ivtv-fileops.c|  918 
 drivers/media/video/ivtv/ivtv-fileops.h|   45 +
 drivers/media/video/ivtv/ivtv-firmware.c   |  272 +++
 drivers/media/video/ivtv/ivtv-firmware.h   |   25 
 drivers/media/video/ivtv/ivtv-gpio.c   |

[linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects

2007-03-01 Thread Antti P Miettinen 
Patrick Boettcher [EMAIL PROTECTED] writes:
 Can you please try to increase the URB buffer size by 1KB?

 in the define DIB0700_DEFAULT_STREAMING_CONFIG

 you change .buffersize = 39480, to 40504.

Did not prevent USB disconnect.

I'll be running with the original firmware for a while now to double
check the XactErr frequency. So far no transaction errors.

--
http://www.iki.fi/~ananaza/


___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Re: Nova-T 500 (dvb_usb_dib0700) usb disconnects

2007-03-01 Thread Jonas Larsson 
Patrick Boettcher wrote:
 Hi Antti,
 
 beside the XactErr which is not OK, there is maybe the chance to fix the 
 disconnect issue:
 
 Can you please try to increase the URB buffer size by 1KB?
 
 in the define DIB0700_DEFAULT_STREAMING_CONFIG
 
 you change .buffersize = 39480, to 40504.

I've been following this thread, hoping to see a solution to the
Nova-T disconnect issue being found. I did some tests with this
new buffersize.

I've changed the buffersize (2.6.20.1) as above and tried it with
the 3 available firmwares. In all cases did this make the problem
much worse! I used to have one disconnect each 24-30 hours, now it took
less than 1 hour. Event though this is bad it's a clue to what is
really going wrong. Did anyone analyse what sizes the windows driver
uses? Or does it also suffer from disconnects? Any other sizes that
may be interesting?

I can do more tests on my system if you need help. Just ask me...

/ Jonas





___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] budget_av eats resources

2007-03-01 Thread JJussi 
Hi!

So, nobody knows how to fix that budget_av's new (after patch) problem, where 
CPU load goes to 1 at every exist core (at Core 2 Duo load goes over 2).

Could somebody tell me how to debug that module to find out where is that 
tight loop what eats all resources?

-- 
JJussi

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] digi vox mini II problems,

2007-03-01 Thread Nick Andrew 
On Thu, Mar 01, 2007 at 02:59:09PM +0100, Pierre Willenbrock wrote:
 + if (dvb_attach(tda827x_attach, adap-fe, 0xc0, adap-dev-i2c_adap,
 +digivox_tda8275_config) == NULL)

You sure about the 0xc0 there ?

In a previous msg on this list to me, Trent Piepho [EMAIL PROTECTED] wrote:

 The I2C address passed to tda827x_attach is a 7-bit address.  Instead of
 scanning 2, 4, 6, ... 254, you should scan 1, 2, 3, ... 127.   You
 probably want to use i1.

And the error msg within tda827x_attach() says:

if (i2c_transfer(i2c, msg, 1) != 1) {
printk(%s: could not read from tuner at addr: 0x%02x\n,
   __FUNCTION__, addr  1);
return NULL;
}

(resulting in could not read from tuner at addr: 0x180)

Nick.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] digi vox mini II problems,

2007-03-01 Thread Pierre Willenbrock 
Nick Andrew schrieb:
 On Thu, Mar 01, 2007 at 02:59:09PM +0100, Pierre Willenbrock wrote:
 +if (dvb_attach(tda827x_attach, adap-fe, 0xc0, adap-dev-i2c_adap,
 +   digivox_tda8275_config) == NULL)
 
 You sure about the 0xc0 there ?

I am not sure, but that is the way the i2c-transfer function expects the
address. The 0xc0 gets passed right through to that function, where it
was matched against its internal list of i2c devices to get the correct
read-address from the magic field. Currently, its calculated by
'or'ing 1 onto the address.

 
 In a previous msg on this list to me, Trent Piepho [EMAIL PROTECTED] wrote:
 
 The I2C address passed to tda827x_attach is a 7-bit address.  Instead of
 scanning 2, 4, 6, ... 254, you should scan 1, 2, 3, ... 127.   You
 probably want to use i1.
 
 And the error msg within tda827x_attach() says:
 
 if (i2c_transfer(i2c, msg, 1) != 1) {
 printk(%s: could not read from tuner at addr: 0x%02x\n,
__FUNCTION__, addr  1);
 return NULL;
 }
 
 (resulting in could not read from tuner at addr: 0x180)

Seems like the i2c_transfer function is wrong, then, as are the places
in m920x.c setting the addresses. I need to dig out my i2c-specs, i guess.

Regards,
  Pierre

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [PATCH] Initial Support for Opera USB2.0 DVB-S Adapter

2007-03-01 Thread Marco Gittler 


Am Donnerstag, 1. März 2007 schrieb Patrick Boettcher:
 On Sun, 25 Feb 2007, Marco wrote:
  Hi
 
  Attached is a patch for v4l-dvb , for the Opera DVB-S USB2.0 Adapter.
  It should work for the dvb stuff 100% and for RC-Stuff nearly 100%(slow
  response to keys some times)
  3 firmware files are needed which can be found after a search with google
  (or can i upload these files somwhere ?)
 
 
  Signed-of-by: Marci Gittler [EMAIL PROTECTED]
  Signed-of-by: Mario Hlawitschka [EMAIL PROTECTED]

 Some comment about the driver:

 In general you could cleanup the thing a little. There are some strange
 things which should be written differently to make it easier for others to
 read (and also to please kernel people). For buffers you should always u8
 not char.

 [..]
 +#include opera1.h
 +
 +static u32 last_key_pressed=-1;

 You cannot do that, because if you plug two devices at the same time, they
 will both use the same global variable. Things like that have to go into
 a private struct allocated for each device. You can you the size_of_priv
 field in the dvb_usb_device_properties to let the dvb-usb-framework
 allocate it.
ok done

 +static const char* xilinx_init=\x90\x6e\xc5\xfa\x32\xd0\x73\x23\x1e;
 +static int opera1_xilinx_load_firmware(struct usb_device *dev, const char
 *filename); +
 +int dvb_usb_opera1_debug;

done 
 you can make this global static.

 +module_param_named(debug,dvb_usb_opera1_debug, int, 0644);
 +MODULE_PARM_DESC(debug, set debugging level
 (1=info,xfer=2,pll=4,ts=8,err=16,rc=32,fw=64 (or-able)).
 DVB_USB_DEBUG_STATUS); +//struct mutex mymutex;
 +
 +int opera1_xilinx_rw(struct usb_device*dev, u8 request, u16 value,
 u8*data, u16 len,int flags){ +
 +   int ret=0,t=0;
 +   char r[10];
 +   u8 u8buf[len];
 +   unsigned int
 pipe=(flags==1)?usb_rcvctrlpipe(dev,0):usb_sndctrlpipe(dev,0); +   u8
 request_type=(flags==1)?USB_DIR_IN:USB_DIR_OUT;
 +
 +
 +   //if (mutex_lock_interruptible(mymutex)){
 +   //return -EAGAIN;
 +   //}
 +
 +
 +   if (flags==0)
 +   memcpy(u8buf,data,len);
 +   ret=usb_control_msg(dev, pipe,request, request_type|
 USB_TYPE_VENDOR,value, 0x0 /*index*/, u8buf,len, 2000); +   //msleep(20);
 +   if (request==OPERA_TUNER_REQ){
 +   t=usb_control_msg(dev, usb_rcvctrlpipe(dev,0),
 +   OPERA_TUNER_REQ, USB_DIR_IN|USB_TYPE_VENDOR, 0x01,0x0/*index*/, r,
 10, 2000); +   }
 +   if (flags==1)
 +   memcpy(data,u8buf,len);
 +   //mutex_unlock(mymutex);
 +   return ret;
 +
 +}

 You could use *data here to do the transfer. Use u8 for local buffers.
 Initialize buffers. Make all locally used functions static.
this causes some usb-ehci controllers to die while sending, so i did copy 
that, but can be removed after successfull test 

 +int opera1_xilinx_read(struct usb_device*dev, u8 request, u16 value,
 u8*data, u16 len){ +return
 opera1_xilinx_rw(dev,request,value,data,len,1);
 +}
 +int opera1_xilinx_send(struct usb_device*dev, u8 request, u16 value,
 u8*data, u16 len){ +return
 opera1_xilinx_rw(dev,request,value,data,len,0);
 +}
 +
 +/* I2C */
 +
 +static int opera1_usb_i2c_xfer(struct dvb_usb_device* dev,struct i2c_msg
 msg[],int num) +{
 +   int i;
 +   u8 request;
 +   u16 value;
 +   //return 0;
 +   if (dev==NULL){
 +   info (no usb_device);
 +   return -EINVAL;
 +   }
 +   if (mutex_lock_interruptible(dev-i2c_mutex)  0)
 +   return -EAGAIN;
 +   for (i = 0; i  num; i++) {
 +   //READ
 +   request=(msg[i].addr0xff00)  8;
 +   if (!request)
 +   request=0xb1;
 +   value=(msg[i].addr0xff);
 +   if (msg[i].flags  I2C_M_RD){
 +   value|=0x01;
 +   }
 +   if (request==0xa0)
 +   value=0xe600;
 +   if ((msg[i].flags  I2C_M_RD)) {
 +  
 opera1_xilinx_read(dev-udev,request,value,msg[i].buf,msg[i].len); +  
 }else{//WRITE
 +  
 opera1_xilinx_send(dev-udev,request,value,msg[i].buf,msg[i].len); +  
 }
 +   }
 +   mutex_unlock(dev-i2c_mutex);
 +   return i;
 +}

 Do not abuse i2c_messages for doing USB-transfer. I2C is dedicated bus
 with a standardized interface (i2c_address, buffer). The I2C Adapter in
 the linux kernel should only be used to represent the real I2C-bus inside
 a device.
ok did it

 +static int opera1_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg
 msg[],int num) +{
 +   struct dvb_usb_device *d = i2c_get_adapdata(adap);
 +   if (d)
 +   return opera1_usb_i2c_xfer(d,msg,num);
 +   return -EINVAL;
 +}
 +static u32 opera1_i2c_func(struct i2c_adapter *adapter)
 +{
 +   return I2C_FUNC_I2C;
 +}
 +
 +static struct i2c_algorithm opera1_i2c_algo = {
 +   .master_xfer   = opera1_i2c_xfer,
 +   .functionality = opera1_i2c_func,
 +};
 +
 +
 +static int opera1_tuner_set_params(struct dvb_frontend *fe, struct
 dvb_frontend_parameters *params) +{
 +   int freq_add=0;
 +   u8 tuner_buf[4];
 +   struct dvb_usb_adapter* udev_adap=(struct
 dvb_usb_adapter*)(fe-dvb-priv); +
 +
 +   struct i2c_msg tuner_msg = {.addr=0xc0, .flags=0, .buf=tuner_buf,

[linux-dvb] [PATCH] Hauppauge Nova-T endianess problem on powerpc

2007-03-01 Thread Dennis Ranke 
Hi!

When trying to use a Hauppauge Nova-T Stick on a big-endian architecture
(such as powerpc) no frontend can be attached.

The attached patch fixes this problem by removing two lines in
dib0700_ctrl_rd() that try to correct the endianess on two values that
already are correct:
-   /* think about swapping here */
-   value = le16_to_cpu(value);
-   index = le16_to_cpu(index);

With this simple patch this dvb hardware works great, thanks to anyone
involved for the good work. :)

Signed-off-by: Dennis Ranke [EMAIL PROTECTED]
--- linux/drivers/media/dvb/dvb-usb/dib0700_core.c.orig	2007-03-02 01:14:36.0 +0100
+++ linux/drivers/media/dvb/dvb-usb/dib0700_core.c	2007-03-02 00:19:46.0 +0100
@@ -56,10 +56,6 @@ static int dib0700_ctrl_rd(struct dvb_us
 	if (txlen  3)
 		index |= tx[3];
 
-	/* think about swapping here */
-	value = le16_to_cpu(value);
-	index = le16_to_cpu(index);
-
 	status = usb_control_msg(d-udev, usb_rcvctrlpipe(d-udev,0), tx[0],
 			USB_TYPE_VENDOR | USB_DIR_IN, value, index, rx, rxlen,
 			USB_CTRL_GET_TIMEOUT);
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Tuning problem with WinFast DTV2000 H (cx88-dvb / cx22702)

2007-03-01 Thread Joel Michael 

Joel Michael wrote:
I'm having a strange problem with tuning and locking some channels on 
this card.  After a cold boot, it will always lock to any channel, but 
after a while (20 minutes or so) it will refuse to lock to two 
particular frequencies, while the other 3 are fine.  Immediately cold 
booting (ACPI power off, wait about 10 seconds, hit the power button) 
will result in being able to get a channel lock again.  I don't think a 
warm boot fixes the problem (I will test next time it refuses to lock).


Well, I think I've got this sorted out now.  It seems as though this 
particular card drops sensitivity when it warms up, and the signal I was 
feeding the card was right on the edge of an acceptable signal.  A fan 
pointed at the card mitigated the problem enough to keep a stable 
signal, and an amplifier has solved the problem entirely.


Now I've realised I need some more capture cards ;-)
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb