On Tuesday 23 May 2006 12:27 pm, Christopher Montgomery wrote:
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).
Yes ...
If so, why does
check_intr_schedule() not only blindly always
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?
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 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 queued?
Starting 10% into the frame, yes. Recall
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
On Friday 12 May 2006 12:22 pm, Christopher Montgomery wrote:
I'm looking at things from the view of the FS/LB bus and the frame on
that bus. In the use cases I'm currently concerned about, the high
speed bus (and any one uFrame) is never going to run out of bandwidth.
I'm more concerned
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 into
The EHCI FS/LS sceduling should probably be aping the OHCI
behavior as it's known to work well.
No; ohci-hcd does some best fit logic, which happens to be cheap for
that hardware. Whereas ehci-hcd uses first fit, because it's costly
to do highspeed scheduling.
I don't mean
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 Thursday 11 May 2006 8:49 am, Christopher Montgomery wrote:
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
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 into the full-speed frame and
then plop the splits into
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 Wednesday 10 May 2006 10:35 am, Christopher Montgomery wrote:
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 restriction)
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 that,
On Wednesday 03 May 2006 1:03 pm, Christopher Montgomery wrote:
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
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
18 matches
Mail list logo
