Am Dienstag, 22. Mai 2007 17:23 schrieb Alan Stern:
On Tue, 22 May 2007, Laurent Pinchart wrote:
The usb_buffer_alloc name is misleading. Many USB driver developers believe
it
is a generic purpose buffer allocator.
I'd like to change usb_buffer_alloc to make it a general purpose
On Wednesday 23 May 2007, Oliver Neukum wrote:
I thought a bit about this. Maybe there _is_ room for an allocator that
will provide memory the HCD can get at, but without the full overhead
of allocating a coherent buffer.
kmalloc() does exactly that...
Am Mittwoch, 23. Mai 2007 10:48 schrieb David Brownell:
On Wednesday 23 May 2007, Oliver Neukum wrote:
I thought a bit about this. Maybe there _is_ room for an allocator that
will provide memory the HCD can get at, but without the full overhead
of allocating a coherent buffer.
Am Montag, 21. Mai 2007 23:36 schrieb David Brownell:
On Monday 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will
never get in the
Am Dienstag, 22. Mai 2007 15:28 schrieb Laurent Pinchart:
I'd like to change usb_buffer_alloc to make it a general purpose allocator. A
parameter would tell the function to just allocate memory (default behaviour)
Nope. What for? We avoid such flags if we can. If you need two version,
create
On Friday 18 May 2007, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks
of PAGE_SIZE bytes?
Not at all. The size parameter is in bytes, and the utility
code it calls goes to some lengths to
On Tue, 22 May 2007, Laurent Pinchart wrote:
The usb_buffer_alloc name is misleading. Many USB driver developers believe
it
is a generic purpose buffer allocator.
I'd like to change usb_buffer_alloc to make it a general purpose allocator. A
parameter would tell the function to just
On Tuesday 22 May 2007, Oliver Neukum wrote:
Am Dienstag, 22. Mai 2007 15:28 schrieb Laurent Pinchart:
I'd like to change usb_buffer_alloc to make it a general purpose
allocator. A parameter would tell the function to just allocate memory
(default behaviour)
Nope. What for? We avoid such
Am Dienstag, 22. Mai 2007 18:10 schrieb Laurent Pinchart:
My idea was to have a general purpose URB buffer allocation function that all
(most?) drivers could use, with flags (or another function) for specific
cases. usb_buffer_alloc is currently used by some drivers when they should
use
Am Donnerstag, 17. Mai 2007 20:39 schrieb Pete Zaitcev:
I think we should remove those local_irq_save's, and leave just the
guarantee that it won't be re-entered (currently such a guarantee
is inherited from the Linux's interrupt handling, and we'll only
need to make it explicit if any HCDs
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 stack, but that is handled just
fine, through some
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
Am Mittwoch, 16. Mai 2007 19:38 schrieb Alan Stern:
It doesn't save code. You need to check for the memory when you
allocate it, no matter when that is done.
Yes, but it is a difference doing it once at attach or doing it every time
you
start a transfer.
Above you said it
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on Linux.
That's not a
Am Mittwoch, 16. Mai 2007 19:33 schrieb Alan Stern:
All devices need to allocate some memory, even if they are not used. That
is
just the way it is. If you want to save memory, then USB has the advantage
that you can unplug the device and save resources.
Of course all devices need
On Monday 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will
never get in the situation of not being able to allocate transfer
descriptors
On Thu, 17 May 2007 17:37:22 -0700, David Brownell [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a
somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you remember why we're doing
On Saturday 19 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 17:37:22 -0700, David Brownell [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a
somewhat
artificial restriction; in theory there's no reason we couldn't
allow
On Sat, 19 May 2007, David Brownell wrote:
Absolutely right, I'm being an idiot here. I think I looked at root
hub code in the rush to the FreedomHEC preparations. We do not have
local_irq_save in the giveback routine. So, when Alan wrote USB
callbacks cannot be interrupted, he meant
On Saturday 19 May 2007, Alan Stern wrote:
On Sat, 19 May 2007, David Brownell wrote:
Absolutely right, I'm being an idiot here. I think I looked at root
hub code in the rush to the FreedomHEC preparations. We do not have
local_irq_save in the giveback routine. So, when Alan wrote USB
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 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_compat_linux.c
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h
It is almost finished
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
On Fri, 18 May 2007, Hans Petter Selasky wrote:
It occurred to me last night that you could accomplish what you want
without any change to the Linux drivers at all. Just change the
FreeBSD stack so that it preallocates one or two transfers for every
endpoint at the time the endpoint is
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 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 have detached a USB device.
How does that work then
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: Calling synchronous USB callbacks
from
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
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. The callback is atomic because it is not
allowed to sleep. That's
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 usb_device *usb, struct usb_interface *ui, struct
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. The
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 and talking about the
licensing so deeply in the thread
On Thu, 17 May 2007, Hans Petter Selasky wrote:
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
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 Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you remember why we're doing this? I did not touch that
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
On Thu, 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you
On Thursday 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED]
wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you
On Thursday 17 May 2007, 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 and
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 model
will work better with your USB API. ...
int
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 Wednesday 16 May 2007, 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.
...
in that
On Thursday 17 May 2007, Laurent Pinchart wrote:
On Wednesday 16 May 2007, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will never get in the situation of not
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 the user reported that
allocating such an amount
On Thursday 17 May 2007, David Brownell wrote:
On Thursday 17 May 2007, Laurent Pinchart wrote:
On Wednesday 16 May 2007, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
in that when you have
pre-allocated all buffers and all USB host controller
The call will setup one or two pre-allocated USB transfers for the
emulation layer between the Linux USB stack and the FreeBSD USB stack.
So what's a transfer ... just a bunch of TDs? And what would be
the advantage to a Linux driver, since the TDs are allocated on
demand in any
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
On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
Do you remember why we're doing this? I did not
On Thursday 17 May 2007, Pete Zaitcev wrote:
On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote:
As it happens, USB callbacks cannot be interrupted. That's a somewhat
artificial restriction; in theory there's no reason we couldn't allow
interrupts.
On Thursday 17 May 2007, Hans Petter Selasky wrote:
Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks of
PAGE_SIZE bytes?
Not at all. The size parameter is in bytes, and the utility
code it calls goes to some lengths to *avoid* that kind of wastage.
As they say: UTSL!
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-optimal due to its
API design.
I think that what you described is largely
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
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.
...
What I would suggest is that when you allocate an URB and
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 Wed, 16 May 2007, Pete Zaitcev wrote:
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
On the BSD platform there is something called BUS-DMA. Memory is allocated
according to PCI device capabilities. This is because sometimes the PCI
device is not capable of addressing the complete memory. Also you need to
sync memory,
On Wednesday 16 May 2007, Pete Zaitcev wrote:
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will
never get in the situation of not being able to allocate
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
about that.
I was referring to the dma_pool allocations ... those don't need
to be atomic. OHCI or EHCI
On Wed, 16 May 2007 16:52:53 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
[...] Then you need to send specific
commands to the PCI-bridge, for example pshyco. From what I see
your model will not work in all cases.
USB through Psycho/Schizo is fully supported on Linux. Heck it works
On Wed, 16 May 2007 11:38:47 -0400 (EDT), Alan Stern [EMAIL PROTECTED] 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
about that.
I was referring to the dma_pool allocations ... those
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 among multiple
endpoints. One example is usb-storage.
This is for CBI transport, right? Honestly,
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
about that.
I was referring to the dma_pool
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 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 among multiple
endpoints. One example is
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.
My usbd_transfer_start() returns void. Your
On Wednesday 16 May 2007, Alan Stern wrote:
On Wed, 16 May 2007, Pete Zaitcev wrote:
Right. Per-endpoint with a size limits also allows TDs to be
preallocated.
With a large potential waste of memory!
Which is the general down-side of preallocation...
UHCI is so inefficient that
the
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.
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It's also true for bulk-only; the same URB and buffer get used for the
IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if
necessary.
I would says it is a specification design fault that read and write endpoints
are not
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 an USB transfer will require extra error handling in the
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
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 that's how Eric Youngdale defined it in 1992.
See, there
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 transfers.
No; it's because unforeseen events can occur. For
On Wed, 16 May 2007 19:49:57 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
No; it's because unforeseen events can occur. For example, the device
may have been unplugged or suspended.
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the
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
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 for regardless.
Yes, but that is because you allow too
79 matches
Mail list logo
