Drivers for Pinnacle pctv200e and pctv60e

PATCH In review Gabriele Dini Ciacci 4 participants 10 messages Mar 29, 2009 – Apr 1, 2009 Media (V4L/DVB)

lore

Share & tools

lore

Gabriele Dini Ciacci

author

2009-03-29 14:02 UTC #0 lore raw

PATCH 1/1 Drivers for Pinnacle pctv200e and pctv60e

Hello,

This is a stub patch to make the subjects card work.

I am using the driver on a pctv60e and it is very stable, I use it daily. It should work for pctv200e but not owning the device I cannot test it.

The code need to be cleaned, as I am not an experienced kernel coder. The code in mt352.c contains an hard-coded address for the device, while Pinnalce devices with that tuner uses a different address. Currently the address is "hijacked" to be the correct one. This is a hack, and i think that mt352.c should be changed to support multiple addresses, selected via params, duplicate code or something.

Remote support is missing, cause it was not working out of the box. I do not use it and so developing it for myself only was not very useful, if someone wants it or is interested I can have a look.

The patch is generally messy, I need help there. I do not know if I have to change all the functions to take as parameter an adapter_nr or change the caller to continue to pass them a struct dvb_usb_device obtained with i2c_get_adapdata(adapter_nr).

Here is the patch, as an attachment, thanks meanwhile.

Best Regards,
Gabriele Dini Ciacci

Signed-off-by Gabriele Dini Ciacci <[email protected]>

-----------
http://linux-wildo.sf.net
http://www.diniciacci.org

linux/drivers/media/dvb/dvb-usb/Kconfig +6 -0

diff -uprN v4l-dvd/linux/drivers/media/dvb/dvb-usb/Kconfig my_v4l-dvb/linux/drivers/media/dvb/dvb-usb/Kconfig
@@ -299,3 +299,9 @@ config DVB_USB_AF9015
 	select MEDIA_TUNER_MXL5005S if !MEDIA_TUNER_CUSTOMIZE
 	help
 	  Say Y here to support the Afatech AF9015 based DVB-T USB2.0 receiver
+
+config DVB_USB_PCTV200E
+	tristate "Pinnacle PCTV200e and PCTV60e support"
+	depends on DVB_USB && EXPERIMENTAL
+	help
+	  Say Y here to support for PCTV200e or PCTV60e

linux/drivers/media/dvb/dvb-usb/Makefile +2 -0

diff -uprN v4l-dvd/linux/drivers/media/dvb/dvb-usb/Makefile my_v4l-dvb/linux/drivers/media/dvb/dvb-usb/Makefile
@@ -54,6 +54,8 @@ obj-$(CONFIG_DVB_USB_DIB0700) += dvb-usb
 dvb-usb-opera-objs = opera1.o
 obj-$(CONFIG_DVB_USB_OPERA1) += dvb-usb-opera.o
 
+dvb-usb-pctv200e-objs = pctv200e.o
+obj-$(CONFIG_DVB_USB_PCTV200E) += dvb-usb-pctv200e.o
 
 dvb-usb-af9005-objs = af9005.o af9005-fe.o
 obj-$(CONFIG_DVB_USB_AF9005) += dvb-usb-af9005.o

linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h +1 -0

diff -uprN v4l-dvd/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h my_v4l-dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -174,6 +174,7 @@
 #define USB_PID_PINNACLE_PCTV73E			0x0237
 #define USB_PID_PINNACLE_PCTV801E			0x023a
 #define USB_PID_PINNACLE_PCTV801E_SE			0x023b
+#define USB_PID_PCTV_60E				0x0216
 #define USB_PID_PCTV_200E				0x020e
 #define USB_PID_PCTV_400E				0x020f
 #define USB_PID_PCTV_450E				0x0222

linux/drivers/media/dvb/dvb-usb/pctv200e.c +644 -0

644 lines not on this page · raw message

linux/drivers/media/dvb/dvb-usb/pctv200e.h +35 -0

diff -uprN v4l-dvd/linux/drivers/media/dvb/dvb-usb/pctv200e.h my_v4l-dvb/linux/drivers/media/dvb/dvb-usb/pctv200e.h
@@ -0,0 +1,35 @@
+#ifndef _DVB_USB_PCTV200E_H_
+#define _DVB_USB_PCTV200E_H_
+
+#define DVB_USB_LOG_PREFIX "pctv200e"
+#include "dvb-usb.h"
+
+extern int dvb_usb_pctv200e_debug;
+#define deb_rc(args...)   dprintk(dvb_usb_pctv200e_debug,0x01,args)
+
+/*
+#define USB_READ_EEPROM         1
+
+#define USB_READ_COFDM          2
+#define USB_WRITE_COFDM         5
+
+#define USB_WRITE_TUNER         6
+
+#define USB_READ_REMOTE         3
+#define USB_WRITE_REMOTE        7
+#define USB_WRITE_REMOTE_TYPE   8
+
+#define USB_DEV_INIT            9
+*/
+
+
+#define USB_READ	1
+#define USB_WRITE	2
+
+#define TUNER_ADDR 0xc0
+#define DEMUX_ADDR 0x3e
+
+
+
+
+#endif

Mauro Carvalho Chehab

2009-03-31 10:56 UTC #1 lore raw

Hi Gabriele,

Quoted 19 lines · On Sun, 29 Mar 2009 15:56:08 +0200 Gabriele Dini Ciacci…

Hello,
This is a stub patch to make the subjects card work.
I am using the driver on a pctv60e and it is very stable, I use it daily. It should work for pctv200e but not owning the device I cannot test it.
The code need to be cleaned, as I am not an experienced kernel coder. The code in mt352.c contains an hard-coded address for the device, while Pinnalce devices with that tuner uses a different address. Currently the address is "hijacked" to be the correct one. This is a hack, and i think that mt352.c should be changed to support multiple addresses, selected via params, duplicate code or something.
Remote support is missing, cause it was not working out of the box. I do not use it and so developing it for myself only was not very useful, if someone wants it or is interested I can have a look.

Quoted 6 lines

The patch is generally messy, I need help there. I do not know if I have to change all the functions to take as parameter an adapter_nr or change the caller to continue to pass them a struct dvb_usb_device obtained with i2c_get_adapdata(adapter_nr).
Here is the patch, as an attachment, thanks meanwhile.

Well, let's go by parts.

It seems that you wrote your driver based on some USB sniffing. Do you know what are the chipsets present on your driver? Maybe there's another driver already developed or under development for the same chipset.

In the case of your patch, you should first run checkpatch.pl for it to show you the non-compliances of your driver and Linux Kernel CodingStyle. checkpatch.pl is avaliable at kernel tree, under /scripts dir. You'll also find it at v4l-dvb development tree, at v4l/script/checkpatch.pl.

It is also a good idea to read README.patches at v4l-dvb development tree.

Cheers,
Mauro

Gabriele Dini Ciacci

author

2009-03-31 19:20 UTC #2 lore raw

Quoted 30 lines · On Tue, 31 Mar 2009 07:56:10 -0300 Mauro Carvalho Chehab…

Hi Gabriele,
Quoted 25 lines · On Sun, 29 Mar 2009 15:56:08 +0200 Gabriele Dini Ciacci…
Hello,
This is a stub patch to make the subjects card work.
I am using the driver on a pctv60e and it is very stable, I use it daily. It should work for pctv200e but not owning the device I cannot test it.
The code need to be cleaned, as I am not an experienced kernel coder. The code in mt352.c contains an hard-coded address for the device, while Pinnalce devices with that tuner uses a different address. Currently the address is "hijacked" to be the correct one. This is a hack, and i think that mt352.c should be changed to support multiple addresses, selected via params, duplicate code or something.
Remote support is missing, cause it was not working out of the box. I do not use it and so developing it for myself only was not very useful, if someone wants it or is interested I can have a look.
The patch is generally messy, I need help there. I do not know if I have to change all the functions to take as parameter an adapter_nr or change the caller to continue to pass them a struct dvb_usb_device obtained with i2c_get_adapdata(adapter_nr).

Quoted 8 lines

Quoted 1 line
Here is the patch, as an attachment, thanks meanwhile.
Well, let's go by parts.
It seems that you wrote your driver based on some USB sniffing. Do you know what are the chipsets present on your driver? Maybe there's another driver already developed or under development for the same chipset.

I actually did not any sniffing at all. I was ready to go for it (so I asked a windows guy to send me the sniff).
Obtained that, I started to look at it, then I
realized that v4l already had support for all the chipsets the thing was using. I just made the code that connects the parts and such, indeed the patch is only the main file, no low level chip file, or anything else touched. So there is no actual code for the chipsets. I'm using mt353 and mt2060, that are already in the main tree.

As I explained above, mt353.c makes a wrong assumption about the address the chip has, at it also states that in a comment, explaining that on pinnacle hardware (like in this case) the address is different. I just had to hijack that and hack this. I was suggesting above to fix mt353.c else, no pinnacle card with mt353 can be implemented with a clean code.

Quoted 8 lines

In the case of your patch, you should first run checkpatch.pl for it to show you the non-compliances of your driver and Linux Kernel CodingStyle. checkpatch.pl is avaliable at kernel tree, under /scripts dir. You'll also find it at v4l-dvb development tree, at v4l/script/checkpatch.pl.
It is also a good idea to read README.patches at v4l-dvb development tree.

I have checked coding style manually, I'll use the script. I read README.patches the first time i coded the driver, reread it on January when I updated the driver to the new interface and decided to send it the first time to the ml on 01/06/2009. In January it was outdated in regards to the new patch system adopted, wiki was also outdated. I'll reread it to see if I am missing something and to check if it needs to be updated to explain the new system for patch.

To sum up I will run checkpatch.pl and when it run fine I will resend the patch.

But note that the problem with mt353.c stays, I do not have the necessary confidence to change a low level chipset driver interface to make it not assume an hardcoded adderss.

Quoted 2 lines

Cheers,
Mauro

Thanks, see you :)
Best Regards,
Gabriele

-----------
http://linux-wildo.sf.net
http://www.diniciacci.org

Devin Heitmueller

2009-03-31 20:59 UTC #3 lore raw

Quoted 82 lines · Gabriele Dini Ciacci

Quoted 30 lines · On Tue, 31 Mar 2009 07:56:10 -0300 Mauro Carvalho Chehab…
Hi Gabriele,
Quoted 25 lines · On Sun, 29 Mar 2009 15:56:08 +0200 Gabriele Dini Ciacci…
Hello,
This is a stub patch to make the subjects card work.
I am using the driver on a pctv60e and it is very stable, I use it daily. It should work for pctv200e but not owning the device I cannot test it.
The code need to be cleaned, as I am not an experienced kernel coder. The code in mt352.c contains an hard-coded address for the device, while Pinnalce devices with that tuner uses a different address. Currently the address is "hijacked" to be the correct one. This is a hack, and i think that mt352.c should be changed to support multiple addresses, selected via params, duplicate code or something.
Remote support is missing, cause it was not working out of the box. I do not use it and so developing it for myself only was not very useful, if someone wants it or is interested I can have a look.
The patch is generally messy, I need help there. I do not know if I have to change all the functions to take as parameter an adapter_nr or change the caller to continue to pass them a struct dvb_usb_device obtained with i2c_get_adapdata(adapter_nr).
Quoted 8 lines
Quoted 1 line
Here is the patch, as an attachment, thanks meanwhile.
Well, let's go by parts.
It seems that you wrote your driver based on some USB sniffing. Do you know what are the chipsets present on your driver? Maybe there's another driver already developed or under development for the same chipset.
I actually did not any sniffing at all. I was ready to go for it (so I asked a windows guy to send me the sniff).
Obtained that, I started to look at it, then I
realized that v4l already had support for all the chipsets the thing was using. I just made the code that connects the parts and such, indeed the patch is only the main file, no low level chip file, or anything else touched. So there is no actual code for the chipsets. I'm using mt353 and mt2060, that are already in the main tree.
As I explained above, mt353.c makes a wrong assumption about the address the chip has, at it also states that in a comment, explaining that on pinnacle hardware (like in this case) the address is different. I just had to hijack that and hack this. I was suggesting above to fix mt353.c else, no pinnacle card with mt353 can be implemented with a clean code.
Quoted 8 lines
In the case of your patch, you should first run checkpatch.pl for it to show you the non-compliances of your driver and Linux Kernel CodingStyle. checkpatch.pl is avaliable at kernel tree, under /scripts dir. You'll also find it at v4l-dvb development tree, at v4l/script/checkpatch.pl.
It is also a good idea to read README.patches at v4l-dvb development tree.
I have checked coding style manually, I'll use the script. I read README.patches the first time i coded the driver, reread it on January when I updated the driver to the new interface and decided to send it the first time to the ml on 01/06/2009. In January it was outdated in regards to the new patch system adopted, wiki was also outdated. I'll reread it to see if I am missing something and to check if it needs to be updated to explain the new system for patch.
To sum up I will run checkpatch.pl and when it run fine I will resend the patch.
But note that the problem with mt353.c stays, I do not have the necessary confidence to change a low level chipset driver interface to make it not assume an hardcoded adderss.

Quoted 6 lines

Quoted 2 lines
Cheers,
Mauro
Thanks, see you :)
Best Regards,
Gabriele

Is this device not based on a Cypress FX2? If so, then there shouldn't be a new driver at all. We would just need a device profile in the existing driver.

http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_60e

Devin

Signature · 3 lines

Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Gabriele Dini Ciacci

author

2009-03-31 21:35 UTC #4 lore raw

Quoted 93 lines · On Tue, 31 Mar 2009 16:59:35 -0400 Devin Heitmueller…

Quoted 84 lines · Gabriele Dini Ciacci
Quoted 31 lines · On Tue, 31 Mar 2009 07:56:10 -0300 Mauro Carvalho Chehab…
Hi Gabriele,
Quoted 26 lines · On Sun, 29 Mar 2009 15:56:08 +0200 Gabriele Dini Ciacci…
Hello,
This is a stub patch to make the subjects card work.
I am using the driver on a pctv60e and it is very stable, I use it daily. It should work for pctv200e but not owning the device I cannot test it.
The code need to be cleaned, as I am not an experienced kernel coder. The code in mt352.c contains an hard-coded address for the device, while Pinnalce devices with that tuner uses a different address. Currently the address is "hijacked" to be the correct one. This is a hack, and i think that mt352.c should be changed to support multiple addresses, selected via params, duplicate code or something.
Remote support is missing, cause it was not working out of the box. I do not use it and so developing it for myself only was not very useful, if someone wants it or is interested I can have a look.
The patch is generally messy, I need help there. I do not know if I have to change all the functions to take as parameter an adapter_nr or change the caller to continue to pass them a struct dvb_usb_device obtained with i2c_get_adapdata(adapter_nr).
Quoted 8 lines
Quoted 1 line
Here is the patch, as an attachment, thanks meanwhile.
Well, let's go by parts.
It seems that you wrote your driver based on some USB sniffing. Do you know what are the chipsets present on your driver? Maybe there's another driver already developed or under development for the same chipset.
I actually did not any sniffing at all. I was ready to go for it (so I asked a windows guy to send me the sniff).
Obtained that, I started to look at it, then I
realized that v4l already had support for all the chipsets the thing was using. I just made the code that connects the parts and such, indeed the patch is only the main file, no low level chip file, or anything else touched. So there is no actual code for the chipsets. I'm using mt353 and mt2060, that are already in the main tree.
As I explained above, mt353.c makes a wrong assumption about the address the chip has, at it also states that in a comment, explaining that on pinnacle hardware (like in this case) the address is different. I just had to hijack that and hack this. I was suggesting above to fix mt353.c else, no pinnacle card with mt353 can be implemented with a clean code.
Quoted 8 lines
In the case of your patch, you should first run checkpatch.pl for it to show you the non-compliances of your driver and Linux Kernel CodingStyle. checkpatch.pl is avaliable at kernel tree, under /scripts dir. You'll also find it at v4l-dvb development tree, at v4l/script/checkpatch.pl.
It is also a good idea to read README.patches at v4l-dvb development tree.
I have checked coding style manually, I'll use the script. I read README.patches the first time i coded the driver, reread it on January when I updated the driver to the new interface and decided to send it the first time to the ml on 01/06/2009. In January it was outdated in regards to the new patch system adopted, wiki was also outdated. I'll reread it to see if I am missing something and to check if it needs to be updated to explain the new system for patch.
To sum up I will run checkpatch.pl and when it run fine I will resend the patch.
But note that the problem with mt353.c stays, I do not have the necessary confidence to change a low level chipset driver interface to make it not assume an hardcoded adderss.
Quoted 6 lines
Quoted 2 lines
Cheers,
Mauro
Thanks, see you :)
Best Regards,
Gabriele

Quoted 8 lines

Is this device not based on a Cypress FX2? If so, then there shouldn't be a new driver at all. We would just need a device profile in the existing driver.
http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_60e
Devin

I it's so, say me how to make or where to look to create a profile for the existing driver.

I am willing to do the work.

(when I first wrote the driver to me it seemed that this was the simplet way.

Meanwhile I will try to look at the Cypress FX2

Thanks,
looking forward
Regards
Gabriele

Devin Heitmueller

2009-03-31 21:51 UTC #5 lore raw

Quoted 9 lines · Gabriele Dini Ciacci

I it's so, say me how to make or where to look to create a profile for the existing driver.
I am willing to do the work.
(when I first wrote the driver to me it seemed that this was the simplet way.
Meanwhile I will try to look at the Cypress FX2

As Michael Krufky pointed out to me off-list, I was not exactly correct here.

While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach.

Regards,

Devin

Signature · 3 lines

Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller

Gabriele Dini Ciacci

author

2009-03-31 22:47 UTC #6 lore raw

Quoted 24 lines · On Tue, 31 Mar 2009 17:51:23 -0400 Devin Heitmueller…

Quoted 9 lines · Gabriele Dini Ciacci
I it's so, say me how to make or where to look to create a profile for the existing driver.
I am willing to do the work.
(when I first wrote the driver to me it seemed that this was the simplet way.
Meanwhile I will try to look at the Cypress FX2
As Michael Krufky pointed out to me off-list, I was not exactly correct here.
While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach.

Quoted 4 lines

Regards,
Devin

Fine perfect, thanks,

I will have a look asap and report for judge.

Cheers.
Gabriele

-----------
http://linux-wildo.sf.net
http://www.diniciacci.org

Patrick Boettcher

2009-04-01 07:35 UTC #7 lore raw

Hi all,

Quoted 9 lines · Gabriele Dini Ciacci

Quoted 9 lines
While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach.

Quoted 8 lines

Quoted 4 lines
Regards,
Devin
Fine perfect, thanks,
I will have a look asap and report for judge.

I think you can save the time... When I started on a driver for those two devices 4 years ago, I had almost everything finished, but at that time we hadn't had a mt2060 driver available.

I think I still have that driver somewhere, I'll check that and will send it to the list if I can find it. (at least the I2C-part was a little bit cleaner, IIRC).

Gabriele, btw. there is nothing wrong with the I2C-address in your driver. setting 0x3e to the demod-address-field in the config-struct is totally fine.

OTOH, your problem of unterstanding is most likely the notation used for i2c-addresses in linux: In Linux's drivers you'll find the 7-bit notation of the chip's i2c-address where as outside Linux, IMO, usually the 8-bit (wrong) notation is used:

In the i2c-protocol the first byte of communication is the address plus a bit (the LSB) which is indicating wheter it is a read or write access.

ie: AAAA AAAD, where A is address-bits and D is direction.

In Linux what you'll see is e.g 0x1f which is the 7 bit address of 0x3e. The same for the tuner 0xc0 or 0xc2 is in Linux 0x60 and 0x61. Or the eeprom 0xa0 -> 0x50

On the various USB-2-I2C interfaces most of the time the 8 bit notation is used, that why you'll have to shift the address << 1 before filling the buffer in the i2c_transfer function.

HTH,
Patrick.

--
Mail: [email protected]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/

Patrick Boettcher

2009-04-01 15:27 UTC #8 lore raw

In reply to Gabriele Dini Ciacci

Hi,

Quoted 27 lines · Gabriele Dini Ciacci

Quoted 24 lines · On Tue, 31 Mar 2009 17:51:23 -0400 Devin Heitmueller…
Quoted 9 lines · Gabriele Dini Ciacci
I it's so, say me how to make or where to look to create a profile for the existing driver.
I am willing to do the work.
(when I first wrote the driver to me it seemed that this was the simplet way.
Meanwhile I will try to look at the Cypress FX2
As Michael Krufky pointed out to me off-list, I was not exactly correct here.
While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach.

Quoted 6 lines

Quoted 4 lines
Regards,
Devin
Fine perfect, thanks,

Attached you can find my attempts from 2005. I2C should work, please re-use this implementation as it nicely splits i2c_transfer from the rest of the required functionality.

I think I still have the pctv 200e somewhere in a box... I may get it back, undust it and try.

Patrick.

--
Mail: [email protected]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/

/* DVB USB compliant linux driver for the Pinnacle PCTV 200e DVB-T USB2.0 receiver.
*
* Copyright (C) 2005 Patrick Boettcher ([email protected])
*

 *  This program is free software; you can redistribute it and/or modify it
 *  under the terms of the GNU General Public License as published by the Free
 *  Software Foundation, version 2.

*
* see Documentation/dvb/README.dvb-usb for more information */

#ifndef _DVB_USB_PCTV_H_
#define _DVB_USB_PCTV_H_

#define DVB_USB_LOG_PREFIX "pctv"
#include "dvb-usb.h"

extern int dvb_usb_pctv_debug;
#define deb_info(args...) dprintk(dvb_usb_pctv_debug,0x01,args)

#define CMD_I2C_WRITE 0x01
/* out: <addr << 1> <olen> <buf>[olen]
* in: 0x00 */

#define CMD_I2C_READ 0x02
/* out: <addr << 1> <olen> <ilen> <buf>[olen]
* in: 0x00 <buf>[ilen] */

#define CMD_GPIO_TUNER 0x16
/* out: <onoff>
* in: 0x00 */

//#define CMD_STREAMING 0x18
/* out: <onoff>
* in: 0x00 */

#endif

/* DVB USB compliant linux driver for the Pinnacle PCTV 200e DVB-T USB2.0 receiver.
*
* Copyright (C) 2005 Patrick Boettcher ([email protected])
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
* Software Foundation, version 2.
*
* see Documentation/dvb/README.dvb-usb for more information
*/
#include "pctv.h"

#include "mt352.h"

/* debug */
int dvb_usb_pctv_debug;
module_param_named(debug,dvb_usb_pctv_debug, int, 0644); MODULE_PARM_DESC(debug, "set debugging level (1=debug (or-able))." DVB_USB_DEBUG_STATUS);

static int pctv_msg(struct dvb_usb_device *d, u8 cmd,
u8 *wbuf, int wlen, u8 *rbuf, int rlen)

{
	int ret;
	u8 sndbuf[wlen+1],
	   rcvbuf[rlen+2];
	memset(sndbuf,0,wlen+1);

	sndbuf[0] = cmd;
	memcpy(&sndbuf[1],wbuf,wlen);

	if ((ret = dvb_usb_generic_rw(d,sndbuf,wlen+1,rcvbuf,rlen+2,0)) < 0)
		return ret;

	if (rcvbuf[0] != sndbuf[0] ||
		rcvbuf[1] != 0x00)
		err("probably a xfer error");

	memcpy(rbuf,&rcvbuf[2],rlen);

	if (rlen > 0)
		deb_info("rbuf[0]: %x, rlen: %d\n",rbuf[0],rlen);

	return 0;
}

static int pctv_i2c_xfer(struct i2c_adapter *adap,struct i2c_msg msg[],int num)

{
	struct dvb_usb_device *d = i2c_get_adapdata(adap);
	static u8 obuf[255];
	int i,read;;

	if (down_interruptible(&d->i2c_sem) < 0)
		return -EAGAIN;

	if (num > 2)
		warn("more than 2 i2c messages at a time is not handled yet. TODO.");

	for (i = 0; i < num; i++) {
		read = i+1 < num && (msg[i+1].flags & I2C_M_RD);

		obuf[0] = msg[i].addr << 1;
		obuf[1] = msg[i].len;

		/* read request */
		if (read)
			obuf[2] = msg[i+1].len;

		memcpy(&obuf[2+read],msg[i].buf,msg[i].len);

		if (read)
			pctv_msg(d,CMD_I2C_READ,obuf,msg[i].len+3,msg[i+1].buf,msg[i+1].len);
		else
			pctv_msg(d,CMD_I2C_WRITE,obuf,msg[i].len+2,NULL,0);

		i += read;

	}

	up(&d->i2c_sem);
	return i;
}

static u32 pctv_i2c_func(struct i2c_adapter *adapter)

{
	return I2C_FUNC_I2C;
}

static struct i2c_algorithm pctv_i2c_algo = {

	.name          = "Pinnacle PCTV USB I2C algorithm",
	.id            = I2C_ALGO_BIT,
	.master_xfer   = pctv_i2c_xfer,

.functionality = pctv_i2c_func,
};

/* GPIO */
static void pctv_gpio_tuner(struct dvb_usb_device *d, int onoff) {

//struct cxusb_state *st = d->priv;
	u8 o;

// if (st->gpio_write_state[GPIO_TUNER] == onoff)
// return;

	o = onoff;
	pctv_msg(d,CMD_GPIO_TUNER,&o,1,NULL,0);
}

static int pctv_power_ctrl(struct dvb_usb_device *d, int onoff)

{
	return 0;
}

static int pctv_streaming_ctrl(struct dvb_usb_device *d, int onoff)

{
	return 0;
}

static int pctv_mt352_demod_init(struct dvb_frontend *fe)

{
	static u8 reset_buf[] = { 0x89, 0xbd,  0x8a, 0x28, 0x50, 0x80 };
	static u8 init_buf[] = { 0x50, 0x00, 0x8e, 0x40,  0x56, 0x31, 0x57, 0xb5,
		0x8b, 0x09, 0x88, 0x0d, 0x7b, 0x04, 0x53, 0xf4, 0x5e, 0x01, 0x54,
		0x73, 0x55, 0x1c, 0x75, 0x30, 0x67, 0x1c, 0x67, 0x00 };
	int i;

	for (i = 0; i < ARRAY_SIZE(reset_buf); i += 2)
		mt352_write(fe, &reset_buf[i], 2);

	msleep(1);

	for (i = 0; i < ARRAY_SIZE(init_buf); i += 2)
		mt352_write(fe, &init_buf[i], 2);

	return 0;
}

static struct mt352_config pctv_mt352_config = {
	.demod_address = 0x1f,

	.demod_init = pctv_mt352_demod_init,

//.pll_init = NULL, /* it'll be mt2060_init */

	.pll_set = dvb_usb_pll_set, /* probably not, it's rather mt2060_set */
};

/* Callbacks for DVB USB */
static int pctv_tuner_attach(struct dvb_usb_device *d)

{
	u8 bpll[4] = { 0x0b, 0xdc, 0x9c, 0xa0 };
	d->pll_addr = 0x61;
	memcpy(d->pll_init,bpll,4);
	d->pll_desc = &dvb_pll_fmd1216me;
	return 0;
}

static int pctv_frontend_attach(struct dvb_usb_device *d)

{
	u8 o=0,i=0;

	pctv_msg(d,0x10,&o,1,&i,1);

	pctv_msg(d,0x15,NULL,0,NULL,0);

	pctv_gpio_tuner(d, 0);
	if ((d->fe = mt352_attach(&pctv_mt352_config, &d->i2c_adap)) != NULL)
		return 0;

	return -EIO;
}

/* DVB USB Driver stuff */
static struct dvb_usb_properties pctv_properties;

static int pctv_probe(struct usb_interface *intf,
const struct usb_device_id *id)

{
	return dvb_usb_device_init(intf,&pctv_properties,THIS_MODULE,NULL);
}

static struct usb_device_id pctv_table [] = {
		{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PCTV_200E) },
		{}		/* Terminating entry */
};

MODULE_DEVICE_TABLE (usb, pctv_table);

static struct dvb_usb_properties pctv_properties = {
	.caps = DVB_USB_IS_AN_I2C_ADAPTER,

	.size_of_priv     = 0,

	.streaming_ctrl   = pctv_streaming_ctrl,
	.power_ctrl       = pctv_power_ctrl,
	.frontend_attach  = pctv_frontend_attach,
	.tuner_attach     = pctv_tuner_attach,

	.i2c_algo         = &pctv_i2c_algo,

	.generic_bulk_ctrl_endpoint = 0x01,
	/* parameter for the MPEG2-data transfer */
	.urb = {
		.type = DVB_USB_BULK,
		.count = 7,
		.endpoint = 0x02,
		.u = {
			.bulk = {
				.buffersize = 4096,
			}
		}
	},

	.num_device_descs = 1,
	.devices = {
		{   "Pinnacle 200e DVB-T USB2.0",
			{ NULL },
			{ &pctv_table[0], NULL },
		},
	}
};

static struct usb_driver pctv_driver = {
	.owner		= THIS_MODULE,
	.name		= "pctv_200e",
	.probe		= pctv_probe,
	.disconnect = dvb_usb_device_exit,
	.id_table	= pctv_table,
};

/* module stuff */
static int __init pctv_module_init(void)

{
	int result;
	if ((result = usb_register(&pctv_driver))) {
		err("usb_register failed. Error number %d",result);
		return result;
	}

	return 0;
}

static void __exit pctv_module_exit(void)

{
	/* deregister this driver from the USB subsystem */
	usb_deregister(&pctv_driver);
}

module_init (pctv_module_init);
module_exit (pctv_module_exit);

MODULE_AUTHOR("Patrick Boettcher <[email protected]>"); MODULE_DESCRIPTION("Driver for Pinnacle 200e DVB-T USB2.0 receiver"); MODULE_VERSION("1.0-alpha");
MODULE_LICENSE("GPL");

Gabriele Dini Ciacci

author

2009-04-01 18:29 UTC #9 lore raw

Quoted 42 lines · On Wed, 1 Apr 2009 17:27:04 +0200 (CEST) Patrick Boettcher…

Hi,
Quoted 27 lines · Gabriele Dini Ciacci
Quoted 24 lines · On Tue, 31 Mar 2009 17:51:23 -0400 Devin Heitmueller…
Quoted 9 lines · Gabriele Dini Ciacci
I it's so, say me how to make or where to look to create a profile for the existing driver.
I am willing to do the work.
(when I first wrote the driver to me it seemed that this was the simplet way.
Meanwhile I will try to look at the Cypress FX2
As Michael Krufky pointed out to me off-list, I was not exactly correct here.
While there are indeed drivers based on the same FX2 chip in your device, it may be possible to reuse an existing driver, or you may need a whole new driver, depending on how much the firmware varies between your product versus the others. You may want to look at the pvrusb2 and cxusb drivers, which also use the FX2 chip, and see what similarities exist in terms of the API and command set. If it is not similar to any of the others, then writing a new driver is probably the correct approach.
Quoted 6 lines
Quoted 4 lines
Regards,
Devin
Fine perfect, thanks,
Attached you can find my attempts from 2005. I2C should work, please re-use this implementation as it nicely splits i2c_transfer from the rest of the required functionality.

Quoted 8 lines

I think I still have the pctv 200e somewhere in a box... I may get it back, undust it and try.
Patrick.
--
Mail: [email protected]
WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/

I had a quick look (1 min) and I think the interface is to port to the new "style" used. I can merge my version of the driver with your and get a final driver, indeed your i2c is much better, as I coded i2c as a i2c ignorant, so just copying from the other drivers. I will just take your implementation for that part.

Thanks a lot for the i2c explanation, that explains! Now my view is much clearer.

So what if I try to merge the two drivers to get a clean one, test them on pctv60e, you test them on pctv200e and... done!

The cherry would be to spend some time on the IR also, but just wait to have a driver.

Regards & cheers,
Gabriele