On Sunday 09 March 2008 05:37:04 Andy Walls wrote:
> Hans Verkuil wrote:
> > > Here's my observation: There was no good reason for q_full to
> > > stay empty for so long (> 5 seconds), just because data was
> > > sitting queued in q_io. It was as if data stopped being moved
> > > from the encoder to buffers and into q_full. What is both
> > > fortunate and unfortunate is that draining q_full and q_io, seems
> > > to restart the transfers from the encoder.
> > >
> > >
> > > So to test these hypotheses, I'll have to gain some understanding
> > > of the new mailbox protocol and the Memory Descriptor List stuff
> > > and do some testing with the fix to cx18_v4l2_enc_poll() backed
> > > out.
> >
> > Look for 'CX18_CPU_DE_SET_MDL' in cx18-fileops.c: this is where the
> > processed buffer is returned to the firmware so that it can be used
> > again. Based on your description I was wondering whether in some
> > cases all or most buffers are in use and the firmware will just
> > stop capturing due to a lack of available buffers.
>
> Argh. I'm giving up on hunting this down for now. Here are my
> observations and speculations with the return value of
> cx18_v4l2_enc_poll() does not depend on q_io.length:
>
> a) The most buffers I've ever seen in use in the driver are 1 in q_io
> and 10 in q_full. That was when then encoder decided to give the
> driver 10 buffers all at once. (What good is q_io anyway in the cx18
> driver? It seems like a lot of book keeping just to store the 1
> partially read buffer. Would pushing a partially read buffer back on
> the head of q_full be that hard?)
This code is basically copied from ivtv (where bookkeeping is much more
complicated still). It might well be replaced by just pushing it back
to q_full for this driver.
> b) I can always get the transfer from the encoder to stall.
>
> c) stopping the capture, reloading all the MDLs and restarting the
> capture doesn't make transfers from the encoder work again.
>
> d) a common sequence of failure looked like the following, with the
> encoder sending a small (2048 bytes) buffer, the driver returning 2
> MDLs very close together, and then the encoder sending only one more
> buffer:
...
>
> I changed the cx18_read() function to exit the loop and return once
> it had returned 1 MDL to the encoder, but the problem still
> persisted. In this case the short buffer in at least one trial was
> 4096 bytes.
>
>
> e) I don't know what to make of it all without some specific commands
> to query the encoder's status, use of MDLs, and timeouts. I could
> take a closer look at the MDL acks and the irqs and irq acks, but I'm
> not that motivated at this point. The driver/encoder transfer
> performance is good enough for me for now with the return value logic
> of the cx18_v4l2_enc_poll() function fixed.
Is it possible to reproduce it by writing a small capture program that
acts similar to MythTV? If I had a program like this, then I could
investigate.
Regards,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
