Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tue, Jun 11, 2013 at 4:51 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 10 Jun 2013, Alan Stern wrote: Tasklet doesn't disable local interrupts. It is documented that interrupts will be disabled while the completion handler runs. Therefore the tasklet _must_ disable local interrupts. You know, it may be that you can get most of the advantages you want by enabling local interrupts around the call to unmap_urb_for_dma() in usb_hcd_giveback_urb(). No, please don't enable IRQs inside interrupt handler, and you will get warning dump. Except for unmap_urb_for_dma() in usb_hcd_giveback_urb(), I hope map_urb_for_dma() inside complete() can benefit from the change too, since map_urb_for_dma() is same time-consuming with unmap_urb_for_dma(). Also I hope complete() can be run with interrupt enabled since driver's complete() may take long time on some ARCH, as I mentioned in my last mail. And it isn't good to disable interrupt only for one interface driver, looks I still don't get real good explanation about disabling IRQs here, :-) This may be a little dangerous, though, because it is possible for an URB to be given back at the time it is submitted. Drivers may not expect interrupts to get enabled temporarily when they call usb_submit_urb(). 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: serial/ftdi_sio byte loss / performance regression
On Thu, Jun 06, 2013 at 11:21:54AM -0700, Greg KH wrote: On Thu, Jun 06, 2013 at 11:58:56AM +0200, Johan Hovold wrote: On Thu, Jun 06, 2013 at 10:50:36AM +0200, Tomaž Šolc wrote: Hi I have noticed that the ftdi_sio serial driver in recent kernel versions has very bad performance when used through the Python's serial library. As a test case I have a custom device that will send a continuous block of 5k characters once every few seconds over a RS-232 line (115200 baud) to an Olimex programmer (based on FT2232C, also tried one with FT2232H). Programmer is connected to a Linux system where a simple Python script reads the device: import serial comm = serial.Serial(/dev/ttyUSB0, 115200) while True: line = comm.readline() With kernels before 3.7.0 the script reads uncorrupted data while using newer kernels (including 3.9.4) the Python script sees heavy byte loss. top shows an 95% idle CPU. Only very slow transmissions (on the order of tens of bytes per second) will come through uncorrupted. Using git-bisect, I have found the commit that introduced this problem: 6f602912c9d0c84c2edbd446dd9f72660b701605 usb: serial: ftdi_sio: Add missing chars_in_buffer function This might also be related with the unusual way Python serial library reads the device. It uses select() with no timeout and single byte read()s in a loop. strace output: select(4, [3], [], [], NULL)= 1 (in [3]) read(3, D, 1) = 1 select(4, [3], [], [], NULL)= 1 (in [3]) read(3, E, 1) = 1 ... With sufficiently large read()s the byte loss can be eliminated. With the commit above, each select() now causes an additional round trip over USB to read the state of the hardware buffer. It's possible that constant status querying triggers some bug in the hardware or the query is simply too slow and causes overflows in the hardware buffer. You're absolutely right. This is a known issue (the select overhead) that was just recently fixed by commit a37025b5c7 (USB: ftdi_sio: fix chars_in_buffer overhead) in v3.10-rc3. Care to give v3.10-rc4 a try? Greg, perhaps we should consider backporting the wait-until-sent patches (i.e. 0693196fe..4746b6c6e)? Yes, that's a good idea, I'll do that for the next round of stable updates, after this next release tomorrow. I applied these, plus a few others in order to get them all to apply and build properly. But the last patch, 4746b6c6e, didn't apply, and I don't think we really need it for the 3.9 kernel, do we? 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] USB: serial/ftdi_sio.c Fix kernel oops
On Fri, Jun 07, 2013 at 03:14:32PM +0200, Lotfi Manseur wrote: Handle null termios in ftdi_set_termios(), introduced in commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846 This has been corrected in the mainline by commits c515598e0f5769916c31c00392cc2bfe6af74e55 and This commit showed up in 3.3, so it can't go into 3.4 at all. Please be more careful when asking for stable patches to be applied. That is why I want the _exact_ same patch to apply, don't try going and being smart by mushing them together into something else, this would have obviously not been correct for the 3.4 kernel at all. 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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tuesday 11 June 2013 13:40:20 Ming Lei wrote: On Tue, Jun 11, 2013 at 1:36 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 10 Jun 2013, Ming Lei wrote: If complete() callback runs in one tasklet context, spin_lock() inside complete() is enough, just like hard irq, the tasklet itself is disabled during complete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources between complete(). We also have exclusion between complete() and other contexts, i.e. timers. When the lock is to protect shared resources between complete() and non-IRQ context, currently spin_lock_irqsave() is used in non-IRQ context, which is enough to prevent tasklet from being run on the CPU, so no problem for this situation too. When all HCDs support to run URB giveback in tasklet context, we can change all spin_lock_irq*() to spin_lock() in drivers URB-complete(), and in other places, the spin_lock_irq*() can be changed to spin_lock_bh(). Even now we cannot guarantee that all calls to complete() are in irq. There is the case of HCD hotunplug and other cases, like timeouts. They will have to be verified. 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 v2 3/7] usb: musb: dsps: remove nop_xceiv_(un)register APIs from dsps glue
removed nop xceiv (un_)register API's references from musb dsps platform, as it uses saperate phy driver. Signed-off-by: Ravi Babu ravib...@ti.com --- drivers/usb/musb/musb_dsps.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 590dd0b..0ecedb3 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -36,7 +36,6 @@ #include linux/dma-mapping.h #include linux/pm_runtime.h #include linux/module.h -#include linux/usb/nop-usb-xceiv.h #include linux/platform_data/usb-omap.h #include linux/sizes.h @@ -416,7 +415,6 @@ static int dsps_musb_init(struct musb *musb) musb-mregs += wrp-musb_core_offset; /* NOP driver needs change if supporting dual instance */ - usb_nop_xceiv_register(); musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -EPROBE_DEFER; @@ -449,7 +447,6 @@ static int dsps_musb_init(struct musb *musb) return 0; err0: usb_put_phy(musb-xceiv); - usb_nop_xceiv_unregister(); return status; } @@ -466,7 +463,6 @@ static int dsps_musb_exit(struct musb *musb) /* NOP driver needs change if supporting dual instance */ usb_put_phy(musb-xceiv); - usb_nop_xceiv_unregister(); 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 6/7] usb: phy: dts: Adding usbphy DT bindings for am33xx
The am33xx platforms suppors dual musb instance which need two instances
of usb-phy. Add dual instance usb-phy DT bindings for am333x platform.
Signed-off-by: Ravi Babu ravib...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0957645..b0b4deb 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -322,6 +322,22 @@
status = disabled;
};
+ phy1: usbphy-gs70@44e10620 {
+ compatible = ti,dsps-usbphy;
+ reg = 0x44e10620 0x8
+ 0x44e10648 0x4;
+ reg-names = phy_ctrl,phy_wkup;
+ id = 0;
+ };
+
+ phy2: usbphy-gs70@44e10628 {
+ compatible = ti,dsps-usbphy;
+ reg = 0x44e10628 0x8
+ 0x44e10648 0x4;
+ reg-names = phy_ctrl,phy_wkup;
+ id = 1;
+ };
+
usb@4740 {
compatible = ti,musb-am33xx;
reg = 0x4740 0x1000/* usbss */
@@ -337,6 +353,7 @@
port1-mode = 3;
power = 250;
ti,hwmods = usb_otg_hs;
+ usb-phy = phy1, phy2;
};
mac: ethernet@4a10 {
--
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 7/7] usb: musb: dsp: remove the usb-phy control acess from platform glue
Remove usb-phy control access from platform glue, after moving
usb-phy controls to saperate phy-dsps-usb driver.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/musb_dsps.c | 51 --
1 files changed, 0 insertions(+), 51 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 0d8581b..958c6b6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -123,49 +123,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer[2]; /* otg_workaround timer */
unsigned long last_timer[2];/* last timer data for each instance */
- u32 __iomem *usb_ctrl[2];
};
-#defineDSPS_AM33XX_CONTROL_MODULE_PHYS_0 0x44e10620
-#defineDSPS_AM33XX_CONTROL_MODULE_PHYS_1 0x44e10628
-
-static const resource_size_t dsps_control_module_phys[] = {
- DSPS_AM33XX_CONTROL_MODULE_PHYS_0,
- DSPS_AM33XX_CONTROL_MODULE_PHYS_1,
-};
-
-#define USBPHY_CM_PWRDN(1 0)
-#define USBPHY_OTG_PWRDN (1 1)
-#define USBPHY_OTGVDET_EN (1 19)
-#define USBPHY_OTGSESSEND_EN (1 20)
-
-/**
- * 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
- * module space.
- *
- * 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 id, u8 on)
-{
- u32 usbphycfg;
-
- usbphycfg = readl(glue-usb_ctrl[id]);
-
- if (on) {
- usbphycfg = ~(USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN);
- usbphycfg |= USBPHY_OTGVDET_EN | USBPHY_OTGSESSEND_EN;
- } else {
- usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
- }
-
- writel(usbphycfg, glue-usb_ctrl[id]);
-}
/**
* dsps_musb_enable - enable interrupts
*/
@@ -494,16 +453,6 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
u8 id)
char res_name[11];
int ret;
- resources[0].start = dsps_control_module_phys[id];
- resources[0].end = resources[0].start + SZ_4 - 1;
- resources[0].flags = IORESOURCE_MEM;
-
- glue-usb_ctrl[id] = devm_ioremap_resource(pdev-dev, resources);
- if (IS_ERR(glue-usb_ctrl[id])) {
- ret = PTR_ERR(glue-usb_ctrl[id]);
- goto err0;
- }
-
/* first resource is for usbss, so start index from 1 */
res = platform_get_resource(pdev, IORESOURCE_MEM, id + 1);
if (!res) {
--
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/7] usb: musb: dsps: use usb-phy driver API for phy power on/off
use usb-phy driver API for powering on/off phy and removed
usage of the phy control access in platform glue driver.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/musb_dsps.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 0ecedb3..0096aad 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -36,6 +36,7 @@
#include linux/dma-mapping.h
#include linux/pm_runtime.h
#include linux/module.h
+#include linux/usb/phy.h
#include linux/platform_data/usb-omap.h
#include linux/sizes.h
@@ -432,7 +433,7 @@ static int dsps_musb_init(struct musb *musb)
dsps_writel(reg_base, wrp-control, (1 wrp-reset));
/* Start the on-chip PHY and its PLL. */
- musb_dsps_phy_control(glue, pdev-id, 1);
+ usb_phy_init(musb-xceiv);
musb-isr = dsps_interrupt;
@@ -459,10 +460,7 @@ static int dsps_musb_exit(struct musb *musb)
del_timer_sync(glue-timer[pdev-id]);
/* Shutdown the on-chip PHY and its PLL. */
- musb_dsps_phy_control(glue, pdev-id, 0);
-
- /* NOP driver needs change if supporting dual instance */
- usb_put_phy(musb-xceiv);
+ usb_phy_shutdown(musb-xceiv);
return 0;
}
@@ -690,10 +688,13 @@ static int dsps_suspend(struct device *dev)
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb;
int i;
- for (i = 0; i wrp-instances; i++)
- musb_dsps_phy_control(glue, i, 0);
+ for (i = 0; i wrp-instances; i++) {
+ musb = dev_get_drvdata(glue-musb[i]-dev);
+ usb_phy_set_suspend(musb-xceiv, 1);
+ }
return 0;
}
@@ -703,10 +704,13 @@ static int dsps_resume(struct device *dev)
struct platform_device *pdev = to_platform_device(dev-parent);
struct dsps_glue *glue = platform_get_drvdata(pdev);
const struct dsps_musb_wrapper *wrp = glue-wrp;
+ struct musb *musb;
int i;
- for (i = 0; i wrp-instances; i++)
- musb_dsps_phy_control(glue, i, 1);
+ for (i = 0; i wrp-instances; i++) {
+ musb = dev_get_drvdata(glue-musb[i]-dev);
+ usb_phy_set_suspend(musb-xceiv, 0);
+ }
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 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform
Adds usb-phy driver support for am33xx platform, the host/device
peripheral controller shall get this phy object to control the phy
operations.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/phy/Kconfig|9 ++
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/phy-dsps-usb.c | 236
3 files changed, 246 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/phy/phy-dsps-usb.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 372db48..b55c265 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -85,6 +85,15 @@ config OMAP_USB3
This driver interacts with the OMAP Control USB Driver to power
on/off the PHY.
+config DSPS_USB2PHY
+ tristate DSPS USB2 PHY Driver
+ depends on SOC_AM33XX
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ phy supports all LS/FS/HS speed and also supports OTG functionality.
+ The USB OTG controller communicates with this phy through stand UTMI
+ interface.
+
config SAMSUNG_USBPHY
tristate Samsung USB PHY Driver
help
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..0b16fb3 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_NOP_USB_XCEIV) += phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB) += phy-omap-control.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3)+= phy-omap-usb3.o
+obj-$(CONFIG_DSPS_USB2PHY) += phy-dsps-usb.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
obj-$(CONFIG_SAMSUNG_USB2PHY) += phy-samsung-usb2.o
obj-$(CONFIG_SAMSUNG_USB3PHY) += phy-samsung-usb3.o
diff --git a/drivers/usb/phy/phy-dsps-usb.c b/drivers/usb/phy/phy-dsps-usb.c
new file mode 100644
index 000..aae97b3
--- /dev/null
+++ b/drivers/usb/phy/phy-dsps-usb.c
@@ -0,0 +1,236 @@
+/*
+ * phy-dsps-usb.c - TI gs70 based usb phy driver used by usb controller
+ *
+ * Copyright (C) 2013 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.
+ *
+ * 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 linux/delay.h
+#include linux/usb/phy.h
+
+struct dsps_phy {
+ struct usb_phy phy;
+ struct device *dev;
+ struct platform_device *pdev;
+ void __iomem *phy_ctrl;
+ void __iomem *phy_wkup;
+ u8 is_suspended:1;
+ int id;
+};
+
+#define DSPS_USBPHY_CM_PWRDN (1 0)
+#define DSPS_USBPHY_OTG_PWRDN (1 1)
+#define DSPS_USBPHY_OTGVDET_EN (1 19)
+#define DSPS_USBPHY_OTGSESSEND_EN (1 20)
+#define DSPS_USB0_WKUP_CTRL_ENABLE (1 0)
+#define DSPS_USB1_WKUP_CTRL_ENABLE (1 8)
+#define phy_to_dspsphy(x) container_of((x), struct dsps_phy, phy)
+
+static void dsps_usbphy_power(struct usb_phy *phy, bool is_on)
+{
+ struct dsps_phy *dsps_phy = phy_to_dspsphy(phy);
+ u32 val;
+
+ val = readl(dsps_phy-phy_ctrl);
+
+ if (is_on) {
+ val = ~(DSPS_USBPHY_CM_PWRDN | DSPS_USBPHY_OTG_PWRDN);
+ val |= DSPS_USBPHY_OTGVDET_EN |
+ DSPS_USBPHY_OTGSESSEND_EN;
+ } else
+ val |= DSPS_USBPHY_CM_PWRDN | DSPS_USBPHY_OTG_PWRDN;
+
+ writel(val, dsps_phy-phy_ctrl);
+}
+
+static void dsps_usbphy_wakeup(struct usb_phy *phy, bool enable)
+{
+ struct dsps_phy *dsps_phy = phy_to_dspsphy(phy);
+ int id = dsps_phy-id;
+ u32 val, wkup_flag;
+
+ val = readl(dsps_phy-phy_wkup);
+ wkup_flag = id ? DSPS_USB1_WKUP_CTRL_ENABLE :
+ DSPS_USB0_WKUP_CTRL_ENABLE;
+
+ if (enable)
+ val |= wkup_flag;
+ else
+ val = ~wkup_flag;
+
+ writel(val, dsps_phy-phy_wkup);
+}
+
+static int dsps_usbphy_suspend(struct usb_phy *x, int suspend)
+{
+ struct dsps_phy *dsps_phy = phy_to_dspsphy(x);
+
+ if (suspend) {
+ if (!pm_runtime_suspended(dsps_phy-pdev-dev))
+ pm_runtime_put(dsps_phy-pdev-dev);
+ } else if (!suspend)
+ pm_runtime_get(dsps_phy-pdev-dev);
+
+ return 0;
+}
+
+static int
[PATCH v2 1/7] usb: musb: dsps: enable dual instance support for am33xx platform
The dsps am33xx platform has two instances of musb controller,
enable the support for dual musb instances
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/musb/musb_dsps.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 3a18e44..590dd0b 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -746,7 +746,7 @@ static const struct dsps_musb_wrapper ti81xx_driver_data = {
.rxep_bitmap= (0xfffe 16),
.musb_core_offset = 0x400,
.poll_seconds = 2,
- .instances = 1,
+ .instances = 2,
};
static const struct platform_device_id musb_dsps_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 v2 5/7] usb: musb: dsps: use get-usb-phy by phandle for multi instance
In case of mutli instance support, use get-phy object using phandle to return to repsective phy xceiv object for each instance Signed-off-by: Ravi Babu ravib...@ti.com --- drivers/usb/musb/musb_dsps.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 0096aad..0d8581b 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -416,7 +416,11 @@ static int dsps_musb_init(struct musb *musb) musb-mregs += wrp-musb_core_offset; /* NOP driver needs change if supporting dual instance */ - musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + if (dev-parent-of_node) + musb-xceiv = devm_usb_get_phy_by_phandle(dev-parent, + usb-phy, pdev-id); + else + musb-xceiv = devm_usb_get_phy_dev(dev, pdev-id); if (IS_ERR_OR_NULL(musb-xceiv)) return -EPROBE_DEFER; -- 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 0/7] adding dual instance and usb-phy support for am335x platform
This patch set series - adds dual musb instances support for am335x platform - adds phy-dsps-usb driver based on TI's gs70 driver - adds DT bindings for am33xx usb-phy - removed references to usb-nop-xceiv from musb has been verified on tree [1] [1] git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git changes from v1: - includes sergei's felipe comments - retain the nop-phy driver API usage for non-DT davinci other musb platform Ravi Babu (7): usb: musb: dsps: enable dual instance support for am33xx platform usb: phy: dsps: adding usbphy driver for am33xx platform usb: musb: dsps: remove nop_xceiv_(un)register APIs from dsps glue usb: musb: dsps: use usb-phy driver API for phy power on/off usb: musb: dsps: use get-usb-phy by phandle for multi instance usb: phy: dts: Adding usbphy DT bindings for am33xx usb: musb: dsp: remove the usb-phy control acess from platform glue arch/arm/boot/dts/am33xx.dtsi | 17 +++ drivers/usb/musb/musb_dsps.c | 85 +++--- drivers/usb/phy/Kconfig|9 ++ drivers/usb/phy/Makefile |1 + drivers/usb/phy/phy-dsps-usb.c | 236 5 files changed, 282 insertions(+), 66 deletions(-) create mode 100644 drivers/usb/phy/phy-dsps-usb.c -- 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 v9 resend 0/3] Add USB support to R8A7778/BOCK-W
On Sun, Jun 09, 2013 at 12:32:34AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130607' tag, and the R8A7779/Marzen USB patchset I've posted. It was created to add support of R8A7778/BOCK-W USB to the platform code and the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees. [1/3] phy-rcar-usb: add R8A7778 support [2/3] ARM: shmobile: r8a7778: add USB support [3/3] ARM: shmobile: BOCK-W: add USB support The patchset is completely ready for merging now. Thanks, I have queued this up in the soc2 phy-rcar-usb. My current plan is to let that branch sit in next for a few days and then send a pull-request for it to be included in v3.11. -- 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 v8 0/9] Reorganize R8A7779/Marzen USB code
On Fri, Jun 07, 2013 at 02:45:45PM +0400, Sergei Shtylyov wrote: Hello. On 07-06-2013 12:06, Simon Horman wrote: Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130528' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer [4/9] phy-rcar-usb: remove EHCI internal buffer setup [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource [6/9] phy-rcar-usb: correct base address [7/9] phy-rcar-usb: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] phy-rcar-usb: handle platform data The patchset is completely ready to be merged now. Can I confirm that the plan is for me to merge this code? Yes, that was the plan. If so, I should be able to do so next week. Thanks, I have queued this up in the soc2 phy-rcar-usb. My current plan is to let that branch sit in next for a few days and then send a pull-request for it to be included in v3.11. -- 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 v8 0/9] Reorganize R8A7779/Marzen USB code
On Tue, Jun 11, 2013 at 04:49:43PM +0900, Simon Horman wrote: On Fri, Jun 07, 2013 at 02:45:45PM +0400, Sergei Shtylyov wrote: Hello. On 07-06-2013 12:06, Simon Horman wrote: Here's the set of 9 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130528' tag. It was created to fix the shortcomings in the R8A7779/Marzen USB platform code and R8A7779 USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/ subtrees (some patches have to touch both subtrees). The patches were conceived with the complete bisectability goal in mind. [1/9] ARM: shmobile: Marzen: move USB EHCI, OHCI, and PHY devices to R8A7779 code [2/9] ehci-platform: add pre_setup() method to platform data [3/9] ARM: shmobile: r8a7779: setup EHCI internal buffer [4/9] phy-rcar-usb: remove EHCI internal buffer setup [5/9] ARM: shmobile: r8a7779: remove USB PHY 2nd memory resource [6/9] phy-rcar-usb: correct base address [7/9] phy-rcar-usb: add platform data [8/9] ARM: shmobile: Marzen: pass platform data to USB PHY device [9/9] phy-rcar-usb: handle platform data The patchset is completely ready to be merged now. Can I confirm that the plan is for me to merge this code? Yes, that was the plan. If so, I should be able to do so next week. Thanks, I have queued this up in the soc2 phy-rcar-usb. s/soc2 phy-rcar-usb/phy-rcar-usb branch/ My current plan is to let that branch sit in next for a few days and then send a pull-request for it to be included in v3.11. -- To unsubscribe from this list: send the line unsubscribe linux-sh 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 v9 resend 0/3] Add USB support to R8A7778/BOCK-W
On Tue, Jun 11, 2013 at 04:49:59PM +0900, Simon Horman wrote: On Sun, Jun 09, 2013 at 12:32:34AM +0400, Sergei Shtylyov wrote: Hello. Here's the set of 3 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130607' tag, and the R8A7779/Marzen USB patchset I've posted. It was created to add support of R8A7778/BOCK-W USB to the platform code and the USB common PHY driver, and so spans both arch/arm/mach-shmobile/ and drivers/usb/phy/ subtrees. [1/3] phy-rcar-usb: add R8A7778 support [2/3] ARM: shmobile: r8a7778: add USB support [3/3] ARM: shmobile: BOCK-W: add USB support The patchset is completely ready for merging now. Thanks, I have queued this up in the soc2 phy-rcar-usb. s/soc2 phy-rcar-usb/phy-rcar-usb branch/ My current plan is to let that branch sit in next for a few days and then send a pull-request for it to be included in v3.11. -- To unsubscribe from this list: send the line unsubscribe linux-sh 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: Fwd: Fwd: request some hep for usb comminucation
Hi i install windowx XP and Ubuntu in vmware and install a USBlizer (trial) in host windows (win 7 64 bit). next snooping a message between an application and device. and send a same data from ubuntu to device. but device dosent responce. What reason might be that the device does not respond? thanks a lot Mahdi Razavi 2013/6/10 Greg KH gre...@linuxfoundation.org: On Mon, Jun 10, 2013 at 10:25:26AM +0430, Mahdi Razavi wrote: Hi This is a Digital Radio which can report some data through USB to its application. The output of lsudb : Bus 002 Device 004: ID 238b:0a31 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class Ick, a vendor-specific device :( bDeviceSubClass 254 bDeviceProtocol 254 bMaxPacketSize0 8 idVendor 0x238b idProduct 0x0a31 bcdDevice0.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower4mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 255 -- output od dmesg: [26785.637159] usb 2-2.1: new full-speed USB device number 11 using uhci_hcd [26785.748010] usb 2-2.1: config 1 has an invalid interface number: 2 but max is 0 [26785.748018] usb 2-2.1: config 1 has no interface number 0 [26785.759058] usb 2-2.1: New USB device found, idVendor=238b, idProduct=0a31 [26785.759064] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [26785.759069] usb 2-2.1: Product: Digital Radio [26785.759073] usb 2-2.1: Manufacturer: RIGOL Communications this device has a SDK for developing in windows but there isnt any in Linux. i know protocol specification of message, and try sniffing on windows verify protocol. but when send a same data in Linux(with pyusb) to device dosent response. i guess there is a initial handshake in driver layer between device and OS. There really shouldn't be, but you might want to run Windows under kvm or vmware and snoop the data that way on the Linux side to determine the whole protocol being used. Good luck, greg k-h -- Best Regards M.Razavi -- 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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tue, Jun 11, 2013 at 3:18 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 13:40:20 Ming Lei wrote: On Tue, Jun 11, 2013 at 1:36 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 10 Jun 2013, Ming Lei wrote: If complete() callback runs in one tasklet context, spin_lock() inside complete() is enough, just like hard irq, the tasklet itself is disabled during complete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources between complete(). We also have exclusion between complete() and other contexts, i.e. timers. The patch also converts the complete() called in timers to tasklet context too. So could you let me know if that eases your concern? If not, could you explain your concern about other contexts in a bit detail? When the lock is to protect shared resources between complete() and non-IRQ context, currently spin_lock_irqsave() is used in non-IRQ context, which is enough to prevent tasklet from being run on the CPU, so no problem for this situation too. When all HCDs support to run URB giveback in tasklet context, we can change all spin_lock_irq*() to spin_lock() in drivers URB-complete(), and in other places, the spin_lock_irq*() can be changed to spin_lock_bh(). Even now we cannot guarantee that all calls to complete() are in irq. There is the case of HCD hotunplug and other cases, like timeouts. They will have to be verified. All URBs are completed via usb_hcd_giveback_urb(), so there should be no differences between these cases and the common one about introducing the patchset. 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: Linux USB file storage gadget with new UDC
Hi, The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the Device Descriptor Test - Addressed State. The test just failed after Get Configuration request. I can't tell what's wrong. You will have to use a USB bus analyzer. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Thanks, Victor [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc134 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 12 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc134 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x6d903ceb 4: 0x736f646b 8: 0x7366 c: 0x10402 len_num 3072, iter_num 2 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x6f007442 4: 0x7000 8: 0xf00 c: 0xc100 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete -- 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 12 00 00 00 00 00 00 00 00 [start_transfer] 53425355 12 ept1 in queue len 0xd, buffer 0xc0c5c000 0: 0x53425355 4: 0x12 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc134 before kagen2_ep_queue g_file_storage gadget: disconnect or port reset after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 12 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 12 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096 g_file_storage gadget: after calling do_scsi_command handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: reset config g_file_storage gadget: reset interface g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: in fsg-running loop g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 40 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: disconnect or port reset handle_exception begin handle_exception wait until handle_exception old_state 5 g_file_storage gadget: in handle_exception loop g_file_storage gadget: in fsg-running loop USB_RECIP_DEVICE function address is 0x5d exit A g_file_storage gadget: ep0-setup, length 8: : 80 06 00 01 00 00 12 00 g_file_storage gadget: get device descriptor ept0 in queue len 0x12, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 18: : 12 01 00 02 00 00 00 40 25 05 a5 a4 33 03 01 02 0010: 00 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 06 00 00 0a 00 g_file_storage gadget: get device qualifier ept0 in queue len 0xa, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 10: : 0a 06 00 02 00 00 00 40 01 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 09 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x9, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 9: : 09 02 20 00 01 01 04 c0 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 02 00 00 20 00 g_file_storage gadget: get configuration descriptor ept0 in queue len 0x20, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 32: : 09 02 20 00 01 01 04 c0 01 09 04 00 00 02 08 06 0010: 50 05 07 05 81 02 00 02 00 07 05 01 02 00 02 01 g_file_storage gadget: ep0-setup, length 8: : 80 06 00 03 00 00 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x4, buffer 0xc128b800 ep0_complete g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadget: ep0-setup,
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tue, Jun 11, 2013 at 4:54 AM, Steven Rostedt rost...@goodmis.org wrote: On Mon, 2013-06-10 at 16:47 -0400, Alan Stern wrote: On Mon, 10 Jun 2013, Steven Rostedt wrote: and why so many drivers are using tasklet/softirq? Because it's easy to set up and device driver authors don't know any better ;-). Note, a lot of drivers are now using work queues today, which run as a task. Yes, there's a little more overhead with a task than for a softirq, but the problem with softirqs and tasklets is that they can't be preempted, and they are more important than all tasks on the system. If you have a task that is critical, it must yield for your softirq. Almost! That is, even if you have a softirq, it may not run in irq context at all. If you get too many softirqs at a time (one comes while another one is running), it will defer the processing to the ksoftirq thread. This not only runs as a task, but also runs as SCHED_OTHER, and must yield to other tasks like everyone else too. Thus, adding it as a softirq does not guarantee that it will be processed quickly. It just means that most of the time it will prevent anything else from happening while your most important handler in the world is running. From this, it sounds like you generally advise using threaded interrupt handlers rather than tasklets/softirqs. Yes, there's plenty of benefits for them, and I highly doubt that any USB device would even notice the difference between a softirq and a thread for response time latencies. Steven, thanks for your input. IMO, about the problem, the most important point between threaded interrupt handler and tasklet is the latency. For USB video/audio application, the data need to be handled very quickly. Also new transfer need to be scheduled without much latency. I am wondering if interrupt thread handler can respond quickly enough if there is high load on CPUs. For USB mass storage driver, it still need to be handled quickly. If tasklet is taken, tasklet_schedule() is always called from hard interrupt context, so most of time the latency should be better than interrupt thread handler latency since tasklet handler is called just after irq handler exits in the situation. Also we can avoid to do tasklet_schedule when the tasklet is being handled. I will compare, collect and post out some latency data later for the sake of choosing which one to handle URB giveback. 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: [PATCH v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform
Hi,
On Tuesday 11 June 2013 12:47 PM, Ravi Babu wrote:
Adds usb-phy driver support for am33xx platform, the host/device
peripheral controller shall get this phy object to control the phy
operations.
Signed-off-by: Ravi Babu ravib...@ti.com
---
drivers/usb/phy/Kconfig|9 ++
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/phy-dsps-usb.c | 236
3 files changed, 246 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/phy/phy-dsps-usb.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 372db48..b55c265 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -85,6 +85,15 @@ config OMAP_USB3
This driver interacts with the OMAP Control USB Driver to power
on/off the PHY.
+config DSPS_USB2PHY
+ tristate DSPS USB2 PHY Driver
+ depends on SOC_AM33XX
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ phy supports all LS/FS/HS speed and also supports OTG functionality.
+ The USB OTG controller communicates with this phy through stand UTMI
+ interface.
+
config SAMSUNG_USBPHY
tristate Samsung USB PHY Driver
help
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 33863c0..0b16fb3 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_NOP_USB_XCEIV) += phy-nop.o
obj-$(CONFIG_OMAP_CONTROL_USB)+= phy-omap-control.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_OMAP_USB3) += phy-omap-usb3.o
+obj-$(CONFIG_DSPS_USB2PHY) += phy-dsps-usb.o
obj-$(CONFIG_SAMSUNG_USBPHY) += phy-samsung-usb.o
obj-$(CONFIG_SAMSUNG_USB2PHY) += phy-samsung-usb2.o
obj-$(CONFIG_SAMSUNG_USB3PHY) += phy-samsung-usb3.o
diff --git a/drivers/usb/phy/phy-dsps-usb.c b/drivers/usb/phy/phy-dsps-usb.c
new file mode 100644
index 000..aae97b3
--- /dev/null
+++ b/drivers/usb/phy/phy-dsps-usb.c
@@ -0,0 +1,236 @@
+/*
+ * phy-dsps-usb.c - TI gs70 based usb phy driver used by usb controller
+ *
+ * Copyright (C) 2013 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.
+ *
+ * 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 linux/delay.h
+#include linux/usb/phy.h
+
+struct dsps_phy {
+ struct usb_phy phy;
+ struct device *dev;
+ struct platform_device *pdev;
+ void __iomem *phy_ctrl;
+ void __iomem *phy_wkup;
+ u8 is_suspended:1;
+ int id;
+};
+
+#define DSPS_USBPHY_CM_PWRDN (1 0)
+#define DSPS_USBPHY_OTG_PWRDN (1 1)
+#define DSPS_USBPHY_OTGVDET_EN (1 19)
+#define DSPS_USBPHY_OTGSESSEND_EN (1 20)
+#define DSPS_USB0_WKUP_CTRL_ENABLE (1 0)
+#define DSPS_USB1_WKUP_CTRL_ENABLE (1 8)
+#define phy_to_dspsphy(x) container_of((x), struct dsps_phy, phy)
+
+static void dsps_usbphy_power(struct usb_phy *phy, bool is_on)
+{
+ struct dsps_phy *dsps_phy = phy_to_dspsphy(phy);
+ u32 val;
+
+ val = readl(dsps_phy-phy_ctrl);
+
+ if (is_on) {
+ val = ~(DSPS_USBPHY_CM_PWRDN | DSPS_USBPHY_OTG_PWRDN);
+ val |= DSPS_USBPHY_OTGVDET_EN |
+ DSPS_USBPHY_OTGSESSEND_EN;
+ } else
+ val |= DSPS_USBPHY_CM_PWRDN | DSPS_USBPHY_OTG_PWRDN;
+
+ writel(val, dsps_phy-phy_ctrl);
+}
+
+static void dsps_usbphy_wakeup(struct usb_phy *phy, bool enable)
+{
Where is this function called from?
+ struct dsps_phy *dsps_phy = phy_to_dspsphy(phy);
+ int id = dsps_phy-id;
+ u32 val, wkup_flag;
+
+ val = readl(dsps_phy-phy_wkup);
+ wkup_flag = id ? DSPS_USB1_WKUP_CTRL_ENABLE :
+ DSPS_USB0_WKUP_CTRL_ENABLE;
+
+ if (enable)
+ val |= wkup_flag;
+ else
+ val = ~wkup_flag;
+
+ writel(val, dsps_phy-phy_wkup);
+}
+
+static int dsps_usbphy_suspend(struct usb_phy *x, int suspend)
+{
+ struct dsps_phy *dsps_phy = phy_to_dspsphy(x);
+
+ if (suspend) {
+ if (!pm_runtime_suspended(dsps_phy-pdev-dev))
+ pm_runtime_put(dsps_phy-pdev-dev);
+ }
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tuesday 11 June 2013 16:14:25 Ming Lei wrote: On Tue, Jun 11, 2013 at 3:18 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 13:40:20 Ming Lei wrote: On Tue, Jun 11, 2013 at 1:36 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 10 Jun 2013, Ming Lei wrote: If complete() callback runs in one tasklet context, spin_lock() inside complete() is enough, just like hard irq, the tasklet itself is disabled during complete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources between complete(). We also have exclusion between complete() and other contexts, i.e. timers. The patch also converts the complete() called in timers to tasklet context too. So could you let me know if that eases your concern? If not, could you explain your concern about other contexts in a bit detail? The driver itself may have submitted a timer and race against it. What locking do you need in complete() and a timer to lock against each other? Even now we cannot guarantee that all calls to complete() are in irq. There is the case of HCD hotunplug and other cases, like timeouts. They will have to be verified. All URBs are completed via usb_hcd_giveback_urb(), so there should be no differences between these cases and the common one about introducing the patchset. But it makes no sense to go to a tasklet when you are already in task context. In those cases you need to do something, essentially blocking the tasklet. 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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tue, Jun 11, 2013 at 4:49 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 16:14:25 Ming Lei wrote: On Tue, Jun 11, 2013 at 3:18 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 13:40:20 Ming Lei wrote: On Tue, Jun 11, 2013 at 1:36 AM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 10 Jun 2013, Ming Lei wrote: If complete() callback runs in one tasklet context, spin_lock() inside complete() is enough, just like hard irq, the tasklet itself is disabled during complete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources between complete(). We also have exclusion between complete() and other contexts, i.e. timers. The patch also converts the complete() called in timers to tasklet context too. So could you let me know if that eases your concern? If not, could you explain your concern about other contexts in a bit detail? The driver itself may have submitted a timer and race against it. What locking do you need in complete() and a timer to lock against each other? Good catch. The problem will come if only spin_lock() is called inside complete(), I will check main USB drivers in tree to see if there is such use case. Even now we cannot guarantee that all calls to complete() are in irq. There is the case of HCD hotunplug and other cases, like timeouts. They will have to be verified. All URBs are completed via usb_hcd_giveback_urb(), so there should be no differences between these cases and the common one about introducing the patchset. But it makes no sense to go to a tasklet when you are already in task context. In those cases you need to do something, essentially blocking the tasklet. At least now, always doing complete() in tasklet handler can simplify implementation since these cases aren't in hot path. 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: [PATCH 05/39] ARM: ux500: Stop passing MMC's platform data for Device Tree boots
On Mon, Jun 10, 2013 at 11:15 AM, Lee Jones lee.jo...@linaro.org wrote: On Wed, 15 May 2013, Linus Walleij wrote: On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: It was required to pass DMA channel configuration information to the MMC driver before the new DMA API was in place. Now that it is, and is fully compatible with Device Tree we can stop doing that. Reviewed-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org So since the use of dma_request_slave_channel() is not upstream, I guess this will break DMA use (i.e slow down transfers!) on all device tree boots? I'd be happy to apply it once the MMCI patch is in linux-next indicating there may just be a window in the merge period where it falls back to IRQ mode, but I don't want to disable DMA on DT boots for an entire kernel cycle just like that. Not applied as of yet. I believe it's now okay to apply this. Yep, I've rebased and applied it to the ux500-devicetree branch. I have some stuff on this branch which is queued up but may miss v3.11, because I need the 5 outstanding pull requests to land in ARM SoC so I get a merge base there before I can send any more stuff. It's mainly because this stuff isn't any orthogonal, everything just conflicts in the AUXDATA all the time. Yours, Linus Walleij -- 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: Serial ports for Septentrio USB GNSS receiver
On 10.06.2013 20:19, Bjørn Mork wrote: The cdc-acm driver cannot handle those ports, but a more forgiving generic driver can. I don't recommend it for normal use because it abuses the option driver, but Ben could do a simple test like this: echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue modprobe option echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id Unless I missed something, this should result in two /dev/ttyUSBx serial devices. Before plugging in the receiver, there's ttyUSB0 and ttyUSB1 from another usb/serial converter device that I can't remove. After plugging in, dmesg says: usb 3-2: new full-speed USB device number 2 using uhci_hcd usb 3-2: New USB device found, idVendor=152a, idProduct=8230 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: Septentrio USB Device usb 3-2: Manufacturer: Septentrio cdc_acm 3-2:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters and ttyACM0 appears. # echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue usbcore: registered new interface driver cdc_ether usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_host usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_wlan ttyACM0 is gone and no new ttyUSB* appear. # modprobe option usbcore: registered new interface driver option usbserial: USB Serial support registered for GSM modem (1-port) # echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id option 3-2:2.0: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB2 option 3-2:2.1: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB3 option 3-2:2.2: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB4 option 3-2:2.3: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB5 ttyUSB2 is dead ttyUSB3 works and is connected to a port named USB1 on the receiver ttyUSB4 is dead ttyUSB5 works and is connected to a port named USB2 on the receiver usb-devices now shows: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 P: Vendor=152a ProdID=8230 Rev=01.10 S: Manufacturer=Septentrio S: Product=Septentrio USB Device C: #Ifs= 4 Cfg#= 2 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I guess this device is worth a new serial driver of its own in case that works? Or should we create a generic driver for 02/02/ff serial devices (using the inverse of the logic in drivers/net/usb/cdc_ether.c: usbnet_generic_cdc_bind to avoid RNDIS devices)? A few modems with such ports have been added to option, but a generic solution might be better. I obviously don't know, but would be very happy to supply further information! thanks, ben -- Ben Adler Universität Hamburg MIN-Fakultät FB Informatik, AB TAMS Vogt-Kölln-Strasse 30 22527 Hamburg Tel +49 40 42883 2504 Fax +49 40 42883 2397 Mob +49 160 858 0660 -- 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 06/39] ARM: ux500: Move SDI (MMC) and UART devices under more descriptive heading
On Mon, Jun 10, 2013 at 11:17 AM, Lee Jones lee.jo...@linaro.org wrote: On Wed, 15 May 2013, Linus Walleij wrote: On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote: Now DMA DT bindings exist and are in use by he MMC and UART drivers, it should be possible to remove them from the auxdata structure. However, after doing so the drivers fail. Common clk is still reliant on the dev_name() call to do device name matching, which will fail due to the fact that Device Tree naming differs somewhat do the more traditional conventions. Reviewed-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Lee Jones lee.jo...@linaro.org Cannot be applied due to dependency on 5/39. I think this can be applied now (if it hasn't already). I really need a clean mergebase for this to merge ... This patch requires both the dma40 and devicetree branches to land in a common place before it can be applied. I want the DMA40 branch to be closed down now as I have sent all pull requests on it, so pls ping me again on this when we have something in the ARM SoC tree we can work on. Yours, Linus Walleij -- 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] qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820
From: Bjørn Mork bj...@mork.no Date: Thu, 6 Jun 2013 12:57:02 +0200 Another QMI speaking Qualcomm based device, which should be driven by qmi_wwan, while cdc_ether should ignore it. ... Reported-by: Graham Inggs graham.in...@uct.ac.za Signed-off-by: Bjørn Mork bj...@mork.no Applied, thanks. -- 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 v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform
Kishon Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Balbi, Felipe Subject: Re: [PATCH v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform + +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_wkup); +phy-phy_wkup = ioremap(res-start, resource_size(res)); devm_ioremap? The phy_wakeup register is common across two instances of phy, devm_ioremap_resource() will fail to map for twice for same register space. +if (IS_ERR(phy-phy_wkup)) +return PTR_ERR(phy-phy_wkup); + +if (np) +of_property_read_u32(np, id, phy-id); Is this property documented somewhere? Not it is not documented. + +phy-phy.dev= phy-dev; +phy-phy.label = dsps-usbphy; +dsps_usbphy_power(dsps_phy-phy, 0); +dsps_phy-is_suspended = 1; Are you using this is_suspended anywhere else? Currently not used. -- Ravi B -- 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/2] usb: chipidea: fixes for v3.10-rc5
Hi, Here are two fixes for v3.10-rc5, one of them is also applicable for -stable. Alexander Shishkin (2): usb: chipidea: fix no transceiver case usb: chipidea: fix id change handling drivers/usb/chipidea/core.c |3 ++- drivers/usb/chipidea/udc.c | 13 - 2 files changed, 10 insertions(+), 6 deletions(-) -- 1.7.10.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 2/2] usb: chipidea: fix id change handling
Re-enable chipidea irq even if there's no role changing to do. This is a problem since b183c19f (USB: chipidea: re-order irq handling to avoid unhandled irqs); when it manifests, chipidea irq gets disabled for good. Cc: sta...@vger.kernel.org # v3.7 Signed-off-by: Alexander Shishkin alexander.shish...@linux.intel.com --- drivers/usb/chipidea/core.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 49b098b..475c9c1 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -276,8 +276,9 @@ static void ci_role_work(struct work_struct *work) ci_role_stop(ci); ci_role_start(ci, role); - enable_irq(ci-irq); } + + enable_irq(ci-irq); } static irqreturn_t ci_irq(int irq, void *data) -- 1.7.10.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: serial/ftdi_sio byte loss / performance regression
On Mon, Jun 10, 2013 at 02:39:06PM -0700, Greg KH wrote: On Thu, Jun 06, 2013 at 11:21:54AM -0700, Greg KH wrote: On Thu, Jun 06, 2013 at 11:58:56AM +0200, Johan Hovold wrote: Greg, perhaps we should consider backporting the wait-until-sent patches (i.e. 0693196fe..4746b6c6e)? Yes, that's a good idea, I'll do that for the next round of stable updates, after this next release tomorrow. I applied these, plus a few others in order to get them all to apply and build properly. But the last patch, 4746b6c6e, didn't apply, and I don't think we really need it for the 3.9 kernel, do we? No, you're right. It's merely a clean up and slight optimisation as no chars_in_buffer needs the disconnect mutex after the other changes. Not sure why it wouldn't apply, though. I was a bit sloppy when I gave the commit refs above -- it should have been 0693196^..b16634a More specifically: 4746b6c USB: serial: clean up chars_in_buffer This one is not strictly necessary, but should apply to v3.9. ff93b19 USB: ti_usb_3410_5052: fix chars_in_buffer overhead This should not be applied to v3.9 as the problem it fixes wasn't introduced until v3.10-rc1. It seems you had to add two other patches to get this one to apply. They should be dropped as well. b16634a USB: io_ti: fix chars_in_buffer overhead Needed in 3.9. a37025b USB: ftdi_sio: fix chars_in_buffer overhead c413364 USB: ftdi_sio: clean up get_modem_status dcf0105 USB: serial: add generic wait_until_sent implementation These three are also needed in 3.9 (and also 3.8). 0693196 USB: serial: add wait_until_sent operation Needed in 3.9 (and 3.8). (You noticed my refspec did not include it and added it.) Sorry about the confusion. Johan -- 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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tuesday 11 June 2013 17:27:28 Ming Lei wrote: On Tue, Jun 11, 2013 at 4:49 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 16:14:25 Ming Lei wrote: The driver itself may have submitted a timer and race against it. What locking do you need in complete() and a timer to lock against each other? Good catch. The problem will come if only spin_lock() is called inside complete(), I will check main USB drivers in tree to see if there is such use case. All network drivers race against timeout. I think they just unlink the URB, but there's a lot of them. But it makes no sense to go to a tasklet when you are already in task context. In those cases you need to do something, essentially blocking the tasklet. At least now, always doing complete() in tasklet handler can simplify implementation since these cases aren't in hot path. Well, I am afraid this is not simply the case. These cases are partially synchronous. For example you need to make sure all calls to complete() are finished before you disconnect a HCD itself. The same applies to a device being disconnected. It the same area, what happens if an URB is unlinked between the irq handler and the tasklet? 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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tue, Jun 11, 2013 at 6:51 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 17:27:28 Ming Lei wrote: On Tue, Jun 11, 2013 at 4:49 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 16:14:25 Ming Lei wrote: The driver itself may have submitted a timer and race against it. What locking do you need in complete() and a timer to lock against each other? Good catch. The problem will come if only spin_lock() is called inside complete(), I will check main USB drivers in tree to see if there is such use case. All network drivers race against timeout. I think they just unlink the URB, but there's a lot of them. usbnet is fine since no spin_lock() is used in complete() and the same lock is acquired in timer handler. As far as I think of, the problem only exists in the below situation: complete(): spin_lock(A) ... spin_unlock(A) timer handler(): spin_lock(A) spin_unlock(A) And we need to replace spin_lock() in complete() with spin_lock_irqsave() if the change is going to be introduced. But it makes no sense to go to a tasklet when you are already in task context. In those cases you need to do something, essentially blocking the tasklet. At least now, always doing complete() in tasklet handler can simplify implementation since these cases aren't in hot path. Well, I am afraid this is not simply the case. These cases are partially synchronous. For example you need to make sure all calls to complete() are finished before you disconnect a HCD itself. The same applies to a device being disconnected. That is fine since the coming giveback() in tasklet context will drop the URB's reference count(urb-use_count) finally if the scheduled tasklet can't be dropped. (looks tasklet schedule can make sure that) It the same area, what happens if an URB is unlinked between the irq handler and the tasklet? The unlink will return failure since the URB isn't in queue of ep-urb_list. 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: Linux USB file storage gadget with new UDC
On Tue, 11 Jun 2013, victor yeo wrote: Hi, The hardware handles Set Address request, and i can see the address of the USB gadget being shown in Windows host. Here i attach the gadget driver log for the Device Descriptor Test - Addressed State. The test just failed after Get Configuration request. I can't tell what's wrong. You will have to use a USB bus analyzer. Another possibility is to set up a virtual Windows system inside your Linux host. Then try running the USB CV program on the virtual machine, and use usbmon on the host system to capture the USB traffic. I don't know if that will work, but it might. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Perhaps you will recognize this answer (I have sent it several times before): I can't tell what is happening without seeing _both_ the log file on the gadget _and_ the usbmon trace on the host. 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: Linux USB file storage gadget with new UDC
Hi, Another possibility is to set up a virtual Windows system inside your Linux host. Then try running the USB CV program on the virtual machine, and use usbmon on the host system to capture the USB traffic. I don't know if that will work, but it might. Thanks. i will find a way to setup the virtual Windows inside Linux host. Ok. Today i tested the same mass storage gadget driver on Lenovo x100e Ubuntu. There is a strange problem. After SCSI_READ_10 command data is returned to the Ubuntu host. The gadget driver says: g_file_storage gadget: reset config g_file_storage gadget: reset interface Then the same process to get descriptors and receive SCSI commands are repeated. Is the SCSI_READ_10 command or something else causing the problem? Please see the attached gadget driver log. Perhaps you will recognize this answer (I have sent it several times before): I can't tell what is happening without seeing _both_ the log file on the gadget _and_ the usbmon trace on the host. Alan Stern Yes, the matching gadget log and usbmon trace are attached in this email. From the usbmon trace, the error (-108) is ESHUTDOWN from SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10 command is received twice. First time it is ok, second time it causes some problem. Which side could cause the ESHUTDOWN error? Thanks, victor [start_transfer] 43425355 35 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 36 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 36 00 00 00 12 00 00 00 80 00 06 03 0010: 00 00 00 12 00 00 00 00 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: REQUEST SENSE; Dc=6, Di=18; Hc=6, Hi=18 g_file_storage gadget: bulk-in, length 18: : 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 0010: 00 00 [start_transfer] 60070 a00 ept1 in queue len 0x12, buffer 0xc0c44000 0: 0x60070 4: 0xa00 8: 0x0 c: 0x29 bulk_in_complete -- 0, 18/18 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 36 00 00 00 00 00 00 00 00 [start_transfer] 53425355 36 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x36 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 60070 a00 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 37 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 37 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 18 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 12288 - 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc0c44000 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3072, iter_num 2 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete -- 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 37 00 00 00 00 00 00 00 00 [start_transfer] 53425355 37 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x37 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc0c44000 before kagen2_ep_queue after kagen2_ep_queue kagen2_ep_queue 31 512 31 [kagen2_ep_queue] 43425355 38 g_file_storage gadget: bulk-out, length 31: : 55 53 42 43 38 00 00 00 00 10 00 00 80 00 0a 28 0010: 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=4096; Hc=10, Hi=4096 g_file_storage gadget-lun0: file read 4096 @ 0 - 4096 [start_transfer] 0 0 ept1 in queue len 0x1000, buffer 0xc0c44000 len_num 4096, iter_num 0 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 3584, iter_num 1 0: 0x6d903ceb 4: 0x736f646b 8: 0x7366 c: 0x10402 len_num 3072, iter_num 2 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 2560, iter_num 3 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 2048, iter_num 4 0: 0xf8 4: 0xfff0 8: 0x0 c: 0x0 len_num 1536, iter_num 5 0: 0x0 4: 0x0 8: 0x0 c: 0x0 len_num 1024, iter_num 6 0: 0x6f007442 4: 0x7000 8: 0xf00 c: 0xc100 len_num 512, iter_num 7 0: 0x0 4: 0x0 8: 0x0 c: 0x0 bulk_in_complete -- 0, 4096/4096 g_file_storage gadget: before calling send_status g_file_storage gadget: bulk-in, length 13: : 55 53 42 53 38 00 00 00 00 00 00 00 00 [start_transfer] 53425355 38 ept1 in queue len 0xd, buffer 0xc1338000 0: 0x53425355 4: 0x38 8: 0x0 bulk_in_complete -- 0, 13/13 [start_transfer] 0 0 ept1 out queue len 0x200, buffer 0xc0c44000
[PATCH] usb: wire adapter: add scatter gather support
This patch adds support for scatter gather DMA to the wire adapter and
updates the HWA to advertise support for SG transfers. This allows the
block layer to submit transfer requests to the HWA HC without first
breaking them up into PAGE_SIZE requests.
Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com
diff --git a/drivers/usb/host/hwa-hc.c b/drivers/usb/host/hwa-hc.c
index c0df599..4af750e 100644
--- a/drivers/usb/host/hwa-hc.c
+++ b/drivers/usb/host/hwa-hc.c
@@ -774,6 +774,7 @@ static int hwahc_probe(struct usb_interface *usb_iface,
goto error_alloc;
}
usb_hcd-wireless = 1;
+ usb_hcd-self.sg_tablesize = ~0;
wusbhc = usb_hcd_to_wusbhc(usb_hcd);
hwahc = container_of(wusbhc, struct hwahc, wusbhc);
hwahc_init(hwahc);
diff --git a/drivers/usb/wusbcore/wa-xfer.c b/drivers/usb/wusbcore/wa-xfer.c
index 6ef94bc..16968c8 100644
--- a/drivers/usb/wusbcore/wa-xfer.c
+++ b/drivers/usb/wusbcore/wa-xfer.c
@@ -85,6 +85,7 @@
#include linux/hash.h
#include linux/ratelimit.h
#include linux/export.h
+#include linux/scatterlist.h
#include wa-hc.h
#include wusbhc.h
@@ -442,8 +443,7 @@ static ssize_t __wa_xfer_setup_sizes(struct wa_xfer *xfer,
goto error;
}
xfer-seg_size = (xfer-seg_size / maxpktsize) * maxpktsize;
- xfer-segs = (urb-transfer_buffer_length + xfer-seg_size - 1)
- / xfer-seg_size;
+ xfer-segs = DIV_ROUND_UP(urb-transfer_buffer_length, xfer-seg_size);
if (xfer-segs = WA_SEGS_MAX) {
dev_err(dev, BUG? ops, number of segments %d bigger than %d\n,
(int)(urb-transfer_buffer_length / xfer-seg_size),
@@ -627,6 +627,86 @@ static void wa_seg_cb(struct urb *urb)
}
}
+/* allocate an SG list to store bytes_to_transfer bytes and copy the
+ * subset of the in_sg that matches the buffer subset
+ * we are about to transfer. */
+static struct scatterlist *wa_xfer_create_subset_sg(struct scatterlist *in_sg,
+ const unsigned int bytes_transferred,
+ const unsigned int bytes_to_transfer, unsigned int *out_num_sgs)
+{
+ struct scatterlist *out_sg;
+ unsigned int bytes_processed = 0, offset_into_current_page_data = 0,
+ nents;
+ struct scatterlist *current_xfer_sg = in_sg;
+ struct scatterlist *current_seg_sg, *last_seg_sg;
+
+ /* skip previously transferred pages. */
+ while ((current_xfer_sg)
+ (bytes_processed bytes_transferred)) {
+ bytes_processed += current_xfer_sg-length;
+
+ /* advance the sg if current segment starts on or past the
+ next page. */
+ if (bytes_processed = bytes_transferred)
+ current_xfer_sg = sg_next(current_xfer_sg);
+ }
+
+ /* the data for the current segment starts in current_xfer_sg.
+ calculate the offset. */
+ if (bytes_processed bytes_transferred) {
+ offset_into_current_page_data = current_xfer_sg-length -
+ (bytes_processed - bytes_transferred);
+ }
+
+ /* calculate the number of pages needed by this segment. */
+ nents = DIV_ROUND_UP((bytes_to_transfer +
+ offset_into_current_page_data +
+ current_xfer_sg-offset),
+ PAGE_SIZE);
+
+ out_sg = kmalloc((sizeof(struct scatterlist) * nents), GFP_ATOMIC);
+ if (out_sg) {
+ sg_init_table(out_sg, nents);
+
+ /* copy the portion of the incoming SG that correlates to the
+* data to be transferred by this segment to the segment SG. */
+ last_seg_sg = current_seg_sg = out_sg;
+ bytes_processed = 0;
+
+ /* reset nents and calculate the actual number of sg entries
+ needed. */
+ nents = 0;
+ while ((bytes_processed bytes_to_transfer)
+ current_seg_sg current_xfer_sg) {
+ unsigned int page_len = min((current_xfer_sg-length -
+ offset_into_current_page_data),
+ (bytes_to_transfer - bytes_processed));
+
+ sg_set_page(current_seg_sg, sg_page(current_xfer_sg),
+ page_len,
+ current_xfer_sg-offset +
+ offset_into_current_page_data);
+
+ bytes_processed += page_len;
+
+ last_seg_sg = current_seg_sg;
+ current_seg_sg = sg_next(current_seg_sg);
+ current_xfer_sg = sg_next(current_xfer_sg);
+
+ /* only the first page may require additional offset. */
+ offset_into_current_page_data = 0;
+ nents++;
+ }
+
+ /* update num_sgs and terminate
Re: [PATCH] usb: wire adapter: add scatter gather support
On Tue, Jun 11, 2013 at 10:39:31AM -0500, Thomas Pugliese wrote: This patch adds support for scatter gather DMA to the wire adapter and Don't you mean wireless adapter? updates the HWA to advertise support for SG transfers. This allows the block layer to submit transfer requests to the HWA HC without first breaking them up into PAGE_SIZE requests. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com Please cc: me on patches you want applied, so I don't loose them in the mailing list archives accidentally. 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] usb: wire adapter: add scatter gather support
On Tue, 11 Jun 2013, Greg KH wrote: On Tue, Jun 11, 2013 at 10:39:31AM -0500, Thomas Pugliese wrote: This patch adds support for scatter gather DMA to the wire adapter and Don't you mean wireless adapter? The Wireless USB spec uses the term wire adapter to specify the means by which the USB protocol is tunnelled over Wireless USB. The wireless host controller is a host wire adapter (HWA) and the device-side of the link is a device wire adapter (DWA) if it allows wired USB devices to be plugged into it. updates the HWA to advertise support for SG transfers. This allows the block layer to submit transfer requests to the HWA HC without first breaking them up into PAGE_SIZE requests. Signed-off-by: Thomas Pugliese thomas.pugli...@gmail.com Please cc: me on patches you want applied, so I don't loose them in the mailing list archives accidentally. Will do. Thanks. 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: [xhci] null pointer dereference on ring_doorbell_for_active_rings
On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote:
Hello all,
i'm working on usb_autosuspend for ath9k_htc and triggered this
oops. Currently i do not know if real bug is in ath9k_htc or in
xhci. Same adapter with same kernel and my patches work fine on ehci
host... so may be it is xhci.
Which kernel version is this oops on? I suspect it's an xHCI issue.
Please turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG and
send me dmesg, from the beginning of connecting the device to when it is
suspended and then resumed. That will be a lot of output, so feel free
to compress it.
Sarah Sharp
i get oops on this line:
426 static void ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
427 unsigned int slot_id,
428 unsigned int ep_index)
429 {
430 unsigned int stream_id;
431 struct xhci_virt_ep *ep;
432
433 ep = xhci-devs[slot_id]-eps[ep_index];
^^^ ^^^
changes for ath9k_htc are in attachment and photo of oops here:
https://plus.google.com/u/0/102032716864870215256/posts/a9d8nFsLhYK
--
Regards,
Oleksij
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index f5dda84..3d74575 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1368,6 +1368,7 @@ static struct usb_driver ath9k_hif_usb_driver = {
.suspend = ath9k_hif_usb_suspend,
.resume = ath9k_hif_usb_resume,
.reset_resume = ath9k_hif_usb_resume,
+ .supports_autosuspend = 1,
#endif
.id_table = ath9k_hif_usb_ids,
.soft_unbind = 1,
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 0743a47..20be8a1 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -905,6 +905,7 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
struct ath_hw *ah = priv-ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ieee80211_channel *curchan = hw-conf.chandef.chan;
+ struct hif_device_usb *hif_dev = priv-htc-hif_dev;
struct ath9k_channel *init_channel;
int ret = 0;
enum htc_phymode mode;
@@ -917,6 +918,14 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
Starting driver with initial channel: %d MHz\n,
curchan-center_freq);
+ ret = usb_autopm_get_interface(hif_dev-interface);
+ if (ret 0) {
+ ath_err(common,
+ Unable wake up hardware\n);
+ mutex_unlock(priv-mutex);
+ return ret;
+ }
+
/* Ensure that HW is awake before flushing RX */
ath9k_htc_setpower(priv, ATH9K_PM_AWAKE);
WMI_CMD(WMI_FLUSH_RECV_CMDID);
@@ -972,6 +981,7 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
{
struct ath9k_htc_priv *priv = hw-priv;
struct ath_hw *ah = priv-ah;
+ struct hif_device_usb *hif_dev = priv-htc-hif_dev;
struct ath_common *common = ath9k_hw_common(ah);
int ret __attribute__ ((unused));
u8 cmd_rsp;
@@ -1022,6 +1032,8 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
set_bit(OP_INVALID, priv-op_flags);
+ usb_autopm_put_interface(hif_dev-interface);
+
ath_dbg(common, CONFIG, Driver halt\n);
mutex_unlock(priv-mutex);
}
--
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: wire adapter: add scatter gather support
On Tue, 11 Jun 2013, Thomas Pugliese wrote: This patch adds support for scatter gather DMA to the wire adapter and updates the HWA to advertise support for SG transfers. This allows the block layer to submit transfer requests to the HWA HC without first breaking them up into PAGE_SIZE requests. While I do not really understand what is going on here, it nevertheless seems very peculiar. To begin with, whether or not the block layer breaks up transfers into PAGE_SIZE requests has no connection with SG. For another thing, the patch has the HCD creating an SG list. That's not how things work -- the HCD _receives_ the SG list attached to an URB. I'm not sure what problem this patch is intended to solve. Can you explain in more detail? 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: Linux USB file storage gadget with new UDC
On Tue, 11 Jun 2013, victor yeo wrote: Yes, the matching gadget log and usbmon trace are attached in this email. From the usbmon trace, the error (-108) is ESHUTDOWN from SCSI_READ_10 command. From the gadget log, the last SCSI_READ_10 command is received twice. First time it is ok, second time it causes some problem. Which side could cause the ESHUTDOWN error? The usbmon trace shows lots of errors. All those -75 (EOVERFLOW) status codes mean that the gadget sent a packet that was too large, i.e., more than 512 bytes. This happened in all the READ(10) commands except the last one -- none of them succeeded in transferring any data. After the last READ(10) command was sent, the usbmon trace shows that the host's USB port got disabled. Maybe because of the too-long packets. Whatever the reason, that's why the ESHUTDOWN error occurred. The gadget's log does indeed show that the last READ(10) was received twice. The second time is a bug in the UDC driver. No command was sent by the host, so the driver should not have reported that a command was received. 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] usb: wire adapter: add scatter gather support
On Tue, 11 Jun 2013, Alan Stern wrote: On Tue, 11 Jun 2013, Thomas Pugliese wrote: This patch adds support for scatter gather DMA to the wire adapter and updates the HWA to advertise support for SG transfers. This allows the block layer to submit transfer requests to the HWA HC without first breaking them up into PAGE_SIZE requests. While I do not really understand what is going on here, it nevertheless seems very peculiar. To begin with, whether or not the block layer breaks up transfers into PAGE_SIZE requests has no connection with SG. For another thing, the patch has the HCD creating an SG list. That's not how things work -- the HCD _receives_ the SG list attached to an URB. I'm not sure what problem this patch is intended to solve. Can you explain in more detail? Alan Stern Sure. The HWA is a USB connected wireless HCD so the HWA driver communicates with the hardware by sending URBs instead of using mapped memory regions like *HCI devices. There is not necessarily a 1 to 1 correlation between the URBs that come in to the driver and URBs that get forwarded down the stack as HCD commands since there is some encapsulation and segmentation that may be done. Once SG support is enabled in the HWA, the driver now needs to create SGs for the URBs it sends down the stack. In the case of a buffer read URB, it looks like this: 1. The HWA HCD receives a read URB addressed to a device connected wirelessly downstream of the HWA. 2. The HWA driver creates an internal URB to send a Transfer Request command to the HWA on its bulk out endpoint that requests some or all of the data associated with the user's URB. This is analagous to filling in a qTD in EHCI. 3. The HWA driver creates another interal URB to read the Transfer Results back from the HWA's bulk in endpoint. 4. Based on the contents of the Transfer Result. The HWA driver submits a bulk in URB to read the actual data received from the device into the user's buffer. Depending on the amount of data associated with the user's URB, steps 2-4 may be iterated over multiple times due to the limited internal memory of the HWA. My patch updates step 4 to handle URBs that have SGs associated with them. The URB submitted in step 4 will need to include an SG that represents the portion of the origial URB buffer that it is currently reading from the HWA. Tom -- 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: [xhci] null pointer dereference on ring_doorbell_for_active_rings
Am 11.06.2013 19:34, schrieb Sarah Sharp: On Mon, Jun 10, 2013 at 08:55:56AM +0200, Oleksij Rempel wrote: Hello all, i'm working on usb_autosuspend for ath9k_htc and triggered this oops. Currently i do not know if real bug is in ath9k_htc or in xhci. Same adapter with same kernel and my patches work fine on ehci host... so may be it is xhci. Which kernel version is this oops on? I suspect it's an xHCI issue. Please turn on CONFIG_USB_XHCI_HCD_DEBUGGING and CONFIG_USB_DEBUG and send me dmesg, from the beginning of connecting the device to when it is suspended and then resumed. That will be a lot of output, so feel free to compress it. Sarah Sharp Hi Sarah, i use 3.10.0-rc4-wl-00055-gc341e6d, and i also tested v3.8 and v3.9 with same results. Suddenly i'm not able to get log after crash. This chip do not support serial port and ehci debug port is not available i any way - i tried it really hard with soldering iron :) There is even no ethernet connection - only usb adapter. If you have some ideas, please tell me. -- Regards, Oleksij -- 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 v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform
Hello. On 06/11/2013 01:45 PM, B, Ravi wrote: + + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, phy_wkup); + phy-phy_wkup = ioremap(res-start, resource_size(res)); devm_ioremap? The phy_wakeup register is common across two instances of phy, devm_ioremap_resource() will fail to map for twice for same register space. I've already told you the register can't be shared between devices like this. BTW, you haven't replied to my request concerning your /proc/iomem contents... 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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Tue, 11 Jun 2013, Ming Lei wrote: Is there any good reason to do URB giveback with interrupt disabled? That's a good question. Offhand I can't think of any drivers that rely on this -- although there certainly are places where callback routines use spin_lock() rather than spin_lock_irq() or spin_lock_irqsave(), because they know that interrupts are already disabled. Complete() may take long time, for example in UVC's driver, URB's complete() may take more than 3 ms, as reported in below link: http://marc.info/?t=136438111600010r=1w=2 Also complete() is provided by interface driver, and it does many driver specific works, so it isn't good to disable interrupt only for one driver. You probably mean it isn't good to disable interrupts for the sake of only one driver. As things stand now, we disable interrupts for all callbacks in all drivers. If complete() callback runs in one tasklet context, spin_lock() inside complete() is enough, just like hard irq, the tasklet itself is disabled during complete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources between complete(). When the lock is to protect shared resources between complete() and non-IRQ context, currently spin_lock_irqsave() is used in non-IRQ context, which is enough to prevent tasklet from being run on the CPU, so no problem for this situation too. When all HCDs support to run URB giveback in tasklet context, we can change all spin_lock_irq*() to spin_lock() in drivers URB-complete(), and in other places, the spin_lock_irq*() can be changed to spin_lock_bh(). I don't follow your reasoning. Consider the following situation, where the same spinlock is used in both a URB completion handler and an interrupt handler: URB completes A tasklet calls the completion handler, with interrupts enabled The completion handler does spin_lock(lock); An interrupt occurs The interrupt handler does spin_lock(lock); // Deadlock! In order to prevent this from happening, you would have to change the spin_lock() call in the completion handler to spin_lock_irqsave(). Furthermore, you will have to audit every USB driver to make sure that all the completion handlers get fixed. However, changing a documented API is not something to be done lightly. You would have to audit _every_ USB driver to make sure no trouble would arise. OK, I will write patch to request for changing the API if the improvement on the situation isn't objected. I don't mind. But don't be surprised if you end up breaking some drivers. In fact, at least now, the change on API is only about document change, and no drivers' change is required, isn't it? We can describe that URB-complete() might run in hard irq or softirq context, depends on HCD_BH flag of hcd-driver-flags. The drivers _do_ need to be changed, as explained above. And that explanation was only one failure scenario. There may be others. Even with current code, one HCD's interrupt handling still may delay the handling for another HCD interrupt handling for quite long, that is the motivation to decrease the interrupt handling time of USB HCD, ;-) And finally, USB HCDs themselves will benefit from the change, won't they? How will they benefit? Merely from not releasing their private locks? That involves a fairly small amount of code. For async transfer, generally, it should have no effect since there should have URBs queued on the qh queue before submitting URB. That's not how the Bulk-Only mass-storage protocol works. There are times when the protocol _requires_ bulk packets not to be submitted until a particular URB has completed. Yes, I agree. But mass-storage driver itself is very fragile, it will perform badly if CPU has a higher load. Why does that make it fragile? _Every_ driver and program will behave worse when the system is under a heavy load. And it is better to submit DATA/CSW transfer in previous transfer's complete(), IMO. Actually, it would be even better to submit DATA _before_ the CBW completes, and to submit the CSW before submitting DATA-OUT. Unfortunately, the design of the SG library makes it impossible to submit the CSW during DATA-IN completion. Compared with usb-storage task's schedule latency, the tasklet schedule delay should be lower at most of situations since the tasklet is scheduled inside irq handler. True. But the two latencies add. So I decided to replace the percpu tasklet with one single tasklet, which can avoid the problem. Hmmm. What happens when there is more than one host controller? The tasklet will give back only one URB at a time, and it won't run on more than one CPU at a time. The existing drivers allow URBs to be given back on multiple CPUs simultaneously. Also the tasklet running in CPU0 can handle the work which should have
Re: [PATCH] usb: wire adapter: add scatter gather support
On Tue, 11 Jun 2013, Thomas Pugliese wrote: On Tue, 11 Jun 2013, Alan Stern wrote: On Tue, 11 Jun 2013, Thomas Pugliese wrote: This patch adds support for scatter gather DMA to the wire adapter and updates the HWA to advertise support for SG transfers. This allows the block layer to submit transfer requests to the HWA HC without first breaking them up into PAGE_SIZE requests. While I do not really understand what is going on here, it nevertheless seems very peculiar. To begin with, whether or not the block layer breaks up transfers into PAGE_SIZE requests has no connection with SG. For another thing, the patch has the HCD creating an SG list. That's not how things work -- the HCD _receives_ the SG list attached to an URB. I'm not sure what problem this patch is intended to solve. Can you explain in more detail? Alan Stern Sure. The HWA is a USB connected wireless HCD so the HWA driver communicates with the hardware by sending URBs instead of using mapped memory regions like *HCI devices. There is not necessarily a 1 to 1 correlation between the URBs that come in to the driver and URBs that get forwarded down the stack as HCD commands since there is some encapsulation and segmentation that may be done. Once SG support is enabled in the HWA, the driver now needs to create SGs for the URBs it sends down the stack. In the case of a buffer read URB, it looks like this: 1. The HWA HCD receives a read URB addressed to a device connected wirelessly downstream of the HWA. 2. The HWA driver creates an internal URB to send a Transfer Request command to the HWA on its bulk out endpoint that requests some or all of the data associated with the user's URB. This is analagous to filling in a qTD in EHCI. 3. The HWA driver creates another interal URB to read the Transfer Results back from the HWA's bulk in endpoint. 4. Based on the contents of the Transfer Result. The HWA driver submits a bulk in URB to read the actual data received from the device into the user's buffer. Depending on the amount of data associated with the user's URB, steps 2-4 may be iterated over multiple times due to the limited internal memory of the HWA. My patch updates step 4 to handle URBs that have SGs associated with them. The URB submitted in step 4 will need to include an SG that represents the portion of the origial URB buffer that it is currently reading from the HWA. I see. Thanks for the explanation. Things do get confusing when you have a USB-connected host controller! 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: serial/ftdi_sio byte loss / performance regression
On Tue, Jun 11, 2013 at 12:43:25PM +0200, Johan Hovold wrote: On Mon, Jun 10, 2013 at 02:39:06PM -0700, Greg KH wrote: On Thu, Jun 06, 2013 at 11:21:54AM -0700, Greg KH wrote: On Thu, Jun 06, 2013 at 11:58:56AM +0200, Johan Hovold wrote: Greg, perhaps we should consider backporting the wait-until-sent patches (i.e. 0693196fe..4746b6c6e)? Yes, that's a good idea, I'll do that for the next round of stable updates, after this next release tomorrow. I applied these, plus a few others in order to get them all to apply and build properly. But the last patch, 4746b6c6e, didn't apply, and I don't think we really need it for the 3.9 kernel, do we? No, you're right. It's merely a clean up and slight optimisation as no chars_in_buffer needs the disconnect mutex after the other changes. Not sure why it wouldn't apply, though. I was a bit sloppy when I gave the commit refs above -- it should have been 0693196^..b16634a More specifically: 4746b6c USB: serial: clean up chars_in_buffer This one is not strictly necessary, but should apply to v3.9. It doesn't apply to 3.9 at all, so it being not really necessary, I'll not include it :) ff93b19 USB: ti_usb_3410_5052: fix chars_in_buffer overhead This should not be applied to v3.9 as the problem it fixes wasn't introduced until v3.10-rc1. It seems you had to add two other patches to get this one to apply. They should be dropped as well. Ok, I've dropped all 3 of these now. b16634a USB: io_ti: fix chars_in_buffer overhead Needed in 3.9. Good, I have that one. a37025b USB: ftdi_sio: fix chars_in_buffer overhead c413364 USB: ftdi_sio: clean up get_modem_status dcf0105 USB: serial: add generic wait_until_sent implementation These three are also needed in 3.9 (and also 3.8). I have these three. 3.8-stable is dead as far as I'm concerned, so I can't do anything about it :) 0693196 USB: serial: add wait_until_sent operation Needed in 3.9 (and 3.8). (You noticed my refspec did not include it and added it.) Yes, other things were breaking without it. Sorry about the confusion. No worries, I've dropped the three patches listed above, so we should be all good to go. I'll do a 3.9.6-rc1 release today to get these all out to people to test. 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: Serial ports for Septentrio USB GNSS receiver
Ben Adler ad...@informatik.uni-hamburg.de writes: On 10.06.2013 20:19, Bjørn Mork wrote: The cdc-acm driver cannot handle those ports, but a more forgiving generic driver can. I don't recommend it for normal use because it abuses the option driver, but Ben could do a simple test like this: echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue modprobe option echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id Unless I missed something, this should result in two /dev/ttyUSBx serial devices. Before plugging in the receiver, there's ttyUSB0 and ttyUSB1 from another usb/serial converter device that I can't remove. Thanks a lot for your attention to detail. That comment prevented unnecessary questions about those devices. After plugging in, dmesg says: usb 3-2: new full-speed USB device number 2 using uhci_hcd usb 3-2: New USB device found, idVendor=152a, idProduct=8230 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: Septentrio USB Device usb 3-2: Manufacturer: Septentrio cdc_acm 3-2:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters and ttyACM0 appears. # echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue usbcore: registered new interface driver cdc_ether usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_host usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_wlan ttyACM0 is gone and no new ttyUSB* appear. Yup, that's expected. The bad CDC descriptors warnings should probably be silcened? They are not very useful to any end user, and only mean that these these drivers probed the device and found that it wasn't a RNDIS device. Which isn't any error, but just the way this is supposed to work. # modprobe option usbcore: registered new interface driver option usbserial: USB Serial support registered for GSM modem (1-port) # echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id option 3-2:2.0: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB2 option 3-2:2.1: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB3 option 3-2:2.2: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB4 option 3-2:2.3: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB5 ttyUSB2 is dead ttyUSB3 works and is connected to a port named USB1 on the receiver ttyUSB4 is dead ttyUSB5 works and is connected to a port named USB2 on the receiver Thanks for verifying this. I didn't expect the ttyUSB2 and ttyUSB4 devices. Thought the driver would refuse the two interfaces with no endpoints. Obviously wrong. But the fact that ttyUSB3 and ttyUSB5 works fine is what we need to know. usb-devices now shows: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 P: Vendor=152a ProdID=8230 Rev=01.10 S: Manufacturer=Septentrio S: Product=Septentrio USB Device C: #Ifs= 4 Cfg#= 2 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I guess this device is worth a new serial driver of its own in case that works? Or should we create a generic driver for 02/02/ff serial devices (using the inverse of the logic in drivers/net/usb/cdc_ether.c: usbnet_generic_cdc_bind to avoid RNDIS devices)? A few modems with such ports have been added to option, but a generic solution might be better. I obviously don't know, but would be very happy to supply further information! I am starting to lean towards the generic 02/02/ff serial driver, but I'm not currently able to do the work so I should probably not propose it... If you are looking for a nice place to start playing with the kernel, then this is the perfect project :) You have the hardware, which makes testing a lot easier. And the driver will be very small. Some of the simpler drivers in driver/usb/serial/ can be used as examples. The main challenge will be handling the separate data interface, because you do want to match on the control interface and parse the functional descriptors there. cdc_acm and cdc_ether are examples on how to do that, but the method will have to be adapted to the usb-serial framework. Anyway, there is no harm in using the method you used above until a more suitable serial driver is found or developed. It's just not a generic solution suitable for inclusion in the kernel (in particular because of the non-functional
Re: [PATCH 0/5] dwc3: omap: adapt dwc3 to use extcon framework
Hi Kishon, Sorry for late reply. I applied patch1,2 on extcon-linus branch. - http://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-linus But, I have comment of patch 3 about dt API. I send comment on patch 3 mailing thread. Thanks, Chanwoo Choi On 06/04/2013 01:13 AM, Kishon Vijay Abraham I wrote: The first three patches deals with cleanup of extcon inorder to get through compilation without any issues. It also adds an API to get extcon device from dt node which I felt was missing. The next two patches deals with adapt dwc3 to use extcon framework. The 4th patch (usb: dwc3: omap: improve error handling of dwc3_omap_probe) should have ideally been sent to Felipe, however since there will be merge conflicts with the 5th patch (usb: dwc3: use extcon fwrk to receive connect/disconnect) in this series, I've sent in the same series. Once this patch series get merged, dwc3 in omap would be functional in device mode. However there is still some discussion on modelling SMPS10 regulator. Once that gets finalized, dwc3 should be functional in host mode as well. Kishon Vijay Abraham I (5): extcon: Add an API to get extcon device from dt node extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions usb: dwc3: omap: improve error handling of dwc3_omap_probe usb: dwc3: use extcon fwrk to receive connect/disconnect Documentation/devicetree/bindings/usb/omap-usb.txt |5 + drivers/extcon/Kconfig |2 +- drivers/extcon/extcon-class.c | 42 +++ drivers/usb/dwc3/dwc3-omap.c | 133 include/linux/extcon.h |8 ++ include/linux/usb/dwc3-omap.h | 30 - 6 files changed, 168 insertions(+), 52 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.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 0/5] dwc3: omap: adapt dwc3 to use extcon framework
Hi Kishon, I confused patch number. I applied patch2,3 on extcon-linus branch. extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions And I will reply comment about patch1 soon. extcon: Add an API to get extcon device from dt node Thanks, Chanwoo Choi On 06/04/2013 01:13 AM, Kishon Vijay Abraham I wrote: The first three patches deals with cleanup of extcon inorder to get through compilation without any issues. It also adds an API to get extcon device from dt node which I felt was missing. The next two patches deals with adapt dwc3 to use extcon framework. The 4th patch (usb: dwc3: omap: improve error handling of dwc3_omap_probe) should have ideally been sent to Felipe, however since there will be merge conflicts with the 5th patch (usb: dwc3: use extcon fwrk to receive connect/disconnect) in this series, I've sent in the same series. Once this patch series get merged, dwc3 in omap would be functional in device mode. However there is still some discussion on modelling SMPS10 regulator. Once that gets finalized, dwc3 should be functional in host mode as well. Kishon Vijay Abraham I (5): extcon: Add an API to get extcon device from dt node extcon: Kconfig: Make extcon config type as bool extcon: add EXPORT_SYMBOL_GPL for exported functions usb: dwc3: omap: improve error handling of dwc3_omap_probe usb: dwc3: use extcon fwrk to receive connect/disconnect Documentation/devicetree/bindings/usb/omap-usb.txt |5 + drivers/extcon/Kconfig |2 +- drivers/extcon/extcon-class.c | 42 +++ drivers/usb/dwc3/dwc3-omap.c | 133 include/linux/extcon.h |8 ++ include/linux/usb/dwc3-omap.h | 30 - 6 files changed, 168 insertions(+), 52 deletions(-) delete mode 100644 include/linux/usb/dwc3-omap.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 1/3] usb: chipidea: add CSR SiRFSoC ci13xxx usb driver
On Sun, Jun 09, 2013 at 11:25:36AM +0800, Barry Song wrote:
From: Rong Wang rong.w...@csr.com
CSR SiRF SoCs licensed chipidea ci13xxx USB IP, this patch
makes the chipidea drivers support CSR SiRF SoCS.
It also changes the Kconfig, only compile MSM and IMX if related
drivers are enabled. Otherwise, we always need to enable all
clients of chipidea drivers.
Cc: Marek Vasut ma...@denx.de
Cc: Richard Zhao richard.z...@freescale.com
Signed-off-by: Rong Wang rong.w...@csr.com
Signed-off-by: Barry Song baohua.s...@csr.com
---
drivers/usb/Kconfig |1 +
drivers/usb/chipidea/Kconfig| 25
drivers/usb/chipidea/Makefile |5 +-
drivers/usb/chipidea/ci13xxx_sirf.c | 223
+++
4 files changed, 252 insertions(+), 2 deletions(-)
create mode 100644 drivers/usb/chipidea/ci13xxx_sirf.c
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 92e1dc9..9cbe1e0 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -49,6 +49,7 @@ config USB_ARCH_HAS_EHCI
default y if ARCH_MMP
default y if MACH_LOONGSON1
default y if PLAT_ORION
+ default y if ARCH_SIRF
default PCI
# some non-PCI HCDs implement xHCI
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index b2df442..847b9f7 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -31,4 +31,29 @@ config USB_CHIPIDEA_DEBUG
help
Say Y here to enable debugging output of the ChipIdea driver.
+if USB_CHIPIDEA_UDC USB_CHIPIDEA_HOST
+
+config USB_CHIPIDEA_SIRF
+ depends on ARCH_SIRF
+ bool SiRF USB controller ChipIdea driver binding
+ default y
+ help
+ Say Y here to enable sirf usb ChipIdea driver binding.
+
+config USB_CHIPIDEA_MSM
+ depends on ARCH_MSM
+ bool MSM USB controller ChipIdea driver binding
+ default y
+ help
+ Say Y here to enable msm usb ChipIdea driver binding.
+
+config USB_CHIPIDEA_IMX
+ depends on ARCH_MXC || ARCH_MXS
+ bool i.MX USB controller ChipIdea driver binding
+ default y
+ help
+ Say Y here to enable imx usb ChipIdea driver binding.
+
+endif
+
endif
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 4ab83e9..7004fde 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -9,7 +9,7 @@ ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG) += debug.o
# Glue/Bridge layers go here
-obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_msm.o
+obj-$(CONFIG_USB_CHIPIDEA_MSM) += ci13xxx_msm.o
# PCI doesn't provide stubs, need to check
ifneq ($(CONFIG_PCI),)
@@ -17,5 +17,6 @@ ifneq ($(CONFIG_PCI),)
endif
ifneq ($(CONFIG_OF_DEVICE),)
- obj-$(CONFIG_USB_CHIPIDEA) += ci13xxx_imx.o usbmisc_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA_IMX) += ci13xxx_imx.o usbmisc_imx.o
+ obj-$(CONFIG_USB_CHIPIDEA_SIRF) += ci13xxx_sirf.o
endif
diff --git a/drivers/usb/chipidea/ci13xxx_sirf.c
b/drivers/usb/chipidea/ci13xxx_sirf.c
new file mode 100644
index 000..1d84a2f
--- /dev/null
+++ b/drivers/usb/chipidea/ci13xxx_sirf.c
@@ -0,0 +1,223 @@
+/*
+ * USB Controller Driver for CSR SiRF SoC
+ *
+ * Copyright (c) 2011 Cambridge Silicon Radio Limited, a CSR plc group
company.
+ * Rong Wangrong.w...@csr.com
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include linux/module.h
+#include linux/io.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/delay.h
+#include linux/reset.h
+
+#include linux/usb/chipidea.h
+#include ci.h
+
+#define RSC_USB_UART_SHARE 0x0
+#define USB1_MODE_SELBIT(2)
+#define pdev_to_phy(pdev)((struct usb_phy *)platform_get_drvdata(pdev))
sorry, no go. This is not the right way to handle USB PHYs.
+static int sirfsoc_vbus_gpio;
this should be removed too, add it as a member of ci13xx_sirf_data.
+struct ci13xxx_sirf_data {
+ struct platform_device *ci_pdev;
most likely you don't need the platform_device, you need the struct
device only.
+ struct clk *clk;
+};
+
+static inline int ci13xxx_sirf_drive_vbus(int value)
NACK, you should pass your ci13xx_sirf_data as argument here.
+{
+ return gpio_direction_output(sirfsoc_vbus_gpio, value ? 0 : 1);
+}
+
+static void ci13xxx_sirf_notify_event(struct ci13xxx *ci, unsigned event)
+{
+ switch (event) {
+ case CI13XXX_CONTROLLER_RESET_EVENT:
+ ci13xxx_sirf_drive_vbus(1);
+ break;
+ case CI13XXX_CONTROLLER_STOPPED_EVENT:
+ ci13xxx_sirf_drive_vbus(0);
+ break;
+ default:
+ dev_info(ci-dev, Unknown Event\n);
+ break;
+ }
+}
+
+static
Re: [PATCH 1/5] extcon: Add an API to get extcon device from dt node
Hi Kishon,
On 06/04/2013 01:13 AM, Kishon Vijay Abraham I wrote:
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/extcon/extcon-class.c | 40
include/linux/extcon.h|8
2 files changed, 48 insertions(+)
I don't prefer that add of helper API in extcon core. I want to add
new of helper file as drivers/extcon/of-extcon.c.
So, I add drivers/extcon/of-extcon.c and include/linux/extcon/of-extcon.h
based on your this patch. I will send modified patch at once.
diff --git a/drivers/extcon/extcon-class.c b/drivers/extcon/extcon-class.c
index 60adc04..265d549 100644
--- a/drivers/extcon/extcon-class.c
+++ b/drivers/extcon/extcon-class.c
@@ -31,6 +31,7 @@
#include linux/extcon.h
#include linux/slab.h
#include linux/sysfs.h
+#include linux/of_platform.h
/*
* extcon_cable_name suggests the standard cable names for commonly used
@@ -392,6 +393,45 @@ int extcon_set_cable_state(struct extcon_dev *edev,
}
EXPORT_SYMBOL_GPL(extcon_set_cable_state);
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct class_dev_iter iter;
+ struct device *extcon_dev;
+ struct device_node *node;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_dbg(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, unable to find device by node\n);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ class_dev_iter_init(iter, extcon_class, NULL, NULL);
+ while ((extcon_dev = class_dev_iter_next(iter))) {
+ if (extcon_dev-parent != extcon_parent_dev-dev)
+ continue;
+
+ class_dev_iter_exit(iter);
+ return dev_get_drvdata(extcon_dev);
+ }
+
+ class_dev_iter_exit(iter);
Use extcon_get_extcon_dev() instead of using class_dev_iter_init/exit()
+ return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
+
/**
* extcon_get_extcon_dev() - Get the extcon device instance from the name
* @extcon_name: The extcon name provided with extcon_dev_register()
diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index fcb51c8..3858bb9 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -182,6 +182,8 @@ struct extcon_specific_cable_nb {
*/
extern int extcon_dev_register(struct extcon_dev *edev, struct device *dev);
extern void extcon_dev_unregister(struct extcon_dev *edev);
+extern struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev,
+ int index);
extern struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name);
/*
@@ -292,6 +294,12 @@ static inline int extcon_set_cable_state(struct
extcon_dev *edev,
return 0;
}
+static inline struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev,
+ int index)
+{
+ return NULL;
+}
+
static inline struct extcon_dev *extcon_get_extcon_dev(const char
*extcon_name)
{
return NULL;
Thanks,
Chanwoo Choi
--
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
USB 3.0 failure and possible regression in kernel 3.8.0
Kernels somewhere around 2.6.35 could handle USB 3.0 at random sometimes, but kernel 3.8.0 fails consistently. I know I should try to bisect this, but I don't have time and the randomness of the older kernel doesn't help. lspci: 0d:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) Kernel driver in use: xhci_hcd lsusb: Bus 007 Device 002: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. dmesg: [ 458.857081] usb 6-1: new high-speed USB device number 2 using xhci_hcd [ 463.857085] xhci_hcd :0d:00.0: Timeout while waiting for address device command [ 464.728073] xhci_hcd :0d:00.0: Stopped the command ring failed, maybe the host is dead [ 464.728073] xhci_hcd :0d:00.0: Host not halted after 16000 microseconds. [ 464.728073] xhci_hcd :0d:00.0: Abort command ring failed [ 479.976010] [sched_delayed] sched: RT throttling activated [ 479.987230] xhci_hcd :0d:00.0: HC died; cleaning up -- 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] extcon: Add an API to get extcon device from dt node
From: Kishon Vijay Abraham I kis...@ti.com
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/extcon/Makefile | 3 +++
drivers/extcon/of-extcon.c | 56
include/linux/extcon/of-extcon.h | 30 +
3 files changed, 89 insertions(+)
create mode 100644 drivers/extcon/of-extcon.c
create mode 100644 include/linux/extcon/of-extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..39cdf95 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,9 +2,12 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF) += of-extcon.o
+
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
+
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
diff --git a/drivers/extcon/of-extcon.c b/drivers/extcon/of-extcon.c
new file mode 100644
index 000..29f82b4
--- /dev/null
+++ b/drivers/extcon/of-extcon.c
@@ -0,0 +1,56 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.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.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of-extcon.h
+
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_dbg(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, unable to find device by node\n);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
+ if (!edev) {
+ dev_dbg(dev, unable to get extcon device : %s\n,
+ dev_name(extcon_parent_dev-dev));
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of-extcon.h b/include/linux/extcon/of-extcon.h
new file mode 100644
index 000..77d01ba
--- /dev/null
+++ b/include/linux/extcon/of-extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.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.
+ */
+
+#ifndef __LINUX_OF_EXTCON_H
+#define __LINUX_OF_EXTCON_H
+
+#if defined(CONFIG_OF)
+extern struct extcon_dev
+ *of_extcon_get_extcon_dev(struct device *dev, int index);
+#else
+static inline struct extcon_dev
+ *of_extcon_get_extcon_dev(struct device *dev, int index);
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
+#endif /* __LINUX_OF_EXTCON_H */
--
1.8.0
--
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 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Wed, Jun 12, 2013 at 3:10 AM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 11 Jun 2013, Ming Lei wrote: Is there any good reason to do URB giveback with interrupt disabled? That's a good question. Offhand I can't think of any drivers that rely on this -- although there certainly are places where callback routines use spin_lock() rather than spin_lock_irq() or spin_lock_irqsave(), because they know that interrupts are already disabled. Complete() may take long time, for example in UVC's driver, URB's complete() may take more than 3 ms, as reported in below link: http://marc.info/?t=136438111600010r=1w=2 Also complete() is provided by interface driver, and it does many driver specific works, so it isn't good to disable interrupt only for one driver. You probably mean it isn't good to disable interrupts for the sake of only one driver. As things stand now, we disable interrupts for all callbacks in all drivers. If complete() callback runs in one tasklet context, spin_lock() inside complete() is enough, just like hard irq, the tasklet itself is disabled during complete(), if the percpu tasklet is converted to single tasklet. So no problem when the lock is to protect shared resources between complete(). When the lock is to protect shared resources between complete() and non-IRQ context, currently spin_lock_irqsave() is used in non-IRQ context, which is enough to prevent tasklet from being run on the CPU, so no problem for this situation too. When all HCDs support to run URB giveback in tasklet context, we can change all spin_lock_irq*() to spin_lock() in drivers URB-complete(), and in other places, the spin_lock_irq*() can be changed to spin_lock_bh(). I don't follow your reasoning. Consider the following situation, where the same spinlock is used in both a URB completion handler and an interrupt handler: URB completes A tasklet calls the completion handler, with interrupts enabled The completion handler does spin_lock(lock); An interrupt occurs The interrupt handler does spin_lock(lock); // Deadlock! If you mean the interrupt handler is HCD irq handler of the device, no such problem since all complete() will run in tasklet context. If not, I am wondering why one USB driver need register another hard interrupt handler? Could you share such examples? I understand the case only exists with timer handler as discussed with Oliver, don't I? In order to prevent this from happening, you would have to change the spin_lock() call in the completion handler to spin_lock_irqsave(). Furthermore, you will have to audit every USB driver to make sure that all the completion handlers get fixed. I have written one script to search usb drivers which may use timers and spin_lock() at the same time, about 30 drivers are found, and looks we can fix them. However, changing a documented API is not something to be done lightly. You would have to audit _every_ USB driver to make sure no trouble would arise. OK, I will write patch to request for changing the API if the improvement on the situation isn't objected. I don't mind. But don't be surprised if you end up breaking some drivers. Sure, we should change these drivers before changing the API. In fact, at least now, the change on API is only about document change, and no drivers' change is required, isn't it? We can describe that URB-complete() might run in hard irq or softirq context, depends on HCD_BH flag of hcd-driver-flags. The drivers _do_ need to be changed, as explained above. And that explanation was only one failure scenario. There may be others. OK, I'd like to know what the others are? :-) Even with current code, one HCD's interrupt handling still may delay the handling for another HCD interrupt handling for quite long, that is the motivation to decrease the interrupt handling time of USB HCD, ;-) And finally, USB HCDs themselves will benefit from the change, won't they? How will they benefit? Merely from not releasing their private locks? The interrupt of one HCD will be responded lately since another HCD's interrupt handler takes very long time. With the change, the problem can be avoided. That involves a fairly small amount of code. Maybe no much code, but : 1) Inside interrupt handler no submitting and unlinking requests from drivers can happen any more, so interrupt handler should have became simple. 2), Also the race between irq handler and related timer handler needn't to be considered because the private lock can't be released in irq handler. For async transfer, generally, it should have no effect since there should have URBs queued on the qh queue before submitting URB. That's not how the Bulk-Only mass-storage protocol works. There are times when the protocol _requires_ bulk packets not to be submitted until a particular URB has completed. Yes,
Re: [PATCH 1/7] clk: samsung: pll: Add support for PLL6552 and PLL6553
Quoting Tomasz Figa (2013-06-05 16:57:25)
This patch adds support for PLL6552 and PLL6553 PLLs present on Samsung
S3C64xx SoCs.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
Acked-by: Mike Turquette mturque...@linaro.org
or I can take it into clk-next.
---
drivers/clk/samsung/clk-pll.c | 160
++
drivers/clk/samsung/clk-pll.h | 4 ++
2 files changed, 164 insertions(+)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 89135f6..cef0bb9 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -336,6 +336,166 @@ struct clk * __init samsung_clk_register_pll46xx(const
char *name,
}
/*
+ * PLL6552 Clock Type
+ */
+
+#define PLL6552_LOCK_REG 0x00
+#define PLL6552_CON_REG0x0c
+
+#define PLL6552_MDIV_MASK 0x3ff
+#define PLL6552_PDIV_MASK 0x3f
+#define PLL6552_SDIV_MASK 0x7
+#define PLL6552_MDIV_SHIFT 16
+#define PLL6552_PDIV_SHIFT 8
+#define PLL6552_SDIV_SHIFT 0
+
+struct samsung_clk_pll6552 {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+};
+
+#define to_clk_pll6552(_hw) container_of(_hw, struct samsung_clk_pll6552, hw)
+
+static unsigned long samsung_pll6552_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll6552 *pll = to_clk_pll6552(hw);
+ u32 mdiv, pdiv, sdiv, pll_con;
+ u64 fvco = parent_rate;
+
+ pll_con = __raw_readl(pll-reg_base + PLL6552_CON_REG);
+ mdiv = (pll_con PLL6552_MDIV_SHIFT) PLL6552_MDIV_MASK;
+ pdiv = (pll_con PLL6552_PDIV_SHIFT) PLL6552_PDIV_MASK;
+ sdiv = (pll_con PLL6552_SDIV_SHIFT) PLL6552_SDIV_MASK;
+
+ fvco *= mdiv;
+ do_div(fvco, (pdiv sdiv));
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6552_clk_ops = {
+ .recalc_rate = samsung_pll6552_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6552(const char *name,
+ const char *pname, void __iomem *base)
+{
+ struct samsung_clk_pll6552 *pll;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll) {
+ pr_err(%s: could not allocate pll clk %s\n, __func__, name);
+ return NULL;
+ }
+
+ init.name = name;
+ init.ops = samsung_pll6552_clk_ops;
+ init.parent_names = pname;
+ init.num_parents = 1;
+
+ pll-hw.init = init;
+ pll-reg_base = base;
+
+ clk = clk_register(NULL, pll-hw);
+ if (IS_ERR(clk)) {
+ pr_err(%s: failed to register pll clock %s\n, __func__,
+ name);
+ kfree(pll);
+ }
+
+ if (clk_register_clkdev(clk, name, NULL))
+ pr_err(%s: failed to register lookup for %s, __func__,
name);
+
+ return clk;
+}
+
+/*
+ * PLL6553 Clock Type
+ */
+
+#define PLL6553_LOCK_REG 0x00
+#define PLL6553_CON0_REG 0x0c
+#define PLL6553_CON1_REG 0x10
+
+#define PLL6553_MDIV_MASK 0xff
+#define PLL6553_PDIV_MASK 0x3f
+#define PLL6553_SDIV_MASK 0x7
+#define PLL6553_KDIV_MASK 0x
+#define PLL6553_MDIV_SHIFT 16
+#define PLL6553_PDIV_SHIFT 8
+#define PLL6553_SDIV_SHIFT 0
+#define PLL6553_KDIV_SHIFT 0
+
+struct samsung_clk_pll6553 {
+ struct clk_hw hw;
+ void __iomem *reg_base;
+};
+
+#define to_clk_pll6553(_hw) container_of(_hw, struct samsung_clk_pll6553, hw)
+
+static unsigned long samsung_pll6553_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct samsung_clk_pll6553 *pll = to_clk_pll6553(hw);
+ u32 mdiv, pdiv, sdiv, kdiv, pll_con0, pll_con1;
+ u64 fvco = parent_rate;
+
+ pll_con0 = __raw_readl(pll-reg_base + PLL6553_CON0_REG);
+ pll_con1 = __raw_readl(pll-reg_base + PLL6553_CON1_REG);
+ mdiv = (pll_con0 PLL6553_MDIV_SHIFT) PLL6553_MDIV_MASK;
+ pdiv = (pll_con0 PLL6553_PDIV_SHIFT) PLL6553_PDIV_MASK;
+ sdiv = (pll_con0 PLL6553_SDIV_SHIFT) PLL6553_SDIV_MASK;
+ kdiv = (pll_con1 PLL6553_KDIV_SHIFT) PLL6553_KDIV_MASK;
+
+ fvco *= (mdiv 16) + kdiv;
+ do_div(fvco, (pdiv sdiv));
+ fvco = 16;
+
+ return (unsigned long)fvco;
+}
+
+static const struct clk_ops samsung_pll6553_clk_ops = {
+ .recalc_rate = samsung_pll6553_recalc_rate,
+};
+
+struct clk * __init samsung_clk_register_pll6553(const char *name,
+ const char *pname, void __iomem *base)
+{
+ struct samsung_clk_pll6553 *pll;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if
Re: [PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs
Quoting Tomasz Figa (2013-06-05 16:57:26)
This patch adds new, Common Clock Framework-based clock driver for Samsung
S3C64xx SoCs. The driver is just added, without actually letting the
platforms use it yet, since this requires more intermediate steps.
It seems like there is an awful lot of clock data here that exists
alongside the stuff in DT. Is this how you plan to keep things going
forward or is this conversion just an intermediate step?
Regards,
Mike
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
.../bindings/clock/samsung,s3c64xx-clock.txt | 48 ++
drivers/clk/samsung/Makefile | 3 +
drivers/clk/samsung/clk-s3c64xx.c | 503
+
include/dt-bindings/clock/samsung,s3c64xx-clock.h | 144 ++
4 files changed, 698 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
create mode 100644 drivers/clk/samsung/clk-s3c64xx.c
create mode 100644 include/dt-bindings/clock/samsung,s3c64xx-clock.h
diff --git
a/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
new file mode 100644
index 000..278ab6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
@@ -0,0 +1,48 @@
+* Samsung S3C64xx Clock Controller
+
+The S3C64xx clock controller generates and supplies clock to various
controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the S3C64xx family.
+
+Required Properties:
+
+- comptible: should be one of the following.
+ - samsung,s3c6400-clock - controller compatible with S3C6400 SoC.
+ - samsung,s3c6410-clock - controller compatible with S3C6410 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available
only
+on a particular S3C64xx SoC and this is specified where applicable.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
+tree sources.
+
+Example: Clock controller node:
+
+ clocks: clock-controller@7e00f000 {
+ compatible = samsung,s3c6410-clock;
+ reg = 0x7e00f000 0x1000;
+ #clock-cells = 1;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller (refer to the standard clock bindings for information about
+ clocks and clock-names properties):
+
+ uart0: serial@7f005000 {
+ compatible = samsung,s3c6400-uart;
+ reg = 0x7f005000 0x100;
+ interrupt-parent = vic1;
+ interrupts = 5;
+ clock-names = uart, clk_uart_baud2,
+ clk_uart_baud3;
+ clocks = clocks PCLK_UART0, clocks PCLK_UART0,
+ clocks SCLK_UART;
+ status = disabled;
+ };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index b7c232e..c023474 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -6,3 +6,6 @@ obj-$(CONFIG_COMMON_CLK)+= clk.o clk-pll.o
obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
+ifdef CONFIG_COMMON_CLK
+obj-$(CONFIG_ARCH_S3C64XX) += clk-s3c64xx.o
+endif
diff --git a/drivers/clk/samsung/clk-s3c64xx.c
b/drivers/clk/samsung/clk-s3c64xx.c
new file mode 100644
index 000..253a972
--- /dev/null
+++ b/drivers/clk/samsung/clk-s3c64xx.c
@@ -0,0 +1,503 @@
+/*
+ * Copyright (c) 2013 Tomasz Figa tomasz.figa at gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for all S3C64xx SoCs.
+*/
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+
+#include dt-bindings/clock/samsung,s3c64xx-clock.h
+
+#include clk.h
+#include clk-pll.h
+
+/* S3C64xx clock controller register offsets. */
+#define APLL_LOCK 0x000
+#define MPLL_LOCK 0x004
+#define EPLL_LOCK 0x008
+#define APLL_CON 0x00c
+#define MPLL_CON 0x010
+#define EPLL_CON0 0x014
+#define EPLL_CON1 0x018
+#define CLK_SRC0x01c
+#define CLK_DIV0 0x020
+#define CLK_DIV1
Re: USB 3.0 failure and possible regression in kernel 3.8.0
On Wed, Jun 12, 2013 at 10:25:32AM +0900, Norman Diamond wrote: Kernels somewhere around 2.6.35 could handle USB 3.0 at random sometimes, but kernel 3.8.0 fails consistently. I know I should try to bisect this, but I don't have time and the randomness of the older kernel doesn't help. lspci: 0d:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) Kernel driver in use: xhci_hcd lsusb: Bus 007 Device 002: ID 152d:0539 JMicron Technology Corp. / JMicron USA Technology Corp. dmesg: [ 458.857081] usb 6-1: new high-speed USB device number 2 using xhci_hcd [ 463.857085] xhci_hcd :0d:00.0: Timeout while waiting for address device command [ 464.728073] xhci_hcd :0d:00.0: Stopped the command ring failed, maybe the host is dead [ 464.728073] xhci_hcd :0d:00.0: Host not halted after 16000 microseconds. [ 464.728073] xhci_hcd :0d:00.0: Abort command ring failed [ 479.976010] [sched_delayed] sched: RT throttling activated [ 479.987230] xhci_hcd :0d:00.0: HC died; cleaning up Can you try a newer kernel (hint, 3.8.0 is old and obsolete)? 3.10-rc5 would be great, but I'll settle for 3.9.5 if you can try that. 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] extcon: Add an API to get extcon device from dt node
On Wed, Jun 12, 2013 at 7:09 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
From: Kishon Vijay Abraham I kis...@ti.com
Added an API of_extcon_get_extcon_dev() to be used by drivers to get
extcon device in the case of dt boot (this can be used instead of
extcon_get_extcon_dev()).
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
drivers/extcon/Makefile | 3 +++
drivers/extcon/of-extcon.c | 56
include/linux/extcon/of-extcon.h | 30 +
3 files changed, 89 insertions(+)
create mode 100644 drivers/extcon/of-extcon.c
create mode 100644 include/linux/extcon/of-extcon.h
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 540e2c3..39cdf95 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -2,9 +2,12 @@
# Makefile for external connector class (extcon) devices
#
+obj-$(CONFIG_OF) += of-extcon.o
+
obj-$(CONFIG_EXTCON) += extcon-class.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_ADC_JACK) += extcon-adc-jack.o
+
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_ARIZONA) += extcon-arizona.o
diff --git a/drivers/extcon/of-extcon.c b/drivers/extcon/of-extcon.c
new file mode 100644
index 000..29f82b4
--- /dev/null
+++ b/drivers/extcon/of-extcon.c
@@ -0,0 +1,56 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.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.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/extcon/of-extcon.h
+
+struct extcon_dev *of_extcon_get_extcon_dev(struct device *dev, int index)
Can this be simpler name? of_extcon_get_dev or something like that?
+{
+ struct device_node *node;
+ struct extcon_dev *edev;
+ struct platform_device *extcon_parent_dev;
+
+ if (!dev-of_node) {
+ dev_dbg(dev, device does not have a device node entry\n);
+ return ERR_PTR(-EINVAL);
+ }
+
+ node = of_parse_phandle(dev-of_node, extcon, index);
+ if (!node) {
+ dev_dbg(dev, failed to get phandle in %s node\n,
+ dev-of_node-full_name);
+ return ERR_PTR(-ENODEV);
+ }
+
+ extcon_parent_dev = of_find_device_by_node(node);
+ if (!extcon_parent_dev) {
+ dev_dbg(dev, unable to find device by node\n);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ edev = extcon_get_extcon_dev(dev_name(extcon_parent_dev-dev));
+ if (!edev) {
+ dev_dbg(dev, unable to get extcon device : %s\n,
+ dev_name(extcon_parent_dev-dev));
+ return ERR_PTR(-ENODEV);
+ }
+
+ return edev;
+}
+EXPORT_SYMBOL_GPL(of_extcon_get_extcon_dev);
diff --git a/include/linux/extcon/of-extcon.h
b/include/linux/extcon/of-extcon.h
new file mode 100644
index 000..77d01ba
--- /dev/null
+++ b/include/linux/extcon/of-extcon.h
@@ -0,0 +1,30 @@
+/*
+ * OF helpers for External connector (extcon) framework
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Kishon Vijay Abraham I kis...@ti.com
+ *
+ * Copyright (C) 2013 Samsung Electronics
+ * Chanwoo Choi cw00.c...@samsung.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.
+ */
+
+#ifndef __LINUX_OF_EXTCON_H
+#define __LINUX_OF_EXTCON_H
+
+#if defined(CONFIG_OF)
+extern struct extcon_dev
+ *of_extcon_get_extcon_dev(struct device *dev, int index);
+#else
+static inline struct extcon_dev
+ *of_extcon_get_extcon_dev(struct device *dev, int index);
+{
+ return NULL;
+}
+#endif /* CONFIG_OF */
+
+#endif /* __LINUX_OF_EXTCON_H */
--
1.8.0
--
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
