[linux-dvb] Re: DVB-CI question

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Monday 19 April 2004 17:07, Johannes Stezenbach wrote:
> Hi,
>
> I'm trying to finish my work on the V4 CI API. After a bit of thinking
> I made the following changes which I just comitted to CVS:
>
> - one device node for all slots on one CI controller
> - define API protocol units to be "raw, unfragmented TPDUs", i.e.
>   slightly above link level but not interpreted by the driver, so
>   the transport level must be implemented in user space;
>   this is the status quo of the V3 API and I think it makes much sense
>   to keep it that way
> - define poll(2) semantics; link/pyhsical layer polling is entirely
>   handled within the driver
>
> (this is not TOFU -- please read down below)

I have no real preference on whether read/write or the IOCTL interface is 
used.. but here are my thoughts on it:

* We're using the read/write interface at the moment.  Is there any real 
advantage to swapping to the IOCTL interface?

* If we supported more than just link level packets, we would have to extend 
the read/write interface anyway as we would need a way to specify the type of 
packet. However, another way of doing this would be for the driver to specify 
what type of packet must be used on a particular slot in the _caps structure. 
The userspace app then just sends the corresponding protocol structure on the 
read/write interface.



Other stuff:

* It would be good to add the max. size of a TPDU (or whatever protocol is in 
use) as a field to dvb_ci_capability. At the moment, everyone is hardcoding 
it to 2048 bytes because that is what is necessary for the av7110 cards. But 
this isn't the case with the budget-ci, so it would be nice to have the 
limits explicitly returned by the driver.

* Is DVB_CI_CAM_IOERR useful? The budget-ci driver returns -EIO if a write 
operation failed, and automatically restarts the link initialisation 
protocol. I suppose it would be useful if the renegotiation fails multiple 
times though... perhaps it should just be called DVB_CI_CAM_FATAL_ERR (or 
something), and used to indicate when the CAM appears to have locked up and 
needs a reset.

* I assume we would have the protocol structures to be sent over read/write 
(if used) defined in the ci.h header.

* As for whether we need to support different types of protocol, I cannot 
comment... to quote Ralph's original message:

> If you keep the interfaces between layers general enough it should
> also be no problem to support drivers with other interfaces (like the
> av7110 cards or also the Twinhan cards with even higher level interface) 
> with the same code. 

What these "higher level" interfaces are was never discussed. I assume higher 
level in EN50221, but I may be wrong.


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.