Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
The main issue is that DMA'able memory is allocated per USB host controller on
Linux and not per USB host controller and pipe
Hi,
Interesting reading.
On Wednesday 16 May 2007 16:08, Pete Zaitcev wrote:
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non
On Wednesday 16 May 2007 16:41, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design
On Wednesday 16 May 2007 18:00, David Brownell wrote:
On Wednesday 16 May 2007, Alan Stern wrote:
On Wed, 16 May 2007, David Brownell wrote:
I have never, ever, seen USB stack deplete the atomic pool completely
either, if this is what you are talking about. So, you're quite right
On Wednesday 16 May 2007 18:21, Alan Stern wrote:
On Wed, 16 May 2007, Pete Zaitcev wrote:
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern
[EMAIL PROTECTED] wrote:
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the point
of starting an USB transfer will require extra error handling in the USB
device driver code!
It's not so clear to me
Hi,
On Wednesday 16 May 2007 19:38, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the
point of starting
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
URB submission has other failure possibilities than lack of memory.
Those other things have to be checked for regardless.
Yes, but that is because you allow too many parameters in the URB to
be changed between USB
On Wednesday 16 May 2007 20:20, Pete Zaitcev wrote:
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
My usbd_transfer_start() returns void. Your usb_submit_urb()
returns int.
We (ok, I) don't like this scheme. In Linux only SCSI uses it,
primarily because
Hi,
On Thursday 17 May 2007 06:38, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
URB submission has other failure possibilities than lack of
memory. Those other things have to be checked
On Thursday 17 May 2007 16:35, Alan Stern wrote:
On Thu, 17 May 2007, Hans Petter Selasky wrote:
If you need to do Async stuff, then you have to do it in a separate
thread or in a so-called task-queue. Else you are in for great trouble!
That was the big sin in the old USB stack on FreeBSD
On Thursday 17 May 2007 16:20, David Brownell wrote:
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the device has detached! It must
be something terribly wrong in the Linux USB stack if the
callbacks are alive after that you
Hi,
On Thursday 17 May 2007 19:03, Alan Stern wrote:
On Thu, 17 May 2007, Hans Petter Selasky wrote:
In Linux, the USB callbacks are generally atomic. Does that answer
your question?
Yes. So you protect the callback with a lock to make it atomic?
No, you don't understand
On Thursday 17 May 2007 19:44, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate model
will work better with your USB API. For example I want something like
this:
void
usb_setup_endpoint(struct
On Thursday 17 May 2007 20:19, Pete Zaitcev wrote:
On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED]
wrote:
So what's the model ... GPL'd Linux drivers will be modified to
incorporate that call, so they'd work better on FreeBSD?
I thought that we ignored this on purpose
Hi,
On Thursday 17 May 2007 21:26, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
On Thursday 17 May 2007 19:44, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate
On Thursday 17 May 2007 23:04, Alan Stern wrote:
On Thu, 17 May 2007, Laurent Pinchart wrote:
A user of the Linux UVC driver unfortunately reported such a failure. The
driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer.
The system had been used for quite some time, and
Hi,
If you are interested, the files are:
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h
It is almost finished now.
And it is not very much code.
--HPS
On Friday 18 May 2007 16:26, Alan Stern wrote:
On Fri, 18 May 2007, Hans Petter Selasky wrote:
Hi,
If you are interested, the files are:
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_co
mpat_linux.c
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys
On Monday 21 May 2007 13:37, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky:
The lock that you are holding during submission is the same lock that is
protecting the callback. Actually you can end up calling the
__usbd_callback() prematurely in my new USB
Hi Oliver!
What you're trying to do is what the HPS USB stack for FreeBSD has been doing
for a while. See for example:
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ohci.c
Look at the function:
static usbd_status
ohci_xfer_setup(struct usbd_device *udev,
21 matches
Mail list logo
