Re: [PATCH] Ngene cam device name
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
Re: [PATCH] Ngene cam device name
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 tha
Re: [PATCH] Ngene cam device name
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 transpo
Re: [PATCH] Ngene cam device name
On 08/05/11 11:53, Andreas Oberritter wrote: > Hello Issa, > > On 05/06/2011 08:29 PM, Issa Gorissen wrote: >> From: Andreas Oberritter >>> 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... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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
Re: [PATCH] Ngene cam device name
Hello Issa, On 05/06/2011 08:29 PM, Issa Gorissen wrote: > From: Andreas Oberritter >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > On 05/06/2011 03:47 PM, Issa Gorissen wrote: > > From: Andreas Oberritter > >>> 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) ? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 05/06/2011 03:47 PM, Issa Gorissen wrote: > From: Andreas Oberritter >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
Hi, On Fri, 06 May 2011 14:17:11 +0200, Andreas Oberritter 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > > 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 ? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > > 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 ??? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 05/04/2011 04:05 PM, Issa Gorissen wrote: > From: Andreas Oberritter >> 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]/ 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > >> 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]/ > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 05/04/2011 01:07 PM, Issa Gorissen wrote: > From: Andreas Oberritter >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 h
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Mauro Carvalho Chehab > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 05/04/2011 10:27 AM, Issa Gorissen wrote: > From: Andreas Oberritter >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@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
>> ---
>> 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_NET7
>> #define DVB_DEVICE_OSD8
>> +#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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@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
> ---
> 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_NET7
> #define DVB_DEVICE_OSD8
> +#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.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@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
---
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_NET7
#define DVB_DEVICE_OSD8
+#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;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@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
---
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_NET7
#define DVB_DEVICE_OSD8
+#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;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
Hello all,
Here is the patch for the NGene card family and the new caio device
Signed-off-by: Issa Gorissen
---
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_NET7
#define DVB_DEVICE_OSD8
+#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;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 03/12/2011 03:34 PM, Issa Gorissen wrote: > From: 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
Andreas Oberritter wrote: On 03/12/2011 03:10 PM, Issa Gorissen wrote: From: 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? 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
On 03/12/2011 03:10 PM, Issa Gorissen wrote: > From: 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? >> > > Are you sure there can be more ca devices than cam devices ? Yes. See my previous response to Ralph. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: 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? > Are you sure there can be more ca devices than cam devices ? Shouldn't they come by pair ? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Ngene cam device name
From: Andreas Oberritter To: Issa Gorissen Cc: linux-media@vger.kernel.org, r...@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 > > --- > > 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_SEC2 > > +#define DVB_DEVICE_CAM2 > > #define DVB_DEVICE_FRONTEND 3 > > #define DVB_DEVICE_DEMUX 4 > > #define DVB_DEVICE_DVR5 > > 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 majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 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 > Signed-off-by: Issa Gorissen > --- > 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_SEC2 > +#define DVB_DEVICE_CAM2 > #define DVB_DEVICE_FRONTEND 3 > #define DVB_DEVICE_DEMUX 4 > #define DVB_DEVICE_DVR5 > 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Ngene cam device name
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 --- 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_SEC2 +#define DVB_DEVICE_CAM2 #define DVB_DEVICE_FRONTEND 3 #define DVB_DEVICE_DEMUX 4 #define DVB_DEVICE_DVR5 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
