> When the original urb is submitted, are you supposed to
> put 64 bytes in the urb, and then 36 bytes in the next urb
> (you as in the driver writer), or is this supposed to happen
> transparently inside the urb resubmission code?
Neither ...
> ie do I submit an URB with 100 bytes of data, or d
Perhaps I'm just being thick here but I'm missing a vital point about
interrupt transfers (well interrupt out transfers at least).
With an interrupt in, you get a callback every now and again, you
look to see what actual_length is, if it's not zero, you copy data
to your own buffer and return. Th
On Tue, Feb 19, 2002 at 11:30:02AM -0800, David Brownell wrote:
> > > And why there's that issue I mentioned (reported in Janary by
> > > Wolfgang Mües) about changing the _length_ of an OUT transfer.
> > > I've some comments I hope to send out, but can't do so much before
> > > Wednesday.
> >
> >
Hello David!
> So, the INTR-OUT problem. For example, maxpacket size is 64,
> period is maybe 8, but the driver needs to send 100 bytes. That
> adds up to 64 bytes in one frame, then 36 bytes after a delay of
> 8 frames ... then wanting to stop/unlink. This is one problem that
> the LEGO folk
> > And why there's that issue I mentioned (reported in Janary by
> > Wolfgang Mües) about changing the _length_ of an OUT transfer.
> > I've some comments I hope to send out, but can't do so much before
> > Wednesday.
>
> It would work if most of the time the interrupt OUT URB could have a
> tran
> I'm puzzled about this thread. As I understand the discussion, seems that
> someone is using an interrupt out for a small amount of data and, for some
> unknown reason, the last data packet is being resent on each "interrupt"
> interval. ...
There are some known reasons this failure mode might
This is starting to make more sense now. I've been playing with the LEGO driver and
that's why I started asking these types of questions several days ago.
When the original urb is submitted, are you supposed to put 64 bytes in the urb, and
then 36 bytes in the next urb (you as in the driver wr
"> " = Vladimir Dergachev
"> > " = Vojtech Pavlik
"> > > " = David Brownell
> > > By the host controller driver. It's a "periodic" transfer,
> > > which _by design_ is going to be happening over and
> > > over and over again.
> >
> > Which is a problem. All uses of interrupt out I have me
On Tue, 19 Feb 2002, Vojtech Pavlik wrote:
> On Tue, Feb 19, 2002 at 02:59:28AM -0800, David Brownell wrote:
>
> > By the host controller driver. It's a "periodic" transfer,
> > which _by design_ is going to be happening over and
> > over and over again.
>
> Which is a problem. All uses of int
ay, February 19, 2002 3:50 AM
> To: David Brownell
> Cc: Roland King; Simon Gittins; [EMAIL PROTECTED]
> Subject: Re: [linux-usb-devel] stopping interrupt transfers..
>
>
> On Tue, Feb 19, 2002 at 02:59:28AM -0800, David Brownell wrote:
>
> > By the host controller driver. I
On Tue, Feb 19, 2002 at 02:59:28AM -0800, David Brownell wrote:
> By the host controller driver. It's a "periodic" transfer,
> which _by design_ is going to be happening over and
> over and over again.
Which is a problem. All uses of interrupt out I have met don't need to
be periodic - they're
> It seems to me that the distinction between interrupt transfers and bulk
> transfers is somewhat artificial.
If you ignore bandwidth and other resource allocation issues, yes.
But those are very real issues in many systems.
"On the wire" you don't see much difference, except that there are
par
> Hmm.. What would happen if I try to send a URB with 0 data size ?
UTSL ... or experiment!
Frankly it seems to me like a poor idea to be sending periodic
empty interrupt transfers, but I'm sure someone will say they
would like to use that as a device keepalive function!
- Dave
_
"> > " == Roland King
"> " == Vojtech Pavlik
> > This is a little similar to the discussion we were having last
> > week about how to do interrupt transfers on the usbdevfs
> > interface. The answer seemed to end up being that you should
> > just do bulk transfers.
"Seemed" -- if you can arrang
On Mon, Feb 18, 2002 at 06:58:28PM -0500, Roland King wrote:
> This is a little similar to the discussion we were having last
> week about how to do interrupt transfers on the usbdevfs
> interface. The answer seemed to end up being that you should
> just do bulk transfers.
>
> I have read the US
uncommon that we
>shouldn't abstract it into some sort of easier process?
>
>Thanks
>Simon Gittins
>
> > -Original Message-
> > From: David Brownell [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, 19 February 2002 7:16 AM
> > To: Vladimir Dergachev;
day, 19 February 2002 7:16 AM
> To: Vladimir Dergachev; [EMAIL PROTECTED]
> Subject: Re: [linux-usb-devel] stopping interrupt transfers..
>
>
> Right now the only portable solution is rather awkward.
> That is:
>
> (a) make sure urb->interval is long enough that it&#
Hmm.. What would happen if I try to send a URB with 0 data size ?
thanks
Vladimir Dergachev
On Mon, 18 Feb 2002, David Brownell wrote:
> Right now the only portable solution is rather awkward.
> That is:
>
> (a) make sure urb->interval is
Right now the only portable solution is rather awkward.
That is:
(a) make sure urb->interval is long enough that it's
probably not going to suffer interrupt/scheduling
latency problems (causing extra transfers), and
submit the URB
(b) have your completion handler signal the thread
19 matches
Mail list logo
