On Mon, May 21, 2001 at 08:48:03PM -0700, David Brownell wrote:
> Do you have enough statistics about those scatter/gather segments
> to come up with a reasonable first-cut performance model? For
> example, how big would each s/g segment be? How many segments
> would get queued at a time? How m
Hi Matt,
> > I can see why multi-buffering might be useful to handle scheduling overruns
> > in controlled-bandwidth i/o (periodic transfers otherwise require real-time
> > scheduling) but that reasoning doesn't apply to bulk or control transfers.
>
> Well, where I sit, there is a large gain fro
On Mon, May 21, 2001 at 06:24:11PM -0700, David Brownell wrote:
> I can see why multi-buffering might be useful to handle scheduling overruns
> in controlled-bandwidth i/o (periodic transfers otherwise require real-time
> scheduling) but that reasoning doesn't apply to bulk or control transfers.
Hi Brads,
Drivers for Divio's PC camera are also in active development. You may add this
piece of the information to the draft.
Thanks.
Regards,
Tong Wu
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/l
> > [...] Please verify that the iso problem shows up with the ohci-0520.patch I
> > just posted; there's a change there that might explain some crashes. I suspect
> > it won't affect the iso problem, but that needs to be checked.
>
> It completely fixed the "error -110" and bus reset problems I
> > To my way of thought, by design/architecture as well; and that text
> > was just a bug. (One can argue "design bug" or otherwise.) Maybe
> > some of the folk who advocated URBs in the first place will disagree.
>
> usb-uhci does what the spec says, or the spec does it like usb-uhci, you ca
David Brownell wrote:
> From: "Mark McClelland" <[EMAIL PROTECTED]>
> >
> > I looks like the problem you are seeing is the same one people are
> > having with OV511 cameras on OHCI. They used to work with 2.4.3, and in
> > 2.4.4 they either crash the kernel or produce corrupted images. The
> > ca
On Mon, May 21, 2001 at 03:02:09PM -0700, David Brownell wrote:
> > > Near as I can tell, that bit of text has never been correct ...
> > > Clearly it's wrong today, and has been so for the last year!
> >
> > Never been correct? Do you mean by design? Or by implementation?
>
> Yes! :)
>
> Clea
> > Near as I can tell, that bit of text has never been correct ...
> > Clearly it's wrong today, and has been so for the last year!
>
> Never been correct? Do you mean by design? Or by implementation?
Yes! :)
Clearly by implementation, "facts on the ground".
To my way of thought, by design/a
Hi,
Does anyone know if there is an autoconf macro that uses
libusb-config to check for libusb? If there is one would you
please let me know where I can get it.
Regards
g
--
Glenn Ramsey
[EMAIL PROTECTED]
___
[EMAIL PROTECTED]
To unsubscribe, use th
On Mon, May 21, 2001 at 05:36:34PM -0400, Johannes Erdfelt wrote:
> > Yes, I realize that I could try to prep the next URB while one is running,
> > but then there are synchronization problems. So, if I'm preping them all
> > in advance anyway
>
> I dunno if that's possible. If one of the pr
On Mon, May 21, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > Wait... different answer here can this be done with ->next? People
> > > seem to have different opinions here. Some say ->next is for ISO only.
> >
> > That's incorrect. From Documentation/usb/URB.txt:
> >
> > - URBs can
> > Wait... different answer here can this be done with ->next? People
> > seem to have different opinions here. Some say ->next is for ISO only.
>
> That's incorrect. From Documentation/usb/URB.txt:
>
> - URBs can be linked. After completing one URB, the next one can be
> automatically su
> What I'd _hope_ for is this: I construct a chain of arbitrary URBs in a
> linked list via the ->next pointer. I send the chain to the API, and now I
> go to sleep while I wait for a completion message from the last URB.
But when you see a fault from one of the intermediate URBs, what then?
S
On Mon, May 21, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> On Mon, May 21, 2001 at 04:52:58PM -0400, Johannes Erdfelt wrote:
> > On Mon, May 21, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > >That is, I want to move several URBs for one
> > > > endpoint, and _when_they_are_done_,
On Mon, May 21, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> Hi Johannes,
>
> > > > What's the difference between queuing URBs with the USB_QUEUE_BULK flag or
> > > > with the next pointer?
> > >
> > > I think QUEUE_BULK is the only way to queue bulk URBs,
> > > and the "next" pointer is on
On Mon, May 21, 2001 at 04:52:58PM -0400, Johannes Erdfelt wrote:
> On Mon, May 21, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > >That is, I want to move several URBs for one
> > > endpoint, and _when_they_are_done_, I want to move an URB for another
> > > endpoint. And, it doesn't mat
Hi Johannes,
> > > What's the difference between queuing URBs with the USB_QUEUE_BULK flag or
> > > with the next pointer?
> >
> > I think QUEUE_BULK is the only way to queue bulk URBs,
> > and the "next" pointer is only for scheduling rings of ISO urbs.
>
> "only" is incorrect. It can be used
On Mon, May 21, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > What's the difference between queuing URBs with the USB_QUEUE_BULK flag or
> > with the next pointer?
>
> I think QUEUE_BULK is the only way to queue bulk URBs,
> and the "next" pointer is only for scheduling rings of ISO urbs.
Hi Matt,
> Are there any plans to make the next pointer work for all URB types? That
> is, a pointer such that, once an URB is completed, the URB pointed to by
> the next pointer will get auto-submitted, hopefully on a "very fast" basis?
I don't have any such plans, but I can't speak for anyone
Hi!
> > Is st7554 based chipset stMicroelectronic usb modem supported by linux
> > 2.4.0?
>
> No, it's a USB-soundchip with line interface, ie. a Winmodem in the ugliest
> sense...
It is not *ugly*. At least it is documented. The fact that it is
pretty hard to support this is not relevant.
It
On Mon, May 21, 2001 at 12:58:45PM -0700, David Brownell wrote:
> > What's the difference between queuing URBs with the USB_QUEUE_BULK flag or
> > with the next pointer?
>
> I think QUEUE_BULK is the only way to queue bulk URBs,
> and the "next" pointer is only for scheduling rings of ISO urbs.
> What's the difference between queuing URBs with the USB_QUEUE_BULK flag or
> with the next pointer?
I think QUEUE_BULK is the only way to queue bulk URBs,
and the "next" pointer is only for scheduling rings of ISO urbs.
> If I queue a bunch of URBs for a bulk endpoint, and one of them in the
No sooner than I send this do I realize that I'm confused...
What's the difference between queuing URBs with the USB_QUEUE_BULK flag or
with the next pointer?
I'm looking for differences in limitations, effects, and applications.
Matt
On Mon, May 21, 2001 at 11:14:03AM -0700, Matthew Dharm wro
If I queue a bunch of URBs for a bulk endpoint, and one of them in the
middle STALLs, what happens? Do all the queued ones stop, or are they all
attempted? What about a short packet?
That question may make more sense after this one: Can I queue URBs for
different endpoints? That is, I want to
OK, here's the "working" version, printer-0521.patch.
It makes unplugging printers mid-job behave sanely;
no oopsing or looping.
It's the same as the printer-0519 patch, updated to force
uniprocessors to schedule() after dropping the semaphore
on write-path errors, so that khubd can acquire it th
Hi,
i cant find anything wrong.
here is my actual .config (filtered the comment lines made by
menconfig):
CONFIG_X86=y
CONFIG_ISA=y
CONFIG_UID16=y
CONFIG_MODULES=y
CONFIG_KMOD=y
CONFIG_MK7=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_
Hi,
I have gone out and bought myself three Keyspan USA-28X adapters,
hoping that they would work with Linux. Unfortunately, it turns out
that what I got is one USA28X A device (and the A is important) and
two USA28X B devices. These devices have different product IDs than
the plain USA28X devi
G'day all,
A while ago, I wrote a press release on the Linux USB project, which got some
coverage. I had always planned to do it again, but I hadn't planned to wait
this long. In any case, I finally got back to it. The final draft is below.
If you have any suggestions for improvements or additiona
Dan Streetman schrieb:
> Here is a patch which makes usbdevfs use the mount options.
Thanks
Tom
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
30 matches
Mail list logo
