[linux-dvb] Re: Twinhan CA

[Manu Abraham <manu@kromtek.com>]

On Thu December 2 2004 4:47 pm, Ralph Metzler wrote:
> Manu Abraham writes:
>  > > 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.
>
> Yes, ok, that could then be the standard En50221 tags.
>
>  > > 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.
>
> OK, good, we can forget about session numbers then.

Not all together, The new card is going to get it back...
One thing i would like to know is why a session number ? Even if you send 
multiple CA PMT objects, generally why would one require multiple sessions ? 
One thing that i did never understood going through the documents.

>
> Of course the CA_PMT message starts with the same byte anyway,
> why is it repeated in the header?
It is a map that i plan to put it in the header.. That might not be required 
at all ? But what about CAM reset and other things like that ?

The ASIC requires more magic, not just EN50221. That can be done in the 
driver. Some more things are appended to the message before sending to the 
ASIC. The message position is shifted to the right by n, where n is the 
number of magic words. Before sending in the EN50221 structure to the cam, it 
is wrapped around with additional ASIC magic words. 

Would you like me to work it out and post it ? It might take a little bit 
time... I've been working too long on this one..

> This explains why nothing changed when I only changed it in the
> message ...
I have a working model, with just one ioctl set_pmt. I thought i will clean up 
and post, i didn't want people to comment about my code, after all that 
coding philosophies... going around.

An application that i created does change stuff, works okay, but it is crude 
since you have to pass the PMT to it. Just enough to test the driver.
>
>  > 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.
>
> Yes, we can basically use all application level messages without
> needing special ioctls. The driver just needs to tell us if it
> thinks the card can or cannot handle it.
Just return an error message if not ? (ioctl error ?)

>
>  > 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 ?
>
> For them there should be a library which handles all the different
> cards transparently. We'll have to come up with an API.
Is there any move as it is for such a library ?

>
>  > 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 ??
>
> Good question.
> Things like not supporting CA_PMT lists are of course harder to intercept
> because the message will have to be at least partially parsed to
> decide if one card can handle it or not. In this case it is just
> one byte in the CA_PMT message to check but in other cases it
> might be more complicated. Let's hope it will not get too messy ...
Not just CA cards, The manufacturer sent me a mail today that some of the FTA 
cards are also obsolete. They gave me a new list..

Another question that is off the topic is the ATSC cards are also on the same 
line, is it that we just detect the card and put out a message that it is an 
ATSC card ?

Manu
>
>
> Ralph