usbip etoken
Hi, list. I have a problem with usbip and etoken. Matt Mooney didn't reply me. Greg Kroah-Hartman seems to be too busy. So, i doesn't know who can help me with my problem. May be anybody know what the cause of the problem? I have a usb etoken that doesn't want to work with usbip from 3.2.21 kernel. It consist of two devices (2-1.2:1.0 and 2-1.2:1.1): legohost:~# grep . /sys/bus/usb/devices/2-1.2/* /sys/bus/usb/devices/2-1.2/authorized:1 /sys/bus/usb/devices/2-1.2/avoid_reset_quirk:0 /sys/bus/usb/devices/2-1.2/bcdDevice:1000 /sys/bus/usb/devices/2-1.2/bConfigurationValue:1 /sys/bus/usb/devices/2-1.2/bDeviceClass:00 /sys/bus/usb/devices/2-1.2/bDeviceProtocol:00 /sys/bus/usb/devices/2-1.2/bDeviceSubClass:00 /sys/bus/usb/devices/2-1.2/bmAttributes:80 /sys/bus/usb/devices/2-1.2/bMaxPacketSize0:64 /sys/bus/usb/devices/2-1.2/bMaxPower:100mA /sys/bus/usb/devices/2-1.2/bNumConfigurations:1 /sys/bus/usb/devices/2-1.2/bNumInterfaces: 2 /sys/bus/usb/devices/2-1.2/busnum:2 Binary file /sys/bus/usb/devices/2-1.2/descriptors matches /sys/bus/usb/devices/2-1.2/dev:189:134 /sys/bus/usb/devices/2-1.2/devnum:7 /sys/bus/usb/devices/2-1.2/devpath:1.2 /sys/bus/usb/devices/2-1.2/idProduct:013c /sys/bus/usb/devices/2-1.2/idVendor:2022 /sys/bus/usb/devices/2-1.2/manufacturer:Infocrypt /sys/bus/usb/devices/2-1.2/maxchild:0 /sys/bus/usb/devices/2-1.2/product:HWDSSL DEVICE /sys/bus/usb/devices/2-1.2/quirks:0x0 grep: /sys/bus/usb/devices/2-1.2/remove: Permission denied /sys/bus/usb/devices/2-1.2/serial: /sys/bus/usb/devices/2-1.2/speed:12 /sys/bus/usb/devices/2-1.2/uevent:MAJOR=189 /sys/bus/usb/devices/2-1.2/uevent:MINOR=134 /sys/bus/usb/devices/2-1.2/uevent:DEVNAME=bus/usb/002/007 /sys/bus/usb/devices/2-1.2/uevent:DEVTYPE=usb_device /sys/bus/usb/devices/2-1.2/uevent:DRIVER=usb /sys/bus/usb/devices/2-1.2/uevent:DEVICE=/proc/bus/usb/002/007 /sys/bus/usb/devices/2-1.2/uevent:PRODUCT=2022/13c/1000 /sys/bus/usb/devices/2-1.2/uevent:TYPE=0/0/0 /sys/bus/usb/devices/2-1.2/uevent:BUSNUM=002 /sys/bus/usb/devices/2-1.2/uevent:DEVNUM=007 /sys/bus/usb/devices/2-1.2/urbnum:315 /sys/bus/usb/devices/2-1.2/version: 2.00 legohost:~# grep . /sys/bus/usb/devices/2-1.2/2-1.2\:1.0/* /sys/bus/usb/devices/2-1.2/2-1.2:1.0/bAlternateSetting: 0 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/bInterfaceClass:08 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/bInterfaceNumber:00 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/bInterfaceProtocol:50 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/bInterfaceSubClass:06 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/bNumEndpoints:02 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/modalias:usb:v2022p013Cd1000dc00dsc00dp00ic08isc06ip50 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/supports_autosuspend:1 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:DEVTYPE=usb_interface /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:DRIVER=usb-storage /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:DEVICE=/proc/bus/usb/002/007 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:PRODUCT=2022/13c/1000 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:TYPE=0/0/0 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:INTERFACE=8/6/80 /sys/bus/usb/devices/2-1.2/2-1.2:1.0/uevent:MODALIAS=usb:v2022p013Cd1000dc00dsc00dp00ic08isc06ip50 legohost:~# grep . /sys/bus/usb/devices/2-1.2/2-1.2\:1.1/* /sys/bus/usb/devices/2-1.2/2-1.2:1.1/bAlternateSetting: 0 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/bInterfaceClass:0b /sys/bus/usb/devices/2-1.2/2-1.2:1.1/bInterfaceNumber:01 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/bInterfaceProtocol:00 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/bInterfaceSubClass:00 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/bNumEndpoints:02 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/modalias:usb:v2022p013Cd1000dc00dsc00dp00ic0Bisc00ip00 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/supports_autosuspend:1 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/uevent:DEVTYPE=usb_interface /sys/bus/usb/devices/2-1.2/2-1.2:1.1/uevent:DEVICE=/proc/bus/usb/002/007 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/uevent:PRODUCT=2022/13c/1000 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/uevent:TYPE=0/0/0 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/uevent:INTERFACE=11/0/0 /sys/bus/usb/devices/2-1.2/2-1.2:1.1/uevent:MODALIAS=usb:v2022p013Cd1000dc00dsc00dp00ic0Bisc00ip00 When i attach it on a client, i see the next kernel messages: vhci_hcd vhci_hcd: rhport(0) sockfd(3) devid(131079) speed(2) vhci_hcd: changed 1 usb 1-1: new full-speed USB device number 14 using vhci_hcd usb 1-1: SetAddress Request (14) to port 0 scsi5 : usb-storage 1-1:1.0 scsi 5:0:0:0: Direct-Access AMICON VPN-KEY STORAGE 0.01 PQ: 0 ANSI: 0 sd 5:0:0:0: Attached scsi generic sg2 type 0 sd 5:0:0:0: [sdb] 924 512-byte logical blocks: (473 kB/462 KiB) sd 5:0:0:0: [sdb] Write Protect is on sd 5:0:0:0: [sdb] Mode Sense: 1b 00 80 00 sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write through sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write through sdb: sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote: On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote: No, now that I think about it an attribute for the drivers is necessary. Like drivers have supports_autosuspend they also should have supports_power_off. In addition it is necessary for ports to have an attribute in sysfs which allows user space to block power off. And it is a bit complicated. Power may be cut, if a) a port is internal and unpluggable, or b) a port is internal and it's interfaces' drivers set supports_power_off, unless: 1) remote wakeup is requested 2) user space has blocked it via the new sysfs attribute 3) USB_QUIRK_RESET_MORPHS is set Yes, that sounds like a good kernel policy. Thanks for pointing out the USB_QUIRK_RESET_MORPHS; I didn't know we had a specific quirk for devices that will morph into a different class of USB devices on a reset. It is supposed to be set (from user space) for 3G cards that feature a mini-SD card reader which the storage driver would reset during error handling. What if the user really wants the bluetooth device off? I have only used the bluetooth on my laptop once in the year I've had it. Whenever I boot my Ubuntu box, I go up to the bluetooth icon in the tray and turn it off. It would be nice at that point to have the bluetooth driver unloaded and the port turned completely off. Unloading the driver is a user space issue. But you are right there is a missing case c) a port is internal and its device's interfaces are all not bound to a driver, if user space has requested it, unless usbfs has claimed an interface. I think we're going to need to help userspace serialize port power management somehow. Why not create a new sysfs file with ioctls similar to the usbfs claim port interface to allow only one userspace process to control the port power at a time? Because you'd go down a road which is a dead end. We want auto-power-on in an ideal case. It has to be triggered by the driver. The driver can be accessed from user space and access to it cannot be serialized by such methods. You'd implement a scheme that would very soon become counter-productive. This can be best seen in the case of the ubiquitous internal webcams. They'd work and save maximum power. But this leaves me with a question. Has anybody ever measured the additional power savings compared to a suspended state for devices? Or are you doing this only as a prelude to become able to send host controllers to D3cold? Furthermore if you go with this scheme you can eventually extend it to external ports. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On 2012年07月19日 14:37, Oliver Neukum wrote: On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote: On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote: No, now that I think about it an attribute for the drivers is necessary. Like drivers have supports_autosuspend they also should have supports_power_off. In addition it is necessary for ports to have an attribute in sysfs which allows user space to block power off. And it is a bit complicated. Power may be cut, if a) a port is internal and unpluggable, or b) a port is internal and it's interfaces' drivers set supports_power_off, unless: 1) remote wakeup is requested 2) user space has blocked it via the new sysfs attribute 3) USB_QUIRK_RESET_MORPHS is set Yes, that sounds like a good kernel policy. Thanks for pointing out the USB_QUIRK_RESET_MORPHS; I didn't know we had a specific quirk for devices that will morph into a different class of USB devices on a reset. It is supposed to be set (from user space) for 3G cards that feature a mini-SD card reader which the storage driver would reset during error handling. What if the user really wants the bluetooth device off? I have only used the bluetooth on my laptop once in the year I've had it. Whenever I boot my Ubuntu box, I go up to the bluetooth icon in the tray and turn it off. It would be nice at that point to have the bluetooth driver unloaded and the port turned completely off. Unloading the driver is a user space issue. But you are right there is a missing case c) a port is internal and its device's interfaces are all not bound to a driver, if user space has requested it, unless usbfs has claimed an interface. I think we're going to need to help userspace serialize port power management somehow. Why not create a new sysfs file with ioctls similar to the usbfs claim port interface to allow only one userspace process to control the port power at a time? Because you'd go down a road which is a dead end. We want auto-power-on in an ideal case. It has to be triggered by the driver. The driver can be accessed from user space and access to it cannot be serialized by such methods. You'd implement a scheme that would very soon become counter-productive. This can be best seen in the case of the ubiquitous internal webcams. They'd work and save maximum power. But this leaves me with a question. Has anybody ever measured the additional power savings compared to a suspended state for devices? Or are you doing this only as a prelude to become able to send host controllers to D3cold? hi Oliver: I have done a test on a usb3.0 ORICO SSD which may cost 3w normally. Traditional suspend can save 1w. Power off can save additional 2w. I also test on some other usb2.0 flashs. The additional power saving is very limit. Because the precision of power meter is not good, I can not get exact power saving. Furthermore if you go with this scheme you can eventually extend it to external ports. Regards Oliver -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] usb: musb: host: don't program dma for zero byte tx
This is to reduce the overhead of dma programming for zero byte
transmit as same can be done using pio mode.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_host.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index e090c79..084d42b 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -693,6 +693,8 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
void __iomem*epio = hw_ep-regs;
struct musb_qh *qh = musb_ep_get_qh(hw_ep, !is_out);
u16 packet_sz = qh-maxpacket;
+ u8 use_dma = 1;
+ u16 csr;
dev_dbg(musb-controller, %s hw%d urb %p spd%d dev%d ep%d%s
h_addr%02x h_port%02x bytes %d\n,
@@ -704,9 +706,17 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
musb_ep_select(mbase, epnum);
+ if (is_out !len) {
+ use_dma = 0;
+ csr = musb_readw(epio, MUSB_TXCSR);
+ csr = ~MUSB_TXCSR_DMAENAB;
+ musb_writew(epio, MUSB_TXCSR, csr);
+ hw_ep-tx_channel = NULL;
+ }
+
/* candidate for DMA? */
dma_controller = musb-dma_controller;
- if (is_dma_capable() epnum dma_controller) {
+ if (use_dma is_dma_capable() epnum dma_controller) {
dma_channel = is_out ? hw_ep-tx_channel : hw_ep-rx_channel;
if (!dma_channel) {
dma_channel = dma_controller-channel_alloc(
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] usb: musb: gadget: fix kernel crash after rmmod
musb-gadget_driver is not getting reset to NULL after the gadget driver is removed. Fixing the same by resetting the musb-gadget_driver to NULL when gadget driver is removed. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- This set of four patches are musb bugfix and created against linus's tree. drivers/usb/musb/musb_gadget.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 95918da..b330ea6 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -2067,6 +2067,7 @@ static int musb_gadget_stop(struct usb_gadget *g, if (!is_otg_enabled(musb)) musb_stop(musb); + musb-gadget_driver = NULL; pm_runtime_put(musb-controller); return 0; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: ci13xxx-imx: remove global struct
On Thu, Jul 19, 2012 at 01:31:07AM +0200, Michael Grzeschik wrote: This patch removes the limitation of having only one instance of the ci13xxx-imx. Each instance of the ci13xxx-imx could have different flags to be configured with, so we also move this settings to the devicetree properties. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- .../devicetree/bindings/usb/ci13xxx-imx.txt|6 + New bindings should always have devicetree-discuss in CC. drivers/usb/chipidea/ci13xxx_imx.c | 25 +++- drivers/usb/chipidea/core.c| 11 + include/linux/usb/chipidea.h |3 +++ 4 files changed, 34 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt index 2c29041..5485eb9 100644 --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt @@ -8,6 +8,9 @@ Required properties: Optional properties: - fsl,usbphy: phandler of usb phy that connects to the only one port - vbus-supply: regulator for vbus +- require-transceiver: enable the flag in the driver +- pullup-on-vbus: enable the flag in the driver +- disable-streaming: enable the flag in the driver NACK to the bindings. You are mapping platform data 1:1 which is nearly always wrong. Having a quick look in the current devicetree bindings for USB shows that there is a transceiver property. So, the the (non-)presence of that property should make require-transceiver superfluous? Also, is disable-streaming a description of the hardware? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On 2012年07月19日 14:37, Oliver Neukum wrote: On Wednesday 18 July 2012 15:07:14 Sarah Sharp wrote: On Wed, Jul 18, 2012 at 09:03:59PM +0200, Oliver Neukum wrote: No, now that I think about it an attribute for the drivers is necessary. Like drivers have supports_autosuspend they also should have supports_power_off. In addition it is necessary for ports to have an attribute in sysfs which allows user space to block power off. And it is a bit complicated. Power may be cut, if a) a port is internal and unpluggable, or b) a port is internal and it's interfaces' drivers set supports_power_off, unless: 1) remote wakeup is requested 2) user space has blocked it via the new sysfs attribute 3) USB_QUIRK_RESET_MORPHS is set Yes, that sounds like a good kernel policy. Thanks for pointing out the USB_QUIRK_RESET_MORPHS; I didn't know we had a specific quirk for devices that will morph into a different class of USB devices on a reset. It is supposed to be set (from user space) for 3G cards that feature a mini-SD card reader which the storage driver would reset during error handling. What if the user really wants the bluetooth device off? I have only used the bluetooth on my laptop once in the year I've had it. Whenever I boot my Ubuntu box, I go up to the bluetooth icon in the tray and turn it off. It would be nice at that point to have the bluetooth driver unloaded and the port turned completely off. Unloading the driver is a user space issue. But you are right there is a missing case hi all: I have a question About device which needs a firmware when connected. If the port powered off when it was suspend, the port would power on when system try to access the device. What happen if try to resume the device, guess it will fail. usb core would disconnect the device and renumerate the device. The driver loaded again with firmware and the device still could work, is Right? I have no a such device to do test. Just from guess. The point is whether resuming the device without loading firmware will fail. -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/11] usb: otg: nop: add support for multiple tranceiver
Hi,
On Thu, Jul 19, 2012 at 11:11 AM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -704,7 +704,7 @@ static void __init omap3_evm_init(void)
omap_sdrc_init(mt46h32m32lf6_sdrc_params, NULL);
/* OMAP3EVM uses ISP1504 phy and so register nop transceiver */
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(0);
if (get_omap3_evm_rev() = OMAP3EVM_BOARD_GEN_2) {
/* enable EHCI VBUS using GPIO22 */
diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..eb6220f 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -364,7 +364,7 @@ static int am35x_musb_init(struct musb *musb)
if (!rev)
return -ENODEV;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..03d081c 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -415,7 +415,7 @@ static int bfin_musb_init(struct musb *musb)
}
gpio_direction_output(musb-config-gpio_vrsel, 0);
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv)) {
gpio_free(musb-config-gpio_vrsel);
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..3ce4a92 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -425,7 +425,7 @@ static int da8xx_musb_init(struct musb *musb)
if (!rev)
goto fail;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto fail;
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..d5156b3 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -385,7 +385,7 @@ static int davinci_musb_init(struct musb *musb)
void __iomem*tibase = musb-ctrl_base;
u32 revision;
- usb_nop_xceiv_register();
+ usb_nop_xceiv_register(musb-id);
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
goto unregister;
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
fail:
usb_put_phy(musb-xceiv);
unregister:
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
}
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
usb_put_phy(musb-xceiv);
- usb_nop_xceiv_unregister();
+ usb_nop_xceiv_unregister(musb-xceiv);
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index a2c8a06..9fcacff 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -420,8 +420,8 @@ static int dsps_musb_init(struct musb *musb)
Re: [PATCH v3 07/11] usb: otg: nop: add dt support
Hi,
On Thu, Jul 19, 2012 at 11:11 AM, Ajay Kumar Gupta ajay.gu...@ti.com wrote:
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 12
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 2e5e889..102e7d8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -152,12 +153,23 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#else
+#define nop_xceiv_id_table NULL
+#endif
The *#else* part is not needed as your *of_match_ptr* will take care of it.
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 04/11] usb: otg: nop: add support for multiple tranceiver
Hi,
Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
drivers/usb/musb/am35x.c |4 ++--
drivers/usb/musb/blackfin.c |4 ++--
drivers/usb/musb/da8xx.c |4 ++--
drivers/usb/musb/davinci.c |6 +++---
drivers/usb/musb/musb_dsps.c | 10 +-
drivers/usb/musb/tusb6010.c |6 +++---
drivers/usb/otg/nop-usb-xceiv.c | 20
include/linux/usb/otg.h |9 +
9 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
omap2/board-omap3evm.c
index ef230a0..a3393bc 100644
[...]
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 4636d39..36cc791 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -95,6 +95,7 @@ struct usb_phy {
struct device *dev;
const char *label;
unsigned int flags;
+ u8 id;
Do we really need to have *id* in phy??
I will update the patches dropping this.
enum usb_phy_type type;
enum usb_otg_state state;
@@ -137,14 +138,14 @@ extern void usb_remove_phy(struct usb_phy *);
#if defined(CONFIG_NOP_USB_XCEIV) ||
(defined(CONFIG_NOP_USB_XCEIV_MODULE) defined(MODULE))
/* sometimes transceivers are accessed only through e.g. ULPI */
-extern void usb_nop_xceiv_register(void);
-extern void usb_nop_xceiv_unregister(void);
+extern void usb_nop_xceiv_register(int id);
+extern void usb_nop_xceiv_unregister(struct usb_phy *);
IMHO, these declarations shouldn't be in usb/otg.h. It can be in a
header file specific to usb_nop?
They were in otg.h and just definition getting changed so I think they
need to be in otg.h only as a logical change of this patch.
Location can be changed as a separate patch later.
Thanks,
Ajay
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 12, 2012 at 12:11 PM, Munegowda, Keshava keshava_mgo...@ti.com wrote: On Wed, Jul 11, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote: Munegowda, Keshava keshava_mgo...@ti.com writes: On Wed, Jul 11, 2012 at 3:59 PM, Samuel Ortiz sa...@linux.intel.com wrote: Hi Keshava, Kevin, On Fri, Jul 06, 2012 at 05:29:00PM +0530, Munegowda, Keshava wrote: Samuel I have sent that patch to disable the ehci in omap2plus_defconfig; after merging that please merge this patch too. This will fix the crashes in during boot with NFS in beagleXM I'm going to apply and push this patch for 3.5, and the defconfig patch can be pushed through Tony's tree. Kevin, could you please ACK it ? Cheers, Samuel. Thanks Samuel Kevin, need your ack for this. You never answered earlier questions from myself or Russ Dill about the more targetted patches from Russ: ARM: OMAP: USB: Fixup ehci_hcd_omap_probe error path Fix OMAP EHCI suspend/resume failure (i693) '354ab856' causes Also, your current $SUBJECT patch is large and not well described. e.g. what is not correct and why. Why does it fix the problems mentioned? The original changelog mentions the core retention issue but this patch does nothing to address that. If you want an Ack from me, especially because I'm not an expert in this IP, you'll have to describe things in a way that I can understand. IMO, at this point of the dev cycle (trying to stabilize v3.5), the full cleanup/fix of this feature will need to be done for v3.6. For v3.5, I think the two patches from Russ Dill should be merged. They are targetted fixes and very well described. Kevin Hi Kevin The usb2 host of omap3/4/5 silicons has the following ips 1. UHH ( /drivers/mfd/omap-usb-host.c ) -- platform driver 2. TLL( /drivers/mfd/omap-usb-host.c ) 3. ehci( /drivers/usb/host/ehci-omap.c) - platform driver 4. ohci ( /drivers/usb/host/ohci-omap3.c ) - platform drivers The 3 platform drivers exists to make the ehci/ohci functional. The UHH-TLL or usb host core driver is the parent platform driver of ehci and ohci. This parent driver doe the clock enable/disable which common for both ehci and ohci. takes care of common port setting and clocks during suspend and resume and ensures that there is no overwrites by ehci and ohci platform drivers. The commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) was handling the clocks in the ehci driver it self, instead it should be handled by usb host core driver as per above explanation. so, the UHH-TLL Driver should handle the changes done by 354ab8567ae3107a8cbe7228c3181990ba598aac. hence this patch removes the changed done by the commit id 354ab8567ae3107a8cbe7228c3181990ba598aac suppose if this patch is not included, then it will cause the following two problems 1. crash during the system boot - observed in beagle xm , with NFS file system the Ethernet is through ehci driver , since the ehci ports clocks are not handled properly by this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac, it leads to crash 2. crash during suspend/resume - observed in beagle xm with ram fs if the ehci is driver is included and if it tries to suspend it leads to crash regards keshava hi Felipe I request you to ack this patch; this will enable the boot issue in beagle xm with NFS. I will rework the patch with commit id 354ab8567ae3107a8cbe7228c3181990ba598aac by Anand gadiyar after the TLL driver gets merged. regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Thursday 19 July 2012 15:42:37 Lan Tianyu wrote: On 2012年07月19日 14:37, Oliver Neukum wrote: But this leaves me with a question. Has anybody ever measured the additional power savings compared to a suspended state for devices? Or are you doing this only as a prelude to become able to send host controllers to D3cold? hi Oliver: I have done a test on a usb3.0 ORICO SSD which may cost 3w normally. Traditional suspend can save 1w. Power off can save additional 2w. I also test Well, then the device violates the standard for power consumption. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams
Hi, Here's the fourth version of the Logitech UVC devices RESET_RESUME quirk patches. Compared to v3, the usb_detect_interface_quirks() has been moved to usb_enumerate_device(). Laurent Pinchart (2): usb: Add quirk detection based on interface information usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams drivers/usb/core/driver.c | 38 +++- drivers/usb/core/hub.c| 10 ++- drivers/usb/core/quirks.c | 151 ++--- drivers/usb/core/usb.h|4 + 4 files changed, 122 insertions(+), 81 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Thu, Jul 19, 2012 at 5:33 PM, Oliver Neukum oneu...@suse.de wrote: On Thursday 19 July 2012 16:21:38 Lan Tianyu wrote: On 2012年07月19日 14:37, Oliver Neukum wrote: Unloading the driver is a user space issue. But you are right there is a missing case hi all: I have a question About device which needs a firmware when connected. If the port powered off when it was suspend, the port would power on when system try to access the device. What happen if try to resume the device, guess it will fail. usb core would disconnect the device and renumerate the device. Yes. That's how reset_resume() works. If reset_resume flag is set, usbcore will try to reset the device first during resume, and no disconnect will be involved if reset completes successfully. The driver loaded again with firmware and the device still could work, is Right? No. All settings user space has done will be lost. I have no a such device to do test. Just from guess. The point is whether resuming the device without loading firmware will fail. It must. Interfaces can vanish and the device class can change. There's nothing to remain bound to. If only interfaces may vanish, how about store the user setting things inside usb_device instance of the interfaces? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 06/11] arm/dts: am33xx: Add dt data for usbss
Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,musb-am33xx;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ port0_mode = 3;
+ port1_mode = 1;
+ power = 250;
+ };
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/11] arm/dts: am33xx: add dt data for usb nop phy
AM33xx has two musb controller and they have one NOP PHY each.
Added the device tree data for NOP PHY.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 08e9a40..b03a9b5 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -155,6 +155,14 @@
ti,hwmods = i2c3;
};
+ usb0_phy: phy0 {
+ compatible = nop-xceiv-usb;
+ };
+
+ usb1_phy: phy1 {
+ compatible = nop-xceiv-usb;
+ };
+
usb_otg_hs: usb_otg_hs {
compatible = ti,musb-am33xx;
ti,hwmods = usb_otg_hs;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 03/11] usb: musb: am335x: add support for dual instance
AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.
Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_dsps.c | 93 +
1 files changed, 57 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..a2c8a06 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8 poll_seconds;
+ /* number of musb instances */
+ u8 instances;
};
/**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
*/
struct dsps_glue {
struct device *dev;
- struct platform_device *musb; /* child musb pdev */
+ struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
- struct timer_list timer;/* otg_workaround timer */
- u32 __iomem *usb_ctrl;
+ struct timer_list timer[2]; /* otg_workaround timer */
+ unsigned long last_timer[2];/* last timer data for each instance */
+ u32 __iomem *usb_ctrl[2];
u8 usbss_rev;
};
/**
* musb_dsps_phy_control - phy on/off
* @glue: struct dsps_glue *
+ * @id: musb instance
* @on: flag for phy to be switched on or off
*
* This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
* XXX: This function will be removed once we have a seperate driver for
* control module
*/
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
{
u32 usbphycfg;
- usbphycfg = __raw_readl(glue-usb_ctrl);
+ usbphycfg = __raw_readl(glue-usb_ctrl[id]);
if (on) {
if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue,
u8 on)
glue-usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
- __raw_writel(usbphycfg, glue-usb_ctrl);
+ __raw_writel(usbphycfg, glue-usb_ctrl[id]);
}
/**
* dsps_musb_enable - enable interrupts
@@ -247,7 +251,7 @@ static void otg_timer(unsigned long _musb)
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl MUSB_DEVCTL_BDEVICE)
- mod_timer(glue-timer,
+ mod_timer(glue-timer[musb-id],
jiffies + wrp-poll_seconds * HZ);
else
musb-xceiv-state = OTG_STATE_A_IDLE;
@@ -263,7 +267,6 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned
long timeout)
struct device *dev = musb-controller;
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
- static unsigned long last_timer;
if (!is_otg_enabled(musb))
return;
@@ -276,22 +279,23 @@ static void dsps_musb_try_idle(struct musb *musb,
unsigned long timeout)
musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb-controller, %s active, deleting timer\n,
otg_state_string(musb-xceiv-state));
- del_timer(glue-timer);
- last_timer = jiffies;
+ del_timer(glue-timer[musb-id]);
+ glue-last_timer[musb-id] = jiffies;
return;
}
- if (time_after(last_timer, timeout) timer_pending(glue-timer)) {
+ if (time_after(glue-last_timer[musb-id], timeout)
+ timer_pending(glue-timer[musb-id])) {
dev_dbg(musb-controller,
Longer idle timer already pending, ignoring...\n);
return;
}
- last_timer = timeout;
+ glue-last_timer[musb-id] = timeout;
dev_dbg(musb-controller, %s inactive, starting idle timer for %u
ms\n,
otg_state_string(musb-xceiv-state),
jiffies_to_msecs(timeout - jiffies));
- mod_timer(glue-timer, timeout);
+ mod_timer(glue-timer[musb-id], timeout);
}
static irqreturn_t dsps_interrupt(int irq, void *hci)
@@ -360,7 +364,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
*/
musb-int_usb = ~MUSB_INTR_VBUSERROR;
musb-xceiv-state = OTG_STATE_A_WAIT_VFALL;
- mod_timer(glue-timer,
+
[PATCH v4 09/11] usb: musb: dsps: remove explicit NOP device creation
As NOP device node is now added in am33xx tree so remove the call which creates the NOP platform_device. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/musb_dsps.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index ac9f58b..78c88fd 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -425,8 +425,7 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb-mregs += wrp-musb_core_offset; - /* Register NOP driver */ - usb_nop_xceiv_register(musb-id); + /* Get the NOP PHY */ musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 11/11] arm/dts: am33xx: add phy phandle to usbss
Added NOP PHY phandle to usbss device node as same will be used to get the phy from otg framework. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- arch/arm/boot/dts/am33xx.dtsi |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index b03a9b5..d3ab69a 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -172,6 +172,8 @@ port0_mode = 3; port1_mode = 1; power = 250; + usb0-phy = usb0_phy; + usb1-phy = usb1_phy; }; }; }; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/11] usb: otg: nop: add dt support
Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt |3 +++
drivers/usb/otg/nop-usb-xceiv.c| 10 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index aa2f767..2788a00 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/usb/otg.h
@@ -151,12 +152,21 @@ static int __devexit nop_usb_xceiv_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+ { .compatible = nop-xceiv-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/11] usb: musb: kill global and static for multi instance
Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.
Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent device's dma_mask.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_core.c| 16 +++-
drivers/usb/musb/musb_core.h|4
drivers/usb/musb/musb_debugfs.c | 14 --
3 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 3e09984..a5db4dd 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1802,10 +1802,9 @@ static const struct attribute_group musb_attr_group = {
static void musb_irq_work(struct work_struct *data)
{
struct musb *musb = container_of(data, struct musb, irq_work);
- static int old_state;
- if (musb-xceiv-state != old_state) {
- old_state = musb-xceiv-state;
+ if (musb-xceiv-state != musb-xceiv_old_state) {
+ musb-xceiv_old_state = musb-xceiv-state;
sysfs_notify(musb-controller-kobj, NULL, mode);
}
}
@@ -2115,11 +2114,6 @@ fail0:
/* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
* bridge to a platform device; this driver then suffices.
*/
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
static int __devinit musb_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
@@ -2138,10 +2132,6 @@ static int __devinit musb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
-#ifndef CONFIG_MUSB_PIO_ONLY
- /* clobbered by use_dma=n */
- orig_dma_mask = dev-dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status 0)
iounmap(base);
@@ -2166,7 +2156,7 @@ static int __devexit musb_remove(struct platform_device
*pdev)
iounmap(ctrl_base);
device_init_wakeup(pdev-dev, 0);
#ifndef CONFIG_MUSB_PIO_ONLY
- pdev-dev.dma_mask = orig_dma_mask;
+ pdev-dev.dma_mask = (dev-dev.parent)-dma_mask;
#endif
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 69ed141..6b6cee9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -452,6 +452,10 @@ struct musb {
#endif
/* id for multiple musb instances */
u8 id;
+ int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *debugfs_root;
+#endif
};
static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..b1e8f21 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{ }/* Terminating Entry */
};
-static struct dentry *musb_debugfs_root;
-
static int musb_regdump_show(struct seq_file *s, void *unused)
{
struct musb *musb = s-private;
@@ -240,20 +238,24 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry *root;
struct dentry *file;
int ret;
+ charname[10];
- root = debugfs_create_dir(musb, NULL);
+ sprintf(name, musb%d, musb-id);
+ root = debugfs_create_dir(name, NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
}
- file = debugfs_create_file(regdump, S_IRUGO, root, musb,
+ sprintf(name, regdump%d, musb-id);
+ file = debugfs_create_file(name, S_IRUGO, root, musb,
musb_regdump_fops);
if (!file) {
ret = -ENOMEM;
goto err1;
}
+ sprintf(name, testmode%d, musb-id);
file = debugfs_create_file(testmode, S_IRUGO | S_IWUSR,
root, musb, musb_test_mode_fops);
if (!file) {
@@ -261,7 +263,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
- musb_debugfs_root = root;
+ musb-debugfs_root = root;
return 0;
@@ -274,5 +276,5 @@ err0:
void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
{
- debugfs_remove_recursive(musb_debugfs_root);
+ debugfs_remove_recursive(musb-debugfs_root);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. -- balbi Thanks Felipe regards keshava -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: chipidea: ci13xxx-imx: remove global struct
Hi Wolfram, On Thu, Jul 19, 2012 at 10:28:56AM +0200, Wolfram Sang wrote: On Thu, Jul 19, 2012 at 01:31:07AM +0200, Michael Grzeschik wrote: This patch removes the limitation of having only one instance of the ci13xxx-imx. Each instance of the ci13xxx-imx could have different flags to be configured with, so we also move this settings to the devicetree properties. Signed-off-by: Michael Grzeschik m.grzesc...@pengutronix.de --- .../devicetree/bindings/usb/ci13xxx-imx.txt|6 + New bindings should always have devicetree-discuss in CC. Right. drivers/usb/chipidea/ci13xxx_imx.c | 25 +++- drivers/usb/chipidea/core.c| 11 + include/linux/usb/chipidea.h |3 +++ 4 files changed, 34 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt index 2c29041..5485eb9 100644 --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt @@ -8,6 +8,9 @@ Required properties: Optional properties: - fsl,usbphy: phandler of usb phy that connects to the only one port - vbus-supply: regulator for vbus +- require-transceiver: enable the flag in the driver +- pullup-on-vbus: enable the flag in the driver +- disable-streaming: enable the flag in the driver NACK to the bindings. You are mapping platform data 1:1 which is nearly always wrong. Having a quick look in the current devicetree bindings for USB shows that there is a transceiver property. So, the the (non-)presence of that property should make require-transceiver superfluous? Also, is disable-streaming a description of the hardware? You are right it probably needs more investigation to decide which condition leads to which flags. Its probably not the best thing to move everything out to device tree. Actually i am touching two thing at a time in this patch, removing the static struct and setting the flags by oftree. I will resend this patch, together with other work, and will just leave the flags as currently set. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
pdata-mode is already read so above should be removed.
Ajay
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible =
Re: [RFC PATCH for v3.5 0/2] usb: gadget: at91_udc: fix oops regression
On Wed, Jul 18, 2012 at 11:56 AM, Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote: On Mon, Jul 16, 2012 at 02:50:29PM +0200, Fabio Porcedda wrote: PROBLEM: 1. usb: gadget: at91_udc: kernel oops regression when connecting the usb cable 2. Every time i connect the usb cable the kernel got a oops Don't really see the difference to 1 You are right. I've tried to follow the REPORTING-BUGS format, the point 2. it's just a description of the point 1. 3. usb gadget arm atmel at91_udc g_ether 4. The latest working kernel release is v3.4, the first non-woring release is v3.5-rc1. I've used an Atmel AT91SAM9260EK board. I would prefer to fix the bug causing the oops instead of reverting patches. Me too, it's just that i don't have much time to work on that, and so I'm not confident to be able to fix the kernel panic oops in time for the v3.5 release. IMHO it's not nice to release the v3.5 with a broken at91_udc driver, at least for the AT91SAM9260, i don't know if it's working on any other soc. Best regards -- Fabio Porcedda -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
Resend because sent to maillist failed. 2012/7/19 Oliver Neukum oneu...@suse.de On Thursday 19 July 2012 16:21:38 Lan Tianyu wrote: On 2012年07月19日 14:37, Oliver Neukum wrote: Unloading the driver is a user space issue. But you are right there is a missing case hi all: I have a question About device which needs a firmware when connected. If the port powered off when it was suspend, the port would power on when system try to access the device. What happen if try to resume the device, guess it will fail. usb core would disconnect the device and renumerate the device. Yes. That's how reset_resume() works. Oh. I recheck find these device will use ordinary resume rather than reset_resume(). I remeber you said userspace should set USB_QUIRK_RESET_MORPHS for those kind devices. After reset, they will morph. So reset_resume doesn't work for them. Ordinary resume almost just calls usb_get_status(udev, USB_RECIP_DEVICE, 0, devstatus) to verify whether usb device is OK. So even the device has been repowered. Resume will be sucessful even the interface is changed. So I have idea to add a verify_resume without reset for these kind devices. Check whether device class was changed or interface vanish .If it morphed, then return error and then renumerate then. Does this make sense? The driver loaded again with firmware and the device still could work, is Right? No. All settings user space has done will be lost. Can we notify user space to reconfigue it? Or they will find original device have removed and new device is coming. Reconfigue the new device. Because the device is renumerated during this procedure. -- Best regards Lan Tianyu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Wed, 18 Jul 2012, Oliver Neukum wrote: On Wednesday 18 July 2012 12:40:38 Alan Stern wrote: Oliver, you seem to be arguing both sides of this discussion. You But there are more than two sides in this discussion. point out the the power-off operation is too dangerous in general for the kernel to do it, and now you say that it's too racy for userspace to do it. It is too dangerous in general. Therefore it may be safe in particular. Are we to infer that you don't want it to be done at all? No, now that I think about it an attribute for the drivers is necessary. Like drivers have supports_autosuspend they also should have supports_power_off. In addition it is necessary for ports to have an attribute in sysfs which allows user space to block power off. And it is a bit complicated. Power may be cut, if a) a port is internal and unpluggable, or b) a port is internal and it's interfaces' drivers set supports_power_off, unless: 1) remote wakeup is requested 2) user space has blocked it via the new sysfs attribute 3) USB_QUIRK_RESET_MORPHS is set The same is true for external ports if they are marked as non-removable. For example, consider a compound keyboard/mouse device with a built-in hub. The connections from the keyboard and the mouse to the hub are internal and not removable. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Hi,
On Thu, Jul 19, 2012 at 6:51 PM, Gupta, Ajay Kumar ajay.gu...@ti.com wrote:
Hi,
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 55
2 files changed, 88 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type
of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..331e477 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board
data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
pdata-mode is already read so above should be removed.
Ok.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] usb: musb: gadget: do read_fifo for non zero data only
On 07/19/2012 03:22 PM, Gupta, Ajay Kumar wrote:
There is no need to call read_fifo for zero byte length.
The same as there's no need to write, and not only here?
Yes, it applies to write also but seems write is taken care
for zero byte length.
Frankly speaking, I don't see it. And what about non-0 endpoints?
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_gadget_ep0.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index e40d764..d762ddb 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -505,8 +505,10 @@ static void ep0_rxstate(struct musb *musb)
req-status = -EOVERFLOW;
count = len;
}
- musb_read_fifo(musb-endpoints[0], count, buf);
- req-actual += count;
+ if (count) {
+ musb_read_fifo(musb-endpoints[0], count, buf);
+ req-actual += count;
+ }
Does it save much?
We do save some instruction and that's good to have.
Wouldn't it be better to check for zero count inside musb_{read|write}_fifo()
though?
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some questions about usb_serial_probe
On Thu, 19 Jul 2012, loody wrote:
You didn't look at usb_serial_probe. At the end of that function there
I found what you mentioned.
for (i = 0; i num_ports; ++i) {
retval = device_add(port-dev);
...
Yes, that's it.
is a loop which runs over all the ports and registers them one at a
time with the device layer. When it is registered, the port is passed
to usb_serial_device_probe, which then registers the port with the tty
layer.
The port we pass to usb_serial_device_probe are usb_serial_port
instead of tty_port, we get it through to_usb_serial_port(dev);
Each usb_serial_port contains a tty_port embedded within it.
in usb_serial_device_probe, it do following things.
1. try to call port_probe, which seems do some control for usb_port
instead of tty port.
The two are pretty much the same thing. Look through the driver
sources to see how often port-port occurs.
2. calling device_create_file(dev, dev_attr_port_number);
dev in above function is embedded in usb_port not in tty_port.
3. tty_register_device(usb_serial_tty_driver, minor, dev); this is
most likely where we register tty port.
but all three parameters have no relations to tty port.
Well, minor comes from the usb_serial_port, and the tty_port is part of
the usb_serial_port.
if above flow is correct, how tty layer know how many tty_ports this
usb device have?
It doesn't know. All it knows is that a bunch of tty_port devices have
been registered; it doesn't know that they all belong to the same USB
device.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/2] usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams
On Thu, 19 Jul 2012, Laurent Pinchart wrote: Hi, Here's the fourth version of the Logitech UVC devices RESET_RESUME quirk patches. Compared to v3, the usb_detect_interface_quirks() has been moved to usb_enumerate_device(). Laurent Pinchart (2): usb: Add quirk detection based on interface information usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams For both patches: Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration post-resume NOT persistent yet persist -- swapped devices nodes -- root partition reference broken
On Thu, 19 Jul 2012, Andreas Mohr wrote: Hi, Yesterday I was surprised to see that with *another* external USB disk happening to be connected before boot, the system booted with root partition device sdb1 assigned rather than sda1. Not thinking much, I then proceeded putting the system into suspend, Do you mean suspend or hibernate? only to be even more surprised to then end up with swapped device nodes post-resume and the system killed (I *know* that device nodes ended up jumbled since the root device contains root plus swap partition device node, whereas the other USB device contains one partition only, and the set of partition device nodes as still successfully looked up via ls -l /dev/sd* ended up exactly reversed after system resume). That shouldn't happen in any case, but it seems more likely to happen after hibernation than after suspend. I attempted to get dmesg off this system, however not even plain sector writing of my /tmp/dmesg.log to a new USB device worked since dd segfaulted. Also, no network access of course. Can you reproduce the problem? http://lists.linux-foundation.org/pipermail/linux-pm/2009-November/023101.html talks about this case, and mentions Documentation/usb/persist.txt as the most authoritative document. The thing is, /sys persist nodes *are* all set to 1 for any affected device (at least as observed after the subsequent fresh boot). The plausibility of the previous killed boot having had persist attribute set as well for all devices is VERY high (there were no changes/updates in system software configuration done, thus settings should have been identical). Thus I'm highly puzzled as to why with USB persistence *activated* it still decided to jumble device nodes on this system resume. Content of the pathological dmesg log didn't contain any mentioning of any persistence mechanism activity, BTW, AFAIR. Device identification *is* as unique as it gets: # lsusb Bus 001 Device 005: ID 174c:55aa ASMedia Technology Inc. Bus 001 Device 002: ID 152d:0601 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 001 Device 004: ID 064e:d101 Suyin Corp. Acer CrystalEye Webcam Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub ... Netbook Acer Aspire One A110L. Running 3.5.0-rc7+ here (yes ma'am, bleeding edge tester :). Was the first time to attempt resume with an additional device remaining connected, IIRC - that -rc7 thing likely doesn't play much of a role here. A bit hesitant to (dis-)prove the bug's regression flag with another version since random possibly succeeding I/O accesses to incompatible devices are not necessarily my thing (or is this safe to attempt again? Any more specific session info one would need?). Well, the dmesg log would help. If you still think the USB layer is at fault then you should enable CONFIG_USB_DEBUG. So, again, possibly USB persistence is bug-broken? You don't have any good evidence to suggest that. None of the information you provided indicates that any USB device nodes (such as /dev/bus/usb/001/002) got mixed up. All you know is that the block-layer device nodes (such as /dev/sda2) got changed. Furthermore, if USB persist were broken then the symptoms would be different. Instead of starting with a root partition at sdb1 and then finding it at sda1, you would have found it gone completely and there would be _new_ devices labelled sdc and sdd. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, 19 Jul 2012, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. I have no objection to reverting the patch. But on a related note, have you had a chance to read my comment: http://marc.info/?l=linux-usbm=134098423528415w=2 ? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel tracing options with USB subsystem
Hello Alan, John, I had this question from the embedded perspective. printk on occasions seems to have some overhead which actually dilutes the issue occurrence frequency. So, just wanted to know if this was not included by choice. Many Thanks, ~Bala On 07/19/2012 12:12 AM, Alan Stern wrote: On Wed, 18 Jul 2012, Balakumar wrote: Hello All, I see that there are no tracing options (e.g. traceevents) defined in the USB subsystem. Like, they have been defined for scsi, scheduler, workqueues etc (include/trace/events/*). I am fairly new to Linux and I am trying to study the debugging options available. Just wanted to understand why such kernel tracing options are not used with USB. As far as I know, the only reason there aren't any USB tracepoints is because nobody has ever felt the need to add some. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration post-resume NOT persistent yet persist -- swapped devices nodes -- root partition reference broken
Hi, On Thu, Jul 19, 2012 at 11:11:50AM -0400, Alan Stern wrote: On Thu, 19 Jul 2012, Andreas Mohr wrote: Hi, Yesterday I was surprised to see that with *another* external USB disk happening to be connected before boot, the system booted with root partition device sdb1 assigned rather than sda1. Not thinking much, I then proceeded putting the system into suspend, Do you mean suspend or hibernate? Doh - S2R. I don't do persistent hibernate here (writing some 1GB of data to flash-based storage each time possibly isn't all too healthy anyway). Can you reproduce the problem? Will retry soonish. http://lists.linux-foundation.org/pipermail/linux-pm/2009-November/023101.html Netbook Acer Aspire One A110L. Running 3.5.0-rc7+ here (yes ma'am, bleeding edge tester :). Was the first time to attempt resume with an additional device remaining connected, IIRC - that -rc7 thing likely doesn't play much of a role here. A bit hesitant to (dis-)prove the bug's regression flag with another version since random possibly succeeding I/O accesses to incompatible devices are not necessarily my thing (or is this safe to attempt again? Any more specific session info one would need?). Well, the dmesg log would help. If you still think the USB layer is at fault then you should enable CONFIG_USB_DEBUG. Maybe I can get this successfully off the machine next time, by pre-caching required binaries prior to initiating a non-working resume. So, again, possibly USB persistence is bug-broken? You don't have any good evidence to suggest that. None of the information you provided indicates that any USB device nodes (such as /dev/bus/usb/001/002) got mixed up. All you know is that the block-layer device nodes (such as /dev/sda2) got changed. OK - so you're trying in vain to tell dense me that I'm supposed to take note of the *non-changing* (i.e., correctly persistent) USB device ID scheme rather than the roguely changing device nodes. To which I say that unfortunately I don't have a pre/post comparison at this moment yet. Furthermore, if USB persist were broken then the symptoms would be different. Instead of starting with a root partition at sdb1 and then finding it at sda1, you would have found it gone completely and there would be _new_ devices labelled sdc and sdd. Ah, yeah - I tend to know *this* other effect, too... Alan Stern Thanks a ton for your reply! Now I know that there's a tendency to better look on the other side (block device layer etc.) and analyze things there, once it's established that USB topology ID numbering in fact did persist. Andreas Mohr -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel tracing options with USB subsystem
On Thu, Jul 19, 2012 at 10:00:12PM +0530, Balakumar wrote: Hello Alan, John, I had this question from the embedded perspective. printk on occasions seems to have some overhead which actually dilutes the issue occurrence frequency. So, just wanted to know if this was not included by choice. What does printk have to do with usbmon? And note, the USB tracing code was added before there was an in-kernel tracing infrastructure, so that is why it does not take advantage of it. Does usbmon somehow not work for you? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB enumeration post-resume NOT persistent yet persist -- swapped devices nodes -- root partition reference broken
On Thu, 19 Jul 2012, Andreas Mohr wrote: Hi, On Thu, Jul 19, 2012 at 11:11:50AM -0400, Alan Stern wrote: On Thu, 19 Jul 2012, Andreas Mohr wrote: Hi, Yesterday I was surprised to see that with *another* external USB disk happening to be connected before boot, the system booted with root partition device sdb1 assigned rather than sda1. Not thinking much, I then proceeded putting the system into suspend, Do you mean suspend or hibernate? Doh - S2R. I don't do persistent hibernate here (writing some 1GB of data to flash-based storage each time possibly isn't all too healthy anyway). Can you reproduce the problem? Will retry soonish. It's understandable that you might not want to risk corrupting an important filesystem. Some systems allow you to run with a read-only root and no swap; you could try that. Or run entirely from within an initramfs image, the way a Rescue CD does. http://lists.linux-foundation.org/pipermail/linux-pm/2009-November/023101.html Netbook Acer Aspire One A110L. Running 3.5.0-rc7+ here (yes ma'am, bleeding edge tester :). Was the first time to attempt resume with an additional device remaining connected, IIRC - that -rc7 thing likely doesn't play much of a role here. A bit hesitant to (dis-)prove the bug's regression flag with another version since random possibly succeeding I/O accesses to incompatible devices are not necessarily my thing (or is this safe to attempt again? Any more specific session info one would need?). Well, the dmesg log would help. If you still think the USB layer is at fault then you should enable CONFIG_USB_DEBUG. Maybe I can get this successfully off the machine next time, by pre-caching required binaries prior to initiating a non-working resume. Running within an initramfs image would probably avoid this problem. So, again, possibly USB persistence is bug-broken? You don't have any good evidence to suggest that. None of the information you provided indicates that any USB device nodes (such as /dev/bus/usb/001/002) got mixed up. All you know is that the block-layer device nodes (such as /dev/sda2) got changed. OK - so you're trying in vain to tell dense me that I'm supposed to take note of the *non-changing* (i.e., correctly persistent) USB device ID scheme rather than the roguely changing device nodes. To which I say that unfortunately I don't have a pre/post comparison at this moment yet. That's one of the reasons why reproducing the problem is important. Furthermore, if USB persist were broken then the symptoms would be different. Instead of starting with a root partition at sdb1 and then finding it at sda1, you would have found it gone completely and there would be _new_ devices labelled sdc and sdd. Ah, yeah - I tend to know *this* other effect, too... Not recently, I hope! Alan Stern Thanks a ton for your reply! Now I know that there's a tendency to better look on the other side (block device layer etc.) and analyze things there, once it's established that USB topology ID numbering in fact did persist. What you described does sound very weird. The relation between block devices and the underlying physical devices is determined entirely by software data structures, which should not change over the course of a suspend. I don't understand how it could have happened. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usbserial issue
Hi, I am playing with some devices and seems to me that I stuck with a driver limitation. I connected usb-to-rs323/485 converter that uses ftdi_sio and usbserial modules and it works. After that I tried to use a 3g modem and it works passing vendor and product parameters to the usbserial module. But if I try to use both devices together just one works. Looking the documentation seems to me that the usbserial is made to suport just one device, is this true? I will try to recompile the usbserial module with another name to load it 2 times with different parameters. Is there something that will prevent this idea to work ? Thanks, Guilherme -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] USBHID: fix several suspend-related bugs
Jiri: This patch series fixes several major and minor bugs in the usbhid driver related to suspend and resume, and especially autosuspend. I don't think any of the problems are terribly severe, although some of them prevent autosuspend from working properly, so I haven't marked the patches for -stable. If you want to submit some of them (especially the first two) for the stable trees, that's okay with me. Alan Stern drivers/hid/usbhid/hid-core.c | 300 +- drivers/hid/usbhid/usbhid.h |1 2 files changed, 154 insertions(+), 147 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] USBHID: fix use-after-free bug
This patch (as1592) fixes an obscure problem in the usbhid driver.
Under some circumstances, a control or interrupt-OUT URB can be
submitted twice. This will happen if the first submission fails; the
queue pointers aren't updated, so the next time the queue is restarted
the same URB will be submitted again.
The problem is that raw_report gets deallocated during the first
submission. The second submission will then dereference and try to
free an already-freed region of memory. The patch fixes the problem
by setting raw_report to NULL when it is deallocated and checking for
NULL before dereferencing it.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Oliver Neukum oli...@neukum.org
---
drivers/hid/usbhid/hid-core.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -331,9 +331,12 @@ static int hid_submit_out(struct hid_dev
usbhid-urbout-transfer_buffer_length = ((report-size - 1) 3) +
1 + (report-id 0);
usbhid-urbout-dev = hid_to_usb_dev(hid);
- memcpy(usbhid-outbuf, raw_report,
- usbhid-urbout-transfer_buffer_length);
- kfree(raw_report);
+ if (raw_report) {
+ memcpy(usbhid-outbuf, raw_report,
+ usbhid-urbout-transfer_buffer_length);
+ kfree(raw_report);
+ usbhid-out[usbhid-outtail].raw_report = NULL;
+ }
dbg_hid(submitting out urb\n);
@@ -362,8 +365,11 @@ static int hid_submit_ctrl(struct hid_de
if (dir == USB_DIR_OUT) {
usbhid-urbctrl-pipe = usb_sndctrlpipe(hid_to_usb_dev(hid), 0);
usbhid-urbctrl-transfer_buffer_length = len;
- memcpy(usbhid-ctrlbuf, raw_report, len);
- kfree(raw_report);
+ if (raw_report) {
+ memcpy(usbhid-ctrlbuf, raw_report, len);
+ kfree(raw_report);
+ usbhid-ctrl[usbhid-ctrltail].raw_report = NULL;
+ }
} else {
int maxpacket, padlen;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] USBHID: fix autosuspend calls
This patch (as1593) fixes some logic errors in the usbhid driver
relating to runtime PM. The driver does not balance its calls to
usb_autopm_get_interface_async() and usb_autopm_put_interface_async().
For example, when the control queue is restarted the driver does a
_get. But the resume won't happen immediately, so the driver leaves
the queue stopped. When the resume does occur, the queue is restarted
and a second _get occurs, with no balancing _put.
The patch fixes the problem by rearranging the logic for restarting
the queues. All the _get/_put calls and bitflag settings in
__usbhid_submit_report() are moved into the queue-restart routines. A
balancing _put call is added for the case where the queue is still
suspended. A call to irq_out_pump_restart(), which doesn't take all
the right actions for restarting the irq-OUT queue, is replaced by a
call to usbhid_restart_out_queue(), which does. Similarly for
ctrl_pump_restart().
Finally, new code is added to prevent an autosuspend from happening
every time an URB is cancelled, and the comments explaining what
happens when an URB needs to be cancelled are expanded and clarified.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Oliver Neukum oli...@neukum.org
---
drivers/hid/usbhid/hid-core.c | 146 --
1 file changed, 72 insertions(+), 74 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -213,9 +213,20 @@ static int usbhid_restart_out_queue(stru
if ((kicked = (usbhid-outhead != usbhid-outtail))) {
hid_dbg(hid, Kicking head %d tail %d, usbhid-outhead,
usbhid-outtail);
+ /* Try to wake up from autosuspend... */
r = usb_autopm_get_interface_async(usbhid-intf);
if (r 0)
return r;
+
+ /*
+* If still suspended, don't submit. Submission will
+* occur if/when resume drains the queue.
+*/
+ if (test_bit(HID_REPORTED_IDLE, usbhid-iofl)) {
+ usb_autopm_put_interface_no_suspend(usbhid-intf);
+ return r;
+ }
+
/* Asynchronously flush queue. */
set_bit(HID_OUT_RUNNING, usbhid-iofl);
if (hid_submit_out(hid)) {
@@ -240,9 +251,20 @@ static int usbhid_restart_ctrl_queue(str
if ((kicked = (usbhid-ctrlhead != usbhid-ctrltail))) {
hid_dbg(hid, Kicking head %d tail %d, usbhid-ctrlhead,
usbhid-ctrltail);
+ /* Try to wake up from autosuspend... */
r = usb_autopm_get_interface_async(usbhid-intf);
if (r 0)
return r;
+
+ /*
+* If still suspended, don't submit. Submission will
+* occur if/when resume drains the queue.
+*/
+ if (test_bit(HID_REPORTED_IDLE, usbhid-iofl)) {
+ usb_autopm_put_interface_no_suspend(usbhid-intf);
+ return r;
+ }
+
/* Asynchronously flush queue. */
set_bit(HID_CTRL_RUNNING, usbhid-iofl);
if (hid_submit_ctrl(hid)) {
@@ -546,49 +568,36 @@ static void __usbhid_submit_report(struc
usbhid-out[usbhid-outhead].report = report;
usbhid-outhead = head;
- /* Try to awake from autosuspend... */
- if (usb_autopm_get_interface_async(usbhid-intf) 0)
- return;
+ /* If the queue isn't running, restart it */
+ if (!test_bit(HID_OUT_RUNNING, usbhid-iofl)) {
+ usbhid_restart_out_queue(usbhid);
- /*
-* But if still suspended, leave urb enqueued, don't submit.
-* Submission will occur if/when resume() drains the queue.
-*/
- if (test_bit(HID_REPORTED_IDLE, usbhid-iofl))
- return;
+ /* Otherwise see if an earlier request has timed out */
+ } else if (time_after(jiffies, usbhid-last_out + HZ * 5)) {
+
+ /* Prevent autosuspend following the unlink */
+ usb_autopm_get_interface_no_resume(usbhid-intf);
- if (!test_and_set_bit(HID_OUT_RUNNING, usbhid-iofl)) {
- if (hid_submit_out(hid)) {
- clear_bit(HID_OUT_RUNNING, usbhid-iofl);
- usb_autopm_put_interface_async(usbhid-intf);
- }
- wake_up(usbhid-wait);
- } else {
/*
-* the queue is known to run
-* but an earlier request may be stuck
-
[PATCH 3/6] USBHID: inline some simple routines
This patch (as1594) simplifies the usbhid driver by inlining a couple
of routines. As a result of an earlier patch, irq_out_pump_restart()
and ctrl_pump_restart() are each used in only one place. Since they
don't really do what their names say, and since they each involve only
about two lines of actual code, there's no reason to keep them as
separate functions.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Oliver Neukum oli...@neukum.org
---
drivers/hid/usbhid/hid-core.c | 47 ++
1 file changed, 16 insertions(+), 31 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -435,16 +435,6 @@ static int hid_submit_ctrl(struct hid_de
* Output interrupt completion handler.
*/
-static int irq_out_pump_restart(struct hid_device *hid)
-{
- struct usbhid_device *usbhid = hid-driver_data;
-
- if (usbhid-outhead != usbhid-outtail)
- return hid_submit_out(hid);
- else
- return -1;
-}
-
static void hid_irq_out(struct urb *urb)
{
struct hid_device *hid = urb-context;
@@ -469,15 +459,17 @@ static void hid_irq_out(struct urb *urb)
spin_lock_irqsave(usbhid-lock, flags);
- if (unplug)
+ if (unplug) {
usbhid-outtail = usbhid-outhead;
- else
+ } else {
usbhid-outtail = (usbhid-outtail + 1) (HID_OUTPUT_FIFO_SIZE
- 1);
- if (!irq_out_pump_restart(hid)) {
- /* Successfully submitted next urb in queue */
- spin_unlock_irqrestore(usbhid-lock, flags);
- return;
+ if (usbhid-outhead != usbhid-outtail
+ hid_submit_out(hid) == 0) {
+ /* Successfully submitted next urb in queue */
+ spin_unlock_irqrestore(usbhid-lock, flags);
+ return;
+ }
}
clear_bit(HID_OUT_RUNNING, usbhid-iofl);
@@ -489,15 +481,6 @@ static void hid_irq_out(struct urb *urb)
/*
* Control pipe completion handler.
*/
-static int ctrl_pump_restart(struct hid_device *hid)
-{
- struct usbhid_device *usbhid = hid-driver_data;
-
- if (usbhid-ctrlhead != usbhid-ctrltail)
- return hid_submit_ctrl(hid);
- else
- return -1;
-}
static void hid_ctrl(struct urb *urb)
{
@@ -526,15 +509,17 @@ static void hid_ctrl(struct urb *urb)
hid_warn(urb-dev, ctrl urb status %d received\n, status);
}
- if (unplug)
+ if (unplug) {
usbhid-ctrltail = usbhid-ctrlhead;
- else
+ } else {
usbhid-ctrltail = (usbhid-ctrltail + 1)
(HID_CONTROL_FIFO_SIZE - 1);
- if (!ctrl_pump_restart(hid)) {
- /* Successfully submitted next urb in queue */
- spin_unlock(usbhid-lock);
- return;
+ if (usbhid-ctrlhead != usbhid-ctrltail
+ hid_submit_ctrl(hid) == 0) {
+ /* Successfully submitted next urb in queue */
+ spin_unlock(usbhid-lock);
+ return;
+ }
}
clear_bit(HID_CTRL_RUNNING, usbhid-iofl);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] USBHID: replace HID_REPORTED_IDLE with HID_SUSPENDED
This patch (as1595) improves the usbhid driver by using the
HID_SUSPENDED bitflag to indicate that the device is suspended rather
than using HID_REPORTED_IDLE, which the patch removes.
Since HID_SUSPENDED was not being used for anything, and since the
name HID_REPORTED_IDLE doesn't convey much meaning, the end result
is easier to read and understand.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Oliver Neukum oli...@neukum.org
---
drivers/hid/usbhid/hid-core.c | 14 +++---
drivers/hid/usbhid/usbhid.h |1 -
2 files changed, 7 insertions(+), 8 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/usbhid.h
===
--- usb-3.5.orig/drivers/hid/usbhid/usbhid.h
+++ usb-3.5/drivers/hid/usbhid/usbhid.h
@@ -53,7 +53,6 @@ struct usb_interface *usbhid_find_interf
#define HID_CLEAR_HALT 6
#define HID_DISCONNECTED 7
#define HID_STARTED8
-#define HID_REPORTED_IDLE 9
#define HID_KEYS_PRESSED 10
#define HID_NO_BANDWIDTH 11
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -84,7 +84,7 @@ static int hid_start_in(struct hid_devic
spin_lock_irqsave(usbhid-lock, flags);
if (hid-open 0
!test_bit(HID_DISCONNECTED, usbhid-iofl)
- !test_bit(HID_REPORTED_IDLE, usbhid-iofl)
+ !test_bit(HID_SUSPENDED, usbhid-iofl)
!test_and_set_bit(HID_IN_RUNNING, usbhid-iofl)) {
rc = usb_submit_urb(usbhid-urbin, GFP_ATOMIC);
if (rc != 0) {
@@ -222,7 +222,7 @@ static int usbhid_restart_out_queue(stru
* If still suspended, don't submit. Submission will
* occur if/when resume drains the queue.
*/
- if (test_bit(HID_REPORTED_IDLE, usbhid-iofl)) {
+ if (test_bit(HID_SUSPENDED, usbhid-iofl)) {
usb_autopm_put_interface_no_suspend(usbhid-intf);
return r;
}
@@ -260,7 +260,7 @@ static int usbhid_restart_ctrl_queue(str
* If still suspended, don't submit. Submission will
* occur if/when resume drains the queue.
*/
- if (test_bit(HID_REPORTED_IDLE, usbhid-iofl)) {
+ if (test_bit(HID_SUSPENDED, usbhid-iofl)) {
usb_autopm_put_interface_no_suspend(usbhid-intf);
return r;
}
@@ -1475,7 +1475,7 @@ static int hid_suspend(struct usb_interf
!test_bit(HID_KEYS_PRESSED, usbhid-iofl)
(!usbhid-ledcount || ignoreled))
{
- set_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ set_bit(HID_SUSPENDED, usbhid-iofl);
spin_unlock_irq(usbhid-lock);
if (hid-driver hid-driver-suspend) {
status = hid-driver-suspend(hid, message);
@@ -1495,7 +1495,7 @@ static int hid_suspend(struct usb_interf
return status;
}
spin_lock_irq(usbhid-lock);
- set_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ set_bit(HID_SUSPENDED, usbhid-iofl);
spin_unlock_irq(usbhid-lock);
if (usbhid_wait_io(hid) 0)
return -EIO;
@@ -1525,7 +1525,7 @@ static int hid_resume(struct usb_interfa
if (!test_bit(HID_STARTED, usbhid-iofl))
return 0;
- clear_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ clear_bit(HID_SUSPENDED, usbhid-iofl);
usbhid_mark_busy(usbhid);
if (test_bit(HID_CLEAR_HALT, usbhid-iofl) ||
@@ -1552,7 +1552,7 @@ static int hid_reset_resume(struct usb_i
struct usbhid_device *usbhid = hid-driver_data;
int status;
- clear_bit(HID_REPORTED_IDLE, usbhid-iofl);
+ clear_bit(HID_SUSPENDED, usbhid-iofl);
status = hid_post_reset(intf);
if (status = 0 hid-driver hid-driver-reset_resume) {
int ret = hid-driver-reset_resume(hid);
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] USBHID: check for suspend or reset before restarting
This patch (as1596) improves the queue-restart logic in usbhid by
checking to see if the device is suspended or a reset is about to
occur. There's no point submitting an URB if either of those is
true.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Oliver Neukum oli...@neukum.org
---
drivers/hid/usbhid/hid-core.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -207,7 +207,8 @@ static int usbhid_restart_out_queue(stru
int kicked;
int r;
- if (!hid)
+ if (!hid || test_bit(HID_RESET_PENDING, usbhid-iofl) ||
+ test_bit(HID_SUSPENDED, usbhid-iofl))
return 0;
if ((kicked = (usbhid-outhead != usbhid-outtail))) {
@@ -245,7 +246,8 @@ static int usbhid_restart_ctrl_queue(str
int r;
WARN_ON(hid == NULL);
- if (!hid)
+ if (!hid || test_bit(HID_RESET_PENDING, usbhid-iofl) ||
+ test_bit(HID_SUSPENDED, usbhid-iofl))
return 0;
if ((kicked = (usbhid-ctrlhead != usbhid-ctrltail))) {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] USBHID: fix error paths in suspend
This patch (as1597) fixes some of the error paths in usbhid's suspend
routine. The driver was not careful to restart everything that might
have been stopped, in cases where a suspend failed.
For example, once the HID_SUSPENDED flag is set, an output report
submission would not restart the corresponding URB queue. If a
suspend fails, it's therefore necessary to check whether the queues
need to be restarted.
Signed-off-by: Alan Stern st...@rowland.harvard.edu
CC: Oliver Neukum oli...@neukum.org
---
drivers/hid/usbhid/hid-core.c | 71 ++
1 file changed, 44 insertions(+), 27 deletions(-)
Index: usb-3.5/drivers/hid/usbhid/hid-core.c
===
--- usb-3.5.orig/drivers/hid/usbhid/hid-core.c
+++ usb-3.5/drivers/hid/usbhid/hid-core.c
@@ -993,9 +993,10 @@ static int usbhid_output_raw_report(stru
static void usbhid_restart_queues(struct usbhid_device *usbhid)
{
- if (usbhid-urbout)
+ if (usbhid-urbout !test_bit(HID_OUT_RUNNING, usbhid-iofl))
usbhid_restart_out_queue(usbhid);
- usbhid_restart_ctrl_queue(usbhid);
+ if (!test_bit(HID_CTRL_RUNNING, usbhid-iofl))
+ usbhid_restart_ctrl_queue(usbhid);
}
static void hid_free_buffers(struct usb_device *dev, struct hid_device *hid)
@@ -1462,11 +1463,38 @@ void usbhid_put_power(struct hid_device
#ifdef CONFIG_PM
+static int hid_resume_common(struct hid_device *hid, bool driver_suspended)
+{
+ struct usbhid_device *usbhid = hid-driver_data;
+ int status;
+
+ spin_lock_irq(usbhid-lock);
+ clear_bit(HID_SUSPENDED, usbhid-iofl);
+ usbhid_mark_busy(usbhid);
+
+ if (test_bit(HID_CLEAR_HALT, usbhid-iofl) ||
+ test_bit(HID_RESET_PENDING, usbhid-iofl))
+ schedule_work(usbhid-reset_work);
+ usbhid-retry_delay = 0;
+
+ usbhid_restart_queues(usbhid);
+ spin_unlock_irq(usbhid-lock);
+
+ status = hid_start_in(hid);
+ if (status 0)
+ hid_io_error(hid);
+
+ if (driver_suspended hid-driver hid-driver-resume)
+ status = hid-driver-resume(hid);
+ return status;
+}
+
static int hid_suspend(struct usb_interface *intf, pm_message_t message)
{
struct hid_device *hid = usb_get_intfdata(intf);
struct usbhid_device *usbhid = hid-driver_data;
int status;
+ bool driver_suspended = false;
if (PMSG_IS_AUTO(message)) {
spin_lock_irq(usbhid-lock); /* Sync with error handler */
@@ -1482,8 +1510,9 @@ static int hid_suspend(struct usb_interf
if (hid-driver hid-driver-suspend) {
status = hid-driver-suspend(hid, message);
if (status 0)
- return status;
+ goto failed;
}
+ driver_suspended = true;
} else {
usbhid_mark_busy(usbhid);
spin_unlock_irq(usbhid-lock);
@@ -1496,11 +1525,14 @@ static int hid_suspend(struct usb_interf
if (status 0)
return status;
}
+ driver_suspended = true;
spin_lock_irq(usbhid-lock);
set_bit(HID_SUSPENDED, usbhid-iofl);
spin_unlock_irq(usbhid-lock);
- if (usbhid_wait_io(hid) 0)
- return -EIO;
+ if (usbhid_wait_io(hid) 0) {
+ status = -EIO;
+ goto failed;
+ }
}
hid_cancel_delayed_stuff(usbhid);
@@ -1508,14 +1540,15 @@ static int hid_suspend(struct usb_interf
if (PMSG_IS_AUTO(message) test_bit(HID_KEYS_PRESSED, usbhid-iofl))
{
/* lost race against keypresses */
- status = hid_start_in(hid);
- if (status 0)
- hid_io_error(hid);
- usbhid_mark_busy(usbhid);
- return -EBUSY;
+ status = -EBUSY;
+ goto failed;
}
dev_dbg(intf-dev, suspend\n);
return 0;
+
+ failed:
+ hid_resume_common(hid, driver_suspended);
+ return status;
}
static int hid_resume(struct usb_interface *intf)
@@ -1527,23 +1560,7 @@ static int hid_resume(struct usb_interfa
if (!test_bit(HID_STARTED, usbhid-iofl))
return 0;
- clear_bit(HID_SUSPENDED, usbhid-iofl);
- usbhid_mark_busy(usbhid);
-
- if (test_bit(HID_CLEAR_HALT, usbhid-iofl) ||
- test_bit(HID_RESET_PENDING, usbhid-iofl))
- schedule_work(usbhid-reset_work);
- usbhid-retry_delay = 0;
- status = hid_start_in(hid);
- if (status 0)
- hid_io_error(hid);
- usbhid_restart_queues(usbhid);
-
- if
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Thursday 19 July 2012 18:58:38 Ming Lei wrote: On Thu, Jul 19, 2012 at 5:33 PM, Oliver Neukum oneu...@suse.de wrote: Yes. That's how reset_resume() works. If reset_resume flag is set, usbcore will try to reset the device first during resume, and no disconnect will be involved if reset completes successfully. The code path still has to be coded. Basically usb_resume() must be extended to resume devices from a state analogous to D3cold. The driver loaded again with firmware and the device still could work, is Right? No. All settings user space has done will be lost. I have no a such device to do test. Just from guess. The point is whether resuming the device without loading firmware will fail. It must. Interfaces can vanish and the device class can change. There's nothing to remain bound to. If only interfaces may vanish, how about store the user setting things inside usb_device instance of the interfaces? We cannot do this as the device state is specific to a driver. And the driver must have an interface to be bound to. That is why we use reset_resume() instead of resume(). resume() means that the device must be brought up but has retained internal state. reset_resume() tells a driver that the internal state has been lost. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Thursday 19 July 2012 10:42:23 Alan Stern wrote: 1) remote wakeup is requested 2) user space has blocked it via the new sysfs attribute 3) USB_QUIRK_RESET_MORPHS is set The same is true for external ports if they are marked as non-removable. For example, consider a compound keyboard/mouse device with a built-in hub. The connections from the keyboard and the mouse to the hub are internal and not removable. True. So the decisive factor is not just being internal. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbserial issue
Hi, Thanks for explanation on how things work. The problem is if I don't pass the vendor and prodId the 3g modem is detect as an USB mass storage. Even after using usb_modeswitch usb_modeswitch -default-vendor 0x19d2 -default-product 0×2000 -target-vendor 0x19d2 -target-product 0×0031 -message-endpoint 0×01 -message-content 555342431234567 820008c85010101180101010101 I am running on: Linux OpenWrt 3.3.8 #1 Mon Jul 9 20:09:35 MSK 2012 mips GNU/Linux With: Modem 3g D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=19d2 ProdID=0031 Rev= 0.00 S: Manufacturer=ZTE,Incorporated S: Product=ZTE WCDMA Technologies MSM S: SerialNumber=P671A1VIVD01 [282646.03] usb 1-1.4: new high-speed USB device number 18 using ehci-platform [282646.17] scsi6 : usb-storage 1-1.4:1.2 [282647.17] scsi 6:0:0:0: Direct-Access ZTE MMC Storage 2.31 PQ: 0 ANSI: 2 [282647.19] sd 6:0:0:0: [sdb] Attached SCSI removable disk [282719.88] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected [282719.88] usb 1-1.3: Detected FT232BM [282719.89] usb 1-1.3: Number of endpoints 2 [282719.89] usb 1-1.3: Endpoint 1 MaxPacketSize 16384 [282719.90] usb 1-1.3: Endpoint 2 MaxPacketSize 16384 [282719.90] usb 1-1.3: Setting MaxPacketSize 64 [282719.92] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0 rs485 USB-Serial D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0403 ProdID=6001 Rev= 4.00 S: Manufacturer=FTDI S: Product=USB - Serial Any suggestions are welcome. Thanks, Guilherme On Thu, Jul 19, 2012 at 5:55 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 19, 2012 at 04:37:17PM -0300, Guilherme Bedin wrote: Hi, I am playing with some devices and seems to me that I stuck with a driver limitation. I connected usb-to-rs323/485 converter that uses ftdi_sio and usbserial modules and it works. After that I tried to use a 3g modem and it works passing vendor and product parameters to the usbserial module. Ah, you shouldn't be passing any vendor ids to the module, that's the problem here. The individual drivers should be handling this device, not the generic usb serial driver. What kernel version are you using? What is the vendor/product id of your 3g modem and your ftdi_sio device? But if I try to use both devices together just one works. Looking the documentation seems to me that the usbserial is made to suport just one device, is this true? Yes, it is ment to support only one generic device, that is true. I will try to recompile the usbserial module with another name to load it 2 times with different parameters. Is there something that will prevent this idea to work ? If it works, your device throughput will be very slow. Use the real drivers for your usb-serial devices instead (ftdi_sio and probably the option driver). thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: USB : Fix the EHCI enumeration and core retention issue
On Thu, Jul 19, 2012 at 01:20:14PM +0300, Felipe Balbi wrote: Hi, On Thu, Jun 21, 2012 at 07:12:12PM +0530, Keshava Munegowda wrote: This commit 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) is causing the usb hub and device detection fails in beagle XM causeing NFS not functional. This affects the core retention too. The same commit logic needs to be revisted adhering to hwmod and device tree framework. for now, this commit id 354ab8567ae3107a8cbe7228c3181990ba598aac titled Fix OMAP EHCI suspend/resume failure (i693) reverted. This patch is validated on BeagleXM with NFS support over usb ethernet and USB mass storage and other device detection. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Acked-by: Felipe Balbi ba...@ti.com turns out this is causing other issues and another version of the patch will be provided. Greg, Alan, this is basically a git revert of the commit id listed above. Ok, I'll queue it up for 3.6-rc1 and add a -stable mark to it to get into 3.5.1, ok? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] isp1362-hcd.c: usb message always saved in case of underrun
On Wed, Jul 18, 2012 at 10:53:09AM +0200, Claudio Scordino wrote:
Il 06/07/2012 19:41, Greg KH ha scritto:
On Wed, Jun 27, 2012 at 06:01:39PM +0200, Claudio Scordino wrote:
Hi Olav,
please find below a patch for the isp1362-hcd.c driver to always
save the message in case of underrun. More information is provided
inside the patch comment. Let us know if you need any further
information.
Best regards,
Claudio
Subject: isp1362-hcd.c: usb message always saved in case of underrun
From: Bruno Morellibr...@evidence.eu.com
The usb message must be saved also in case the USB endpoint is not a
control endpoint (i.e., endpoint 0), otherwise in some circumstances
we don't have a payload in case of error.
The patch has been created by tracing with usbmon the different error
messages generated by this driver with respect to the ehci-hcd driver.
Signed-off-by: Bruno Morellibr...@evidence.eu.com
Signed-off-by: Claudio Scordinoclau...@evidence.eu.com
Tested-by: Bruno Morellibr...@evidence.eu.com
---
drivers/usb/host/isp1362-hcd.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/isp1362-hcd.c b/drivers/usb/host/isp1362-hcd.c
index 2ed112d..61bf1b2 100644
--- a/drivers/usb/host/isp1362-hcd.c
+++ b/drivers/usb/host/isp1362-hcd.c
@@ -543,13 +543,14 @@ static void postproc_ep(struct isp1362_hcd
*isp1362_hcd, struct isp1362_ep *ep)
usb_pipein(urb-pipe) ? IN : OUT, ep-nextpid,
short_ok ? : not_,
PTD_GET_COUNT(ptd), ep-maxpacket, len);
+ /* save the data underrun error code for later and
+* proceed with the status stage
+*/
+ urb-actual_length += PTD_GET_COUNT(ptd);
+ BUG_ON(urb-actual_length
+ urb-transfer_buffer_length);
Please NEVER crash the machine in a driver like this, it's bad and can
cause problems. Yes, I know you are just moving it from the lines
below:
if (usb_pipecontrol(urb-pipe)) {
ep-nextpid = USB_PID_ACK;
- /* save the data underrun error code for later
and
-* proceed with the status stage
-*/
- urb-actual_length += PTD_GET_COUNT(ptd);
- BUG_ON(urb-actual_length
urb-transfer_buffer_length);
But really, it should not be in the driver at all. Please remove it, at
the most, do a WARN_ON() so that someone can see the problem and at
least report it.
Actually, what is this checking? How can someone recover from it? Who
is this check for? The developer of this driver? Another driver?
Hardware developer? End user? Who would be able to fix the problem if
this happens?
As it is, I can't take it, sorry.
Hi Greg.
I understand. As you have already said, this driver is full of BUG_ON
statements.
So, we can shift just the assignment as in the patch below, to have a
correct behavior, leaving the BUG_ON where it already is. Then, we may
propose a different patch to change BUG_ONs to WARN_ONs.
Your updated patch is much better, thanks.
But it doesn't apply to my tree right now. Can you please refresh it
against the usb-next tree and resend it?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
On Fri, Jul 20, 2012 at 3:37 AM, Oliver Neukum oli...@neukum.org wrote: We cannot do this as the device state is specific to a driver. And the driver must have an interface to be bound to. That is why we use reset_resume() instead of resume(). resume() means that the device must be brought up but has retained internal state. reset_resume() tells a driver that the internal state has been lost. The lost internal state is only visible to device or driver inside, and for user space application, it is still the original device, and both resume() and reset_resume() are no difference if the device is not disconnected. I mean for the firmware things involved, we can cache the firmware for interfaces until the device is disconnected, so interface driver can download firmware during resume path. But as Alan pointed out in another email, the reset may not complete successfully, so the device will be disconnected and enumerate again. For this situation, firmware downloading is not a big problem since it happens in .probe path. But user space application will find the device changed. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] USB: enable power/wakeup to control remote wakeup in the runtime suspend
Oh. I recheck find these device will use ordinary resume rather than reset_resume(). I remeber you said userspace should set USB_QUIRK_RESET_MORPHS for those kind devices. After reset, they will morph. So reset_resume doesn't work for them. Ordinary resume almost just calls usb_get_status(udev, USB_RECIP_DEVICE, 0, devstatus) to verify whether usb device is OK. So even the device has been repowered. Resume will be sucessful even the interface is changed. So I have idea to add a verify_resume without reset for these kind devices. Check whether device class was changed or interface vanish .If it morphed, then return error and then renumerate then. Does this make sense? If you have powered off the port during the suspend, the device will be at powered state after resume, the usb_get_status will be failed, even you skip the result of usb_get_status, the coming operation for that device will also be failed as the device address for itself returns to 0, but host doesn't know it. If port power is off (for bus powered device), the reset is the only way to let the device work again. The driver loaded again with firmware and the device still could work, is Right? No. All settings user space has done will be lost. Can we notify user space to reconfigue it? Or they will find original device have removed and new device is coming. Reconfigue the new device. Because the device is renumerated during this procedure. -- Best regards Lan Tianyu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/4] usb: musb: gadget: do read_fifo for non zero data only
Hi,
On 07/19/2012 03:22 PM, Gupta, Ajay Kumar wrote:
There is no need to call read_fifo for zero byte length.
The same as there's no need to write, and not only here?
Yes, it applies to write also but seems write is taken care
for zero byte length.
Frankly speaking, I don't see it. And what about non-0 endpoints?
We had seen zero byte rx on control endpoints but as it can happen
on non-0 endpoint so it is best to put this check in read_fifo and
write_fifo as you suggested.
I will update the patch and resubmit.
Thanks,
Ajay
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_gadget_ep0.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb/musb_gadget_ep0.c
b/drivers/usb/musb/musb_gadget_ep0.c
index e40d764..d762ddb 100644
--- a/drivers/usb/musb/musb_gadget_ep0.c
+++ b/drivers/usb/musb/musb_gadget_ep0.c
@@ -505,8 +505,10 @@ static void ep0_rxstate(struct musb *musb)
req-status = -EOVERFLOW;
count = len;
}
- musb_read_fifo(musb-endpoints[0], count, buf);
- req-actual += count;
+ if (count) {
+ musb_read_fifo(musb-endpoints[0], count, buf);
+ req-actual += count;
+ }
Does it save much?
We do save some instruction and that's good to have.
Wouldn't it be better to check for zero count inside
musb_{read|write}_fifo()
though?
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] usb: musb: gadget: don't program dma for zero byte tx
This is to reduce the overhead of dma programming for zero byte transmit as same can be done using pio mode. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- drivers/usb/musb/musb_gadget.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index b330ea6..841b442 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -366,7 +366,7 @@ static void txstate(struct musb *musb, struct musb_request *req) request_size = min_t(size_t, request-length - request-actual, musb_ep-dma-max_len); - use_dma = (request-dma != DMA_ADDR_INVALID); + use_dma = (request-dma != DMA_ADDR_INVALID request_size); /* MUSB_TXCSR_P_ISO is still set correctly */ -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] usb: musb: host: don't program dma for zero byte tx
This is to reduce the overhead of dma programming for zero byte
transmit as same can be done using pio mode.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_host.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 338947c..351f72a 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -693,6 +693,8 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
void __iomem*epio = hw_ep-regs;
struct musb_qh *qh = musb_ep_get_qh(hw_ep, !is_out);
u16 packet_sz = qh-maxpacket;
+ u8 use_dma = 1;
+ u16 csr;
dev_dbg(musb-controller, %s hw%d urb %p spd%d dev%d ep%d%s
h_addr%02x h_port%02x bytes %d\n,
@@ -704,9 +706,17 @@ static void musb_ep_program(struct musb *musb, u8 epnum,
musb_ep_select(mbase, epnum);
+ if (is_out !len) {
+ use_dma = 0;
+ csr = musb_readw(epio, MUSB_TXCSR);
+ csr = ~MUSB_TXCSR_DMAENAB;
+ musb_writew(epio, MUSB_TXCSR, csr);
+ hw_ep-tx_channel = NULL;
+ }
+
/* candidate for DMA? */
dma_controller = musb-dma_controller;
- if (is_dma_capable() epnum dma_controller) {
+ if (use_dma is_dma_capable() epnum dma_controller) {
dma_channel = is_out ? hw_ep-tx_channel : hw_ep-rx_channel;
if (!dma_channel) {
dma_channel = dma_controller-channel_alloc(
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] usb: musb: gadget: fix kernel crash after rmmod
musb-gadget_driver is not getting reset to NULL after the gadget driver is removed. Fixing the same by resetting the musb-gadget_driver to NULL when gadget driver is removed. Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com --- Changes from v1: - Fixed Sergei's commend on [PATCH 4/4] drivers/usb/musb/musb_gadget.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c index 95918da..b330ea6 100644 --- a/drivers/usb/musb/musb_gadget.c +++ b/drivers/usb/musb/musb_gadget.c @@ -2067,6 +2067,7 @@ static int musb_gadget_stop(struct usb_gadget *g, if (!is_otg_enabled(musb)) musb_stop(musb); + musb-gadget_driver = NULL; pm_runtime_put(musb-controller); return 0; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] usb: musb: check for zero byte in musb_read/write_fifo
Added a check in musb_{read | write}_fifo for zero byte length.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
drivers/usb/musb/musb_core.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index db3dff8..2901f38 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -234,6 +234,9 @@ void musb_write_fifo(struct musb_hw_ep *hw_ep, u16 len,
const u8 *src)
struct musb *musb = hw_ep-musb;
void __iomem *fifo = hw_ep-fifo;
+ if (unlikely(len == 0))
+ return;
+
prefetch((u8 *)src);
dev_dbg(musb-controller, %cX ep%d fifo %p count %d buf %p\n,
@@ -276,6 +279,9 @@ void musb_read_fifo(struct musb_hw_ep *hw_ep, u16 len, u8
*dst)
struct musb *musb = hw_ep-musb;
void __iomem *fifo = hw_ep-fifo;
+ if (unlikely(len == 0))
+ return;
+
dev_dbg(musb-controller, %cX ep%d fifo %p count %d buf %p\n,
'R', hw_ep-epnum, fifo, len, dst);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 --
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index d52651a..874aecc 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include plat/usb.h
#include control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
- if (IS_ERR(phyclk)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
- if (IS_ERR(clk48m)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, usb_phy_cm_clk32k);
- if (IS_ERR(clk32k)) {
- dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
-
[PATCH v5 06/11] arm/dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts |4
arch/arm/boot/dts/omap4-sdp.dts |4
arch/arm/boot/dts/twl6030.dtsi|6 ++
3 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..7052422 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,7 @@
ti,non-removable;
bus-width = 4;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..6326d7c 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,7 @@
bus-width = 4;
ti,non-removable;
};
+
+twlusb {
+ usb-supply = vusb;
+};
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..5efd6d3 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,10 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+ twlusb: twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 22 +++
drivers/usb/otg/twl6030-usb.c | 39 +---
2 files changed, 48 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..e3f6d73
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,22 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - usb-supply : phandle to the regulator device tree node. It should be vusb
+ if it is twl6030 or ldousb if it is twl6025 subclass.
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+};
+
+Board specific device node entry
+twl6030-usb {
+ usb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 9994dd22..6b0d0a1 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -321,9 +314,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev = pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -332,13 +325,24 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ twl-regulator = usb;
+ } else if (pdata) {
+ if (pdata-features TWL6025_SUBCLASS)
+ twl-regulator = ldousb;
+ else
+ twl-regulator = vusb;
+ } else {
+ dev_err(pdev-dev, twl6030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -400,12 +404,21 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible = ti,twl6030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#endif
+
static struct platform_driver twl6030_usb_driver = {
.probe = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
.driver = {
.name = twl6030_usb,
.owner = THIS_MODULE,
+ .of_match_table =
[PATCH v5 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from v4: duplicate getting of 'mode' property is removed in omap-musb glue. Changes from v3: remove the address in the node name of usb_otg_hs since the usb_otg_hs node doesn't have a reg property. Thanks Ajay Gupta for finding this. Changes from v2: Fixed Sergei's comment to remove *0x* prefix in usb2phy@0x4a0ad080 Changes from v1: * Fixed Rajendra Nayak comments (regulator naming, compatible naming of musb and other minor cleanups.) * It's agreed to have ocp2scp in drivers/bus and usb2 phy is a child of ocp2scp, the documentation is updated accordingly. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [PATCH 0/2] omap: add ocp2scp as a bus driver Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/bus/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 48 .../devicetree/bindings/usb/twl-usb.txt| 41 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts | 10 + arch/arm/boot/dts/omap4-sdp.dts| 10 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |6 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 106 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 271 drivers/usb/otg/twl4030-usb.c | 26 +- drivers/usb/otg/twl6030-usb.c | 153 +++ include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 705 insertions(+), 273 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 5fdb9da..addbebf 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue =
[PATCH v5 02/11] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29c6243..15f1890 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+ };
};
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl4030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 19 ++
drivers/usb/otg/twl4030-usb.c | 26 +++-
2 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index e3f6d73..bdf1dd4 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -20,3 +20,22 @@ Board specific device node entry
twl6030-usb {
usb-supply = vusb;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ - supply-name-supply : phandle to the regulator device tree node.
+ supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+ specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
+
+twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..f0d2e75 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(pdev-dev, platform_data not available\n);
- return -EINVAL;
- }
+ struct device_node *np = pdev-dev.of_node;
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, usb_mode,
+ (enum twl4030_usb_mode *)twl-usb_mode);
+ else if (pdata)
+ twl-usb_mode = pdata-usb_mode;
+ else {
+ dev_err(pdev-dev, twl4030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
- twl-usb_mode = pdata-usb_mode;
twl-vbus_supplied = false;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,21 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = ti,twl4030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(twl4030_usb_id_table),
},
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/bus/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 16 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 271
include/linux/usb/omap_usb.h | 45
include/linux/usb/phy_companion.h | 34 +++
7 files changed, 380 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
index d2fe064..bb0c7f4 100644
--- a/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
@@ -8,3 +8,6 @@ properties:
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+ The binding details of usb2phy can be found in:
+ Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..2f9e257
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,271 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/pm_runtime.h
+#include
[PATCH v5 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index ba24d15..c50d828 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5922,6 +5922,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab7ff,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 +++-
drivers/usb/musb/omap2430.c| 54
2 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index addbebf..5db228f 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,42 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +637,26 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
+ .compatible = ti,omap4-musb
+ },
+ {
+
[PATCH v5 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..4b8c142 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,omap3-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 7052422..dd19370 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -93,3 +93,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 6326d7c..0fc10d4 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -162,3 +162,9 @@
twlusb {
usb-supply = vusb;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 15f1890..7886518 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
0x4a002300 0x1;
};
};
+
+ usb_otg_hs: usb_otg_hs {
+ compatible = ti,omap4-musb;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 08/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..761a5a5 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator-vusb1v5 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator-vusb1v8 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator-vusb3v1 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
