On Thu, 22 Jan 2004, David Brownell wrote: > Date: Thu, 22 Jan 2004 13:30:35 -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 :) > > 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. >
Understandable. USB 2.0 video is just too new but as it matures I expect the issue may present itself later on as multiple hispd devices start to compete. We just happen to be pushing the envelope now w stringent requirements. > > > 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 did/do preallocate and recycle. The newer part was trying to hug the ehci as it progressed thru the list, by watch its frame counter and sched'ng into the freed space. I will slack off to 200 msec and see how it flies. > > > 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. > We've looked at every EHCI vendor's products and did try the 6212. It wasn't even close. NEC was the best but PCI Bus analyis showed that it had a fatal flaw, insufficient write buffering: it reads fine but on the write side output doesn't match; of the 6 1k blocks involved, the best it handle was only 4 of them. As I did not personally to the PCI analysis, I don't recall the actual timing values but I can find them if you are interested. Anyway, the hw folks decided to use 2 NEC's 1 in and 1 out. > > > 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 > Thnx much, 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
