[linux-dvb] Re: Twinhan CA -- error in previous mail...

[Manu Abraham <manu@kromtek.com>]

An error in my previous mail, please disregard my reply for the same.
Hence the new mail...


On Thu December 2 2004 2:01 pm, Ralph Metzler wrote:
> Manu Abraham writes:
>  > > 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.
>
> What would these 2 bytes be, command type and session number?
No.. what i thought was that the driver could interpret that number internally 
and apply the corresponding ASIC magic words depending upon that bytes.

> Or do we need anything else?
In a way, those 2 bytes correspond to the routines the ASIC is capable, that's 
all. Logically a map between the numbers and the routines, that's all.

IOCTL's also do something similar, i mean logically, another way to avoid 
multiple IOCTL's that's all.

>
> We could encode the command type with the normal EN50221 command headers
> (3 byte tag + length field) and prepend this (or just use the "type" field,
> see other mail).
> I think the session number is rather specific to the
> implementation or will this always be 3 for the SEND_PMT command?
In the Twinhan implementation,  the session number is hard-coded to 3, as per 
my correspondence with them,
ca_pmt_list_management == 3 ie, the _only_ CA PMT object as per 
EN50221, which is true for the hardware, since they told me that there is 
currently a hardware limitation of a single CA PMT object on the current CI 
boards, which would be changed in the MCU and or firmware very soon itself. 

And therefore change in session numbers is immaterial.

This not my view, but abstracted from my communication with them.

The documentation is a little bit hard to understand at least for me, 
especially CI part. Any way that did not raise much of an issue since 
initially i went on to reverse engineer what the driver was talking to the 
ASIC rather than read the badly written code or the documentation.

Even the code is typedefined every where here and there, which resulted in bad 
readability.

But the documentation did help though at certain points, can't deny it though.

> Either we add this as an exra hint to the type field or we leave it
> to the driver to use the correct session number for each command?
The type field really attracted me to the fact that it would be easier to have 
new features in the driver, as and when the manufacturer makes changes to 
their ASIC/firmware, without having the need for any new IOCTL's at all.

The downside is that the libdvb or any other application which needs to talk 
to the card will need to know what the 2 bytes stand for the corresponding 
function in the ASIC.

Otherwise, as the manufacturer, as they are doing now, they keep on adding 
IOCTL's to their demo driver to demonstrate new features.

What i would think is that, if we follow the same steps of having individual 
IOCTL's the driver in the end after a period, would be nothing more than a 
collection of messy IOCTL code.

Shouldn't we also consider how application authors would like this to 
proceed ?

Another question that i would like to ask is this, 

What about obsolete cards, as classified by the manufacturer ? Obsolete by the 
terms they mean is cards with hardware bugs ??

Manu
>
>
> Ralph