[linux-dvb] Re: Twinhan CA

[Manu Abraham <manu@kromtek.com>]

On Sat November 27 2004 5:26 pm, Ralph Metzler wrote:
> Manu Abraham writes:
> [...]
>
>  > Is there some library in someone's knowledge which does SI parsing
>  > written in C such that i can do a quick and dirty _testing_ (only for
>  > testing) of the same, rather than wait for something to
>  > developed/modified ?
>  >
>  > I thought of two solutions.
>  >
>  > 1)A complete solution would be libdvb or libdvb2 itself.
>  >
>  > There is a place-holder for libdvb2 at linuxtv, eventhough no
>  > developments has undergone so far.
>  >
>  > 2)Another solution would be to hack scan to a certain extent to harvest
>  > information from SI, and set these parameters through *zap.
>
> I wrote a small test program which will get the PMT for a given
> PNR/ServiceID, convert it to CA_PMT and send it (with just the CA
> system ids suported by the CAM) to the CAM. This is working fine.
> Since *zap includes the PNR in the config files it will be easy to
> add this in there. Maybe I will post a patch later.
>
> Regarding the CI API we should settle on something common.
> Currently I am exchanging complete Twinhan style commands with the
> driver via CA_GET/SEND_MSG. Since the Twinhan CI commands send the
> standard En50221 packets minus header and length field plus their own
What about the ASIC instructions ?

> header we could also just send those. The driver would just have to
> exchange the headers from standard En50221 to Twinhan and vice versa.
> Or do you want to use extra ioctls like Twinhan does in their API?
It is somewhat like this...

The CA commands are wrapped as one chunk and treated as data to the ASIC. The 
ASIC reads in the command and does the appropriate of sending in the desired  
command to the CAM. Then there are commands to the ASIC also.


Regarding the ioctls, if i can add an integer preceding the commands to the 
CA_GET and or CA_SET ioctls as per the standard CA interface which exists as 
of now, i can have this driver also work on the same ioctls. This would make 
the driver/interface generic.

This integer, ie 16 bits, would be a wrapper for the commands to the ASIC. All 
the ASIC magic would be hidden in these 2 chars. 

The question is whether to have the ASIC instructions (which can be reduced to 
2 bytes) to be known upwards or not.

In the other case, if this is unacceptable, we have to settle down with 
individual IOCTL's for each ASIC instruction.

Manu
>
>
> Ralph