Sean Naughton wrote:
...
> What is the simplist way to get USB transfer going on Linux using Java. I
> have no conditions to meet other that to get some transfer going.
You could try http://jusb.sourceforge.net/
---
This sf.net email is sponsor
David Brownell wrote:
...
> Linux drivers have so far shown no need to reserve bandwidth in advance.
> They're working just fine on the "look for an interesting hotel and ask
> for a room" strategy; room shortage hasn't been a problem in practice,
> and there's only one rate after all.
The reserv
Johannes Erdfelt wrote:
..
> Anyway, to be correct, it looks like we need to ensure that we don't
> schedule too many low speed control transfers at once, perhaps by
> queuing them until previous ones finish.
As UHCI can process a queue with tds for more than a single endpoint
this looks good. It
Johannes Erdfelt wrote:
>
> On Sun, Oct 13, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> >
> > >>The HC does not control bandwidth reclamation for low speed transfers. I
> > >>am not sure what happens in case of frame overrun (device stall, or
> > >>would that not matter in case of control e
Johannes Erdfelt wrote:
>
> On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
> > On Fri, 11 Oct 2002, Johannes Erdfelt wrote:
> > >On Fri, Oct 11, 2002, Dan Streetman <[EMAIL PROTECTED]> wrote:
...
> > >> -changed lowspeed control TDs from depth to breadth.
> > >
> > >Why for? This
Pieter Nagel wrote:
>
> On Sat, 2002-10-05 at 09:26, Stephan Feder wrote:
>
> > The scanner module does blocking IO. You cannot change it to any kind of
> > nonblocking IO without breaking applications.
>
> The intent of the patch was not to do nonblocking IO. The iss
Dan Streetman wrote:
...
> diff -ur usb-2.5/drivers/usb/host/uhci-hcd.c linux/drivers/usb/host/uhci-hcd.c
> --- usb-2.5/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:52:49 2002
> +++ linux/drivers/usb/host/uhci-hcd.c Fri Oct 11 16:59:53 2002
...
> @@ -545,9 +529,16 @@
> urbp->qh->link = eurbp
f scanner.c asks 22960 (45290-22960, ie count-partial, instead of
> count-this_read), there is no problem.
>
> On Wed, 2002-10-09 at 00:53, Stephan Feder wrote:
> > I do not see how a kernel oops could be caused by the code in scanner.c.
> > Could you give a pointer to the o
Jon Wikne wrote:
>
> Stephan Feder <[EMAIL PROTECTED]> wrote:
>
> > Pieter Nagel wrote:
> > ...
> > > However, I believe for 2.5 the loop should be rewritten as retry loop,
> > > and the function should immediately return whatever it reads, lik
Pieter Nagel wrote:
...
> However, I believe for 2.5 the loop should be rewritten as retry loop,
> and the function should immediately return whatever it reads, like the
> majority of drivers do. As a side effect, the number of retries on
> TIMEOUT/NAK would change, so the TIMEOUT values for vario
Could not all these scenarios be handled the way you want them to with
explicit queues (see my last post to the list)?
Regards
Stephan
--
Matthew Dharm wrote:
>
> On Thu, Jun 06, 2002 at 02:06:30PM -0700, David Brownell wrote:
> > > I'd like to see all those URBs terminated immediately,
David Brownell wrote:
>
> In the interest of de-complicating the API and code,
> I wonder how folk would react to removing the flag
> that enables bulk queuing ... doing it as needed but
> without needing an explicit request.
...
Sounds good.
But there is more: Right now there is one queue for
Georg Acher wrote:
>
> On Fri, May 31, 2002 at 08:21:53AM -0700, David Brownell wrote:
>
> > >4. After reading the logs of the usb-uhci driver I noticed that a
> > >requested transfer block gets split in many small data packets of 64
> > >bytes, i.e the maximum packet size of a bulk transfer whi
David Brownell wrote:
>
> Interesting findings, although they're incomplete and not quite
> relevant to the thread's question ... :)
Well, in short: remove all but one UHCI driver so that the remaining
driver (and not 4 of them) can be fixed.
> > 4. After reading the logs of the usb-uhci driver
Stephan Feder wrote:
>
> Georg Acher wrote:
...
> >
> > Well, a dead HCD smells like VIA ;-) But I don't understand why a correctly
> > signalled short packet should kill the HCD later. Can I have a log of the
> > transfer?
>
> It is an ancient
Greg,
sorry for not replying earlier but I am kind of busy at the moment.
Greg KH wrote:
>
> On Tue, May 28, 2002 at 01:30:18AM +0200, Stephan Feder wrote:
> > Dear Greg,
> >
> > Greg KH wrote:
> > >
> > > Ok, now that 2.5.16 is out, we have a tota
Johannes Erdfelt wrote:
>
> On Tue, May 28, 2002, Stephan Feder <[EMAIL PROTECTED]> wrote:
> > Greg KH wrote:
> > >
> > > Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> > > controller drivers in the kernel! That's about 3
Dear Greg,
Greg KH wrote:
>
> Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI
> controller drivers in the kernel! That's about 3 too many for me :)
...
1. I tried uhci-hcd and usb-uhci-hcd with linux-2.5.18 and in both cases
I get "usb_control/bulk_msg: timeout" while readi
Hello Johannes,
it would be great if there was a flag to always keep FSBR enabled even
in cases of no traffic.
Regards
Stephan
___
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You ge
Hello Johannes,
Johannes Erdfelt wrote:
...
> When we want to deactivate FSBR on an URB's transfer, we can switch it
> from breadth first to depth first. But only do like every 5 or 10 (or
> some number) TD's to make sure it doesn't eat up all of the bandwidth.
>
> I think I'll implement that t
David Brownell wrote:
>
> > usb_submit_urb should really have well defined semantics for failures:
> >
> > 1. the completion handler is _not called_ and the result of
> > usb_submit_urb indicates _failure_ (the way uhci handles it now),
> > ...
> > 3. the completion handler is _called_ and the re
Georg Acher wrote:
>
> On Mon, Mar 18, 2002 at 12:10:31AM +0100, Stephan Feder wrote:
> > To be precise: the failures I am talking about are those that could
> > occur while talking to real devices, not errors like OOM and illegal
> > URBs (e.g. URBs wi
To be precise: the failures I am talking about are those that could
occur while talking to real devices, not errors like OOM and illegal
URBs (e.g. URBs with transfer_buffer=0 and transfer_buffer_length!=0). I
do not know in which category URBs with a bad pipe value fall.
Stephan Feder wrote
Johannes Erdfelt wrote:
>
> uhci.c would call the completion callback when the call to submit_urb
> failed. This is a rare situation.
>
> This patch only calls the completion handler if the URB successfully
> completed immediately (as in the case of talking to the virtual root
> hub).
[patch omi
24 matches
Mail list logo
