[linux-dvb] Re: DVB-CI question

[Johannes Stezenbach <js@convergence.de>]

On Fri, Mar 26, 2004 at 03:27:10PM +0000, Andrew de Quincey wrote:
> On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
> > Andrew de Quincey wrote:
> > > ...
> > > Its just it makes the driver's IO routines _really_ complex, as they have
> > > to deal with multiple connections, multiple slots, the possibility that
> > > the CAM can be yanked out by the user at any time, and lots of other
> > > things. There is a LOT of complex locking involved to ensure it can't
> > > break.
> > >
> > > Add to that the fact that each de-fragmented packet can be up to 65536
> > > bytes,
> >
> > Strange, from what I know a TPDU can be at most 2048 byte long...
> >
> > Maybe you could take a quick look at VDR/ci.c and let me know whether
> > the data VDR exchanges with the CI already consists of the "fragements"
> > you're referring to.
> 
> From looking at it, you're talking about transport layer fragmentation based 
> on T_DATA_LAST/T_DATA_MORE.
> 
> I'm talking about the layer below that: Each of those TPDU fragments can be 
> further re-fragmented into multiple link layer packets when they're actually 
> written to the CAM. Link layer packets can be up to 65535 bytes. I suppose I 
> could use knowledge of the fact that the higher layers will never send 
> anything more than 2048 bytes to optimise that though.

I don't know that much about the CI cruft, but IMHO
EN50221 says that link-layer fragments are of the same size
as the pyhsical layer fragement (annex A.3.2), and the
buffer size for the physical layer is negotiated between
the CAM and the host (annex A.2.2.1.1, buffer size negotiation
protocol). The av7110 implementation uses the minimum required
buffer size of 256 bytes (or less, according to negotiation).

Johannes


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