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 :)
You've still not convinced me there's a top-half problem; though it's clear that lack of a bottom half for your driver was an issue.
Since the issue is demonstrably not general (none of the other ISO drivers have it), and has a fix that doesn't involve changing the EHCI code, I'd need more convincing before I could be happy with changing any of that lower level code.
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.
OK ... but then define "full" as more like 200 msec than 256!
If you preallocate N urbs and just recycle them, you won't need to cope with fault modes for schedule ceilings of N+1.
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.
I kept one kmalloc (for ehci_itd_sched + N * uframes), which would be easy enough to remove by using a freelist. That is, if it turns out to matter.
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.
Isn't their EHCI 1.0 product fast enough? VT6212 might do the job for you.
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.
I look forward to your results!
- Dave
------------------------------------------------------- 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
