Re: Fwd: Fwd: request some hep for usb comminucation
Hi Thank you very much for the attention and support. Unfortunately I made a mistake, when I send data to the device, I expected that the device will send an answer for me, while I should read the response from the device. Thanks a lot M.Razavi 2013/6/11 Greg KH gre...@linuxfoundation.org: On Tue, Jun 11, 2013 at 12:29:19PM +0430, Mahdi Razavi wrote: 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? No idea, you might want to contact the company to try to get the specification for how to talk to the device from them. Good luck, reverse engineering is hard, 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: [PATCH 2/7] clk: samsung: Add clock driver for S3C64xx SoCs
Hi Mike,
On Tuesday 11 of June 2013 19:54:51 Mike Turquette wrote:
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?
Current S3C64xx support contains a lot of boards, for which I don't see
any chance for DT conversion in any time soon, so the driver must cover
both DT and non-DT cases. (Not even saying that DT support for S3C64xx is
not yet submitted, as I want to get all the dependencies merged, or at
least acked, first.)
Also, personally, I don't see anything wrong with having those clocks
defined in the driver. The binding specifies the exact mapping between
clock IDs inside the clock provider and hardware clocks and not all clocks
need to be exported (most of muxes and divs don't need to), so I find it
more reasonable to define them in the driver instead.
Another thing is that it's unlikely for any new SoC from S3C64xx series to
show up, so basically the clock list is fixed.
Best regards,
Tomasz
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)
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Wed, Jun 12, 2013 at 10:43 AM, Ming Lei ming@canonical.com wrote: On Wed, Jun 12, 2013 at 3:10 AM, Alan Stern st...@rowland.harvard.edu wrote: 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 fact, timer funtion is still run in softirq context, so the deadlock won't be caused with acquiring same lock(spin_lock) in both timer function and complete() from tasklet. 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] extcon: Add an API to get extcon device from dt node
Hi Chanwoo Choi,
On Wednesday 12 June 2013 07:09 AM, Chanwoo Choi 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)
+{
+ 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));
In order to get this working, I needed a small fix in extcon_dev_register
- dev_set_name(edev-dev, edev-name ? edev-name : dev_name(dev));
+ edev-name = edev-name ? edev-name : dev_name(dev);
+ dev_set_name(edev-dev, edev-name);
Also using extcon_get_extcon_dev here requires the extcon driver not to
set edev.name since we use *dev_name* here. Hence I recommend using my
initial class iterative approach. Anyway its your call. Let me know if
have to float a new version of the patch (either the iterative approach
or having the fix I mentioned in extcon_dev_register).
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 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.
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...
I have missed that specific mail. The /proc/iomem does show this common
register. As you suggest to create a third device for this shared register? I
agree it can be done.
Initially I thought this should be part of control module, but do we have
control module frame work for every SoC(am335x)?
Every SoC has many such shared register to handle control/status logic for Soc
specific IP(s)?
If we create separate device node for each such registers, this will end up in
adding more files to kernel.
We should create single control module node for each SoC,
cm: control_module@44e1 {
compatible = ti,dsps-usbphy;
reg = 0x44e10648 0x4
0x44e10XXX 0x4
reg-names = phy_wkup, mmc_control, xxxreg_ctrl,
xxxreg_status;
id = 0;
};
Have common control module APIs to control these registers, can be used by
other driver modules.
--
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
RE: [PATCH v2 2/7] usb: phy: dsps: adding usbphy driver for am33xx platform
Typo.. corrected
The /proc/iomem does not show this common register
-Original Message-
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org]
On Behalf Of B, Ravi
Sent: Wednesday, June 12, 2013 12:51 PM
To: Sergei Shtylyov
Cc: ABRAHAM, KISHON VIJAY; 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.
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...
I have missed that specific mail. The /proc/iomem does not show this common
register. As you suggest to create a third device for this shared register? I
agree it can be done.
Initially I thought this should be part of control module, but do we have
control module frame work for every SoC(am335x)?
Every SoC has many such shared register to handle control/status logic for Soc
specific IP(s)?
If we create separate device node for each such registers, this will end up in
adding more files to kernel.
We should create single control module node for each SoC,
cm: control_module@44e1 {
compatible = ti,dsps-usbphy;
reg = 0x44e10648 0x4
0x44e10XXX 0x4
reg-names = phy_wkup, mmc_control, xxxreg_ctrl,
xxxreg_status;
id = 0;
};
Have common control module APIs to control these registers, can be used by
other driver modules.
--
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
--
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, 12 Jun 2013, Ming Lei wrote: On Wed, Jun 12, 2013 at 3:10 AM, Alan Stern st...@rowland.harvard.edu wrote: Also the tasklet running in CPU0 can handle the work which should have been done by the same tasket scheduled in CPU1, so we can avoid busy-waitting in CPU1 which may be introduced by tasklet_schedule() in CPU1. Or you could have a separate tasklet for each host controller. Yes, but I will compare tasklet with interrupt threaded handler first. Yes, please. I read through the thread and I really recommend that you get rid of the tasklet. tasklets are a complete disaster by design and we really should make efforts to get rid of the last users instead of trying to work around their semantical shortcomings. Thanks, tglx -- 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 15:10:03 Alan Stern wrote: 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. Yes. However, it can be done mechanically. And we know only the handlers for complete need to be fixed. 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 2/3] usb: dwc3: omap: Intialize the register offset values for OMAP5 and AM437x
This patch Initializes the register offset values depending
on the X_MAJOR of USBOTGSS_REVISION register. Also adds register
offset defines and new debug register defines.
X_MAJOR is 2 for both OMAP5 and AM437x. But both have different glue register
layout. Differentiate AM437x using dt compatible.
Register offsets are cached in dwc3_omap struct for reg reads and writes.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 57
1 file changed, 57 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index a354b4c..f204d18 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -61,21 +61,38 @@
#define USBOTGSS_REVISION 0x
#define USBOTGSS_SYSCONFIG 0x0010
#define USBOTGSS_IRQ_EOI 0x0020
+#define USBOTGSS_EOI_OFFSET0x0008
#define USBOTGSS_IRQSTATUS_RAW_0 0x0024
#define USBOTGSS_IRQSTATUS_0 0x0028
#define USBOTGSS_IRQENABLE_SET_0 0x002c
#define USBOTGSS_IRQENABLE_CLR_0 0x0030
+#define USBOTGSS_IRQ0_OFFSET 0x0004
#define USBOTGSS_IRQSTATUS_RAW_1 0x0034
#define USBOTGSS_IRQSTATUS_1 0x0038
#define USBOTGSS_IRQENABLE_SET_1 0x003c
#define USBOTGSS_IRQENABLE_CLR_1 0x0040
+#define USBOTGSS_IRQSTATUS_EOI_MISC0x0030
+#define USBOTGSS_IRQSTATUS_RAW_MISC0x0034
+#define USBOTGSS_IRQSTATUS_MISC0x0038
+#define USBOTGSS_IRQENABLE_SET_MISC0x003c
+#define USBOTGSS_IRQENABLE_CLR_MISC0x0040
+#define USBOTGSS_IRQMISC_OFFSET0x03fc
#define USBOTGSS_UTMI_OTG_CTRL 0x0080
#define USBOTGSS_UTMI_OTG_STATUS 0x0084
+#define USBOTGSS_UTMI_OTG_OFFSET 0x0480
+#define USBOTGSS_TXFIFO_DEPTH 0x0508
+#define USBOTGSS_RXFIFO_DEPTH 0x050c
#define USBOTGSS_MMRAM_OFFSET 0x0100
#define USBOTGSS_FLADJ 0x0104
#define USBOTGSS_DEBUG_CFG 0x0108
#define USBOTGSS_DEBUG_DATA0x010c
+#define USBOTGSS_DEV_EBC_EN0x0110
+#define USBOTGSS_DEBUG_OFFSET 0x0600
+/* REVISION REGISTER */
+#define USBOTGSS_REVISION_XMAJOR(reg) ((reg 8) 0x7)
+#define USBOTGSS_REVISION_XMAJOR1 1
+#define USBOTGSS_REVISION_XMAJOR2 2
/* SYSCONFIG REGISTER */
#define USBOTGSS_SYSCONFIG_DMADISABLE (1 16)
@@ -300,6 +317,7 @@ static int dwc3_omap_probe(struct platform_device *pdev)
int irq;
int utmi_mode = 0;
+ int x_major;
u32 reg;
@@ -356,6 +374,42 @@ static int dwc3_omap_probe(struct platform_device *pdev)
return ret;
}
+ reg = dwc3_omap_readl(omap-base, USBOTGSS_REVISION);
+ omap-revision = reg;
+ x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+ /* Differentiate between OMAP5,AM437x and others*/
+ switch (x_major) {
+ case USBOTGSS_REVISION_XMAJOR1:
+ case USBOTGSS_REVISION_XMAJOR2:
+ omap-irq_eoi_offset = 0;
+ omap-irq0_offset = 0;
+ omap-irqmisc_offset = 0;
+ omap-utmi_otg_offset = 0;
+ omap-debug_offset = 0;
+ break;
+ default:
+ /* Default to the latest revision */
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ break;
+ }
+
+ /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for aegis
+*/
+
+ if (of_device_is_compatible(node, ti,am437x-dwc3)) {
+ omap-irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap-irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap-irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap-utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap-debug_offset = USBOTGSS_DEBUG_OFFSET;
+ }
+
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
of_property_read_u32(node, utmi-mode, utmi_mode);
@@ -412,6 +466,9 @@ static const struct of_device_id of_dwc3_match[] = {
{
.compatible = ti,dwc3
},
+ {
+ .compatible = ti,am437x-dwc3
+ },
{ },
};
MODULE_DEVICE_TABLE(of, of_dwc3_match);
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the
[PATCH v2 3/3] usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers
This patch adds wrappers to dwc3_omap_readl/writel calls to accomodate
both OMAP5 and AM437x reg maps (It uses the cached register offsets).
Also renames OMAP5 IRQ1 as IRQMISC and IRQ1 bits as IRQMISC bits.
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 173 +--
1 file changed, 116 insertions(+), 57 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f204d18..4f565d7 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -67,10 +67,18 @@
#define USBOTGSS_IRQENABLE_SET_0 0x002c
#define USBOTGSS_IRQENABLE_CLR_0 0x0030
#define USBOTGSS_IRQ0_OFFSET 0x0004
-#define USBOTGSS_IRQSTATUS_RAW_1 0x0034
-#define USBOTGSS_IRQSTATUS_1 0x0038
-#define USBOTGSS_IRQENABLE_SET_1 0x003c
-#define USBOTGSS_IRQENABLE_CLR_1 0x0040
+#define USBOTGSS_IRQSTATUS_RAW_1 0x0030
+#define USBOTGSS_IRQSTATUS_1 0x0034
+#define USBOTGSS_IRQENABLE_SET_1 0x0038
+#define USBOTGSS_IRQENABLE_CLR_1 0x003c
+#define USBOTGSS_IRQSTATUS_RAW_2 0x0040
+#define USBOTGSS_IRQSTATUS_2 0x0044
+#define USBOTGSS_IRQENABLE_SET_2 0x0048
+#define USBOTGSS_IRQENABLE_CLR_2 0x004c
+#define USBOTGSS_IRQSTATUS_RAW_3 0x0050
+#define USBOTGSS_IRQSTATUS_3 0x0054
+#define USBOTGSS_IRQENABLE_SET_3 0x0058
+#define USBOTGSS_IRQENABLE_CLR_3 0x005c
#define USBOTGSS_IRQSTATUS_EOI_MISC0x0030
#define USBOTGSS_IRQSTATUS_RAW_MISC0x0034
#define USBOTGSS_IRQSTATUS_MISC0x0038
@@ -102,17 +110,17 @@
/* IRQS0 BITS */
#define USBOTGSS_IRQO_COREIRQ_ST (1 0)
-/* IRQ1 BITS */
-#define USBOTGSS_IRQ1_DMADISABLECLR(1 17)
-#define USBOTGSS_IRQ1_OEVT (1 16)
-#define USBOTGSS_IRQ1_DRVVBUS_RISE (1 13)
-#define USBOTGSS_IRQ1_CHRGVBUS_RISE(1 12)
-#define USBOTGSS_IRQ1_DISCHRGVBUS_RISE (1 11)
-#define USBOTGSS_IRQ1_IDPULLUP_RISE(1 8)
-#define USBOTGSS_IRQ1_DRVVBUS_FALL (1 5)
-#define USBOTGSS_IRQ1_CHRGVBUS_FALL(1 4)
-#define USBOTGSS_IRQ1_DISCHRGVBUS_FALL (1 3)
-#define USBOTGSS_IRQ1_IDPULLUP_FALL(1 0)
+/* IRQMISC BITS */
+#define USBOTGSS_IRQMISC_DMADISABLECLR (1 17)
+#define USBOTGSS_IRQMISC_OEVT (1 16)
+#define USBOTGSS_IRQMISC_DRVVBUS_RISE (1 13)
+#define USBOTGSS_IRQMISC_CHRGVBUS_RISE (1 12)
+#define USBOTGSS_IRQMISC_DISCHRGVBUS_RISE (1 11)
+#define USBOTGSS_IRQMISC_IDPULLUP_RISE (1 8)
+#define USBOTGSS_IRQMISC_DRVVBUS_FALL (1 5)
+#define USBOTGSS_IRQMISC_CHRGVBUS_FALL (1 4)
+#define USBOTGSS_IRQMISC_DISCHRGVBUS_FALL (1 3)
+#define USBOTGSS_IRQMISC_IDPULLUP_FALL (1 0)
/* UTMI_OTG_CTRL REGISTER */
#define USBOTGSS_UTMI_OTG_CTRL_DRVVBUS (1 5)
@@ -161,6 +169,58 @@ static inline void dwc3_omap_writel(void __iomem *base,
u32 offset, u32 value)
writel(value, base + offset);
}
+static u32 dwc3_omap_read_utmi_status(struct dwc3_omap *omap)
+{
+ return dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS +
+ omap-utmi_otg_offset);
+}
+
+static void dwc3_omap_write_utmi_status(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS +
+ omap-utmi_otg_offset, value);
+
+}
+
+static u32 dwc3_omap_read_irq0_status(struct dwc3_omap *omap)
+{
+ return dwc3_omap_readl(omap-base, USBOTGSS_IRQSTATUS_0 -
+ omap-irq0_offset);
+}
+
+static void dwc3_omap_write_irq0_status(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap-base, USBOTGSS_IRQSTATUS_0 -
+ omap-irq0_offset, value);
+
+}
+
+static u32 dwc3_omap_read_irqmisc_status(struct dwc3_omap *omap)
+{
+ return dwc3_omap_readl(omap-base, USBOTGSS_IRQSTATUS_MISC +
+ omap-irqmisc_offset);
+}
+
+static void dwc3_omap_write_irqmisc_status(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap-base, USBOTGSS_IRQSTATUS_MISC +
+ omap-irqmisc_offset, value);
+
+}
+
+static void dwc3_omap_write_irqmisc_set(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_MISC +
+ omap-irqmisc_offset, value);
+
+}
+
+static void dwc3_omap_write_irq0_set(struct dwc3_omap *omap, u32 value)
+{
+ dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_0 -
+
[PATCH v2 1/3] usb: dwc3: omap: Adding am437x specific register map changes
AM437x and OMAP5 dwc3 subsytem have different register map.
Major differences are as follows.
OMAP5 has one main interrupt and one misc interrupt
Aegis has four main interrupts and one misc interrupt.
Miscellanous Interrupt offsets are changed.
UTMI OTG Control and Status Registers offsets are changed.
DEBUG Configuration and Status Registers are changed.
The main intend of the patch is to re-use the same wrapper driver
for both OMAP5 and AM437x, by using the x_major in revision
register and adjusting the offsets.
This patch adds the register map offsets and adds offset variables
in struct dwc3_omap to cache the offsets
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 34638b9..a354b4c 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -122,6 +122,12 @@ struct dwc3_omap {
void __iomem*base;
u32 utmi_otg_status;
+ u32 utmi_otg_offset;
+ u32 irqmisc_offset;
+ u32 irq_eoi_offset;
+ u32 debug_offset;
+ u32 irq0_offset;
+ u32 revision;
u32 dma_status:1;
};
--
1.8.1.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/3] Adding AM437x support to dwc3-omap glue
Initial patch set to add support for dwc3 in am437x platform. This patch series addresses the regiter map differences between OMAP5 and AM437x, to re-use the same driver. AM437x and OMAP5 dwc3 subsytem have different register map. Major differences are as follows. OMAP5 has one main interrupt and one misc interrupt Aegis has four main interrupts and one misc interrupt. Miscellanous Interrupt offsets are changed. UTMI OTG Control and Status Registers offsets are changed. DEBUG Configuration and Status Registers are changed. The main intend of the patch is to re-use the same wrapper driver for both OMAP5 and AM437x, by using the x_major in revision register and adjusting the offsets. changes from v1: - Added compatible for AM437X since x_major is same for OMAP5 and AM437x - Added proper wrappers to dwc3_omap_readl/writel George Cherian (3): usb: dwc3: omap: Adding am437x specific register map changes usb: dwc3: omap: Intialize the register offset values for OMAP5 and AM437x usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers drivers/usb/dwc3/dwc3-omap.c | 234 --- 1 file changed, 178 insertions(+), 56 deletions(-) -- 1.8.1.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: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Wed, Jun 12, 2013 at 5:11 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 15:10:03 Alan Stern wrote: 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. Yes. However, it can be done mechanically. And we know only the handlers for complete need to be fixed. I am wondering if the change is needed since timer function is still run in softirq context instead of hard irq. Looks Alan concerned that one USB interface driver may have another hard interrupt handler involved. Is there such kind of USB driver/device in tree? Thanks, -- Ming -- 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 Wednesday 12 June 2013 18:11:34 Ming Lei wrote: On Wed, Jun 12, 2013 at 5:11 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 15:10:03 Alan Stern wrote: 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. Yes. However, it can be done mechanically. And we know only the handlers for complete need to be fixed. I am wondering if the change is needed since timer function is still run in softirq context instead of hard irq. Looks Alan concerned that one USB interface driver may have another hard interrupt handler involved. Is there such kind of USB driver/device in tree? No. Suppose a USB network driver. The complete() handler is written on the assumption that interrupts are off. So it takes a spinlock from the network subsystem. It does so with spin_lock() Other network drivers also take the lock. And they may take it from an IRQ handler. If such an IRQ interrupts the tasklet complete() is running in, the CPU will deadlock. The danger is not interrupt handlers in the same driver but IRQ handlers of _other_ drivers (PCI, ...) a lock is shared with. You need to go through all USB drivers and change every spin_lock() that goes for a lock that is exported to a spin_lock_irqsave() 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: MUSB multiplatform work?
On Thu, May 30, 2013 at 11:19:33PM +0200, Linus Walleij wrote:
On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren t...@atomide.com wrote:
There are many devices where the device FIFO is memory mapped to the
GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the
only reason why these have not been converted to the dmaengine is
the fact that dmaengine cannot configure the DMA hardware to do
autoincrement and loop over the device FIFO.
OK that seems like something pretty generic that we could just add
to the struct dma_slave_config actually, something like:
u32 src_fifoloop;
u32 dst_fifoloop;
Yes for genric but not for loop. For most of our cases we are considering the
FIFO address as a constant. Typically DMA controllers have this ability to
perform incremental/decremental/constant FIFO address.
What would make sense to have is:
enum dmaengine_slave_addr_mode {
DMAENGINE_SLAVE_ADDR_CONSTANT = 0,
DMAENGINE_SLAVE_ADDR_INCREMANT,
DMAENGINE_SLAVE_ADDR_DECREMENT,
};
and add these to struct dma_slave_config:
enum dmaengine_slave_addr_mode src_mode;
enum dmaengine_slave_addr_mode dstn_mode;
For loopover we can have:
u32 loop_counter;
on 0 means no loop, and valid value tells when to loopover (offset).
will this help for all of the above controllers and their conversion?
Given in # of words on the src/dst address simply, left as zero
for hitting a constant address over and over again.
We'd need both to make space for device-device transfers.
If this is all that is needed to convert them do DMAengine
I'd surely ACK it (FWIW).
--
~Vinod
--
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
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 :) Yeah, I know. I just put it in parenthesis for reference. Feels like every kernel version is being picked up by someone these days. :) 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 Wed, Jun 12, 2013 at 6:19 PM, Oliver Neukum oli...@neukum.org wrote: On Wednesday 12 June 2013 18:11:34 Ming Lei wrote: On Wed, Jun 12, 2013 at 5:11 PM, Oliver Neukum oli...@neukum.org wrote: On Tuesday 11 June 2013 15:10:03 Alan Stern wrote: 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. Yes. However, it can be done mechanically. And we know only the handlers for complete need to be fixed. I am wondering if the change is needed since timer function is still run in softirq context instead of hard irq. Looks Alan concerned that one USB interface driver may have another hard interrupt handler involved. Is there such kind of USB driver/device in tree? No. Suppose a USB network driver. The complete() handler is written on the assumption that interrupts are off. So it takes a spinlock from the network subsystem. It does so with spin_lock() Looks I misses the case, but IMO, it might not be very common, generally subsystem provides API for drivers to do something(handle rx/report tx) inside complete(), and seldom exports subsystem-wide lock directly to drivers. API has no context info, and should have called spin_lock_irqrestore(). Other network drivers also take the lock. And they may take it from an IRQ handler. If such an IRQ interrupts the tasklet complete() is running in, the CPU will deadlock. Looks no usbnet drivers hold subsystem(network) locks in its complete(). Both the locks held are per device/per skb list. In usbnet_bh(), there is one, eg. netif_rx(), which is a API and disables local IRQ. The danger is not interrupt handlers in the same driver but IRQ handlers of _other_ drivers (PCI, ...) a lock is shared with. Right, so generally drivers which spin_lock(subsystem lock) in complete() might be affected. You need to go through all USB drivers and change every spin_lock() that goes for a lock that is exported to a spin_lock_irqsave() Yes, that is the safest way. 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 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 I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? thanks, victor # dmesg -c 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 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 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 0xc128f800 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 fa is 0x2 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 0xc128f800 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 0xc128f800 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 0xc128f800 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 0xc128f800 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 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 4: : 04 03 09 04 g_file_storage gadget: ep0-setup, length 8: : 80 06 02 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x36, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 54: : 36 03 46 00 69 00 6c 00 65 00 2d 00 62 00 61 00 0010: 63 00 6b 00 65 00 64 00 20 00 53 00 74 00 6f 00 0020: 72 00 61 00 67 00 65 00 20 00 47 00 61 00 64 00 0030: 67 00 65 00 74 00 g_file_storage gadget: ep0-setup, length 8: : 80 06 01 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x3a, buffer 0xc128f800 ep0_complete g_file_storage gadget: ep0-in, length 58: : 3a 03 4c 00 69 00 6e 00 75 00 78 00 20 00 33 00 0010: 2e 00 34 00 2e 00 34 00 2b 00 20 00 77 00 69 00 0020: 74 00 68 00 20 00 6b 00 61 00 67 00 65 00 6e 00 0030: 32 00 5f 00 75 00 73 00 62 00 g_file_storage gadget: ep0-setup, length 8: : 00 09 01 00 00 00 00 00 g_file_storage gadget: set configuration handle_exception begin handle_exception wait until handle_exception old_state 4 g_file_storage gadget: set interface 0 g_file_storage gadget: high-speed config #1 g_file_storage gadget: ep0-setup, length 8: : 80 06 04 03 09 04 ff 00 g_file_storage gadget: get string descriptor ept0 in queue len 0x1a, buffer 0xc128f800 ep0_complete
Re: MUSB multiplatform work?
On 12 June 2013 15:35, Vinod Koul vinod.k...@intel.com wrote:
On Thu, May 30, 2013 at 11:19:33PM +0200, Linus Walleij wrote:
On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren t...@atomide.com wrote:
There are many devices where the device FIFO is memory mapped to the
GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the
only reason why these have not been converted to the dmaengine is
the fact that dmaengine cannot configure the DMA hardware to do
autoincrement and loop over the device FIFO.
OK that seems like something pretty generic that we could just add
to the struct dma_slave_config actually, something like:
u32 src_fifoloop;
u32 dst_fifoloop;
Yes for genric but not for loop. For most of our cases we are considering the
FIFO address as a constant. Typically DMA controllers have this ability to
perform incremental/decremental/constant FIFO address.
What would make sense to have is:
enum dmaengine_slave_addr_mode {
DMAENGINE_SLAVE_ADDR_CONSTANT = 0,
DMAENGINE_SLAVE_ADDR_INCREMANT,
DMAENGINE_SLAVE_ADDR_DECREMENT,
};
and add these to struct dma_slave_config:
enum dmaengine_slave_addr_mode src_mode;
enum dmaengine_slave_addr_mode dstn_mode;
For loopover we can have:
u32 loop_counter;
on 0 means no loop, and valid value tells when to loopover (offset).
will this help for all of the above controllers and their conversion?
IIRC, TI's Sundaram Raju proposed a TI specific api to DMAEngine for
this very purpose, which was generalized into
device_prep_interleaved_dma(). Which I think should already be enough
to serve the purpose. Is it not?
-jassi
--
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 9, 2013 at 6:25 AM, Barry Song 21cn...@gmail.com wrote:
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.
+ /* 5. set device dma mask */
+ if (!pdev-dev.dma_mask) {
+ pdev-dev.dma_mask = devm_kzalloc(pdev-dev,
+ sizeof(*pdev-dev.dma_mask),
GFP_KERNEL);
+ if (!pdev-dev.dma_mask) {
+ dev_err(pdev-dev, Failed to alloc dma_mask!\n);
+ ret = -ENOMEM;
+ goto err;
+ }
+ *pdev-dev.dma_mask = DMA_BIT_MASK(32);
+ dma_set_coherent_mask(pdev-dev, *pdev-dev.dma_mask);
Perhaps you could avoid this allocation if you apply coherent mask
first and its address will be used as dma_mask value.
+ }
+err:
+ clk_disable_unprepare(data-clk);
+ return ret;
Please, check, but if I remember correctly devm_clk* is doing this for
you on release stage.
+static int ci13xxx_sirf_remove(struct platform_device *pdev)
+{
+ struct ci13xxx_sirf_data *data = platform_get_drvdata(pdev);
+
+ pm_runtime_disable(pdev-dev);
+ ci13xxx_remove_device(data-ci_pdev);
+
+ clk_disable_unprepare(data-clk);
Ditto.
--
With Best Regards,
Andy Shevchenko
--
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, 12 Jun 2013, Ming Lei wrote: 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? Here's another possibility. A USB driver has a private lock, and it acquires this lock in its completion handler. But it also acquires this lock in other routines, and those other routines may be called by other drivers or subsystems in interrupt context. 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? :-) Me too. :-) 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. For reasonably sophisticated host controllers like EHCI, the delay in responding to an interrupt doesn't matter much. But for simpler host controllers (for example, those using PIO instead of DMA) it matters more, so those other HCDs will benefit more from the conversion. 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. I think it should be one tasklet latency added, but what is the other one? I meant that the latency in tasklet scheduling has to be added to the latency in scheduling the usb-storage thread. Or you could have a separate tasklet for each host controller. Yes, but I will compare tasklet with interrupt threaded handler first. Switching to a threaded interrupt handler offers more possibilities. Instead of moving just the givebacks to the thread, we could put almost all the processing there. (At least, we can for ehci-hcd. Other HCDs may not be able to do this.) At this point we are talking about multiple changes: Moving the givebacks to a tasklet or threaded handler. Changing the USB completion handlers so that they can be called with interrupts enabled. Allowing the tasklet/thread to run with interrupts enabled. Moving more of the HCD processing into the tasklet/thread. Maybe other things too. In principle, the first and second items can be done simultaneously. 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 05/10] USB: EHCI: make ehci-atmel a separate driver
On 23:04 Thu 07 Feb , manjunath.gou...@linaro.org wrote:
From: Manjunath Goudar manjunath.gou...@linaro.org
Separate the Atmel host controller driver from ehci-hcd host code
into its own driver module.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Andrew Victor li...@maxim.org.za
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
Best Regards,
J.
---
drivers/usb/host/Kconfig |7
drivers/usb/host/Makefile |1 +
drivers/usb/host/ehci-atmel.c | 78
++---
drivers/usb/host/ehci-hcd.c |6 +---
4 files changed, 51 insertions(+), 41 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 3689b7b..5a13f9d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -176,6 +176,13 @@ config USB_EHCI_HCD_ORION
---help---
Enables support for the on-chip EHCI controller on
Morvell Orion chips.
+config USB_EHCI_HCD_AT91
+tristate Support for Atmel on-chip EHCI USB controller
+depends on USB_EHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip EHCI controller on
+ Atmel chips.
config USB_EHCI_MSM
bool Support for MSM on-chip EHCI USB controller
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 23b07dd..96b4839 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_USB_EHCI_HCD_OMAP) += ehci-omap.o
obj-$(CONFIG_USB_EHCI_HCD_SPEAR)+= ehci-spear.o
obj-$(CONFIG_USB_EHCI_HCD_ORION)+= ehci-orion.o
obj-$(CONFIG_USB_OXU210HP_HCD) += oxu210hp-hcd.o
+obj-$(CONFIG_USB_EHCI_HCD_AT91) += ehci-atmel.o
obj-$(CONFIG_USB_ISP116X_HCD)+= isp116x-hcd.o
obj-$(CONFIG_USB_ISP1362_HCD)+= isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
diff --git a/drivers/usb/host/ehci-atmel.c b/drivers/usb/host/ehci-atmel.c
index 27639487..2f06711 100644
--- a/drivers/usb/host/ehci-atmel.c
+++ b/drivers/usb/host/ehci-atmel.c
@@ -15,6 +15,19 @@
#include linux/platform_device.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/io.h
+#include linux/dma-mapping.h
+
+#include ehci.h
+
+#define DRIVER_DESC EHCI atmel driver
+
+static const char hcd_name[] = ehci-atmel;
+static struct hc_driver __read_mostly ehci_atmel_hc_driver;
/* interface and function clocks */
static struct clk *iclk, *fclk;
@@ -60,41 +73,6 @@ static int ehci_atmel_setup(struct usb_hcd *hcd)
return ehci_setup(hcd);
}
-static const struct hc_driver ehci_atmel_hc_driver = {
- .description= hcd_name,
- .product_desc = Atmel EHCI UHP HS,
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /* generic hardware linkage */
- .irq= ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /* basic lifecycle operations */
- .reset = ehci_atmel_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /* managing i/o requests and associated device resources */
- .urb_enqueue= ehci_urb_enqueue,
- .urb_dequeue= ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
-
- /* scheduling support */
- .get_frame_number = ehci_get_frame,
-
- /* root hub support */
- .hub_status_data= ehci_hub_status_data,
- .hub_control= ehci_hub_control,
- .bus_suspend= ehci_bus_suspend,
- .bus_resume = ehci_bus_resume,
- .relinquish_port= ehci_relinquish_port,
- .port_handed_over = ehci_port_handed_over,
-
- .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
-
static u64 at91_ehci_dma_mask = DMA_BIT_MASK(32);
static int ehci_atmel_drv_probe(struct platform_device *pdev)
@@ -210,7 +188,35 @@ static struct platform_driver ehci_atmel_driver = {
.remove = ehci_atmel_drv_remove,
.shutdown = usb_hcd_platform_shutdown,
.driver = {
- .name = atmel-ehci,
+ .name = hcd_name,
.of_match_table = of_match_ptr(atmel_ehci_dt_ids),
},
};
+
+static const struct ehci_driver_overrides atmel_overrides __initdata = {
+
Re: [PATCH V3 2/7] usb: phy: add MODULE_LICENSE to phy-tegra-usb.c
On Wed, Jun 05, 2013 at 02:03:04PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com When this file is built as a module, it needs a MODULE_LICENSE in order to access many exported symbols. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Arnd Bergmann a...@arndb.de Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH V3 1/7] usb: phy: export ulpi_viewport_access_ops
On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote: From: Manjunath Goudar manjunath.gou...@linaro.org In order to build a ULPI PHY driver as a module, this symbol needs to be exported. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org [swarren, reworked Manjunath's patches to split them more logically] Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Arnd Bergmann a...@arndb.de This should go straight through Greg: Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 32/50] usb: gadget: at91_udc: prepare clk before calling enable
On Fri, Jun 07, 2013 at 08:08:18PM +0200, Boris BREZILLON wrote: Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to avoid common clk framework warnings. Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Wednesday 12 June 2013 10:35:44 Alan Stern wrote: On Wed, 12 Jun 2013, Ming Lei wrote: 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? Here's another possibility. A USB driver has a private lock, and it acquires this lock in its completion handler. But it also acquires this lock in other routines, and those other routines may be called by other drivers or subsystems in interrupt context. That is fatal. But again mechanically using _irqsave in complete() does the job. No other place can be affected. 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: [PATCH] usb/gadget: Add options to build only functions modules
On Mon, Apr 29, 2013 at 12:39:56PM +0200, Andrzej Pietrasiewicz wrote: A USB gadget can be set up entirely through configfs. This patch adds options to build the USB functions' modules without building old gadget modules, e.g. build usb_f_acm.ko or usb_f_ecm.ko, but not g_cdc.ko. Please see: http://www.spinics.net/lists/linux-usb/msg83460.html http://www.spinics.net/lists/linux-usb/msg85065.html http://www.spinics.net/lists/linux-usb/msg85156.html for what functions are already available through configfs; so far the equivalents of g_serial, g_ncm and g_cdc can be set up through configfs. Please note, that the actual gadget composition can consist of any functions available, not just those available in a given old g_xx.ko gadget. That is, one can take some functions found in g_serial, some in g_ncm and some in g_cdc, e.g. such a gadget can consist of acm, generic serial, obex and ecm, functions, while the g_serial consists of acm, generic serial, obex, the g_ncm consists of ncm and g_cdc consists of acm and ecm. The concept is illustrated in the table below, taking into account the currently available configfs support: --- | gadget | |--- function | g_serial | g_ncm | g_cdc | set up through configfs | --- acm| *| | *|o| generic serial | *| | |o| obex | *| | |o| ncm| | *| |o| ecm| | | *|o| | | | | | . . . . . . . . . . . . . . . . . . more functions to come . . . . . . . . . . . . . . . . . . --- * - built-in, mandatory, no other functions possible o - option So one can create, using only mkdir/echo/ln from shell, a gadget which provides e.g. acm, generic serial, obex and ecm without adding and compiling a new g_serial_with_ecm.c. A documentation file is added to Documentation/usb. Function's attributes are described in Documentation/ABI/*/configfs-usb-gadget* The latter might need adjusting the KernelVersion and Date tags. Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Doesn't apply and there are trailing whitespaces in a few places. This will be delayed for v3.12, sorry. -- balbi signature.asc Description: Digital signature
Re: Linux USB file storage gadget with new UDC
On Wed, 12 Jun 2013, victor yeo wrote: I did another usbmon capture from the moment usb cable is plugged into the Ubuntu x100e laptop. This time the usbmon does not have -75 error. When the SCSI_READ_10 command request for 4096 bytes of data, and the data is returned by the gadget, usbmon simply shows -108 error. The gadget driver log and usbmon trace are attached. Again, the -108 indicates that the host controller disabled the port. The usbmon trace confirms this. I think the most common reason for disabling a port in this way is that the device tried to transmit a packet across a microframe boundary. The FIFO size in gadget bulk out endpoint 1 is 512 bytes, so i break the 4096 bytes of data into 8 chunks of 512 bytes, before returning them to Ubuntu. I guess it would not be the root cause, won't it? It's hard to say without looking at the signals on the wire. Are you certain the hardware really is sending 512 bytes for each chunk? That's why you need to use a bus analyzer -- to see what's actually going on. 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
[PATCH 04/10] USB: OHCI: Properly handle ohci-ep93xx suspend
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-ep93xx.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 8704e9f..7c77f61 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -174,13 +174,17 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
+
+ ret = ohci_suspend(hcd, do_wakeup);
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
ep93xx_stop_hc(pdev-dev);
- return 0;
+ return ret;
}
static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] USB: OHCI: Properly handle ohci-exynos suspend
Suspend scenario in case of ohci-exynos glue was not properly handled as it was not suspending generic part of ohci controller.Calling explicitly the ohci_suspend() routine in exynos_ohci_suspend() will ensure proper handling of suspend scenario. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ohci-exynos.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index 6ff830c..6ad38ee 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -203,6 +203,7 @@ static int exynos_ohci_suspend(struct device *dev) struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd); struct ohci_hcd *ohci = hcd_to_ohci(hcd); struct platform_device *pdev = to_platform_device(dev); + bool do_wakeup = device_may_wakeup(dev); unsigned long flags; int rc = 0; @@ -226,6 +227,8 @@ static int exynos_ohci_suspend(struct device *dev) exynos_ohci_phy_disable(pdev); + rc = ohci_suspend(hcd, do_wakeup); + clk_disable_unprepare(exynos_ohci-clk); fail: -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend
Suspend scenario in case of ohci-s3c2410 glue was not properly handled as it was not suspending generic part of ohci controller.Calling explicitly the ohci_suspend() routine in ohci_hcd_s3c2410_drv_suspend() will ensure proper handling of suspend scenario. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ohci-s3c2410.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c index 8018bb1..2ffa693 100644 --- a/drivers/usb/host/ohci-s3c2410.c +++ b/drivers/usb/host/ohci-s3c2410.c @@ -430,6 +430,7 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev) struct platform_device *pdev = to_platform_device(dev); unsigned long flags; int rc = 0; + bool do_wakeup = device_may_wakeup(dev); /* * Root hub was already suspended. Disable irq emission and @@ -445,6 +446,8 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev) clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags); + rc = ohci_suspend(hcd, do_wakeup); + s3c2410_stop_hc(pdev); bail: spin_unlock_irqrestore(ohci-lock, flags); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] USB: OHCI: Properly handle ohci-da8xx suspend
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-da8xx.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..3b1d9bd 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,24 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+
ohci_da8xx_clock(0);
hcd-state = HC_STATE_SUSPENDED;
- dev-dev.power.power_state = PMSG_SUSPEND;
- return 0;
+ pdev-dev.power.power_state = PMSG_SUSPEND;
+ return ret;
}
static int ohci_da8xx_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] USB: OHCI:Properly handle ohci_suspend()routine in bus glue
Suspend scenario in case of ohci bus glue was not properly handled as it was not suspending generic part of ohci controller. Calling explicitly the ohci_suspend()routine will ensure proper handling of suspend scenario. Manjunath Goudar (10): USB: OHCI: Properly handle ohci-at91 suspend USB: OHCI: Properly handle ohci-s3c2410 suspend USB: OHCI: Properly handle ohci-da8xx suspend USB: OHCI: Properly handle ohci-ep93xx suspend USB: OHCI: Properly handle ohci-exynos suspend USB: OHCI: Properly handle ohci-omap suspend USB: OHCI: Properly handle ohci-platform suspend USB: OHCI: Properly handle ohci-pxa27x suspend USB: OHCI: Properly handle ohci-sm501 suspend USB: OHCI: Properly handle ohci-spear suspend drivers/usb/host/ohci-at91.c |8 ++-- drivers/usb/host/ohci-da8xx.c| 13 + drivers/usb/host/ohci-ep93xx.c |6 +- drivers/usb/host/ohci-exynos.c |3 +++ drivers/usb/host/ohci-omap.c | 11 --- drivers/usb/host/ohci-platform.c |6 +- drivers/usb/host/ohci-pxa27x.c |6 +- drivers/usb/host/ohci-s3c2410.c |3 +++ drivers/usb/host/ohci-sm501.c|9 +++-- drivers/usb/host/ohci-spear.c| 10 +++--- 10 files changed, 58 insertions(+), 17 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] USB: OHCI: Properly handle ohci-at91 suspend
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend()routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-at91.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..28400a7 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,12 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
- if (device_may_wakeup(pdev-dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+
+ if (do_wakeup)
enable_irq_wake(hcd-irq);
/*
@@ -637,7 +641,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] USB: OHCI: Properly handle ohci-omap suspend
Suspend scenario in case of ohci-omap glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_omap_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-omap.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index b900dba..a638a14 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -423,16 +423,21 @@ static int ohci_hcd_omap_drv_remove(struct
platform_device *dev)
#ifdef CONFIG_PM
-static int ohci_omap_suspend(struct platform_device *dev, pm_message_t message)
+static int ohci_omap_suspend(struct platform_device *pdev, pm_message_t
message)
{
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(dev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+
omap_ohci_clock_power(0);
- return 0;
+ return ret;
}
static int ohci_omap_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] USB: OHCI: Properly handle ohci-pxa27x suspend
Suspend scenario in case of ohci-pxa27x glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_hcd_pxa27x_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-pxa27x.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 3a9c01d..9dbfeb8 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -564,13 +564,17 @@ static int ohci_hcd_pxa27x_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct pxa27x_ohci *ohci = to_pxa27x_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
if (time_before(jiffies, ohci-ohci.next_statechange))
msleep(5);
ohci-ohci.next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+
pxa27x_stop_hc(ohci, dev);
- return 0;
+ return ret;
}
static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] USB: OHCI: Properly handle ohci-spear suspend
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-spear.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..5a843f0 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,24 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+
clk_disable_unprepare(sohci_p-clk);
- return 0;
+ return ret;
}
static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] USB: OHCI: Properly handle ohci-platform suspend
Suspend scenario in case of ohci-platform glue was not properly handled as it was not suspending generic part of ohci controller.Calling explicitly the ohci_suspend() routine in ohci_platform_suspend() will ensure proper handling of suspend scenario. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ohci-platform.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c index bc30475..ad8cb3b 100644 --- a/drivers/usb/host/ohci-platform.c +++ b/drivers/usb/host/ohci-platform.c @@ -142,11 +142,15 @@ static int ohci_platform_suspend(struct device *dev) struct usb_ohci_pdata *pdata = dev-platform_data; struct platform_device *pdev = container_of(dev, struct platform_device, dev); + bool do_wakeup = device_may_wakeup(dev); + int ret; + + ret = ohci_suspend(hcd, do_wakeup); if (pdata-power_suspend) pdata-power_suspend(pdev); - return 0; + return ret; } static int ohci_platform_resume(struct device *dev) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] USB: OHCI: Properly handle ohci-sm501 suspend
Suspend scenario in case of ohci-sm501 glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_sm501_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-sm501.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index d479d5d..f4f2da0 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -216,14 +216,19 @@ static int ohci_hcd_sm501_drv_remove(struct
platform_device *pdev)
static int ohci_sm501_suspend(struct platform_device *pdev, pm_message_t msg)
{
struct device *dev = pdev-dev;
- struct ohci_hcd *ohci = hcd_to_ohci(platform_get_drvdata(pdev));
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+
sm501_unit_power(dev-parent, SM501_GATE_USB_HOST, 0);
- return 0;
+ return ret;
}
static int ohci_sm501_resume(struct platform_device *pdev)
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc3: fix typo in comment of dwc3_ep
Change intervall into interval.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/dwc3/core.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b69d322..0fc54cc 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -415,7 +415,7 @@ struct dwc3_event_buffer {
* @number: endpoint number (1 - 15)
* @type: set to bmAttributes USB_ENDPOINT_XFERTYPE_MASK
* @resource_index: Resource transfer index
- * @interval: the intervall on which the ISOC transfer is started
+ * @interval: the interval on which the ISOC transfer is started
* @name: a human readable name e.g. ep1out-bulk
* @direction: true for TX, false for RX
* @stream_capable: true when streams are enabled
--
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: [PATCH 03/10] USB: OHCI: Properly handle ohci-da8xx suspend
Hello.
On 12-06-2013 19:28, Manjunath Goudar wrote:
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller.Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-da8xx.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 6aaa9c9..3b1d9bd 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,24 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
Could you align = with other intializers above?
+ int ret;
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/6] USB: OHCI: more bus glues as separate modules
These patches are for separating the SOC On-Chip ohci host controller from ohci-hcd host code into its own driver module. This work is part of enabling multi-platform kernels on ARM. V2: In patch 5/6 and 6/6: -Set non-standard fields in hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. In patch 1/6 to 4/6 -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. Manjunath Goudar (6): USB: OHCI: make ohci-exynos a separate driver USB: OHCI: make ohci-omap a separate driver USB: OHCI: make ohci-omap3 a separate driver USB: OHCI: make ohci-spear a separate driver USB: OHCI: make ohci-at91 a separate driver USB: OHCI: make ohci-s3c2410 a separate driver drivers/usb/host/Kconfig| 30 ++- drivers/usb/host/Makefile |6 ++ drivers/usb/host/ohci-at91.c| 148 +++--- drivers/usb/host/ohci-exynos.c | 167 --- drivers/usb/host/ohci-hcd.c | 108 - drivers/usb/host/ohci-omap.c| 156 drivers/usb/host/ohci-omap3.c | 120 ++-- drivers/usb/host/ohci-s3c2410.c | 129 ++ drivers/usb/host/ohci-spear.c | 140 +--- 9 files changed, 370 insertions(+), 634 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/6] USB: OHCI: make ohci-omap3 a separate driver
Separate the TI OHCI OMAP3 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
V2:
-ohci_setup() removed because it is called in .reset member
of the ohci_hc_driver structure.
-The improper multi-line commenting style written in proper way.
('*' characters aligned in vertically).
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Anand Gadiyar gadi...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig |2 +-
drivers/usb/host/Makefile |1 +
drivers/usb/host/ohci-hcd.c | 18 ---
drivers/usb/host/ohci-omap3.c | 120 ++---
4 files changed, 42 insertions(+), 99 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 7a87c72..db20e43 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -383,7 +383,7 @@ config USB_OHCI_HCD_OMAP1
Enables support for the OHCI controller on OMAP1/2 chips.
config USB_OHCI_HCD_OMAP3
- bool OHCI support for OMAP3 and later chips
+ tristate OHCI support for OMAP3 and later chips
depends on (ARCH_OMAP3 || ARCH_OMAP4)
default y
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 52f2c44..9f2f5f3 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_USB_OHCI_HCD_PCI)+= ohci-pci.o
obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 1abc1e7..cad51d2 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE (GPL);
#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver
#endif
-#ifdef CONFIG_USB_OHCI_HCD_OMAP3
-#include ohci-omap3.c
-#define OMAP3_PLATFORM_DRIVER ohci_hcd_omap3_driver
-#endif
-
#if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx)
#include ohci-pxa27x.c
#define PLATFORM_DRIVERohci_hcd_pxa27x_driver
@@ -1284,12 +1279,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_platform;
#endif
-#ifdef OMAP3_PLATFORM_DRIVER
- retval = platform_driver_register(OMAP3_PLATFORM_DRIVER);
- if (retval 0)
- goto error_omap3_platform;
-#endif
-
#ifdef OF_PLATFORM_DRIVER
retval = platform_driver_register(OF_PLATFORM_DRIVER);
if (retval 0)
@@ -1393,10 +1382,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(OF_PLATFORM_DRIVER);
error_of_platform:
#endif
-#ifdef OMAP3_PLATFORM_DRIVER
- platform_driver_unregister(OMAP3_PLATFORM_DRIVER);
- error_omap3_platform:
-#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
error_platform:
@@ -1448,9 +1433,6 @@ static void __exit ohci_hcd_mod_exit(void)
#ifdef OF_PLATFORM_DRIVER
platform_driver_unregister(OF_PLATFORM_DRIVER);
#endif
-#ifdef OMAP3_PLATFORM_DRIVER
- platform_driver_unregister(OMAP3_PLATFORM_DRIVER);
-#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
#endif
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 8f71357..b7c75ab 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -29,90 +29,22 @@
* - add kernel-doc
*/
+#include linux/dma-mapping.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/usb/otg.h
#include linux/platform_device.h
#include linux/pm_runtime.h
-#include linux/of.h
-#include linux/dma-mapping.h
-
-/*-*/
-
-static int ohci_omap3_init(struct usb_hcd *hcd)
-{
- dev_dbg(hcd-self.controller, starting OHCI controller\n);
-
- return ohci_init(hcd_to_ohci(hcd));
-}
-
-/*-*/
-
-static int ohci_omap3_start(struct usb_hcd *hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int ret;
-
- /*
-* RemoteWakeupConnected has to be set explicitly before
-* calling ohci_run. The reset value of RWC is 0.
-*/
- ohci-hc_control = OHCI_CTRL_RWC;
- writel(OHCI_CTRL_RWC, ohci-regs-control);
+#include linux/usb.h
+#include linux/usb/hcd.h
- ret = ohci_run(ohci);
+#include ohci.h
- if (ret 0) {
- dev_err(hcd-self.controller, can't start\n);
-
[PATCH V2 2/6] USB: OHCI: make ohci-omap a separate driver
Separate the TI OHCI OMAP1/2 host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
V2:
-omap_ohci_clock_power(0) called in usb_hcd_omap_remove().
-Removed ohci_setup() call from usb_hcd_omap_probe() and ohci_omap_reset().
-host_enabled and host_initialized variables aren't used for anything
thats what removed.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Felipe Balbi ba...@ti.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig |2 +-
drivers/usb/host/Makefile|1 +
drivers/usb/host/ohci-hcd.c | 18 -
drivers/usb/host/ohci-omap.c | 156 +-
4 files changed, 51 insertions(+), 126 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 75456f2..7a87c72 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -376,7 +376,7 @@ config USB_OHCI_HCD
if USB_OHCI_HCD
config USB_OHCI_HCD_OMAP1
- bool OHCI support for OMAP1/2 chips
+ tristate OHCI support for OMAP1/2 chips
depends on ARCH_OMAP1
default y
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index bf4a4b2..52f2c44 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
obj-$(CONFIG_USB_OHCI_HCD_PCI) += ohci-pci.o
obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
+obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 2980bb6..1abc1e7 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1182,11 +1182,6 @@ MODULE_LICENSE (GPL);
#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver
#endif
-#ifdef CONFIG_USB_OHCI_HCD_OMAP1
-#include ohci-omap.c
-#define OMAP1_PLATFORM_DRIVER ohci_hcd_omap_driver
-#endif
-
#ifdef CONFIG_USB_OHCI_HCD_OMAP3
#include ohci-omap3.c
#define OMAP3_PLATFORM_DRIVER ohci_hcd_omap3_driver
@@ -1289,12 +1284,6 @@ static int __init ohci_hcd_mod_init(void)
goto error_platform;
#endif
-#ifdef OMAP1_PLATFORM_DRIVER
- retval = platform_driver_register(OMAP1_PLATFORM_DRIVER);
- if (retval 0)
- goto error_omap1_platform;
-#endif
-
#ifdef OMAP3_PLATFORM_DRIVER
retval = platform_driver_register(OMAP3_PLATFORM_DRIVER);
if (retval 0)
@@ -1408,10 +1397,6 @@ static int __init ohci_hcd_mod_init(void)
platform_driver_unregister(OMAP3_PLATFORM_DRIVER);
error_omap3_platform:
#endif
-#ifdef OMAP1_PLATFORM_DRIVER
- platform_driver_unregister(OMAP1_PLATFORM_DRIVER);
- error_omap1_platform:
-#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
error_platform:
@@ -1466,9 +1451,6 @@ static void __exit ohci_hcd_mod_exit(void)
#ifdef OMAP3_PLATFORM_DRIVER
platform_driver_unregister(OMAP3_PLATFORM_DRIVER);
#endif
-#ifdef OMAP1_PLATFORM_DRIVER
- platform_driver_unregister(OMAP1_PLATFORM_DRIVER);
-#endif
#ifdef PLATFORM_DRIVER
platform_driver_unregister(PLATFORM_DRIVER);
#endif
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 8747fa6..b900dba 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -14,12 +14,21 @@
* This file is licenced under the GPL.
*/
-#include linux/signal.h
-#include linux/jiffies.h
-#include linux/platform_device.h
#include linux/clk.h
+#include linux/dma-mapping.h
#include linux/err.h
#include linux/gpio.h
+#include linux/io.h
+#include linux/jiffies.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb/otg.h
+#include linux/platform_device.h
+#include linux/signal.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+
+#include ohci.h
#include asm/io.h
#include asm/mach-types.h
@@ -42,10 +51,7 @@
#define OMAP1510_LB_MMU_RAM_H 0xfffec234
#define OMAP1510_LB_MMU_RAM_L 0xfffec238
-
-#ifndef CONFIG_ARCH_OMAP
-#error This file is OMAP bus glue. CONFIG_OMAP must be defined.
-#endif
+#define DRIVER_DESC OHCI OMAP driver
#ifdef CONFIG_TPS65010
#include linux/i2c/tps65010.h
@@ -68,8 +74,9 @@ extern int ocpi_enable(void);
static struct clk *usb_host_ck;
static struct clk *usb_dc_ck;
-static int host_enabled;
-static int host_initialized;
+
+static const char hcd_name[] = ohci-omap;
+static struct hc_driver __read_mostly ohci_omap_hc_driver;
static void omap_ohci_clock_power(int on)
{
@@ -188,21 +195,21 @@ static void start_hnp(struct ohci_hcd *ohci)
/*-*/
[PATCH V2 6/6] USB: OHCI: make ohci-s3c2410 a separate driver
Separate the Samsung OHCI S3C host controller driver from ohci-hcd host code so that it can be built as a separate driver module. This work is part of enabling multi-platform kernels on ARM; it would be nice to have in 3.11. V2: -Set non-standard fields in ohci_s3c2410_hc_driver manually, rather than relying on an expanded struct ohci_driver_overrides. -Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than relying on ohci_hub_control and hub_status_data being exported. -ohci_setup() has been removed because it is called in .reset member of the ohci_hc_driver structure. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org --- drivers/usb/host/Kconfig|8 +++ drivers/usb/host/Makefile |1 + drivers/usb/host/ohci-hcd.c | 18 -- drivers/usb/host/ohci-s3c2410.c | 129 ++- 4 files changed, 67 insertions(+), 89 deletions(-) diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index e4dc9ab..0b7b0f7 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR Enables support for the on-chip OHCI controller on ST SPEAr chips. +config USB_OHCI_HCD_S3C +tristate Support for S3C on-chip OHCI USB controller +depends on USB_OHCI_HCD (ARCH_S3C24XX) || (ARCH_S3C64XX) +default y +---help--- + Enables support for the on-chip OHCI controller on + S3C chips. + config USB_OHCI_HCD_AT91 tristate Support for Atmel on-chip OHCI USB controller depends on USB_OHCI_HCD ARCH_AT91 diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile index f3e02c0..9fa4b3e 100644 --- a/drivers/usb/host/Makefile +++ b/drivers/usb/host/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o +obj-$(CONFIG_USB_OHCI_HCD_S3C) += ohci-s3c2410.o obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o obj-$(CONFIG_USB_FHCI_HCD) += fhci.o diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index b48c892..b69a49e 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1177,11 +1177,6 @@ MODULE_LICENSE (GPL); #define SA_DRIVER ohci_hcd_sa_driver #endif -#if defined(CONFIG_ARCH_S3C24XX) || defined(CONFIG_ARCH_S3C64XX) -#include ohci-s3c2410.c -#define S3C2410_PLATFORM_DRIVERohci_hcd_s3c2410_driver -#endif - #if defined(CONFIG_PXA27x) || defined(CONFIG_PXA3xx) #include ohci-pxa27x.c #define PLATFORM_DRIVERohci_hcd_pxa27x_driver @@ -1293,12 +1288,6 @@ static int __init ohci_hcd_mod_init(void) goto error_tmio; #endif -#ifdef S3C2410_PLATFORM_DRIVER - retval = platform_driver_register(S3C2410_PLATFORM_DRIVER); - if (retval 0) - goto error_s3c2410; -#endif - #ifdef EP93XX_PLATFORM_DRIVER retval = platform_driver_register(EP93XX_PLATFORM_DRIVER); if (retval 0) @@ -1332,10 +1321,6 @@ static int __init ohci_hcd_mod_init(void) platform_driver_unregister(EP93XX_PLATFORM_DRIVER); error_ep93xx: #endif -#ifdef S3C2410_PLATFORM_DRIVER - platform_driver_unregister(S3C2410_PLATFORM_DRIVER); - error_s3c2410: -#endif #ifdef TMIO_OHCI_DRIVER platform_driver_unregister(TMIO_OHCI_DRIVER); error_tmio: @@ -1382,9 +1367,6 @@ static void __exit ohci_hcd_mod_exit(void) #ifdef EP93XX_PLATFORM_DRIVER platform_driver_unregister(EP93XX_PLATFORM_DRIVER); #endif -#ifdef S3C2410_PLATFORM_DRIVER - platform_driver_unregister(S3C2410_PLATFORM_DRIVER); -#endif #ifdef TMIO_OHCI_DRIVER platform_driver_unregister(TMIO_OHCI_DRIVER); #endif diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c index e125770..8018bb1 100644 --- a/drivers/usb/host/ohci-s3c2410.c +++ b/drivers/usb/host/ohci-s3c2410.c @@ -19,17 +19,34 @@ * This file is licenced under the GPL. */ -#include linux/platform_device.h #include linux/clk.h +#include linux/io.h +#include linux/kernel.h +#include linux/module.h +#include linux/platform_device.h #include linux/platform_data/usb-ohci-s3c2410.h +#include linux/usb.h +#include linux/usb/hcd.h + +#include ohci.h + #define valid_port(idx) ((idx) == 1 || (idx) == 2) /* clock device associated with the hcd */ + +#define DRIVER_DESC OHCI S3C driver + +static const char hcd_name[] = ohci-s3c; + static struct clk *clk; static struct clk *usb_clk; +static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq, u16 wValue, +u16 wIndex, char *buf, u16 wLength); +static int
[PATCH V2 5/6] USB: OHCI: make ohci-at91 a separate driver
Separate the TI OHCI Atmel host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
V2:
-Set non-standard fields in ohci_at91_hc_driver manually, rather than
relying on an expanded struct ohci_driver_overrides.
-Save orig_ohci_hub_control and orig_ohci_hub_status_data rather than
relying on ohci_hub_control and hub_status_data being exported.
-ohci_setup() has been removed because it is called in .reset member
of the ohci_hc_driver structure.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig |8 +++
drivers/usb/host/Makefile|1 +
drivers/usb/host/ohci-at91.c | 148 +++---
drivers/usb/host/ohci-hcd.c | 18 -
4 files changed, 74 insertions(+), 101 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 46c2f42..e4dc9ab 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -390,6 +390,14 @@ config USB_OHCI_HCD_SPEAR
Enables support for the on-chip OHCI controller on
ST SPEAr chips.
+config USB_OHCI_HCD_AT91
+tristate Support for Atmel on-chip OHCI USB controller
+depends on USB_OHCI_HCD ARCH_AT91
+default y
+---help---
+ Enables support for the on-chip OHCI controller on
+ Atmel chips.
+
config USB_OHCI_HCD_OMAP3
tristate OHCI support for OMAP3 and later chips
depends on (ARCH_OMAP3 || ARCH_OMAP4)
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 26cb6b3..f3e02c0 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP1) += ohci-omap.o
obj-$(CONFIG_USB_OHCI_HCD_OMAP3) += ohci-omap3.o
obj-$(CONFIG_USB_OHCI_HCD_SPEAR) += ohci-spear.o
+obj-$(CONFIG_USB_OHCI_HCD_AT91)+= ohci-at91.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 2ee1496..fb2f127 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -13,27 +13,41 @@
*/
#include linux/clk.h
-#include linux/platform_device.h
+#include linux/dma-mapping.h
#include linux/of_platform.h
#include linux/of_gpio.h
+#include linux/platform_device.h
#include linux/platform_data/atmel.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/usb.h
+#include linux/usb/hcd.h
#include mach/hardware.h
#include asm/gpio.h
#include mach/cpu.h
-#ifndef CONFIG_ARCH_AT91
-#error CONFIG_ARCH_AT91 must be defined.
-#endif
+
+#include ohci.h
#define valid_port(index) ((index) = 0 (index) AT91_MAX_USBH_PORTS)
#define at91_for_each_port(index) \
for ((index) = 0; (index) AT91_MAX_USBH_PORTS; (index)++)
/* interface and function clocks; sometimes also an AHB clock */
+
+#define DRIVER_DESC OHCI Atmel driver
+
+static const char hcd_name[] = ohci-atmel;
+
+static struct hc_driver __read_mostly ohci_at91_hc_driver;
static struct clk *iclk, *fclk, *hclk;
static int clocked;
+static int (*orig_ohci_hub_control)(struct usb_hcd *hcd, u16 typeReq, u16
wValue,
+ u16 wIndex, char *buf, u16 wLength);
+static int (*orig_ohci_hub_status_data)(struct usb_hcd *hcd, char *buf);
extern int usb_disabled(void);
@@ -111,6 +125,8 @@ static void usb_hcd_at91_remove (struct usb_hcd *, struct
platform_device *);
static int usb_hcd_at91_probe(const struct hc_driver *driver,
struct platform_device *pdev)
{
+ struct at91_usbh_data *board;
+ struct ohci_hcd *ohci;
int retval;
struct usb_hcd *hcd = NULL;
@@ -163,8 +179,11 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
goto err5;
}
+ board = hcd-self.controller-platform_data;
+ ohci = hcd_to_ohci(hcd);
+ ohci-num_ports = board-ports;
at91_start_hc(pdev);
- ohci_hcd_init(hcd_to_ohci(hcd));
+ ohci_setup(hcd);
retval = usb_add_hcd(hcd, pdev-resource[1].start, IRQF_SHARED);
if (retval == 0)
@@ -221,36 +240,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
}
/*-*/
-
-static int
-ohci_at91_reset (struct usb_hcd *hcd)
-{
- struct at91_usbh_data *board = hcd-self.controller-platform_data;
- struct ohci_hcd *ohci = hcd_to_ohci (hcd);
- int ret;
-
- if ((ret = ohci_init(ohci)) 0)
- return ret;
-
- ohci-num_ports = board-ports;
-
[PATCH V2 1/6] USB: OHCI: make ohci-exynos a separate driver
Separate the Samsung OHCI EXYNOS host controller driver from ohci-hcd
host code so that it can be built as a separate driver module.
This work is part of enabling multi-platform kernels on ARM;
it would be nice to have in 3.11.
V2:
-exynos_ohci_hcd structure assignment error fixed.
-Removed multiple usb_create_hcd() from prob funtion.
-platform_set_drvdata() called before exynos_ohci_phy_enable().
-ohci_setup() removed because it is called in .reset member
of the ohci_hc_driver structure
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: Arnd Bergmann a...@arndb.de
Cc: Jingoo Han jg1@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Greg KH g...@kroah.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/Kconfig |2 +-
drivers/usb/host/Makefile |1 +
drivers/usb/host/ohci-exynos.c | 167 +---
drivers/usb/host/ohci-hcd.c| 18 -
4 files changed, 71 insertions(+), 117 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index f35f71e..75456f2 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -463,7 +463,7 @@ config USB_OHCI_SH
If you use the PCI OHCI controller, this option is not necessary.
config USB_OHCI_EXYNOS
- boolean OHCI support for Samsung EXYNOS SoC Series
+ tristate OHCI support for Samsung EXYNOS SoC Series
depends on ARCH_EXYNOS
help
Enable support for the Samsung Exynos SOC's on-chip OHCI controller.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index d1a34e0..bf4a4b2 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_USB_ISP1362_HCD) += isp1362-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
obj-$(CONFIG_USB_OHCI_HCD_PCI) += ohci-pci.o
obj-$(CONFIG_USB_OHCI_HCD_PLATFORM)+= ohci-platform.o
+obj-$(CONFIG_USB_OHCI_EXYNOS) += ohci-exynos.o
obj-$(CONFIG_USB_UHCI_HCD) += uhci-hcd.o
obj-$(CONFIG_USB_FHCI_HCD) += fhci.o
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index b0b542c..6ff830c 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -12,24 +12,39 @@
*/
#include linux/clk.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
#include linux/of.h
#include linux/platform_device.h
#include linux/platform_data/usb-ohci-exynos.h
#include linux/usb/phy.h
#include linux/usb/samsung_usb_phy.h
+#include linux/usb.h
+#include linux/usb/hcd.h
+#include linux/usb/otg.h
+
+#include ohci.h
+
+#define DRIVER_DESC OHCI exynos driver
+
+static const char hcd_name[] = ohci-exynos;
+static struct hc_driver __read_mostly exynos_ohci_hc_driver;
+
+#define to_exynos_ohci(hcd) (struct exynos_ohci_hcd *)(hcd_to_ohci(hcd)-priv)
struct exynos_ohci_hcd {
- struct device *dev;
- struct usb_hcd *hcd;
struct clk *clk;
struct usb_phy *phy;
struct usb_otg *otg;
struct exynos4_ohci_platdata *pdata;
};
-static void exynos_ohci_phy_enable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_enable(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(exynos_ohci-dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci-phy)
usb_phy_init(exynos_ohci-phy);
@@ -37,9 +52,10 @@ static void exynos_ohci_phy_enable(struct exynos_ohci_hcd
*exynos_ohci)
exynos_ohci-pdata-phy_init(pdev, USB_PHY_TYPE_HOST);
}
-static void exynos_ohci_phy_disable(struct exynos_ohci_hcd *exynos_ohci)
+static void exynos_ohci_phy_disable(struct platform_device *pdev)
{
- struct platform_device *pdev = to_platform_device(exynos_ohci-dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
+ struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
if (exynos_ohci-phy)
usb_phy_shutdown(exynos_ohci-phy);
@@ -47,63 +63,11 @@ static void exynos_ohci_phy_disable(struct exynos_ohci_hcd
*exynos_ohci)
exynos_ohci-pdata-phy_exit(pdev, USB_PHY_TYPE_HOST);
}
-static int ohci_exynos_reset(struct usb_hcd *hcd)
-{
- return ohci_init(hcd_to_ohci(hcd));
-}
-
-static int ohci_exynos_start(struct usb_hcd *hcd)
-{
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
- int ret;
-
- ohci_dbg(ohci, ohci_exynos_start, ohci:%p, ohci);
-
- ret = ohci_run(ohci);
- if (ret 0) {
- dev_err(hcd-self.controller, can't start %s\n,
- hcd-self.bus_name);
- ohci_stop(hcd);
- return ret;
- }
-
- return 0;
-}
-
-static const struct hc_driver exynos_ohci_hc_driver = {
- .description= hcd_name,
- .product_desc = EXYNOS OHCI
Re: [PATCH 02/10] USB: OHCI: Properly handle ohci-s3c2410 suspend
Hello. On 12-06-2013 19:28, Manjunath Goudar wrote: Suspend scenario in case of ohci-s3c2410 glue was not properly handled as it was not suspending generic part of ohci controller.Calling explicitly the ohci_suspend() routine in ohci_hcd_s3c2410_drv_suspend() will ensure proper handling of suspend scenario. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org Cc: Arnd Bergmann a...@arndb.de Cc: Alan Stern st...@rowland.harvard.edu Cc: Greg KH g...@kroah.com Cc: linux-usb@vger.kernel.org --- drivers/usb/host/ohci-s3c2410.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c index 8018bb1..2ffa693 100644 --- a/drivers/usb/host/ohci-s3c2410.c +++ b/drivers/usb/host/ohci-s3c2410.c @@ -430,6 +430,7 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev) struct platform_device *pdev = to_platform_device(dev); unsigned long flags; int rc = 0; + bool do_wakeup = device_may_wakeup(dev); /* * Root hub was already suspended. Disable irq emission and @@ -445,6 +446,8 @@ static int ohci_hcd_s3c2410_drv_suspend(struct device *dev) clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags); + rc = ohci_suspend(hcd, do_wakeup); + Why not call ohci_suspend with device_may_wakeup(pdev-dev) result directly, saving on a local variable only used once? Same comment about the following patches... 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: [PATCH 01/10] USB: OHCI: Properly handle ohci-at91 suspend
On Wed, 12 Jun 2013, Manjunath Goudar wrote:
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend()routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..28400a7 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,12 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
- if (device_may_wakeup(pdev-dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+
+ if (do_wakeup)
enable_irq_wake(hcd-irq);
/*
@@ -637,7 +641,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
If ohci_suspend() fails, we should return right away. Don't execute
the enable_irq_wake() and all the other stuff.
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 V3 1/7] usb: phy: export ulpi_viewport_access_ops
On 06/12/2013 09:06 AM, Felipe Balbi wrote: On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote: From: Manjunath Goudar manjunath.gou...@linaro.org In order to build a ULPI PHY driver as a module, this symbol needs to be exported. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org [swarren, reworked Manjunath's patches to split them more logically] Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Arnd Bergmann a...@arndb.de This should go straight through Greg: All the patches in this series build on top of each-other, so I think need to be applied in the same branch. Applying this patch in branch A but the others in branch B will cause the build to fail in branch B if the driver is built as a module, since ulpi_viewport_access_ops isn't exported, right? And this series is also based on top of all the Tegra driver changes in your PHY branch, so I believe that is the correct place to apply this. -- 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
[RFC PATCH 1/1] Intel xhci: refactor EHCI/xHCI port switching
Make the Linux xHCI driver automatically try to switchover the EHCI ports to
xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI host.
This means we will no longer have to add Intel xHCI hosts to a quirks list when
the PCI device IDs change. Simply continuing to add new Intel xHCI PCI device
IDs to the quirks list is not sustainable.
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/ehci-pci.c | 15 +--
drivers/usb/host/pci-quirks.c | 55 ++--
drivers/usb/host/pci-quirks.h |3 +-
drivers/usb/host/xhci-pci.c |5 ++-
4 files changed, 30 insertions(+), 48 deletions(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 595d210..7dd09ea 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -325,19 +325,6 @@ static bool usb_is_intel_switchable_ehci(struct pci_dev
*pdev)
pdev-device == 0x9C26);
}
-static void ehci_enable_xhci_companion(void)
-{
- struct pci_dev *companion = NULL;
-
- /* The xHCI and EHCI controllers are not on the same PCI slot */
- for_each_pci_dev(companion) {
- if (!usb_is_intel_switchable_xhci(companion))
- continue;
- usb_enable_xhci_ports(companion);
- return;
- }
-}
-
static int ehci_pci_resume(struct usb_hcd *hcd, bool hibernated)
{
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
@@ -360,7 +347,7 @@ static int ehci_pci_resume(struct usb_hcd *hcd, bool
hibernated)
* port was already switched over.
*/
if (usb_is_intel_switchable_ehci(pdev))
- ehci_enable_xhci_companion();
+ usb_enable_intel_xhci_ports();
if (ehci_resume(hcd, hibernated) != 0)
(void) ehci_pci_reinit(ehci, pdev);
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index b9848e4..bbc4e98 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -89,6 +89,11 @@ static struct amd_chipset_info {
int probe_result;
} amd_chipset;
+static struct intel_chipset_info {
+ struct pci_dev *xhci_dev;
+ bool switchable_ports;
+} intel_chipset;
+
static DEFINE_SPINLOCK(amd_lock);
void sb800_prefetch(struct device *dev, int on)
@@ -735,32 +740,6 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
return -ETIMEDOUT;
}
-#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI0x8C31
-#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31
-
-bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
-{
- return pdev-class == PCI_CLASS_SERIAL_USB_XHCI
- pdev-vendor == PCI_VENDOR_ID_INTEL
- pdev-device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI;
-}
-
-/* The Intel Lynx Point chipset also has switchable ports. */
-bool usb_is_intel_lpt_switchable_xhci(struct pci_dev *pdev)
-{
- return pdev-class == PCI_CLASS_SERIAL_USB_XHCI
- pdev-vendor == PCI_VENDOR_ID_INTEL
- (pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI ||
-pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI);
-}
-
-bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
-{
- return usb_is_intel_ppt_switchable_xhci(pdev) ||
- usb_is_intel_lpt_switchable_xhci(pdev);
-}
-EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
-
/*
* Intel's Panther Point chipset has two host controllers (EHCI and xHCI) that
* share some number of ports. These ports can be switched between either
@@ -779,10 +758,16 @@ EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
* terminations before switching the USB 2.0 wires over, so that USB 3.0
* devices connect at SuperSpeed, rather than at USB 2.0 speeds.
*/
-void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
+void usb_enable_intel_xhci_ports(void)
{
+ struct pci_dev *xhci_pdev;
u32 ports_available;
+ if (!intel_chipset.switchable_ports || !intel_chipset.xhci_dev)
+ return;
+
+ xhci_pdev = intel_chipset.xhci_dev;
+
/* Don't switchover the ports if the user hasn't compiled the xHCI
* driver. Otherwise they will see dead USB ports that don't power
* the devices.
@@ -840,7 +825,7 @@ void usb_enable_xhci_ports(struct pci_dev *xhci_pdev)
dev_dbg(xhci_pdev-dev, USB 2.0 ports that are now switched over
to xHCI: 0x%x\n, ports_available);
}
-EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+EXPORT_SYMBOL_GPL(usb_enable_intel_xhci_ports);
void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
{
@@ -921,8 +906,18 @@ static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
hc_init:
- if (usb_is_intel_switchable_xhci(pdev))
- usb_enable_xhci_ports(pdev);
+ if (pdev-vendor == PCI_VENDOR_ID_INTEL)
[GIT PULL] USB patches for v3.11 merge window
Hi Greg,
Here's my pull request for v3.11 merge window. It's rather
large. Let me know if you want any changes.
cheers
The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.11
for you to fetch changes up to b4b1ceec0c3e87065787e7da4c8c3fd7549660b8:
usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12 18:11:51
+0300)
usb: patches for v3.11 merge window
All function drivers are now converted to our new configfs-based
binding. Eventually this will help us getting rid of in-kernel
gadget drivers and only keep function drivers in the kernel.
MUSB was taught that it needs to be built for host-only and
device-only modes too. We had this support long ago but it
involved a ridiculous amount of ifdefs. Now we have a much
cleaner approach.
Samsung Exynos4 platform now implements HSIC support.
We're introducing support for AB8540 and AB9540 PHYs.
MUSB module reinsertion now works as expected, before we were
getting -EBUSY being returned by the resource checks done on
driver core.
DWC3 now has minimum support for TI's AM437x series of SoCs.
OMAP5 USB3 PHY learned one extra DPLL configuration values because
that PHY is reused in TI's DRA7xx devices.
Users can now select a PHY without enabling the PHY layer first.
We're introducing support for Faraday fotg210 UDCs.
Last, but not least, the usual set of non-critical fixes and cleanups
ranging from usage of platform_{get,set}_drvdata to lock improvements.
Signed-of-by: Felipe Balbi ba...@ti.com
Alexey Khoroshilov (1):
usb: gadget: r8a66597-udc: do not unlock unheld spinlock in
r8a66597_sudmac_irq()
Andrzej Pietrasiewicz (40):
usb: gadget: u_ether: convert into module
usb: gadget: rndis: convert into module
usb: gadget: u_ether: construct with default values and add
setters/getters
usb: gadget: f_ncm: convert to new function interface with backward
compatibility
usb: gadget: ncm: convert to new function interface
usb: gadget: f_ncm: remove compatibility layer
usb: gadget: f_ncm: use usb_gstrings_attach
usb: gadget: f_ncm: add configfs support
usb: gadget: add helpers for configfs support for USB Ethernet
usb: gadget: f_ecm: convert to new function interface with backward
compatibility
usb: gadget: cdc2: convert to new interface of f_ecm
usb: gadget: f_ecm: use usb_gstrings_attach
usb: gadget: f_ecm: add configfs support
usb: gadget: f_obex: use usb_gstrings_attach
usb: gadget: nokia: convert to new interface of f_obex
usb: gadget: f_obex: remove compatibility layer
usb: gadget: phonet: move global dev variable to its user
usb: gadget: f_phonet: convert to new function interface with backward
compatibility
usb: gadget: nokia: convert to new interface of f_phonet
usb: gadget: f_phonet: remove compatibility layer
usb: gadget: nokia: convert to new interface of f_ecm
usb: gadget: f_phonet: add configfs support
usb: gadget: u_ether: allow getting binary-form host address
usb: gadget: ether: convert to new interface of f_ecm
usb: gadget: f_eem: convert to new function interface with backward
compatibility
usb: gadget: ether: convert to new interface of f_eem
usb: gadget: f_eem: remove compatibility layer
usb: gadget: f_eem: use usb_gstrings_attach
usb: gadget: f_eem: add configfs support
usb: gadget: multi: Remove unused include
usb: gadget: f_subset: convert to new function interface with backward
compatibility
usb: gadget: ether: convert to new interface of f_subset
usb: gadget: f_subset: use usb_gstrings_attach
usb: gadget: f_subset: add configfs support
usb: gadget: f_rndis: convert to new function interface with backward
compatibility
usb: gadget: ether: convert to new interface of f_rndis
usb: gadget: rndis: init exit rndis at module load/unload
usb: gadget: f_rndis: use usb_gstrings_attach
usb: gadget: f_rndis: add configfs support
usb: gadget: f_mass_storage: fix default product name
Daniel Mack (11):
usb: gadget: drop unused USB_GADGET_MUSB_HDRC
usb: musb: move function declarations to musb_{host,gadget}.h
usb: musb: factor some host-specific functions
usb: musb: gadget: remove hcd initialization
usb: musb: move musb_start to musb_virthub.c
usb: musb: factor out hcd initalization
usb: musb: add Kconfig options for HOST, GAGDET or DUAL_ROLE modes
usb: musb: add musb_host_setup() and musb_host_cleanup()
usb: musb: re-introduce musb-port_mode
usb: musb: use musb-port_mode
usb: musb: eliminate musb_to_hcd
Re: [PATCH 01/10] USB: OHCI: Properly handle ohci-at91 suspend
On Wed, 12 Jun 2013, Alan Stern wrote:
On Wed, 12 Jun 2013, Manjunath Goudar wrote:
Suspend scenario in case of ohci-at91 glue was not properly
handled as it was not suspending generic part of ohci controller.
Calling explicitly the ohci_suspend()routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario.
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index fb2f127..28400a7 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -619,8 +619,12 @@ ohci_hcd_at91_drv_suspend(struct platform_device
*pdev, pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
- if (device_may_wakeup(pdev-dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+
+ if (do_wakeup)
enable_irq_wake(hcd-irq);
/*
@@ -637,7 +641,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
If ohci_suspend() fails, we should return right away. Don't execute
the enable_irq_wake() and all the other stuff.
Actually, the situation is more complicated. In order to handle races
with remote wakeup, the logic we need is more like this:
Index: usb-3.10/drivers/usb/host/ohci-at91.c
===
--- usb-3.10.orig/drivers/usb/host/ohci-at91.c
+++ usb-3.10/drivers/usb/host/ohci-at91.c
@@ -674,8 +674,18 @@ ohci_hcd_at91_drv_suspend(struct platfor
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
- if (device_may_wakeup(pdev-dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret == 0 do_wakeup HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ ret = -EBUSY;
+ }
+ if (ret)
+ return ret;
+
+ if (do_wakeup)
enable_irq_wake(hcd-irq);
/*
@@ -692,7 +702,7 @@ ohci_hcd_at91_drv_suspend(struct platfor
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
The same is true for all the other drivers.
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: [RFC PATCH 1/1] Intel xhci: refactor EHCI/xHCI port switching
On Wed, Jun 12, 2013 at 07:11:23PM +0300, Mathias Nyman wrote: Make the Linux xHCI driver automatically try to switchover the EHCI ports to xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI host. This means we will no longer have to add Intel xHCI hosts to a quirks list when the PCI device IDs change. Simply continuing to add new Intel xHCI PCI device IDs to the quirks list is not sustainable. So you are saying that all future Intel devices will work this way? For some reason I thought we originally proposed this, but it was rejected by Sarah as she said this might not be true. Has this changed? 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 V3 1/7] usb: phy: export ulpi_viewport_access_ops
On Wed, Jun 12, 2013 at 10:11:27AM -0600, Stephen Warren wrote: On 06/12/2013 09:06 AM, Felipe Balbi wrote: On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote: From: Manjunath Goudar manjunath.gou...@linaro.org In order to build a ULPI PHY driver as a module, this symbol needs to be exported. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org [swarren, reworked Manjunath's patches to split them more logically] Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Arnd Bergmann a...@arndb.de This should go straight through Greg: All the patches in this series build on top of each-other, so I think need to be applied in the same branch. Applying this patch in branch A but the others in branch B will cause the build to fail in branch B if the driver is built as a module, since ulpi_viewport_access_ops isn't exported, right? And this series is also based on top of all the Tegra driver changes in your PHY branch, so I believe that is the correct place to apply this. Isn't it the same thing as Greg taking these patches after applying my pull request ? There's way too much outside of my domain here without proper Acks for me to pick it up anyway. -- balbi signature.asc Description: Digital signature
Re: [PATCH V3 1/7] usb: phy: export ulpi_viewport_access_ops
Hi, On Wed, Jun 12, 2013 at 10:51:05AM -0600, Stephen Warren wrote: On 06/12/2013 10:38 AM, Felipe Balbi wrote: On Wed, Jun 12, 2013 at 10:11:27AM -0600, Stephen Warren wrote: On 06/12/2013 09:06 AM, Felipe Balbi wrote: On Wed, Jun 05, 2013 at 02:03:03PM -0600, Stephen Warren wrote: From: Manjunath Goudar manjunath.gou...@linaro.org In order to build a ULPI PHY driver as a module, this symbol needs to be exported. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org [swarren, reworked Manjunath's patches to split them more logically] Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Arnd Bergmann a...@arndb.de This should go straight through Greg: All the patches in this series build on top of each-other, so I think need to be applied in the same branch. Applying this patch in branch A but the others in branch B will cause the build to fail in branch B if the driver is built as a module, since ulpi_viewport_access_ops isn't exported, right? And this series is also based on top of all the Tegra driver changes in your PHY branch, so I believe that is the correct place to apply this. Isn't it the same thing as Greg taking these patches after applying my pull request ? There's way too much outside of my domain here without proper Acks for me to pick it up anyway. Yes. I wasn't aware that you'd sent a pull request to Greg already though. If you have, then it's fine for Greg to apply this series after the PHY branch is pulled. (I think Alan did Ack all the EHCI patches though, so either way is probably fine...) Indeed, just saw his replies to the two patches which were missing his Acks. My bad -- balbi signature.asc Description: Digital signature
Re: DWC3: Event Interrupt Mask issue
Hi,
On Fri, Jun 07, 2013 at 03:50:17PM +0800, Huang Rui wrote:
Hi Felipe,
I was reading dwc3 codes and found that during the process of
configuring event buffer (dwc3_event_buffers_setup), it only write the
size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ
register like below,
dwc3_writel(dwc-regs, DWC3_GEVNTSIZ(n),
evt-length 0x);
But in spec, it suggests that write this bit to prevent the interrupt
from being generated in an event buffer configuration. So need we set
where does it say that ? I just re-read details about that bit and all
it says is that it can be used to mask the interrupt, but events will
still be queued. Maybe I'm missing some part. Which revision of the
databook are you reading ?
Anyway, we don't really need that bit right now because linux will only
enable the IRQ line after request_*irq() has been called and we're
setting up our event buffers before calling that.
OTOH, we could use that bit as means to get rid of IRQF_ONESHOT from
DWC3 driver.
Can you test a patch for me ? I don't have access to HW right now. I
assume the patch below works fine, does it ?
(it's not final yet, I will still break it down into proper patches)
8--- cut here
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..be74df6 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -236,7 +236,7 @@ static int dwc3_event_buffers_setup(struct dwc3 *dwc)
dwc3_writel(dwc-regs, DWC3_GEVNTADRHI(n),
upper_32_bits(evt-dma));
dwc3_writel(dwc-regs, DWC3_GEVNTSIZ(n),
- evt-length 0x);
+ DWC3_GEVNTSIZ_SIZE(evt-length));
dwc3_writel(dwc-regs, DWC3_GEVNTCOUNT(n), 0);
}
@@ -255,7 +255,8 @@ static void dwc3_event_buffers_cleanup(struct dwc3 *dwc)
dwc3_writel(dwc-regs, DWC3_GEVNTADRLO(n), 0);
dwc3_writel(dwc-regs, DWC3_GEVNTADRHI(n), 0);
- dwc3_writel(dwc-regs, DWC3_GEVNTSIZ(n), 0);
+ dwc3_writel(dwc-regs, DWC3_GEVNTSIZ(n), DWC3_GEVNTSIZ_INTMASK
+ | DWC3_GEVNTSIZ_SIZE(0));
dwc3_writel(dwc-regs, DWC3_GEVNTCOUNT(n), 0);
}
}
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b69d322..d2ceb82 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -194,6 +194,10 @@
#define DWC3_GTXFIFOSIZ_TXFDEF(n) ((n) 0x)
#define DWC3_GTXFIFOSIZ_TXFSTADDR(n) ((n) 0x)
+/* Global Event Size Registers */
+#define DWC3_GEVNTSIZ_INTMASK (1 31)
+#define DWC3_GEVNTSIZ_SIZE(n) ((n) 0x)
+
/* Global HWPARAMS1 Register */
#define DWC3_GHWPARAMS1_EN_PWROPT(n) (((n) (3 24)) 24)
#define DWC3_GHWPARAMS1_EN_PWROPT_NO 0
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 2b6e7e0..dc7ee3d 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1567,7 +1567,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
irq = platform_get_irq(to_platform_device(dwc-dev), 0);
ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
- IRQF_SHARED | IRQF_ONESHOT, dwc3, dwc);
+ IRQF_SHARED, dwc3, dwc);
if (ret) {
dev_err(dwc-dev, failed to request irq #%d -- %d\n,
irq, ret);
@@ -2491,6 +2491,7 @@ static irqreturn_t dwc3_thread_interrupt(int irq, void
*_dwc)
struct dwc3 *dwc = _dwc;
unsigned long flags;
irqreturn_t ret = IRQ_NONE;
+ u32 reg;
int i;
spin_lock_irqsave(dwc-lock, flags);
@@ -2530,6 +2531,11 @@ static irqreturn_t dwc3_thread_interrupt(int irq, void
*_dwc)
evt-count = 0;
evt-flags = ~DWC3_EVENT_PENDING;
ret = IRQ_HANDLED;
+
+ /* Unask interrupt */
+ reg = dwc3_readl(dwc-regs, DWC3_GEVNTSIZ(i));
+ reg = ~DWC3_GEVNTSIZ_INTMASK;
+ dwc3_writel(dwc-regs, DWC3_GEVNTSIZ(i), reg);
}
spin_unlock_irqrestore(dwc-lock, flags);
@@ -2541,6 +2547,7 @@ static irqreturn_t dwc3_process_event_buf(struct dwc3
*dwc, u32 buf)
{
struct dwc3_event_buffer *evt;
u32 count;
+ u32 reg;
evt = dwc-ev_buffs[buf];
@@ -2552,6 +2559,11 @@ static irqreturn_t dwc3_process_event_buf(struct dwc3
*dwc, u32 buf)
evt-count = count;
evt-flags |= DWC3_EVENT_PENDING;
+ /* Mask interrupt */
+ reg = dwc3_readl(dwc-regs, DWC3_GEVNTSIZ(buf));
+ reg |= DWC3_GEVNTSIZ_INTMASK;
+ dwc3_writel(dwc-regs, DWC3_GEVNTSIZ(buf), reg);
+
return IRQ_WAKE_THREAD;
}
--
balbi
signature.asc
Description: Digital signature
USB communication stops working after 0x7FFFFFFF milliseconds
We are running the 2.6.28-15 kernel under Ubuntu 9.04 (I know... we are migrating now). We see the USB communication between the kernel driver and the USB device stop after what appears to be 0x7 microseconds, and suspect it is a logic problem with an unsigned long rolling over. We cannot find the source for this kernel, but in looking at the linux USB driver code in later versions of the kernel and the firmware in our USB device, we are not using timers or incremental counters such that this would be the root cause. We monitored the USB bus when this failure occured with a software monitor tool and saw that URBs submitted at the linux driver level were being put out on the bus, but no response was received from the USB device. The USB device is a TI CC part, hosted on a controller board attached to the system on a PCI slot. We are doing additional tests with the same board hosted on a cradle board that connects to a standard USB 2.0 port on the linux computer with a USB cable to see if the problem replicates that way. With the cradle board configuration, we saw a USB communication failure monitored with a Beagle board USB monitor where traffic was being exchanged bidirectionally on the bus between the linux driver and the CC hosted driver, but the data was not making it to our kernel module that sends/receives URBS. We saw this failure when we disconnected the USB cable and reconnected it. Normally this works, it is not a hard failure, but we do intermittently see communication stop when this procedure is done. I am not sure what part on the linux computer is providing USB host controller services, but we are using the standard USB driver distributed in the kernel. We have ported our application and drivers to the 3.9.2 version of the kernel, hosted under Ubuntu 12.4. Unfortunately, this takes 25 days to reach the fail point so we can analyze the results. Anyone seen this problem or have ideas about what could cause the USB comm to stop consistently at this benchmark time. Is the unplug/reconnect failure a completely separate issue, or is it indicative of some handling problem that also manifests itself in the 0x7fff microsecond communication halt? As I indicated earlier, I do not see incremental timer or time calculations being done in the driver sources, so this communication halt that has been 100% predictable certainly seems timer or some increment calculation related, but I just do not see it in the code.-- 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. i learned how to use kdump :) complete log is in attachment -- Regards, Oleksij crash_log.bz2 Description: application/bzip
Re: [GIT PULL] USB patches for v3.11 merge window
Hi,
On Wed, Jun 12, 2013 at 01:17:42PM -0700, Greg KH wrote:
On Wed, Jun 12, 2013 at 07:12:23PM +0300, Felipe Balbi wrote:
Hi Greg,
Here's my pull request for v3.11 merge window. It's rather
large. Let me know if you want any changes.
cheers
The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
tags/usb-for-v3.11
for you to fetch changes up to b4b1ceec0c3e87065787e7da4c8c3fd7549660b8:
usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12
18:11:51 +0300)
usb: patches for v3.11 merge window
All function drivers are now converted to our new configfs-based
binding. Eventually this will help us getting rid of in-kernel
gadget drivers and only keep function drivers in the kernel.
MUSB was taught that it needs to be built for host-only and
device-only modes too. We had this support long ago but it
involved a ridiculous amount of ifdefs. Now we have a much
cleaner approach.
Samsung Exynos4 platform now implements HSIC support.
We're introducing support for AB8540 and AB9540 PHYs.
MUSB module reinsertion now works as expected, before we were
getting -EBUSY being returned by the resource checks done on
driver core.
DWC3 now has minimum support for TI's AM437x series of SoCs.
OMAP5 USB3 PHY learned one extra DPLL configuration values because
that PHY is reused in TI's DRA7xx devices.
Users can now select a PHY without enabling the PHY layer first.
We're introducing support for Faraday fotg210 UDCs.
Last, but not least, the usual set of non-critical fixes and cleanups
ranging from usage of platform_{get,set}_drvdata to lock improvements.
Signed-of-by: Felipe Balbi ba...@ti.com
Alexey Khoroshilov (1):
usb: gadget: r8a66597-udc: do not unlock unheld spinlock in
r8a66597_sudmac_irq()
Andrzej Pietrasiewicz (40):
usb: gadget: u_ether: convert into module
usb: gadget: rndis: convert into module
usb: gadget: u_ether: construct with default values and add
setters/getters
usb: gadget: f_ncm: convert to new function interface with backward
compatibility
usb: gadget: ncm: convert to new function interface
usb: gadget: f_ncm: remove compatibility layer
usb: gadget: f_ncm: use usb_gstrings_attach
usb: gadget: f_ncm: add configfs support
usb: gadget: add helpers for configfs support for USB Ethernet
usb: gadget: f_ecm: convert to new function interface with backward
compatibility
usb: gadget: cdc2: convert to new interface of f_ecm
usb: gadget: f_ecm: use usb_gstrings_attach
usb: gadget: f_ecm: add configfs support
usb: gadget: f_obex: use usb_gstrings_attach
usb: gadget: nokia: convert to new interface of f_obex
usb: gadget: f_obex: remove compatibility layer
usb: gadget: phonet: move global dev variable to its user
usb: gadget: f_phonet: convert to new function interface with
backward compatibility
usb: gadget: nokia: convert to new interface of f_phonet
usb: gadget: f_phonet: remove compatibility layer
usb: gadget: nokia: convert to new interface of f_ecm
usb: gadget: f_phonet: add configfs support
usb: gadget: u_ether: allow getting binary-form host address
usb: gadget: ether: convert to new interface of f_ecm
usb: gadget: f_eem: convert to new function interface with backward
compatibility
usb: gadget: ether: convert to new interface of f_eem
usb: gadget: f_eem: remove compatibility layer
usb: gadget: f_eem: use usb_gstrings_attach
usb: gadget: f_eem: add configfs support
usb: gadget: multi: Remove unused include
usb: gadget: f_subset: convert to new function interface with
backward compatibility
usb: gadget: ether: convert to new interface of f_subset
usb: gadget: f_subset: use usb_gstrings_attach
usb: gadget: f_subset: add configfs support
usb: gadget: f_rndis: convert to new function interface with backward
compatibility
usb: gadget: ether: convert to new interface of f_rndis
usb: gadget: rndis: init exit rndis at module load/unload
usb: gadget: f_rndis: use usb_gstrings_attach
usb: gadget: f_rndis: add configfs support
usb: gadget: f_mass_storage: fix default product name
Daniel Mack (11):
usb: gadget: drop unused USB_GADGET_MUSB_HDRC
usb: musb: move function declarations to musb_{host,gadget}.h
usb: musb: factor some host-specific functions
usb: musb: gadget: remove hcd initialization
Re: [GIT PULL] USB patches for v3.11 merge window
Hi,
On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote:
But, I get a build error with your tree pulled in, at the link point in
time:
ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined!
ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined!
ERROR: usb_add_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-omap-usb3.ko] undefined!
ERROR: usb_add_phy_dev [drivers/usb/phy/phy-omap-usb3.ko] undefined!
ERROR: usb_add_phy_dev [drivers/usb/phy/phy-nop.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-nop.ko] undefined!
ERROR: usb_add_phy_dev [drivers/usb/phy/phy-isp1301.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-isp1301.ko] undefined!
ERROR: usb_add_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
ERROR: usb_remove_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined!
ERROR: usb_get_phy [drivers/usb/musb/ux500.ko] undefined!
ERROR: usb_put_phy [drivers/usb/musb/ux500.ko] undefined!
ERROR: usb_put_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined!
ERROR: usb_get_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined!
ERROR: devm_usb_get_phy [drivers/usb/gadget/mv_udc.ko] undefined!
ERROR: devm_usb_get_phy [drivers/usb/dwc3/dwc3.ko] undefined!
ERROR: devm_usb_get_phy_by_phandle [drivers/usb/dwc3/dwc3.ko] undefined!
ERROR: usb_get_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined!
ERROR: usb_put_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined!
ERROR: usb_get_phy [drivers/power/isp1704_charger.ko] undefined!
ERROR: usb_put_phy [drivers/power/isp1704_charger.ko] undefined!
Any ideas?
hmm... I think it was Roger's patches changing the way PHY layer is
enabled, do you mind if I drop that for now ? I would have to rebase,
but I guess it's a necessary evil at this point.
I took the silence as a yes and pushed a new tag with Roger's patches
removed. I have also removed one musb patch which wasn't necessary after
all.
Here's an updated pull request, which I have compiled on ARM and x86
and didn't see the linking problem mentioned above:
The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b:
Linux 3.10-rc3 (2013-05-26 16:00:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.11
for you to fetch changes up to b1fd6cb5ee2f97a553d1c4b8a88914bd970daf37:
usb: dwc3: omap: Adds dwc3_omap_readl/writel wrappers (2013-06-12 23:57:13
+0300)
usb: patches for v3.11 merge window
All function drivers are now converted to our new configfs-based
binding. Eventually this will help us getting rid of in-kernel
gadget drivers and only keep function drivers in the kernel.
MUSB was taught that it needs to be built for host-only and
device-only modes too. We had this support long ago but it
involved a ridiculous amount of ifdefs. Now we have a much
cleaner approach.
Samsung Exynos4 platform now implements HSIC support.
We're introducing support for AB8540 and AB9540 PHYs.
MUSB module reinsertion now works as expected, before we were
getting -EBUSY being returned by the resource checks done on
driver core.
DWC3 now has minimum support for TI's AM437x series of SoCs.
OMAP5 USB3 PHY learned one extra DPLL configuration values because
that PHY is reused in TI's DRA7xx devices.
We're introducing support for Faraday fotg210 UDCs.
Last, but not least, the usual set of non-critical fixes and cleanups
ranging from usage of platform_{get,set}_drvdata to lock improvements.
Signed-of-by: Felipe Balbi ba...@ti.com
Alexey Khoroshilov (1):
usb: gadget: r8a66597-udc: do not unlock unheld spinlock in
r8a66597_sudmac_irq()
Andrzej Pietrasiewicz (40):
usb: gadget: u_ether: convert into module
usb: gadget: rndis: convert into module
usb: gadget: u_ether: construct with default values and add
setters/getters
usb: gadget: f_ncm: convert to new function interface with backward
compatibility
usb: gadget: ncm: convert to new function interface
usb: gadget: f_ncm: remove compatibility layer
usb: gadget: f_ncm: use usb_gstrings_attach
usb: gadget: f_ncm: add configfs support
usb: gadget: add helpers for configfs support for USB Ethernet
usb: gadget: f_ecm: convert to new function interface with backward
compatibility
usb: gadget: cdc2: convert to new interface of f_ecm
usb: gadget: f_ecm: use usb_gstrings_attach
usb: gadget: f_ecm: add configfs support
usb: gadget: f_obex: use usb_gstrings_attach
usb: gadget: nokia: convert to new interface of f_obex
Re: [GIT PULL] USB patches for v3.11 merge window
On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: Hi, On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: But, I get a build error with your tree pulled in, at the link point in time: ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-omap-usb3.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-omap-usb3.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-nop.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-nop.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-isp1301.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-isp1301.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! ERROR: usb_get_phy [drivers/usb/musb/ux500.ko] undefined! ERROR: usb_put_phy [drivers/usb/musb/ux500.ko] undefined! ERROR: usb_put_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined! ERROR: usb_get_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined! ERROR: devm_usb_get_phy [drivers/usb/gadget/mv_udc.ko] undefined! ERROR: devm_usb_get_phy [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: devm_usb_get_phy_by_phandle [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: usb_get_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined! ERROR: usb_put_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined! ERROR: usb_get_phy [drivers/power/isp1704_charger.ko] undefined! ERROR: usb_put_phy [drivers/power/isp1704_charger.ko] undefined! Any ideas? hmm... I think it was Roger's patches changing the way PHY layer is enabled, do you mind if I drop that for now ? I would have to rebase, but I guess it's a necessary evil at this point. I took the silence as a yes and pushed a new tag with Roger's patches removed. I have also removed one musb patch which wasn't necessary after all. Sorry for the silence, I went to lunch :) Here's an updated pull request, which I have compiled on ARM and x86 and didn't see the linking problem mentioned above: Ok, thanks, I'll try it out now... greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB communication stops working after 0x7FFFFFFF milliseconds
On Wed, Jun 12, 2013 at 06:51:00PM +, Kerry Calvert wrote: We are running the 2.6.28-15 kernel under Ubuntu 9.04 (I know... we are migrating now). Then you really need to get support from Ubuntu, there's nothing we can do here about such an old and obsolete, and really unknown kernel tree, sorry. Given that I know machines are out there running successfully for longer than that many milliseconds, with USB, just fine (my build server is one such example), I'd point to either the changes that Canonical made to that kernel version, or your specific drivers you have for your hardware. Good luck, 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 v2] xhci: fix dma mask setup in xhci.c
On Fri, Jun 07, 2013 at 11:37:53PM +0300, Felipe Balbi wrote: Hi, On Fri, Jun 07, 2013 at 10:19:23AM -0700, Sarah Sharp wrote: Adding Felipe. Xenia, Felipe is the USB gadget maintainer, and also added code for non-PCI xHCI hosts. Felipe, Xenia is my summer intern through the FOSS Outreach Program for Women: http://kernelnewbies.org/OPWIntro Hey, cool Sarah :-) Welcome Xenia :-) Ah, slight correction, my intern wants to be called Ksenia. Xenia is her legal name, but everyone calls her Ksenia. :) On Fri, Jun 07, 2013 at 03:00:47PM +0300, Mathias Nyman wrote: Andy explained his concern in more detail to me irl. The beef is that the dma_mask is a pointer while dma_coherent_mask is a u64 value in struct device, and dma_set_mask() fails if dev-dma_mask doesn't point anywhere. This is not a problem for PCI enumerated devices because PCI probe sets a default 32bit mask and makes the dma_mask of all new PCI devices point to this value. For non-pci enumerated devices the device dma_mask may be NULL and dma_set_mask() may fail even if dma is supported on the host machine. for example ehci-platform.c solves this by adding: if (!dev-dev.dma_mask) dev-dev.dma_mask = dev-dev.coherent_dma_mask; if (!dev-dev.coherent_dma_mask) dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); So it sounds like xhci_plat_setup() in xhci-plat.c needs to do something similar before it calls xhci_gen_setup(). Felipe, do you agree? (now, after reading the whole thing...) I'll agree with that :) It's funny that the code worked before. Perhaps setting the dma_mask pointer should be a separate patch for stable? sounds like a good plan to me :-) Great! Ok, Ksenia, can you create those two patches? The first patch in the series should add setting the dma_mask pointer to xhci_plat_setup(). The second patch will be the same as this patch. Let me know via IRC if you have any questions. Sarah Sharp -- 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 1/1] Intel xhci: refactor EHCI/xHCI port switching
On Wed, Jun 12, 2013 at 03:01:50PM -0700, Sarah Sharp wrote: On Wed, Jun 12, 2013 at 09:32:58AM -0700, Greg KH wrote: On Wed, Jun 12, 2013 at 07:11:23PM +0300, Mathias Nyman wrote: Make the Linux xHCI driver automatically try to switchover the EHCI ports to xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI host. This means we will no longer have to add Intel xHCI hosts to a quirks list when the PCI device IDs change. Simply continuing to add new Intel xHCI PCI device IDs to the quirks list is not sustainable. So you are saying that all future Intel devices will work this way? For some reason I thought we originally proposed this, but it was rejected by Sarah as she said this might not be true. Has this changed? For the long-term roadmap, eventually Intel will drop the EHCI host controller and only use xHCI. Originally, I thought this would happen within one Intel chipset generation. However, it looks like the EHCI host is still being used for Haswell, Haswell-ULT, and its shrink, Broadwell. Those chipsets are being re-used in other Intel products, but branded with a different PCI ID, and that means another explosion of PCI IDs to add to the quirk. It's just not sustainable to continue to add PCI IDs, so I asked Mathias to look into reworking the code. Thanks for the explaination, if you are ok with this, I have no objections. Feel free to queue it up in your next round of patches if you want to. 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: Crash in xhci_hcd for 3.10-rc5 (old 3.5.0 bug)
On Wed, Jun 12, 2013 at 08:47:30PM -0400, Jérôme Poulin wrote: In reference to this email: http://www.spinics.net/lists/linux-usb/msg78711.html I have exactly the same stack dump with different words, null pointer dereference. Plugging a USB3 external disk and using ddrescue will cause this stack dump: http://postimg.org/image/70fi6f39n/ This is using the uas driver, right? That's known to be broken right now, can you fallback to old usb-storage support? 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: [GIT PULL] USB patches for v3.11 merge window
Hi, On Wed, Jun 12, 2013 at 03:37:00PM -0700, Greg KH wrote: On Wed, Jun 12, 2013 at 02:31:17PM -0700, Greg KH wrote: On Thu, Jun 13, 2013 at 12:19:02AM +0300, Felipe Balbi wrote: Hi, On Wed, Jun 12, 2013 at 11:56:19PM +0300, Felipe Balbi wrote: But, I get a build error with your tree pulled in, at the link point in time: ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb3.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-samsung-usb2.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-rcar-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-omap-usb3.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-omap-usb3.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-nop.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-nop.ko] undefined! ERROR: usb_add_phy_dev [drivers/usb/phy/phy-isp1301.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-isp1301.ko] undefined! ERROR: usb_add_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! ERROR: usb_remove_phy [drivers/usb/phy/phy-gpio-vbus-usb.ko] undefined! ERROR: usb_get_phy [drivers/usb/musb/ux500.ko] undefined! ERROR: usb_put_phy [drivers/usb/musb/ux500.ko] undefined! ERROR: usb_put_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined! ERROR: usb_get_phy [drivers/usb/gadget/pxa27x_udc.ko] undefined! ERROR: devm_usb_get_phy [drivers/usb/gadget/mv_udc.ko] undefined! ERROR: devm_usb_get_phy [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: devm_usb_get_phy_by_phandle [drivers/usb/dwc3/dwc3.ko] undefined! ERROR: usb_get_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined! ERROR: usb_put_phy [drivers/usb/chipidea/ci_hdrc.ko] undefined! ERROR: usb_get_phy [drivers/power/isp1704_charger.ko] undefined! ERROR: usb_put_phy [drivers/power/isp1704_charger.ko] undefined! Any ideas? hmm... I think it was Roger's patches changing the way PHY layer is enabled, do you mind if I drop that for now ? I would have to rebase, but I guess it's a necessary evil at this point. I took the silence as a yes and pushed a new tag with Roger's patches removed. I have also removed one musb patch which wasn't necessary after all. Sorry for the silence, I went to lunch :) Here's an updated pull request, which I have compiled on ARM and x86 and didn't see the linking problem mentioned above: Ok, thanks, I'll try it out now... That worked, now pulled and pushed out, thanks. thanks Greg ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 0/2] USB: PHY: Improve PHY selection logic
On Fri, May 31, 2013 at 02:29:01PM +0300, Roger Quadros wrote: Hi, Improve Kconfig so that the relevant PHY driver can be explicitely selected by the controller driver instead of relying on the user to do so. Detailed description in patch 1. v2: - Merge patches 3-5 into the first patch to prevent circular dependency between the Kconfig options during bisection. FYI, these patches were dropped because they cause linking issues as noted by Greg. -- balbi signature.asc Description: Digital signature
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Wed, Jun 12, 2013 at 3:45 PM, Thomas Gleixner t...@linutronix.de wrote: On Wed, 12 Jun 2013, Ming Lei wrote: Yes, please. I read through the thread and I really recommend that you get rid of the tasklet. tasklets are a complete disaster by design and we really should make efforts to get rid of the last users instead of trying to work around their semantical shortcomings. The attached patch001 supports tasklet in HCD and patch002 implements interrupt threaded handler, then if USB_HCD_THREADED_IRQ is set, interrupt threaded handler is used to do URB giveback, otherwise tasklet is used to do that. The other 3 patches(2/4, 3/4, 4/4) aren't changed now, if anyone want to try it. (the patch 2 is only for comparing performance difference, and welcome to review/comment it so that we can get accurate test result to make decision) Follows the mass storage test result(average over 10 times test) with tasklet /interrupt threaded handler/hard interrupt handler under same environment of lenovo T410(x86), which means the test is switched by reinserting module of usbcore or ehci-hcd without changing other things in the machine. - do below tests 10 times and figure out the average speed dd if=/dev/sdN of=/dev/null iflag=direct bs=200M 1 device: sandisk extreme USB 3.0 16G, host: Lenovo T410 EHCI - using interrupt threaded handler(default) 33.440 MB/sec - using tasklet(#undef USB_HCD_THREADED_IRQ) 34.29 MB/sec - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c ) 34.260 MB/s So looks usb mass storage performance loss can be observed with interrupt threaded handler because one mass storage read/write sectors requires at least 3 interrupts which wake up usb-storage thread 3 times (each interrupt wakeup the usb-storage each time), introducing irq threaded handler will make 2 threads to be waken up about 6 times for one read/write. I think usb mass storage transfer handler need to be rewritten, otherwise it may become worsen after using irq threaded handler in USB 3.0.(the above device can reach 120MB/sec with hardware handler or tasklet handler, which means about ~3K interrupts/sec, so ~6K contexts switch in case of using irq threaded handler) So how about supporting tasklet first, then convert to interrupt threaded handler after usb mass storage transfer is rewritten without performance loss? (rewriting usb mass storage transfer handler may need some time and work since storage stability/correctness is extremely important, :-) Also another problem with irq threaded handler is that there is no sort of tasklet_schedule() interface to wakeup the thread handler manually, so I have to use work to schedule some URB giveback from drivers(root hub transfer, unlink), even though that isn't a big deal but will cause code a bit much/complicated, :-) Thanks, -- Ming Lei 0002-USB-support-interrupt-threaded-handler.patch Description: Binary data 0001-USB-HCD-support-giveback-of-URB-in-tasklet-context.patch Description: Binary data
Re: [PATCH] USB: serial/ftdi_sio.c Fix kernel oops
On Fri, 2013-06-07 at 15:14 +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 a816e3113b63753c330ca4751ea1d208e93e3015. This is to be fixed in longterm 2.6.32.60 and 3.4.47. This bug has been found with coccinelle. Signed-off-by: Lotfi Manseur lotfi.mans...@imag.fr Signed-off-by: Nicolas Palix nicolas.pa...@imag.fr I've queued up those changes for 3.2. This backported version seems nicer, but we generally prefer to use patches that are as close as possible to those in mainline. Ben. --- drivers/usb/serial/ftdi_sio.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c index c374beb..615bd9e 100644 --- a/drivers/usb/serial/ftdi_sio.c +++ b/drivers/usb/serial/ftdi_sio.c @@ -2364,7 +2364,8 @@ static void ftdi_set_termios(struct tty_struct *tty, cflag = termios-c_cflag; - if (old_termios-c_cflag == termios-c_cflag + if (old_termios + old_termios-c_cflag == termios-c_cflag old_termios-c_ispeed == termios-c_ispeed old_termios-c_ospeed == termios-c_ospeed) goto no_c_cflag_changes; @@ -2373,7 +2374,8 @@ static void ftdi_set_termios(struct tty_struct *tty, ftdi_sio_read_bulk_callback - need to examine what this means - don't see any problems yet */ - if ((old_termios-c_cflag (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) == + if (old_termios + (old_termios-c_cflag (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB)) == (termios-c_cflag (CSIZE|PARODD|PARENB|CMSPAR|CSTOPB))) goto no_data_parity_stop_changes; -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: [RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context
On Wed, Jun 12, 2013 at 10:35 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 12 Jun 2013, Ming Lei wrote: 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? Here's another possibility. A USB driver has a private lock, and it acquires this lock in its completion handler. But it also acquires this lock in other routines, and those other routines may be called by other drivers or subsystems in interrupt context. OK, so the problem is more complicated than I imaged at start, :-( 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? :-) Me too. :-) 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. For reasonably sophisticated host controllers like EHCI, the delay in responding to an interrupt doesn't matter much. But for simpler host EHCI might still benefit from the change: suppose uvc video is playing on one EHCI bus, and mass storage's performance over another EHCI may decrease because of the IRQ latency introduced. controllers (for example, those using PIO instead of DMA) it matters more, so those other HCDs will benefit more from the conversion. Indeed, musb and ehci/ohci are coexisted on OMAP3/4/5. 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. I think it should be one tasklet latency added, but what is the other one? I meant that the latency in tasklet scheduling has to be added to the latency in scheduling the usb-storage thread. Or you could have a separate tasklet for each host controller. Yes, but I will compare tasklet with interrupt threaded handler first. Switching to a threaded interrupt handler offers more possibilities. Instead of moving just the givebacks to the thread, we could put almost all the processing there. (At least, we can for ehci-hcd. Other HCDs may not be able to do this.) At this point we are talking about multiple changes: Moving the givebacks to a tasklet or threaded handler. Changing the USB completion handlers so that they can be called with interrupts enabled. Allowing the tasklet/thread to run with interrupts enabled. Moving more of the HCD processing into the tasklet/thread. Maybe other things too. In principle, the first and second items can be done simultaneously. Very good summery, we can push the 1st change with disabling local IRQ when calling complete(), so that at least DMA unmapping can be done with IRQ enabled, and at the same time do the API change, which should be a bit slow but the mechanical way proposed by Oliver may be OK. The 3rd item is easy once the 1st two items are completed. For the 4th one, it might be a long term thing, since refactoring HCD interrupt handler is a bit complicated. Also, when the 1st three items are completed, hard interrupt handler takes less time, often less than 20us at average about EHCI, so I am wondering if the 4th is worthy. 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
Business Opportunity
Good day, I Am Chi Pui;Do not be surprised! I got your email contact via the World Email On-line Directory I am crediting officer at Sino Pac Bank Plc in Hong Kong and i have a deal of $17.3M to discuss with you urgently. Regards, Mr.Chi Pui -- 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
