On Fri, 6 Feb 2004, David Brownell wrote:
> Date: Fri, 06 Feb 2004 11:57:41 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: linux-usb-devel <[EMAIL PROTECTED]>,
> John Heil <[EMAIL PROTECTED]>
> Subject: Re: [linux-u
Michal Sojka wrote:
*frames per urb
* *lengths of valid data
* *length of mess
*
16
27520
4472
But you said this was at 2 KB/uframe high bandwidth rate, so that
math doesn't check out: 16 frames/urb * 8 uframes/frame * 2 KB/uframe
means 256 KByte/urb, not 128 bytes shy of 27 KB.
Sorry. Formating of the table was broken. Here is fixed version:
Michal Sojka wrote:
I have measured how the length of chunks depends on uframes per urb and
here are results:
*frames per urb* *lengths of valid data* *length of mess*
16275204472
12
Hi Dave,
today I tested more the ehci code and my results are as follows.
David Brownell wrote:
You should explain more about your tests. Sounds like IN transfers
with two 1KB packets per uframe. How big are your URBs ... how many
uframes each? And how deep is your URB queue? Are these "erro
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]>
> Subjec
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 hav
On Wed, 21 Jan 2004, David Brownell wrote:
> Date: Wed, 21 Jan 2004 17:53:16 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> linux-usb-devel <[EMAIL PROTECTED]>
> Subjec
On Wed, 21 Jan 2004, David Brownell wrote:
> Date: Wed, 21 Jan 2004 18:03:59 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> linux-usb-devel <[EMAIL PROTECTED]>
> Subjec
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 hav
John Heil wrote:
I looked back at my driver code and it does set each URB to
URB_NO_INTERRUPT, however, in itd_fill I set the EHCI_ITD_IOC bit
on the last transation of each iTD, thus overriding URB_NO_INTERRUPT
Why would you want to force IRQ-per-iTD? Hmm, and I noticed that
the URB_NO_INTERRUPT
On Wed, 21 Jan 2004, David Brownell wrote:
> Date: Wed, 21 Jan 2004 11:49:21 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> linux-usb-devel <[EMAIL PROTECTED]>
> Subjec
On Wed, 21 Jan 2004, David Brownell wrote:
> Date: Wed, 21 Jan 2004 11:45:22 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> linux-usb-devel <[EMAIL PROTECTED]>
> Subjec
I meant: 2048 bytes per transaction and 8 transaction per
URB/iTD and each read iTD is laterally chained to a write iTD and
the pair is anchored by a single periodic frame list slot so that
the controller re-reads the pair 8 times per slot.
There is a 1 to 1 mapping of urbs to iTDs.
Each iTD use
John Heil wrote:
On Tue, 20 Jan 2004, David Brownell wrote:
I'd recommend you do that in your device driver, instead.
Your completion callback can use urb->urb_list (so long as
the URB hasn't been submitted!) and schedule the tasklet.
I did the tasklets driver thing first and in that mode
I had
I meant: 2048 bytes per transaction and 8 transaction per
URB/iTD and each read iTD is laterally chained to a write iTD and
the pair is anchored by a single periodic frame list slot so that
the controller re-reads the pair 8 times per slot.
There is a 1 to 1 mapping of urbs to iTDs.
Each iTD use
On Tue, 20 Jan 2004, David Brownell wrote:
> Date: Tue, 20 Jan 2004 19:38:13 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> linux-usb-devel <[EMAIL PROTECTED]>
> Subjec
Hi John,
More later, but one quick comment:
Each urb at present has 2048 bytes so the mult bit is on and it
comes in 1K chunks. The production version will be about 2800+
so 3 chunks.
Interesting ... so eight urbs per uframe, one IRQ each 125 usec.
What happens when you make each URB larger, lik
On Tue, 20 Jan 2004, David Brownell wrote:
> Date: Tue, 20 Jan 2004 18:09:43 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: John Heil <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
> linux-usb-devel <[EMAIL PROTECTED]>
> Subjec
John Heil wrote:
On Tue, 20 Jan 2004, David Brownell wrote:
At one point I noticed schedule glitching if the URB queue got short enough
to empty; for now, that'll force a big (10 msec!) gap in the stream. If
that's an issue, the fix is using deeper queues in your host side driver.
Forgive my ju
On Tue, 20 Jan 2004, David Brownell wrote:
> Date: Tue, 20 Jan 2004 15:10:15 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: linux-usb-devel <[EMAIL PROTECTED]>
> Subject: [linux-usb-devel] Re: Test of ehci iso patch
>
> Michal S
Michal Sojka wrote:
We transfer a stream of four 16 bit channels over USB. In one channel
there is a sample number that increases every sample period. We use this
"counter" to detect errors in a stream. With my ehci patch I can
transfer aproximately 3 MB of data without any error. It's quite sma
21 matches
Mail list logo
