Attached is a version of David's 'ehci update: 3/3, highspeed iso rewrite'
patch that is slightly modified to apply to Andrew Morton's 2.6.0-mm
versions of the 2.6.0 kernel:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/
The original ehci-1228c.patch has a rejected hunk.
On Dec 30 2003, Alan Stern wrote:
> Don't get too excited! It may take a while to get this working. It
> doesn't seem to be an easy problem.
Ok. I thought that you had solved it already and were looking for a
minimal solution to the problem.
> Well, the problem didn't occur where I first though
Hi Duncan,
If you need to have disconnect() called in all cases, feel free
to get rid of usb_interface.driver ... it needs to go someday,
and I'd guess that's making trouble for you.
I'm happy to get rid of it... but I don't really want my usbfs fix to
change behaviour for other drivers.
When I
On Thu, 25 Dec 2003, Nathan Neulinger wrote:
> Here's a trace with sddr55. I'm not seeing the same errors as when
> debugging was not enabled, but still taking forever, and quite a few
> multi-second hangs in the diagnostics.
I see these multi-second delays in both your logs. But so far as I can
On Mon, 29 Dec 2003, Rogério Brito wrote:
> Hi, Alan.
>
> Thank you very much for your feedback. I'm now excited that maybe I will
> finally be able to use my USB drive with my computer to carry some
> documents to my workplace!
Don't get too excited! It may take a while to get this working. I
Hi Dave,
...
> > usb_set_configuration. Can you please tell me - how (and where) is
> > a driver's disconnect method called? I ask because in some situations
>
> Disconnection is only triggered through the driver model, somewhere
> in the device_del() and/or device_release_driver() paths. That'
Greg KH wrote:
On Mon, Dec 15, 2003 at 01:17:53PM -0800, David Brownell wrote:
We've had some open issues in the usb_reset_device() paths for
some time, and this starts to resolve them.
This looks nice, thanks.
So far as I can tell it's ready for merging right now (unless
Greg wants any small
On Mon, 29 Dec 2003, Greg KH wrote:
> On Sun, Dec 28, 2003 at 03:14:17PM -0500, Alan Stern wrote:
> >
> > Apparently some devices put extra garbage at the end of their
> > configuration information. For the particular device considered here,
> > there's a device descriptor followed by an illegal
This patch adds a new product ID to the list of devices using the FTDI232BM
chip. It applies cleanly against vanilla 2.6.0.
--
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"
diff -urN -X dontdiff vanilla/drivers/usb/serial/ftdi_sio.c
linux-2.6
> > Any limitation would show up at submit time. Either it will work or it
> > won't work. If it fails, it's most likely a memory allocation problem.
>
> Another way to show up at submit time would be waiting for memory
> to free up ... although UHCI does allocations at GFP_ATOMIC, so that
> part
Greg KH wrote:
Hm, this patch is linewrapped or something, and can't be applied. Can
you try to send it again so that it doesn't get mangled?
Sorry about that.
I'm sending it attached this time to avoid the mess :)
--
Paulo Marques - www.grupopie.com
"In a world without walls and fences who n
On Tue, Dec 30, 2003 at 06:55:29PM +, Paulo Marques wrote:
>
>
> --- drivers/usb/class/usblp.ori Tue Dec 30 18:52:19 2003
> +++ drivers/usb/class/usblp.c Tue Dec 30 18:53:31 2003
> @@ -603,14 +603,14 @@
> {
> DECLARE_WAITQUEUE(wait, current);
> struct usblp *usblp = file->p
I have a problem with inadequate throughput when submitting bulk urbs
with transfer buffers greater than about 128kB. ...
The system looks like this:
kernel 2.6.0 with the uhci-hcd module driving a Via controller
Try using a non-UHCI controller. UHCI needs one DMA descriptor (TD)
per packet, so yo
This patch corrects a bug produced by the weird logic in the "usblp_write"
function. The patch applies cleanly against a vanilla 2.6.0 kernel, and
already has the return codes correction proposed by me and Oliver Neukum.
This functions used the "usblp->writeurb->transfer_buffer_length" before
initi
On Tue, 30 Dec 2003, Johannes Erdfelt wrote:
> On Tue, Dec 30, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> > Axel Waggershauser wrote:
> > > I have a problem with inadequate throughput when submitting bulk urbs
> > > with transfer buffers greater than about 128kB. ...
> > >
> > > The system
On Fri, Dec 19, 2003 at 07:11:19AM -0600, Goddard James wrote:
>
> I have some code but it doesn't work. I found out on this list that
> hiddev doesn't really support some very basic things. Depending on
> what you are trying to talk to you may never get it to work.
>
> We've basicly had to dro
On Tue, Dec 30, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Axel Waggershauser wrote:
> > I have a problem with inadequate throughput when submitting bulk urbs
> > with transfer buffers greater than about 128kB. ...
> >
> > The system looks like this:
> > kernel 2.6.0 with the uhci-hcd modul
Axel Waggershauser wrote:
Hi,
I have a problem with inadequate throughput when submitting bulk urbs
with transfer buffers greater than about 128kB. ...
The system looks like this:
kernel 2.6.0 with the uhci-hcd module driving a Via controller
Try using a non-UHCI controller. UHCI needs one DMA de
> I have a problem with inadequate throughput when submitting bulk urbs
> with transfer buffers greater than about 128kB.
I thought transfer buffers were limited to 64k max...
Duncan.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Hi,
I have a problem with inadequate throughput when submitting bulk urbs
with transfer buffers greater than about 128kB. I have written a simple
usb driver to access our proprietary device. The device has a "testing"
mode, in which it dumps data to its 64 byte bulk endpoint as fast as I
can trans
On Wed, 2003-12-17 at 19:06, Alan Stern wrote:
> On Wed, 17 Dec 2003, Axel Waggershauser wrote:
>
> > Hi,
> >
> > I was about to write a usb driver (port my old one) based on the
> > usb-skeleton.c example in the 2.6.0-test11 source. I either found a bug
> > or overlooked something...
>
> What y
21 matches
Mail list logo
