Re: [PATCH] Ngene cam device name

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>> Hi,
>>
>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>> simple question which has been pointed out to me before:
>>
>> Why is cxd2099.c in staging regarding the device name question?
>> It has nothing to do with the naming.
> It is not just because of naming. A NACK was given to it, as is, at:
>
> http://www.spinics.net/lists/linux-media/msg28004.html
>
> A previous discussion about this subject were started at:
> 	http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
>
> The point is that an interface meant to be used by satellite were
> used as a ci interface, due to the lack of handling independent CA devices.
>
> As there were no final decision about a proper way to address it, Oliver
> decided to keep it as-is, and I decided to move it to staging while we
> don't properly address the question, extending the DVB API in order to
support
> independent CA devs.
>
> Having the driver at staging allow us to rework at the API and change the
> driver when API changes are done, without needing to pass through kernel 
> process of deprecating old API stuff.
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello all,

Here is the patch for the NGene card family and the new caio device.
Can cxd2099 be removed from staging as this patch fixes the raised issue.

Signed-off-by: Issa Gorissen <flop.m@usa.net>
---
 drivers/media/dvb/dvb-core/dvbdev.c  |    2 +-
 drivers/media/dvb/dvb-core/dvbdev.h  |    1 +
 drivers/media/dvb/ngene/ngene-core.c |    2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
 
 static const char * const dnames[] = {
 	"video", "audio", "sec", "frontend", "demux", "dvr", "ca",
-	"net", "osd"
+	"net", "osd", "caio"
 };
 
 #ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
 #define DVB_DEVICE_CA         6
 #define DVB_DEVICE_NET        7
 #define DVB_DEVICE_OSD        8
+#define DVB_DEVICE_CAIO       9
 
 #define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
 	static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
 		set_transfer(&chan->dev->channel[2], 1);
 		dvb_register_device(adapter, &chan->ci_dev,
 				    &ngene_dvbdev_ci, (void *) chan,
-				    DVB_DEVICE_SEC);
+				    DVB_DEVICE_CAIO);
 		if (!chan->ci_dev)
 			goto err;
 	}

Re: [PATCH] Ngene cam device name

[Mauro Carvalho Chehab]

Em 24-04-2011 08:38, Issa Gorissen escreveu:
> On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
>> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>>> Hi,
>>>
>>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>>> simple question which has been pointed out to me before:
>>>
>>> Why is cxd2099.c in staging regarding the device name question?
>>> It has nothing to do with the naming.
>> It is not just because of naming. A NACK was given to it, as is, at:
>>
>> http://www.spinics.net/lists/linux-media/msg28004.html
>>
>> A previous discussion about this subject were started at:
>> 	http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
>>
>> The point is that an interface meant to be used by satellite were
>> used as a ci interface, due to the lack of handling independent CA devices.
>>
>> As there were no final decision about a proper way to address it, Oliver
>> decided to keep it as-is, and I decided to move it to staging while we
>> don't properly address the question, extending the DVB API in order to
> support
>> independent CA devs.
>>
>> Having the driver at staging allow us to rework at the API and change the
>> driver when API changes are done, without needing to pass through kernel 
>> process of deprecating old API stuff.
>>
>> Cheers,
>> Mauro
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Hello all,
> 
> Here is the patch for the NGene card family and the new caio device.
> Can cxd2099 be removed from staging as this patch fixes the raised issue.
> 
> Signed-off-by: Issa Gorissen <flop.m@usa.net>
> ---
>  drivers/media/dvb/dvb-core/dvbdev.c  |    2 +-
>  drivers/media/dvb/dvb-core/dvbdev.h  |    1 +
>  drivers/media/dvb/ngene/ngene-core.c |    2 +-
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
> b/drivers/media/dvb/dvb-core/dvbdev.c
> index f732877..7a64b81 100644
> --- a/drivers/media/dvb/dvb-core/dvbdev.c
> +++ b/drivers/media/dvb/dvb-core/dvbdev.c
> @@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
>  
>  static const char * const dnames[] = {
>  	"video", "audio", "sec", "frontend", "demux", "dvr", "ca",
> -	"net", "osd"
> +	"net", "osd", "caio"
>  };
>  
>  #ifdef CONFIG_DVB_DYNAMIC_MINORS
> diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
> b/drivers/media/dvb/dvb-core/dvbdev.h
> index fcc6ae9..c63c70d 100644
> --- a/drivers/media/dvb/dvb-core/dvbdev.h
> +++ b/drivers/media/dvb/dvb-core/dvbdev.h
> @@ -47,6 +47,7 @@
>  #define DVB_DEVICE_CA         6
>  #define DVB_DEVICE_NET        7
>  #define DVB_DEVICE_OSD        8
> +#define DVB_DEVICE_CAIO       9
>  
>  #define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
>  	static short adapter_nr[] = \
> diff --git a/drivers/media/dvb/ngene/ngene-core.c
> b/drivers/media/dvb/ngene/ngene-core.c
> index 175a0f6..17cdd38 100644
> --- a/drivers/media/dvb/ngene/ngene-core.c
> +++ b/drivers/media/dvb/ngene/ngene-core.c
> @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
>  		set_transfer(&chan->dev->channel[2], 1);
>  		dvb_register_device(adapter, &chan->ci_dev,
>  				    &ngene_dvbdev_ci, (void *) chan,
> -				    DVB_DEVICE_SEC);
> +				    DVB_DEVICE_CAIO);
>  		if (!chan->ci_dev)
>  			goto err;
>  	}
> 

It is not that simple. The question is not just how to name the interface, 
but that such interface will work on a different way than the current 
ca interface.

In other words, the DVB API should clearly explain why this
interface is different, when it should be used and how.

Cheers,
Mauro.

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/04/2011 01:11 AM, Mauro Carvalho Chehab wrote:
> Em 24-04-2011 08:38, Issa Gorissen escreveu:
>> On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
>>> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>>>> Hi,
>>>>
>>>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>>>> simple question which has been pointed out to me before:
>>>>
>>>> Why is cxd2099.c in staging regarding the device name question?
>>>> It has nothing to do with the naming.
>>> It is not just because of naming. A NACK was given to it, as is, at:
>>>
>>> http://www.spinics.net/lists/linux-media/msg28004.html
>>>
>>> A previous discussion about this subject were started at:
>>> 	http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
>>>
>>> The point is that an interface meant to be used by satellite were
>>> used as a ci interface, due to the lack of handling independent CA devices.
>>>
>>> As there were no final decision about a proper way to address it, Oliver
>>> decided to keep it as-is, and I decided to move it to staging while we
>>> don't properly address the question, extending the DVB API in order to
>> support
>>> independent CA devs.
>>>
>>> Having the driver at staging allow us to rework at the API and change the
>>> driver when API changes are done, without needing to pass through kernel 
>>> process of deprecating old API stuff.
>>>
>>> Cheers,
>>> Mauro
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> Hello all,
>>
>> Here is the patch for the NGene card family and the new caio device.
>> Can cxd2099 be removed from staging as this patch fixes the raised issue.
>>
>> Signed-off-by: Issa Gorissen <flop.m@usa.net>
>> ---
>>  drivers/media/dvb/dvb-core/dvbdev.c  |    2 +-
>>  drivers/media/dvb/dvb-core/dvbdev.h  |    1 +
>>  drivers/media/dvb/ngene/ngene-core.c |    2 +-
>>  3 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/dvb/dvb-core/dvbdev.c
>> b/drivers/media/dvb/dvb-core/dvbdev.c
>> index f732877..7a64b81 100644
>> --- a/drivers/media/dvb/dvb-core/dvbdev.c
>> +++ b/drivers/media/dvb/dvb-core/dvbdev.c
>> @@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
>>  
>>  static const char * const dnames[] = {
>>  	"video", "audio", "sec", "frontend", "demux", "dvr", "ca",
>> -	"net", "osd"
>> +	"net", "osd", "caio"
>>  };

There's no reason to keep sec.

>>  
>>  #ifdef CONFIG_DVB_DYNAMIC_MINORS
>> diff --git a/drivers/media/dvb/dvb-core/dvbdev.h
>> b/drivers/media/dvb/dvb-core/dvbdev.h
>> index fcc6ae9..c63c70d 100644
>> --- a/drivers/media/dvb/dvb-core/dvbdev.h
>> +++ b/drivers/media/dvb/dvb-core/dvbdev.h
>> @@ -47,6 +47,7 @@
>>  #define DVB_DEVICE_CA         6
>>  #define DVB_DEVICE_NET        7
>>  #define DVB_DEVICE_OSD        8
>> +#define DVB_DEVICE_CAIO       9
>>  
>>  #define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
>>  	static short adapter_nr[] = \
>> diff --git a/drivers/media/dvb/ngene/ngene-core.c
>> b/drivers/media/dvb/ngene/ngene-core.c
>> index 175a0f6..17cdd38 100644
>> --- a/drivers/media/dvb/ngene/ngene-core.c
>> +++ b/drivers/media/dvb/ngene/ngene-core.c
>> @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
>>  		set_transfer(&chan->dev->channel[2], 1);
>>  		dvb_register_device(adapter, &chan->ci_dev,
>>  				    &ngene_dvbdev_ci, (void *) chan,
>> -				    DVB_DEVICE_SEC);
>> +				    DVB_DEVICE_CAIO);
>>  		if (!chan->ci_dev)
>>  			goto err;
>>  	}
>>
> 
> It is not that simple. The question is not just how to name the interface, 
> but that such interface will work on a different way than the current 
> ca interface.
> 
> In other words, the DVB API should clearly explain why this
> interface is different, when it should be used and how.

Also, there's still no mapping between ca and caio devices. Imagine a
built-in descrambler ca0 and two CI slots ca1 and ca2.

ca0 won't get a caio device, at least for now.
ca1 and ca2 might or might not have a caio device.

If there is caio0, how am I supposed to know that it's related to ca1 or
ca2 (or ca0, if someone implements a caio device to bypass the software
demux to use a built-in descrambler)? You must not assume that there are
either none or two (or three) caio interfaces. You need to be able to
detect (or set up) the connection between the interfaces. Otherwise this
"API" will be a mess.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> On 05/06/2011 03:47 PM, Issa Gorissen wrote:
> > From: Andreas Oberritter <obi@linuxtv.org>
> >>> The best would be to create independent adapters for each independent
CA
> >>> device (ca0/caio0 pair) - they are independent after all (physically
and
> >>> in the way they're used).
> >>
> >> Physically, it's a general purpose TS I/O interface of the nGene
> >> chipset. It just happens to be connected to a CI slot. On another board,
> >> it might be connected to a modulator or just to some kind of socket.
> >>
> >> If the next version gets a connector for two switchable CI modules, then
> >> the physical independence is gone. You'd have two ca nodes but only one
> >> caio node. Or two caio nodes, that can't be used concurrently.
> >>
> >> Maybe the next version gets the ability to directly connect the TS input
> >> from the frontend to the TS output to the CI slot to save copying around
> >> the data, by using some kind of pin mux. Not physically independent
either.
> >>
> >> It just looks physically independent in the one configuration
> >> implemented now.
> > 
> > 
> > When I read the cxd2099ar datasheet, I can see that in dual slot
> > configuration, there is still one communication channel for the TS and one
for
> > the control.
> 
> It doesn't matter how the cxd2099ar works, because I'm talking about the
> nGene chipset in place of any chipset having at least two TS inputs and
> one TS output.


Don't know the ngene bridge enough to comment on this.


> 
> Btw., I don't think the cxd2099 driver has any obvious problems. It's
> the nGene driver that registers the sec/caio interface.
> 
> > Also, it seems linux en50221 stack provides for the slot selection. So,
why
> > would you need two ca nodes ?
> 
> Because it's the most obvious way to use it. And more importantly
> because the API sucks, if you have more than one device per node. You
> can have only one reader, one writer, one poll function per node. For
> example, you can't use one instance of mplayer to watch one channel with
> fe0+dmx0+ca0 and a second instance of mplayer to watch or record another
> channel with fe1+dmx1+ca0. You won't know which device has an event if
> you use poll. The API even allows mixing multiple CI slots and built-in
> descramblers in the same node. But try calling CA_RESET on a specific
> slot or on a descrambler. It won't work. It's broken by design.


You need to write a userspace soft which will handle the concurrent access of
your ca device...

But for your given example, is there any card allowing you to do that (one ci
slot, two tuners) ?

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

Hello Issa,

On 05/06/2011 08:29 PM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>> On 05/06/2011 03:47 PM, Issa Gorissen wrote:
>>> Also, it seems linux en50221 stack provides for the slot selection. So,
> why
>>> would you need two ca nodes ?
>>
>> Because it's the most obvious way to use it. And more importantly
>> because the API sucks, if you have more than one device per node. You
>> can have only one reader, one writer, one poll function per node. For
>> example, you can't use one instance of mplayer to watch one channel with
>> fe0+dmx0+ca0 and a second instance of mplayer to watch or record another
>> channel with fe1+dmx1+ca0. You won't know which device has an event if
>> you use poll. The API even allows mixing multiple CI slots and built-in
>> descramblers in the same node. But try calling CA_RESET on a specific
>> slot or on a descrambler. It won't work. It's broken by design.
> 
> 
> You need to write a userspace soft which will handle the concurrent access of
> your ca device...

... to gain what exactly over using two distinct nodes?

How do you propose solving the problem with CA_RESET with a userspace soft?

> But for your given example, is there any card allowing you to do that (one ci
> slot, two tuners) ?

You don't seem to have understood my example. I was explaining some
drawbacks of having more than one CI slot, but only one node, answering
your prior question.

Besides that, it's highly probable that such a card exists. It wouldn't
make much sense to hardwire CI slots to tuners, if multiple tuners exist
on a board.

Disregarding the term "cards", there are variants of the Dreambox with
1, 2 or 4 CI slots combined with 1 to 4 tuners.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

On 08/05/11 11:53, Andreas Oberritter wrote:
> Hello Issa,
>
> On 05/06/2011 08:29 PM, Issa Gorissen wrote:
>> From: Andreas Oberritter <obi@linuxtv.org>
>>> On 05/06/2011 03:47 PM, Issa Gorissen wrote:
>>>> Also, it seems linux en50221 stack provides for the slot selection. So,
>> why
>>>> would you need two ca nodes ?
>>> Because it's the most obvious way to use it. And more importantly
>>> because the API sucks, if you have more than one device per node. You
>>> can have only one reader, one writer, one poll function per node. For
>>> example, you can't use one instance of mplayer to watch one channel with
>>> fe0+dmx0+ca0 and a second instance of mplayer to watch or record another
>>> channel with fe1+dmx1+ca0. You won't know which device has an event if
>>> you use poll. The API even allows mixing multiple CI slots and built-in
>>> descramblers in the same node. But try calling CA_RESET on a specific
>>> slot or on a descrambler. It won't work. It's broken by design.
>>
>> You need to write a userspace soft which will handle the concurrent access of
>> your ca device...
> ... to gain what exactly over using two distinct nodes?
>
> How do you propose solving the problem with CA_RESET with a userspace soft?

Well, solving your problem of having two mplayer instances!

The CA_RESET ioctl will not reset one slot at a time obviously. But you
can do an interface reset via the control register, no ? In cases when
you remove/add a second/third/... module from one of the slot of a CI
device, then I guess the CA_RESET is broken because it will reset
everything... Have you got patches for that ?


>> But for your given example, is there any card allowing you to do that (one ci
>> slot, two tuners) ?
> You don't seem to have understood my example. I was explaining some
> drawbacks of having more than one CI slot, but only one node, answering
> your prior question.
>
> Besides that, it's highly probable that such a card exists. It wouldn't
> make much sense to hardwire CI slots to tuners, if multiple tuners exist
> on a board.
>
> Disregarding the term "cards", there are variants of the Dreambox with
> 1, 2 or 4 CI slots combined with 1 to 4 tuners.
>
> Regards,
> Andreas


I guess your point is valid, maybe the improvement you would like to see
will pop up when the need will be created...

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> > The best would be to create independent adapters for each independent CA
> > device (ca0/caio0 pair) - they are independent after all (physically and
> > in the way they're used).
> 
> Physically, it's a general purpose TS I/O interface of the nGene
> chipset. It just happens to be connected to a CI slot. On another board,
> it might be connected to a modulator or just to some kind of socket.
> 
> If the next version gets a connector for two switchable CI modules, then
> the physical independence is gone. You'd have two ca nodes but only one
> caio node. Or two caio nodes, that can't be used concurrently.
> 
> Maybe the next version gets the ability to directly connect the TS input
> from the frontend to the TS output to the CI slot to save copying around
> the data, by using some kind of pin mux. Not physically independent either.
> 
> It just looks physically independent in the one configuration
> implemented now.


When I read the cxd2099ar datasheet, I can see that in dual slot
configuration, there is still one communication channel for the TS and one for
the control.
Also, it seems linux en50221 stack provides for the slot selection. So, why
would you need two ca nodes ?

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/06/2011 03:47 PM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>>> The best would be to create independent adapters for each independent CA
>>> device (ca0/caio0 pair) - they are independent after all (physically and
>>> in the way they're used).
>>
>> Physically, it's a general purpose TS I/O interface of the nGene
>> chipset. It just happens to be connected to a CI slot. On another board,
>> it might be connected to a modulator or just to some kind of socket.
>>
>> If the next version gets a connector for two switchable CI modules, then
>> the physical independence is gone. You'd have two ca nodes but only one
>> caio node. Or two caio nodes, that can't be used concurrently.
>>
>> Maybe the next version gets the ability to directly connect the TS input
>> from the frontend to the TS output to the CI slot to save copying around
>> the data, by using some kind of pin mux. Not physically independent either.
>>
>> It just looks physically independent in the one configuration
>> implemented now.
> 
> 
> When I read the cxd2099ar datasheet, I can see that in dual slot
> configuration, there is still one communication channel for the TS and one for
> the control.

It doesn't matter how the cxd2099ar works, because I'm talking about the
nGene chipset in place of any chipset having at least two TS inputs and
one TS output.

Btw., I don't think the cxd2099 driver has any obvious problems. It's
the nGene driver that registers the sec/caio interface.

> Also, it seems linux en50221 stack provides for the slot selection. So, why
> would you need two ca nodes ?

Because it's the most obvious way to use it. And more importantly
because the API sucks, if you have more than one device per node. You
can have only one reader, one writer, one poll function per node. For
example, you can't use one instance of mplayer to watch one channel with
fe0+dmx0+ca0 and a second instance of mplayer to watch or record another
channel with fe1+dmx1+ca0. You won't know which device has an event if
you use poll. The API even allows mixing multiple CI slots and built-in
descramblers in the same node. But try calling CA_RESET on a specific
slot or on a descrambler. It won't work. It's broken by design.

Do you know any implementation that has more than one CI slot per ca
device and that really is in use?

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> 
> I don't think this is going to happen, as nobody really seems to care
> (me included). I was just pointing out ways that I consider more likely
> to succeed.
> 
> Regards,
> Andreas


If you don't care, why fueling all this fuss ???

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> >> Last but not least, using a different adapter number wouldn't fit
> >> either, because a DVB adapter is supposed to
> >> - be one independent piece of hardware
> >> - provide at least a frontend and a demux device
> > 
> > 
> > How would you support device like the Hauppauge WinTV-CI ? This one comes
on a
> > USB port and does not provide any frontend and demux device.
> 
> Yes, as an exception, this device indeed wouldn't have a frontend,
> because it doesn't exist physycally.
> 
> It wouldn't have multiple adapters numbers either.


What do you mean by they shouldn't have mulitple adapters numbers ? Multiple
WinTV-CI devices should have distinct node parents, ie
/dev/dvb/adapter[01]/<node>



> > With the transmitted keys changed frequently (at least for viaccess),
what's
> > the point in supporting offline descrambling when it will not work
reliably
> > for all ?
> 
> The reliability of offline descrambling depends on the network operators
> policy. So while it won't be useful for everybody in the world, it might
> well be useful to all customers of certain operators.
> 
> > As for descrambling multiple tv channels from different transponders with
only
> > one cam, this is already possible. An example is what Digital Devices
calls
> > MTD (Multi Transponder Decrypting). But this is CAM dependent, some do
not
> > support it.
> 
> What's the point if it doesn't work reliably for everybody? ;-)


Well, isn't it easier to change a CAM than an operator ? For many of us in
France/Belgium, you might even have no choice at all for the operator.


> >> Why don't you just create a new device, e.g. ciX, deprecate the use of
> >> caX for CI devices, inherit CI-related existing ioctls from the CA API,
> >> translate the existing read and write funtions to ioctls and then use
> >> read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
> >> pretty sure this can be done without too much code and in a backwards
> >> compatible way.
> > 
> > 
> > I'm open to this idea, but is there a consensus on this big API change ?
> > (deprecating ca device) If yes, I will try to prepare something.
> 
> The existing API could be copied to linux/dvb/ci.h and then simplified
> and reviewed.
> 

As I said, if you can create a consensus behind your idea, then I will try to
prepare something.

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/04/2011 04:05 PM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>> It wouldn't have multiple adapters numbers either.
> 
> What do you mean by they shouldn't have mulitple adapters numbers ? Multiple
> WinTV-CI devices should have distinct node parents, ie
> /dev/dvb/adapter[01]/<node>

I wrote "wouldn't", not "shouldn't". I'm fine with it.

>>> With the transmitted keys changed frequently (at least for viaccess),
> what's
>>> the point in supporting offline descrambling when it will not work
> reliably
>>> for all ?
>>
>> The reliability of offline descrambling depends on the network operators
>> policy. So while it won't be useful for everybody in the world, it might
>> well be useful to all customers of certain operators.
>>
>>> As for descrambling multiple tv channels from different transponders with
> only
>>> one cam, this is already possible. An example is what Digital Devices
> calls
>>> MTD (Multi Transponder Decrypting). But this is CAM dependent, some do
> not
>>> support it.
>>
>> What's the point if it doesn't work reliably for everybody? ;-)
> 
> 
> Well, isn't it easier to change a CAM than an operator ? For many of us in
> France/Belgium, you might even have no choice at all for the operator.

Again it depends on the operator, whether getting a working CAM at all
is possible, putting aside that there's no guarantee that it would work
with "MTD". But I really don't mind. See the smiley. I was just
referring to your similar question. I wasn't going to tell that foo was
better than or even related to bar, but just that foo is a good feature
for many people. I also consider bar a good feature.

>>>> Why don't you just create a new device, e.g. ciX, deprecate the use of
>>>> caX for CI devices, inherit CI-related existing ioctls from the CA API,
>>>> translate the existing read and write funtions to ioctls and then use
>>>> read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
>>>> pretty sure this can be done without too much code and in a backwards
>>>> compatible way.
>>>
>>>
>>> I'm open to this idea, but is there a consensus on this big API change ?
>>> (deprecating ca device) If yes, I will try to prepare something.
>>
>> The existing API could be copied to linux/dvb/ci.h and then simplified
>> and reviewed.
>>
> 
> As I said, if you can create a consensus behind your idea, then I will try to
> prepare something.

I don't think this is going to happen, as nobody really seems to care
(me included). I was just pointing out ways that I consider more likely
to succeed.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Mauro Carvalho Chehab <mchehab@redhat.com>
> 
> It is not that simple. The question is not just how to name the interface, 
> but that such interface will work on a different way than the current 
> ca interface.
> 
> In other words, the DVB API should clearly explain why this
> interface is different, when it should be used and how.
> 
> Cheers,
> Mauro.
> 

Ok, please give me the location of the DVB API. Could not find it under the
linux/Documentation folder.

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> 
> Of course I'm referring to devices connected to the same physical
> adapter. Otherwise they would all be called ca0. Device enumeration
> always starts at 0, for each adapter. What you're describing just
> doesn't make sense.


Yes indeed you're right, I answered too quickly.


> Last but not least, using a different adapter number wouldn't fit
> either, because a DVB adapter is supposed to
> - be one independent piece of hardware
> - provide at least a frontend and a demux device


How would you support device like the Hauppauge WinTV-CI ? This one comes on a
USB port and does not provide any frontend and demux device.


> 
> At least on embedded devices, it simply isn't feasible to copy a TS to
> userspace from a demux, just to copy it back to the kernel and again
> back to userspace through a caio device, when live streaming. But you
> may want to provide a way to use the caio device for
> offline-descrambling. Unless you want to force users to buy multiple
> modules and multiple subscriptions for a single receiver, which in turn
> would need multiple CI slots, you need a way to make sure caio can not
> be used during live streaming. If this dependency is between different
> adapters, then something is really, really wrong.


With the transmitted keys changed frequently (at least for viaccess), what's
the point in supporting offline descrambling when it will not work reliably
for all ?

As for descrambling multiple tv channels from different transponders with only
one cam, this is already possible. An example is what Digital Devices calls
MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not
support it.

Question is, where does this belong ? kernel or userspace ?


> 
> Why don't you just create a new device, e.g. ciX, deprecate the use of
> caX for CI devices, inherit CI-related existing ioctls from the CA API,
> translate the existing read and write funtions to ioctls and then use
> read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
> pretty sure this can be done without too much code and in a backwards
> compatible way.


I'm open to this idea, but is there a consensus on this big API change ?
(deprecating ca device) If yes, I will try to prepare something.

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/04/2011 01:07 PM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>>
>> Of course I'm referring to devices connected to the same physical
>> adapter. Otherwise they would all be called ca0. Device enumeration
>> always starts at 0, for each adapter. What you're describing just
>> doesn't make sense.
> 
> 
> Yes indeed you're right, I answered too quickly.
> 
> 
>> Last but not least, using a different adapter number wouldn't fit
>> either, because a DVB adapter is supposed to
>> - be one independent piece of hardware
>> - provide at least a frontend and a demux device
> 
> 
> How would you support device like the Hauppauge WinTV-CI ? This one comes on a
> USB port and does not provide any frontend and demux device.

Yes, as an exception, this device indeed wouldn't have a frontend,
because it doesn't exist physycally.

It wouldn't have multiple adapters numbers either.

>> At least on embedded devices, it simply isn't feasible to copy a TS to
>> userspace from a demux, just to copy it back to the kernel and again
>> back to userspace through a caio device, when live streaming. But you
>> may want to provide a way to use the caio device for
>> offline-descrambling. Unless you want to force users to buy multiple
>> modules and multiple subscriptions for a single receiver, which in turn
>> would need multiple CI slots, you need a way to make sure caio can not
>> be used during live streaming. If this dependency is between different
>> adapters, then something is really, really wrong.
> 
> 
> With the transmitted keys changed frequently (at least for viaccess), what's
> the point in supporting offline descrambling when it will not work reliably
> for all ?

The reliability of offline descrambling depends on the network operators
policy. So while it won't be useful for everybody in the world, it might
well be useful to all customers of certain operators.

> As for descrambling multiple tv channels from different transponders with only
> one cam, this is already possible. An example is what Digital Devices calls
> MTD (Multi Transponder Decrypting). But this is CAM dependent, some do not
> support it.

What's the point if it doesn't work reliably for everybody? ;-)

> Question is, where does this belong ? kernel or userspace ?

I guess it depends on whether the remultiplexing takes place in hardware
or software (remapping of PIDs and generation of the joined SI data).

>> Why don't you just create a new device, e.g. ciX, deprecate the use of
>> caX for CI devices, inherit CI-related existing ioctls from the CA API,
>> translate the existing read and write funtions to ioctls and then use
>> read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
>> pretty sure this can be done without too much code and in a backwards
>> compatible way.
> 
> 
> I'm open to this idea, but is there a consensus on this big API change ?
> (deprecating ca device) If yes, I will try to prepare something.

The existing API could be copied to linux/dvb/ci.h and then simplified
and reviewed.

- There's no need for a slot number. Just assign a device node to every
CI slot.
- CA_CI_PHYS is unused.
- ci.h doesn't need CA_DESCR, CA_SC, ca_descr_info_t, ca_caps_t,
ca_descr_t, ca_pid_t and accompanying ioctls.
- ca_slot_info.type should be an enum instead of a bitmask.
- ca_msg.index and ca_msg.type are probably unused
- Instead of a fixed length array, ca_msg.msg might as well just be a
pointer to a user allocated buffer
- Then, CA_GET_MSG should use _IOWR, because the maximum length must be
read inside the kernel.

Btw., does the av7110 really support two distinct CI slots?

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> Also, there's still no mapping between ca and caio devices. Imagine a
> built-in descrambler ca0 and two CI slots ca1 and ca2.
> 
> ca0 won't get a caio device, at least for now.
> ca1 and ca2 might or might not have a caio device.
> 
> If there is caio0, how am I supposed to know that it's related to ca1 or
> ca2 (or ca0, if someone implements a caio device to bypass the software
> demux to use a built-in descrambler)? You must not assume that there are
> either none or two (or three) caio interfaces. You need to be able to
> detect (or set up) the connection between the interfaces. Otherwise this
> "API" will be a mess.
> 
> Regards,
> Andreas


To my understanding, in such a described case, 

- ca0 would be reached from /dev/dvb/adapter0/ca0
- ca[12], depending on if they are connected to the same physical adapter
(PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
/dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio
devices.

- If the 3 ca devices are on the same adapter, then the driver writer should
take care of the order of the mapping so that ca1 always map caio1 and
ca2/caio2, ...; and if this is not feasable, then the driver writer should
span the ca/caio devices on different /dev/dvb/adapter folders.

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/04/2011 10:27 AM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>> Also, there's still no mapping between ca and caio devices. Imagine a
>> built-in descrambler ca0 and two CI slots ca1 and ca2.
>>
>> ca0 won't get a caio device, at least for now.
>> ca1 and ca2 might or might not have a caio device.
>>
>> If there is caio0, how am I supposed to know that it's related to ca1 or
>> ca2 (or ca0, if someone implements a caio device to bypass the software
>> demux to use a built-in descrambler)? You must not assume that there are
>> either none or two (or three) caio interfaces. You need to be able to
>> detect (or set up) the connection between the interfaces. Otherwise this
>> "API" will be a mess.
>>
>> Regards,
>> Andreas
> 
> 
> To my understanding, in such a described case, 
> 
> - ca0 would be reached from /dev/dvb/adapter0/ca0
> - ca[12], depending on if they are connected to the same physical adapter
> (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
> /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio
> devices.

Of course I'm referring to devices connected to the same physical
adapter. Otherwise they would all be called ca0. Device enumeration
always starts at 0, for each adapter. What you're describing just
doesn't make sense.

> - If the 3 ca devices are on the same adapter, then the driver writer should
> take care of the order of the mapping so that ca1 always map caio1 and
> ca2/caio2, ...; and if this is not feasable, then the driver writer should
> span the ca/caio devices on different /dev/dvb/adapter folders.

You can't create caio1 without creating caio0 first. Of course, you
could require driver writers to register those ca devices first that
have caio devices. But that conflicts with other policies the driver
author might already have chosen, e.g. to map the ca (descrambler)
device numbers to demux and dvr numbers, which seems way more intuitive
to me, because demux hardware usually comes with built-in descramblers.

It's ugly to force random policies on drivers. Please create a proper
interface instead!

Last but not least, using a different adapter number wouldn't fit
either, because a DVB adapter is supposed to
- be one independent piece of hardware
- provide at least a frontend and a demux device

At least on embedded devices, it simply isn't feasible to copy a TS to
userspace from a demux, just to copy it back to the kernel and again
back to userspace through a caio device, when live streaming. But you
may want to provide a way to use the caio device for
offline-descrambling. Unless you want to force users to buy multiple
modules and multiple subscriptions for a single receiver, which in turn
would need multiple CI slots, you need a way to make sure caio can not
be used during live streaming. If this dependency is between different
adapters, then something is really, really wrong.

Why don't you just create a new device, e.g. ciX, deprecate the use of
caX for CI devices, inherit CI-related existing ioctls from the CA API,
translate the existing read and write funtions to ioctls and then use
read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
pretty sure this can be done without too much code and in a backwards
compatible way.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Andreas Oberritter writes:
 > > - ca0 would be reached from /dev/dvb/adapter0/ca0
 > > - ca[12], depending on if they are connected to the same physical adapter
 > > (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
 > > /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio
 > > devices.
 > 
 > Of course I'm referring to devices connected to the same physical
 > adapter. Otherwise they would all be called ca0. Device enumeration
 > always starts at 0, for each adapter. What you're describing just
 > doesn't make sense.

Of course it does since it is not feasible to use the same adapter
number even on the same card when it provides multi-standard 
frontends which share dvr and demux devices. E.g., frontend0 and
frontend1 can belong to the same demod which can be DVB-C and -T 
(or other combinations, some demods can even do DVB-C/T/S2). 

frontend0 and frontend1 could then be DVB-C/T of demod 0
frontend2 and frontend3 would be DVB-C/T of demod 1.
frontend4 might be a DVB-S frontend of demod 2, frontend5 DVB-S of
demod 3. How do I know then which frontends belong to the 
4 demux/dvr devices? 
Or is there a standard way this is supposed to be handled?

There are no mechanism to connect a frontend with specific dvr or
demux devices in the current API. But you demand it for the caio device.

 
 > > - If the 3 ca devices are on the same adapter, then the driver writer should
 > > take care of the order of the mapping so that ca1 always map caio1 and
 > > ca2/caio2, ...; and if this is not feasable, then the driver writer should
 > > span the ca/caio devices on different /dev/dvb/adapter folders.
 > 
 > You can't create caio1 without creating caio0 first. Of course, you
 > could require driver writers to register those ca devices first that
 > have caio devices. But that conflicts with other policies the driver
 > author might already have chosen, e.g. to map the ca (descrambler)
 > device numbers to demux and dvr numbers, which seems way more intuitive
 > to me, because demux hardware usually comes with built-in descramblers.

A ca/caio pair is completely independent by design and should not get mixed with
other devices.

 > 
 > It's ugly to force random policies on drivers. Please create a proper
 > interface instead!
 > 

Then the whole API should first get proper interfaces. See above.


 > Last but not least, using a different adapter number wouldn't fit
 > either, because a DVB adapter is supposed to
 > - be one independent piece of hardware
 > - provide at least a frontend and a demux device

If you only plug in CI adapter modules in the octopus cards there are
no frontend and demux devices.
So, should we invent frontend and demux devices so that we are allowed
to use the DVB API? 
Or should we create a new independent API for this? 
Even if we copy 99% of the existing ca API?

 > At least on embedded devices, it simply isn't feasible to copy a TS to
 > userspace from a demux, just to copy it back to the kernel and again
 > back to userspace through a caio device, when live streaming.

Then do not use it on embedded devices. 
But this is how this hardware works and APIs will not change the hardware.

 >  But you
 > may want to provide a way to use the caio device for
 > offline-descrambling. Unless you want to force users to buy multiple
 > modules and multiple subscriptions for a single receiver, which in turn
 > would need multiple CI slots, you need a way to make sure caio can not
 > be used during live streaming. If this dependency is between different
 > adapters, then something is really, really wrong.

What dependency are you talking about?


 > 
 > Why don't you just create a new device, e.g. ciX, deprecate the use of
 > caX for CI devices, inherit CI-related existing ioctls from the CA API,
 > translate the existing read and write funtions to ioctls and then use
 > read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
 > pretty sure this can be done without too much code and in a backwards
 > compatible way.


This would require changing all en50221 related user space code. I
only mentioned it would have been nice to have it this way from the
beginning. Now it would be too late since one usually gets loud 
screaming from everywhere if user space API changes
(not extensions) are even thought about.


-Ralph

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/04/2011 01:20 PM, Ralph Metzler wrote:
> Andreas Oberritter writes:
>  > > - ca0 would be reached from /dev/dvb/adapter0/ca0
>  > > - ca[12], depending on if they are connected to the same physical adapter
>  > > (PCI, USB, ...), would be reached from /dev/dvb/adapter1/ca[12] or
>  > > /dev/dvb/adapter1/ca1 and /dev/dvb/adapter2/ca2 and there respective caio
>  > > devices.
>  > 
>  > Of course I'm referring to devices connected to the same physical
>  > adapter. Otherwise they would all be called ca0. Device enumeration
>  > always starts at 0, for each adapter. What you're describing just
>  > doesn't make sense.
> 
> Of course it does since it is not feasible to use the same adapter
> number even on the same card when it provides multi-standard 
> frontends which share dvr and demux devices. E.g., frontend0 and
> frontend1 can belong to the same demod which can be DVB-C and -T 
> (or other combinations, some demods can even do DVB-C/T/S2). 

There's absolutely no need to have more than one frontend device per
demod. Just add two commands, one to query the possible delivery systems
and one to switch the system. Why would you need more than one device
node at all, if you can only use one delivery system at a time?

> frontend0 and frontend1 could then be DVB-C/T of demod 0
> frontend2 and frontend3 would be DVB-C/T of demod 1.
> frontend4 might be a DVB-S frontend of demod 2, frontend5 DVB-S of
> demod 3. How do I know then which frontends belong to the 
> 4 demux/dvr devices? 

By configuration.

> Or is there a standard way this is supposed to be handled?

Yes. Since ages. The ioctl is called DMX_SET_SOURCE.

> There are no mechanism to connect a frontend with specific dvr or
> demux devices in the current API. But you demand it for the caio device.

See above.

>  > > - If the 3 ca devices are on the same adapter, then the driver writer should
>  > > take care of the order of the mapping so that ca1 always map caio1 and
>  > > ca2/caio2, ...; and if this is not feasable, then the driver writer should
>  > > span the ca/caio devices on different /dev/dvb/adapter folders.
>  > 
>  > You can't create caio1 without creating caio0 first. Of course, you
>  > could require driver writers to register those ca devices first that
>  > have caio devices. But that conflicts with other policies the driver
>  > author might already have chosen, e.g. to map the ca (descrambler)
>  > device numbers to demux and dvr numbers, which seems way more intuitive
>  > to me, because demux hardware usually comes with built-in descramblers.
> 
> A ca/caio pair is completely independent by design and should not get mixed with
> other devices.

I guess you're right, but I'm questioning your design.

>  > 
>  > It's ugly to force random policies on drivers. Please create a proper
>  > interface instead!
>  > 
> 
> Then the whole API should first get proper interfaces. See above.

Already done. See above.

>  > Last but not least, using a different adapter number wouldn't fit
>  > either, because a DVB adapter is supposed to
>  > - be one independent piece of hardware
>  > - provide at least a frontend and a demux device
> 
> If you only plug in CI adapter modules in the octopus cards there are
> no frontend and demux devices.
> So, should we invent frontend and demux devices so that we are allowed
> to use the DVB API? 

Of course, you shouldn't invent fake frontends. But, if you decide to
plug a frontend into your octopus card later on, then the frontend
device should appear under the same adapter number. Right?

If the demux is hardware-based, then of course the device should be
present, even if no frontend is connected. If it's software-based, it's
probably a matter of choice.

> Or should we create a new independent API for this? 
> Even if we copy 99% of the existing ca API?

I already proposed an API that would integrate nicely into the status quo.

>  > At least on embedded devices, it simply isn't feasible to copy a TS to
>  > userspace from a demux, just to copy it back to the kernel and again
>  > back to userspace through a caio device, when live streaming.
> 
> Then do not use it on embedded devices. 
> But this is how this hardware works and APIs will not change the hardware.

In a similar way, I could propose to not use vanilla kernels, if you
don't want to come up with a good API.

Anyway, my point was that there must be some kind of resource management
between the data path used in live streaming applications (i.e. in
kernel space) and the data path used for offline-descrambling (i.e. your
caio device through userspace). How do you intend to implement resource
management between multiple adapters? If a device appears to be
independent of another device, because it has a different adapter
number, then this device must not interfere with devices of other adapters.

Maybe the Ngene CAM really is independent and can't be used without all
the copying, but we're talking about the introduction of a new API here,
and I hope that this API won't just work with this one device.

>  >  But you
>  > may want to provide a way to use the caio device for
>  > offline-descrambling. Unless you want to force users to buy multiple
>  > modules and multiple subscriptions for a single receiver, which in turn
>  > would need multiple CI slots, you need a way to make sure caio can not
>  > be used during live streaming. If this dependency is between different
>  > adapters, then something is really, really wrong.
> 
> What dependency are you talking about?

Locking between adapters. See above.

>  > 
>  > Why don't you just create a new device, e.g. ciX, deprecate the use of
>  > caX for CI devices, inherit CI-related existing ioctls from the CA API,
>  > translate the existing read and write funtions to ioctls and then use
>  > read and write for TS I/O? IIRC, Ralph suggested something similar. I'm
>  > pretty sure this can be done without too much code and in a backwards
>  > compatible way.
> 
> 
> This would require changing all en50221 related user space code. I
> only mentioned it would have been nice to have it this way from the
> beginning. Now it would be too late since one usually gets loud 
> screaming from everywhere if user space API changes
> (not extensions) are even thought about.

Read again: backwards compatible. That implies no change to existing APIs.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Andreas Oberritter writes:
 > > Of course it does since it is not feasible to use the same adapter
 > > number even on the same card when it provides multi-standard 
 > > frontends which share dvr and demux devices. E.g., frontend0 and
 > > frontend1 can belong to the same demod which can be DVB-C and -T 
 > > (or other combinations, some demods can even do DVB-C/T/S2). 
 > 
 > There's absolutely no need to have more than one frontend device per
 > demod. Just add two commands, one to query the possible delivery systems
 > and one to switch the system. Why would you need more than one device
 > node at all, if you can only use one delivery system at a time?


Maybe because there is no proper documentation for this.


 > > Or is there a standard way this is supposed to be handled?
 > 
 > Yes. Since ages. The ioctl is called DMX_SET_SOURCE.

This does make no sense regarding my question.


 > > There are no mechanism to connect a frontend with specific dvr or
 > > demux devices in the current API. But you demand it for the caio device.
 > 
 > See above.

Ok, wrong formulation. There is no API to indicate which can connect
to which.


 > > A ca/caio pair is completely independent by design and should not get mixed with
 > > other devices.
 > 
 > I guess you're right, but I'm questioning your design.


How else can an independent CI interface be designed?
And this is how the hardware is. I cannot change this in software.

 > >  > It's ugly to force random policies on drivers. Please create a proper
 > >  > interface instead!
 > >  > 
 > > 
 > > Then the whole API should first get proper interfaces. See above.
 > 
 > Already done. See above.

And no proper documentation.


 > Of course, you shouldn't invent fake frontends. But, if you decide to
 > plug a frontend into your octopus card later on, then the frontend
 > device should appear under the same adapter number. Right?

No, it does not right now.

 
 > >  > At least on embedded devices, it simply isn't feasible to copy a TS to
 > >  > userspace from a demux, just to copy it back to the kernel and again
 > >  > back to userspace through a caio device, when live streaming.
 > > 
 > > Then do not use it on embedded devices. 
 > > But this is how this hardware works and APIs will not change the hardware.
 > 
 > In a similar way, I could propose to not use vanilla kernels, if you
 > don't want to come up with a good API.

Why? The driver works fine on top of vanilla kernels.

I do not really care if the driver itself gets into the kernel anymore.

 
-Ralph

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

> 
>> Or is there a standard way this is supposed to be handled?
> 
> Yes. Since ages. The ioctl is called DMX_SET_SOURCE.

DMX_SET_SOURCE seems to not be implemented anywhere, all it does is 
return EINVAL. I also fail to find any useful documentation about what 
it is supposed to do.

> 
>> There are no mechanism to connect a frontend with specific dvr or
>> demux devices in the current API. But you demand it for the caio device.
> 

I think there is currently no useful API to connect devices. Every few 
months there comes a new device which deprecates how I enumerate devices 
and determine types of FE's.

The most useful way to query devices seems to be using HAL, and I think 
this is the correct way in Linux, but DVB-API may be lacking with 
providing the necessary information. Maybe this is the direction we 
should consider? Device names under /dev seem to be irrelevant nowadays.

Best regards,
Martin Vidovic

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/04/2011 03:35 PM, Martin Vidovic wrote:
>>
>>> Or is there a standard way this is supposed to be handled?
>>
>> Yes. Since ages. The ioctl is called DMX_SET_SOURCE.
> 
> DMX_SET_SOURCE seems to not be implemented anywhere, all it does is
> return EINVAL. I also fail to find any useful documentation about what
> it is supposed to do.

It is supposed to connect the TS output of frontend X to the TS input of
demux Y. Whether you need to manually connect anything depends on your
application and hardware environment. It's not required at all when
using the software demux, which is what almost all in-tree drivers do.

>>> There are no mechanism to connect a frontend with specific dvr or
>>> demux devices in the current API. But you demand it for the caio device.
>>
> 
> I think there is currently no useful API to connect devices. Every few
> months there comes a new device which deprecates how I enumerate devices
> and determine types of FE's.

Can you describe the most common problems? What do you mean by connecting?

> The most useful way to query devices seems to be using HAL, and I think
> this is the correct way in Linux, but DVB-API may be lacking with
> providing the necessary information. Maybe this is the direction we
> should consider? Device names under /dev seem to be irrelevant nowadays.

I think in the long run we should look closely at how V4L2 is solving
similar problems.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Hi,

Broadly speaking, I could put issues discussed in this thread into 
following categories:

- How devices are named;
- How devices are used;
- How devices relate to one another;
- How devices are enumerated;
- How devices are described;

Mostly we discuss category 1 and 2 with relation to nGENE CI, but 
sometimes we leap to other categories as well.

Andreas Oberritter wrote:
> On 05/04/2011 03:35 PM, Martin Vidovic wrote:
 >>
>> I think there is currently no useful API to connect devices. Every few
>> months there comes a new device which deprecates how I enumerate devices
>> and determine types of FE's.
> 
> Can you describe the most common problems? What do you mean by connecting?

What I mean by connecting devices falls into last 3 categories (above). 
I brought this up because I don't believe this is the actual problem we 
need to solve here since it's not nGENE specific.

Some examples of problems in categories 3-5:

a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between them.

b) Take a Hybrid terrestrial TV tuner. V4L and DVB APIs (may) use shared 
resources, how does one find this out?

c.1) How does one know which frontend device can be used with which 
demux device?

c.2) Which CA device can be used with which frontend device?

d) How does one list all supported delivery systems for a device 
(FE_GET_INFO is not general, and DTV_DELIVERY_SYSTEM can't be used to 
query available delivery systems).

e) the list could be extended...

These problems are mostly not fatal, they have workarounds. Some of them 
require device/driver specific knowledge.

>> The most useful way to query devices seems to be using HAL, and I think
>> this is the correct way in Linux, but DVB-API may be lacking with
>> providing the necessary information. Maybe this is the direction we
>> should consider? Device names under /dev seem to be irrelevant nowadays.
> 
> I think in the long run we should look closely at how V4L2 is solving
> similar problems.

The best would be to create independent adapters for each independent CA 
device (ca0/caio0 pair) - they are independent after all (physically and 
in the way they're used).

What I understand you would like to see, is the ability to do direct 
transfers between independent devices or parts of devices. Is this correct?

Best regards,
Martin Vidovic

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/05/2011 04:43 PM, Martin Vidovic wrote:
> Hi,
> 
> Broadly speaking, I could put issues discussed in this thread into
> following categories:
> 
> - How devices are named;
> - How devices are used;
> - How devices relate to one another;
> - How devices are enumerated;
> - How devices are described;
> 
> Mostly we discuss category 1 and 2 with relation to nGENE CI, but
> sometimes we leap to other categories as well.
> 
> Andreas Oberritter wrote:
>> On 05/04/2011 03:35 PM, Martin Vidovic wrote:
>>>
>>> I think there is currently no useful API to connect devices. Every few
>>> months there comes a new device which deprecates how I enumerate devices
>>> and determine types of FE's.
>>
>> Can you describe the most common problems? What do you mean by
>> connecting?
> 
> What I mean by connecting devices falls into last 3 categories (above).
> I brought this up because I don't believe this is the actual problem we
> need to solve here since it's not nGENE specific.
> 
> Some examples of problems in categories 3-5:
> 
> a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between them.

I don't have any USB or PCI hardware within reach, but if udev is able
to create the devices, there should be some way to connect adapters to
the bus id through sysfs. I guess that's how it's done with other
subsystems, too.

If this information is missing from sysfs, would adding it help to solve
this problem?

> b) Take a Hybrid terrestrial TV tuner. V4L and DVB APIs (may) use shared
> resources, how does one find this out?

That's a good question and the same question must be asked for video and
audio decoders, which can be controlled by V4L, DVB, ALSA etc.

How does V4L integrate with ALSA?

> c.1) How does one know which frontend device can be used with which
> demux device?

I'd say by default (i.e. without DMX_SET_SOURCE, whether implemented or
not) frontendX is connected to demuxX on the same adapter. You have
probably faced other situations. Can you describe any?

> c.2) Which CA device can be used with which frontend device?

For built-in descramblers, I'd say each caX is always connected to
(built into) demuxX.

For CI slots, this might be different and on the Dreambox we're using a
proprietary API to connect CI slots between frontends and demuxes.

Is there any in-tree supported hardware, that has more than one CI slot
*and* more than one frontend (usable at the same time)?

I agree that an API would be nice to query and set up such things, but I
had expected that the need for it was rather low for non-embedded systems.

> d) How does one list all supported delivery systems for a device
> (FE_GET_INFO is not general, and DTV_DELIVERY_SYSTEM can't be used to
> query available delivery systems).

How about this proposal?

http://www.mail-archive.com/linux-media@vger.kernel.org/msg31124.html

> e) the list could be extended...
> 
> These problems are mostly not fatal, they have workarounds. Some of them
> require device/driver specific knowledge.
> 
>>> The most useful way to query devices seems to be using HAL, and I think
>>> this is the correct way in Linux, but DVB-API may be lacking with
>>> providing the necessary information. Maybe this is the direction we
>>> should consider? Device names under /dev seem to be irrelevant nowadays.
>>
>> I think in the long run we should look closely at how V4L2 is solving
>> similar problems.
> 
> The best would be to create independent adapters for each independent CA
> device (ca0/caio0 pair) - they are independent after all (physically and
> in the way they're used).

Physically, it's a general purpose TS I/O interface of the nGene
chipset. It just happens to be connected to a CI slot. On another board,
it might be connected to a modulator or just to some kind of socket.

If the next version gets a connector for two switchable CI modules, then
the physical independence is gone. You'd have two ca nodes but only one
caio node. Or two caio nodes, that can't be used concurrently.

Maybe the next version gets the ability to directly connect the TS input
from the frontend to the TS output to the CI slot to save copying around
the data, by using some kind of pin mux. Not physically independent either.

It just looks physically independent in the one configuration
implemented now.

> What I understand you would like to see, is the ability to do direct
> transfers between independent devices or parts of devices. Is this correct?

Yes, between parts of devices, where the CI input can be fed by both the
TS output of the frontend and from memory (e.g. userspace).

Although it would be nice to have DMA transfers between independent
devices, that's a different topic.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Walter Van Eetvelt]

Hi, 

On Fri, 06 May 2011 14:17:11 +0200, Andreas Oberritter <obi@linuxtv.org>
wrote:
> On 05/05/2011 04:43 PM, Martin Vidovic wrote:
>> Hi,
>> 
>> Broadly speaking, I could put issues discussed in this thread into
>> following categories:
>> 
>> - How devices are named;
>> - How devices are used;
>> - How devices relate to one another;
>> - How devices are enumerated;
>> - How devices are described;
>> 
>> Mostly we discuss category 1 and 2 with relation to nGENE CI, but
>> sometimes we leap to other categories as well.
>> 

I must say I really like this discussion so far.  But for me to keep
focus: Can someone list different options for
naming/using/relating/enumerating/describing devices in relation to
(multiple?ngene?) CI's.  
Or does that information already exist?

Walter

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Andreas Oberritter wrote:
> On 05/05/2011 04:43 PM, Martin Vidovic wrote:
>> 
>> a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between them.
> 
> I don't have any USB or PCI hardware within reach, but if udev is able
> to create the devices, there should be some way to connect adapters to
> the bus id through sysfs. I guess that's how it's done with other
> subsystems, too.
> 
> If this information is missing from sysfs, would adding it help to solve
> this problem?
> 

Binding to bus id is not a problem. However, especially for USB devices,
it may be useful to have adapter MAC address in sysfs.

>> b) Take a Hybrid terrestrial TV tuner. V4L and DVB APIs (may) use shared
>> resources, how does one find this out?
> 
> That's a good question and the same question must be asked for video and
> audio decoders, which can be controlled by V4L, DVB, ALSA etc.
> 
> How does V4L integrate with ALSA?
> 

I don't know.

>> c.1) How does one know which frontend device can be used with which
>> demux device?
> 
> I'd say by default (i.e. without DMX_SET_SOURCE, whether implemented or
> not) frontendX is connected to demuxX on the same adapter. You have
> probably faced other situations. Can you describe any?
> 

I thought we were discussing how to connect frontendX to demuxY on
different adapters, since this would be needed for nGene CI.

>> c.2) Which CA device can be used with which frontend device?
> 
> For built-in descramblers, I'd say each caX is always connected to
> (built into) demuxX.
> 
> For CI slots, this might be different and on the Dreambox we're using a
> proprietary API to connect CI slots between frontends and demuxes.
> 
> Is there any in-tree supported hardware, that has more than one CI slot
> *and* more than one frontend (usable at the same time)?
> 

NetUP Dual DVB S2 CI

>> 
>> The best would be to create independent adapters for each independent CA
>> device (ca0/caio0 pair) - they are independent after all (physically and
>> in the way they're used).
> 
> Physically, it's a general purpose TS I/O interface of the nGene
> chipset. It just happens to be connected to a CI slot. On another board,
> it might be connected to a modulator or just to some kind of socket.
> 

I agree, but I look at it like at any other general purpose interface
(e.g. USB, PCI).

Maybe nGene is not a good case for such analysis, but there is other
hardware which would hit this problem again.

I'm aware of two such examples:

1) Hauppauge WinTV-CI (USB attached CI - I think Issa mentioned this one 
already);
2) DigitalDevices Octopus (PCI bridge with 4 general purpose ports - Ralph
mentioned this one and I'm using these cards myself);

> If the next version gets a connector for two switchable CI modules, then
> the physical independence is gone. You'd have two ca nodes but only one
> caio node. Or two caio nodes, that can't be used concurrently.
> 

What is a switchable CI module?

> Maybe the next version gets the ability to directly connect the TS input
> from the frontend to the TS output to the CI slot to save copying around
> the data, by using some kind of pin mux. Not physically independent either.
> 

When this feature would be in action, opening caioX could return EBUSY and 
vice versa. This sounds similar to V4L <-> DVB interaction for hybrid
devices. API can't change the fact a resource is shared.

> It just looks physically independent in the one configuration
> implemented now.
> 

I don't believe it's an accident how nGene cards interface with CI. To
me it rather looks like a very good feature.

Imagine a use case like this:

There's a machine with:
- DigitalDevices CineS2
- CI-Module attached to CineS2;
- TechniSat SkyStar2 (has no CI);

A user wants to stream two DVB-S2 transponders using CineS2. They are
both clear, so CI-Module is not needed.

At the same time, the user wants to stream one DVB-S transponder but it is
scrambled. Since CI-Module attached to CineS2 is not in use, it can be made 
to work with SkyStar2 using a few lines of code in user space.

>> What I understand you would like to see, is the ability to do direct
>> transfers between independent devices or parts of devices. Is this correct?
> 
> Yes, between parts of devices, where the CI input can be fed by both the
> TS output of the frontend and from memory (e.g. userspace).
> 

I don't know Demux API so well to be able to tell for sure, but it looks
like it could be used (with a few extensions) instead of caioX.

One benefit of using Demux API would probably be the ability to have PID
filtering (in software or hardware), I think you've mentioned this already.
It is also similar to the way on-board decoder can be used on full-featured
cards.

This way both cases (nGene and your configurable design) could be covered.

On the other hand, using Demux API for nGene looks like an overkill, and
switching of TS route in your case could be done in some other way.
Specific HW design related problems seem to be common to both approaches.

Nevertheless, Demux API approach looks cleaner. But on the other hand, it
hides the fact that CI can be used in this particular way (sysfs could
help).

I imagine there would still be a difference between the two cases:

- nGene (CineS2 with CI-Module)

Device nodes would be:

/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0

/dev/dvb/adapter1/frontend0
/dev/dvb/adapter1/demux0
/dev/dvb/adapter1/dvr0

/dev/dvb/adapter2/ca0
/dev/dvb/adapter2/demux0
/dev/dvb/adapter2/dvr0

- Configurable Design (dual card similar to NetUP)

Device nodes would be:

/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/ca0

/dev/dvb/adapter1/frontend0
/dev/dvb/adapter1/demux0
/dev/dvb/adapter1/dvr0
/dev/dvb/adapter1/ca0

What do you say about this difference?


Best regards,
Martin Vidovic

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

Hello Martin,

On 05/08/2011 12:05 PM, Martin Vidovic wrote:
> Andreas Oberritter wrote:
>> On 05/05/2011 04:43 PM, Martin Vidovic wrote:
>>>
>>> a) Plug two TerraTec Cinergy T RC MKII and try to distinguish between
>>> them.
>>
>> I don't have any USB or PCI hardware within reach, but if udev is able
>> to create the devices, there should be some way to connect adapters to
>> the bus id through sysfs. I guess that's how it's done with other
>> subsystems, too.
>>
>> If this information is missing from sysfs, would adding it help to solve
>> this problem?
>>
> 
> Binding to bus id is not a problem. However, especially for USB devices,
> it may be useful to have adapter MAC address in sysfs.

a DVB adapter isn't required to have a unique MAC address, but we could
add this attribute to sysfs, if present. I think it would be preferrable
to use information available from the bus, e.g. the USB serial number.
But in cases, where the serial number is unavailable (probably quite
often), the MAC address might be a good fallback. It won't be available
in every case though.

>>> b) Take a Hybrid terrestrial TV tuner. V4L and DVB APIs (may) use shared
>>> resources, how does one find this out?
>>
>> That's a good question and the same question must be asked for video and
>> audio decoders, which can be controlled by V4L, DVB, ALSA etc.
>>
>> How does V4L integrate with ALSA?
>>
> 
> I don't know.
> 
>>> c.1) How does one know which frontend device can be used with which
>>> demux device?
>>
>> I'd say by default (i.e. without DMX_SET_SOURCE, whether implemented or
>> not) frontendX is connected to demuxX on the same adapter. You have
>> probably faced other situations. Can you describe any?
>>
> 
> I thought we were discussing how to connect frontendX to demuxY on
> different adapters, since this would be needed for nGene CI.

Such connections between adapters are impossible, API-wise. Each adapter
is an independent circuit by definition.

>>> c.2) Which CA device can be used with which frontend device?
>>
>> For built-in descramblers, I'd say each caX is always connected to
>> (built into) demuxX.
>>
>> For CI slots, this might be different and on the Dreambox we're using a
>> proprietary API to connect CI slots between frontends and demuxes.
>>
>> Is there any in-tree supported hardware, that has more than one CI slot
>> *and* more than one frontend (usable at the same time)?
>>
> 
> NetUP Dual DVB S2 CI

Nice. Is it possible to assign a CI slot to a frontend by means of
software with this card? Or does it appear as two independent circuits
on one board?

>>>
>>> The best would be to create independent adapters for each independent CA
>>> device (ca0/caio0 pair) - they are independent after all (physically and
>>> in the way they're used).
>>
>> Physically, it's a general purpose TS I/O interface of the nGene
>> chipset. It just happens to be connected to a CI slot. On another board,
>> it might be connected to a modulator or just to some kind of socket.
>>
> 
> I agree, but I look at it like at any other general purpose interface
> (e.g. USB, PCI).
> 
> Maybe nGene is not a good case for such analysis, but there is other
> hardware which would hit this problem again.
> 
> I'm aware of two such examples:
> 
> 1) Hauppauge WinTV-CI (USB attached CI - I think Issa mentioned this one
> already);
> 2) DigitalDevices Octopus (PCI bridge with 4 general purpose ports - Ralph
> mentioned this one and I'm using these cards myself);
> 
>> If the next version gets a connector for two switchable CI modules, then
>> the physical independence is gone. You'd have two ca nodes but only one
>> caio node. Or two caio nodes, that can't be used concurrently.
>>
> 
> What is a switchable CI module?

Sorry, I meant two normal CI modules and the ability to switch between
them, i.e. to only use one of them at a time.

>> Maybe the next version gets the ability to directly connect the TS input
>> from the frontend to the TS output to the CI slot to save copying around
>> the data, by using some kind of pin mux. Not physically independent
>> either.
>>
> 
> When this feature would be in action, opening caioX could return EBUSY
> and vice versa. This sounds similar to V4L <-> DVB interaction for hybrid
> devices. API can't change the fact a resource is shared.

Indeed. However, what I was trying to explain with this example was,
that such a shared resource isn't physically independent and thus has to
appear under the same adapter number as the other parts of the circuit
it resides on.

>> It just looks physically independent in the one configuration
>> implemented now.
>>
> 
> I don't believe it's an accident how nGene cards interface with CI. To
> me it rather looks like a very good feature.
> 
> Imagine a use case like this:
> 
> There's a machine with:
> - DigitalDevices CineS2

(adapter0)

> - CI-Module attached to CineS2;

(adapter0/{ca0,caio0})

> - TechniSat SkyStar2 (has no CI);

(adapter1)

> A user wants to stream two DVB-S2 transponders using CineS2. They are
> both clear, so CI-Module is not needed.
> 
> At the same time, the user wants to stream one DVB-S transponder but it is
> scrambled. Since CI-Module attached to CineS2 is not in use, it can be
> made to work with SkyStar2 using a few lines of code in user space.

You're right, absolutely. This can of course still be done if ca0 and
caio0 reside on adapter0, even if adapter0 also contains frontends,
demuxes and stuff.

>>> What I understand you would like to see, is the ability to do direct
>>> transfers between independent devices or parts of devices. Is this
>>> correct?
>>
>> Yes, between parts of devices, where the CI input can be fed by both the
>> TS output of the frontend and from memory (e.g. userspace).
>>
> 
> I don't know Demux API so well to be able to tell for sure, but it looks
> like it could be used (with a few extensions) instead of caioX.
> 
> One benefit of using Demux API would probably be the ability to have PID
> filtering (in software or hardware), I think you've mentioned this already.
> It is also similar to the way on-board decoder can be used on full-featured
> cards.
> 
> This way both cases (nGene and your configurable design) could be covered.

I think so, too.

> On the other hand, using Demux API for nGene looks like an overkill, and
> switching of TS route in your case could be done in some other way.
> Specific HW design related problems seem to be common to both approaches.
> 
> Nevertheless, Demux API approach looks cleaner. But on the other hand, it
> hides the fact that CI can be used in this particular way (sysfs could
> help).

In most applications you'll want the PID filtering at the CI's output
anyway, so you can use the decrypted stream the same way you'd use it
without the CI. In other words, every physical TS input of the chipset
(in this case: nGene) should get its own demux interface, e.g. demux0
and demux1 for the frontends, demux2 for the CI.

Whatever we'll agree on, we should define an interface to query the
possible inputs and outputs of a demux, be it by means of sysfs or
ioctls. This would also be useful to find out which demux can be used
with DMX_OUT_DECODER for full-featured cards.

We can add DMX_OUT_CI, DMX_IN_CI, DMX_SOURCE_CI{0,1,2,3...} to the enums
in dmx.h. Ideally, in addition to that, I'd prefer dividing descramblers
and CIs into ca and ci device nodes, as proposed some days ago.

I think an ioctl to enable bypassing the PID filter when writing to the
CI would help to decrease the amount of overkill.

> I imagine there would still be a difference between the two cases:
> 
> - nGene (CineS2 with CI-Module)
> 
> Device nodes would be:
> 
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/dvr0
> 
> /dev/dvb/adapter1/frontend0
> /dev/dvb/adapter1/demux0
> /dev/dvb/adapter1/dvr0
> 
> /dev/dvb/adapter2/ca0
> /dev/dvb/adapter2/demux0
> /dev/dvb/adapter2/dvr0

IMO, this should be:

/dev/dvb/adapter0/ca0 (or better: ci0)
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/demux1
/dev/dvb/adapter0/demux2
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr1
/dev/dvb/adapter0/dvr2
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1

(assuming 3 TS inputs)

> - Configurable Design (dual card similar to NetUP)
> 
> Device nodes would be:
> 
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/ca0
> 
> /dev/dvb/adapter1/frontend0
> /dev/dvb/adapter1/demux0
> /dev/dvb/adapter1/dvr0
> /dev/dvb/adapter1/ca0

and

/dev/dvb/adapter0/ca0 (or better: ci0)
/dev/dvb/adapter0/ca1 (or better: ci1)
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/demux1
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr1
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1

(assuming 2 TS inputs and a way to map a CI to a frontend)

or your suggestion for NetUP, assuming fixed relations between CI slots
and frontends.

> What do you say about this difference?

Different capabilities result in different nodes. I don't see anything
special about it.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Hi Andreas,

Andreas Oberritter wrote:
> Hello Martin,
> 
>> 
>> Binding to bus id is not a problem. However, especially for USB devices,
>> it may be useful to have adapter MAC address in sysfs.
> 
> a DVB adapter isn't required to have a unique MAC address, but we could
> add this attribute to sysfs, if present. I think it would be preferrable
> to use information available from the bus, e.g. the USB serial number.
> But in cases, where the serial number is unavailable (probably quite
> often), the MAC address might be a good fallback. It won't be available
> in every case though.
> 

I'm aware MAC is not required. I used the TerraTec example because the
USB serial numbers are the same for both devices (maybe only in my case).
 
>>>> c.1) How does one know which frontend device can be used with which
>>>> demux device?
>>>
>>> I'd say by default (i.e. without DMX_SET_SOURCE, whether implemented or
>>> not) frontendX is connected to demuxX on the same adapter. You have
>>> probably faced other situations. Can you describe any?
>>>
>> 
>> I thought we were discussing how to connect frontendX to demuxY on
>> different adapters, since this would be needed for nGene CI.
> 
> Such connections between adapters are impossible, API-wise. Each adapter
> is an independent circuit by definition.
> 

I'm using a different definition of DVB adapter:

DVB adapter is a collection of related DVB device nodes which can be 
used independently from (without side effects for) other DVB device 
nodes in the system.

>> 
>> NetUP Dual DVB S2 CI
> 
> Nice. Is it possible to assign a CI slot to a frontend by means of
> software with this card? Or does it appear as two independent circuits
> on one board?
> 

The latter.

>>> If the next version gets a connector for two switchable CI modules, then
>>> the physical independence is gone. You'd have two ca nodes but only one
>>> caio node. Or two caio nodes, that can't be used concurrently.
>>>
>> 
>> What is a switchable CI module?
> 
> Sorry, I meant two normal CI modules and the ability to switch between
> them, i.e. to only use one of them at a time.
> 

It looks like an odd HW design, but it can make sense for certain use
cases. I think this would call for some different API extension, because
there's effectively only one CI bus, but the SW would need to be able
to bind a certain physical CI bus to this logical bus.

>>> Maybe the next version gets the ability to directly connect the TS input
>>> from the frontend to the TS output to the CI slot to save copying around
>>> the data, by using some kind of pin mux. Not physically independent
>>> either.
>>>
>> 
>> When this feature would be in action, opening caioX could return EBUSY
>> and vice versa. This sounds similar to V4L <-> DVB interaction for hybrid
>> devices. API can't change the fact a resource is shared.
> 
> Indeed. However, what I was trying to explain with this example was,
> that such a shared resource isn't physically independent and thus has to
> appear under the same adapter number as the other parts of the circuit
> it resides on.
> 

How about this device: TeVii S480

This board integrates a USB controller and two TeVii S660 devices on
a single PCIe card. Why would a driver be required to handle this
situation any differently than having two actual S660's attached to a 
USB controller sitting on PCI?

>>> It just looks physically independent in the one configuration
>>> implemented now.
>>>
>> 
>> I don't believe it's an accident how nGene cards interface with CI. To
>> me it rather looks like a very good feature.
>> 
>> Imagine a use case like this:
>> 
>> There's a machine with:
>> - DigitalDevices CineS2
> 
> (adapter0)
> 
>> - CI-Module attached to CineS2;
> 
> (adapter0/{ca0,caio0})
> 
>> - TechniSat SkyStar2 (has no CI);
> 
> (adapter1)
> 
>> A user wants to stream two DVB-S2 transponders using CineS2. They are
>> both clear, so CI-Module is not needed.
>> 
>> At the same time, the user wants to stream one DVB-S transponder but it is
>> scrambled. Since CI-Module attached to CineS2 is not in use, it can be
>> made to work with SkyStar2 using a few lines of code in user space.
> 
> You're right, absolutely. This can of course still be done if ca0 and
> caio0 reside on adapter0, even if adapter0 also contains frontends,
> demuxes and stuff.
> 

I agree, but I don't use udev for DVB/V4L, so on my systems they will not 
reside on the same logical adapter.

>> I don't know Demux API so well to be able to tell for sure, but it looks
>> like it could be used (with a few extensions) instead of caioX.
>> 
>> One benefit of using Demux API would probably be the ability to have PID
>> filtering (in software or hardware), I think you've mentioned this already.
>> It is also similar to the way on-board decoder can be used on full-featured
>> cards.
>> 
>> This way both cases (nGene and your configurable design) could be covered.
> 
> I think so, too.
> 
>> On the other hand, using Demux API for nGene looks like an overkill, and
>> switching of TS route in your case could be done in some other way.
>> Specific HW design related problems seem to be common to both approaches.
>> 
>> Nevertheless, Demux API approach looks cleaner. But on the other hand, it
>> hides the fact that CI can be used in this particular way (sysfs could
>> help).
> 
> In most applications you'll want the PID filtering at the CI's output
> anyway, so you can use the decrypted stream the same way you'd use it
> without the CI. In other words, every physical TS input of the chipset
> (in this case: nGene) should get its own demux interface, e.g. demux0
> and demux1 for the frontends, demux2 for the CI.
> 

PID filtering on CI's output makes sense. However, I'm not sure if it
really presents a significant benefit for most applications.

I'm also not sure every TS port needs a demux device. DVB API 
documentation says a demux should allow multiple sessions and it 
should be possible to configure the same demux device to use 
different inputs &| outputs (the enums) for individual sessions.

> Whatever we'll agree on, we should define an interface to query the
> possible inputs and outputs of a demux, be it by means of sysfs or
> ioctls. This would also be useful to find out which demux can be used
> with DMX_OUT_DECODER for full-featured cards.
> 

My view of sysfs vs. ioctl: I think both should provide equivalent 
infrastructure for querying device capabilities. Sometimes it is 
necessary to know what kind of device I'm dealing with at the time
of device node creation or later at device enumeration.

How do you know which device is S2, T, C (or something else) without 
resorting to ioctl's?

> We can add DMX_OUT_CI, DMX_IN_CI, DMX_SOURCE_CI{0,1,2,3...} to the enums
> in dmx.h. Ideally, in addition to that, I'd prefer dividing descramblers
> and CIs into ca and ci device nodes, as proposed some days ago.
> 

I've had a few thoughts before and after writing the last email.

One is: It looks to me like ASI cards would require a similar interface,
and this makes enums somewhat unattractive (maybe only at first sight).

The other: DVR device looks sort of tailored for the on-board decoder. So, 
it may make more sense if we add CAIO to Demux API. Both dvrX and caioX 
would be configured using ioctl's on demux0.

Rough examples:

Assume:

typedef enum
{
	DMX_OUT_DECODER,
	DMX_OUT_CI,
	DMX_OUT_TAP,
	DMX_OUT_TS_TAP
} dmx_output_t;

typedef enum
{
	DMX_IN_FRONTEND,
	DMX_IN_CI,
	DMX_IN_DVR,
	DMX_IN_CAIO
} dmx_input_t;

Then:

- Equivalent of status quo (secX/caioX):

	1. open demux0 and set:

	dmx_pes_filter_params {
		pid: 0x2000,
		input: DMX_IN_FRONTEND,
		output: DMX_OUT_TAP,
		pes_type: DMX_PES_OTHER,
		flags: DMX_IMMEDIATE_START
	}

	2. open demux0 and set:

	dmx_pes_filter_params {
		pid: 0x2000,
		input: DMX_IN_CAIO,
		output: DMX_OUT_CI,
		pes_type: DMX_PES_OTHER,
		flags: DMX_IMMEDIATE_START
	}

	3. open demux0 and set:

	dmx_pes_filter_params {
		pid: 0x2000,
		input: DMX_IN_CI,
		output: DMX_OUT_TAP, // or DMX_OUT_TS_TAP
		pes_type: DMX_PES_OTHER,
		flags: DMX_IMMEDIATE_START
	}

- HW/SW (in-kernel) TS passing:

	1. open demux0 and set:

	dmx_pes_filter_params {
		pid: 0x2000,
		input: DMX_IN_FRONTEND,
		output: DMX_OUT_CI,
		pes_type: DMX_PES_OTHER,
		flags: DMX_IMMEDIATE_START
	}

	2. open demux0 and set:

	dmx_pes_filter_params {
		pid: 0x2000,
		input: DMX_IN_CI,
		output: DMX_OUT_TAP, // or DMX_OUT_TS_TAP
		pes_type: DMX_PES_OTHER,
		flags: DMX_IMMEDIATE_START
	}

> I think an ioctl to enable bypassing the PID filter when writing to the
> CI would help to decrease the amount of overkill.
> 

By overkill I meant that Demux API has features which may not be
needed in the nGene case, and that implementing CAIO with Demux API
may be more difficult than what we have now (SEC). Use may also be
more complicated.

>> I imagine there would still be a difference between the two cases:
>> 
>> - nGene (CineS2 with CI-Module)
> 
> IMO, this should be:
> 
> /dev/dvb/adapter0/ca0 (or better: ci0)
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/demux1
> /dev/dvb/adapter0/demux2
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/dvr1
> /dev/dvb/adapter0/dvr2
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/frontend1
> 
> (assuming 3 TS inputs)

Another version:

/dev/dvb/adapter0/ca0
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/caio0
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1

One could use 3 TS inputs this way too.

>> - Configurable Design (dual card similar to NetUP)
> 
> and
> 
> /dev/dvb/adapter0/ca0 (or better: ci0)
> /dev/dvb/adapter0/ca1 (or better: ci1)
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/demux1
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/dvr1
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/frontend1
> 
> (assuming 2 TS inputs and a way to map a CI to a frontend)
> 
> or your suggestion for NetUP, assuming fixed relations between CI slots
> and frontends.
> 

Fixed relations indeed. Alternatively:

/dev/dvb/adapter0/ca0
/dev/dvb/adapter0/ca1
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1

>> What do you say about this difference?
> 
> Different capabilities result in different nodes. I don't see anything
> special about it.
> 
> Regards,
> Andreas

Best regards,
Martin

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 05/09/2011 01:55 AM, Martin Vidovic wrote:
> Hi Andreas,
> 
> Andreas Oberritter wrote:
>> Hello Martin,
>>
>>>
>>> Binding to bus id is not a problem. However, especially for USB devices,
>>> it may be useful to have adapter MAC address in sysfs.
>>
>> a DVB adapter isn't required to have a unique MAC address, but we could
>> add this attribute to sysfs, if present. I think it would be preferrable
>> to use information available from the bus, e.g. the USB serial number.
>> But in cases, where the serial number is unavailable (probably quite
>> often), the MAC address might be a good fallback. It won't be available
>> in every case though.
>>
> 
> I'm aware MAC is not required. I used the TerraTec example because the
> USB serial numbers are the same for both devices (maybe only in my case).
> 
>>>>> c.1) How does one know which frontend device can be used with which
>>>>> demux device?
>>>>
>>>> I'd say by default (i.e. without DMX_SET_SOURCE, whether implemented or
>>>> not) frontendX is connected to demuxX on the same adapter. You have
>>>> probably faced other situations. Can you describe any?
>>>>
>>>
>>> I thought we were discussing how to connect frontendX to demuxY on
>>> different adapters, since this would be needed for nGene CI.
>>
>> Such connections between adapters are impossible, API-wise. Each adapter
>> is an independent circuit by definition.
>>
> 
> I'm using a different definition of DVB adapter:
> 
> DVB adapter is a collection of related DVB device nodes which can be
> used independently from (without side effects for) other DVB device
> nodes in the system.

I'd agree if you'd modify your definition to read "which can *only* be
used independently from [...] other DVB devices nodes [...]".

frontendX and demuxY of different adapters simply can't be both
independent from each other and connected to each other at the same time.

>>> NetUP Dual DVB S2 CI
>>
>> Nice. Is it possible to assign a CI slot to a frontend by means of
>> software with this card? Or does it appear as two independent circuits
>> on one board?
>>
> 
> The latter.
> 
>>>> If the next version gets a connector for two switchable CI modules,
>>>> then
>>>> the physical independence is gone. You'd have two ca nodes but only one
>>>> caio node. Or two caio nodes, that can't be used concurrently.
>>>>
>>>
>>> What is a switchable CI module?
>>
>> Sorry, I meant two normal CI modules and the ability to switch between
>> them, i.e. to only use one of them at a time.
>>
> 
> It looks like an odd HW design, but it can make sense for certain use
> cases. I think this would call for some different API extension, because
> there's effectively only one CI bus, but the SW would need to be able
> to bind a certain physical CI bus to this logical bus.
> 
>>>> Maybe the next version gets the ability to directly connect the TS
>>>> input
>>>> from the frontend to the TS output to the CI slot to save copying
>>>> around
>>>> the data, by using some kind of pin mux. Not physically independent
>>>> either.
>>>>
>>>
>>> When this feature would be in action, opening caioX could return EBUSY
>>> and vice versa. This sounds similar to V4L <-> DVB interaction for
>>> hybrid
>>> devices. API can't change the fact a resource is shared.
>>
>> Indeed. However, what I was trying to explain with this example was,
>> that such a shared resource isn't physically independent and thus has to
>> appear under the same adapter number as the other parts of the circuit
>> it resides on.
>>
> 
> How about this device: TeVii S480
> 
> This board integrates a USB controller and two TeVii S660 devices on
> a single PCIe card. Why would a driver be required to handle this
> situation any differently than having two actual S660's attached to a
> USB controller sitting on PCI?

I think my statement was mistakable. By independent circuits I was
covering only the data reception path. Of course, multiple circuits may
share the same board and thus be connected to each other somehow, e.g.
sharing a PCIe bridge. Still they appear to be independent to the user,
because the components used in the individual paths can not be shared
(reordered or interconnected by software).

>>>> It just looks physically independent in the one configuration
>>>> implemented now.
>>>>
>>>
>>> I don't believe it's an accident how nGene cards interface with CI. To
>>> me it rather looks like a very good feature.
>>>
>>> Imagine a use case like this:
>>>
>>> There's a machine with:
>>> - DigitalDevices CineS2
>>
>> (adapter0)
>>
>>> - CI-Module attached to CineS2;
>>
>> (adapter0/{ca0,caio0})
>>
>>> - TechniSat SkyStar2 (has no CI);
>>
>> (adapter1)
>>
>>> A user wants to stream two DVB-S2 transponders using CineS2. They are
>>> both clear, so CI-Module is not needed.
>>>
>>> At the same time, the user wants to stream one DVB-S transponder but
>>> it is
>>> scrambled. Since CI-Module attached to CineS2 is not in use, it can be
>>> made to work with SkyStar2 using a few lines of code in user space.
>>
>> You're right, absolutely. This can of course still be done if ca0 and
>> caio0 reside on adapter0, even if adapter0 also contains frontends,
>> demuxes and stuff.
>>
> 
> I agree, but I don't use udev for DVB/V4L, so on my systems they will
> not reside on the same logical adapter.

The way devices are named in userspace (by udev or anything else) on
your system doesn't matter at all. Upon device registration,
dvb_register_device gets called with an adapter passed as a parameter.
This creates the logical association between device node and adapter
we're discussing. The default scheme used by udev just happens to
display this association 1:1.

>>> I don't know Demux API so well to be able to tell for sure, but it looks
>>> like it could be used (with a few extensions) instead of caioX.
>>>
>>> One benefit of using Demux API would probably be the ability to have PID
>>> filtering (in software or hardware), I think you've mentioned this
>>> already.
>>> It is also similar to the way on-board decoder can be used on
>>> full-featured
>>> cards.
>>>
>>> This way both cases (nGene and your configurable design) could be
>>> covered.
>>
>> I think so, too.
>>
>>> On the other hand, using Demux API for nGene looks like an overkill, and
>>> switching of TS route in your case could be done in some other way.
>>> Specific HW design related problems seem to be common to both
>>> approaches.
>>>
>>> Nevertheless, Demux API approach looks cleaner. But on the other
>>> hand, it
>>> hides the fact that CI can be used in this particular way (sysfs could
>>> help).
>>
>> In most applications you'll want the PID filtering at the CI's output
>> anyway, so you can use the decrypted stream the same way you'd use it
>> without the CI. In other words, every physical TS input of the chipset
>> (in this case: nGene) should get its own demux interface, e.g. demux0
>> and demux1 for the frontends, demux2 for the CI.
>>
> 
> PID filtering on CI's output makes sense. However, I'm not sure if it
> really presents a significant benefit for most applications.

Otherwise, the application needs to implement a PID filter by itself.

> I'm also not sure every TS port needs a demux device. DVB API
> documentation says a demux should allow multiple sessions and it should
> be possible to configure the same demux device to use different inputs
> &| outputs (the enums) for individual sessions.

Is this really documented somewhere that way? I'm asking, because it
won't work. Think about the dvr device, for example. You really need a
dvr device for each concurrent TS input, but dvr devices are implicitly
bound to demux devices with the same number. I'm not a big fan of the
dvr device, but it's already there and used by many applications.

>> Whatever we'll agree on, we should define an interface to query the
>> possible inputs and outputs of a demux, be it by means of sysfs or
>> ioctls. This would also be useful to find out which demux can be used
>> with DMX_OUT_DECODER for full-featured cards.
>>
> 
> My view of sysfs vs. ioctl: I think both should provide equivalent
> infrastructure for querying device capabilities. Sometimes it is
> necessary to know what kind of device I'm dealing with at the time
> of device node creation or later at device enumeration.
> 
> How do you know which device is S2, T, C (or something else) without
> resorting to ioctl's?

Exporting some data to userspace through sysfs would be nice, indeed.
Having to open a frontend node, and thus causing a lengthy firmware
upload for many of the newer demods, sucks if you just want to find out
the supported delivery system(s).

>> We can add DMX_OUT_CI, DMX_IN_CI, DMX_SOURCE_CI{0,1,2,3...} to the enums
>> in dmx.h. Ideally, in addition to that, I'd prefer dividing descramblers
>> and CIs into ca and ci device nodes, as proposed some days ago.
>>
> 
> I've had a few thoughts before and after writing the last email.
> 
> One is: It looks to me like ASI cards would require a similar interface,
> and this makes enums somewhat unattractive (maybe only at first sight).
> 
> The other: DVR device looks sort of tailored for the on-board decoder.
> So, it may make more sense if we add CAIO to Demux API. Both dvrX and
> caioX would be configured using ioctl's on demux0.

demuxX instead of demux0. Writing to dvr just feeds a TS to the demux.
It may be used with a decoder, but doesn't necessarily have to.

We can influence the behaviour of the dvr device (or of the demux
device) by adding an ioctl to disable the TS parser.

> Rough examples:
> 
> Assume:
> 
> typedef enum
> {
>     DMX_OUT_DECODER,
>     DMX_OUT_CI,
>     DMX_OUT_TAP,
>     DMX_OUT_TS_TAP
> } dmx_output_t;
> 
> typedef enum
> {
>     DMX_IN_FRONTEND,
>     DMX_IN_CI,
>     DMX_IN_DVR,
>     DMX_IN_CAIO
> } dmx_input_t;
> 
> Then:
> 
> - Equivalent of status quo (secX/caioX):
> 
>     1. open demux0 and set:
> 
>     dmx_pes_filter_params {
>         pid: 0x2000,
>         input: DMX_IN_FRONTEND,
>         output: DMX_OUT_TAP,
>         pes_type: DMX_PES_OTHER,
>         flags: DMX_IMMEDIATE_START
>     }
> 
>     2. open demux0 and set:
> 
>     dmx_pes_filter_params {
>         pid: 0x2000,
>         input: DMX_IN_CAIO,
>         output: DMX_OUT_CI,
>         pes_type: DMX_PES_OTHER,
>         flags: DMX_IMMEDIATE_START
>     }

You're using DMX_IN_CAIO to pass raw data (in this case an unfiltered
TS) to any output (in this case to a CI). This invalidates the reason to
call it "caio" in the first place.

>     3. open demux0 and set:
> 
>     dmx_pes_filter_params {
>         pid: 0x2000,
>         input: DMX_IN_CI,
>         output: DMX_OUT_TAP, // or DMX_OUT_TS_TAP
>         pes_type: DMX_PES_OTHER,
>         flags: DMX_IMMEDIATE_START
>     }
> 
> - HW/SW (in-kernel) TS passing:
> 
>     1. open demux0 and set:
> 
>     dmx_pes_filter_params {
>         pid: 0x2000,
>         input: DMX_IN_FRONTEND,
>         output: DMX_OUT_CI,
>         pes_type: DMX_PES_OTHER,
>         flags: DMX_IMMEDIATE_START
>     }
> 
>     2. open demux0 and set:
> 
>     dmx_pes_filter_params {
>         pid: 0x2000,
>         input: DMX_IN_CI,
>         output: DMX_OUT_TAP, // or DMX_OUT_TS_TAP
>         pes_type: DMX_PES_OTHER,
>         flags: DMX_IMMEDIATE_START
>     }
> 
>> I think an ioctl to enable bypassing the PID filter when writing to the
>> CI would help to decrease the amount of overkill.
>>
> 
> By overkill I meant that Demux API has features which may not be
> needed in the nGene case, and that implementing CAIO with Demux API
> may be more difficult than what we have now (SEC). Use may also be
> more complicated.
>
>>> I imagine there would still be a difference between the two cases:
>>>
>>> - nGene (CineS2 with CI-Module)
>>
>> IMO, this should be:
>>
>> /dev/dvb/adapter0/ca0 (or better: ci0)
>> /dev/dvb/adapter0/demux0
>> /dev/dvb/adapter0/demux1
>> /dev/dvb/adapter0/demux2
>> /dev/dvb/adapter0/dvr0
>> /dev/dvb/adapter0/dvr1
>> /dev/dvb/adapter0/dvr2
>> /dev/dvb/adapter0/frontend0
>> /dev/dvb/adapter0/frontend1
>>
>> (assuming 3 TS inputs)
> 
> Another version:
> 
> /dev/dvb/adapter0/ca0
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/caio0
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/frontend1
> 
> One could use 3 TS inputs this way too.

But then you can record only one TS at a time through dvr.

Regards,
Andreas

>>> - Configurable Design (dual card similar to NetUP)
>>
>> and
>>
>> /dev/dvb/adapter0/ca0 (or better: ci0)
>> /dev/dvb/adapter0/ca1 (or better: ci1)
>> /dev/dvb/adapter0/demux0
>> /dev/dvb/adapter0/demux1
>> /dev/dvb/adapter0/dvr0
>> /dev/dvb/adapter0/dvr1
>> /dev/dvb/adapter0/frontend0
>> /dev/dvb/adapter0/frontend1
>>
>> (assuming 2 TS inputs and a way to map a CI to a frontend)
>>
>> or your suggestion for NetUP, assuming fixed relations between CI slots
>> and frontends.
>>
> 
> Fixed relations indeed. Alternatively:
> 
> /dev/dvb/adapter0/ca0
> /dev/dvb/adapter0/ca1
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter0/frontend1
> 
>>> What do you say about this difference?
>>
>> Different capabilities result in different nodes. I don't see anything
>> special about it.
>>
>> Regards,
>> Andreas
> 
> Best regards,
> Martin
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> 
> I'm not against adding a new node if its behaviour is well defined and
> documented and if it integrates well into the existing API.


Integration is okay; current API is left untouched.
The behaviour is defined as a write encrypted stream / read decrypted stream
device.


> 
> > You might find that adding a new node is lazy, but there are advantages:
> > - current API isn't broken, namely, ca devices are still used for the
control
> > messages, nothing more;
> 
> "nothing more" is wrong, as ca devices are used for descramblers, too.


I don't understand your point here, do you mean these DVB descramblers
currently use ca device for more than the control messages ?


> 
> > - for applications using the DVB API, it is also easier to debug while
reading
> > the code, in my opinion, because of the usage of two distinct devices (ca
/
> > cam) instead of one (ca / ioctls);
> 
> That's just a matter of taste.

Okay, so you agree that choosing ca/ioctls over ca/cam is just a matter of
taste.

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Ralph Metzler <rjkm@metzlerbros.de>
> Andreas Oberritter writes:
>  > > Unless you want to move the writing to/reading from the CI module into
>  > > ioctls of the ci device you need another node. 
>  > > Even nicer would be having the control messages moved to ioctls and
the
>  > > TS IO in read/write of ci, but this would break the old interface.
>  > 
>  > It's possible to keep compatibility. Just add ioctls to get and set the
>  > interface version. Default to the current version, not supporting TS
>  > I/O. If the version is set to e.g. 1, switch from the current interface
>  > to the new one, using ioctls for control messages.
> 
> A possibility, but also requires rewrites in existing software like
libdvben50221.
> Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an
unchanged
> libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even
> be on a different card) and pipe all PIDs of cam_pmt of the program
> you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded.

This is KISS compliant by the way.

Andreas, please explain what *really* bothers you with this architecture
choice of having a new node, leaving the current API as is.

You might find that adding a new node is lazy, but there are advantages:
- current API isn't broken, namely, ca devices are still used for the control
messages, nothing more;
- for applications using the DVB API, it is also easier to debug while reading
the code, in my opinion, because of the usage of two distinct devices (ca /
cam) instead of one (ca / ioctls);


--
Issa

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/12/2011 03:34 PM, Issa Gorissen wrote:
> From: Ralph Metzler <rjkm@metzlerbros.de>
>> Andreas Oberritter writes:
>>  > > Unless you want to move the writing to/reading from the CI module into
>>  > > ioctls of the ci device you need another node. 
>>  > > Even nicer would be having the control messages moved to ioctls and
> the
>>  > > TS IO in read/write of ci, but this would break the old interface.
>>  > 
>>  > It's possible to keep compatibility. Just add ioctls to get and set the
>>  > interface version. Default to the current version, not supporting TS
>>  > I/O. If the version is set to e.g. 1, switch from the current interface
>>  > to the new one, using ioctls for control messages.
>>
>> A possibility, but also requires rewrites in existing software like
> libdvben50221.
>> Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an
> unchanged
>> libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even
>> be on a different card) and pipe all PIDs of cam_pmt of the program
>> you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded.

Obviously, adapting libdvben50221 would be the first thing to do for an
enhanced CI API. Probably not a big deal.

> This is KISS compliant by the way.
> 
> Andreas, please explain what *really* bothers you with this architecture
> choice of having a new node, leaving the current API as is.

I'm not against adding a new node if its behaviour is well defined and
documented and if it integrates well into the existing API.

> You might find that adding a new node is lazy, but there are advantages:
> - current API isn't broken, namely, ca devices are still used for the control
> messages, nothing more;

"nothing more" is wrong, as ca devices are used for descramblers, too.

> - for applications using the DVB API, it is also easier to debug while reading
> the code, in my opinion, because of the usage of two distinct devices (ca /
> cam) instead of one (ca / ioctls);

That's just a matter of taste.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Hi,

since I just saw cxd2099 appear in staging in the latest git kernel, a
simple question which has been pointed out to me before:

Why is cxd2099.c in staging regarding the device name question?
It has nothing to do with the naming.


Regards,
Ralph

Re: [PATCH] Ngene cam device name

[Mauro Carvalho Chehab]

Em 27-03-2011 21:44, Ralph Metzler escreveu:
> Hi,
> 
> since I just saw cxd2099 appear in staging in the latest git kernel, a
> simple question which has been pointed out to me before:
> 
> Why is cxd2099.c in staging regarding the device name question?
> It has nothing to do with the naming.

It is not just because of naming. A NACK was given to it, as is, at:

http://www.spinics.net/lists/linux-media/msg28004.html

A previous discussion about this subject were started at:
	http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html

The point is that an interface meant to be used by satellite were
used as a ci interface, due to the lack of handling independent CA devices.

As there were no final decision about a proper way to address it, Oliver
decided to keep it as-is, and I decided to move it to staging while we
don't properly address the question, extending the DVB API in order to support
independent CA devs.

Having the driver at staging allow us to rework at the API and change the
driver when API changes are done, without needing to pass through kernel 
process of deprecating old API stuff.

Cheers,
Mauro

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

On 28/03/11 23:40, Mauro Carvalho Chehab wrote:
> Em 27-03-2011 21:44, Ralph Metzler escreveu:
>> Hi,
>>
>> since I just saw cxd2099 appear in staging in the latest git kernel, a
>> simple question which has been pointed out to me before:
>>
>> Why is cxd2099.c in staging regarding the device name question?
>> It has nothing to do with the naming.
> It is not just because of naming. A NACK was given to it, as is, at:
>
> http://www.spinics.net/lists/linux-media/msg28004.html
>
> A previous discussion about this subject were started at:
> 	http://www.mail-archive.com/linux-media@vger.kernel.org/msg22196.html
>
> The point is that an interface meant to be used by satellite were
> used as a ci interface, due to the lack of handling independent CA devices.
>
> As there were no final decision about a proper way to address it, Oliver
> decided to keep it as-is, and I decided to move it to staging while we
> don't properly address the question, extending the DVB API in order to support
> independent CA devs.
>
> Having the driver at staging allow us to rework at the API and change the
> driver when API changes are done, without needing to pass through kernel 
> process of deprecating old API stuff.
>
> Cheers,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello all,

Here is the patch for the NGene card family and the new caio device.
Can cxd2099 be removed from staging as this patch fixes the raised issue.

Signed-off-by: Issa Gorissen <flop.m@usa.net>
---
 drivers/media/dvb/dvb-core/dvbdev.c  |    2 +-
 drivers/media/dvb/dvb-core/dvbdev.h  |    1 +
 drivers/media/dvb/ngene/ngene-core.c |    2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvbdev.c b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
 
 static const char * const dnames[] = {
 	"video", "audio", "sec", "frontend", "demux", "dvr", "ca",
-	"net", "osd"
+	"net", "osd", "caio"
 };
 
 #ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
 #define DVB_DEVICE_CA         6
 #define DVB_DEVICE_NET        7
 #define DVB_DEVICE_OSD        8
+#define DVB_DEVICE_CAIO       9
 
 #define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
 	static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
 		set_transfer(&chan->dev->channel[2], 1);
 		dvb_register_device(adapter, &chan->ci_dev,
 				    &ngene_dvbdev_ci, (void *) chan,
-				    DVB_DEVICE_SEC);
+				    DVB_DEVICE_CAIO);
 		if (!chan->ci_dev)
 			goto err;
 	}

Re: [PATCH] Ngene cam device name

[Oliver Endriss]

On Monday 28 March 2011 02:44:14 Ralph Metzler wrote:
> Hi,
> 
> since I just saw cxd2099 appear in staging in the latest git kernel, a
> simple question which has been pointed out to me before:
> 
> Why is cxd2099.c in staging regarding the device name question?
> It has nothing to do with the naming.

Well, it was a political decision. ;-)

Afaics there were 3 alternatives:
(1) Do not submit the cxd driver.
(2) Move cxd to staging.
(3) Move ngene to staging.

Imho option (2) was the one with minimal impact.

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/
----------------------------------------------------------------

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

Hello all,

Here is the patch for the NGene card family and the new caio device

Signed-off-by: Issa Gorissen <flop.m@usa.net>
---
 drivers/media/dvb/dvb-core/dvbdev.c  |    2 +-
 drivers/media/dvb/dvb-core/dvbdev.h  |    1 +
 drivers/media/dvb/ngene/ngene-core.c |    2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvbdev.c b/drivers/media/dvb/dvb-core/dvbdev.c
index f732877..7a64b81 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.c
+++ b/drivers/media/dvb/dvb-core/dvbdev.c
@@ -47,7 +47,7 @@ static DEFINE_MUTEX(dvbdev_register_lock);
 
 static const char * const dnames[] = {
 	"video", "audio", "sec", "frontend", "demux", "dvr", "ca",
-	"net", "osd"
+	"net", "osd", "caio"
 };
 
 #ifdef CONFIG_DVB_DYNAMIC_MINORS
diff --git a/drivers/media/dvb/dvb-core/dvbdev.h b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..c63c70d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -47,6 +47,7 @@
 #define DVB_DEVICE_CA         6
 #define DVB_DEVICE_NET        7
 #define DVB_DEVICE_OSD        8
+#define DVB_DEVICE_CAIO       9
 
 #define DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr) \
 	static short adapter_nr[] = \
diff --git a/drivers/media/dvb/ngene/ngene-core.c b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..17cdd38 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
 		set_transfer(&chan->dev->channel[2], 1);
 		dvb_register_device(adapter, &chan->ci_dev,
 				    &ngene_dvbdev_ci, (void *) chan,
-				    DVB_DEVICE_SEC);
+				    DVB_DEVICE_CAIO);
 		if (!chan->ci_dev)
 			goto err;
 	}

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
> On 03/11/2011 10:44 PM, Martin Vidovic wrote:
> > Andreas Oberritter wrote:
> >> It's rather unintuitive that some CAMs appear as ca0, while others as
> >> cam0.
> >>   
> > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
> > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
> > transport stream. To me it  looks like an extension of the current API.
> 
> I see. This raises another problem. How to find out, which ca device
> cam0 relates to, in case there are more ca devices than cam devices?
> 

Are you sure there can be more ca devices than cam devices ? Shouldn't they
come by pair ?

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/12/2011 03:10 PM, Issa Gorissen wrote:
> From: Andreas Oberritter <obi@linuxtv.org>
>> On 03/11/2011 10:44 PM, Martin Vidovic wrote:
>>> Andreas Oberritter wrote:
>>>> It's rather unintuitive that some CAMs appear as ca0, while others as
>>>> cam0.
>>>>   
>>> Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
>>> as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
>>> transport stream. To me it  looks like an extension of the current API.
>>
>> I see. This raises another problem. How to find out, which ca device
>> cam0 relates to, in case there are more ca devices than cam devices?
>>
> 
> Are you sure there can be more ca devices than cam devices ?

Yes. See my previous response to Ralph.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Andreas Oberritter wrote:
> On 03/12/2011 03:10 PM, Issa Gorissen wrote:
>   
>> From: Andreas Oberritter <obi@linuxtv.org>
>>     
>>> On 03/11/2011 10:44 PM, Martin Vidovic wrote:
>>>       
>>>> Andreas Oberritter wrote:
>>>>         
>>>>> It's rather unintuitive that some CAMs appear as ca0, while others as
>>>>> cam0.
>>>>>   
>>>>>           
>>>> Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
>>>> as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
>>>> transport stream. To me it  looks like an extension of the current API.
>>>>         
>>> I see. This raises another problem. How to find out, which ca device
>>> cam0 relates to, in case there are more ca devices than cam devices?
>>>
>>>       
>> Are you sure there can be more ca devices than cam devices ?
>>     
>
> Yes. See my previous response to Ralph.
>   

Isn't this the same as asking which 'dvr' device relates to which 
'frontend' device?

Regards,
Martin

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/12/2011 03:57 PM, Martin Vidovic wrote:
> Andreas Oberritter wrote:
>> On 03/12/2011 03:10 PM, Issa Gorissen wrote:
>>  
>>> From: Andreas Oberritter <obi@linuxtv.org>
>>>    
>>>> On 03/11/2011 10:44 PM, Martin Vidovic wrote:
>>>>      
>>>>> Andreas Oberritter wrote:
>>>>>        
>>>>>> It's rather unintuitive that some CAMs appear as ca0, while others as
>>>>>> cam0.
>>>>>>             
>>>>> Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
>>>>> as usual, to setup the CAM. The cam0 (or sec0) node is used to
>>>>> read/write
>>>>> transport stream. To me it  looks like an extension of the current
>>>>> API.
>>>>>         
>>>> I see. This raises another problem. How to find out, which ca device
>>>> cam0 relates to, in case there are more ca devices than cam devices?
>>>>
>>>>       
>>> Are you sure there can be more ca devices than cam devices ?
>>>     
>>
>> Yes. See my previous response to Ralph.
>>   
> 
> Isn't this the same as asking which 'dvr' device relates to which
> 'frontend' device?

No, because this is defined. If demuxN is configured to output to a dvr
device, then it outputs to dvrN. The input of demuxN is configured by
using DMX_SET_SOURCE, which can be frontendX or dvrY.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

From: Andreas Oberritter <obi@linuxtv.org>
To: Issa Gorissen <flop.m@usa.net>Cc: linux-media@vger.kernel.org,
rjkm@metzlerbros.de
Subject: Re: [PATCH] Ngene cam device name

> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
> > As the cxd20099 driver is in staging due to abuse of the sec0 device,
this
> > patch renames it to cam0. The sec0 device is not in use and can be
removed
> 
> That doesn't solve anything. Besides, your patch doesn't even do what
> you describe.
> 
> Wouldn't it be possible to extend the current CA API? If not, shouldn't
> a new API be created that covers both old and new requirements?
> 
> It's rather unintuitive that some CAMs appear as ca0, while others as cam0.
> 
> If it was that easy to fix, it wouldn't be in staging today.
> 
> Regards,
> Andreas


Yes indeed, this patch is missing the update of dnames arrays in dvbdev.c

Now, according to Mauro comments, he has put this code into staging because of
the usage of sec0 name for a cam device.

Please comment on Oliver's explanations from this thread

http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html


Thx
--
Issa


> 
> > Signed-off-by: Issa Gorissen <flop.m@usa.net>
> > ---
> >  drivers/media/dvb/dvb-core/dvbdev.h  |    2 +-
> >  drivers/media/dvb/ngene/ngene-core.c |    2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/dvb/dvb-core/dvbdev.h 
> > b/drivers/media/dvb/dvb-core/dvbdev.h
> > index fcc6ae9..dcac27d 100644
> > --- a/drivers/media/dvb/dvb-core/dvbdev.h
> > +++ b/drivers/media/dvb/dvb-core/dvbdev.h
> > @@ -40,7 +40,7 @@
> >  
> >  #define DVB_DEVICE_VIDEO      0
> >  #define DVB_DEVICE_AUDIO      1
> > -#define DVB_DEVICE_SEC        2
> > +#define DVB_DEVICE_CAM        2
> >  #define DVB_DEVICE_FRONTEND   3
> >  #define DVB_DEVICE_DEMUX      4
> >  #define DVB_DEVICE_DVR        5
> > diff --git a/drivers/media/dvb/ngene/ngene-core.c 
> > b/drivers/media/dvb/ngene/ngene-core.c
> > index 175a0f6..6be2d7c 100644
> > --- a/drivers/media/dvb/ngene/ngene-core.c
> > +++ b/drivers/media/dvb/ngene/ngene-core.c
> > @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
> >                 set_transfer(&chan->dev->channel[2], 1);
> >                 dvb_register_device(adapter, &chan->ci_dev,
> >                                     &ngene_dvbdev_ci, (void *) chan,
> > -                                   DVB_DEVICE_SEC);
> > +                                   DVB_DEVICE_CAM);
> >                 if (!chan->ci_dev)
> >                         goto err;
> >         }
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

>> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
>>> As the cxd20099 driver is in staging due to abuse of the sec0 device,
> this
>>> patch renames it to cam0. The sec0 device is not in use and can be
> removed
>>
>> That doesn't solve anything. Besides, your patch doesn't even do what
>> you describe.
>>
>> Wouldn't it be possible to extend the current CA API? If not, shouldn't
>> a new API be created that covers both old and new requirements?
>>
>> It's rather unintuitive that some CAMs appear as ca0, while others as cam0.
>>
>> If it was that easy to fix, it wouldn't be in staging today.
>>
>> Regards,
>> Andreas
> 
> 
> Yes indeed, this patch is missing the update of dnames arrays in dvbdev.c
> 
> Now, according to Mauro comments, he has put this code into staging because of
> the usage of sec0 name for a cam device.
> 
> Please comment on Oliver's explanations from this thread
> 
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html

Oliver explained that he's not going to put work into this driver,
because he's not using it.

Until now, I haven't heard any reasons for just adding another device
node other than it being easier than defining a proper interface. The
fact that a solution "just works as is" is not sufficient to move a
driver from staging. IMO the CI driver should not have been included at
all in its current shape.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Andreas Oberritter writes:
 > >> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
 > > Now, according to Mauro comments, he has put this code into staging because of
 > > the usage of sec0 name for a cam device.
 > > 
 > > Please comment on Oliver's explanations from this thread
 > > 
 > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html
 > 
 > Oliver explained that he's not going to put work into this driver,
 > because he's not using it.
 > 
 > Until now, I haven't heard any reasons for just adding another device
 > node other than it being easier than defining a proper interface. The
 > fact that a solution "just works as is" is not sufficient to move a
 > driver from staging. IMO the CI driver should not have been included at
 > all in its current shape.

Unless you want to move the writing to/reading from the CI module into
ioctls of the ci device you need another node. 
Even nicer would be having the control messages moved to ioctls and the
TS IO in read/write of ci, but this would break the old interface.

What kind of proper interface were you thinking about?


Regarding usage of dvr/demux mentioned in the linked thread above,
this would add major overhead and lots more nodes. 
You would need dvr0/demux0 for output and dvr1/demux1 for input and both
would PID-filter the stream yet again although it probably already was
when being read from the demux or dvr device belonging to the tuner.


Regards,
Ralph

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/11/2011 10:46 PM, Ralph Metzler wrote:
> Andreas Oberritter writes:
>  > >> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
>  > > Now, according to Mauro comments, he has put this code into staging because of
>  > > the usage of sec0 name for a cam device.
>  > > 
>  > > Please comment on Oliver's explanations from this thread
>  > > 
>  > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26901.html
>  > 
>  > Oliver explained that he's not going to put work into this driver,
>  > because he's not using it.
>  > 
>  > Until now, I haven't heard any reasons for just adding another device
>  > node other than it being easier than defining a proper interface. The
>  > fact that a solution "just works as is" is not sufficient to move a
>  > driver from staging. IMO the CI driver should not have been included at
>  > all in its current shape.
> 
> Unless you want to move the writing to/reading from the CI module into
> ioctls of the ci device you need another node. 
> Even nicer would be having the control messages moved to ioctls and the
> TS IO in read/write of ci, but this would break the old interface.

It's possible to keep compatibility. Just add ioctls to get and set the
interface version. Default to the current version, not supporting TS
I/O. If the version is set to e.g. 1, switch from the current interface
to the new one, using ioctls for control messages.

> What kind of proper interface were you thinking about?

At least something that's documented and has a defined behaviour.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Andreas Oberritter writes:
 > > Unless you want to move the writing to/reading from the CI module into
 > > ioctls of the ci device you need another node. 
 > > Even nicer would be having the control messages moved to ioctls and the
 > > TS IO in read/write of ci, but this would break the old interface.
 > 
 > It's possible to keep compatibility. Just add ioctls to get and set the
 > interface version. Default to the current version, not supporting TS
 > I/O. If the version is set to e.g. 1, switch from the current interface
 > to the new one, using ioctls for control messages.

A possibility, but also requires rewrites in existing software like libdvben50221.
Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an unchanged
libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even
be on a different card) and pipe all PIDs of cam_pmt of the program
you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded.



Regards,
Ralph

[PATCH] Ngene cam device name

[Issa Gorissen]

As the cxd20099 driver is in staging due to abuse of the sec0 device, this
patch renames it to cam0. The sec0 device is not in use and can be removed

Signed-off-by: Issa Gorissen <flop.m@usa.net>
---
 drivers/media/dvb/dvb-core/dvbdev.h  |    2 +-
 drivers/media/dvb/ngene/ngene-core.c |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvbdev.h 
b/drivers/media/dvb/dvb-core/dvbdev.h
index fcc6ae9..dcac27d 100644
--- a/drivers/media/dvb/dvb-core/dvbdev.h
+++ b/drivers/media/dvb/dvb-core/dvbdev.h
@@ -40,7 +40,7 @@
 
 #define DVB_DEVICE_VIDEO      0
 #define DVB_DEVICE_AUDIO      1
-#define DVB_DEVICE_SEC        2
+#define DVB_DEVICE_CAM        2
 #define DVB_DEVICE_FRONTEND   3
 #define DVB_DEVICE_DEMUX      4
 #define DVB_DEVICE_DVR        5
diff --git a/drivers/media/dvb/ngene/ngene-core.c 
b/drivers/media/dvb/ngene/ngene-core.c
index 175a0f6..6be2d7c 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
                set_transfer(&chan->dev->channel[2], 1);
                dvb_register_device(adapter, &chan->ci_dev,
                                    &ngene_dvbdev_ci, (void *) chan,
-                                   DVB_DEVICE_SEC);
+                                   DVB_DEVICE_CAM);
                if (!chan->ci_dev)
                        goto err;
        }

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/10/2011 04:29 PM, Issa Gorissen wrote:
> As the cxd20099 driver is in staging due to abuse of the sec0 device, this
> patch renames it to cam0. The sec0 device is not in use and can be removed

That doesn't solve anything. Besides, your patch doesn't even do what
you describe.

Wouldn't it be possible to extend the current CA API? If not, shouldn't
a new API be created that covers both old and new requirements?

It's rather unintuitive that some CAMs appear as ca0, while others as cam0.

If it was that easy to fix, it wouldn't be in staging today.

Regards,
Andreas

> Signed-off-by: Issa Gorissen <flop.m@usa.net>
> ---
>  drivers/media/dvb/dvb-core/dvbdev.h  |    2 +-
>  drivers/media/dvb/ngene/ngene-core.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/dvb/dvb-core/dvbdev.h 
> b/drivers/media/dvb/dvb-core/dvbdev.h
> index fcc6ae9..dcac27d 100644
> --- a/drivers/media/dvb/dvb-core/dvbdev.h
> +++ b/drivers/media/dvb/dvb-core/dvbdev.h
> @@ -40,7 +40,7 @@
>  
>  #define DVB_DEVICE_VIDEO      0
>  #define DVB_DEVICE_AUDIO      1
> -#define DVB_DEVICE_SEC        2
> +#define DVB_DEVICE_CAM        2
>  #define DVB_DEVICE_FRONTEND   3
>  #define DVB_DEVICE_DEMUX      4
>  #define DVB_DEVICE_DVR        5
> diff --git a/drivers/media/dvb/ngene/ngene-core.c 
> b/drivers/media/dvb/ngene/ngene-core.c
> index 175a0f6..6be2d7c 100644
> --- a/drivers/media/dvb/ngene/ngene-core.c
> +++ b/drivers/media/dvb/ngene/ngene-core.c
> @@ -1523,7 +1523,7 @@ static int init_channel(struct ngene_channel *chan)
>                 set_transfer(&chan->dev->channel[2], 1);
>                 dvb_register_device(adapter, &chan->ci_dev,
>                                     &ngene_dvbdev_ci, (void *) chan,
> -                                   DVB_DEVICE_SEC);
> +                                   DVB_DEVICE_CAM);
>                 if (!chan->ci_dev)
>                         goto err;
>         }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Andreas Oberritter wrote:
> On 03/10/2011 04:29 PM, Issa Gorissen wrote:
>   
>> As the cxd20099 driver is in staging due to abuse of the sec0 device, this
>> patch renames it to cam0. The sec0 device is not in use and can be removed
>>     
>
> That doesn't solve anything. Besides, your patch doesn't even do what
> you describe.
>
> Wouldn't it be possible to extend the current CA API? If not, shouldn't
> a new API be created that covers both old and new requirements?
>
> It's rather unintuitive that some CAMs appear as ca0, while others as cam0.
>   
Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
transport stream. To me it  looks like an extension of the current API.

The sec name needs changing obviously, but there seem to be some other
problems too.
> If it was that easy to fix, it wouldn't be in staging today.
>
> Regards,
> Andreas
>   
Regards,
Martin

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/11/2011 10:44 PM, Martin Vidovic wrote:
> Andreas Oberritter wrote:
>> It's rather unintuitive that some CAMs appear as ca0, while others as
>> cam0.
>>   
> Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
> as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
> transport stream. To me it  looks like an extension of the current API.

I see. This raises another problem. How to find out, which ca device
cam0 relates to, in case there are more ca devices than cam devices?

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Andreas Oberritter writes:
 > On 03/11/2011 10:44 PM, Martin Vidovic wrote:
 > > Andreas Oberritter wrote:
 > >> It's rather unintuitive that some CAMs appear as ca0, while others as
 > >> cam0.
 > >>   
 > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
 > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
 > > transport stream. To me it  looks like an extension of the current API.
 > 
 > I see. This raises another problem. How to find out, which ca device
 > cam0 relates to, in case there are more ca devices than cam devices?
 > 

They should be in different adapterX directories. 
Even on the cards where you can connect up to 4 dual frontends or CAM adapters
I currently use one adapter directory for every frontend and CAM.

If you want to "save" adapters one could put them in the same
directory and caX would belong to camX. 
More ca than cam devices could only occur on cards with mixed old and
new style hardware. I am not aware of such cards.

I think there are cards with dual frontend and two CAM adapters where
normally data from frontendX is passed through caX (they are in the same adapter
directory) but the paths can also be switched. I do not now how this is
handled.


Regards,
Ralph

Re: [PATCH] Ngene cam device name

[Andreas Oberritter]

On 03/12/2011 03:05 PM, Ralph Metzler wrote:
> Andreas Oberritter writes:
>  > On 03/11/2011 10:44 PM, Martin Vidovic wrote:
>  > > Andreas Oberritter wrote:
>  > >> It's rather unintuitive that some CAMs appear as ca0, while others as
>  > >> cam0.
>  > >>   
>  > > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
>  > > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
>  > > transport stream. To me it  looks like an extension of the current API.
>  > 
>  > I see. This raises another problem. How to find out, which ca device
>  > cam0 relates to, in case there are more ca devices than cam devices?
>  > 
> 
> They should be in different adapterX directories. 
> Even on the cards where you can connect up to 4 dual frontends or CAM adapters
> I currently use one adapter directory for every frontend and CAM.

That looks like a hack to me, that may work well for your PC style
adapter, e.g frontends and CAMs attached to PCI or USB. But how would
you integrate audio and video decoders and hardware demux devices into
that scenario? Would you expect adapterN's frontend to be able to feed a
TS into adapterN+1's hardware demux and then into adapterN+2's video
decoder?

> If you want to "save" adapters one could put them in the same
> directory and caX would belong to camX. 
> More ca than cam devices could only occur on cards with mixed old and
> new style hardware. I am not aware of such cards.

DVB descramblers use ca devices, too. So it's certainly possible to occur.

And even if no hardware exists that uses CAM slots with such different
capabilities, we should be prepared when such hardware appears.

> I think there are cards with dual frontend and two CAM adapters where
> normally data from frontendX is passed through caX (they are in the same adapter
> directory) but the paths can also be switched. I do not now how this is
> handled.

On our STB platform. we have four frontends and four CAM slots.
Frontends and CAM slots get connected on demand or even chained to allow
multiple CAMs to try to decode parts of the same TS. I don't see how
multiple adapters could fit in that situation.

Regards,
Andreas

Re: [PATCH] Ngene cam device name

[Ralph Metzler]

Andreas Oberritter writes:
 > > They should be in different adapterX directories. 
 > > Even on the cards where you can connect up to 4 dual frontends or CAM adapters
 > > I currently use one adapter directory for every frontend and CAM.
 > 
 > That looks like a hack to me, that may work well for your PC style
 > adapter, e.g frontends and CAMs attached to PCI or USB. But how would

Exactly what I want to support with this.


 > you integrate audio and video decoders and hardware demux devices into
 > that scenario? Would you expect adapterN's frontend to be able to feed a
 > TS into adapterN+1's hardware demux and then into adapterN+2's video
 > decoder?

This would be up to the application since there is no hardware stream
routing on these cards and no general stream routing protocol for 
DVB in the kernel.

 > > If you want to "save" adapters one could put them in the same
 > > directory and caX would belong to camX. 
 > > More ca than cam devices could only occur on cards with mixed old and
 > > new style hardware. I am not aware of such cards.
 > 
 > DVB descramblers use ca devices, too. So it's certainly possible to occur.

Not in the same adapter directory.


 > And even if no hardware exists that uses CAM slots with such different
 > capabilities, we should be prepared when such hardware appears.

Then we also should not use the current API (or any) for the same reason?


 > > I think there are cards with dual frontend and two CAM adapters where
 > > normally data from frontendX is passed through caX (they are in the same adapter
 > > directory) but the paths can also be switched. I do not now how this is
 > > handled.
 > 
 > On our STB platform. we have four frontends and four CAM slots.
 > Frontends and CAM slots get connected on demand or even chained to allow
 > multiple CAMs to try to decode parts of the same TS. I don't see how
 > multiple adapters could fit in that situation.

Is this routing in hardware? If yes, it is totally different 
because your devices are not independent.
How do you support this with the current API?


Regards,
Ralph

Re: [PATCH] Ngene cam device name

[Oliver Endriss]

Hi,

On Saturday 12 March 2011 14:29:08 Andreas Oberritter wrote:
> On 03/11/2011 10:44 PM, Martin Vidovic wrote:
> > Andreas Oberritter wrote:
> >> It's rather unintuitive that some CAMs appear as ca0, while others as
> >> cam0.
> >>   
> > Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
> > as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
> > transport stream. To me it  looks like an extension of the current API.
> 
> I see. This raises another problem. How to find out, which ca device
> cam0 relates to, in case there are more ca devices than cam devices?

Hm, I do not see a problem here. The API extension is simple:

(1) camX is optional. If camX exists, it is tied to caX.

(2) If there is no camX, the CI/CAM operates in 'legacy mode'.

(3) If camX exists, the encrypted transport stream of the CI/CAM is sent
    through camX, and the decrypted stream is received from camX.
    caX behaves the same way as in (2).

Btw, we should choose a more meaningful name for 'camX'.
I would prefer something like cainoutX or caioX or cinoutX or cioX.

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/
----------------------------------------------------------------

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Oliver Endriss wrote:
> Hi,
>
> On Saturday 12 March 2011 14:29:08 Andreas Oberritter wrote:
>   
>> On 03/11/2011 10:44 PM, Martin Vidovic wrote:
>>     
>>> Andreas Oberritter wrote:
>>>       
>>>> It's rather unintuitive that some CAMs appear as ca0, while others as
>>>> cam0.
>>>>   
>>>>         
>>> Ngene CI appears as both ca0 and cam0 (or sec0). The ca0 node is used
>>> as usual, to setup the CAM. The cam0 (or sec0) node is used to read/write
>>> transport stream. To me it  looks like an extension of the current API.
>>>       
>> I see. This raises another problem. How to find out, which ca device
>> cam0 relates to, in case there are more ca devices than cam devices?
>>     
>
> Hm, I do not see a problem here. The API extension is simple:
>
> (1) camX is optional. If camX exists, it is tied to caX.
>
> (2) If there is no camX, the CI/CAM operates in 'legacy mode'.
>
> (3) If camX exists, the encrypted transport stream of the CI/CAM is sent
>     through camX, and the decrypted stream is received from camX.
>     caX behaves the same way as in (2).
>
> Btw, we should choose a more meaningful name for 'camX'.
> I would prefer something like cainoutX or caioX or cinoutX or cioX.
>   

I agree, camX could be misleading since it's not necessarily a CAM 
application.

According to EN 50221 the two interfaces are named Command Interface 
(for caX)
and Transport Stream Interface (for camX). Then maybe 'tsiX' would be an 
appropriate
name?

Anyway, 'cioX' sounds good too.

Regards,
Martin

Re: [PATCH] Ngene cam device name

[Issa Gorissen]

On 13/03/11 11:47, Martin Vidovic wrote:
>>
>> Btw, we should choose a more meaningful name for 'camX'.
>> I would prefer something like cainoutX or caioX or cinoutX or cioX.
>>   
>
>
> I agree, camX could be misleading since it's not necessarily a CAM
> application.
>
> According to EN 50221 the two interfaces are named Command Interface
> (for caX)
> and Transport Stream Interface (for camX). Then maybe 'tsiX' would be
> an appropriate
> name?
>
> Anyway, 'cioX' sounds good too.

I'll prepare the patch with caio (for conditional access I/O) if all
agrees on it. tsi is a good candidate as it perfectly matches the
standard specification, but then, ca should have been ci...

--
Issa

Re: [PATCH] Ngene cam device name

[Martin Vidovic]

Issa Gorissen wrote:
> On 13/03/11 11:47, Martin Vidovic wrote:
>   
>>> Btw, we should choose a more meaningful name for 'camX'.
>>> I would prefer something like cainoutX or caioX or cinoutX or cioX.
>>>   
>>>       
>> I agree, camX could be misleading since it's not necessarily a CAM
>> application.
>>
>> According to EN 50221 the two interfaces are named Command Interface
>> (for caX)
>> and Transport Stream Interface (for camX). Then maybe 'tsiX' would be
>> an appropriate
>> name?
>>
>> Anyway, 'cioX' sounds good too.
>>     
>
> I'll prepare the patch with caio (for conditional access I/O) if all
> agrees on it. tsi is a good candidate as it perfectly matches the
> standard specification, but then, ca should have been ci...
>
> --
> Issa
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   
Fine with me, as long as the name is stable.

However, these issues still bother me:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg29022.html

Regards,
Martin