George Campbell wrote:
>
> i'm working with an older version of the kernel so the interfaces may have changed,
>but couldn't you just use:
>
> tty->ldisc.recieve_buf( tty, data, NULL, urb->actual_length );
I had a look at this.
This would work assuming low_latency is set (which is it in most
On Tue, May 22, 2001 at 04:49:49PM -0700, David Brownell wrote:
> > Thus, if I was writing and my bulk out endpoint STALLed, then yes, I want
> > the string of bulk-out transfers to all fail with -EPIPE. However, if
> > there is a bulk-in transfer in the chain, why not do it?
>
> Because that IN
Announcing: USBMon Version 0.2
USBMon is an attempt at a free solution to USB monitoring in Linux.
I announced an early development version a while ago, things have moved
along quite a lot now - USBMon now has some actually useful functionality.
See amazing screenshots at
http://www.dcs.ed.ac.
> This sounds like exactly what I want. Perhaps waiting for shared-code
> merging will bring about everything I'd like to see
That'd be nice! Or use it with EHCI before other hcds start to use
the "sharable" code. I saw a high speed CD-RW on the web...
> Thus, if I was writing and my bul
On Tue, May 22, 2001 at 01:11:12PM -0700, David Brownell wrote:
> > My hope was that I could use the fact that the ->next pointer doesn't
> > submit the data stage URB until _after_ the command stage URB is completed.
>
> As I say, this is naturally done in the completion sequence,
> outside the
> Now with queued URBs:
>
> - Submit a chain (URB_1, URB_2) immediately to the HCD
>/* I think we still need to submit both URBs seperately? */
Certainly each "submit" can report errors immediately ... which
is why I don't quite know what it should mean to submit the
had of a list of bulk UR
> My hope was that I could use the fact that the ->next pointer doesn't
> submit the data stage URB until _after_ the command stage URB is completed.
As I say, this is naturally done in the completion sequence,
outside the HCD (and today, in the completion handler).
My main issue is that the HCDs
On Tue, May 22, 2001 at 09:35:52AM -0700, David Brownell wrote:
> So in many typical cases, multiple endpoints are involved.
Yes. But, the number of endpoints involved varies, depending on the
device.
> > Data is always passed via bulk endpoint. The SCSI layer will allocate the
> > scatter-gat
Heh ... we'll find ways to get better performance from usb-storage
for sure! :)
> All storage device transfers can be looked at in terms of 3 phases:
> command, (optional) data, and status.
>
> All service options require an URB for the command, either to a control or
> bulk endpoint.
> Status
Hi all,
I think the main problem with the ->next pointer is that it
is designed without queueuing in mind. But all!!!
transfer types can use some sort of queueing because
we can not guartantee that the CPU can handle a HC interrupt
immediately (and therefore without transfer queueing we get gap
10 matches
Mail list logo
