Re: [linux-usb-devel] [patch 2.6.18-rc3] ohci-sa1111 build fix on pxa
On Sunday 30 July 2006 8:58 pm, Greg KH wrote: > On Sun, Jul 30, 2006 at 08:51:17PM -0700, David Brownell wrote: > > This must only have been build tested on sa-1100 hardware, > > but the chip is also used on some pxa-25x boards. > > Is this 2.6.18 material, or can it wait? It can wait ... it's been there since this bus glue was checked in!! - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Claim Interface before snd_usb_audio does
Hey, Trying to modify the Micronas GO7007SB Driver to work with the board that I've got. I've managed to get the video working, but now I'd like to get the audio working. So far, all the other boards that the driver has been written to work with either do not support audio or support both video and audio through an EZ-USB chip connected the parallel interface of the chip so the driver has been designed around supported both audio and video through one interface. On my board, however, there the USB interface of the GO7007SB chip is used and its USB device descriptor contains three interfaces, the video interface, an audio control interface and an audio streaming interface. That means that if I want to access the audio endpoint I need to claim the audio interfaces as well as the video interfaces. However if I call usb_driver_claim_interface in the probe function of the driver that matches with the video interface, it fails with EBUSY, presumably because the snd_usb_audio driver has already claimed those interfaces (even though it fails to successfully work as its driver). Alternatively if I modify my matching table to include the audio interfaces, I end up with three instances of the driver rather than one. I realise that I could modify the driver to separate the audio driver out from the video driver and have the video driver claim the video interface and the audio driver claim the audio interfaces, but that would involve modifying the driver more that I would like to. Is there a way for either reclaim the audio interfaces from the snd_usb_audio driver or to have the GO7007SB driver load and claim those interfaces first? JHZ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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 2.6.18-rc3] ohci-sa1111 build fix on pxa
On Sun, Jul 30, 2006 at 08:51:17PM -0700, David Brownell wrote: > This must only have been build tested on sa-1100 hardware, > but the chip is also used on some pxa-25x boards. Is this 2.6.18 material, or can it wait? thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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.18-rc3] ohci-sa1111 build fix on pxa
This must only have been build tested on sa-1100 hardware,
but the chip is also used on some pxa-25x boards.
- Dave
Build fixes for ohci-sa with PXA ... it assumes SA-1100 CPUs,
but some PXA 255 boards use it too. (And minor whitespace fixes.)
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: pxa/drivers/usb/host/ohci-sa.c
===
--- pxa.orig/drivers/usb/host/ohci-sa.c 2006-07-30 18:10:20.0 -0700
+++ pxa/drivers/usb/host/ohci-sa.c 2006-07-30 19:51:20.0 -0700
@@ -4,7 +4,7 @@
* (C) Copyright 1999 Roman Weissgaerber <[EMAIL PROTECTED]>
* (C) Copyright 2000-2002 David Brownell <[EMAIL PROTECTED]>
* (C) Copyright 2002 Hewlett-Packard Company
- *
+ *
* SA Bus Glue
*
* Written by Christopher Hoover <[EMAIL PROTECTED]>
@@ -12,17 +12,19 @@
*
* This file is licenced under the GPL.
*/
-
+
#include
#include
+
+#ifdef CONFIG_SA1100
#include
#include
-#include
-
-#ifndef CONFIG_SA
-#error "This file is SA- bus glue. CONFIG_SA must be defined."
+#else
+#define machine_has_neponset() 0
#endif
+#include
+
extern int usb_disabled(void);
/*-*/
@@ -31,7 +33,7 @@ static void sa_start_hc(struct sa111
{
unsigned int usb_rst = 0;
- printk(KERN_DEBUG __FILE__
+ printk(KERN_DEBUG __FILE__
": starting SA- OHCI USB Controller\n");
#ifdef CONFIG_SA1100_BADGE4
@@ -65,7 +67,7 @@ static void sa_start_hc(struct sa111
static void sa_stop_hc(struct sa_dev *dev)
{
unsigned int usb_rst;
- printk(KERN_DEBUG __FILE__
+ printk(KERN_DEBUG __FILE__
": stopping SA- OHCI USB Controller\n");
/*
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
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] Should we move USB input drivers to drivers/input?
On Sun, Jul 30, 2006 at 10:54:38PM -0400, Dmitry Torokhov wrote: > Hi, > > Currently we have 2 main places for input-related devices in *config - > one under "Input device support" and another under "USB support". > While the split made perfect sense when USB was somewhat rare and > did not share the same infrastructure as the other input device it > does not make sence now. User should not go to one place to enable > serial version of Microtouch driver and into another place to enable > USB version and so on. > > Do you think it is time to move everything in one place? Like Pete mentioned, if you can clean up the Kconfig stuff to make it easier for users to find all of the Input devices by merging the stuff into one directory, I have no objection to moving the usb input drivers into the drivers/input/ directory. Note that some other subsystems have already done this with their types of drivers (video being the most recent), so there is precident for what you are proposing. thanks, greg k-h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Should we move USB input drivers to drivers/input?
On Sun, 30 Jul 2006 22:54:38 -0400, Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > Currently we have 2 main places for input-related devices in *config - > one under "Input device support" and another under "USB support". >[...] > Do you think it is time to move everything in one place? I do not approve meaningless cleanups, but if you have an idea how to make Kconfig files simpler and more obvious, that's very laudable. So, more power to you. -- Pete - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] usbmon: don't call dmapeek for non-DMA-able controllers
> > > Are you asking why the method is per-bus? I don't know; the current > > > implementation doesn't use this feature. > > > > At least sl811-hcd could use it, and in general the dma issues need > > to be tied to the underlying usb_bus not a usb_device since that's how > > the operations work. > > What could the HCDs do that would be any better than hcd_buffer_alloc? In that case, kmalloc. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Should we move USB input drivers to drivers/input?
Hi, Currently we have 2 main places for input-related devices in *config - one under "Input device support" and another under "USB support". While the split made perfect sense when USB was somewhat rare and did not share the same infrastructure as the other input device it does not make sence now. User should not go to one place to enable serial version of Microtouch driver and into another place to enable USB version and so on. Do you think it is time to move everything in one place? -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] usbtouchscreen: version 0.4
On Sunday 30 July 2006 15:26, Daniel Ritz wrote: > On Sunday 30 July 2006 20.48, Alan Stern wrote: > > On Sun, 30 Jul 2006, Daniel Ritz wrote: > > > > > there was a report from a user who saw a series of disconnect/connect > > > until X11 was started up. and of course most of the time the device > > > was disconnected when X11 fired up. the workaround he found was doing > > > cat /dev/input/event3 > /dev/null 2>&1 & > > > immediately after the touchscreen was detected. this prevented the device > > > from doing those disconnect/connects...ie. as soon as some process has the > > > event interface open the touchscreen is stable. > > > > I'm curious about this; there have been similar reports about a USB mouse > > that would repeatedly disconnect/connect itself for no apparent reason. > > I don't know if holding the event file open would make any difference, and > > in any case I don't see how it possibly could. > > well, the only difference in the touchscreen case really seems to be when > the URB is submitted... > > > > > Do you have an idea about what's really going on?" > > nope, not really...i'm still waiting for a dmesg with all debugging enabled... > i'll keep you updated... > In this case I'd rather not have this change lumped together with the rest and hold it off for now. -- Dmitry - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] [2.6 patch] fix the USB_GADGET_DUMMY_HCD dependencies
If USB=m, USB_GADGET=y, the option USB_GADGET_DUMMY_HCD mustn't be offered since selecting it results in a compile error. This patch fixes kernel Bugzilla #6534 reported by Toralf Förster. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.18-rc2-mm1-full/drivers/usb/gadget/Kconfig.old2006-07-29 03:58:25.0 +0200 +++ linux-2.6.18-rc2-mm1-full/drivers/usb/gadget/Kconfig2006-07-29 03:59:15.0 +0200 @@ -207,7 +207,7 @@ config USB_GADGET_DUMMY_HCD boolean "Dummy HCD (DEVELOPMENT)" - depends on USB && EXPERIMENTAL + depends on (USB=y || (USB=m && USB_GADGET=m)) && EXPERIMENTAL select USB_GADGET_DUALSPEED help This host controller driver emulates USB, looping all data transfer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Power limit exceeded? / bConfigurationValue = 1 does not work
2006/7/30, Alan Stern <[EMAIL PROTECTED]>: First, thank you very much for your reply! I got WLAN adapter running now! (more or less, but it has been recognized as interface wlan0) :) > Not having an exact duplicate of your hardware, I can't answer that > question. In fact, you're in a better position to answer it than anyone > reading your email. I have a Sharp Zaurus, perhaps you know of it? > > That's where you installed config #1 by hand. The kernel has warned you > that the new configuration may fail because of insufficient power. What does this mean, the new configuration may "fail"? If I try to ping out of my WLAN adapter I get the error "wlan0: tx timeout". Maybe this is some art of failing because of insufficient power? Or does such failing look more like crashing of WLAN adapter? > > New firmware was sent to the device and the device was restarted. Why does kernel sent new firmware to device? Is this necessary? Or just a nice feature? > > usb 1-2: new full speed USB device using pxa27x-ohci and address 3 > > usb 1-2: no configuration chosen from 1 choice > > Now the device is running the new firmware and it has restarted. You need > to install the configuration by hand again. Oh no, I was so near! :) bye - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] usbtouchscreen: version 0.4
On Sunday 30 July 2006 20.48, Alan Stern wrote: > On Sun, 30 Jul 2006, Daniel Ritz wrote: > > > there was a report from a user who saw a series of disconnect/connect > > until X11 was started up. and of course most of the time the device > > was disconnected when X11 fired up. the workaround he found was doing > > cat /dev/input/event3 > /dev/null 2>&1 & > > immediately after the touchscreen was detected. this prevented the device > > from doing those disconnect/connects...ie. as soon as some process has the > > event interface open the touchscreen is stable. > > I'm curious about this; there have been similar reports about a USB mouse > that would repeatedly disconnect/connect itself for no apparent reason. > I don't know if holding the event file open would make any difference, and > in any case I don't see how it possibly could. well, the only difference in the touchscreen case really seems to be when the URB is submitted... > > Do you have an idea about what's really going on?" nope, not really...i'm still waiting for a dmesg with all debugging enabled... i'll keep you updated... > > Alan Stern > rgds -daniel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] usbtouchscreen: version 0.4
On Sun, 30 Jul 2006, Daniel Ritz wrote: > there was a report from a user who saw a series of disconnect/connect > until X11 was started up. and of course most of the time the device > was disconnected when X11 fired up. the workaround he found was doing > cat /dev/input/event3 > /dev/null 2>&1 & > immediately after the touchscreen was detected. this prevented the device > from doing those disconnect/connects...ie. as soon as some process has the > event interface open the touchscreen is stable. I'm curious about this; there have been similar reports about a USB mouse that would repeatedly disconnect/connect itself for no apparent reason. I don't know if holding the event file open would make any difference, and in any case I don't see how it possibly could. Do you have an idea about what's really going on? Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] usbmon: don't call dmapeek for non-DMA-able controllers
On Sun, 30 Jul 2006, David Brownell wrote: > > It's documented in usb.c:usb_buffer_alloc. Obviously the idea is to map a > > frequently-used DMA buffer just once instead of over and over. > > Erm, no ... buffer allocation and buffer mapping are distinct operations, > that one only affects allocation. Right. I should have said: "The idea is to allocate a frequently-used DMA buffer in a DMA-consistent memory area and thereby avoid the need to map it over and over." > Note by the way that recent kernels added a new dma operation: > > dma_mapping_error(dma_addr_t) > > returns boolean ... finally, it's at least possible to report mapping > errors, alhough the invalid DMA address is still arch-specific (and usually > all-ones). However hcd_buffer_alloc doesn't use the arch-specific value. It's hard-coded to all-ones. It's also worth pointing out that there is now a dma_supported() routine. We could start using it. > > Are you asking why the method is per-bus? I don't know; the current > > implementation doesn't use this feature. > > At least sl811-hcd could use it, and in general the dma issues need > to be tied to the underlying usb_bus not a usb_device since that's how > the operations work. What could the HCDs do that would be any better than hcd_buffer_alloc? Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Power limit exceeded? / bConfigurationValue = 1 does not work
On Sun, 30 Jul 2006, niam.tni wrote: > Hi, > > I'm using Kernel 2.6.16 on PDA. > It has an USB-slot/internal hub where I connect my WLAN adapter to. > But kernel doesn't configure this adapter "usb 1-2: no configuration > chosen from 1 choice". > > There is a post from Alan Stern > http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html > who suggests to do a "echo -n 1 > /sys/bus/usb/devices//bConfigurationValue". > > I tried that trick, but I didn't get my WLAN adapter running with > this. Instead I get an interesting kernel message (dmesg) : "usb 1-2: > new config #1 exceeds power limit by 350mA". > > I guess, PDA's usb port doesn't supply more than 150mA. > > Am I right? Do I really need an external powered usb hub to get WLAN > adapter (500mA MaxPower via lsusb -v) working? Not having an exact duplicate of your hardware, I can't answer that question. In fact, you're in a better position to answer it than anyone reading your email. > The rest of dmesg output: > > pxa27x-ohci pxa27x-ohci: PXA27x OHCI > pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 > pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c00 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 3 ports detected > usb 1-2: new full speed USB device using pxa27x-ohci and address 2 > usb 1-2: no configuration chosen from 1 choice That's where the kernel disallowed the only configuration because of the power requirement. > at76_usbdfu: no version magic, tainting kernel. > USB Device Firmware Upgrade (DFU) handler v0.14dev-static loading > at76c503: no version magic, tainting kernel. > Generic Atmel at76c503/at76c505 routines v0.14dev-static > at76c503_rfmd: no version magic, tainting kernel. > Atmel at76c503 (RFMD) Wireless LAN Driver v0.14dev-static loading > usbcore: registered new driver at76c503-rfmd > usb 1-2: new config #1 exceeds power limit by 350mA That's where you installed config #1 by hand. The kernel has warned you that the new configuration may fail because of insufficient power. > usb 1-2: reset full speed USB device using pxa27x-ohci and address 2 > usb 1-2: device firmware changed > usb 1-2: USB disconnect, address 2 > at76c503-rfmd disconnected New firmware was sent to the device and the device was restarted. > usb 1-2: new full speed USB device using pxa27x-ohci and address 3 > usb 1-2: no configuration chosen from 1 choice Now the device is running the new firmware and it has restarted. You need to install the configuration by hand again. Alan Stern - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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 1/4] pl2303: remove 80-columns limit violations in pl2303 driver
On Sun, 30 Jul 2006 11:00:59 -0300, Thiago Galesi <[EMAIL PROTECTED]> wrote: > 2nd try, addressing the comments Looks much better now, but how did this happen: > -static void pl2303_set_termios (struct usb_serial_port *port, struct termios > *old_termios) > +static void pl2303_set_termios (struct usb_serial_port *port, struct termios > + *old_termios) It would more readable to preserve declaration boundaries. -- Pete - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Power limit exceeded? / bConfigurationValue = 1 does not work
2006/7/30, David Brownell <[EMAIL PROTECTED]>: > > An external hub would certainly be a good idea, although there's > also the possibility that the PDA _could_ source 500 mA for a short > while before its battery gets drained. That sound's good and that is what I want to do. Then one AC adapter should be enough to power both, the PDA and external WLAN card connected to it (or something other). No need for an additive AC adapter for some external USB hub. > > What's the entire power drain for the whole PDA? I'd have guessed > a lot less than 500 mA myself, especially with backlight off. uhh... I guess about 250-500 mA. Is there any way to ask kernel for power comsumption instead of measuring yourself and using some algebra? bye - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Power limit exceeded? / bConfigurationValue = 1 does not work
On Sunday 30 July 2006 8:28 am, niam.tni wrote: > > I'm using Kernel 2.6.16 on PDA. > ... > "usb 1-2: new config #1 exceeds power limit by 350mA". > > I guess, PDA's usb port doesn't supply more than 150mA. > > Am I right? Do I really need an external powered usb hub to get WLAN > adapter (500mA MaxPower via lsusb -v) working? An external hub would certainly be a good idea, although there's also the possibility that the PDA _could_ source 500 mA for a short while before its battery gets drained. What's the entire power drain for the whole PDA? I'd have guessed a lot less than 500 mA myself, especially with backlight off. - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] mentor graphics usb controller
On Wednesday 26 July 2006 4:59 am, Manish RATHI wrote: > Hi, > I've to develop driver for mentor graphics usb controller. Which one? There are several, with variants. > It's available on sourceforge.net but no documentation is there. Got URL? I know that Mentor's code for the HDRC is basically not worth looking at; it's a pile of patches that don't work correctly on any kernel version. There's a fork that works reasonably well with various TI parts (DaVinci, OMAP 2430, TUSB 6010) but hasn't yet had any host side updates for the post-2.6.10 kernels. > What's the purpose of generic hcd driver? There is no such thing. There's some reusable HCD "framework" code though, which handles a lot of what the old 2.2-based "usb_operations" interface either requred each HCD to duplicate (root hub stuff etc) or couldn't handle (notably proper shutdown on unplug/unbind). - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] usbmon: don't call dmapeek for non-DMA-able controllers
On Saturday 29 July 2006 1:37 pm, Alan Stern wrote: > On Fri, 28 Jul 2006, Pete Zaitcev wrote: > > > Why do we even have this bus operation method? > > It's documented in usb.c:usb_buffer_alloc. Obviously the idea is to map a > frequently-used DMA buffer just once instead of over and over. Erm, no ... buffer allocation and buffer mapping are distinct operations, that one only affects allocation. Note by the way that recent kernels added a new dma operation: dma_mapping_error(dma_addr_t) returns boolean ... finally, it's at least possible to report mapping errors, alhough the invalid DMA address is still arch-specific (and usually all-ones). > Are you asking why the method is per-bus? I don't know; the current > implementation doesn't use this feature. At least sl811-hcd could use it, and in general the dma issues need to be tied to the underlying usb_bus not a usb_device since that's how the operations work. - Dave - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Power limit exceeded? / bConfigurationValue = 1 does not work
Hi, I'm using Kernel 2.6.16 on PDA. It has an USB-slot/internal hub where I connect my WLAN adapter to. But kernel doesn't configure this adapter "usb 1-2: no configuration chosen from 1 choice". There is a post from Alan Stern http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg43480.html who suggests to do a "echo -n 1 /sys/bus/usb/devices//bConfigurationValue". I tried that trick, but I didn't get my WLAN adapter running with this. Instead I get an interesting kernel message (dmesg) : "usb 1-2: new config #1 exceeds power limit by 350mA". I guess, PDA's usb port doesn't supply more than 150mA. Am I right? Do I really need an external powered usb hub to get WLAN adapter (500mA MaxPower via lsusb -v) working? The rest of dmesg output: pxa27x-ohci pxa27x-ohci: PXA27x OHCI pxa27x-ohci pxa27x-ohci: new USB bus registered, assigned bus number 1 pxa27x-ohci pxa27x-ohci: irq 3, io mem 0x4c00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected usb 1-2: new full speed USB device using pxa27x-ohci and address 2 usb 1-2: no configuration chosen from 1 choice at76_usbdfu: no version magic, tainting kernel. USB Device Firmware Upgrade (DFU) handler v0.14dev-static loading at76c503: no version magic, tainting kernel. Generic Atmel at76c503/at76c505 routines v0.14dev-static at76c503_rfmd: no version magic, tainting kernel. Atmel at76c503 (RFMD) Wireless LAN Driver v0.14dev-static loading usbcore: registered new driver at76c503-rfmd usb 1-2: new config #1 exceeds power limit by 350mA usb 1-2: reset full speed USB device using pxa27x-ohci and address 2 usb 1-2: device firmware changed usb 1-2: USB disconnect, address 2 at76c503-rfmd disconnected usb 1-2: new full speed USB device using pxa27x-ohci and address 3 usb 1-2: no configuration chosen from 1 choice - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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 1/4] pl2303: remove 80-columns limit violations in pl2303 driver
2nd try, addressing the comments
Fixes several lines that overrun 80 columns in Prolific pl2303 driver
Signed-off-by: Thiago Galesi <[EMAIL PROTECTED]>
Index: linux-2.6.17/drivers/usb/serial/pl2303.c
===
--- linux-2.6.17.orig/drivers/usb/serial/pl2303.c
+++ linux-2.6.17/drivers/usb/serial/pl2303.c
@@ -257,7 +257,8 @@ static int set_control_lines (struct usb
return retval;
}
-static int pl2303_write (struct usb_serial_port *port, const unsigned char *buf, int count)
+static int pl2303_write (struct usb_serial_port *port, const unsigned char *buf,
+ int count)
{
struct pl2303_private *priv = usb_get_serial_port_data(port);
unsigned long flags;
@@ -303,13 +304,15 @@ static void pl2303_send(struct usb_seria
spin_unlock_irqrestore(&priv->lock, flags);
- usb_serial_debug_data(debug, &port->dev, __FUNCTION__, count, port->write_urb->transfer_buffer);
+ usb_serial_debug_data(debug, &port->dev, __FUNCTION__, count,
+ port->write_urb->transfer_buffer);
port->write_urb->transfer_buffer_length = count;
port->write_urb->dev = port->serial->dev;
result = usb_submit_urb (port->write_urb, GFP_ATOMIC);
if (result) {
- dev_err(&port->dev, "%s - failed submitting write urb, error %d\n", __FUNCTION__, result);
+ dev_err(&port->dev, "%s - failed submitting write urb,"
+ " error %d\n", __FUNCTION__, result);
priv->write_urb_in_use = 0;
// TODO: reschedule pl2303_send
}
@@ -349,7 +352,8 @@ static int pl2303_chars_in_buffer(struct
return chars;
}
-static void pl2303_set_termios (struct usb_serial_port *port, struct termios *old_termios)
+static void pl2303_set_termios (struct usb_serial_port *port, struct termios
+*old_termios)
{
struct usb_serial *serial = port->serial;
struct pl2303_private *priv = usb_get_serial_port_data(port);
@@ -370,7 +374,8 @@ static void pl2303_set_termios (struct u
spin_lock_irqsave(&priv->lock, flags);
if (!priv->termios_initialized) {
*(port->tty->termios) = tty_std_termios;
- port->tty->termios->c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL;
+ port->tty->termios->c_cflag = B9600 | CS8 | CREAD
+ | HUPCL | CLOCAL;
priv->termios_initialized = 1;
}
spin_unlock_irqrestore(&priv->lock, flags);
@@ -379,7 +384,8 @@ static void pl2303_set_termios (struct u
/* check that they really want us to change something */
if (old_termios) {
if ((cflag == old_termios->c_cflag) &&
- (RELEVANT_IFLAG(port->tty->termios->c_iflag) == RELEVANT_IFLAG(old_termios->c_iflag))) {
+ (RELEVANT_IFLAG(port->tty->termios->c_iflag) ==
+ RELEVANT_IFLAG(old_termios->c_iflag))) {
dbg("%s - nothing to change...", __FUNCTION__);
return;
}
@@ -428,7 +434,8 @@ static void pl2303_set_termios (struct u
case B230400: baud = 230400; break;
case B460800: baud = 460800; break;
default:
- dev_err(&port->dev, "pl2303 driver does not support the baudrate requested (fix it)\n");
+ dev_err(&port->dev, "pl2303 driver does not support"
+ " the baudrate requested (fix it)\n");
break;
}
dbg("%s - baud = %d", __FUNCTION__, baud);
@@ -576,7 +583,8 @@ static int pl2303_open (struct usb_seria
port->read_urb->dev = serial->dev;
result = usb_submit_urb (port->read_urb, GFP_KERNEL);
if (result) {
- dev_err(&port->dev, "%s - failed submitting read urb, error %d\n", __FUNCTION__, result);
+ dev_err(&port->dev, "%s - failed submitting read urb,"
+ " error %d\n", __FUNCTION__, result);
pl2303_close (port, NULL);
return -EPROTO;
}
@@ -585,7 +593,8 @@ static int pl2303_open (struct usb_seria
port->interrupt_in_urb->dev = serial->dev;
result = usb_submit_urb (port->interrupt_in_urb, GFP_KERNEL);
if (result) {
- dev_err(&port->dev, "%s - failed submitting interrupt urb, error %d\n", __FUNCTION__, result);
+ dev_err(&port->dev, "%s - failed submitting interrupt urb,"
+ " error %d\n", __FUNCTION__, result);
pl2303_close (port, NULL);
return -EPROTO;
}
@@ -748,7 +757,8 @@ static int wait_modem_info(struct usb_se
return 0;
}
-static int pl2303_ioctl (struct usb_serial_port *port, struct file *file, unsigned int cmd, unsigned long arg)
+static int pl2303_ioctl (struct usb_serial_port *port, struct file *file,
+ unsigned int cmd, unsigned long arg)
{
dbg("%s (%d) cmd = 0x%04x", __FUNCTION__, port->number, cmd);
@@ -852,20 +862,25 @@ static void pl2303_read_int_callback (st
case -ENOENT:
case -ESHUTDOWN:
/* this urb is terminated, clean up */
- dbg("%s - urb shutting down with status: %d", __FUNCTION__, urb->status);
+ dbg("%s - urb shutting down with status: %d", __FUNCTION__,
+urb->status);
return;
default:
- dbg("%s - nonzero urb status received: %d", __FUNCTION__, urb->status);
+ dbg("%s - nonzero urb status received: %d", __FUNCTION__,
+urb->status);
goto exit;
}
- usb_serial_debug_data(debug, &port->dev, __FUNCTION__, urb->actual_length, urb-
Re: [linux-usb-devel] [PATCH] usbtouchscreen: version 0.4
On Sunday 30 July 2006 03.34, Dmitry Torokhov wrote: > Hi Daniel, > > On Saturday 29 July 2006 18:38, Daniel Ritz wrote: > > > - always do usb_submit_urb(dev->irq) in probe() to work around issues > > with some eGalaxe contollers > > Could you elaborate on the issues you are seeing? Submitting URB in > ->open() basically just delays it, that's all. > there was a report from a user who saw a series of disconnect/connect until X11 was started up. and of course most of the time the device was disconnected when X11 fired up. the workaround he found was doing cat /dev/input/event3 > /dev/null 2>&1 & immediately after the touchscreen was detected. this prevented the device from doing those disconnect/connects...ie. as soon as some process has the event interface open the touchscreen is stable. > > +out_unregister: > > + input_unregister_device(usbtouch->input); > > + > > out_free_buffers: > > usbtouch_free_buffers(udev, usbtouch); > > out_free: > > input_free_device(input_dev); > > kfree(usbtouch); > > > > It is not allowed to simply call input_free_device() after calling > input_unregister_device(). Either take an extra reference with > input_get_device() or just add "input_dev = NULL;" after calling > input_unregister_devive() - input_free_device() handles NULLs just > fine. oops, yes. will set it to NULL. thanks, rgds -daniel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ 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] Bug with USB proc_bulk in 2.4 kernel
On Thu, 27 Jul 2006 15:21:37 -0700, Benjamin Cherian <[EMAIL PROTECTED]> wrote:
> On Monday 24 July 2006 23:07, Pete Zaitcev wrote:
> > Anyway, please test the attached patch. Does it do what you want?
>
> Sorry to say that it doesnt. When calling usb_get_string_simple in libusb,
> the program segfaults with the patched kernel. I believe that
> usb_get_string_simple eventually calls usbdev_ioctl.
Indeed, I should've tested better, sorry. How about now?
-- Pete
diff -urp -X dontdiff linux-2.4.32/drivers/usb/devices.c
linux-2.4.32-wk/drivers/usb/devices.c
--- linux-2.4.32/drivers/usb/devices.c 2004-11-17 03:54:21.0 -0800
+++ linux-2.4.32-wk/drivers/usb/devices.c 2006-07-24 22:30:54.0
-0700
@@ -392,7 +392,7 @@ static char *usb_dump_desc(char *start,
* Grab device's exclusive_access mutex to prevent its driver or
* devio from using this device while we are accessing it.
*/
- down (&dev->exclusive_access);
+ usb_excl_lock(dev, 3, 0);
start = usb_dump_device_descriptor(start, end, &dev->descriptor);
@@ -411,7 +411,7 @@ static char *usb_dump_desc(char *start,
}
out:
- up (&dev->exclusive_access);
+ usb_excl_unlock(dev, 3);
return start;
}
diff -urp -X dontdiff linux-2.4.32/drivers/usb/devio.c
linux-2.4.32-wk/drivers/usb/devio.c
--- linux-2.4.32/drivers/usb/devio.c2006-04-13 19:02:30.0 -0700
+++ linux-2.4.32-wk/drivers/usb/devio.c 2006-07-30 00:27:13.0 -0700
@@ -623,7 +623,12 @@ static int proc_bulk(struct dev_state *p
free_page((unsigned long)tbuf);
return -EINVAL;
}
+ if (usb_excl_lock(dev, 1, 1) != 0) {
+ free_page((unsigned long)tbuf);
+ return -ERESTARTSYS;
+ }
i = usb_bulk_msg(dev, pipe, tbuf, len1, &len2, tmo);
+ usb_excl_unlock(dev, 1);
if (!i && len2) {
if (copy_to_user(bulk.data, tbuf, len2)) {
free_page((unsigned long)tbuf);
@@ -637,7 +642,12 @@ static int proc_bulk(struct dev_state *p
return -EFAULT;
}
}
+ if (usb_excl_lock(dev, 2, 1) != 0) {
+ free_page((unsigned long)tbuf);
+ return -ERESTARTSYS;
+ }
i = usb_bulk_msg(dev, pipe, tbuf, len1, &len2, tmo);
+ usb_excl_unlock(dev, 2);
}
free_page((unsigned long)tbuf);
if (i < 0) {
@@ -1160,12 +1170,6 @@ static int usbdev_ioctl_exclusive(struct
inode->i_mtime = CURRENT_TIME;
break;
- case USBDEVFS_BULK:
- ret = proc_bulk(ps, (void *)arg);
- if (ret >= 0)
- inode->i_mtime = CURRENT_TIME;
- break;
-
case USBDEVFS_RESETEP:
ret = proc_resetep(ps, (void *)arg);
if (ret >= 0)
@@ -1259,8 +1263,13 @@ static int usbdev_ioctl(struct inode *in
ret = proc_disconnectsignal(ps, (void *)arg);
break;
- case USBDEVFS_CONTROL:
case USBDEVFS_BULK:
+ ret = proc_bulk(ps, (void *)arg);
+ if (ret >= 0)
+ inode->i_mtime = CURRENT_TIME;
+ break;
+
+ case USBDEVFS_CONTROL:
case USBDEVFS_RESETEP:
case USBDEVFS_RESET:
case USBDEVFS_CLEAR_HALT:
@@ -1272,9 +1281,9 @@ static int usbdev_ioctl(struct inode *in
case USBDEVFS_RELEASEINTERFACE:
case USBDEVFS_IOCTL:
ret = -ERESTARTSYS;
- if (down_interruptible(&ps->dev->exclusive_access) == 0) {
+ if (usb_excl_lock(ps->dev, 3, 1) == 0) {
ret = usbdev_ioctl_exclusive(ps, inode, cmd, arg);
- up(&ps->dev->exclusive_access);
+ usb_excl_unlock(ps->dev, 3);
}
break;
diff -urp -X dontdiff linux-2.4.32/drivers/usb/storage/transport.c
linux-2.4.32-wk/drivers/usb/storage/transport.c
--- linux-2.4.32/drivers/usb/storage/transport.c2005-04-03
18:42:19.0 -0700
+++ linux-2.4.32-wk/drivers/usb/storage/transport.c 2006-07-24
22:58:58.0 -0700
@@ -628,16 +628,16 @@ void usb_stor_invoke_transport(Scsi_Cmnd
int result;
/*
-* Grab device's exclusive_access mutex to prevent libusb/usbfs from
+* Grab device's exclusive access lock to prevent libusb/usbfs from
* sending out a command in the middle of ours (if libusb sends a
* get_descriptor or something on pipe 0 after our CBW and before
* our CSW, and then we get a stall, we have trouble).
*/
- down(&(us->pusb_dev->exclusive_access));
+ usb_excl_lock(us->pusb_dev, 3, 0);
/* send the c
