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

[Ralph Metzler <rjkm@metzlerbros.de>]

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.

Of course the CA_PMT message starts with the same byte anyway, 
why is it repeated in the header?
This explains why nothing changed when I only changed it in the
message ...

 
 > 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. 

 
 > 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.



 > 
 > 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 ...


Ralph