[linux-dvb] Re: DVB-CI question

[Johannes Stezenbach <js@convergence.de>]

On Thu, Apr 22, 2004 at 12:09:56PM +0100, Andrew de Quincey wrote:
> 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?

No, I just thought it would make the code more explicit. But I guess
V3 was only confusing because we had both read/write and ioctl, and
the packet format for read/write was undefined.

I guess I remove the ioctls and settle with read/write in V4.


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

I think if we want to implement higher level protocols we need
additional ioctls or message types, e.g. for the transport layer
we'd need a notification for terminated transport connections.

All in all I think that's not worth it, and we should just support
the current link layer interface.


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

This might be a good idea, however it means that some drivers are
inherently broken, as the standard does not allow for such limitations?


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

Yes, the intention is to mark the CAM as broken, not to return error
information for individual TPDUs. One could just time out waiting for
DVB_CI_CAM_READY after the cam has been inserted, but DVB_CI_CAM_IOERR
is more explicit. Maybe a better name is DVB_CI_CAM_ERROR?


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

The ancient av7110 DVB driver/firmware used a "high level" protocol
for CI, with partial application layer support via special messages
(see CI_MSG* and CI_CMD* in drivers/media/dvb/ttpci/av7110_hw.h).

However, this protocol is so proprietary that I don't see how to map it
into a standard API, so I don't think we should worry about it.


Thanks for your comments,
Johannes


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