Re: problem with resume after s2ram
On Tue, Apr 01 2014, Alan Stern wrote: Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? The system hangs... Do you have a netconsole log? Hi Alan, Yes, here: [ 4694.420213] PM: Syncing filesystems ... done. [ 4694.591736] PM: Preparing system for mem sleep [ 4694.756151] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 4694.758468] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 4694.759870] PM: Entering mem sleep [ 4694.760313] usb 6-3: usb suspend, wakeup 0 [ 4694.760464] usb 2-3: usb suspend, wakeup 0 [ 4694.760520] usb usb7: usb auto-resume [ 4694.760578] ohci-pci :00:14.5: resume root hub [ 4694.760753] usb usb5: usb auto-resume [ 4694.760813] ohci-pci :00:13.0: resume root hub [ 4694.760908] usb usb4: usb auto-resume [ 4694.760961] ohci-pci :00:12.1: resume root hub [ 4694.761058] usb usb3: usb auto-resume [ 4694.761086] ohci-pci :00:12.0: resume root hub [ 4694.761300] hub 2-0:1.0: hub_suspend [ 4694.761340] usb usb1: usb auto-resume [ 4694.761396] ehci-pci :00:12.2: resume root hub [ 4694.761422] usb usb2: bus suspend, wakeup 0 [ 4694.761481] ehci-pci :00:13.2: suspend root hub [ 4694.761554] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 4694.761720] sd 2:0:0:0: [sdb] Stopping disk [ 4694.761862] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 4694.762063] sd 0:0:0:0: [sda] Stopping disk [ 4694.762223] usb 6-2: usb suspend, wakeup 1 [ 4697.508604] r8169 :02:00.0 eth0: link up [ 4699.733189] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4699.763610] ata3.00: configured for UDMA/133 [ 4699.768070] sd 2:0:0:0: [sdb] Starting disk [ 4701.366082] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4701.383352] ata1.00: configured for UDMA/133 [ 4701.387815] sd 0:0:0:0: [sda] Starting disk Should I do another git-bisect? Yes, that would be a good idea. Ok, but this will take some time. I can only do 1 or 2 reboots per day. -- Peter -- 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
MUSB/OMAP: gadget does not start when cable is plugged after the driver is started
Hi! I'm currently seeing a problem on an OMAP3530 based board (Technexion TAO3530). Where the MUSB is configured as device/peripheral and the ethernet gadget is compiled into the kernel. This works without any problems and usb0 is available when the USB cable is connected to a PC upon startup. But when the cable is disconnected when the driver is started (doesn't matter if the gadget is included in the kernel or if the gadget driver module is loaded) and the cable is plugged in later, the ethernet gadget does not start up. This is 100% reproducible. Before digging deeper into this, I wanted to check here if this is a known issue. And if anybody already has a solution/hint for it. FYI: I'm using v3.14 right now. Thanks, Stefan -- 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 v6 07/11] usb: chipidea: OTG HNP and SRP fsm implementation.
On Fri, Apr 04, 2014 at 11:31:16AM +0800, Li Jun wrote:
From: Li Jun b47...@freescale.com
USB OTG interrupt handling and fsm transitions according to USB OTG
and EH 2.0.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/core.c| 13 ++-
drivers/usb/chipidea/otg.c |9 +-
drivers/usb/chipidea/otg_fsm.c | 228
drivers/usb/chipidea/otg_fsm.h | 18
drivers/usb/chipidea/udc.c |6 ++
5 files changed, 270 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index ff38cf3..e63b9fa 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -42,7 +42,6 @@
* - Not Supported: 15 16 (ISO)
*
* TODO List
- * - OTG
* - Interrupt Traffic
* - GET_STATUS(device) - always reports 0
* - Gadget API (majority of optional features)
@@ -74,6 +73,7 @@
#include host.h
#include debug.h
#include otg.h
+#include otg_fsm.h
/* Controller register map */
static const u8 ci_regs_nolpm[] = {
@@ -412,8 +412,14 @@ static irqreturn_t ci_irq(int irq, void *data)
irqreturn_t ret = IRQ_NONE;
u32 otgsc = 0;
- if (ci-is_otg)
+ if (ci-is_otg) {
otgsc = hw_read_otgsc(ci, ~0);
+ if (ci_otg_is_fsm_mode(ci)) {
+ ret = ci_otg_fsm_irq(ci);
+ if (ret == IRQ_HANDLED)
+ return ret;
+ }
+ }
/*
* Handle id change interrupt, it indicates device/host function
@@ -697,6 +703,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
goto stop;
}
+ if (ci_otg_is_fsm_mode(ci))
+ ci_hdrc_otg_fsm_start(ci);
+
platform_set_drvdata(pdev, ci);
ret = request_irq(ci-irq, ci_irq, IRQF_SHARED, ci-platdata-name,
ci);
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 200784e..b054d0b 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -11,8 +11,8 @@
*/
/*
- * This file mainly handles otgsc register, it may include OTG operation
- * in the future.
+ * This file mainly handles otgsc register, OTG fsm operations for HNP and
SRP
+ * are also included.
*/
#include linux/usb/otg.h
@@ -91,6 +91,11 @@ static void ci_otg_work(struct work_struct *work)
{
struct ci_hdrc *ci = container_of(work, struct ci_hdrc, work);
+ if (ci_otg_is_fsm_mode(ci) !ci_otg_fsm_work(ci)) {
+ enable_irq(ci-irq);
+ return;
+ }
+
if (ci-id_event) {
ci-id_event = false;
ci_handle_id_switch(ci);
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 721994b..6e4ad80 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -13,6 +13,10 @@
/*
* This file mainly handles OTG fsm, it includes OTG fsm operations
* for HNP and SRP.
+ *
+ * TODO List
+ * - ADP
+ * - OTG test device
*/
#include linux/usb/otg.h
@@ -92,6 +96,33 @@ static void ci_otg_del_timer(struct ci_hdrc *ci, enum
ci_otg_fsm_timer_index t)
hw_write_otgsc(ci, OTGSC_1MSIE, 0);
}
+/*
+ * Reduce timer count by 1, and find timeout conditions.
+ * Called by otg 1ms timer interrupt
+ */
+static inline int ci_otg_tick_timer(struct ci_hdrc *ci)
+{
+ struct ci_otg_fsm_timer *tmp_timer, *del_tmp;
+ struct list_head *active_timers = ci-fsm_timer-active_timers;
+ int expired = 0;
+
+ list_for_each_entry_safe(tmp_timer, del_tmp, active_timers, list) {
+ tmp_timer-count--;
+ /* check if timer expires */
+ if (!tmp_timer-count) {
+ list_del(tmp_timer-list);
+ tmp_timer-function(ci, tmp_timer-data);
+ expired = 1;
+ }
+ }
+
+ /* disable 1ms irq if there is no any timer active */
+ if ((expired == 1) list_empty(active_timers))
+ hw_write_otgsc(ci, OTGSC_1MSIE, 0);
+
+ return expired;
+}
+
/* The timeout callback function to set time out bit */
static void set_tmout(void *ptr, unsigned long indicator)
{
@@ -397,6 +428,203 @@ static struct otg_fsm_ops ci_otg_ops = {
.start_gadget = ci_otg_start_gadget,
};
+int ci_otg_fsm_work(struct ci_hdrc *ci)
+{
+ /*
+ * Don't do fsm transition for B device
+ * when there is no gadget class driver
+ */
+ if (ci-fsm.id !(ci-driver)
+ ci-transceiver-state OTG_STATE_A_IDLE)
+ return 0;
+
+ if (otg_statemachine(ci-fsm)) {
+ if (ci-transceiver-state == OTG_STATE_A_IDLE) {
+ if (ci-fsm.id)
+ /* A idle to B idle */
+ otg_statemachine(ci-fsm);
+ else if
i.MX6 UDC driver fsl-usb2-udc versus chipidea driver
I am developing a usb perihperal with the goal of high data throughput on a freescla i.Mx6 (phyFlex). My current UDC driver is fsl-usb2-udc on kernel 3.0.35. I was recommended the chipidea driver introduced in kernel 3.5 since it would perform better. Currently I have speed issues when I use gadgetfs with bulk transfer (~15MB/s) and I was wondering if the UDC driver could really be such a bottleneck. Thanks for any input! -- 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: i.MX6 UDC driver fsl-usb2-udc versus chipidea driver
On Fri, Apr 04, 2014 at 09:58:10AM +0200, Marco Zamponi wrote: I am developing a usb perihperal with the goal of high data throughput on a freescla i.Mx6 (phyFlex). My current UDC driver is fsl-usb2-udc on kernel 3.0.35. I was recommended the chipidea driver introduced in kernel 3.5 since it would perform better. Currently I have speed issues when I use gadgetfs with bulk transfer (~15MB/s) and I was wondering if the UDC driver could really be such a bottleneck. Thanks for any input! -- Which kernel branch you are using? Mainline or internal? The bottleneck should not be at udc driver, try to improve gadgetfs, and send as many as requests to udc driver. -- Best Regards, Peter Chen -- 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: about possible port reset when disconnect
hi Alan:
2014-04-04 8:48 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Thu, 3 Apr 2014, vichy wrote:
I add more description.
in Below #1, since connect status is zero, handshake will fail with
return -ETIMEDOUT.
Then go to #2 error label.
and finally hub_port_status get -32, -EPIPE.
1. Platform-ehci Platform-ehci.0: port 1 reset error -110
the -110 is due to below handshake timeout.
retval = handshake(ehci, status_reg,
PORT_RESET, 0, 1000);
if (retval != 0) {
ehci_err (ehci, port %d reset error %d\n,
wIndex + 1, retval);
goto error;
}
Right -- although the handshake shouldn't time out. That's a bug in
the hardware.
if there is no connection, it is reasonable have return value as timeout.
Why you think it is a bug in hardware?
2. hub 4-0:1.0: hub_port_status failed (err = -32)
the -32 is due to below error label we set retval = -EPIPE
error:
/* stall on error */
retval = -EPIPE;
But... This will happen only the first time we get the port status.
After that, ehci-reset_done[wIndex] will be 0 and so handshake() won't
get called.
hub_port_status() calls get_port_status(), which performs the operation
up to 3 times. The first time it will fail with -EPIPE, but what about
the second time?
in hub_port_reset, there PORT_RESET_TRIES, 5 in right now definition
to reset port.
and ehci-reset_done[wIndex] will refilled the (jiffies + 50ms) when
set port reset.
if in all PORT_RESET_TRIES loops, there is no device connected.
We will get -EPIPE all the time, right?
for (i = 0; i PORT_RESET_TRIES; i++) {
status = set_port_feature(hub-hdev, port1, (warm ?
USB_PORT_FEAT_BH_PORT_RESET :
USB_PORT_FEAT_RESET));
if (status) {
dev_err(hub-intfdev,
cannot %sreset port %d (err = %d)\n,
warm ? warm : , port1, status);
} else {
status = hub_port_wait_reset(hub, port1, udev, delay,
warm);
if (status status != -ENOTCONN)
dev_dbg(hub-intfdev,
port_wait_reset: err = %d\n,
status);
}
}
appreciate your kind explanation,
--
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_hcd: Error while assigning device slot ID
That sounds like the xHCI host ran out of slot IDs. It may be that it simply can't handle having more than 24 devices connected to the system. The USB bus specification says that 255 devices can be connected to the host, but that doesn't mean the xHCI host controller has all the internal resources to support that. Ah, as a consumer I would not expect that, but I can certainly see manufacturers would love to save on registers. In practice then, most consumer products won’t allow you to connect more than a few dozen devices? Can you unload and reload the module with dynamic debugging enabled, and look for output in dmesg like: // xHC can handle at most %d device slots. There's an xHCI capabilities register that gets printed which contains the maximum number of device slots the xHCI host provides. Indeed, after turning on debug for at module initialisation I find that my NEC chip reports 32 device slots, while my VIA chip only supports 16 (these are the doorbell registers?). I’m a bit curious what the remaining slots are used for. When I plug in a single hub with debugging enabled I get Slot IDs up to 8. I suppose this is necessary since each hub is seen as both superspeed and high-speed device? My two Anker hubs then need 2x(4+4) = 16 slots leaving 13+3 slots for my devices consistent with my testing. I will be sure to read the capability register of the host controller for my next purchase, luckily my final setup will have a dedicated controller for each hub. Thanks Sarah for pointing out this basic limitation, — Amund Hov +47 412 96 298 amund@silabs.com This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication. Thank you. -- 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: problem with resume after s2ram
On Fri, 4 Apr 2014, Peter Münster wrote: On Tue, Apr 01 2014, Alan Stern wrote: Also, I'd like to track down the problem when both devices are plugged into front ports. Can you try that as well, again without the new diagnostic patch? The system hangs... Do you have a netconsole log? Hi Alan, Yes, here: [ 4694.420213] PM: Syncing filesystems ... done. [ 4694.591736] PM: Preparing system for mem sleep [ 4694.756151] Freezing user space processes ... (elapsed 0.002 seconds) done. [ 4694.758468] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 4694.759870] PM: Entering mem sleep [ 4694.760313] usb 6-3: usb suspend, wakeup 0 [ 4694.760464] usb 2-3: usb suspend, wakeup 0 [ 4694.760520] usb usb7: usb auto-resume [ 4694.760578] ohci-pci :00:14.5: resume root hub [ 4694.760753] usb usb5: usb auto-resume [ 4694.760813] ohci-pci :00:13.0: resume root hub [ 4694.760908] usb usb4: usb auto-resume [ 4694.760961] ohci-pci :00:12.1: resume root hub [ 4694.761058] usb usb3: usb auto-resume [ 4694.761086] ohci-pci :00:12.0: resume root hub [ 4694.761300] hub 2-0:1.0: hub_suspend [ 4694.761340] usb usb1: usb auto-resume [ 4694.761396] ehci-pci :00:12.2: resume root hub [ 4694.761422] usb usb2: bus suspend, wakeup 0 [ 4694.761481] ehci-pci :00:13.2: suspend root hub [ 4694.761554] sd 2:0:0:0: [sdb] Synchronizing SCSI cache [ 4694.761720] sd 2:0:0:0: [sdb] Stopping disk [ 4694.761862] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 4694.762063] sd 0:0:0:0: [sda] Stopping disk [ 4694.762223] usb 6-2: usb suspend, wakeup 1 [ 4697.508604] r8169 :02:00.0 eth0: link up [ 4699.733189] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4699.763610] ata3.00: configured for UDMA/133 [ 4699.768070] sd 2:0:0:0: [sdb] Starting disk [ 4701.366082] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4701.383352] ata1.00: configured for UDMA/133 [ 4701.387815] sd 0:0:0:0: [sda] Starting disk No error messages about hung-up tasks 120 seconds later? Should I do another git-bisect? Yes, that would be a good idea. Ok, but this will take some time. I can only do 1 or 2 reboots per day. That's fine. 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: about possible port reset when disconnect
On Fri, 4 Apr 2014, vichy wrote:
1. Platform-ehci Platform-ehci.0: port 1 reset error -110
the -110 is due to below handshake timeout.
retval = handshake(ehci, status_reg,
PORT_RESET, 0, 1000);
if (retval != 0) {
ehci_err (ehci, port %d reset error %d\n,
wIndex + 1, retval);
goto error;
}
Right -- although the handshake shouldn't time out. That's a bug in
the hardware.
if there is no connection, it is reasonable have return value as timeout.
No, it isn't. That handshake call waits for up to 1000 microseconds
for the controller to turn off the PORT_RESET bit, after the kernel
told it to turn the bit off. The controller should be able to turn the
RESET bit off whether there is a connection or not.
Why you think it is a bug in hardware?
The timeout error means that the kernel told the controller to turn off
the PORT_RESET bit, and 1000 us later the bit was still on. That's a
hardware bug.
2. hub 4-0:1.0: hub_port_status failed (err = -32)
the -32 is due to below error label we set retval = -EPIPE
error:
/* stall on error */
retval = -EPIPE;
But... This will happen only the first time we get the port status.
After that, ehci-reset_done[wIndex] will be 0 and so handshake() won't
get called.
hub_port_status() calls get_port_status(), which performs the operation
up to 3 times. The first time it will fail with -EPIPE, but what about
the second time?
in hub_port_reset, there PORT_RESET_TRIES, 5 in right now definition
to reset port.
and ehci-reset_done[wIndex] will refilled the (jiffies + 50ms) when
set port reset.
if in all PORT_RESET_TRIES loops, there is no device connected.
We will get -EPIPE all the time, right?
No.
for (i = 0; i PORT_RESET_TRIES; i++) {
status = set_port_feature(hub-hdev, port1, (warm ?
USB_PORT_FEAT_BH_PORT_RESET :
USB_PORT_FEAT_RESET));
if (status) {
dev_err(hub-intfdev,
cannot %sreset port %d (err = %d)\n,
warm ? warm : , port1, status);
} else {
status = hub_port_wait_reset(hub, port1, udev, delay,
warm);
You didn't look at what hub_port_wait_reset does. It calls
hub_port_status, which calls get_port_status, which has a loop.
if (status status != -ENOTCONN)
dev_dbg(hub-intfdev,
port_wait_reset: err = %d\n,
status);
}
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] usb: ohci-exynos: Remove locks for 'ohci' in suspend callback
Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend has already removed 'ohci_hcd' settings from exynos glue layer as a part of streamlining the ohci controller's suspend. So we don't need the locks for 'ohci_hcd' anymore. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Manjunath Goudar csmanjuvi...@gmail.com Cc: Alan Stern st...@rowland.harvard.edu --- drivers/usb/host/ohci-exynos.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index 68588d8..7f5e779 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -199,8 +199,6 @@ static int exynos_ohci_suspend(struct device *dev) if (rc) return rc; - spin_lock_irqsave(ohci-lock, flags); - if (exynos_ohci-otg) exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self); @@ -208,8 +206,6 @@ static int exynos_ohci_suspend(struct device *dev) clk_disable_unprepare(exynos_ohci-clk); - spin_unlock_irqrestore(ohci-lock, flags); - return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: ohci-exynos: Remove locks for 'ohci' in suspend callback
Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend
has already removed 'ohci_hcd' settings from exynos glue layer
as a part of streamlining the ohci controller's suspend.
So we don't need the locks for 'ohci_hcd' anymore.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-exynos.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 68588d8..9cf80cb 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -190,17 +190,13 @@ static int exynos_ohci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(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 = ohci_suspend(hcd, do_wakeup);
if (rc)
return rc;
- spin_lock_irqsave(ohci-lock, flags);
-
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
@@ -208,8 +204,6 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
- spin_unlock_irqrestore(ohci-lock, flags);
-
return 0;
}
--
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] usb: ohci-exynos: Remove locks for 'ohci' in suspend callback
On Fri, Apr 4, 2014 at 7:03 PM, Vivek Gautam gautamvivek1...@gmail.com wrote: Patch : 14982e3 USB: OHCI: Properly handle ohci-exynos suspend has already removed 'ohci_hcd' settings from exynos glue layer as a part of streamlining the ohci controller's suspend. So we don't need the locks for 'ohci_hcd' anymore. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Manjunath Goudar csmanjuvi...@gmail.com Cc: Alan Stern st...@rowland.harvard.edu --- Please ignore this patch, WIP, got sent by mistake :-( Sorry for spamming. drivers/usb/host/ohci-exynos.c |4 1 file changed, 4 deletions(-) diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c index 68588d8..7f5e779 100644 --- a/drivers/usb/host/ohci-exynos.c +++ b/drivers/usb/host/ohci-exynos.c @@ -199,8 +199,6 @@ static int exynos_ohci_suspend(struct device *dev) if (rc) return rc; - spin_lock_irqsave(ohci-lock, flags); - if (exynos_ohci-otg) exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self); @@ -208,8 +206,6 @@ static int exynos_ohci_suspend(struct device *dev) clk_disable_unprepare(exynos_ohci-clk); - spin_unlock_irqrestore(ohci-lock, flags); - return 0; } -- 1.7.10.4 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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
email Cerrado
Cuenta de correo web expirará en tres días, para validar su dirección de e-mail sigue el enlace a continuación y enviar de forma inmediata. https://www.formstack.com/forms/?1719124-hOPAVY0TYQ gracias administrador del sistema -- 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/OMAP: gadget does not start when cable is plugged after the driver is started
On Fri, Apr 04, 2014 at 09:45:06AM +0200, Stefan Roese wrote: Hi! I'm currently seeing a problem on an OMAP3530 based board (Technexion TAO3530). Where the MUSB is configured as device/peripheral and the ethernet gadget is compiled into the kernel. This works without any problems and usb0 is available when the USB cable is connected to a PC upon startup. But when the cable is disconnected when the driver is started (doesn't matter if the gadget is included in the kernel or if the gadget driver module is loaded) and the cable is plugged in later, the ethernet gadget does not start up. This is 100% reproducible. Before digging deeper into this, I wanted to check here if this is a known issue. And if anybody already has a solution/hint for it. FYI: I'm using v3.14 right now. Can you see if this helps ? commit e8fbe7b90021960907e885e0b7a9b52d378b0202 Author: Felipe Balbi ba...@ti.com Date: Fri Mar 28 14:31:47 2014 -0500 usb: musb: fix PHY power on/off commi 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic) removed phy_power_on() and phy_power_off() calls from runtime PM callbacks but it failed to note that the driver depended on pm_runtime_get_sync() calls to power up the PHY, thus leaving some platforms without any means to have a working PHY. Fix that by enabling the phy during omap2430_musb_init() and killing it in omap2430_musb_exit(). Fixes: 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic) Cc: sta...@vger.kernel.org # v3.14 Cc: Pali Rohár pali.ro...@gmail.com Cc: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com Reported-by: Michael Scott hashcod...@gmail.com Tested-by: Michael Scott hashcod...@gmail.com Reported-by: Rabin Vincent ra...@rab.in Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index d341c14..819a7cd 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -416,6 +416,7 @@ static int omap2430_musb_init(struct musb *musb) omap_musb_set_mailbox(glue); phy_init(musb-phy); + phy_power_on(musb-phy); pm_runtime_put_noidle(musb-controller); return 0; @@ -478,6 +479,7 @@ static int omap2430_musb_exit(struct musb *musb) del_timer_sync(musb_idle_timer); omap2430_low_level_exit(musb); + phy_power_off(musb-phy); phy_exit(musb-phy); return 0; -- balbi signature.asc Description: Digital signature
Re: MUSB/OMAP: gadget does not start when cable is plugged after the driver is started
Hi Felipe, On 04.04.2014 16:34, Felipe Balbi wrote: On Fri, Apr 04, 2014 at 09:45:06AM +0200, Stefan Roese wrote: Hi! I'm currently seeing a problem on an OMAP3530 based board (Technexion TAO3530). Where the MUSB is configured as device/peripheral and the ethernet gadget is compiled into the kernel. This works without any problems and usb0 is available when the USB cable is connected to a PC upon startup. But when the cable is disconnected when the driver is started (doesn't matter if the gadget is included in the kernel or if the gadget driver module is loaded) and the cable is plugged in later, the ethernet gadget does not start up. This is 100% reproducible. Before digging deeper into this, I wanted to check here if this is a known issue. And if anybody already has a solution/hint for it. FYI: I'm using v3.14 right now. Can you see if this helps ? commit e8fbe7b90021960907e885e0b7a9b52d378b0202 Author: Felipe Balbi ba...@ti.com Date: Fri Mar 28 14:31:47 2014 -0500 usb: musb: fix PHY power on/off commi 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic) removed phy_power_on() and phy_power_off() calls from runtime PM callbacks but it failed to note that the driver depended on pm_runtime_get_sync() calls to power up the PHY, thus leaving some platforms without any means to have a working PHY. Fix that by enabling the phy during omap2430_musb_init() and killing it in omap2430_musb_exit(). Fixes: 30a70b0 (usb: musb: fix obex in g_nokia.ko causing kernel panic) Cc: sta...@vger.kernel.org # v3.14 Cc: Pali Rohár pali.ro...@gmail.com Cc: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com Reported-by: Michael Scott hashcod...@gmail.com Tested-by: Michael Scott hashcod...@gmail.com Reported-by: Rabin Vincent ra...@rab.in Signed-off-by: Felipe Balbi ba...@ti.com Yes, this patch fixes this problem. Thanks a lot! Tested-by: Stefan Roese s...@denx.de Thanks, Stefan -- 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/9] pci-rcar-gen2: add devicetree support
On Thu, Mar 06, 2014 at 06:01:19PM +, Ben Dooks wrote:
Add OF match table for pci-rcar-gen2 driver for device tree support.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
I'm not sure what the status of this is. I saw comments about a missing
#include, but I didn't see a fixed repost. Ben, could you please repost
anything you have outstanding for me?
---
Updates since v1:
- moved documentation into patch
- moved to using bus-range parsing
- ensured usb phy can be linked to usb devices
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Simon Horman ho...@verge.net.au
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
.../bindings/pci/renessas,pci-rcar-gen2.txt| 52
++
drivers/pci/host/pci-rcar-gen2.c | 33 +-
2 files changed, 83 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pci/renessas,pci-rcar-gen2.txt
diff --git a/Documentation/devicetree/bindings/pci/renessas,pci-rcar-gen2.txt
b/Documentation/devicetree/bindings/pci/renessas,pci-rcar-gen2.txt
new file mode 100644
index 000..bd6d291
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/renessas,pci-rcar-gen2.txt
@@ -0,0 +1,52 @@
+Renesas AHB to PCI bridge
+-
+
+This is the bridge used internally to connect the USB controllers to the
+AHB. There is one bridge instance per USB port consiting of an internal
+OHCI and EHCI controller.
+
+Required properties:
+ - compatible: renesas,pci-r8a7790 for the R8A7790 SoC
+ - reg : A list of physical regions to access the device. The first is
+ the operational registers for the OHCI/EHCI controller and the
+ second region is for the bridge configuration and control registers.
+ - interrupts : interrupt for the device
+ - clocks : The reference to the device clock
+ - bus-range: The PCI bus number ranges. As this is a single bus, the range
+ should be specified as the same value twice.
+
+
+Example SoC configuration:
+
+ pci0: pci@ee09 {
+ compatible = renesas,pci-r8a7790;
+ clocks = mstp7_clks R8A7790_CLK_EHCI;
+ reg = 0x0 0xee09 0x0 0xc00,
+ 0x0 0xee08 0x0 0x1100;
+ interrupts = 0 108 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+
+ bus-range = 0 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ };
+
+Example board setup:
+
+pci1 {
+ status = okay;
+ pinctrl-0 = usb1_pins;
+ pinctrl-names = default;
+
+ pci@0,1 {
+ reg = 0x800 0 0 0 0;
+ device_type = pci;
+ usb-phy = usbphy;
+ };
+
+ pci@0,2 {
+ reg = 0x1000 0 0 0 0;
+ device_type = pci;
+ usb-phy = usbphy;
+ };
+};
diff --git a/drivers/pci/host/pci-rcar-gen2.c
b/drivers/pci/host/pci-rcar-gen2.c
index fd3e3ab..1216784 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -16,6 +16,7 @@
#include linux/kernel.h
#include linux/module.h
#include linux/pci.h
+#include linux/of_pci.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/sizes.h
@@ -98,6 +99,7 @@ struct rcar_pci_priv {
struct resource io_res;
struct resource mem_res;
struct resource *cfg_res;
+ unsigned busnr;
int irq;
unsigned long window_size;
};
@@ -312,8 +314,8 @@ static int rcar_pci_setup(int nr, struct pci_sys_data
*sys)
pci_add_resource(sys-resources, priv-io_res);
pci_add_resource(sys-resources, priv-mem_res);
- /* Setup bus number based on platform device id */
- sys-busnr = to_platform_device(priv-dev)-id;
+ /* Setup bus number based on platform device id / of bus-range */
+ sys-busnr = priv-busnr;
return 1;
}
@@ -366,6 +368,23 @@ static int rcar_pci_probe(struct platform_device *pdev)
priv-window_size = SZ_1G;
+ if (pdev-dev.of_node) {
+ struct resource busnr;
+ int ret;
+
+ ret = of_pci_parse_bus_range(pdev-dev.of_node, busnr);
+ if (ret 0) {
+ dev_err(pdev-dev, failed to parse bus-range\n);
+ return ret;
+ }
+
+ priv-busnr = busnr.start;
+ if (busnr.end != busnr.start)
+ dev_warn(pdev-dev, only one bus number supported\n);
+ } else {
+ priv-busnr = pdev-id;
+ }
+
hw_private[0] = priv;
memset(hw, 0, sizeof(hw));
hw.nr_controllers = ARRAY_SIZE(hw_private);
@@ -377,11 +396,21 @@ static int rcar_pci_probe(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id rcar_pci_of_match[] = {
+ { .compatible = renesas,pci-r8a7790, },
Re: [PATCH 1/9] pci-rcar-gen2: add devicetree support
On 04/04/14 18:09, Bjorn Helgaas wrote: On Thu, Mar 06, 2014 at 06:01:19PM +, Ben Dooks wrote: Add OF match table for pci-rcar-gen2 driver for device tree support. Signed-off-by: Ben Dooks ben.do...@codethink.co.uk I'm not sure what the status of this is. I saw comments about a missing #include, but I didn't see a fixed repost. Ben, could you please repost anything you have outstanding for me? Sergei was going to re-post this series. I can have a look at re-sending this later today if he hasn't already sorted it out. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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/9] pci-rcar-gen2: add devicetree support
Hello. On 04/04/2014 09:09 PM, Bjorn Helgaas wrote: Add OF match table for pci-rcar-gen2 driver for device tree support. Signed-off-by: Ben Dooks ben.do...@codethink.co.uk I'm not sure what the status of this is. I saw comments about a missing #include, but I didn't see a fixed repost. Since there was none. :-) Ben, could you please repost anything you have outstanding for me? I took updating this patch into my hands with Ben's consent, so I'll repost it soonish. 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: xhci_hcd: Error while assigning device slot ID
The USB bus specification says that 255 devices can be connected to the host, but that doesn't mean the xHCI host controller has all the internal resources to support that. To me that sounds like such xHCI HCs can not be considered USB compliant. :\ //Peter -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] ftdi-elan: neatening
Found when looking for invalid vsprintf %foo types, with some other neatenings done. Joe Perches (5): usb: ftdi-elan: Fix format fragments usb: ftdi-elan: Convert leading spaces to tabs usb: ftdi-elan: Coalesce formats usb: ftdi-elan: Coalesce string fragment usb: ftdi-elan: Use pr_level drivers/usb/misc/ftdi-elan.c | 4878 +- 1 file changed, 2419 insertions(+), 2459 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- 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
drivers/usb/misc/ftdi-elan.c: odd retry code
(It seems as if elandigitalsystems.com doesn't exist
any longer, Tony Olech cc'd just for the hellofit)
Code like this seems to be an infinite loop
if command_size = COMMAND_SIZE and elan_command_work
returns -ENOMEM.
There are a lot of them in this driver.
Is this never-tested/defective, or am I misreading?
static int ftdi_elan_write_reg(struct usb_ftdi *ftdi, u32 data)
{
wait:if (ftdi-disconnected 0) {
return -ENODEV;
} else {
int command_size;
mutex_lock(ftdi-u132_lock);
command_size = ftdi-command_next - ftdi-command_head;
if (command_size COMMAND_SIZE) {
struct u132_command *command = ftdi-command[
COMMAND_MASK ftdi-command_next];
command-header = 0x00 | cPCIu132wr;
command-length = 0x04;
command-address = 0x00;
command-width = 0x00;
command-follows = 4;
command-value = data;
command-buffer = command-value;
ftdi-command_next += 1;
ftdi_elan_kick_command_queue(ftdi);
mutex_unlock(ftdi-u132_lock);
return 0;
} else {
mutex_unlock(ftdi-u132_lock);
msleep(100);
goto wait;
}
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] usb: ftdi-elan: Coalesce string fragment
Make it easier to grep for this.
Neaten a trailing statement.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/usb/misc/ftdi-elan.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 8cda881..10c54b3 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -55,8 +55,8 @@ MODULE_LICENSE(GPL);
#define INT_MODULE_PARM(n, v) static int n = v;module_param(n, int, 0444)
static bool distrust_firmware = 1;
module_param(distrust_firmware, bool, 0);
-MODULE_PARM_DESC(distrust_firmware, true to distrust firmware
power/overcurren
-t setup);
+MODULE_PARM_DESC(distrust_firmware,
+true to distrust firmware power/overcurrent setup);
extern struct platform_driver u132_platform_driver;
static struct workqueue_struct *status_queue;
static struct workqueue_struct *command_queue;
@@ -590,8 +590,7 @@ static void ftdi_elan_status_work(struct work_struct *work)
ftdi_elan_flush_targets(ftdi);
work_delay_in_msec = 250;
} else {
- dev_err(ftdi-udev-dev, PCI device has disappeared\n
- );
+ dev_err(ftdi-udev-dev, PCI device has
disappeared\n);
ftdi_elan_cancel_targets(ftdi);
work_delay_in_msec = 500;
ftdi-enumerated = 0;
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] usb: ftdi-elan: Use pr_level
Use a more current logging style.
Add pr_fmt to prefix messages appropriately.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/usb/misc/ftdi-elan.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 10c54b3..8ab1f8f 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -35,6 +35,9 @@
* via an ELAN U132 adapter.
*
*/
+
+#define pr_fmt(fmt) KBUILD_MODNAME : fmt
+
#include linux/kernel.h
#include linux/errno.h
#include linux/init.h
@@ -623,7 +626,7 @@ static int ftdi_elan_open(struct inode *inode, struct file
*file)
interface = usb_find_interface(ftdi_elan_driver, subminor);
if (!interface) {
- printk(KERN_ERR can't find device for minor %d\n, subminor);
+ pr_err(can't find device for minor %d\n, subminor);
return -ENODEV;
} else {
struct usb_ftdi *ftdi = usb_get_intfdata(interface);
@@ -2722,10 +2725,8 @@ static int ftdi_elan_probe(struct usb_interface
*interface,
struct usb_ftdi *ftdi;
ftdi = kzalloc(sizeof(struct usb_ftdi), GFP_KERNEL);
- if (!ftdi) {
- printk(KERN_ERR Out of memory\n);
+ if (!ftdi)
return -ENOMEM;
- }
mutex_lock(ftdi_module_lock);
list_add_tail(ftdi-ftdi_list, ftdi_static_list);
@@ -2849,7 +2850,7 @@ static struct usb_driver ftdi_elan_driver = {
static int __init ftdi_elan_init(void)
{
int result;
- printk(KERN_INFO driver %s\n, ftdi_elan_driver.name);
+ pr_info(driver %s\n, ftdi_elan_driver.name);
mutex_init(ftdi_module_lock);
INIT_LIST_HEAD(ftdi_static_list);
status_queue = create_singlethread_workqueue(ftdi-status-control);
@@ -2866,8 +2867,7 @@ static int __init ftdi_elan_init(void)
destroy_workqueue(status_queue);
destroy_workqueue(command_queue);
destroy_workqueue(respond_queue);
- printk(KERN_ERR usb_register failed. Error number %d\n,
- result);
+ pr_err(usb_register failed. Error number %d\n, result);
}
return result;
@@ -2876,7 +2876,7 @@ err_respond_queue:
err_command_queue:
destroy_workqueue(status_queue);
err_status_queue:
- printk(KERN_ERR %s couldn't create workqueue\n,
ftdi_elan_driver.name);
+ pr_err(%s couldn't create workqueue\n, ftdi_elan_driver.name);
return -ENOMEM;
}
@@ -2885,7 +2885,7 @@ static void __exit ftdi_elan_exit(void)
struct usb_ftdi *ftdi;
struct usb_ftdi *temp;
usb_deregister(ftdi_elan_driver);
- printk(KERN_INFO ftdi_u132 driver deregistered\n);
+ pr_info(ftdi_u132 driver deregistered\n);
list_for_each_entry_safe(ftdi, temp, ftdi_static_list, ftdi_list) {
ftdi_status_cancel_work(ftdi);
ftdi_command_cancel_work(ftdi);
--
1.8.1.2.459.gbcd45b4.dirty
--
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 3/5] usb: ftdi-elan: Coalesce formats
Make it easier to find formats.
Realign arguments around these changes.
Signed-off-by: Joe Perches j...@perches.com
---
drivers/usb/misc/ftdi-elan.c | 151 ---
1 file changed, 56 insertions(+), 95 deletions(-)
diff --git a/drivers/usb/misc/ftdi-elan.c b/drivers/usb/misc/ftdi-elan.c
index 0487f8e..8cda881 100644
--- a/drivers/usb/misc/ftdi-elan.c
+++ b/drivers/usb/misc/ftdi-elan.c
@@ -545,11 +545,10 @@ static void ftdi_elan_status_work(struct work_struct
*work)
ftdi-stuck_status = 0;
ftdi-synchronized = 0;
} else if ((ftdi-stuck_status++ % 60) == 1) {
- dev_err(ftdi-udev-dev, WRONG type of card inserted
- - please remove\n);
+ dev_err(ftdi-udev-dev, WRONG type of card inserted
- please remove\n);
} else
- dev_err(ftdi-udev-dev, WRONG type of card inserted
- - checked %d times\n, ftdi-stuck_status);
+ dev_err(ftdi-udev-dev, WRONG type of card inserted
- checked %d times\n,
+ ftdi-stuck_status);
work_delay_in_msec = 100;
} else if (ftdi-enumerated == 0) {
if (ftdi_elan_enumeratePCI(ftdi) == 0) {
@@ -562,8 +561,7 @@ static void ftdi_elan_status_work(struct work_struct *work)
ftdi-initialized = 1;
work_delay_in_msec = 500;
} else {
- dev_err(ftdi-udev-dev, initialized failed - trying
- again in 10 seconds\n);
+ dev_err(ftdi-udev-dev, initialized failed - trying
again in 10 seconds\n);
work_delay_in_msec = 1 *1000;
}
} else if (ftdi-registered == 0) {
@@ -578,9 +576,7 @@ static void ftdi_elan_status_work(struct work_struct *work)
work_delay_in_msec = 250;
} else if (ftdi-controlreg 0x0040) {
if (ftdi-gone_away 0) {
- dev_err(ftdi-udev-dev, PCI device eject con
- firmed platform_dev.dev.parent=%p plat
- form_dev.dev=%p\n,
+ dev_err(ftdi-udev-dev, PCI device eject
confirmed platform_dev.dev.parent=%p platform_dev.dev=%p\n,
ftdi-platform_dev.dev.parent,
ftdi-platform_dev.dev);
platform_device_unregister(ftdi-platform_dev);
@@ -788,17 +784,15 @@ static int ftdi_elan_command_engine(struct usb_ftdi *ftdi)
total_size = ftdi_elan_total_command_size(ftdi, command_size);
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
- dev_err(ftdi-udev-dev, could not get a urb to write %d comm
- ands totaling %d bytes to the Uxxx\n, command_size,
- total_size);
+ dev_err(ftdi-udev-dev, could not get a urb to write %d
commands totaling %d bytes to the Uxxx\n,
+ command_size, total_size);
return -ENOMEM;
}
buf = usb_alloc_coherent(ftdi-udev, total_size, GFP_KERNEL,
urb-transfer_dma);
if (!buf) {
- dev_err(ftdi-udev-dev, could not get a buffer to write %d c
- ommands totaling %d bytes to the Uxxx\n, command_size,
- total_size);
+ dev_err(ftdi-udev-dev, could not get a buffer to write %d
commands totaling %d bytes to the Uxxx\n,
+ command_size, total_size);
usb_free_urb(urb);
return -ENOMEM;
}
@@ -824,9 +818,8 @@ static int ftdi_elan_command_engine(struct usb_ftdi *ftdi)
}
retval = usb_submit_urb(urb, GFP_KERNEL);
if (retval) {
- dev_err(ftdi-udev-dev, failed %d to submit urb %p to write
- %d commands totaling %d bytes to the Uxxx\n, retval,
- urb, command_size, total_size);
+ dev_err(ftdi-udev-dev, failed %d to submit urb %p to write
%d commands totaling %d bytes to the Uxxx\n,
+ retval, urb, command_size, total_size);
usb_free_coherent(ftdi-udev, total_size, buf,
urb-transfer_dma);
usb_free_urb(urb);
return retval;
@@ -980,8 +973,7 @@ read:{
goto have;
} else if (retval == -ETIMEDOUT) {
if (retry_on_timeout-- 0) {
- dev_err(ftdi-udev-dev, TIMED OUT with packe
- t_bytes = %d with total %d bytes%s\n,
+ dev_err(ftdi-udev-dev, TIMED OUT with
packet_bytes =
[PATCH] usb: phy: msm: Select secondary PHY via TCSR
Select the secondary PHY using the TCSR register, if phy-num=1
in the DTS (or phy_number is set in the platform data). The
SOC has 2 PHYs which can be used with the OTG port, and this
code allows configuring the correct one.
Note: This resolves the problem I was seeing where I couldn't
get the USB driver working at all on a dragonboard, from cold
boot. This patch depends on patch 5/14 from Ivan's msm USB
patch set. It does not use DT for the register address, as
there's no evidence that this address changes between SoC
versions.
Signed-off-by: Tim Bird tim.b...@sonymobile.com
---
drivers/usb/phy/phy-msm-usb.c| 14 ++
include/linux/usb/msm_hsusb_hw.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index c4820e6..0272489 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1518,6 +1518,7 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
struct resource *res;
struct msm_otg *motg;
struct usb_phy *phy;
+ void __iomem *phy_select;
motg = devm_kzalloc(pdev-dev, sizeof(struct msm_otg), GFP_KERNEL);
if (!motg) {
@@ -1580,6 +1581,19 @@ static int __init msm_otg_probe(struct platform_device
*pdev)
if (IS_ERR(motg-regs))
return PTR_ERR(motg-regs);
+ /*
+* NOTE: The PHYs can be multiplexed between the chipidea controller
+* and the dwc3 controller, using a single bit. It is important that
+* the dwc3 driver does not set this bit in an incompatible way.
+*/
+ if (motg-phy_number) {
+ phy_select = devm_ioremap_nocache(pdev-dev, USB2_PHY_SEL, 4);
+ if (IS_ERR(phy_select))
+ return PTR_ERR(phy_select);
+ /* Enable second PHY with the OTG port */
+ writel_relaxed(0x1, phy_select);
+ }
+
dev_info(pdev-dev, OTG regs = %p\n, motg-regs);
motg-irq = platform_get_irq(pdev, 0);
diff --git a/include/linux/usb/msm_hsusb_hw.h b/include/linux/usb/msm_hsusb_hw.h
index 575c743..10bf692 100644
--- a/include/linux/usb/msm_hsusb_hw.h
+++ b/include/linux/usb/msm_hsusb_hw.h
@@ -16,6 +16,9 @@
#ifndef __LINUX_USB_GADGET_MSM72K_UDC_H__
#define __LINUX_USB_GADGET_MSM72K_UDC_H__
+/* USB phy selector - in TCSR address range */
+#define USB2_PHY_SEL 0xfd4ab000
+
#define USB_AHBBURST (MSM_USB_BASE + 0x0090)
#define USB_AHBMODE (MSM_USB_BASE + 0x0098)
#define USB_CAPLENGTH(MSM_USB_BASE + 0x0100) /* 8 bit */
--
1.8.2.2
--
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] gadget: rndis: Include u_rndis.h
From: Fabio Estevam fabio.este...@freescale.com Include u_rndis.h in order to fix the following sparse warning: drivers/usb/gadget/rndis.c:1144:5: warning: symbol 'rndis_init' was not declared. Should it be static? drivers/usb/gadget/rndis.c:1177:6: warning: symbol 'rndis_exit' was not declared. Should it be static? Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- drivers/usb/gadget/rndis.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c index d822d82..7ed452d 100644 --- a/drivers/usb/gadget/rndis.c +++ b/drivers/usb/gadget/rndis.c @@ -35,6 +35,7 @@ #include asm/byteorder.h #include asm/unaligned.h +#include u_rndis.h #undef VERBOSE_DEBUG -- 1.8.3.2 -- 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
