Re: [linux-usb-devel] Question about EHCI PCI/platform drivers
David Brownell wrote: On Tuesday 15 May 2007, Tzachi Perelstein wrote: David Brownell wrote: On Sunday 13 May 2007, Tzachi Perelstein wrote: Hello, I'm working on EHCI HC glue port for Marvell Orion SoC. The Orion has a PCI/PCIE interfaces as well as an integrated USB controller. While looking at ehci-hcd.c it looks like there's some kind of dependency between PCI_DRIVER and PLATFORM_DRIVER. I saw some previous threads about the ehci-fsl.c regarding this issue, but I'm not sure I understand, for example, why in module_init if pci_register_driver fails the platform driver is unregistered? Shouldn't these two types of drivers be independent? If the platform has PCI but you can't register a PCI driver, it's quite broken. How broken must a platform be before you fix those bugs, rather than expect drivers to work around them? I have no problem with my PCI, it works just fine! Who said anything about bugs workaround??? You -- by asking why a bug (pci_register_driver fails) should be handled differently (working around the failure). Asking about some existing implementation does not necessarily mean one need a workaround. I just wanted to better understand this dependency and perhaps improving it. That's all. I was just wondering if there is a _real_ reason why *if* pci_register_driver fails then the platform driver will be unregistered. Theoretically it could be that PCI will fail but platform driver will work ok, so why unregistering it?? Why not just dumping an error message and continuing?? No; theoretically pci_register_driver() has no reason to fail on a correctly working system. I agree with that. However, the existing implementation _does_ handle this theoretical pci_register_driver failure by unregistering the *platform* driver (?). Besides arguing with me if I have a buggy PCI or not, you couldn't explain _why_ this is the appropriate handling. It's not that important, so you can just forget it. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 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 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 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 ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. 1) usbd_transfer_start() is always called like this: usbd_transfer_start(sc-sc_xfer[x]); 2) sc-sc_xfer[x] is set to zero at detach holding the private lock of the USB device driver. All subsequent calls to usbd_transfer_start(), if any, will fail. So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. It is an assert statement. The priv_mtx lock must be locked before you call usbd_transfer_start(). There is no race on SMP. 3) usbd_transfer_start() is always non-blocking. In other words a single lock is held across the call. Like usb_submit_urb() then, except that the disconnect race is handled by being buggy rather than by reporting a fault at submit time... Ok. ... Because if there's no lock against async disconnect events, then it's trivial to have the disconnect logic underway on one CPU while another CPU does real work, submitting an I/O request. We solve this in one of two ways: 1) Using a mutex. At detach we lock the mutex stopping all transfers. 2) Using a thread. At detach we teardown and wait for the thread to exit. But there's that race above, so it's not solved. 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 everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. The problem clearly appears on Linux SMP because: a) No locks are in the USB drivers (then they must be all so-called Giant locked) b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] usb_control_msg() returns timeout !!
Hello Group, I have two devices connected to a host. I periodically read bulk data from first device and pass it on to the second device via EP-2. Apart from this periodic data, the host sends some vendor commands through EP-0 of first device. Though these vendor commands are received successfully by the device, usb_control_msg() returns -ETIMEDOUT error sometimes. If I stop sending the periodic bulk data, no -ETIMEDOUT is seen for the usb_control_msg(). I traced out the message.c file and it looks like the URB times out to call the timeout_kill() function. I even tried with a higher timeout, but no improvement is seen. Any pointers on what could have gone wrong ? I observed the same with both EHCI and OHCI drivers. The device is Cypress based, capable of USB2.0. The host runs 2.6.11 on MPC8270 with PCI-USB ISP1561. Regards, Jayaprakash. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Remove duplicate ID in ipaq driver
On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified device */
-{ USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
if (vendor) {
ipaq_id_table[0].idVendor = vendor;
ipaq_id_table[0].idProduct = product;
}
in ipaq_init()?
My mistake, quick on the patching going through this dupe list.
Might I add that this is terrible use of the device table, though.
Clutters userspace, and adds processing to module-init-tools programs.
It's a hold-over from the times when we didn't have the sysfs add a new
id interface for usb-serial drivers, which only recently was created.
So we just have to live with it, and the infinitesimal speed hit it
creates :)
thanks,
greg k-h
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ark3116: receive returns negative
On Wed, May 16, 2007 at 06:04:45PM +0200, Jan Engelhardt wrote: Hello, I seem to have problems with the ark3116 driver from 2.6.18.8. This is a USB-RS232 cable. Just opening the /dev/ttyUSB0 device gives (this is the debug output enabled by `modprobe ark3116 debug=1`). The lines that look suspicious are /serial/ark3116.c: 124 1 bytes [0xFFB0] and /serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported Why is this suspicious? We don't support all ioctls for all usb-serial drivers, perhaps this one is just not really needed? I have also seen things like id here -62 [0x10], which would indicate that usb_control_msg() returned something very negative (-ETIME!?). But does the driver seem to work properly? Issuing a write() on an open fd to ttyUSB does not generate any further debug output. Is the driver even complete/functional? Do you get data through the device properly? thanks, greg k-h - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] FW: Pl2303 on 2.4.x
On Tue, May 15, 2007 at 03:32:35PM -0400, Matthew Hickey wrote: Good afternoon all, i have a 2.4.26 kernel with the newer patch for the pl2303 driver (10.1) only the problem is that it only allows for a maxpacketsize of 64 bytes, if i look at the driver for 2.6.x i see that there is a constant in there that allows for a higher buffer and i am able to transfer in greater quantities, is it possible that there is a patch for the pl2303 to increase the packetsize or buffersize or is there an adapter that utilizes a different driver to accomodate this. As I responded to a private inquiry to this, the packet size of the internal driver buffer should not matter at all to the userspace program you are using. If it does, there is a bug in your code :) thanks, greg k-h - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Remove duplicate ID in ipaq driver
On Thu, 2007-05-17 at 05:43 -0700, Greg KH wrote:
On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified
device */
- { USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
if (vendor) {
ipaq_id_table[0].idVendor = vendor;
ipaq_id_table[0].idProduct = product;
}
in ipaq_init()?
My mistake, quick on the patching going through this dupe list.
Might I add that this is terrible use of the device table, though.
Clutters userspace, and adds processing to module-init-tools programs.
It's a hold-over from the times when we didn't have the sysfs add a new
id interface for usb-serial drivers, which only recently was created.
So we just have to live with it, and the infinitesimal speed hit it
creates :)
Any objection to adding it to planned-for-removal and spitting out a
printk when someone uses the feature?
--
Ubuntu : http://www.ubuntu.com/
Linux1394: http://wiki.linux1394.org/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Remove duplicate ID in ipaq driver
On Thu, 17 May 2007 09:02:20 EDT, Ben Collins said: So we just have to live with it, and the infinitesimal speed hit it creates :) Any objection to adding it to planned-for-removal and spitting out a printk when someone uses the feature? Do we have any good reason to believe that this will eventually lead to a clean-up? ISTR that we did a similar printk for sysctl (or as Dr. Phil likes to say, How's that working for you?) pgpoB1afb59iv.pgp Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] Remove duplicate ID in ipaq driver
On Thu, May 17, 2007 at 09:02:20AM -0400, Ben Collins wrote:
On Thu, 2007-05-17 at 05:43 -0700, Greg KH wrote:
On Wed, May 16, 2007 at 05:36:48PM -0400, Ben Collins wrote:
On Wed, 2007-05-16 at 13:59 -0700, Roland Dreier wrote:
/* The first entry is a placeholder for the insmod-specified
device */
-{ USB_DEVICE(0x049F, 0x0003) },
Is it obvious why this patch is correct? Especially given the
comment just before the line you delete, and the code
if (vendor) {
ipaq_id_table[0].idVendor = vendor;
ipaq_id_table[0].idProduct = product;
}
in ipaq_init()?
My mistake, quick on the patching going through this dupe list.
Might I add that this is terrible use of the device table, though.
Clutters userspace, and adds processing to module-init-tools programs.
It's a hold-over from the times when we didn't have the sysfs add a new
id interface for usb-serial drivers, which only recently was created.
So we just have to live with it, and the infinitesimal speed hit it
creates :)
Any objection to adding it to planned-for-removal and spitting out a
printk when someone uses the feature?
No, it's a module parameter and it's much easier to use for some systems
than the sysfs file way. It's just not worth breaking userspace APIs
for no good reason.
thanks,
greg k-h
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Question about EHCI PCI/platform drivers
On Thursday 17 May 2007, Tzachi Perelstein wrote: Besides arguing with me if I have a buggy PCI or not, you couldn't explain _why_ this is the appropriate handling. I was pointing out to you that there's nothing particularly wrong about it. And it has the virtues of being straightforward ... no hard-to-debug half registered state to clean up from later, no consequentially surprising runtime behaviors. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ark3116: receive returns negative
Hi Greg,
On May 17 2007 05:45, Greg KH wrote:
I seem to have problems with the ark3116 driver from 2.6.18.8. This
is a USB-RS232 cable. Just opening the /dev/ttyUSB0 device gives
(this is the debug output enabled by `modprobe ark3116 debug=1`).
The lines that look suspicious are
/serial/ark3116.c: 124 1 bytes [0xFFB0]
and
/serial/ark3116.c: ark3116_ioctl cmd 0x5401 not supported
Why is this suspicious? We don't support all ioctls for all usb-serial
drivers, perhaps this one is just not really needed?
ark3116 supports set_termios (0x5402), but does not get_termios
(0x5401). Not sure how that affects userspace, though.
The 0xFFB0 looks like a simple formatting error (ark3116.c line 66)
an explicit cast to (unsigned char)buf[0] or (unsigned int) seems
required.
I have also seen things like id here -62 [0x10], which would
indicate that usb_control_msg() returned something very negative
(-ETIME!?).
The -62 only shows up when the cable is already connected when I
modprobe ark3116. Reinserting it - and no -62 shows up.
Maybe this is something normal with USB?
But does the driver seem to work properly?
Issuing a write() on an open fd to ttyUSB does not generate any further
debug output. Is the driver even complete/functional?
(I found that I already need to modprobe usbserial with debug=1,
since ark3116 uses usb_serial_generic_write)
Do you get data through the device properly?
I would have to test with a real serial port. (I do not
have any real port right now, just two cables + adapters.)
What certainly does not work: Connecting two cables to each other, that is,
USB-RS232-GenderChanger-RS232-USB. (1) USB ends connected to the same machine
(2) USB ends connected to different machines. Both (1) and (2) do not work.
The write() seems to succeed, but read() blocks:
# klogconsole -l8 -r0
# ./sertest
[...]
Writing...
drivers/usb/serial/usb-serial.c: serial_write_room - port 0
drivers/usb/serial/generic.c: usb_serial_generic_write_room - port 0
drivers/usb/serial/generic.c: usb_serial_generic_write_room - returns 64
drivers/usb/serial/usb-serial.c: serial_write - port 0, 3 byte(s)
drivers/usb/serial/generic.c: usb_serial_generic_write - port 0
ark3116 ttyUSB0: usb_serial_generic_write - length = 3, data = 66 6f 6f
drivers/usb/serial/generic.c: usb_serial_generic_write_bulk_callback -
port 0
drivers/usb/serial/usb-serial.c: usb_serial_port_work - port 0
Reading...
(stops)
Source:
#include sys/stat.h
#include sys/types.h
#include fcntl.h
#include stdio.h
#include stdlib.h
#include unistd.h
int main(void)
{
char bar[4] = {};
int s0 = open(/dev/ttyUSB0, O_RDWR);
int s1 = open(/dev/ttyUSB1, O_RDWR);
if (s0 0 || s1 0)
abort();
printf(Writing...\n);
write(s0, foo, 3);
printf(Reading...\n);
read(s1, bar, 3);
printf(Read: %s\n, bar);
return 0;
}
Jan
--
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb_control_msg() returns timeout !!
On Thu, 17 May 2007, Jayaprakash Shanmugam wrote: Hello Group, I have two devices connected to a host. I periodically read bulk data from first device and pass it on to the second device via EP-2. Apart from this periodic data, the host sends some vendor commands through EP-0 of first device. Though these vendor commands are received successfully by the device, usb_control_msg() returns -ETIMEDOUT error sometimes. If I stop sending the periodic bulk data, no -ETIMEDOUT is seen for the usb_control_msg(). Are you sure about that? If you stop sending the bulk data to the second device, then the control messages to the first device start working? Even though you continue to read the bulk data periodically from the first device? I traced out the message.c file and it looks like the URB times out to call the timeout_kill() function. I even tried with a higher timeout, but no improvement is seen. Any pointers on what could have gone wrong ? I observed the same with both EHCI and OHCI drivers. The device is Cypress based, capable of USB2.0. The host runs 2.6.11 on MPC8270 with PCI-USB ISP1561. What happens with a different host? What happens with a later version of the kernel on the host? 2.6.11 is quite old... Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. ... So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. It is an assert statement. The priv_mtx lock must be locked before you call usbd_transfer_start(). There is no race on SMP. I see; I was expecting a response like yes, driver must grab lock and that step was omitted from your response. 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 everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? All callbacks are async. At one point there were some bugs associated with callers that accidentally placed racey restrictions on when the callbacks could occur -- i.e. expected them at some point after a call returned, rather than any point after the call was issued -- but such bugs seem to be largely fixed now. (Hard to be sure though.) On Linux I see no locks used in the USB drivers, Look again, then! Driver-private locks are all over the place. so they are solely protected by interrupt-level mechanisms. Maybe you mean caller-transparent mechanisms? Synchronous calls use mutexes (or for old code, semaphores) internally. Async ones use spinlocks. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. Well *obviously* blocking calls require a schedulable context, and others don't. We don't restrict things to config threads. The problem clearly appears on Linux SMP because: a) No locks are in the USB drivers (then they must be all so-called Giant locked) Nope; I don't have an idea why you overlook all the mutex and spinlock calls in the drivers. There's the legacy big kernel lock but not much uses that any more. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) You should learn more about the stack before making such sweeping (and wrong) statements. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? It's hard to answer; your use of terminology is peculiar. The word synchronous does not mean capable of blocking; it means that the routine waits until a result is received. It is not directly related to whether the routine runs in a process context (which can sleep) vs. an atomic context (one which isn't allowed to sleep). Referring to a callback as synchronous doesn't make sense. A callback doesn't send a message -- it _receives_ a message -- and hence it doesn't need to wait for any result. In Linux, the USB callbacks are generally atomic. Does that answer your question? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. That's an awfully strange thing to say. No locks used in the USB drivers? Good lord, they are full of locks! Semaphores, mutexes, spinlocks -- you name it, it's in there. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. What distinguishes a config thread from any other kind of thread? What distingishes threads you can wait for from threads you can't wait for? What's wrong with a config thread that you can't wait for making a blocking call? Who cares if you can't wait for it? -- the thread will still carry out the call okay. The problem clearly appears on Linux SMP because: What problem? Or should I say, Which problem? a) No locks are in the USB drivers (then they must be all so-called Giant locked) You must be living in some sort of fantasy land if you really believe this. Or else you're looking at a version of Linux from 8 years ago. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? In code paths which can't block, we do non-blocking late allocation. And we do think about what can happen. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ark3116: receive returns negative
On May 17 2007 16:10, Jan Engelhardt wrote: Hi Greg, But does the driver seem to work properly? Do you get data through the device properly? I have taken a voltmeter and an appropriate testcase program - and yes, at least transmit works. USB-RS232-GenderChanger-RS232-USB. A faulty setup that is. My bad. Jan -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] ark3116: receive returns negative
On Thu, May 17, 2007 at 04:51:09PM +0200, Jan Engelhardt wrote: On May 17 2007 16:10, Jan Engelhardt wrote: Hi Greg, But does the driver seem to work properly? Do you get data through the device properly? I have taken a voltmeter and an appropriate testcase program - and yes, at least transmit works. USB-RS232-GenderChanger-RS232-USB. A faulty setup that is. My bad. You forgot the NULL modem inverter :) thanks, greg k-h - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] Re: ark3116: receive returns negative
On May 17 2007 07:58, Greg KH wrote: On Thu, May 17, 2007 at 04:51:09PM +0200, Jan Engelhardt wrote: On May 17 2007 16:10, Jan Engelhardt wrote: Hi Greg, But does the driver seem to work properly? Do you get data through the device properly? I have taken a voltmeter and an appropriate testcase program - and yes, at least transmit works. USB-RS232-GenderChanger-RS232-USB. A faulty setup that is. My bad. You forgot the NULL modem inverter :) Yeah I figured. Screw this legacy tech... Anyway here is the patch for that printk: --- Subject: Fix debug output of ark3116 Fix debug output. Previously, it would output 0xFFB0 on 32-bit archs (and probably 0xFFB0 on 64-bits), because buf is taken as signed char, which is promoted to signed int, while %x always expects an unsigned int. Signed-off-by: Jan Engelhardt [EMAIL PROTECTED] --- drivers/usb/serial/ark3116.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: linux-2.6/drivers/usb/serial/ark3116.c === --- linux-2.6.orig/drivers/usb/serial/ark3116.c +++ linux-2.6/drivers/usb/serial/ark3116.c @@ -63,7 +63,8 @@ static inline void ARK3116_RCV(struct us request, requesttype, value, index, buf, 0x001, 1000); if (result) - dbg(%03d %d bytes [0x%02X], seq, result, buf[0]); + dbg(%03d %d bytes [0x%02X], seq, result, + ((unsigned char *)buf)[0]); else dbg(%03d 0 bytes, seq); } - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] anybody have a working driver for ELO 1529L with Mag-Tek USB Swipe Reader?
Thanks, JB - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? It's hard to answer; your use of terminology is peculiar. The word synchronous does not mean capable of blocking; it means that the routine waits until a result is received. It is not directly related to whether the routine runs in a process context (which can sleep) vs. an atomic context (one which isn't allowed to sleep). I meant blocking USB transfers, there. For example when you want to do a control transfer and wait for it to finish. Referring to a callback as synchronous doesn't make sense. A callback doesn't send a message -- it _receives_ a message -- and hence it doesn't need to wait for any result. Right. 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? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. That's an awfully strange thing to say. No locks used in the USB drivers? Good lord, they are full of locks! Semaphores, mutexes, spinlocks -- you name it, it's in there. Ok, Ok. I'm not the Linux expert. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. What distinguishes a config thread from any other kind of thread? What distingishes threads you can wait for from threads you can't wait for? What's wrong with a config thread that you can't wait for making a blocking call? Who cares if you can't wait for it? -- the thread will still carry out the call okay. You can use any thread you like, as long as you make sure it is gone before the detach routine of the USB device in question returns. The problem clearly appears on Linux SMP because: What problem? Or should I say, Which problem? a) No locks are in the USB drivers (then they must be all so-called Giant locked) You must be living in some sort of fantasy land if you really believe this. Or else you're looking at a version of Linux from 8 years ago. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. In code paths which can't block, we do non-blocking late allocation. And we do think about what can happen. Good. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [3/3] 2.6.22-rc1: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.22-rc1. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Timers/NOHZ Subject: 2.6.21-git4 BUG: soft lockup detected on CPU#1! References : http://lkml.org/lkml/2007/5/2/511 Submitter : Michal Piotrowski [EMAIL PROTECTED] Handled-By : Thomas Gleixner [EMAIL PROTECTED] Status : problem is being debugged USB Subject: usb hotplug/udev cannot correctly register usb/scanners References : http://lkml.org/lkml/2007/5/15/205 Submitter : [EMAIL PROTECTED] [EMAIL PROTECTED] Status : Unknown V4L Subject: V4L ABI breakage References : http://lkml.org/lkml/2007/5/14/42 Submitter : Robert Fitzsimons [EMAIL PROTECTED] Caused-By : Hans Verkuil [EMAIL PROTECTED] Mauro Carvalho Chehab [EMAIL PROTECTED] commit 206ebaf32795cf1582b1e2ff2ec6a560c9e986b8 Status : Unknown Networking Subject: panic with e1000 driver on HP Integrity servers References : http://bugzilla.kernel.org/show_bug.cgi?id=8455 Submitter : Doug Chapman [EMAIL PROTECTED] Caused-By : Auke Kok [EMAIL PROTECTED] commit e0aac5a289b1dacbc94bd9ae8c449bcdf9ab508c Status : problem is being debugged Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [3/3] 2.6.22-rc1: known regressions v2
Hi Michal, V4L Subject: V4L ABI breakage References : http://lkml.org/lkml/2007/5/14/42 Submitter : Robert Fitzsimons [EMAIL PROTECTED] Caused-By : Hans Verkuil [EMAIL PROTECTED] Mauro Carvalho Chehab [EMAIL PROTECTED] commit 206ebaf32795cf1582b1e2ff2ec6a560c9e986b8 Status : Unknown We are currently working on it. I expect to have a patch fixing the issue until next week. Cheers, Mauro. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. ... So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. It is an assert statement. The priv_mtx lock must be locked before you call usbd_transfer_start(). There is no race on SMP. I see; I was expecting a response like yes, driver must grab lock and that step was omitted from your response. 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 everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? All callbacks are async. At one point there were some bugs associated with callers that accidentally placed racey restrictions on when the callbacks could occur -- i.e. expected them at some point after a call returned, rather than any point after the call was issued -- but such bugs seem to be largely fixed now. (Hard to be sure though.) On Linux I see no locks used in the USB drivers, Look again, then! Driver-private locks are all over the place. so they are solely protected by interrupt-level mechanisms. Maybe you mean caller-transparent mechanisms? Synchronous calls use mutexes (or for old code, semaphores) internally. Async ones use spinlocks. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. Well *obviously* blocking calls require a schedulable context, and others don't. We don't restrict things to config threads. The problem clearly appears on Linux SMP because: a) No locks are in the USB drivers (then they must be all so-called Giant locked) Nope; I don't have an idea why you overlook all the mutex and spinlock calls in the drivers. There's the legacy big kernel lock but not much uses that any more. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) You should learn more about the stack before making such sweeping (and wrong) statements. Ok, thanks for clearing it up. You obviously know more about the Linux USB stack than I do. In between: 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 usb_host_endpoint *uhe, uint32_t bufsize, uint32_t unused0, uint32_t unused1, uint32_t unused2); On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. On linux you will probably use uint32_t uhe, hence I will do it like this: struct usb_host_endpoint * usb_find_host_endpoint(struct usb_device *dev, uint8_t type, uint8_t dir); #define usb_sndctrlpipe(dev,endpoint) \ usb_find_host_endpoint(dev, PIPE_CONTROL, (endpoint) | USB_DIR_OUT) Whether usb_sndctrlpipe() returns a pointer or uint32_t, will be hidden to the USB device drivers. What do you think? --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Cannot stall an endpoint 0 control transfer from a data stage callback function
For some reason, this didn't appear in the mailing list archive, so I'm sending again. -Original Message- From: Geoffrey Tam Sent: Wednesday, May 09, 2007 11:14 AM To: 'linux-usb-devel@lists.sourceforge.net' Cc: '[EMAIL PROTECTED]' Subject: RE: [linux-usb-devel] Cannot stall an endpoint 0 control transfer from a data stage callback function Here is the patch created as per instructions in Documentation/SubmittingPatches. Does anyone know if there is a MontaVista USB developer mailing list? Hi, On Wed, May 09, 2007 at 12:52:46AM -0700, ext Greg KH wrote: On Thu, May 03, 2007 at 04:02:59PM -0400, Geoffrey Tam wrote: I am new to the Linux open source community. I am not sure if I am posting this to the correct mailing list. Please tell me where this should be posted if it is in the wrong spot. I have subscribed to this mailing list. I am using Linux 2.6.20. It was retrieved from the MontaVista git tree (source.mvista.com/git/linux-davinci-2.6.gitCVS:) in February 2007. I am using the TI Davinci processor. My USB gadget supports 2 endpoint 0 control transfers: get variable and set variable. The get function must stall endpoint 0 if the variable id retrieved from the endpoint 0 setup stage packet is invalid. The current implementation of the USB gadget supports this. The set function receives the variable id in the endpoint 0 setup stage packet. The value to set the variable to is received in the data stage packet. If this value is outside of the variable's valid range, it must stall endpoint 0. The current implementation of the USB gadget does not support this. This is a legacy protocol, so it cannot be changed as this would break other applications that already use it. Through my debugging, I believe that the souce of my problems are: - The state machine is going to the setup stage (MGC_END0_STAGE_SETUP) too early. - The USB peripheral hardware is being notified with end of data stage too early (MGC_M_CSR0_P_DATAEND bit in MGC_O_HDRC_CSR0 being written too early). I noticed that on 22 Mar 2007, an update to the git tree was made to correct problems on endpoint 0 (source.mvista.com/git/gitweb.cgi?p=linux-davinci-2.6.git;a=lo g). I scanned the changes that were made, and do not believe that my changes are included. I made changes to the code, and this has fixed the problem for me. I would appreciate if someone could review them for correctness, and if possible, add them to the git tree. Only 1 file had to be modified: drivers/usb/musb/g_ep0.c There are 4 files included in this e-mail: - g_ep0-2_6_20.c is the original Linux 2.6.20 g_ep0.c from the git tree. - g_ep0.c is my modified file. - PATCH contains the differences between the 2 files. - README contains information on how PATCH was generated, and why the changes were made. Can you take a look at the file, Documentation/SubmittingPatches and resend this based on the directions written there for how to create a patch in a manner so that we can apply it? Also, if you are having mvista specific issues, I suggest contacting them, there is nothing we can do about their kernels, and we do not know what they add or remove from them, based on the kernel.org releases. And also, musb driver is not yet pushed into linux-2.6.git. Maybe you would like to sign to linux-omap mailing list. Here's the link: http://linux.omap.com/mailman/listinfo/linux-omap-open-source Also, you would like to send this email to Kevin Hilman [EMAIL PROTECTED]. He's the maintainer of the linux-davinci gittree. thanks, greg k-h -- --- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- Best Regards, Felipe Balbi [EMAIL PROTECTED] +55 92 2126-1003 Kernel Developers Team patch Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] rx errors reported by usbnet
Hi, I have a bunch of USB devices configured for ethernet over USB connected to my machine. The host is running a 2.6.16 based kernel and I notice that rx errors reported via /proc/net/dev keep increasing infinitely. Initially the device responds without any problems, but at some random time, eventually the device and USB subsystem seem to lock up, i.e. commands like lsusb begin to fail. The USB device itself is also running a 2.6.9 based kernel, but during the time the RX errors are seen there is no TX or RX from the device side. Neither are any errors reported via /proc/net/dev on the USB side. After some debug statements, I see that the RX errors are due to -71 EPROTO errors. Any help appreciated in understanding what is happening here. Here are the related messages (the messages keep repeating): ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33ce0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 ohci_hcd :00:04.0: urb c3a33da0 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev3: rxqlen 3 -- 4 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881d20 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c00 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33d40 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 Thanks. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 what atomic means. It has nothing to do with locking or protection. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags You _can_ rely on the no-wait option to prevent the allocation from sleeping or flushing pages to a disk... unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. ... and you can't rely on no-wait to succeed unless, as you say, you already know there is memory available. But that's also true for early, blocking allocations; there's nothing special about late, non-blocking malloc. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] rx errors reported by usbnet
On Thu, 17 May 2007, Yum Rayan wrote: Hi, I have a bunch of USB devices configured for ethernet over USB connected to my machine. The host is running a 2.6.16 based kernel and I notice that rx errors reported via /proc/net/dev keep increasing infinitely. Initially the device responds without any problems, but at some random time, eventually the device and USB subsystem seem to lock up, i.e. commands like lsusb begin to fail. The USB device itself is also running a 2.6.9 based kernel, but during the time the RX errors are seen there is no TX or RX from the device side. Neither are any errors reported via /proc/net/dev on the USB side. After some debug statements, I see that the RX errors are due to -71 EPROTO errors. Any help appreciated in understanding what is happening here. Here are the related messages (the messages keep repeating): ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33ce0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33e00 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881cc0 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 ohci_hcd :00:04.0: urb c3a33da0 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev3: rxqlen 3 -- 4 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881d20 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c00 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 mydev3: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c3a33d40 path 1 ep1in 6d16 cc 6 -- status -71 mydev1: rx throttle -71 mydev1: rxqlen 3 -- 4 ohci_hcd :00:04.0: urb c7881c60 path 2 ep1in 6d16 cc 6 -- status -71 mydev3: rx throttle -71 These error codes indicate low-level USB communication problems. There may be something wrong with the USB cable, or the device's USB interface may have stopped running. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 usb_host_endpoint *uhe, uint32_t bufsize, uint32_t unused0, uint32_t unused1, uint32_t unused2); The usb_device and usb_interface are implied by the usb_host_endpoint, and unused parameters are pointless. Sizes are size_t, and such a call could obviously fail because of invalid parameters. So int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); What would such a call do, though? Who would use it, and why? On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. And it cannot be interrupted either? b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags You _can_ rely on the no-wait option to prevent the allocation from sleeping or flushing pages to a disk... unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. ... and you can't rely on no-wait to succeed unless, as you say, you already know there is memory available. But that's also true for early, blocking allocations; there's nothing special about late, non-blocking malloc. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? There is a greater chance of successing with pre-allocation if you use the wait flag when you malloc? Right? --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. It's a fact of life that BSDs steal Linux code and slap their own copyright and licensing on it. The story of OpenBSD and the Broadcom wireless was just the latest example. However, we cannot preclude them doing this, and least of all by pretending that they'd stop if we ask nicely. I chose to not discuss this up to this point and take the best from Hans' independent insight, because this way I (as a kernel hacker) receive at least some benefit. If I turned Hans away right off the bat, his cohorts would still do the same thing, only without talking to us. That would be a net loss for Linux. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 to make it atomic? No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. And it cannot be interrupted either? Some atomic routines can be interrupted and some can't. If an interrupt does occur then the interrupt handler is also atomic (by definition), so no problem will arise. 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. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? There is a greater chance of successing with pre-allocation if you use the wait flag when you malloc? Right? Certainly. But turn it around: With pre-allocation you force other parts of the system to have a higher chance of failing, because you already own the memory they want (even though you may not be using it). Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 usb_device *usb, struct usb_interface *ui,
struct usb_host_endpoint *uhe, uint32_t bufsize, uint32_t unused0,
uint32_t unused1, uint32_t unused2);
The usb_device and usb_interface are implied by the usb_host_endpoint,
and unused parameters are pointless. Sizes are size_t, and such
a call could obviously fail because of invalid parameters. So
int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize);
To save the hep to struct usb_device pointer, I would like to have struct
usb_device *dev as an argument.
What would such a call do, though? Who would use it, and why?
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.
I've currently put the following into this function:
int32_t
usb_setup_endpoint(struct usb_device *dev, struct usb_host_endpoint *uhe,
uint32_t bufsize)
{
struct usbd_config cfg[2];
uint16_t mfs = usbd_get_max_frame_size((usb_endpoint_descriptor_t
*)(uhe-desc));
uint8_t type = uhe-desc.bmAttributes UE_XFERTYPE;
uint8_t addr = uhe-desc.bEndpointAddress;
usbd_transfer_unsetup(uhe-bsd_xfer, 2);
if (bufsize == 0) {
return 0;
}
bzero(cfg, sizeof(cfg));
if (type == UE_ISOCHRONOUS) {
/* Isochronous is special */
cfg[0].type = type;
cfg[0].endpoint = addr UE_ADDR;
cfg[0].direction = addr (UE_DIR_OUT|UE_DIR_IN);
cfg[0].callback = usb_linux_isoc_callback;
cfg[0].bufsize = 0; /* use wMaxPacketSize */
bcopy(cfg + 0, cfg + 1, sizeof(*cfg));
if (usbd_transfer_setup(dev-bsd_udev, uhe-bsd_iface_index,
uhe-bsd_xfer, cfg, 2, uhe,
usb_global_lock))
{
return -EINVAL;
}
} else {
if (bufsize (1 22)) {
/* limit buffer size */
bufsize = (1 22);
}
if (type == UE_CONTROL) {
/* we need enough room for the control header */
if (bufsize sizeof(usb_device_request_t)) {
bufsize = sizeof(usb_device_request_t);
}
}
if (bufsize mfs) {
/* we need to be able to hold at least one frame! */
bufsize = mfs;
}
cfg[0].type = type;
cfg[0].endpoint = addr UE_ADDR;
cfg[0].direction = addr (UE_DIR_OUT|UE_DIR_IN);
cfg[0].callback = usb_linux_non_isoc_callback;
cfg[0].bufsize = bufsize;
if (usbd_transfer_setup(dev-bsd_udev, uhe-bsd_iface_index,
uhe-bsd_xfer, cfg, 1, uhe,
usb_global_lock))
{
return -EINVAL;
}
}
return 0;
}
The reason for this is to allow Linux USB drivers to tell the FreeBSD USB
stack that they want larger/smaller buffers.
On Linux this information can be used to reserve EHCI/UHCI/OHCI USB transfer
descriptors.
On FreeBSD this function will pre-allocate one or two USB transfers for
an endpoint using the given bufsize argument. Those FreeBSD USB
transfers will then be used to do all the Linux USB transfers. This
function can block and must have a context.
So what's the model ... GPL'd Linux drivers will be modified to
incorporate that call, so they'd work better on FreeBSD?
Yes, and under Linux.
As you can see, it is not possible to emulate an on-the-fly allocation model
by a pre-allocation model. That's why I suggest this API addition.
--HPS
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 part since the attempt to keep usb-lock across the callback (read: years back). 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 start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. Yours, -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 and talking about the licensing so deeply in the thread is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. It's a fact of life that BSDs steal Linux code and slap their own copyright and licensing on it. The story of OpenBSD and the Broadcom wireless was just the latest example. However, we cannot preclude them doing this, and least of all by pretending that they'd stop if we ask nicely. I chose to not discuss this up to this point and take the best from Hans' independent insight, because this way I (as a kernel hacker) receive at least some benefit. If I turned Hans away right off the bat, his cohorts would still do the same thing, only without talking to us. That would be a net loss for Linux. This sound like well known theory: Do towards others what you want them to do towards you. I'm just giving my enemies food ;-) MODULE_LICENSE(Dual BSD/GPL); If the open-source world could unite on a common USB stack in the kernel, that would be a win for all. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). I think it's pretty much just legacy. Nobody wants to audit all the callback routines to see which ones really need interrupts to be disabled. 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 start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. None that I can recall. Even without the interrupt handling guarantee, the HCDs are (or should be) written so that callbacks won't occur recursively. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch 2.6.21-rc1-git] ehci refcounts work on ppc7448
Remove atomic operations on the reference counter for EHCI queue heads.
On various platforms (including ppc7448), atomic operations are unusable
with dma-coherent memory.
Signed-off-by: Steven J. Hill [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/usb/host/ehci-mem.c | 11 ++-
drivers/usb/host/ehci.h |9 -
2 files changed, 14 insertions(+), 6 deletions(-)
--- g26.orig/drivers/usb/host/ehci.h2007-05-17 09:06:02.0 -0700
+++ g26/drivers/usb/host/ehci.h 2007-05-17 09:07:57.0 -0700
@@ -457,7 +457,14 @@ struct ehci_qh {
struct ehci_qh *reclaim; /* next to reclaim */
struct ehci_hcd *ehci;
- struct kref kref;
+
+ /*
+* Do NOT use atomic operations for QH refcounting. On some CPUs
+* (PPC7448 for example), atomic operations cannot be performed on
+* memory that is cache-inhibited (i.e. being used for DMA).
+* Spinlocks are used to protect all QH fields.
+*/
+ u32 refcount;
unsignedstamp;
u8 qh_state;
--- g26.orig/drivers/usb/host/ehci-mem.c2007-05-17 09:06:02.0
-0700
+++ g26/drivers/usb/host/ehci-mem.c 2007-05-17 09:08:12.0 -0700
@@ -64,9 +64,8 @@ static inline void ehci_qtd_free (struct
}
-static void qh_destroy (struct kref *kref)
+static void qh_destroy(struct ehci_qh *qh)
{
- struct ehci_qh *qh = container_of(kref, struct ehci_qh, kref);
struct ehci_hcd *ehci = qh-ehci;
/* clean qtds first, and know this is not linked */
@@ -90,7 +89,7 @@ static struct ehci_qh *ehci_qh_alloc (st
return qh;
memset (qh, 0, sizeof *qh);
- kref_init(qh-kref);
+ qh-refcount = 1;
qh-ehci = ehci;
qh-qh_dma = dma;
// INIT_LIST_HEAD (qh-qh_list);
@@ -112,13 +111,15 @@ static struct ehci_qh *ehci_qh_alloc (st
/* to share a qh (cpu threads, or hc) */
static inline struct ehci_qh *qh_get (struct ehci_qh *qh)
{
- kref_get(qh-kref);
+ WARN_ON(!qh-refcount);
+ qh-refcount++;
return qh;
}
static inline void qh_put (struct ehci_qh *qh)
{
- kref_put(qh-kref, qh_destroy);
+ if (!(qh-refcount--))
+ qh_destroy(qh);
}
/*-*/
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. Examples of (c) being the release of some reserved periodic bandwidth, or cleanup then re-enabling a halted bulk queue. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 talking about the licensing so deeply in the thread is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. Not entirely. Would those drivers be forked into a BSD distro? Would Linux be expected to merge those changes? Or alternatively: just clone the Linux stack sufficiently well that new BSD-licensed drivers could be written, which would run on both systems. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); To save the hep to struct usb_device pointer, I would like to have struct usb_device *dev as an argument. Introducing new error paths ... why? As a rule we remove redudancy. What would such a call do, though? Who would use it, and why? 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 case? The reason for this is to allow Linux USB drivers to tell the FreeBSD USB stack that they want larger/smaller buffers. On Linux this information can be used to reserve EHCI/UHCI/OHCI USB transfer descriptors. I still don't get it. What's the advantage to Linux? I could imagine a new HCD entry, parallel to endpoint_disable(), called by usbcore. It could initialize HCD-internal state like a QH, and maybe ensure that the relevant TD pool isn't empty. It'd be nice to have a task context for that in all cases. But that wouldn't be visible outside usbcore... On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? Yes, and under Linux. As you can see, it is not possible to emulate an on-the-fly allocation model by a pre-allocation model. That's why I suggest this API addition. All Linux drivers are allowed to assume on-the-fly allocation though. That's a simpler model than mandatory pre-allocation. In this context, simpler is better. Seems to me that your Linux emulation is missing some important characteristics! - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 model will work better with your USB API. ... int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); To save the hep to struct usb_device pointer, I would like to have struct usb_device *dev as an argument. Introducing new error paths ... why? As a rule we remove redudancy. What would such a call do, though? Who would use it, and why? 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 case? A USB transfer on FreeBSD is equivalent to an URB on Linux. The difference is that on FreeBSD the USB transfer, struct usbd_xfer, has pointers to pre-allocated TD's, QH's and data-buffers. I want to use one or two USB transfers to move all the USB data from the Linux's URB to a FreeBSD USB transfer. The reason for this is to allow Linux USB drivers to tell the FreeBSD USB stack that they want larger/smaller buffers. On Linux this information can be used to reserve EHCI/UHCI/OHCI USB transfer descriptors. I still don't get it. What's the advantage to Linux? That the Linux USB stack can pre-allocate TD's and QH's on a per-endpoint basis. I could imagine a new HCD entry, parallel to endpoint_disable(), called by usbcore. It could initialize HCD-internal state like a QH, and maybe ensure that the relevant TD pool isn't empty. It'd be nice to have a task context for that in all cases. But that wouldn't be visible outside usbcore... On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? Yes, and under Linux. As you can see, it is not possible to emulate an on-the-fly allocation model by a pre-allocation model. That's why I suggest this API addition. All Linux drivers are allowed to assume on-the-fly allocation though. That's a simpler model than mandatory pre-allocation. In this context, simpler is better. Why is it simpler than pre-allocation? Seems to me that your Linux emulation is missing some important characteristics! --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Wednesday 16 May 2007, Alan Stern wrote: On Tue, 15 May 2007, Laurent Pinchart wrote: Hi everybody, following the discussion about the split bulk transfers, Alan Stern and David Brownell told me I shouldn't use usb_buffer_alloc as a generic purpose URB buffer allocated. However, Documentation/usb/dma.txt contradicts this. Should the documentation be fixed, or can/should usb_buffer_alloc be used to allocate URB buffers ? It's difficult to give general advice, since the performance will vary according to the platform and the usage. If a buffer is going to be used once and then thrown away, I think there's not much advantage to usb_buffer_alloc(). Although on some odd platforms that may not be true, it should be true on the vast majority. Ok. A driver should obviously not allocate a lot of DMA cache coherent memory if it's not going to use it. For buffers that are allocated at initialisation time and not used often, usb_buffer_alloc() should not be used. If a buffer is going to be used many times, then usb_buffer_alloc() might give improved performance. Again, that depends on the platform and the type of memory accesses involved. The tradeoffs are hard to assess because they involve a lot of variables: How responsive is the IOMMU, does the cache do bus-snooping, will there be many accesses to uncached memory, and so on. There's something I don't get. The documentation states that USB buffer memory should be allocated using kmalloc or get_free_pages. This means that allocated memory will be physically contiguous. However, not all controllers should require that. There are, from what I can tell, three classes of USB host controllers: - PIO host controllers don't use DMA at all, and should thus not require physically contiguous memory. The device dma_mask field is set to 0, and usb_hcd_submit_urb doesn't allocate DMA mappings for URB buffers when using such a controller. - DMA-able host controllers without hardware scatter-gather require physically contiguous memory. For those controllers, usb_hcd_submit_urb allocates DMA mappings if the URB buffers haven't been mapped already (URB_NO_*_DMA_MAP flags not set). usb_hcd_giveback_urb unmaps the buffers if they have been mapped by usb_hcd_submit_urb. As those controllers require physically contiguous memory, kmalloc or get_free_pages must be used. - DMA-able host controllers with hardware scatter-gather don't require physically contiguous memory. EHCI controllers seem to have scatter-gather capabilities. For those controllers, pressure on the memory allocator could be lowered by implementing scatter-gather. USB device drivers currently either allocate URB buffers with kmalloc/get_free_pages or call usb_buffer_alloc. When using the former, the DMA mapping is created and deleted at URB submission/completion. When using the later, DMA mappings are created once and kept for the entire life of the buffer. I suppose we should keep kmalloc/get_free_pages for buffers that are seldom used. From what I've seen so far, usb_buffer_alloc would help for buffers used for isochronous or bulk streaming, where the same URBs are submitted again and again. That would remove the DMA map/unmap overhead. Shouldn't we implement scatter-gather for EHCI (and possibly other) controllers ? Is it planned ? We would then need a generic URB buffer allocator, as the device driver should not care about what kind of memory the USB host controller needs. The allocator would be passed a parameter to DMA-map the buffer for streaming bulk/isochronous transfers. These are just my 2 cents, as I'm not too familiar with the USB stack implementation (but this is going better with every mail to/from the list :-)) Best regards, Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Wednesday 16 May 2007, David Brownell wrote: On Tuesday 15 May 2007, Laurent Pinchart wrote: Hi everybody, following the discussion about the split bulk transfers, Alan Stern and David Brownell told me I shouldn't use usb_buffer_alloc as a generic purpose URB buffer allocated. However, Documentation/usb/dma.txt contradicts this. Should the documentation be fixed, or can/should usb_buffer_alloc be used to allocate URB buffers ? I think the doc should be fixed ... avoid using it as a general purpose allocator. We've learned better since that doc was first written. :) It *can* be used to allocate buffers, in cases where the DMA map/unmap overhead of the more typical usage would excessive. So it's not going to vanish. As I explained in my answer to Alan's mail, I think a general purpose allocator will be needed if we implement scatter-gather support for EHCI controllers (provided I'm not mistaken and that the hardware actually supports it). Even without scatter-gather, a general purpose allocator could allocate virtual memory instead of physically contiguous pages for PIO USB host controllers. Could we change usb_buffer_alloc and turn it into a general purpose allocator ? A flag could be used to DMA-map the buffer when needed. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 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 failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. 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 of contiguous memory made the box swap out and become very slow. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. 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. Buffer != transfer descriptor. The bug here is asking for a 2.7 MB block of contiguous memory. As previously discussed, that's not necessary ... or desirable. Drivers asking for such things are buggy -- except possibly on dedicated systems. - Dave The system had been used for quite some time, and the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 of contiguous memory made the box swap out and become very slow. Obviously the driver should be smart enough not to try and get such a large buffer. It should allocate several smaller buffers instead. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 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 failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. 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. Buffer != transfer descriptor. Ok, sorry for the noise. The bug here is asking for a 2.7 MB block of contiguous memory. As previously discussed, that's not necessary ... or desirable. Drivers asking for such things are buggy -- except possibly on dedicated systems. I'm testing a driver patch to allocate much smaller buffers. I will probably run into issues with buggy devices that send a zero packet when the actual payload size is equal to the maximum payload size, and is a multiple of the packet size, but that's another story. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Is usb_buffer_alloc a generic URB buffer allocator ? (was Split Bulk Transfers)
On Thursday 17 May 2007, Laurent Pinchart wrote: Shouldn't we implement scatter-gather for EHCI (and possibly other) controllers ? If by scatter-gather you mean struct scatterlist, we've had that support for some time now ... in usb_sg_*() routines. That's the usual definition inside Linux. But I suspect you mean something else, not well defined. A few things I've heard called scatter gather in the past: - Single copy I/O to buffers specified by kernel (or user) virtual addresses. If the page boundaries are transfer buffer boundaries, that's handled already ... given a bit of glue code to pin the pages and dma-map them, and the same I/O queue mechanisms used by usb_sg_*(). - Combining N buffers, which aren't aligned on wMaxPacketSize boundaries ... e.g. buffers of 10, 500, and 2 bytes combined into one 512 byte transfer. This violates the fundamental model of what an URB signifies, so it wouldn't be at easy. So for most definitions we *do* already handle scatter/gather. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 case? A USB transfer on FreeBSD is equivalent to an URB on Linux. The difference is that on FreeBSD the USB transfer, struct usbd_xfer, has pointers to pre-allocated TD's, QH's and data-buffers. So it's not equivalent at all then. The call you want to add would be the first of many, and would imply a second I/O model. Linux only associates a QH and TDs -- where relevant! -- on a temporary basis, while I/O is pending. All Linux drivers are allowed to assume on-the-fly allocation though. That's a simpler model than mandatory pre-allocation. In this context, simpler is better. Why is it simpler than pre-allocation? If you've already got one model, why would you need a second one? When you've got a model that doesn't care where the buffer came from, needing to adopt a second one where you *do* need to care is obviously adding complexity. And that's on top of the performance cost of needing to copy into particular buffers. Also, the current Linux model only exposes resources to drivers if they actually need to manage them: URBs, and buffers (which may come from upper layers of the driver stack). Implementation details (like a TD or other DMA descriptor, QH, etc) are managed separately. - Dave Seems to me that your Linux emulation is missing some important characteristics! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Obviously the driver should be smart enough not to try and get such a large buffer. It should allocate several smaller buffers instead. Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks of PAGE_SIZE bytes? Is it right understood that the Linux USB stack does currently not use scatter and gathering? To me it seems like that, hence in the URB Linux only has a single DMA address value. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anybody have a working driver for ELO 1529L with Mag-Tek USB Swipe Reader?
On Thu, 17 May 2007, Jason Brewster wrote: Thanks, What kind of device is that? (could you please post at least output of lsusb, etc.). It might be that the device is standard-compliant (for example HID), so wouldn't require any extra driver. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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 touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Linux already guarantees that interrupt handlers are not re-entered. If the interrupt controller on the platform allows it, this is done by masking a specific IRQ. If that is impossible, interrupts are masked in the CPU (maybe only partially, e.g. on SPARC). However it is done though, the local_irq_save that we do adds nothing that I can see. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [patch] berry_charge.c updated with Blackberry Pearl support, and other bugfixes
Hi,
Below is a patch with the following changes to the berry_charge.c module:
1) kzalloc() is called, but memory is never freed
Is this a memory leak? I'm not sure, but the buffer is only
a dummy buffer to hold return data that is never used,
so I suspect a stack variable will suffice.
2) Added pearl mode change
Blackberry Pearls start out with a Product ID of 0006, and in
this mode, only a usb mass storage configuration is available.
This patch sends the required command to change it from 0006
to 0004, in which both mass storage and the Blackberry
database configuration are available.
Also, Pearls need to be reset explicitly before the power change
takes effect.
3) Added a sleep() for slow devices.
My kernel-fu is not up to speed, so I'm sure this is the wrong
fix, and I hope someone recommends the proper one. Older devices,
such as the 7750, are slow to reset, and this creates the
possibility of the kernel going into an endless loop, detecting
the device and trying to set the power. The devices, in some
cases of my testing, never actually changed to 500mA, but
the kernel was extremely busy trying to do so, and the entire
USB subsystem seemed to lock up (lsusb would freeze, for example).
On my system, the sleep gives the device a chance to change to
500mA, which prevents the endless loop.
- Chris
--- linux-2.6.21.1/drivers/usb/misc/berry_charge.c 2007-04-27
17:49:26.0 -0400
+++ ../linux-2.6.21.1/drivers/usb/misc/berry_charge.c 2007-05-17
14:56:07.0 -0400
@@ -26,6 +26,8 @@
#define RIM_VENDOR 0x0fca
#define BLACKBERRY 0x0001
+#define PEARL_DUAL 0x0004
+#define PEARL 0x0006
static int debug;
@@ -36,15 +38,22 @@
if (debug) \
dev_printk(KERN_DEBUG , dev , format , ## arg)
+/* We watch for product IDs 0001 and 0006, with the idea that
+ * for non-Pearl devices, we only change the charging setting,
+ * and for Pearl devices, we change the charge and the mode.
+ * If a Pearl shows up as 0004, we've already seen it and
+ * don't need to mess with it again.
+ */
static struct usb_device_id id_table [] = {
{ USB_DEVICE(RIM_VENDOR, BLACKBERRY) },
+ { USB_DEVICE(RIM_VENDOR, PEARL) },
{ },/* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, id_table);
static int magic_charge(struct usb_device *udev)
{
- char *dummy_buffer = kzalloc(2, GFP_KERNEL);
+ char dummy_buffer[2];
int retval;
if (!dummy_buffer)
@@ -78,11 +87,22 @@
return retval;
}
- dbg(udev-dev, Calling set_configuration\n);
- retval = usb_driver_set_configuration(udev, 1);
- if (retval)
- dev_err(udev-dev, Set Configuration failed :%d.\n, retval);
+ return retval;
+}
+static int magic_pearl(struct usb_device *udev)
+{
+ char dummy_buffer[2];
+ int retval;
+
+ dbg(udev-dev, Sending magic Pearl command\n);
+ retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+0xa9, 0xc0, 1, 1, dummy_buffer, 2, 100);
+ if (retval != 0) {
+ dev_err(udev-dev, Pearl magic command failed: %d.\n,
+ retval);
+ return retval;
+ }
return retval;
}
@@ -90,6 +110,9 @@
const struct usb_device_id *id)
{
struct usb_device *udev = interface_to_usbdev(intf);
+ int retval;
+
+dbg(udev-dev, Dev module, version: 2\n);
dbg(udev-dev, Power is set to %dmA\n,
udev-actconfig-desc.bMaxPower * 2);
@@ -105,6 +128,28 @@
/* turn the power on */
magic_charge(udev);
+ /* change modes if device is a Pearl */
+ if (udev-descriptor.idProduct == PEARL)
+ magic_pearl(udev);
+
+ /* set configuration and reset to activate change */
+ dbg(udev-dev, Calling set_configuration\n);
+ retval = usb_driver_set_configuration(udev, 1);
+ if (retval) {
+ dev_err(udev-dev, Set Configuration failed :%d.\n, retval);
+ return retval;
+ }
+
+ /* reset is required by the Pearl */
+ retval = usb_reset_configuration(udev);
+ if (retval) {
+ dev_err(udev-dev, Configuration reset failed: %d.\n,
retval);
+ return retval;
+ }
+
+ /* give slower devices a chance to reset properly */
+ ssleep(1);
+
/* we don't really want to bind to the device, userspace programs can
* handle the syncing just fine, so get outta here. */
return -ENODEV;
-
This SF.net email is sponsored by DB2 Express
Download DB2
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Where is that done? The HCDs just seem to call usb_hcd_giveback_urb() after dropping their internal spinlock (except the u132 one, which has always been kind of dubious and acts unmaintained). And that routine doesn't do a local_irq_save. So the primary paths certainly don't do such a thing. I could believe other paths have that in case they're not called from an IRQ handler context. Like for example with root hub URBs... - Dave Linux already guarantees that interrupt handlers are not re-entered. If the interrupt controller on the platform allows it, this is done by masking a specific IRQ. If that is impossible, interrupts are masked in the CPU (maybe only partially, e.g. on SPARC). However it is done though, the local_irq_save that we do adds nothing that I can see. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] SAĞLIĞINIZ SİZİN İÇİN ÖNEMLİYSE..
TAM KAPSAMLI CHECK-UP KAMPANYASI SAÐLIÐINIZ Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
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! The original reason to have such routines was to allocate small buffers for HID devices on systems where DMA map/unmap operations were absurdly expensive on such small buffers. (Think IOMMU ops across a slowish bus.) Is it right understood that the Linux USB stack does currently not use scatter and gathering? To me it seems like that, hence in the URB Linux only has a single DMA address value. Let me guess -- you didn't read my response on that topic ... ? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] problem with EHCI port status register
Hi I'm using HP storageworks USB DAT device on RHEL4 (based on kernel 2.6.9). It works okay most of the times, but sometimes the driver does not detect the device (about 1 out of 10 times). No other USB devices are used on the system. Let me explain some details. I turned on the CONFIG_USB_DEBUG option and put some orignal debug printk into the EHCI and core driver code. I found out that the ehci_hub_status_data() returns 0 when the DAT device is not detected. As a result the URB is not given back to the URB's complete function which is hub_irq(). If the function returns non zero, khubd is woken up as a sequence of hub_irq() and the setup control packets will be sent to the newly detected device. Am I right? The reason why ehci_hub_status_data() returns 0 is because the EHCI's port status register for the DAT is 0x1005 (PORT_POWER | PORT_PE | PORT_CONNECT), although it should be something like 0x1803 if the device is detected properly. As far as I know, the port status becomes 0x1005 only after the device is detected. Since the port status is 0x1005 when ehci_hub_status_data() is executed, the driver assumes that the device has already been detected, so it does not try to detect it as I mentioned above. Have any of you ever seen the same situation before? Or is there any way to fix this issue regarding the port status? Any suggestions would be helpful. Thanks, Tomohiro Kusumi T: Bus=01 Lev=01 Prnt=01 Port=06 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=03f0 ProdID=0125 Rev=30.30 S: Manufacturer=Hewlett Packard S: Product=DAT72 USB Tape S: SerialNumber= C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 2mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms ehci_hcd: block sizes: qh 128 qtd 96 itd 192 sitd 96 ACPI: PCI interrupt :00:1d.7[A] - GSI 23 (level, low) - IRQ 177 ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: reset hcs_params 0x104208 dbg=1 cc=4 pcc=2 ordered !ppc ports=8 ehci_hcd :00:1d.7: reset hcc_params 6871 thresh 7 uframes 1024 64 bit addr ehci_hcd :00:1d.7: capability 101 at 68 PCI: Setting latency timer of device :00:1d.7 to 64 ehci_hcd :00:1d.7: irq 177, pci mem f881a000 SELinux: initialized (dev usbdevfs, type usbdevfs), uses genfs_contexts ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: reset command 080022 (park)=0 ithresh=8 Async period=1024 Reset HALT PCI: cache line size of 128 is not supported by device :00:1d.7 ehci_hcd :00:1d.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN ehci_hcd :00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2004-May-10 ehci_hcd :00:1d.7: supports USB remote wakeup usb usb1: default language 0x0409 usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 2.6.9-acpi-debug ehci_hcd usb usb1: SerialNumber: :00:1d.7 usb usb1: hotplug usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: hotplug hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: ganged power switching hub 1-0:1.0: individual port over-current protection hub 1-0:1.0: Single TT hub 1-0:1.0: TT requires at most 8 FS bit times hub 1-0:1.0: power on to power good time: 20ms hub 1-0:1.0: local power source is good [hub_configure] submit int urb for dev 1 [rh_urb_enqueue] enqueue int urb for dev 1 [rh_status_urb] set rh timer for dev 1 hub 1-0:1.0: enabling power on all ports ehci_hcd :00:1d.7: irq status 0004 PCD [ehci_irq] port 8 status 0x1000 [ehci_irq] port 7 status 0x1803 - the port status starts with 0x1803 [ehci_irq] port 6 status 0x1000 [ehci_irq] port 5 status 0x1000 [ehci_irq] port 4 status 0x1000 [ehci_irq] port 3 status 0x1000 [ehci_irq] port 2 status 0x1000 [ehci_irq] port 1 status 0x1000 [ehci_irq] finish ehci_irq without ehci_work [ehci_hub_status_data] port 1 status 0x1000 [ehci_hub_status_data] port 2 status 0x1000 [ehci_hub_status_data] port 3 status 0x1000 [ehci_hub_status_data] port 4 status 0x1000 [ehci_hub_status_data] port 5 status 0x1000 [ehci_hub_status_data] port 6 status 0x1000 [ehci_hub_status_data] port 7 status 0x1005 - somehow it became 0x1005 (should be still 0x1803) [ehci_hub_status_data] port 8 status 0x1000 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last
Re: [linux-usb-devel] [Bugme-new] [Bug 8498] New: BUG: 2.6.22-rc1+ resume after suspend-to-disk broken when USB compiled in.
On Thu, 17 May 2007 21:52:30 -0700 [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8498 Summary: BUG: 2.6.22-rc1+ resume after suspend-to-disk broken when USB compiled in. Kernel Version: 2.6.22-rc1-d3a36fb82a0864a85e238ac946817030a18c5f9a Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.21.1 Distribution: Gentoo Hardware Environment: x86_64 Software Environment: Problem Description: Suspends to disk fine, but when resuming it breaks due to USB. I have confirmed by suspending to disk and resuming without USB compiled in. I don't have time to do a bisect tonight, but will try to track this down within the next 48 hours if my dmesg doesn't give enough hints within that time. Anything I can do please let me know. A post-2.6.21 regression.. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
