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
adapter0/frontend0
adapter0/frontend1
adapter0/frontend2
adapter0/frontend3
adapter0/ca0
adapter0/ca1
adapter0/ca2
adapter0/ca3
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
etc
b) the streams might not be routable
ie
frontend0 --> ca0
frontend1 --> ca1
etc
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.
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
