Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-06 Thread David Brownell
On Wednesday 04 May 2005 12:13 pm, Christopher Li wrote: > I would like to see (or may be working on it depends how many times > I get) the zero copy for usbfs. > > It has been mention a few times about the usbfs2. What is > the plan there so far? It's still in the talk-about-it stage, no plan.

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-04 Thread Christopher Li
I would like to see (or may be working on it depends how many times I get) the zero copy for usbfs. It has been mention a few times about the usbfs2. What is the plan there so far? On Mon, May 02, 2005 at 10:23:11AM -0700, David Brownell wrote: > > I was rather shocked to notice that gadgetfs

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-02 Thread David Brownell
On Monday 02 May 2005 3:45 am, Oliver Neukum wrote: > Am Montag, 2. Mai 2005 03:38 schrieb David Brownell: > > It might well be simpler to just pin whatever (aligned) buffers > > have been passed, ensure they're properly flushed, and then just > > DMA to/from those pages without requiring special D

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-02 Thread David Brownell
On Monday 02 May 2005 1:24 am, Duncan Sands wrote: > > If it's not aligned nicely, then you could send the initial unaligned > bit in it's own urb, by copying, and the rest directly out of the > userspace buffer. Or more typically, when the file descriptor has O_DIRECT set (which tends to flag t

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-02 Thread Oliver Neukum
Am Montag, 2. Mai 2005 03:38 schrieb David Brownell: > It might well be simpler to just pin whatever (aligned) buffers > have been passed, ensure they're properly flushed, and then just > DMA to/from those pages without requiring special DMA mappings > to be set up first, and without needing specia

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-02 Thread Duncan Sands
> I've thought about that on occasion. On some processors you'd > need to flush the userspace caches first, but on typical PC-ish > stuff the main concern would be making sure that the buffers are > aligned nicely ... i.e. only start a 512 byte packet on a 512 byte > boundary, since if it crosses

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-01 Thread David Brownell
On Sunday 01 May 2005 1:37 pm, Eric Blossom wrote: > > I think the biggest benefit would be in giving us potentially lower > latency. Right now, our throughput bottleneck is in the firmware in > the FX2. We currently get 32MB/sec. We know that at least for > unidirectional apps (might not apply

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-01 Thread David Brownell
On Sunday 01 May 2005 2:04 pm, Oliver Neukum wrote: > Am Sonntag, 1. Mai 2005 21:29 schrieb Harald Welte: > > A quick browse through the EHCI specification and the ehci linux hcd > > driver This should be true of any HCD that supports DMA, FWIW. EHCI is probably most interesting because it's the

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-01 Thread Oliver Neukum
Am Sonntag, 1. Mai 2005 21:29 schrieb Harald Welte: > A quick browse through the EHCI specification and the ehci linux hcd > driver revealed that it should be technically possible to: > > 0) open an usbdevfs file like usual > 1) set up a mmap()ed buffer between kernel and userspace > 2) create one

Re: [linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-01 Thread Eric Blossom
On Sun, May 01, 2005 at 09:29:41PM +0200, Harald Welte wrote: > Hi! > > I've been playing quite a bit with the gnuradio[1] project's USRP[2] > recently. One of the key issues with the USRP is to get the highes > possible USB2.0 throughput (since the ADC and DAC's actually outperform > the slow US

[linux-usb-devel] mmap() for usbdevfs, zerocopy EHCI ?

2005-05-01 Thread Harald Welte
Hi! I've been playing quite a bit with the gnuradio[1] project's USRP[2] recently. One of the key issues with the USRP is to get the highes possible USB2.0 throughput (since the ADC and DAC's actually outperform the slow USB2.0 bus). Another key issue is that for digital signal processing you ne