On Sun, 20 Jan 2008, Jon Smirl wrote: > On 1/20/08, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > > Sorry ... I thought he had posted lcpci showing a NEC controller > > > > with EHCI *and* OHCI. > > > > > > It is a NEC controller with both. But I have 1.0 hub plugged in with > > > three 1.0 devices in it. The 1.0 hub causes the OHCI controller in > > > the NEC to be used. > > > > > > I have had even worse luck trying to get three USB audio devices > > > working on 2.0. That NEC chip is a single-TT EHCI implementation. > > > > Actually it's a NEC chip with a zero-TT implementation. ;) > > > > I forget why our high speed root hubs lie about having a TT. > > They probably don't need to do that, except for the ones that > > don't have companion controllers. Like the silicon using the > > IP from ARC, Mentor, and so on.
As far as I can tell, there's no reason at all for the root hubs to lie about having a TT. Although then the code in hcd.c:rh_call_control() would have to be expanded to handle the ARC/Mentor/etc. class of controllers. It wouldn't be hard to do. > I tried this setup a while ago on a single-TT 2.0 hub. It would seem > that 4.2Mb of audio data wouldn't fill up a 480Mb channel. The 480-Mb bandwidth between the computer and the hub doesn't matter. What matters is the 12-Mb single-channel bandwidth between the hub and the devices. With multiple TTs it would be 12-Mb multiple-channel and the constraints would be looser. However it certainly is true that even a 12-Mb single channel shouldn't be overloaded by 4.2 Mb of audio data. And in reality it isn't, as can be seen from the fact that your USB-1.1 hub works almost all of the time. The difficulty lies in scheduling the split transactions that fill and empty the TT; that's where there may be room for improvement. > But that's > when I learned about single-TT hubs, the audio would drop out because > of scheduling problems. I tried some of the scheduling patches which > helped but didn't fix it 100%. There's a thread about it in archives > somewhere. I think you were helping, it was about nine months ago. I don't know if there have been any changes to the scheduling code since then. IIRC your earlier tests were made at about the same time the most recent set of improvements were added. > Someone suggested that I switch to a 1.0 hub. I've been using the 1.0 > for the last nine months. The only problem is that it drops all of the > devices about once every 20 hours. That's not a scheduling problem; it appears to be a firmware problem in the hub. Hard to say for certain without the debugging log. > I'll giving up on building a new kernel for the slug, there are way > too many manual steps involved. > http://www.nslu2-linux.org/wiki/Debian/BuildImage > It's just taking too long. I'll ask on the NSLU2 ground maybe someone > will point me at an automated x86 build environment. Why not forget about the slug for a while, and instead dedicate a regular desktop PC to testing for a couple of days? > > Disconnecting isn't what I'd call a PNP issue. > > I think of PNP as being able to plug in three 1.0 audio devices and > have it work on the first try without going through three different > hubs (1.0, 2.0 single-tt, 2.0 multi-tt) to find one that works > reliably. This is a matter of definitions. Is faulty hardware a PNP issue? I'd say it isn't, because faulty hardware can cause problems in any environment -- whether PNP or not. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
