Hans Verkuil wrote:
> On Sunday 09 March 2008 00:26:55 Andy Walls wrote:
> >
> > Can you shed some light on what this error code 0x20100004 means in
> > the following context? The cx23418.h and cx18-mailbox.h files don't
> > make it obvious, aside from saying it really is a failure since (err
> > & 0xff) != 0 and that its of the type "ERR_DE_...".
>
> Yuck. The error is "MDL queue full", so apparently there is an
> (undocumented) MDL queue limit.
I guessed that there was a limit on MDLs. I did not expect the limit to
be undocumented though. Optimism fails me again. ;)
> This just might cause all sorts of mayhem.
Well, maybe; it depends on how you plan to use MDLs vs how the cx23418
designers envisioned MDLs being used.
As I understand it, each MDL is a scatter-gather list of buffers. So to
further figure out the designers' intent for MDLs, here are other givens
or assumptions I'll work under:
a. the firmware expects 2 MDL Ack structures per stream/task in the SCB,
b. about 15 CAPTURE_CHANNEL types, and hence tasks/stream, could be ever
be supported simultaneously
c. the firmware reports back filled buffers pointed to by an MDL by the
MDL id on a per task/stream basis
d. the firmware accepts setting MDLs per task/stream
e. the firmware *rarely* sends back more than 1 MDL (that has only 1 32k
buffer) back in a burst (I have seen 2, 3, 9, and 10 though)
f. the MDL list maintained in the firmware is a *global* resource for
all streams
g. the MDL list maintained in the firmware only has 63 entries.
If all of the above is true, then I suspect the designers expected the
host to maintain 2 to 4 MDLs for each stream type that could be opened.
Streams using 2 MDLs would have 1 MDL for the host to work on while the
firmware filled in the other - good for low data rate streams. This
could be extended to 3 MDLs for streams where the host might not be able
to always keep up with the encoder. A stream with 4 MDLs with smaller
buffers could be for lower latency streams (latency measured as time
elapsed from analog signal at input to digital data buffer sent to
host).
One thing to think about right now is how to use MDLs pointing to
multiple buffers in the cx18 driver as opposed to using every one of the
63 MDLs for one MPEG stream. If my assumption "f." is correct,
transferring the ATSC and MPEG streams simultaneously (my plausible use
case) will require allocation of the MDLs split between to the two
streams.
Tradeoffs with buffer sizes, number of buffers, numbers of MDL, and
numbers of simultaneous streams vs. encoding latency, host workload, irq
rate, and DMA memory regions will probably need to be made.
Ah-ha! that's the mayhem.
Do I seem way off on any of the above?
> You want to take a look at cx18_stream_init():
>
> s->buf_size = cx->stream_buf_size[type];
> if (s->buf_size)
> s->buffers = cx->options.megabytes[type] * 1024 * 1024 /
> s->buf_size;
>
> Try to change it to something like this:
>
> if (s->buf_size) {
> s->buffers = cx->options.megabytes[type] * 1024 * 1024 /
> s->buf_size;
> if (s->buffers > 64) { // or 63 is that's the max queue length
> s->buffers = 64;
> s->buf_size =
> (cx->options.megabytes[type] * 1024 * 1024 / s->buffers) &
> ~0xff;
> }
> }
>
> See if this works better.
That'll fix the one minor problem of only having 63 MDLs available, but
the encoder firmware never puts our 64th one into the rotation anyway.
.
I'll have to think about this one.
1. We want to honor the user's request for the specified memory to be
set aside per stream (assuming 1 stream of each type?).
2. We have no indication of the user's latency preference right now, so
I guess we get to pick: low for YUV, high for MPEG, medium for PCM, low
for TS from the ATSC side, low for VBI not synch'ed to MPEG?
3. We'd like buffer sizes to by multiples of 4 kB to be nice to the OS
for DMA regions, or are 256 byte multiples OK?
4. We don't want to use all the MDL list entries in the firmware.
Empirically no more than 11 are ever in use on my machine for an MPEG
stream with the encoder trying to compress a snowy, unstable NTSC video
signal with mono audio.
5. I'd prefer to work in support for multiple buffers per MDL at first
or at the same time, as not having it may cause problems eventually,
(IMO).
> Thank you for your work on this, I'm still working on ivtv issues and
> I
> don't think I'll have time for more cx18 work until after Easter. But
> if you have any questions, just mail me and I'll try to answer them.
No problem. I do the work to stay sharp (so I then can enter a
vegetative state watching digital TV...?).
I'll send any questions I have your way. I'm going to assume Conexant
or Hauppauge related NDAs may prevent you from answering some though.
As much as possible, I'd prefer to keep my communications in a public
forum like this mailing list vs. private email (for job/employer related
reasons).
Here are my first few questions:
Are there any buffer size minimums/maximums imposed by the CX23418 for
the various stream/CAPTURE_CHANNEL types?
What is the limit on the number of buffers that can be specified for a
single MDL?
Regards,
Andy
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
