I've done some of the requisite homework myself for getting full speed
audio devices to work properly through ehci and TTs on a 2.0 hub
(playback *and* capture). At this point it all works although my
changes are not production-ready.
I have three specific questions for now.
The primary reason
Hi David,
I thought my post got lost; I never saw it appear and hadn't seen
replies. Scratch that, I was *hoping* it got lost, as more code
research later showed each question was at least partially
nonsensical.
At this point, the actual ISO transfer machinery all looks perfectly
solid. The
One new question, hopefully this one is just rote arcana to one of you
The current scheduler strategy always tries to place a given periodic
request (be it iso or intr) into the same uFrame slot in all scheduled
HFrames. Is this a requirement of the spec (I don't recall seeing
such a
On 5/10/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
In some
ways it's easier to just stack requests into the full-speed frame and
then plop the splits into whatever uFrame that happens to work out to,
even if that means
On 5/11/06, Christopher Montgomery [EMAIL PROTECTED] wrote:
On 5/10/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
In some
ways it's easier to just stack requests into the full-speed frame and
then plop the splits into whatever
On 5/11/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 10 May 2006 9:38 pm, Christopher Montgomery wrote:
On 5/10/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
In some
ways it's easier to just stack requests
On 5/13/06, David Brownell [EMAIL PROTECTED] wrote:
On Thursday 11 May 2006 8:49 am, Christopher Montgomery wrote:
I also forgot the example of OHCI, which appears to do some/all of the
actual intraframe scheduling in hardware. Is it just sending out
transaction packets in the order they're
On 5/12/06, David Brownell [EMAIL PROTECTED] wrote:
Let me repeat that: TT scheduling and highspeed scheduling interfere
with each other. You can't perform one in ignorance of the other.
I believe we are vehemently agreeing with one another :-)
Correct, but the reason we need to shift in
On 5/11/06, David Brownell [EMAIL PROTECTED] wrote:
On Thursday 11 May 2006 8:49 am, Christopher Montgomery wrote:
(If so, the isos are occurring in totally random places in a given frame).
Nope. Periodic transfers take up the second 90% of the frame (at most).
And this doesn't have any
On 5/12/06, David Brownell [EMAIL PROTECTED] wrote:
That is, your beef is with the weak TT scheduling, which isn't something
that OHCI (or UHCI) does, and which accordingly can't be borrowed from
either of those drivers.
Vehement agreement. I'm looking to the other approaches and other
I've independently found Dan Streetman's ehci TT scheduler patches
looking for some other ssplit scheduling rule clarifications. He
implements the part I was going to do last [schedule counting]. At
this point, I've implemented the parts he didn't (FSTN and sITD
backpointer support for frame
Oh, a quick question that's been bugging me...
I assume that intr_submit() in ehci-sched.c also handles high-speed
endpoints (not just fs/ls endpoints). If so, why does
check_intr_schedule() not only blindly always assign a cmask, but also
blindly check that cmask against TT scheduling slots?
There is currently no FSTN support, just placeholder code in ehci-sched.c.
I have implemented FSTN support (along with sITD backpointer support)
and am in the process of implementing a new TT scheduler as well. My
work is currently against 2.6.17-rc3. Enough has happened in the USB
code that
I'm putting the finishing touches on the new EHCI scheduler and
noticed an interesting 'problem' in shutdown. In practice it usually
doesn't work out to being a bug, but it appears to be unintentional
and potentially problematic on slow CPUs when a hub with lots of
devices is detached.
In
I didn't reply to all. oops.
-- Forwarded message --
From: Christopher Montgomery [EMAIL PROTECTED]
Date: Jul 2, 2006 12:17 PM
Subject: Re: [linux-usb-devel] new EHCI scheduler and shudtown
question / interrupt race
To: Alan Stern [EMAIL PROTECTED]
On 7/2/06, Alan Stern [EMAIL
On 7/2/06, Alan Stern [EMAIL PROTECTED] wrote:
I don't understand the problem you are describing. The kernel doesn't
kill off an IRQ unless it gets a lot of unhandled interrupts (99900 out of
the last 10). But none of the interrupts you mention will be
unhandled -- ehci-hcd will handle
On 7/2/06, David Brownell [EMAIL PROTECTED] wrote:
On Sunday 02 July 2006 6:29 am, Christopher Montgomery wrote:
Disconnecting a hub/device causes two things to happen at the same time:
1) usb_disconnect is called on the root device.
2) each active transfer descriptor throws an interrupt
On 7/3/06, Alan Stern [EMAIL PROTECTED] wrote:
The part I forgot to mention is that usb-hub.c implements a magic
number of ten consecutive interrupt errors on a given hcd before it
starts aggressively resetting/downing hardware.
Ah, okay. That's different from what I thought you meant --
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
Ummm... I've lost track of the original question. What is suboptimal and
would be painful to fix?
The fact that when I unplug a hub/device the ehci work handler is
descheduling/rescheduling the endpoints repeatedly [because each hit
in the
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
Actually it is. Look in drivers/usb/core/hub.c at the
usb_set_device_state() routine.
will do.
Potentially tight doesn't have to mean tight. Higher-level drivers should
strive to avoid immediate resubmissions of URBs that fail because of
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
The only catch is that you have to make sure usbcore isn't in use, because
the kernel won't let you unload modules that are being used. For usbcore,
this means you first have to unload all the other USB driver modules and
you have to unmount
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
) before
deciding the endpoint EPROTO fault calls for tearing it down and
setting it back up. Active/submitted URBs potentially have nothing to
do with it; it is happening even when my devices are idle.
I'm not terribly familiar with
On 7/5/06, Christopher Montgomery [EMAIL PROTECTED] wrote:
/ the two lines below
*/
intr_deschedule (ehci, qh);
(void) periodic_qh_schedule (ehci, qh);
Oops
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 7:16 am, Christopher Montgomery wrote:
Odd ... interwoven certainly allows gaps, and all of your
additional details agree completely with the facts as I had
pointed out.
I think we both actually agree on all
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 8:30 am, Christopher Montgomery wrote:
/ the two lines below
*/
intr_deschedule (ehci, qh
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
To repeat myself: the instant the physical disconnect happens,
then pending transfers to that device's endpoints may trigger
USB transfer errors. And that can happen a LONG time before any
component of the USB stack (e.g. qh_completions)
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 8:42 am, Christopher Montgomery wrote:
The hub is plugged in doing nothing.
Except being regularly polled did anything happen about 4x/second.
It's certainly active. (Though there's some new autosuspend stuff
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
I'm hampered by lack of detailed knowledge of the driver. However it
seems to me that those two calls should affect the schedule (cheap) and
not the budget (expensive).
Oh, hmm. That's actually not a bad idea. Some part of me is saying 'duh'.
On 7/5/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 05 July 2006 1:52 pm, Christopher Montgomery wrote:
On 7/5/06, Alan Stern [EMAIL PROTECTED] wrote:
I'm hampered by lack of detailed knowledge of the driver. However it
seems to me that those two calls should affect
I see that's exactly what's happening. It merely seems unfortunate.
That sort of behavior is inevitable in hardware-parallel systems.
But it's also a rather minor failure mode, and the only folk who
seem to run into it are people tweaking host controller drivers
and adding lots of
On 7/22/06, Ian Stirling [EMAIL PROTECTED] wrote:
Config/... as my earlier message on USB - though with the bandwidth
enforcement
turned off so it actually plays sound, when plugged into the USB1 port.
2.6.17.
Basically - playing sound with
mplayer -ao alsa:device=hw=1 or whatever - and
On 8/4/06, David Brownell [EMAIL PROTECTED] wrote:
Did you try with 2.6.18-rc3? There's a Kconfig option for an
improved interrupt scheduler, which might help especially with
all those low speed devices.
Actually, assuming I'm reading the spec right, I've come to realize
Dan's improved
David,
Sorry my patches are taking so long to assemble. What is the current
correct kernel version against which to be patching?
Thanks, Monty
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's
While I continue working to split my scheduler patch up into smaller
bits that are easier to review, I've tossed the monolithic version up
on the web for testing.
http://web.mit.edu/xiphmont/Public/kernel/
Short summary: It's an attempt to write the first fully complete
bandwidth
[resending again; sourceforge's SMTP servers appear to be unhappy.
The original mails bounced back to me after timing out]
While I continue working to split my scheduler patch up into smaller
bits that are easier to review, I've tossed the monolithic version up
on the web for testing.
I'd not normally complain, but
I'll need to do addiitonal work and release an all new patchset of the
ehci-scheduler... just to deal with cosmetic whitespace changes?
Monty
-
Using Tomcat but need to do more? Need to
On 8/30/06, David Brownell [EMAIL PROTECTED] wrote:
On Wednesday 30 August 2006 4:36 pm, Christopher Montgomery wrote:
I'd not normally complain, but
I'll need to do addiitonal work and release an all new patchset of the
ehci-scheduler... just to deal with cosmetic whitespace changes
On 8/31/06, Greg KH [EMAIL PROTECTED] wrote:
Does this patch conflict with yours?
I read the first few pages, it does. However, something massively
messed the size of the thing when I saved it out to read in emacs. I
thought this was a 10,000 line or so patch. it isn't; it's relatively
On 8/31/06, David Brownell [EMAIL PROTECTED] wrote:
I'm committed to seeing this patch to either oblivion or production,
and globally altering whitespace is going to blow my time for *no net
benefit to anyone*.
Cleanups like these _do_ have benefit.
Never said otherwise. I'd objected for
I've been able to complete an updated [bugfix] version of the new
ehci-scheduler patch that should address the bug reports that have
come in.
The download page for the new version (available for 2.6.17 through
2.6.18-rc7-git4) is at:
http://web.mit.edu/xiphmont/Public/kernel/
The direct links
Hello David and Greg,
I've completed an incremental version of my patchset for the new EHCI
scheduler. It is broken up into 14 seperate patches and each
incremental yields a valid/working ehci scheduler. Naturally,
they're all meant to all be applied at once but they can be evaluated
On 9/22/06, Greg KH [EMAIL PROTECTED] wrote:
Should I post them to the list or this sufficient?
Please post them.
OK. Any specific subject line format? The pattern I've seen for
other patches has been for patches already signed off on.
Monty
On 9/25/06, Gerhard Pircher [EMAIL PROTECTED] wrote:
1) The EHCI driver uses a structure called echi_qh, which contains
both data to be accessed by the USB hardware through DMA, and
private housekeeping data.
Yes. I am currently tromping through all of this code with steel-toed
boots
On 9/23/06, Greg KH [EMAIL PROTECTED] wrote:
Read Documenation/SubmittingPatches for the proper format.
Thank you.
There's at least one bug that turned up just before the weekend that I
want to quash first, then I will update the patchset and post.
Monty
Hello,
This set of patches implements abstracted budgeting logic for the ehci
scheduler that both takes advantage of hardware features not currently
exploited by the current schedulers (FSTNs and sITD backpointers) and
makes a greater effort to get the niggling corner cases of scheduling
45 matches
Mail list logo
