Re: [PATCH] Ngene cam device name

[Martin Vidovic <xtronom@gmail.com>]

Hi Andreas,

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

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

I'm using a different definition of DVB adapter:

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

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

The latter.

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

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

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

How about this device: TeVii S480

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

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

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

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

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

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

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

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

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

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

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

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

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

Rough examples:

Assume:

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

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

Then:

- Equivalent of status quo (secX/caioX):

	1. open demux0 and set:

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

	2. open demux0 and set:

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

	3. open demux0 and set:

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

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

	1. open demux0 and set:

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

	2. open demux0 and set:

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

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

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

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

Another version:

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

One could use 3 TS inputs this way too.

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

Fixed relations indeed. Alternatively:

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

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

Best regards,
Martin