Re: [linux-usb-devel] Is libusb dead?
Am Sonntag, 13. Mai 2007 12:24 schrieb Greg KH: > "I'm" not designing it, I just offered up my initial ideas, others are Sorry, I didn't want to offend. > trying to run with them and see if they are crap or not. Most likely, > crap, but hopefully they will have figured it out by the time we get it > into the kernel tree :) > > Any help you can provide them will probably be greatly appreciated. Then my advice is: USB devices have interfaces. Not reflecting that in the design is a bad idea. Regards Oliver - 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] converting appletouch to usb autosuspend...
Am Montag, 14. Mai 2007 02:53 schrieb Alistair John Strachan: > > What did you use instead of hci_usb then ? usbkbd ? This won't give you > > the special keys etc... > > Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got > nothing to do with the keyboard. I unloaded both appletouch AND hci_usb. If you want large power savings from USB autosuspend, all loaded drivers must support autosuspend. The HCD can suspend only if all connected devices are suspended. Are you willing to test patches for HID & the new last_busy based usb core infrastructure? Regards Oliver - 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] Patches still in the queue
Am Sonntag, 13. Mai 2007 17:15 schrieb Alan Stern: > On Sun, 13 May 2007, Oliver Neukum wrote: > > > Am Samstag, 12. Mai 2007 21:26 schrieb Alan Stern: > > > It could be controlled by both a Kconfig option and a writable module > > > parameter. I'm not sure that would satisfy everybody. But maybe there > > > _is_ no way to satisfy everyone... > > > > I agree. Hibernation with a mounted fs on usb sucks, no matter what > > you do. > > Don't forget that "persistence" applies to network interfaces just as much > as to block devices. Yes, but it is not problematic, as you run no additional risk. The worst thing that could happen is that you assign an IP to the wrong interface. But if the driver can't tell apart devices, neither can udev. So you've got nothing to lose and a lot to gain. > > I suggest a setting per interface in sysfs. > > That approach isn't feasible. For one thing, "persistence" applies to > entire devices, not to interfaces. For another, we can't make a device > persistent unless we also make all its ancestor hubs persistent. (If a > hub disappears during resume then its children are destroyed too.) Well, we have again a distinction between device and interface persistance. Some drivers and therefore interfaces will be unable to support persistance. It must be possible to resurrect only some interfaces of a device. On the core side persistance is asked for if a devices's interface or a device lower in the tree want persistance. > While a per-device flag might be workable, I think the most > straightforward approach is a single system-wide On/Off setting. Why? Treating a hard drive differently than a floppy seems very reasonable to me. Regards Oliver - 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 14/16] USB: Add usbfs ioctl to get the frame number
On Sat, May 12, 2007 at 12:44:38AM -0700, Pete Zaitcev wrote: > On Fri, 11 May 2007 23:23:18 -0700, Greg KH <[EMAIL PROTECTED]> wrote: > > > I thought that you needed to do something with this value pretty > > quickly, and that by the time you were able to send something back into > > the kernel, the value would be not correct anymore. But if this is > > really just like a timestamp, then ok, I have no objection other than it > > needs to be correct for all host controllers. > > Greg, I'm sorry if I'm wrong, but it looks you missed the funny part. > Danny's device remembers the value that HC circulated in the SOF frame. > It then supplies that value alongside some data it returns. By reading > the "current" frame number from HC, Danny's application can tell > how many frames back, approximately, these data were generated > (this is not the time when it was transferred across USB). Ah, yeah, I missed that. If Alan fixes up the hcds, I'll take the patch. 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] Patches still in the queue
On Sat, May 12, 2007 at 03:26:19PM -0400, Alan Stern wrote: > On Fri, 11 May 2007, Greg KH wrote: > > > > Can you suggest a better way of packaging it to help support the distros? > > > I'm perfectly willing to change the way USB-persist gets enabled, to > > > insure that people don't turn it on unless they really mean to. > > > > Is there any way to turn it on at run-time? That would be better for > > everyone involved so that the feature will always be present and no > > rebuilding of kernels is needed. > > Ha! When I first started working on this stuff, it was controlled by a > module parameter. Dave Brownell objected then because there was no way > for distros to turn it off! Well, as long as we make it so that root access is required to turn it on, and we spit out some nasty meesage to the kernel log when it is disabled, I don't mind. > It could be controlled by both a Kconfig option and a writable module > parameter. I'm not sure that would satisfy everybody. But maybe there > _is_ no way to satisfy everyone... That sounds reasonable, I don't object to that. 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] converting appletouch to usb autosuspend...
On Monday 14 May 2007 01:46:10 Soeren Sonnenburg wrote: > On Sat, 2007-05-12 at 22:47 +0100, Alistair John Strachan wrote: > > On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote: > > > Dear all, > > [...] > > > > While we are at it usb related powerhogs on this macbook pro are > > > uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) > > > too... > > > > I've found that hci_usb also hogs power on the Macbook; blacklisting this > > module cuts down HZ considerably. I also found appletouch consumed ticks, > > I guess without loading appletouch ? Then there really is something in > there that needs to be fixed.. > > > just as you did. > > What did you use instead of hci_usb then ? usbkbd ? This won't give you > the special keys etc... Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got nothing to do with the keyboard. I unloaded both appletouch AND hci_usb. > > uhci_hcd then drops to noise; my Macbook's sitting on 10W with the > > backlight on minimum, which is about what it can manage in OS X on > > maximum life settings. > > Thats quite some improvement... Yes indeed. The only thing left to improve, as I understand it, is enabling the C4/C4e power states available on the Core 2 Duo, which don't currently seem to be utilised by Linux. I notice, however, that the screenshot on the Intel Powertop page does seem to have these states available? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - 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] converting appletouch to usb autosuspend...
On Sat, 2007-05-12 at 22:47 +0100, Alistair John Strachan wrote: > On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote: > > Dear all, [...] > > While we are at it usb related powerhogs on this macbook pro are > > uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) > > too... > > I've found that hci_usb also hogs power on the Macbook; blacklisting this > module cuts down HZ considerably. I also found appletouch consumed ticks, I guess without loading appletouch ? Then there really is something in there that needs to be fixed.. > just as you did. What did you use instead of hci_usb then ? usbkbd ? This won't give you the special keys etc... > uhci_hcd then drops to noise; my Macbook's sitting on 10W with the backlight > on minimum, which is about what it can manage in OS X on maximum life > settings. Thats quite some improvement... Soeren. -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - 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] Make appletouch shut up when it has nothing to say
On Sun, 2007-05-13 at 20:57 +0100, Matthew Garrett wrote: > Ok, I've tidied this up a little. I've separated the actual mode init > code into a separate function in order to avoid code duplication, and no > longer creating a new workqueue. The only other change is something that > I /think/ is actually a bug in the driver to begin with, but I'd like > some more feedback on that first - the first packet sent after the mode > change has 0x20 in the final byte. This seems to be interpreted as a > left mouse button press. As a result, moving the touchpad sends a false > press after every reinitialisation, or (approximately) every time the > pointer is moved. As far as I can tell this also happens with the > existing code, but is probably not noticable there because it won't > appear again after the first touch on the pad. Just skipping that case > seems to work fine. This patch indeed fixes the problem and I have yet to observe problems with it... However I don't know whether a re-init is the intended way of dealing with it... Soeren -- Sometimes, there's a moment as you're waking, when you become aware of the real world around you, but you're still dreaming. - 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] How can I compare the performance between Linux 2.4 and 2.6?
Dear All, How can I get the time-length of "interrupt handling" of the system? many thanks, Brooks - 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] Make appletouch shut up when it has nothing to say
On Sun, 13 May 2007 20:57:25 +0100, Matthew Garrett <[EMAIL PROTECTED]> wrote: > Ok, I've tidied this up a little. [...] Looks fine here... well, almost. Did you try rmmod (I don't even know if it's applicable, sorry)? Usually, when schedule_work is involved, you want to make sure that a scheduled work won't be run when the module is gone. More often, a device removal is the issue, but as I take it, such is not possible for a built-in device :-) . In most cases, all it takes is a strategically placed flush_scheduled_work(). -- 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] Is libusb dead?
On Tue, Apr 24, 2007 at 07:58:33AM +0200, Oliver Neukum wrote: > Am Dienstag, 24. April 2007 01:32 schrieb Greg KH: > > On Tue, Apr 24, 2007 at 01:24:02AM +0200, Oliver Neukum wrote: > > > Am Dienstag, 24. April 2007 00:35 schrieb Greg KH: > > > > > This suggests that usbfs2 should have special "interface" files as > > > > > well as > > > > > a special "device" file and "endpoint" files. > > > > > > > > Nah, I don't think that will be needed. > > > > > > 1. Interfaces have properties, namely the setting > > > > Yes, which we should be able to control through the control endpoint > > with an ioctl, right? > > No, because then we'd have to continue giving access to the whole > device if we want to drive only an interface. The 0 endpoint must be > replicated for each interface, which is in effect the "interface" file > Alan is talking about. Plus, there are situation where some requests > to endpoint 0 must fail and others must work. > > > > 2. We cannot operate solely at the level of the endpoint > > > We must know which requests are affected when an interface > > > is affected, eg. reset cannot restore the altsetting. This cannot work > > > at the endpoint level because endpoint 0 is shared. We cannot drop > > > claiming an interface as is done in the current usbfs. > > > > Once you open an endpoint that is not endpoint 0 that would signify that > > the interface is then "claimed" as far as the kernel goes, right? > > That's not enough. The kernel must have a notion of _who_ owns the > interface. As a task may own several interfaces, the action must be > explicit. Besides, an interface is not required to have endpoints, nor > should a task be required to open an endpoint just for show. > > You are designing a kludge. "I'm" not designing it, I just offered up my initial ideas, others are trying to run with them and see if they are crap or not. Most likely, crap, but hopefully they will have figured it out by the time we get it into the kernel tree :) Any help you can provide them will probably be greatly appreciated. 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] Fwd: sn9c102 vs 2.6.21 problems (-ENOSPC)
Hello, some persons are reporting -ENOSPC errors from usb_submit_urb() in the sn9c102 driver for some unkown reasons. I can't reproduce this bug, although I tested and compiled the driver against the same version of the kernel used by one of the above users (default kubuntu 2.6.20-15-generic namely). Everything is working fine on my machine, so for now I can't give you further details about this issue. I suspect there have been some changes in the USB internals affecting usb_submit_urb(). Is this the reason in your opinion? Below is another bug report. The latest version of the sn9c102 used in these tests is available at http://www.linux-projects.org or included in 2.6.21-mm2. Best regards Luca -- Forwarded Message -- Subject: sn9c102 vs 2.6.21 problems Date: sabato 12 maggio 2007 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] I have a Chicony DC-2110 webcam. It was chosen to avoid the need for external linux drivers. Thank you for your contribution to the linux community by making a lot of webcam owners happy around the world. However unfortunately things sometimes go wrong, and I want to report an error here. My webcam have been working fine using Ekiga and sonic-snap until a recent kernel upgrade. I'm using the Hardened favour of Gentoo Linux. First I wasn't sure if the hardening features (PaX, grsecurity) may interfere with the driver, but after I've got exactly the same error messages using a vanilla kernel from kernel.org it was clear that it's not related to these special security additions. The symptom is, that previously functioning v4l2 programs fail to handle or even find the device. 1. the kernel log says: *** May 11 03:03:36 hostname usb 3-1: new full speed USB device using uhci_hcd and address 4 May 11 03:03:36 hostname usb 3-1: configuration #1 chosen from 1 choice May 11 03:03:36 hostname usb 3-1: SN9C10[12] PC Camera Controller detected (vid/pid 0x0C45:0x600D) May 11 03:03:36 hostname usb 3-1: PAS106B image sensor detected May 11 03:03:36 hostname usb 3-1: Initialization succeeded May 11 03:03:36 hostname usb 3-1: V4L2 device registered as /dev/video0 May 11 03:03:36 hostname usb 3-1: Optional device control through 'sysfs' interface ready May 11 03:04:31 hostname usb 3-1: usb_submit_urb() failed, error -28 *** It repeats the last line as many times I try to access the device by any program. 2. sonic-snap fails like this: *** sonic-snap-gui Cannot open '/dev/video0': 28, No space left on device *** 3. Ekiga even won't find the webcam. I have a basic knowledge of the kernel, and it's clear, that the driver calls this function pretty clearly. I also suspect, that the data transfer completely fails. I've noticed, that with 2.6.21, a version bump happened regarding sn9c102, with a couple of new features. I reverted the driver to the previous version, and even after this I couldn't get it to work. It seems to me, that some changes were introduced in the USB layer with the advent of 2.6.21 blocking this driver to function correctly. I assume, that I'm not the only one with this complain. I hope, that I've found the right person, and I'll try to do my best to help you to fix this issue. Do you have any webcams failing with vanilla 2.6.21? Please let me know, what should I do next. Regards, Attila -- dr Tóth Attila, Radiológus Szakorvos jelölt, 06-20-825-8057, 06-30-5962-962 Attila Toth MD, Radiologist in Training, +36-20-825-8057, +36-30-5962-962 --- - 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] Error -28 from usb_submit_urb function.
On Sun, 13 May 2007, Marek Brudka wrote: > Hi, > > I have a problem with my sn9c102 webcam. After some debugging with Luca > Ricolia (see below), > > Luca recognized that the problem comes from usb_submit_urb function, and > probably was introduced recently Um, what was the actual problem? Is it the "Error -28" in your Subject line? -28 is -ENOSPC (which explains the error message for your "cat" command). It means the driver is trying to overcommit the available bandwidth. If you build a kernel with CONFIG_USB_DEBUG turned on, you'll probably see some warning messages in the dmesg log when the error occurs. 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] [PATCH] Make appletouch shut up when it has nothing to say
Ok, I've tidied this up a little. I've separated the actual mode init
code into a separate function in order to avoid code duplication, and no
longer creating a new workqueue. The only other change is something that
I /think/ is actually a bug in the driver to begin with, but I'd like
some more feedback on that first - the first packet sent after the mode
change has 0x20 in the final byte. This seems to be interpreted as a
left mouse button press. As a result, moving the touchpad sends a false
press after every reinitialisation, or (approximately) every time the
pointer is moved. As far as I can tell this also happens with the
existing code, but is probably not noticable there because it won't
appear again after the first touch on the pad. Just skipping that case
seems to work fine.
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index e321526..f126de8 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -155,6 +155,8 @@ struct atp {
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
int overflowwarn; /* overflow warning printed? */
int datalen;/* size of an USB urb transfer
*/
+ int idlecount; /* number of empty packets */
+ struct work_struct work;
};
#define dbg_dump(msg, tab) \
@@ -208,6 +210,51 @@ static inline int atp_is_geyser_3(struct atp *dev)
(productId == GEYSER4_JIS_PRODUCT_ID);
}
+static int atp_geyser3_init(struct usb_device *udev)
+{
+ char data[8];
+ int size;
+
+ size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ ATP_GEYSER3_MODE_READ_REQUEST_ID,
+ USB_DIR_IN | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
+ ATP_GEYSER3_MODE_REQUEST_VALUE,
+ ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+
+ if (size != 8) {
+ err("Could not do mode read request from device"
+ " (Geyser 3 mode)");
+ return -EIO;
+ }
+
+ /* Apply the mode switch */
+ data[0] = ATP_GEYSER3_MODE_VENDOR_VALUE;
+
+ size = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ ATP_GEYSER3_MODE_WRITE_REQUEST_ID,
+ USB_DIR_OUT | USB_TYPE_CLASS |
+ USB_RECIP_INTERFACE,
+ ATP_GEYSER3_MODE_REQUEST_VALUE,
+ ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+
+ if (size != 8) {
+ err("Could not do mode write request to device"
+ " (Geyser 3 mode)");
+ return -EIO;
+ }
+ return 0;
+}
+
+/* Reinitialise the device if it's a geyser 3 */
+static void atp_reinit(struct work_struct *work)
+{
+ struct atp *dev = container_of(work, struct atp, work);
+ struct usb_device *udev = dev->udev;
+
+ dev->idlecount = 0;
+ atp_geyser3_init(udev);
+}
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -441,7 +488,6 @@ static void atp_complete(struct urb* urb)
dev->y_old = y;
}
else if (!x && !y) {
-
dev->x_old = dev->y_old = -1;
input_report_key(dev->input, BTN_TOUCH, 0);
input_report_abs(dev->input, ABS_PRESSURE, 0);
@@ -449,10 +495,21 @@ static void atp_complete(struct urb* urb)
/* reset the accumulator on release */
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
+
+ /* Geyser 3 will continue to send packets continually after
+ the first touch unless reinitialised. Do so if it's been
+ idle for a while in order to avoid waking the kernel up
+ several hundred times a second */
+ if (atp_is_geyser_3(dev)) {
+ dev->idlecount++;
+ if (dev->idlecount == 10)
+ schedule_work (&dev->work);
+ }
}
- input_report_key(dev->input, BTN_LEFT,
-!!dev->data[dev->datalen - 1]);
+ if (dev->data[dev->datalen-1] != 20)
+ input_report_key(dev->input, BTN_LEFT,
+!!dev->data[dev->datalen - 1]);
input_sync(dev->input);
@@ -533,35 +590,9 @@ static int atp_probe(struct usb_interface *iface, const
struct usb_device_id *id
* packets (Report ID 2). This code changes device mode, so it
* sends raw sensor reports (Report ID 5).
*/
- char data[8];
- int size;
-
- size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
- ATP_GEYSER3_MODE_READ_REQUEST
Re: [linux-usb-devel] [PATCH] Make appletouch shut up when it has nothing to say
On Sun, 13 May 2007 18:20:53 +0100, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> +static void atp_reinit(struct work_struct *work)
> +{
> + char data[8];
> + size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
> +ATP_GEYSER3_MODE_READ_REQUEST_ID,
> +USB_DIR_IN | USB_TYPE_CLASS |
> USB_RECIP_INTERFACE,
> +ATP_GEYSER3_MODE_REQUEST_VALUE,
> +ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
Generally speaking, DMA-ing from stack is not allowed. Maybe you want
to add a comment saying "buffer on stack because this is Mac-only driver".
I would not ask for kmalloc here which is entirely pointless.
> +
> + /* Geyser 3 will continue to send packets continually after
> +the first touch unless reinitialised. Do so if it's been
> +idle for a while in order to avoid waking the kernel up
> +several hundred times a second */
> + if (dev->idlecount >= 10)
> + queue_work (appletouch_wq, &dev->work);
So, why don't you check for Geyser 3 or whatnot here instead of doing
it inside the work function? Why poking workqueue on other systems?
> + appletouch_wq = create_singlethread_workqueue("kappletouch");
> + if (!appletouch_wq) {
> + printk(KERN_ERR "appletouch: failed to create workqueue\n");
> + return -ENOMEM;
> + }
> return usb_register(&atp_driver);
I'm wondering about the wisdom of this too. Why won't the stock
workqueue work? We have way too many daemons already. Plus, making
one more unconditionally regardless of hardware present seems like
stepping over the line to me.
Overall this seems like a good patch to me, only needs to be less
intrusive for owners of other hardware.
-- 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] Make appletouch shut up when it has nothing to say
The appletouch devices found in the Intel Macs (and possibly some later
PPC ones?) send a constant stream of packets after the first touch. This
results in the kernel waking up around once every couple of milliseconds
to process them, making it almost impossible to spend any significant
period of time in C3 state on a dynamic HZ kernel. Sending the mode
initialisation code makes the device shut up until it's touched again.
This patch does so after receiving 10 packets with no interesting
content.
Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index e321526..7931a76 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -155,8 +155,12 @@ struct atp {
int xy_acc[ATP_XSENSORS + ATP_YSENSORS];
int overflowwarn; /* overflow warning printed? */
int datalen;/* size of an USB urb transfer
*/
+ int idlecount; /* number of empty packets */
+ struct work_struct work;
};
+static struct workqueue_struct *appletouch_wq;
+
#define dbg_dump(msg, tab) \
if (debug > 1) {\
int i; \
@@ -208,6 +212,46 @@ static inline int atp_is_geyser_3(struct atp *dev)
(productId == GEYSER4_JIS_PRODUCT_ID);
}
+/* Reinitialise the device if it's a geyser 3 */
+static void atp_reinit(struct work_struct *work)
+{
+ struct atp *dev = container_of(work, struct atp, work);
+ struct usb_device *udev = dev->udev;
+ char data[8];
+ int size;
+
+ if (!atp_is_geyser_3(dev))
+ return;
+
+ size = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
+ ATP_GEYSER3_MODE_READ_REQUEST_ID,
+ USB_DIR_IN | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
+ ATP_GEYSER3_MODE_REQUEST_VALUE,
+ ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+
+ if (size != 8) {
+ err("Could not do mode read request from device"
+ " (Geyser 3 mode)");
+ return;
+ }
+
+ /* Apply the mode switch */
+ data[0] = ATP_GEYSER3_MODE_VENDOR_VALUE;
+
+ size = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ ATP_GEYSER3_MODE_WRITE_REQUEST_ID,
+ USB_DIR_OUT | USB_TYPE_CLASS |
+ USB_RECIP_INTERFACE,
+ ATP_GEYSER3_MODE_REQUEST_VALUE,
+ ATP_GEYSER3_MODE_REQUEST_INDEX, &data, 8, 5000);
+
+ if (size != 8) {
+ err("Could not do mode write request to device"
+ " (Geyser 3 mode)");
+ return;
+ }
+}
+
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
int *z, int *fingers)
{
@@ -419,6 +463,7 @@ static void atp_complete(struct urb* urb)
ATP_YFACT, &y_z, &y_f);
if (x && y) {
+ dev->idlecount = 0;
if (dev->x_old != -1) {
x = (dev->x_old * 3 + x) >> 2;
y = (dev->y_old * 3 + y) >> 2;
@@ -441,7 +486,7 @@ static void atp_complete(struct urb* urb)
dev->y_old = y;
}
else if (!x && !y) {
-
+ dev->idlecount++;
dev->x_old = dev->y_old = -1;
input_report_key(dev->input, BTN_TOUCH, 0);
input_report_abs(dev->input, ABS_PRESSURE, 0);
@@ -449,6 +494,13 @@ static void atp_complete(struct urb* urb)
/* reset the accumulator on release */
memset(dev->xy_acc, 0, sizeof(dev->xy_acc));
+
+ /* Geyser 3 will continue to send packets continually after
+ the first touch unless reinitialised. Do so if it's been
+ idle for a while in order to avoid waking the kernel up
+ several hundred times a second */
+ if (dev->idlecount >= 10)
+ queue_work (appletouch_wq, &dev->work);
}
input_report_key(dev->input, BTN_LEFT,
@@ -636,6 +688,8 @@ static int atp_probe(struct usb_interface *iface, const
struct usb_device_id *id
/* save our data pointer in this interface device */
usb_set_intfdata(iface, dev);
+INIT_WORK(&dev->work, atp_reinit);
+
return 0;
err_free_buffer:
@@ -694,12 +748,18 @@ static struct usb_driver atp_driver = {
static int __init atp_init(void)
{
+ appletouch_wq = create_singlethread_workqueue("kappletouch");
+ if (!appletouch_wq) {
+ printk(KERN_ERR "appletouch: failed to create workqueue\n");
+ retur
[linux-usb-devel] Error -28 from usb_submit_urb function.
Hi, I have a problem with my sn9c102 webcam. After some debugging with Luca Ricolia (see below), Luca recognized that the problem comes from usb_submit_urb function, and probably was introduced recently in 2.6.20 kernel, maybe in ubuntu only. Can anyone help us with this ? Best regards Marek lsusb: Bus 002 Device 010: ID 0c45:608f Microdia Bus 002 Device 005: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter Bus 002 Device 002: ID 045e:006a Microsoft Corp. uname -a Linux wiejca97c 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64 GNU/Linux lspci: 00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2) 00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2) 00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2) 00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2) 00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2) 00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2) 00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2) 00:02.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1) 00:05.0 VGA compatible controller: nVidia Corporation C51PV [GeForce 6150] (rev a2) 00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2) 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3) 00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3) 00:0b.0 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0b.1 USB Controller: nVidia Corporation MCP51 USB Controller (rev a3) 00:0d.0 IDE interface: nVidia Corporation MCP51 IDE (rev a1) 00:0e.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) 00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2) 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 04:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 04:08.0 Network controller: RaLink RT2561/RT61 rev B 802.11g CHAT: Hi 17:51:48 l_r 17:51:52 i miswrote in my previous email: i didn't not test the driver on ubuntu-feisty yet, although i have it mbrudka1 17:52:16 its not only feisty but also smd64 architecture :) well, amd64 l_r 17:52:35 ok, videoview does not work definitly mbrudka1 17:52:44 it doesn't l_r 17:53:07 i know, it's compiled for 32-bit mbrudka1 17:53:27 I see l_r 17:53:28 however do a simple cat mbrudka1 17:53:41 however it seems vv finds all necessary libraries l_r 17:54:07 do a simple cat on the video device and tell me the kernel messages load the driver with debug=3 first mbrudka1 17:56:31 May 13 17:55:49 wiejca97c kernel: [ 4322.911221] sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers v1:1.44 May 13 17:55:49 wiejca97c kernel: [ 4322.911935] usbcore: registered new interface driver sn9c102 May 13 17:56:11 wiejca97c kernel: [ 4342.238572] usb 2-5: new full speed USB device using ohci_hcd and address 7 May 13 17:56:11 wiejca97c kernel: [ 4342.427369] usb 2-5: configuration #1 chosen from 1 choice May 13 17:56:11 wiejca97c kernel: [ 4342.432668] usb 2-5: SN9C103 PC Camera Controller detected (vid:pid 0x0C45:0x608F) May 13 17:56:11 wiejca97c kernel: [ 4342.456929] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for HV7131D image sensor May 13 17:56:11 wiejca97c kernel: [ 4342.473116] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for HV7131D image sensor May 13 17:56:11 wiejca97c kernel: [ 4342.505470] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for HV7131R image sensor May 13 17:56:11 wiejca97c kernel: [ 4342.529751] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for MI-0343 image sensor May 13 17:56:11 wiejca97c kernel: [ 4342.554012] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for MI-0360 image sensor May 13 17:56:11 wiejca97c kernel: [ 4342.578290] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for PAS106B image sensor May 13 17:56:11 wiejca97c kernel: [ 4342.594468] usb 2-5: [sn9c102_i2c_try_raw_read:404] I2C read failed for PAS106B im
Re: [linux-usb-devel] Patches still in the queue
On Sun, 13 May 2007, Oliver Neukum wrote: > Am Samstag, 12. Mai 2007 21:26 schrieb Alan Stern: > > It could be controlled by both a Kconfig option and a writable module > > parameter. I'm not sure that would satisfy everybody. But maybe there > > _is_ no way to satisfy everyone... > > I agree. Hibernation with a mounted fs on usb sucks, no matter what > you do. Don't forget that "persistence" applies to network interfaces just as much as to block devices. > I suggest a setting per interface in sysfs. That approach isn't feasible. For one thing, "persistence" applies to entire devices, not to interfaces. For another, we can't make a device persistent unless we also make all its ancestor hubs persistent. (If a hub disappears during resume then its children are destroyed too.) While a per-device flag might be workable, I think the most straightforward approach is a single system-wide On/Off setting. 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] [PATCH 14/16] USB: Add usbfs ioctl to get the frame number
On Sat, 12 May 2007, Pete Zaitcev wrote: > On Sat, 12 May 2007 15:40:45 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> > wrote: > > > > timestamp, which would not depend on HC implementing SOF number > > > as a monotonously increasing counter (I think, it's not guaranteed). > > > The frame numbers are guaranteed to be monotonically increasing until they > > roll over from 2047 to 0 (see 8.3.3, 8.4.3, and 10.2.3 in the USB spec). > > I see, you're right, of course. I only looked at 8.4.3, and it was somewhat > vague. The 10.2.3 places stronger restrictions on the way numbers are > generated, although oddly enough it alows a host to keep wider counters > than are needed. Indeed, the spec includes this puzzling language: The current (micro)frame number as returned by the host (Host Controller or HCD) is at least 32 bits, although the Host Controller itself is not required to maintain more than 11 bits when operating with full-speed devices or 14 bits when operating with high-speed devices. It's not at all clear what this is supposed to mean. Does it refer to a register in the host controller hardware, or is it talking about the value returned from a driver's subroutine? Does it mean that a 32-bit value is returned, of which only the lowest 11 (or 14) need to be valid? Or does it mean that the driver should maintain a full 32-bit (minimum) counter, where the lowest bits always agree with the value reported by the hardware? 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] Question about EHCI PCI/platform drivers
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 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? Thanks, Tzachi - 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
