[linux-dvb] Rationalisation of /dev/adapterX/caY devices
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:
> However, what you actually see is
> 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,
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.
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