Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Twinhan CA



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?
Or do we need anything else?

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


Ralph


 







Home | Main Index | Thread Index