On Sunday 09 March 2008 21:08:04 Andy Walls wrote:
> 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?
And to both questions I have to say: not a clue. I'll have to dig a bit
more in the data I do have and will probably have to ask Conexant.
There are some companies that give you datasheets that are complete and
understandable. Unfortunately, Conexant isn't one of them. I think you
read the cx25840 datasheet and that should give you some idea of what I
mean. 90% of the info you need is there, but there is always that
missing 10% that they didn't include and another 10% that is written so
badly that you can't figure out what they mean exactly.
What's worse is that they often have features in their datasheets that
are not actually implemented. Very irritating.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
