Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver

2011-01-18 Thread Oliver Endriss
On Monday 17 January 2011 17:31:15 Mauro Carvalho Chehab wrote:
 Em 10-01-2011 15:20, Oliver Endriss escreveu:
  On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote:
  On 01/10/2011 10:36 AM, Oliver Endriss wrote:
  From: Ralph Metzler r...@metzlerbros.de
 
  Driver for the Common Interface Controller CXD2099AR.
  Supports the CI of the cineS2 DVB-S2.
 
  For now, data is passed through '/dev/dvb/adapterX/sec0':
  - Encrypted data must be written to 'sec0'.
  - Decrypted data can be read from 'sec0'.
  - Setup the CAM using device 'ca0'.
 
  Nack. In DVB API terms, sec stands for satellite equipment control,
  and if I remember correctly, sec0 already existed in the first versions
  of the API and that's why its leftovers can be abused by this driver.
 
  The interfaces for writing data are dvr0 and demux0. If they don't fit
  for decryption of recorded data, then they should be extended.
 
  For decryption of live data, no new user interface needs to be created.
  
  There was an attempt to find a solution for the problem in thread
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
  
  As that discussion did not come to a final solution, and the driver is
  still experimental, I left the original patch 'as is'.
 
 Drivers that don't use the proper API should be moved to staging. Just making
 them as experimental is not good enough. As this is the only issue with
 this patch series, I'll be applying them and moving cxd2099 driver to staging
 while we don't have a proper fix for it.

Ok.

 +struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct i2c_adapter 
 *i2c)
 +{
 + printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
 + return NULL;
 +}
 +#endif

If staging drivers are disabled, compilation will fail with
multiple definition of `cxd2099_attach'.

The helper function must be declared as 'static inline'.

Please apply this fix:

diff --git a/drivers/staging/cxd2099/cxd2099.h 
b/drivers/staging/cxd2099/cxd2099.h
index a313dc2..bed54ff 100644
--- a/drivers/staging/cxd2099/cxd2099.h
+++ b/drivers/staging/cxd2099/cxd2099.h
@@ -31,7 +31,7 @@
 (defined(CONFIG_DVB_CXD2099_MODULE)  defined(MODULE))
 struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct i2c_adapter 
*i2c);
 #else
-struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct i2c_adapter 
*i2c)
+static inline struct dvb_ca_en50221 *cxd2099_attach(u8 adr, void *priv, struct 
i2c_adapter *i2c)
 {
printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
return NULL;


-- 

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

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


Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver

2011-01-17 Thread Mauro Carvalho Chehab
Em 10-01-2011 15:20, Oliver Endriss escreveu:
 On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote:
 On 01/10/2011 10:36 AM, Oliver Endriss wrote:
 From: Ralph Metzler r...@metzlerbros.de

 Driver for the Common Interface Controller CXD2099AR.
 Supports the CI of the cineS2 DVB-S2.

 For now, data is passed through '/dev/dvb/adapterX/sec0':
 - Encrypted data must be written to 'sec0'.
 - Decrypted data can be read from 'sec0'.
 - Setup the CAM using device 'ca0'.

 Nack. In DVB API terms, sec stands for satellite equipment control,
 and if I remember correctly, sec0 already existed in the first versions
 of the API and that's why its leftovers can be abused by this driver.

 The interfaces for writing data are dvr0 and demux0. If they don't fit
 for decryption of recorded data, then they should be extended.

 For decryption of live data, no new user interface needs to be created.
 
 There was an attempt to find a solution for the problem in thread
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
 
 As that discussion did not come to a final solution, and the driver is
 still experimental, I left the original patch 'as is'.

Drivers that don't use the proper API should be moved to staging. Just making
them as experimental is not good enough. As this is the only issue with
this patch series, I'll be applying them and moving cxd2099 driver to staging
while we don't have a proper fix for it.

Cheers,
Mauro.

PS.: The patch I'm appling to move it to staging is enclosed.

-

commit 96d7f7656af8a348134302d8c36760156ea6428e
Author: Mauro Carvalho Chehab mche...@redhat.com
Date:   Mon Jan 17 14:20:49 2011 -0200

[media] Move CI cxd2099 driver to staging

This driver is abusing the kernel=userspace API, due to the lack of a
proper solution for it. A discussion were done at:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
But there's not a solution for it yet. So, move the driver to staging, while
we don't have a final solution.

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

diff --git a/drivers/media/dvb/ngene/Makefile b/drivers/media/dvb/ngene/Makefile
index 00d12d6..2bc9687 100644
--- a/drivers/media/dvb/ngene/Makefile
+++ b/drivers/media/dvb/ngene/Makefile
@@ -2,10 +2,13 @@
 # Makefile for the nGene device driver
 #
 
-ngene-objs := ngene-core.o ngene-i2c.o ngene-cards.o ngene-dvb.o cxd2099.o
+ngene-objs := ngene-core.o ngene-i2c.o ngene-cards.o ngene-dvb.o
 
 obj-$(CONFIG_DVB_NGENE) += ngene.o
 
 EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/
 EXTRA_CFLAGS += -Idrivers/media/dvb/frontends/
 EXTRA_CFLAGS += -Idrivers/media/common/tuners/
+
+# For the staging CI driver cxd2099
+EXTRA_CFLAGS += -Idrivers/staging/cxd2099/
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index bdc632b..1fc1087 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -51,6 +51,8 @@ source drivers/staging/cx25821/Kconfig
 
 source drivers/staging/tm6000/Kconfig
 
+source drivers/staging/cxd2099/Kconfig
+
 source drivers/staging/dabusb/Kconfig
 
 source drivers/staging/se401/Kconfig
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 3eda5c7..2f638e5 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_SLICOSS)   += slicoss/
 obj-$(CONFIG_VIDEO_GO7007) += go7007/
 obj-$(CONFIG_VIDEO_CX25821)+= cx25821/
 obj-$(CONFIG_VIDEO_TM6000) += tm6000/
+obj-$(CONFIG_DVB_CXD2099)  += cxd2099/
 obj-$(CONFIG_USB_DABUSB)+= dabusb/
 obj-$(CONFIG_USB_VICAM) += usbvideo/
 obj-$(CONFIG_USB_SE401) += se401/
diff --git a/drivers/staging/cxd2099/Kconfig b/drivers/staging/cxd2099/Kconfig
new file mode 100644
index 000..9d638c3
--- /dev/null
+++ b/drivers/staging/cxd2099/Kconfig
@@ -0,0 +1,11 @@
+config DVB_CXD2099
+tristate CXD2099AR Common Interface driver
+depends on DVB_CORE  PCI  I2C  DVB_NGENE
+---help---
+  Support for the CI module found on cineS2 DVB-S2, supported by
+ the Micronas PCIe device driver (ngene).
+
+ For now, data is passed through '/dev/dvb/adapterX/sec0':
+   - Encrypted data must be written to 'sec0'.
+   - Decrypted data can be read from 'sec0'.
+   - Setup the CAM using device 'ca0'.
diff --git a/drivers/staging/cxd2099/Makefile b/drivers/staging/cxd2099/Makefile
new file mode 100644
index 000..72b1455
--- /dev/null
+++ b/drivers/staging/cxd2099/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_DVB_CXD2099) += cxd2099.o
+
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/
+EXTRA_CFLAGS += -Idrivers/media/dvb/frontends/
+EXTRA_CFLAGS += -Idrivers/media/common/tuners/
diff --git a/drivers/staging/cxd2099/TODO b/drivers/staging/cxd2099/TODO
new file mode 100644
index 000..375bb6f
--- /dev/null
+++ b/drivers/staging/cxd2099/TODO
@@ -0,0 +1,12 @@
+For now, data is passed through '/dev/dvb/adapterX/sec0':
+ - Encrypted data must be 

[PATCH 07/16] ngene: CXD2099AR Common Interface driver

2011-01-10 Thread Oliver Endriss
From: Ralph Metzler r...@metzlerbros.de

Driver for the Common Interface Controller CXD2099AR.
Supports the CI of the cineS2 DVB-S2.

For now, data is passed through '/dev/dvb/adapterX/sec0':
- Encrypted data must be written to 'sec0'.
- Decrypted data can be read from 'sec0'.
- Setup the CAM using device 'ca0'.

Signed-off-by: Ralph Metzler r...@metzlerbros.de
Signed-off-by: Oliver Endriss o.endr...@gmx.de
---
 drivers/media/dvb/ngene/Makefile  |2 +-
 drivers/media/dvb/ngene/cxd2099.c |  574 +
 drivers/media/dvb/ngene/cxd2099.h |   32 ++
 drivers/media/dvb/ngene/ngene-cards.c |6 +-
 drivers/media/dvb/ngene/ngene-core.c  |  110 +--
 drivers/media/dvb/ngene/ngene-dvb.c   |   70 -
 drivers/media/dvb/ngene/ngene.h   |   19 ++
 7 files changed, 782 insertions(+), 31 deletions(-)
 create mode 100644 drivers/media/dvb/ngene/cxd2099.c
 create mode 100644 drivers/media/dvb/ngene/cxd2099.h

diff --git a/drivers/media/dvb/ngene/Makefile b/drivers/media/dvb/ngene/Makefile
index 0608aab..00d12d6 100644
--- a/drivers/media/dvb/ngene/Makefile
+++ b/drivers/media/dvb/ngene/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the nGene device driver
 #
 
-ngene-objs := ngene-core.o ngene-i2c.o ngene-cards.o ngene-dvb.o
+ngene-objs := ngene-core.o ngene-i2c.o ngene-cards.o ngene-dvb.o cxd2099.o
 
 obj-$(CONFIG_DVB_NGENE) += ngene.o
 
diff --git a/drivers/media/dvb/ngene/cxd2099.c 
b/drivers/media/dvb/ngene/cxd2099.c
new file mode 100644
index 000..b49186c
--- /dev/null
+++ b/drivers/media/dvb/ngene/cxd2099.c
@@ -0,0 +1,574 @@
+/*
+ * cxd2099.c: Driver for the CXD2099AR Common Interface Controller
+ *
+ * Copyright (C) 2010 DigitalDevices UG
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/version.h
+#include linux/slab.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/wait.h
+#include linux/delay.h
+#include linux/mutex.h
+#include linux/io.h
+
+#include cxd2099.h
+
+#define MAX_BUFFER_SIZE 248
+
+struct cxd {
+   struct dvb_ca_en50221 en;
+
+   struct i2c_adapter *i2c;
+   u8 adr;
+   u8 regs[0x23];
+   u8 lastaddress;
+   u8 clk_reg_f;
+   u8 clk_reg_b;
+   intmode;
+   u32bitrate;
+   intready;
+   intdr;
+   intslot_stat;
+
+   u8 amem[1024];
+   intamem_read;
+
+   intcammode;
+   struct mutex lock;
+};
+
+static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
+u8 reg, u8 data)
+{
+   u8 m[2] = {reg, data};
+   struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
+
+   if (i2c_transfer(adapter, msg, 1) != 1) {
+   printk(KERN_ERR Failed to write to I2C register %...@%02x!\n,
+  reg, adr);
+   return -1;
+   }
+   return 0;
+}
+
+static int i2c_write(struct i2c_adapter *adapter, u8 adr,
+u8 *data, u8 len)
+{
+   struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
+
+   if (i2c_transfer(adapter, msg, 1) != 1) {
+   printk(KERN_ERR Failed to write to I2C!\n);
+   return -1;
+   }
+   return 0;
+}
+
+static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
+   u8 reg, u8 *val)
+{
+   struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+  .buf = reg, .len = 1 },
+ {.addr = adr, .flags = I2C_M_RD,
+  .buf = val, .len = 1 } };
+
+   if (i2c_transfer(adapter, msgs, 2) != 2) {
+   printk(KERN_ERR error in i2c_read_reg\n);
+   return -1;
+   }
+   return 0;
+}
+
+static int i2c_read(struct i2c_adapter *adapter, u8 adr,
+   u8 reg, u8 *data, u8 n)
+{
+   struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+  .buf = reg, .len = 1 },
+ {.addr = adr, .flags = I2C_M_RD,
+  .buf = data, .len = n } };
+
+   if (i2c_transfer(adapter, msgs, 2) != 2) {
+   printk(KERN_ERR error in 

Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver

2011-01-10 Thread Andreas Oberritter
On 01/10/2011 10:36 AM, Oliver Endriss wrote:
 From: Ralph Metzler r...@metzlerbros.de
 
 Driver for the Common Interface Controller CXD2099AR.
 Supports the CI of the cineS2 DVB-S2.
 
 For now, data is passed through '/dev/dvb/adapterX/sec0':
 - Encrypted data must be written to 'sec0'.
 - Decrypted data can be read from 'sec0'.
 - Setup the CAM using device 'ca0'.

Nack. In DVB API terms, sec stands for satellite equipment control,
and if I remember correctly, sec0 already existed in the first versions
of the API and that's why its leftovers can be abused by this driver.

The interfaces for writing data are dvr0 and demux0. If they don't fit
for decryption of recorded data, then they should be extended.

For decryption of live data, no new user interface needs to be created.

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


Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver

2011-01-10 Thread Oliver Endriss
On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote:
 On 01/10/2011 10:36 AM, Oliver Endriss wrote:
  From: Ralph Metzler r...@metzlerbros.de
  
  Driver for the Common Interface Controller CXD2099AR.
  Supports the CI of the cineS2 DVB-S2.
  
  For now, data is passed through '/dev/dvb/adapterX/sec0':
  - Encrypted data must be written to 'sec0'.
  - Decrypted data can be read from 'sec0'.
  - Setup the CAM using device 'ca0'.
 
 Nack. In DVB API terms, sec stands for satellite equipment control,
 and if I remember correctly, sec0 already existed in the first versions
 of the API and that's why its leftovers can be abused by this driver.
 
 The interfaces for writing data are dvr0 and demux0. If they don't fit
 for decryption of recorded data, then they should be extended.
 
 For decryption of live data, no new user interface needs to be created.

There was an attempt to find a solution for the problem in thread
http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html

As that discussion did not come to a final solution, and the driver is
still experimental, I left the original patch 'as is'.

CU
Oliver

-- 

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

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


Interconnection of different DVB adapters (was: Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver)

2011-01-10 Thread Andreas Oberritter
On 01/10/2011 06:20 PM, Oliver Endriss wrote:
 On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote:
 On 01/10/2011 10:36 AM, Oliver Endriss wrote:
 From: Ralph Metzler r...@metzlerbros.de

 Driver for the Common Interface Controller CXD2099AR.
 Supports the CI of the cineS2 DVB-S2.

 For now, data is passed through '/dev/dvb/adapterX/sec0':
 - Encrypted data must be written to 'sec0'.
 - Decrypted data can be read from 'sec0'.
 - Setup the CAM using device 'ca0'.

 Nack. In DVB API terms, sec stands for satellite equipment control,
 and if I remember correctly, sec0 already existed in the first versions
 of the API and that's why its leftovers can be abused by this driver.

 The interfaces for writing data are dvr0 and demux0. If they don't fit
 for decryption of recorded data, then they should be extended.

 For decryption of live data, no new user interface needs to be created.
 
 There was an attempt to find a solution for the problem in thread
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
 
 As that discussion did not come to a final solution, and the driver is
 still experimental, I left the original patch 'as is'.

Thanks for the pointer. My impression from the quoted thread is that the
most desired and viable solution was to create a ca device node which
can be virtually connected on demand to a demux or dvr device of another
adapter, but there was no intent to put the required amount of work into
it. That's fair, but IMHO not suitable for submission to the mainline
kernel.

This definitely needs more thought.

Maybe the adapter-based scheme currently in use needs to be revised
thoroughly. The budget type of adapters are basically just frontends
and we should be able to interconnect those (and also other) frontends
with CIs, demuxes and decoders of different adapters, if the underlying
buses allow it. Is this something the media controller and mem2mem APIs
are trying to solve for V4L? If yes, this could become interesting for
DVB, too.

Regards,
Andreas
--
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: Interconnection of different DVB adapters (was: Re: [PATCH 07/16] ngene: CXD2099AR Common Interface driver)

2011-01-10 Thread Oliver Endriss
On Tuesday 11 January 2011 02:32:14 Andreas Oberritter wrote:
 On 01/10/2011 06:20 PM, Oliver Endriss wrote:
  On Monday 10 January 2011 15:05:34 Andreas Oberritter wrote:
  On 01/10/2011 10:36 AM, Oliver Endriss wrote:
  From: Ralph Metzler r...@metzlerbros.de
 
  Driver for the Common Interface Controller CXD2099AR.
  Supports the CI of the cineS2 DVB-S2.
 
  For now, data is passed through '/dev/dvb/adapterX/sec0':
  - Encrypted data must be written to 'sec0'.
  - Decrypted data can be read from 'sec0'.
  - Setup the CAM using device 'ca0'.
 
  Nack. In DVB API terms, sec stands for satellite equipment control,
  and if I remember correctly, sec0 already existed in the first versions
  of the API and that's why its leftovers can be abused by this driver.
 
  The interfaces for writing data are dvr0 and demux0. If they don't fit
  for decryption of recorded data, then they should be extended.
 
  For decryption of live data, no new user interface needs to be created.
  
  There was an attempt to find a solution for the problem in thread
  http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
  
  As that discussion did not come to a final solution, and the driver is
  still experimental, I left the original patch 'as is'.
 
 Thanks for the pointer. My impression from the quoted thread is that the
 most desired and viable solution was to create a ca device node which
 can be virtually connected on demand to a demux or dvr device of another
 adapter, but there was no intent to put the required amount of work into
 it.

Attaching a CI to a single frontend is easy. In this case we could
simply attach the CI to the first frontend of the card, and we are done.

The intention was to allow decryption of streams from more than one
frontend _at_the_same_time_. That might require multiplexing partial
TS streams into a new one, passing it to the CAM and demultiplexing the
decrypted stream again.

The idea was to perform these operations in userspace, while the kernel
provides a simple interface which
- accepts an encrypted stream and
- delivers the decrypted stream.

sec0 was chosen because it exists and it is currently unused.
It can be renamed anytime, if we reach an agreement.

 That's fair, but IMHO not suitable for submission to the mainline 
 kernel.

 This definitely needs more thought.

If this is the common opinion, I will simply strip the CI support from
the driver again. The stv0900x and ngene patches are too important to be
delayed.

 Maybe the adapter-based scheme currently in use needs to be revised
 thoroughly. The budget type of adapters are basically just frontends
 and we should be able to interconnect those (and also other) frontends
 with CIs, demuxes and decoders of different adapters, if the underlying
 buses allow it. Is this something the media controller and mem2mem APIs
 are trying to solve for V4L? If yes, this could become interesting for
 DVB, too.

Honestly, I have little motivation to work on things,  which I do not
use. I do not care about CAM stuff. I am just submitting the code
I received...

CU
Oliver

-- 

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

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