[linux-dvb] Rationalisation of /dev/adapterX/caY devices

Manu Abraham abraham.manu at gmail.com
Mon Apr 10 16:58:13 CEST 2006

Andrew de Quincey wrote:
> Currently there is a slightly weird behaviour with DVB CA devices. Say you 
> have an adapter with three CI slots. You would expect to see:
> /dev/adapter0/ca0
> /dev/adapter0/ca1
> /dev/adapter0/ca2
> However, what you actually see is
> /dev/adapter0/ca0
> Then each message sent to and from that ca0 (using read()/write()) has a two 
> byte header prepended:
> byte0: slot_id
> byte1: transport_connection_id.
> Where slot_id will vary from 0->2. This complicates writing CA related 
> things.. Its not possible to just check a specific slot for data. And when 
> you start to support multiple adapters each with multiple slots, you have to 
> have a sort of virtual device layer. It also complicates the kernel 
> dvb_ca_en50221.c generic link level CA device driver.
> I would like to change this so that:
> 1) We create a caX device per slot on the adapters.
> 2) We'll keep the two byte header for back compatability (the 
> transport_connection_id is useful still). However, the slot_id will always be 
> set to 0.

As we talked last on this, in fact i am for this approach.

The case where the CA modules on one slot is seen as one single device 
is for daisy chaining of modules where the capabilities of one module is 
outsourced to the other. This would mean that module from vendor A 
seemlessly works in conjunction with module from vendor B. This does not 
practically happen as many businesses are not for this model. In fact a 
situation where this arises is nil.

We have 2 cases now with CA devices,

Case 1)

We have multiple frontends where one CA device is used
In this case a dedicated CPLD/FPGA is used to remultiplex the TS to 
create a MPTS and send it to the module.

Case 2)

We have multiple frontends with multiple CA devices
example we have an adapter with

In such a case

a) the streams from each frontend might be routable to other CA devices
ie,In such a case,
frontend2 --> ca0
frontend1 --> ca2


b) the streams might not be routable

frontend0 --> ca0
frontend1 --> ca1


In either case we will not be having a case where we can daisy chain the 
modules. I mean the hardware will not be daisy chained. The daisy 
chaining can be enforced only when hardware vendors do abide by the 
specs 100%. But if we address the slots directly, we will be able to 
handle both the scenarios , but id we do handle daisy chaining, we will 
not be able to handle either of these situations.


More information about the linux-dvb mailing list