[linux-dvb] Re: DVB-CI question

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

[...]

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

Agreed. Until someone actually implements support for hardware which really 
needs it, we've no idea of what requirements are necessary, so anything we do 
is likely to be incorrect.

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

Oh yeah, it definitely does. It has *three* separate fragmentation systems all 
layered on top of each other! They're supposedly there to get round buffer 
size limitations in the underlying protocols and hardware. They don't provide 
a standard way to know these limits, so I assume a particular implementation 
is just expected to find out in some implementation-specific way. 

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

yeah.

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

yup.


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