On Wed, 21 Jan 2004, David Brownell wrote: > Date: Wed, 21 Jan 2004 18:03:59 -0800 > From: David Brownell <[EMAIL PROTECTED]> > To: John Heil <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], > linux-usb-devel <[EMAIL PROTECTED]> > Subject: Re: [linux-usb-devel] Re: Test of ehci iso patch > > John Heil wrote: > > > The delay I found was that the periodic frame list was completely > > full and no more slots were available. The callback code was > > not freeing urbs fast enough. > > So I was right -- the problem _was_ in your driver. A simple > policy of keeping only 200 msec of buffers queued wouldn't have > had such problems, in any hardware config. >
Initially my value was small, then I gradually increased it to its present level... reasons are below. Another way to look at it is that my loading of the frame list, revealed an inefficiency in top-half in_interrupt() processing, which I've now fixed :) > Why are you queuing so many URBs? If I were to suggest a policy > for how deep a transfer queue _should_ be, I'd have started with > something smaller, like 16 or 32 msec ... that's enough to cover > a reasonable amount of IRQ blockage, especially when you can rely > on realtime deadlines with the video processing. > We decided, here, to keep the frame list full to assure that no video data packet is ever missed/lost and a full list seemed the best chance to that. The stream will need to endure the piggy-backed audio as well as an in-driver video frame grab facility. (I will try backing it down once again and see if I can still maintain 100% delivery.) Also the list had to be filled to find any other potential bottlenecks in the path(s) (yes, we actually did discussed it from that perspective) ...and indeed, there _was_ one... filling the list means callbacks can't keep up... One solution: pop completed iTDs etc out of the list and queue them for callback processing in tasklet land... Seems to me, a more linux classic top-half/bottom-half approach to driver/device management ie keeping your top half as lean as possible and offloading non-critical work to bottom-halves aka tasklet land. > > > Anyway, I completed the callback-by-tasklet mod today and it solved > > the CATC detected wait state! :) > > ... but it doesn't seem like you needed to change EHCI at all. > As I know, since the driver was happily streaming for me too! But did you CATC your packets and assure that no extra SOF's were sneaking in without data? I do & did, and as of today, none are any longer. :) > > - Dave > I did not modify Michal's/your most recent code... I started modifying the original 2.6.0-test9 level of the ehci core code long before your latest ehci patch group based on Michal Sojka's patch for test7. I had looked at Michal's test7 patch when you suggested it but I had already begun altering test9 and I could not get the initial patch to go on cleanly (I did not chase it down as I probably should have.) Michal's mods were significantly different from what I had done, so I continued on w test9. Also I noted the kmalloc's which mine did not have, and thought they might be an issue. This code is ultimately destined to run on a much slower ARM arch Intel Xscale, relative to the P4/Centrino combo I'm developing on. I am going to have to live w 2 NEC controllers instead of one fast intel southbridge, since one NEC can't handle the write side of the video load once the read load is present. Given the application and other driver space loads on it, I'm concerned about it being too slow... so I need to get the video as fast as I can. Once I get this running on the actually hardware at 3K*2, I will be trying out the new code and OProfile'ing both as well as possibly a hybrid of the 2 appoaches and I'll post what I find. johnh - ----------------------------------------------------------------- John Heil South Coast Software Custom systems software for UNIX and IBM MVS mainframes 1-714-774-6952 [EMAIL PROTECTED] http://www.sc-software.com ----------------------------------------------------------------- ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
