Re: [RESEND PATCH v2] documentation: docbook: document process of writing an musb glue layer
Hi, On Mon, Apr-07-2014 at 06:02:18 PM -0500, Felipe Balbi wrote: Hi, On Mon, Apr 07, 2014 at 03:12:09PM -0700, Randy Dunlap wrote: On 04/05/2014 11:42 AM, Apelete Seketeli wrote: Document the process of writing an musb glue layer by taking the Ingenic JZ4740 glue layer as an example, as it seems more simple than most glue layers due to the basic feature set of the JZ4740 USB device controller. Signed-off-by: Apelete Seketeli apel...@seketeli.net Hi, You should be cc-ing the musb maintainer and the USB mailing list (so now done). That was my intent in the first place -- I mentioned the USB mailing list in the cover letter and then forgot to actually cc the people over there. Thanks for taking care of that. Felipe should probably be the person to merge this unless he wants me to do it... I'll merge it, just resend once -rc1 is out. Thanks Ok, I'll resend once -rc1 is out. Thanks for your time. Cheers. -- Apelete -- 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 07.04.2014 18:04, Felipe Balbi wrote:
snip
that's not caused by my patch, it's a previously existing bug. This
should sort it out:
commit e7f69404a878b5345ad07bf06d78559ecd31db79
Author: Felipe Balbi ba...@ti.com
Date: Mon Apr 7 10:58:01 2014 -0500
usb: musb: omap2430: make sure clocks are enabled when running mailbox
on early initialization we could fall into
a situation where the mailbox is called before
MUSB's clocks are running, in order to avoid
that, make sure mailbox is always wrapped with
pm_runtime calls.
Reported-by: Stefan Roese s...@denx.de
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 819a7cd..d369bf1 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -316,7 +316,13 @@ static void omap_musb_mailbox_work(struct work_struct
*mailbox_work)
{
struct omap2430_glue *glue = container_of(mailbox_work,
struct omap2430_glue, omap_musb_mailbox_work);
+ struct musb *musb = glue_to_musb(glue);
+ struct device *dev = musb-controller;
+
+ pm_runtime_get_sync(dev);
omap_musb_set_mailbox(glue);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
}
static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
let me know
The crash doesn't appear anymore with this patch. But the ethernet
gadget is not started. This happens also with a plugged cable upon
driver startup. Now I see an error in the log:
[2.793121] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in b_idle (80, SessEnd),
retry #0, port1 0100
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] cdc-acm: some enhancement on acm delayed write
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
We find two problems on acm tty write delayed mechanism.
Then you should split this into two patches.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm suspend. More acm write
may be abandoned.
Why not simply return 0 in write and use the tty buffering rather than
implement another buffer in cdc_acm?
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when
close. If acm resume callback run after ASYNCB_INITIALIZED flag
cleared, there will have no chance for delayed write to start.
That lead to acm_wb.use can't be cleared. If user space open
acm tty again and try to setd, tty will be blocked in
tty_wait_until_sent for ever.
This patch have two modification.
(1) use list_head to save the write acm_wb during acm suspend.
It can ensure no acm write abandoned.
(2) enable flush buffer callback when acm tty close. acm delayed
wb will start before acm port shutdown callback, it make sure
the delayed acm_wb.use to be cleared. The patch also clear
acm_wb.use and acm.transmitting when port shutdown.
This is not the right way to do this. See below.
Signed-off-by: xiao jin jin.x...@intel.com
Reviewed-by: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/class/cdc-acm.c | 56
++-
drivers/usb/class/cdc-acm.h |3 ++-
2 files changed, 42 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff..cfe00b2 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -217,6 +217,24 @@ static int acm_start_wb(struct acm *acm, struct
acm_wb *wb)
}
/*
+ * Delayed write.
+ */
+static int acm_start_delayed_wb(struct acm *acm)
+{
+ struct acm_wb *wb, *n_wb;
+ LIST_HEAD(delay_wb_list);
+
+ spin_lock_irq(acm-write_lock);
+ list_replace_init(acm-delayed_wb_list, delay_wb_list);
+ spin_unlock_irq(acm-write_lock);
+ list_for_each_entry_safe(wb, n_wb,
+ delay_wb_list, delay) {
+ list_del(wb-delay);
+ acm_start_wb(acm, wb);
+ }
+}
+
+/*
* attributes exported through sysfs
*/
static ssize_t show_caps
@@ -580,8 +598,11 @@ static void acm_port_shutdown(struct tty_port *port)
usb_autopm_get_interface(acm-control);
acm_set_control(acm, acm-ctrlout = 0);
usb_kill_urb(acm-ctrlurb);
- for (i = 0; i ACM_NW; i++)
+ acm-transmitting = 0;
No need to reset transmitting which is balanced by usb_kill_urb below.
+ for (i = 0; i ACM_NW; i++) {
usb_kill_urb(acm-wb[i].urb);
+ acm-wb[i].use = 0;
Same here: use is generally cleared by the completion handler -- you
only need to handle any delayed urb.
+ }
for (i = 0; i acm-rx_buflimit; i++)
usb_kill_urb(acm-read_urbs[i]);
acm-control-needs_remote_wakeup = 0;
@@ -608,6 +629,8 @@ static void acm_tty_close(struct tty_struct *tty,
struct file *filp)
{
struct acm *acm = tty-driver_data;
dev_dbg(acm-control-dev, %s\n, __func__);
+ /* Set flow_stopped to enable flush buffer*/
+ tty-flow_stopped = 1;
You shouldn't abuse the flow_stopped flag. Simply clear the delayed urb
in shutdown (rather than try to use flush_buffer).
tty_port_close(acm-port, tty, filp);
}
@@ -646,10 +669,7 @@ static int acm_tty_write(struct tty_struct *tty,
usb_autopm_get_interface_async(acm-control);
if (acm-susp_count) {
- if (!acm-delayed_wb)
- acm-delayed_wb = wb;
- else
- usb_autopm_put_interface_async(acm-control);
+ list_add_tail(wb-delay, acm-delayed_wb_list);
spin_unlock_irqrestore(acm-write_lock, flags);
return count; /* A white lie */
}
@@ -688,6 +708,18 @@ static int acm_tty_chars_in_buffer(struct
tty_struct *tty)
return (ACM_NW - acm_wb_is_avail(acm)) * acm-writesize;
}
+static void acm_tty_flush_buffer(struct tty_struct *tty)
+{
+ struct acm *acm = tty-driver_data;
+
+ /* flush delayed write buffer */
+ if (!acm-disconnected) {
+ usb_autopm_get_interface(acm-control);
+ acm_start_delayed_wb(acm);
+ usb_autopm_put_interface(acm-control);
+ }
+}
+
Again, don't use flush_buffer for this (it's used to discard output
buffers).
Johan
static void acm_tty_throttle(struct tty_struct *tty)
{
struct acm *acm = tty-driver_data;
@@ -1346,6 +1378,7 @@ made_compressed_probe:
snd-urb-transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
snd-instance = acm;
}
+ INIT_LIST_HEAD(acm-delayed_wb_list);
usb_set_intfdata(intf, acm);
@@ -1540,7 +1573,6 @@
Re: [PATCH] xhci: Report max device limit when Enable Slot command fails.
I completely understand your frustration, and it actually is relevant to kernel development. :) Perhaps the attached patch would have at least saved you some time and frustration in debugging the driver and host issue? Thanks Sarah. An error like that would allow me to know what the error is and where to look for host capabilities. Is this the only case in which slot_id would not be properly set? — 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: xhci: non-superspeed enumeration failure
On Mon, Apr 07, 2014 at 07:26:01PM +0300, Mathias Nyman wrote: On 04/03/2014 07:32 PM, Johan Hovold wrote: Hi Mathias and Benjamin, Mathias, I understand you've got quite a lot on your plate with xhci at the moment, but have you had a change to look at this issue yet? It's an xhci-issue (possibly due to buggy hw) which seems related to the non-superspeed enumeration work that was made by Sarah and Dan during the fall. In summary, the device works fine with ehci, but fails to enumerate with xhci. Prior to 3.14 this resulted in babble errors, but since 3.14 it appears that enumeration times out instead: xhci_hcd :00:14.0: Timeout while waiting for setup address command Sometimes it enumerates successfully with 3.14, though. Not sure if it's related, but Benjamin was also able to trigger: xhci_hcd :00:14.0: HC died; cleaning up The full thread is available here: http://marc.info/?l=linux-usbm=139464536212863w=2 (The usb-serial related bits are really just about recognising the VID/PID and is unrelated to the xhci-enumeration problem.) Do you need any further information from Benjamin? It might be related to Dan's enumeration scheme change, but looking at the xhci parts of the logs there seems to be both Address command timeout and halting/stalling endpoint clearing issues. There is currently an issue with clearing halted endpoints and toggle bit getting out of sync on xhci which I'm about to take on, this could be related. http://marc.info/?l=libusb-develm=134930472420570w=2 Hopefully, fixing that will solve some of the issues you are seeing as well. There's also a rfc patchset which completely changes how xhci handles command timeouts. You could also test if it has any impact on the address command timeout. http://marc.info/?l=linux-usbm=139653559120996w=2 Alright, thanks for taking a look. Benjamin, were you able to reproduce this on a different host controller? If you're interested in debugging this further you could try Mathias timeout RFC. I could prepare a branch for you to pull if that'd simplify things. Thanks, 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: [PATCH 2/2] USB: serial: add dell wwan card(413c:81a9)
AceLan Kao acelan@canonical.com writes:
Hi,
I'm not an expert of this field, so I can't really understand your reply.
So, is the patch is acceptable?
And I have another pci modem card with id 413c:81a3.
I tried to add its id into sierra driver, but no luck.
I still don't think the sierra driver is correct for these devices. But
the reason you have no success is because cfg #2 of this device has no
serial functions at all. It's a MBIM only config. More (very technical)
details follow...
Here are the logs, could you also take a look of it?
[..]
[2.924414] usb 1-1.8.3: new high-speed USB device number 7 using ehci-pci
[2.928390] Switched to clocksource tsc
[3.028854] usb 1-1.8.3: config 1 has an invalid interface number: 8 but
max is 3
[3.028859] usb 1-1.8.3: config 1 has no interface number 1
many modern Sierra Wireless devices use fixed interface numbers to
identify different function types. They do this both for vendor
specific functions and for class functions. The lsusb output will show
the same, but we can figure out lots of stuff based on the two lines
above:
- max is 3 = there are 4 interfaces in total in cfg #1
- invalid interface number: 8 = one of them is numbered '8'.
- no interface number 1 = interfaces 0, 2 and 3 exists
So this is a typical Sierra QMI config, with 3 serial funcions and one
network function:
0: QCDM
2: NMEA (Qualcomm)
3: AT + PPP modem
8: QMI/wwan
These interfaces all use ff/ff/ff class codes, so we have to look at the
interface numbers to tell them apart.
We've (well, OK I have. My fault...) previously added a number of
similar devices to the qcserial driver, using 3 lines per device and the
USB_DEVICE_INTERFACE_NUMBER to match only the serial functions. This
works, but having 3 matching entries per device doesn't really scale too
well. Sierra are obviously selling these designs to vendors using their
own device IDs, so we must expect the number of such entries to grow.
I guess we should create a probe explicitly for this type of device?
Maybe just extend the qcserial driver with a sierra device type in
addition to the gobi1k and gobi2k types?
[3.029353] usb 1-1.8.3: config 2 has an invalid interface number: 12 but
max is 1
[3.029358] usb 1-1.8.3: config 2 has an invalid interface number: 13 but
max is 1
[3.029361] usb 1-1.8.3: config 2 has an invalid interface number: 13 but
max is 1
[3.029363] usb 1-1.8.3: config 2 has no interface number 0
[3.029364] usb 1-1.8.3: config 2 has no interface number 1
And this device has a 2nd configuration with only 2 interfaces, number
12 and 13. Sierra use these numbers for MBIM control and data
interfaces.
This will be the default configuration in Linux because the first
interface (number 12) has a proper class (CDC MBIM), while the first
interface of configuration #1 is vendor specific. This default can be a
bit surprising. Especially the fact that it isn't tied to the
availability of a class driver, and we do have quite a few kernel
releases where there are drivers for cfg #1 but not for cfg#2. But this
device shows why the policy is sane: Each new device ID must be added to
the vendor specific drivers before they can work, while the class driver
just works even if we've never heard of this device before:
[ 11.141019] cdc_mbim 1-1.8.3:2.12: cdc-wdm1: USB WDM device
[ 11.141208] cdc_mbim 1-1.8.3:2.12 wwan0: register 'cdc_mbim' at
usb-:00:1d.0-1.8.3, CDC MBIM, ba:e1:96:a8:eb:2f
So everything is fine :-)
Not really. We should update the vendor specific drivers as well to
allow users to choose serial + QMI instead of MBIM. That means qmi_wwan
and *some* serial driver. But the vendor specific drivers still won't
be used by default for this device unless you create an udev rule.
Example only - I'm no udev expert:
ATTR{idVendor}==413c,ATTR{idProduct}==81a3,ATTR{bConfigurationValue}==2
ATTR{bConfigurationValue}=1
Bjørn
--
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: add glue layer dependencies
Glue layers for the DWC3 driver only make sense on specific platforms. Add dependencies so that they are not built where they aren't needed. Signed-off-by: Jean Delvare jdelv...@suse.de Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: WingMan Kwok w-kw...@ti.com --- drivers/usb/dwc3/Kconfig |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- linux-3.15-rc0.orig/drivers/usb/dwc3/Kconfig2014-03-31 05:40:15.0 +0200 +++ linux-3.15-rc0/drivers/usb/dwc3/Kconfig 2014-04-08 10:36:19.218960761 +0200 @@ -44,7 +44,7 @@ comment Platform Glue Driver Support config USB_DWC3_OMAP tristate Texas Instruments OMAP5 and similar Platforms - depends on EXTCON + depends on EXTCON (ARCH_OMAP2PLUS || COMPILE_TEST) default USB_DWC3 help Some platforms from Texas Instruments like OMAP5, DRA7xxx and @@ -54,6 +54,7 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate Samsung Exynos Platform + depends on ARCH_EXYNOS || COMPILE_TEST default USB_DWC3 help Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside, @@ -72,6 +73,7 @@ config USB_DWC3_PCI config USB_DWC3_KEYSTONE tristate Texas Instruments Keystone2 Platforms + depends on ARCH_KEYSTONE || COMPILE_TEST default USB_DWC3 help Support of USB2/3 functionality in TI Keystone2 platforms. -- Jean Delvare SUSE L3 Support -- 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
Fwd: Isochronos audio
-- Forwarded message -- From: Russel Hughes russel.hug...@gmail.com Date: 6 April 2014 11:32 Subject: Isochronos audio To: linux-usb linux-usb@vger.kernel.org Can you describe the actual problem ? How can you trigger it ? What are you doing when the problem arises ? Do you hear audio glitches or does the device disconnect ? Do you have a crash ? Does the *same* device work on other setups ? Try to capture a usbmon trace of the failure, that's likely to help. -- Hi, I put in a new kernel and get the response from uname -r of 3.14.0-031400-generic, apologies for the pedantry I am not that sure what I am doing. The device behaves exactly the same as default Linux kernel, buffer is erratic not stable like USB 2.0 and audio droputs every couple of seconds. The HDMI audio output does not work after installing the new kernel. I captured some data with usbmon but its a big file 4MB so I can email it separately if you are interested but a sample is as below. sudo cat /sys/kernel/debug/usb/usbmon/2u /tmp/1.mon.out Thanks Russel 8800d0230400 2003746485 C Zi:2:003:1 0:1:1116:0 1 0:0:3 4 = 00030b00 8800d0230400 2003746493 S Zi:2:003:1 -115:1:1116 1 -18:0:3 4 8802115e9540 2003746499 C Ii:2:003:3 0:32 2 = 0002 8802115e9540 2003746514 S Ii:2:003:3 -115:32 2 880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 880036e14600 2003747556 S Zo:2:003:1 -115:1:1106 5 -18:0:264 -18:264:270 -18:534:264 -18:798:264 -18:1062:264 1326 = b40e4abb e343b295 4cb72848 bc8d42bd 7341c10b 3ec4943b c2883dc8 9737cc17 8800d0230100 2003747563 C Zi:2:003:1 0:1:1117:0 1 0:0:3 4 = 00030b00 8800d0230100 2003747564 S Zi:2:003:1 -115:1:1117 1 -18:0:3 4 8800d0237900 2003748552 C Zi:2:003:1 0:1:1118:0 1 0:0:3 4 = 00030b00 8800d0237900 2003748561 S Zi:2:003:1 -115:1:1118 1 -18:0:3 4 8800d0237600 2003749520 C Zi:2:003:1 0:1:1119:0 1 0:0:3 4 = 00030b00 8800d0237600 2003749526 S Zi:2:003:1 -115:1:1119 1 -18:0:3 4 8800d0230400 2003750493 C Zi:2:003:1 0:1:1120:0 1 0:0:3 4 = 00030b00 8800d0230400 2003750498 S Zi:2:003:1 -115:1:1120 1 -18:0:3 4 8800d0230100 2003751518 C Zi:2:003:1 0:1:1121:0 1 0:0:3 4 = 00030b00 8800d0230100 2003751523 S Zi:2:003:1 -115:1:1121 1 -18:0:3 4 8800d0237900 2003752501 C Zi:2:003:1 0:1:1122:0 1 0:0:3 4 = 00030b00 8800d0237900 2003752506 S Zi:2:003:1 -115:1:1122 1 -18:0:3 4 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 880036e15c00 2003753516 S Zo:2:003:1 -115:1: 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 1537ea16 c9e808b1 f60dd5f1 f7970801 e4fdef09 10fab104 f4e00afb c103fbf6 8800d0237600 2003753520 C Zi:2:003:1 0:1:1123:0 1 0:0:3 4 = 00030b00 8800d0237600 2003753521 S Zi:2:003:1 -115:1:1123 1 -18:0:3 4 8800d0230400 2003754492 C Zi:2:003:1 0:1:1124:0 1 0:0:3 4 = 00030b00 8800d0230400 2003754494 S Zi:2:003:1 -115:1:1124 1 -18:0:3 4 8800d0230100 200371 C Zi:2:003:1 0:1:1125:0 1 0:0:3 4 = 00030b00 8800d0230100 2003755560 S Zi:2:003:1 -115:1:1125 1 -18:0:3 4 8800d0237900 2003756552 C Zi:2:003:1 0:1:1126:0 1 0:0:3 4 = 00030b00 8800d0237900 2003756561 S Zi:2:003:1 -115:1:1126 1 -18:0:3 4 8800d0237600 2003757557 C Zi:2:003:1 0:1:1127:0 1 0:0:3 4 = 00030b00 8800d0237600 2003757565 S Zi:2:003:1 -115:1:1127 1 -18:0:3 4 880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 880036e14000 2003758507 S Zo:2:003:1 -115:1:1116 6 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 = 1761e712 8ded1cce e21323ec 1264ec08 caf607e0 f7ff1500 0823f703 28fc1409 8800d0230400 2003758511 C Zi:2:003:1 0:1:1128:0 1 0:0:3 4 = 00030b00 8800d0230400 2003758512 S Zi:2:003:1 -115:1:1128 1 -18:0:3 4 8800d0230100 2003759550 C Zi:2:003:1 0:1:1129:0 1 0:0:3 4 = 00030b00 8800d0230100 2003759559 S Zi:2:003:1 -115:1:1129 1 -18:0:3 4 8800d0237900 2003760554 C Zi:2:003:1 0:1:1130:0 1 0:0:3 4 = 00030b00 8800d0237900 2003760563 S Zi:2:003:1 -115:1:1130 1 -18:0:3 4 8800d0237600 2003761552 C Zi:2:003:1 0:1:1131:0 1 0:0:3 4 = 00030b00 8800d0237600 2003761561 S Zi:2:003:1 -115:1:1131 1 -18:0:3 4 8800d0230400 2003762512 C Zi:2:003:1 0:1:1132:0 1 0:0:3 4 = 00030b00 8800d0230400 2003762515 S Zi:2:003:1 -115:1:1132 1 -18:0:3 4 880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264 0:264:270 0:534:264 0:798:264 0:1062:264 1326 880036e14600 2003763519 S Zo:2:003:1 -115:1:1121 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 26acd81f 9fe02ac2 d423c1db 2f70d027 1fd82b7f d424d5da 28b0d623 35dc2e61 8800d0230100 2003763524 C Zi:2:003:1 0:1:1133:0 1 0:0:3 4 = 00030b00 8800d0230100 2003763526 S Zi:2:003:1 -115:1:1133 1 -18:0:3 4 8800d0237900 2003764553 C Zi:2:003:1 0:1:1134:0 1 0:0:3 4 = 00030b00 8800d0237900 2003764562 S
Re: [PATCH] cdc-acm: some enhancement on acm delayed write
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote:
On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote:
We find two problems on acm tty write delayed mechanism.
Then you should split this into two patches.
(1) When acm resume, the delayed wb will be started. But now
only one write can be saved during acm suspend. More acm write
may be abandoned.
Why not simply return 0 in write and use the tty buffering rather than
implement another buffer in cdc_acm?
Yes. We need a single buffer because the tty layer is not happy
when you accept no data. But we should be able to refuse subsequent
writes. Could you test this patch?
Regards
Oliver
From 1d44c1f2a10b5617824a37c8ec51f5547e482259 Mon Sep 17 00:00:00 2001
From: Oliver Neukum oneu...@suse.de
Date: Tue, 8 Apr 2014 12:17:39 +0200
Subject: [PATCH] cdc-acm: fix consecutive writes while device is suspended
CDC-ACM needs to handle one attempt to write to a suspended
device because we told the tty layer that there is room.
A second attempt may and must fail or we drop data.
Signed-off-by: Oliver Neukum oneu...@suse.de
CC: sta...@vger.kernel.org
---
drivers/usb/class/cdc-acm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 900f7ff..7ad3105 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class/cdc-acm.c
@@ -646,10 +646,12 @@ static int acm_tty_write(struct tty_struct *tty,
usb_autopm_get_interface_async(acm-control);
if (acm-susp_count) {
- if (!acm-delayed_wb)
+ if (!acm-delayed_wb) {
acm-delayed_wb = wb;
- else
+ } else {
usb_autopm_put_interface_async(acm-control);
+ count = 0;
+ }
spin_unlock_irqrestore(acm-write_lock, flags);
return count; /* A white lie */
}
--
1.8.4.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
Re: [PATCH] cdc-acm: some enhancement on acm delayed write
On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote: On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote: (2) acm tty port ASYNCB_INITIALIZED flag will be cleared when close. If acm resume callback run after ASYNCB_INITIALIZED flag cleared, there will have no chance for delayed write to start. That lead to acm_wb.use can't be cleared. If user space open acm tty again and try to setd, tty will be blocked in tty_wait_until_sent for ever. This patch have two modification. (1) use list_head to save the write acm_wb during acm suspend. It can ensure no acm write abandoned. (2) enable flush buffer callback when acm tty close. acm delayed wb will start before acm port shutdown callback, it make sure the delayed acm_wb.use to be cleared. The patch also clear acm_wb.use and acm.transmitting when port shutdown. This is not the right way to do this. See below. If I see this correctly, then ASYNCB_INITIALIZED is cleared in tty_port_close() we is called from acm_tty_close(). Thus it should be enough to make sure that the device is resumed at the beginning of acm_tty_close() and acm_resume() will do the job automatically. What do you think? 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] cdc-acm: some enhancement on acm delayed write
(2) acm tty port ASYNCB_INITIALIZED flag will be cleared when close. If acm resume callback run after ASYNCB_INITIALIZED flag cleared, there will have no chance for delayed write to start. That lead to acm_wb.use can't be cleared. If user space open acm tty again and try to setd, tty will be blocked in tty_wait_until_sent for ever. If there is data pending when the close occurs the close path should block until either the close timeout occurs or the buffer is written. This sounds more like the implementation of the ACM chars_in_buffer method is wrong and not counting the deferred bytes as unsent ? Alan -- 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
move ZTE CDMA device pid from zte_ev.c back to option.c
dear linuxfoundation:
I'm not sure if you receive our mails in lase week , i resend it now.
Please confirm whether it is correct format for submit.
Looking forward to your reply.
modify reason:
1. Move device pid fffe from zte_ev.c back to option.c for our company.
2. Modify the parameter from 0x0003 to 0x. the problem may cause the device
can not be close.
these two points are in the patch, please submit it for me. thanks.
Signed-off-by:lei liuliu.le...@zte.com.cn
diff -u -r drivers-old/usb/serial/option.c drivers/usb/serial/option.c
--- drivers-old/usb/serial/option.c 2014-03-24 12:45:42.0 +0800
+++ drivers/usb/serial/option.c 2014-03-26 15:13:02.232956251 +0800
@@ -1462,6 +1462,7 @@
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff92, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff93, 0xff, 0xff,
0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff94, 0xff, 0xff,
0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffe, 0xff, 0xff,
0xff) },
/* NOTE: most ZTE CDMA devices should be driven by zte_ev, not option */
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718,
0xff, 0xff, 0xff),
diff -u -r drivers-old/usb/serial/zte_ev.c drivers/usb/serial/zte_ev.c
--- drivers-old/usb/serial/zte_ev.c 2014-03-24 12:45:42.0 +0800
+++ drivers/usb/serial/zte_ev.c 2014-03-26 16:08:52.916827643 +0800
@@ -258,12 +258,12 @@
/* send 8 cmd */
/*
-* 16.0 CTL 21 22 03 00 00 00 00 00
+* 16.0 CTL 21 22 00 00 00 00 00 00
*/
len = 0;
result = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
0x22, 0x21,
-0x0003, 0x, NULL, len,
+0x, 0x, NULL, len,
USB_CTRL_GET_TIMEOUT);
dev_dbg(dev, result = %d\n, result);
@@ -276,7 +276,6 @@
/* AC8710, AC8710T */
{ USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0x, 0xff, 0xff, 0xff) },
/* AC8700 */
- { USB_DEVICE_AND_INTERFACE_INFO(0x19d2, 0xfffe, 0xff, 0xff, 0xff) },
/* MG880 */
{ USB_DEVICE(0x19d2, 0xfffd) },
{ USB_DEVICE(0x19d2, 0xfffc) },
thanks.
lei
liuN�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Re: about possible port reset when disconnect
hi Alan:
2014-04-07 10:06 GMT+08:00 Alan Stern st...@rowland.harvard.edu:
On Sun, 6 Apr 2014, vichy wrote:
hi alan:
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.
after checking my hardware I found if device is no connected and do
the port reset,
the reset bit always will be 1 (I purposely add port status check in
set port reset case like below)
Platform-ehci Platform-ehci.0: port 1 reset
Platform-ehci Platform-ehci.0: in port reset sequence, GetStatus
port:1 status 000100 0 ACK sig=se0 RESET
Yep. That's a hardware bug.
from ehci spec, there did not mention what will HW to do if port reset
happens on no connection.
it only explain what controller needs to do when device is connected.
Nonsense. The EHCI spec says this (in Table 2-16, the description
for bit 8):
... Software writes a zero to this bit to terminate
the bus reset sequence...
... Note that when software writes a zero to this bit there
may be a delay before the bit status changes to a zero. The bit
status will not read as a zero until after the reset has
completed... A host controller must terminate the reset and
stabilize the state of the port within 2 milliseconds of
software transitioning this bit from a one to a zero.
Thus, the bit is supposed to change to 0 after no more than 2 ms,
whether a device is connected or not.
I got it.
At first glance of this part of spec, I only focus this behaviour when
device is connected.
^^
if related reset bit will automatically cleared for a while when
device is not connected.
Why we still need to clear them in hub_port_finish_reset like below flow
in hub_port_reset,
/* Check for disconnect or reset */
if (status == 0 || status == -ENOTCONN || status == -ENODEV) {
hub_port_finish_reset(hub, port1, udev, status);
then in hub_port_finish_reset
case -ENOTCONN:
case -ENODEV:
clear_port_feature(hub-hdev,
port1, USB_PORT_FEAT_C_RESET);
That's a different bit. USB_PORT_FEAT_C_RESET isn't the same as
USB_PORT_FEAT_RESET.
what I am curious is,
if port reset bit will clear to 0 within 2ms, why we still need to
clear_port_feature with USB_PORT_FEAT_C_RESET
(clear Port reset )
if (hub_is_superspeed(hub-hdev)) {
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
}
Sincerely 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: [PATCH] cdc-acm: some enhancement on acm delayed write
[ +CC: Oliver ] On Tue, Apr 08, 2014 at 12:22:29PM +0100, One Thousand Gnomes wrote: (2) acm tty port ASYNCB_INITIALIZED flag will be cleared when close. If acm resume callback run after ASYNCB_INITIALIZED flag cleared, there will have no chance for delayed write to start. That lead to acm_wb.use can't be cleared. If user space open acm tty again and try to setd, tty will be blocked in tty_wait_until_sent for ever. If there is data pending when the close occurs the close path should block until either the close timeout occurs or the buffer is written. This sounds more like the implementation of the ACM chars_in_buffer method is wrong and not counting the deferred bytes as unsent ? The ACM chars_in_buffer does count the deferred bytes so I guess this can only happen if close happens fast enough that resume is never called before shutdown (e.g. closing_wait = ASYNC_CLOSING_WAIT_NONE and drain_delay = 0). 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: [PATCH] cdc-acm: some enhancement on acm delayed write
[ +CC: Alan ] On Tue, Apr 08, 2014 at 12:33:31PM +0200, Oliver Neukum wrote: On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote: On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote: (2) acm tty port ASYNCB_INITIALIZED flag will be cleared when close. If acm resume callback run after ASYNCB_INITIALIZED flag cleared, there will have no chance for delayed write to start. That lead to acm_wb.use can't be cleared. If user space open acm tty again and try to setd, tty will be blocked in tty_wait_until_sent for ever. This patch have two modification. (1) use list_head to save the write acm_wb during acm suspend. It can ensure no acm write abandoned. (2) enable flush buffer callback when acm tty close. acm delayed wb will start before acm port shutdown callback, it make sure the delayed acm_wb.use to be cleared. The patch also clear acm_wb.use and acm.transmitting when port shutdown. This is not the right way to do this. See below. If I see this correctly, then ASYNCB_INITIALIZED is cleared in tty_port_close() we is called from acm_tty_close(). Thus it should be enough to make sure that the device is resumed at the beginning of acm_tty_close() and acm_resume() will do the job automatically. What do you think? But the device should already be about to be resumed, right? If the port is closed fast enough that resume hasn't had time to run before shutdown is called I think the right thing to do is simply to discard the delayed bytes (in shutdown). 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: [PATCH] cdc-acm: some enhancement on acm delayed write
On Tue, 2014-04-08 at 15:17 +0200, Johan Hovold wrote: [ +CC: Alan ] On Tue, Apr 08, 2014 at 12:33:31PM +0200, Oliver Neukum wrote: On Tue, 2014-04-08 at 09:33 +0200, Johan Hovold wrote: On Tue, Apr 08, 2014 at 11:05:20AM +0800, Xiao Jin wrote: (2) acm tty port ASYNCB_INITIALIZED flag will be cleared when close. If acm resume callback run after ASYNCB_INITIALIZED flag cleared, there will have no chance for delayed write to start. That lead to acm_wb.use can't be cleared. If user space open acm tty again and try to setd, tty will be blocked in tty_wait_until_sent for ever. This patch have two modification. (1) use list_head to save the write acm_wb during acm suspend. It can ensure no acm write abandoned. (2) enable flush buffer callback when acm tty close. acm delayed wb will start before acm port shutdown callback, it make sure the delayed acm_wb.use to be cleared. The patch also clear acm_wb.use and acm.transmitting when port shutdown. This is not the right way to do this. See below. If I see this correctly, then ASYNCB_INITIALIZED is cleared in tty_port_close() we is called from acm_tty_close(). Thus it should be enough to make sure that the device is resumed at the beginning of acm_tty_close() and acm_resume() will do the job automatically. What do you think? But the device should already be about to be resumed, right? If the port Yes. is closed fast enough that resume hasn't had time to run before shutdown is called I think the right thing to do is simply to discard the delayed bytes (in shutdown). I think if we said we have transmitted then we should do so. 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/OMAP: gadget does not start when cable is plugged after the driver is started
Hi,
On Tue, Apr 08, 2014 at 09:24:09AM +0200, Stefan Roese wrote:
On 07.04.2014 18:04, Felipe Balbi wrote:
snip
that's not caused by my patch, it's a previously existing bug. This
should sort it out:
commit e7f69404a878b5345ad07bf06d78559ecd31db79
Author: Felipe Balbi ba...@ti.com
Date: Mon Apr 7 10:58:01 2014 -0500
usb: musb: omap2430: make sure clocks are enabled when running mailbox
on early initialization we could fall into
a situation where the mailbox is called before
MUSB's clocks are running, in order to avoid
that, make sure mailbox is always wrapped with
pm_runtime calls.
Reported-by: Stefan Roese s...@denx.de
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 819a7cd..d369bf1 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -316,7 +316,13 @@ static void omap_musb_mailbox_work(struct work_struct
*mailbox_work)
{
struct omap2430_glue *glue = container_of(mailbox_work,
struct omap2430_glue, omap_musb_mailbox_work);
+ struct musb *musb = glue_to_musb(glue);
+ struct device *dev = musb-controller;
+
+ pm_runtime_get_sync(dev);
omap_musb_set_mailbox(glue);
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_autosuspend(dev);
}
static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
let me know
The crash doesn't appear anymore with this patch. But the ethernet
gadget is not started. This happens also with a plugged cable upon
driver startup. Now I see an error in the log:
[2.793121] musb-hdrc musb-hdrc.0.auto: VBUS_ERROR in b_idle (80,
SessEnd), retry #0, port1 0100
that shouldn't happen... Can you add some extra debugging prints and try
to figure out what's going on ?
--
balbi
signature.asc
Description: Digital signature
[PATCH V4 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Removing this older USB 3.0 DRD controller PHY driver, since
a new driver based on generic phy framework is now available.
Also removing the dt node for older driver from Exynos5250
device tree and updating the dt node for DWC3 controller.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
NOTE: This patch should be merged only when the new USB 3.0
DRD phy controller driver is available in the tree from the
patches:
phy: Add new Exynos5 USB 3.0 PHY driver; and
dt: exynos5250: Enable support for generic USB DRD phy
arch/arm/boot/dts/exynos5250.dtsi | 17 +-
drivers/usb/phy/phy-samsung-usb.h | 83 -
drivers/usb/phy/phy-samsung-usb3.c | 350
3 files changed, 2 insertions(+), 448 deletions(-)
delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 92c6fcd..1cb1e91 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -512,21 +512,8 @@
compatible = synopsys,dwc3;
reg = 0x1200 0x1;
interrupts = 0 72 0;
- usb-phy = usb2_phy usb3_phy;
- };
- };
-
- usb3_phy: usbphy@1210 {
- compatible = samsung,exynos5250-usb3phy;
- reg = 0x1210 0x100;
- clocks = clock 1, clock 286;
- clock-names = ext_xtal, usbdrd30;
- #address-cells = 1;
- #size-cells = 1;
- ranges;
-
- usbphy-sys {
- reg = 0x10040704 0x8;
+ phys = usbdrd_phy 0, usbdrd_phy 1;
+ phy-names = usb2-phy, usb3-phy;
};
};
diff --git a/drivers/usb/phy/phy-samsung-usb.h
b/drivers/usb/phy/phy-samsung-usb.h
index 68771bf..ced8b65 100644
--- a/drivers/usb/phy/phy-samsung-usb.h
+++ b/drivers/usb/phy/phy-samsung-usb.h
@@ -155,86 +155,6 @@
#define EXYNOS5_PHY_OTG_TUNE (0x40)
-/* EXYNOS5: USB 3.0 DRD */
-#define EXYNOS5_DRD_LINKSYSTEM (0x04)
-
-#define LINKSYSTEM_FLADJ_MASK (0x3f 1)
-#define LINKSYSTEM_FLADJ(_x) ((_x) 1)
-#define LINKSYSTEM_XHCI_VERSION_CONTROL(0x1 27)
-
-#define EXYNOS5_DRD_PHYUTMI(0x08)
-
-#define PHYUTMI_OTGDISABLE (0x1 6)
-#define PHYUTMI_FORCESUSPEND (0x1 1)
-#define PHYUTMI_FORCESLEEP (0x1 0)
-
-#define EXYNOS5_DRD_PHYPIPE(0x0c)
-
-#define EXYNOS5_DRD_PHYCLKRST (0x10)
-
-#define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff 23)
-#define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) 23)
-
-#define PHYCLKRST_SSC_RANGE_MASK (0x03 21)
-#define PHYCLKRST_SSC_RANGE(_x)((_x) 21)
-
-#define PHYCLKRST_SSC_EN (0x1 20)
-#define PHYCLKRST_REF_SSP_EN (0x1 19)
-#define PHYCLKRST_REF_CLKDIV2 (0x1 18)
-
-#define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x02 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d 11)
-#define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 11)
-
-#define PHYCLKRST_FSEL_MASK(0x3f 5)
-#define PHYCLKRST_FSEL(_x) ((_x) 5)
-#define PHYCLKRST_FSEL_PAD_100MHZ (0x27 5)
-#define PHYCLKRST_FSEL_PAD_24MHZ (0x2a 5)
-#define PHYCLKRST_FSEL_PAD_20MHZ (0x31 5)
-#define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 5)
-
-#define PHYCLKRST_RETENABLEN (0x1 4)
-
-#define PHYCLKRST_REFCLKSEL_MASK (0x03 2)
-#define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 2)
-#define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 2)
-
-#define PHYCLKRST_PORTRESET(0x1 1)
-#define PHYCLKRST_COMMONONN(0x1 0)
-
-#define EXYNOS5_DRD_PHYREG0(0x14)
-#define EXYNOS5_DRD_PHYREG1(0x18)
-
-#define EXYNOS5_DRD_PHYPARAM0 (0x1c)
-
-#define PHYPARAM0_REF_USE_PAD (0x1 31)
-#define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f 26)
-#define PHYPARAM0_REF_LOSLEVEL (0x9 26)
-
-#define EXYNOS5_DRD_PHYPARAM1 (0x20)
-
-#define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f 0)
-#define PHYPARAM1_PCS_TXDEEMPH (0x1c)
-
-#define EXYNOS5_DRD_PHYTERM(0x24)
-
-#define EXYNOS5_DRD_PHYTEST(0x28)
-
-#define PHYTEST_POWERDOWN_SSP (0x1 3)
-#define PHYTEST_POWERDOWN_HSP (0x1 2)
-
-#define EXYNOS5_DRD_PHYADP (0x2c)
-
[PATCH V4 4/5] dt: exynos5250: Enable support for generic USB DRD phy
Add device tree node for new usbdrd-phy driver, which
is based on generic phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index b7dec41..92c6fcd 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -530,6 +530,16 @@
};
};
+ usbdrd_phy: phy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, ref;
+ samsung,syscon-phandle = pmu_system_controller;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
+
usb@1211 {
compatible = samsung,exynos4210-ehci;
reg = 0x1211 0x100;
--
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 RESEND] 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
[PATCH V4 3/5] dt: exynos5420: Enable support for DWC3 controller
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index a6efb52..20c2d0b 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -653,6 +653,23 @@
clock-names = tmu_apbif, tmu_triminfo_apbif;
};
+ usb@1200 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock 366;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1200 0x1;
+ interrupts = 0 72 0;
+ phys = usbdrd_phy0 0, usbdrd_phy0 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
usbdrd_phy0: phy@1210 {
compatible = samsung,exynos5420-usbdrd-phy;
reg = 0x1210 0x100;
@@ -663,6 +680,23 @@
#phy-cells = 1;
};
+ usb@1240 {
+ compatible = samsung,exynos5250-dwusb3;
+ clocks = clock 367;
+ clock-names = usbdrd30;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dwc3 {
+ compatible = synopsys,dwc3;
+ reg = 0x1240 0x1;
+ interrupts = 0 73 0;
+ phys = usbdrd_phy1 0, usbdrd_phy1 1;
+ phy-names = usb2-phy, usb3-phy;
+ };
+ };
+
usbdrd_phy1: phy@1250 {
compatible = samsung,exynos5420-usbdrd-phy;
reg = 0x1250 0x100;
--
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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 42 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 668
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {
Refer to DT bindings documentation of particular PHY consumer devices for more
information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), associated by
+ phy name, used to determine bit values for clock settings
+ register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY operation
+ depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, usb3phy_refclk;
+ samsung,syscon-phandle = pmu_syscon;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8d3c49c..d955a05 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
help
This option enables support for APM X-Gene SoC multi-purpose PHY.
+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5 OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..31baa0c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ff54a7c
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -0,0 +1,668 @@
+/*
+ * Samsung EXYNOS5 SoC series USB DRD PHY driver
+ *
+ * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Vivek Gautam gautam.vi...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/io.h
Re: Fwd: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support
On Mon, Apr 7, 2014 at 10:05 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Apr 07, 2014 at 02:36:13PM +0530, sundeep subbaraya wrote:
+/**
+ * xudc_wrstatus - Sets up the usb device status stages.
+ * @udc: pointer to the usb device controller structure.
+ */
+static void xudc_wrstatus(struct xusb_udc *udc)
+{
+ u32 epcfgreg;
+
+ epcfgreg = udc-read_fn(udc-base_address +
+ udc-ep[XUSB_EP_NUMBER_ZERO].offset)|
+ XUSB_EP_CFG_DATA_TOGGLE_MASK;
are you really trying to mask here ? If you're trying to mask you should
be using a bitwise and.
This is used for making DATA1 packet for status stage during control
transfers.
IP has internally a weak check for alternating between DATA0 and DATA1
packets using
this bit. Firmware can set this bit to send a DATA1 packet. As we
always need to send DATA1
for status stage, we force IP to send DATA1 packet whatever maybe in this
bit because of alternating behavior. Is this is confusing for the name
*_TOGGLE_MASK ?
yeah, I guess it was the suffix _MASK, nevermind then ;-)
OK :)
+static int xudc_get_frame(struct usb_gadget *gadget)
+{
+
+ struct xusb_udc *udc = to_udc(gadget);
+ unsigned long flags;
+ int retval;
+
+ if (!gadget)
+ return -ENODEV;
oh boy... so you first deref gadget, then you check for it ?
Yes i too had this doubt after looking at some of the functions (like
ep_queue) of other controller drivers.
if there are other gadget drivers doing this, they're wrong and need to
be fixed.
I tested sending a NULL to container_of macro I see no NULL exception.
yeah, container_of() will *always* return a valid pointer, even if it's
argument is NULL.
Hence using container_of
macro first and then checking for NULL input is fine. If you insist
no, it's not. You'd waste cpu cycles with pointer arithmetic for no
reason.
this i need to change code at other
places too.
yes.
ok will modify
+static int xudc_wakeup(struct usb_gadget *gadget)
+{
+ struct xusb_udc *udc = to_udc(gadget);
+ u32 crtlreg;
+ int status = -EINVAL;
+ unsigned long flags;
+
+ spin_lock_irqsave(udc-lock, flags);
+
+ /* Remote wake up not enabled by host */
+ if (!udc-remote_wkp)
+ goto done;
+
+ crtlreg = udc-read_fn(udc-base_address + XUSB_CONTROL_OFFSET);
+ /* set remote wake up bit */
+ udc-write_fn(udc-base_address, XUSB_CONTROL_OFFSET, crtlreg |
+ XUSB_CONTROL_USB_RMTWAKE_MASK);
+ /* wait for a while and reset remote wake up bit */
+ mdelay(2);
why 2 ms ? why not 5 ? why not 1 ? shouldn't you be polling a bit in a
register or something ?
IP datasheet says writing Remote wake bit to this register will send
remote wake up
signalling to host immediately and this bit will not be cleared by
hardware, firmware has
to clear it. There is no bit for polling.
then you need a better comment stating this detail.
sure
+static const struct usb_gadget_ops xusb_udc_ops = {
+ .get_frame = xudc_get_frame,
+ .wakeup = xudc_wakeup,
+ .udc_start = xudc_start,
+ .udc_stop = xudc_stop,
no pullup ??? What gives ? This HW doesn't support it ? really ?
Yes, there is no pull up. writing to control register to start udc is
sufficient for this IP.
right, but is there a bit inside control register which actually starts
the IP ? You might want to move that to -pullup(), see how we did on
drivers/usb/dwc3/gadget.c::dwc3_gadget_pullup(); we're basically using
that to control RUN/STOP bit in DCTL register. That bit has two
functions: a) actually enable the ip; b) connect data pullups.
You can actually see with a scope that the line goes high and low when
you mess with that bit.
The reason I suggest this is because you don't want to let your host see
a connection until your gadget driver is registered and ready to go and
that's what the pullup method would guarantee.
No.There are only two bits in Control register, one for Ready bit, another for
sending remote wakeup and remaining are reserved as zeroes. Until ready is
set host do not see the gadget.
+ }
+ if (intrstatus XUSB_STATUS_SUSPEND_MASK) {
+
+ DBG(Suspend\n);
+
+ /* Enable the reset and resume */
+ intrreg = udc-read_fn(udc-base_address + XUSB_IER_OFFSET);
+ intrreg |= XUSB_STATUS_RESET_MASK | XUSB_STATUS_RESUME_MASK;
+ udc-write_fn(udc-base_address, XUSB_IER_OFFSET, intrreg);
+ udc-usb_state = USB_STATE_SUSPENDED;
+
+ if (udc-driver-suspend)
+ udc-driver-suspend(udc-gadget);
+ }
when are you going to call driver-resume() ??
When an interrupt occurs we first check if udc-usb_state =
USB_STATE_SUSPENDED,
if yes driver-resume is called. Also
Re: XHCI Clear halt issue
Hi On 04/07/2014 09:12 PM, Eric Gross wrote: Hi all, I am implementing a driver (currently libusb-based, but may change to kernel-based eventually) for a USB standard class type that makes use of endpoint stalling as a synchronization mechanism to recover after error conditions between device and host (the reasons for needing it are a bit complex). The driver code I have been using works beautifully on Windows, some embedded OSes with proprietary USB stacks, and Linux via the EHCI driver. However, I ran into problems as soon as we started using this driver on XHCI systems (based off the 3.10 kernel). The sequence the driver typically does when encountering an error (or thinking it needs to resync) is: - Abort any pending URBs (may be several queued to the EP) - Set Feature(HALT) - Clear EP Stall - Continue What we saw with a bus analyzer was that, independent of host controller used (tested Intel and Renesas), the sequence number of the next outgoing packet (or toggle bit when in High Speed mode) was incorrect after clearing the stall. The device resets its expected sequence/toggle after un-stalling the EP and hence it ignores the next packet with the incorrect one. Interestingly, some devices are actually tolerant of this behavior and accept the incorrect sequence id, but any devices based on the Cypress FX3 (a large number of devices implementing this class type) fail. When researching this issue I saw a number of previous posts hinting at known issues like this, but I have not seen a firm conclusion. It seems that some of the early responses by Sarah Sharp indicate that it is working this way by design (I admit I am not an expert in the XHCI spec). I see some newer posts referencing a clear halt bug, but I have been unable to find what this definitively is referencing. Based on my experience with how every other stack appears to work (including the Linux EHCI driver) and how the device is supposed to behave when it gets the clear stall request, I can't help but think that the behavior as it currently is is wrong. The issue we currently have is that the xHCI (both driver and hw) refuses to reset an endpoint if it's not halted. SetFeature(ENDPOINT_HALT) will set the device to halted state, but it requires some additional transfer that returns STALL until xHCI will see the endpoint as halted. So in this case the situation is: Abort pending urbs SetFeature(ENDPOINT_HALT) - ep halted on device side, xHCI doesn't consider ep halted. usb_clear_halt() - ClearFeature(ENDPOINT_HALT) - device resets its ep toggle/sequence - call hcd-driver-endpoint_reset(), but the xhci .endpoint_reset() callback can't reset an endpoint it doesn't consider halted. xhci host side toggle/sequence are not reset - mismatch. I can provide any additional information (bus traces, testing results, etc) as needed. If this is a known issue that someone can point me to the bugzilla entry for (I have been unsuccessful finding one) or some previous discussion threads I may have not found, it would be appreciated as well. With dynamic debugging enabled for xhci you should probably see: Endpoint x not halted, refusing to reset. Discussion threads touching this topic: http://marc.info/?l=linux-usbm=134922286125585w=2 http://marc.info/?l=linux-usbm=134852269014614w=2 http://marc.info/?l=linux-usbm=139025060301432w=2 I'm focusing on this issue right now, and I appreciate if you are able to run some test with your setup once I get something ready. The main thing that needs to be done is what xHCI specs states in an additional Note added to section 4.6.8 : If software wishes reset the Data Toggle or Sequence Number of an endpoint that isn't in the Halted state, then software may issue a Configure Endpoint Command with the Drop and Add bits set for the target endpoint. But some other tweaking to how xhci driver handles STALL and clears halted endpoints is also needed. -Mathias -- 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: move ZTE CDMA device pid from zte_ev.c back to option.c
On Tue, Apr 08, 2014 at 07:59:28PM +0800, 刘磊 wrote: dear linuxfoundation: I'm not sure if you receive our mails in lase week , i resend it now. Please confirm whether it is correct format for submit. Looking forward to your reply. modify reason: 1. Move device pid fffe from zte_ev.c back to option.c for our company. 2. Modify the parameter from 0x0003 to 0x. the problem may cause the device can not be close. these two points are in the patch, please submit it for me. thanks. Signed-off-by:lei liuliu.le...@zte.com.cn Hi, This is the friendly semi-automated patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. Right now, the development tree you have sent a patch for is closed due to the timing of the merge window. Don't worry, the patch(es) you have sent are not lost, and will be looked at after the merge window is over (after the -rc1 kernel is released by Linus). So thank you for your patience and your patches will be reviewed at this later time, you do not have to do anything further, this is just a short note to let you know the patch status and so you don't worry they didn't make it through. thanks, greg k-h's patch email bot -- 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] xhci: Report max device limit when Enable Slot command fails.
On Tue, Apr 08, 2014 at 07:53:39AM +, Amund Hov wrote: I completely understand your frustration, and it actually is relevant to kernel development. :) Perhaps the attached patch would have at least saved you some time and frustration in debugging the driver and host issue? Thanks Sarah. An error like that would allow me to know what the error is and where to look for host capabilities. Is this the only case in which slot_id would not be properly set? I believe so. There's at least one other function that allocates a new slot ID, but it calls the function I added debugging to. A device may also not get enumerated if it fails to respond to a Set Address control transfer, but that code path already has some nicer printks already. Sarah Sharp p.s. You might want to try to remove your footer when communicating with open source mailing lists. Some kernel devs will refuse to answer you back because it really doesn't make any sense to try to impose the legalise on a public mailing list that sends email copies to everyone. I know some people just use their personal addresses if their company slaps the footer on all outgoing messages. 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 -- 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 Clear halt issue
Thanks for your help, Mathias! See my comments inline below: Mathias Nyman mathias.ny...@linux.intel.com wrote on 04/08/2014 10:26:43 AM: The issue we currently have is that the xHCI (both driver and hw) refuses to reset an endpoint if it's not halted. SetFeature(ENDPOINT_HALT) will set the device to halted state, but it requires some additional transfer that returns STALL until xHCI will see the endpoint as halted. So in this case the situation is: Abort pending urbs SetFeature(ENDPOINT_HALT) - ep halted on device side, xHCI doesn't consider ep halted. usb_clear_halt() - ClearFeature(ENDPOINT_HALT) - device resets its ep toggle/sequence - call hcd-driver-endpoint_reset(), but the xhci .endpoint_reset() callback can't reset an endpoint it doesn't consider halted. xhci host side toggle/sequence are not reset - mismatch. Ok. But there shouldn't be any way user code should be able to get the two out-of-sync, right? This is really a layer below what the user should be able to interact with. Maybe this is what you are saying? With dynamic debugging enabled for xhci you should probably see: Endpoint x not halted, refusing to reset. I'll try to get a kernel installed with this enabled. Right now it is a bit tricky to update kernels on our systems because their are a whole hierarchy of dependencies that need to rebuild with it. If there are specific things to test that I can lump together I can rebuild it all at once. Discussion threads touching this topic: http://marc.info/?l=linux-usbm=134922286125585w=2 http://marc.info/?l=linux-usbm=134852269014614w=2 http://marc.info/?l=linux-usbm=139025060301432w=2 Thanks for consolidating those messages. Those were the ones I had seen previously but wasn't sure what to conclude. I'm focusing on this issue right now, and I appreciate if you are able to run some test with your setup once I get something ready. Great! I can help as needed. The main thing that needs to be done is what xHCI specs states in an additional Note added to section 4.6.8 : If software wishes reset the Data Toggle or Sequence Number of an endpoint that isn't in the Halted state, then software may issue a Configure Endpoint Command with the Drop and Add bits set for the target endpoint. But some other tweaking to how xhci driver handles STALL and clears halted endpoints is also needed. Since the bus trace looks the same on Windows as on Linux (minues the incorrect sequence number and the failure), I assume this must be how it is done there? Eric Gross -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH v2 2/2] usb: gadget: Add xilinx axi usb2 device support
Hi,
On Tue, Apr 08, 2014 at 09:31:29PM +0530, sundeep subbaraya wrote:
+static const struct usb_gadget_ops xusb_udc_ops = {
+ .get_frame = xudc_get_frame,
+ .wakeup = xudc_wakeup,
+ .udc_start = xudc_start,
+ .udc_stop = xudc_stop,
no pullup ??? What gives ? This HW doesn't support it ? really ?
Yes, there is no pull up. writing to control register to start udc is
sufficient for this IP.
right, but is there a bit inside control register which actually starts
the IP ? You might want to move that to -pullup(), see how we did on
drivers/usb/dwc3/gadget.c::dwc3_gadget_pullup(); we're basically using
that to control RUN/STOP bit in DCTL register. That bit has two
functions: a) actually enable the ip; b) connect data pullups.
You can actually see with a scope that the line goes high and low when
you mess with that bit.
The reason I suggest this is because you don't want to let your host see
a connection until your gadget driver is registered and ready to go and
that's what the pullup method would guarantee.
No.There are only two bits in Control register, one for Ready bit, another for
sending remote wakeup and remaining are reserved as zeroes. Until ready is
set host do not see the gadget.
so this READY bit is what you want to toggle on pullup().
+ }
+ if (intrstatus XUSB_STATUS_SUSPEND_MASK) {
+
+ DBG(Suspend\n);
+
+ /* Enable the reset and resume */
+ intrreg = udc-read_fn(udc-base_address +
XUSB_IER_OFFSET);
+ intrreg |= XUSB_STATUS_RESET_MASK |
XUSB_STATUS_RESUME_MASK;
+ udc-write_fn(udc-base_address, XUSB_IER_OFFSET,
intrreg);
+ udc-usb_state = USB_STATE_SUSPENDED;
+
+ if (udc-driver-suspend)
+ udc-driver-suspend(udc-gadget);
+ }
when are you going to call driver-resume() ??
When an interrupt occurs we first check if udc-usb_state =
USB_STATE_SUSPENDED,
if yes driver-resume is called. Also if Resume bit is set then it is
cleared too. Resume status bit is set
when device is resumed by host after device sends Remote wakeup
signalling to host.
snip
+static irqreturn_t xudc_irq(int irq, void *_udc)
+{
+ struct xusb_udc *udc = _udc;
+ u32 intrstatus;
+ u32 intrreg;
+ u8 index;
+ u32 bufintr;
+
+ spin_lock((udc-lock));
+
+ intrreg = udc-read_fn(udc-base_address + XUSB_IER_OFFSET);
+ intrreg = ~XUSB_STATUS_INTR_EVENT_MASK;
+ udc-write_fn(udc-base_address, XUSB_IER_OFFSET, intrreg);
+
+ /* Read the Interrupt Status Register.*/
+ intrstatus = udc-read_fn(udc-base_address + XUSB_STATUS_OFFSET);
+
+ if (udc-usb_state == USB_STATE_SUSPENDED) {
+
+ DBG(Resume\n);
+
+ if (intrstatus XUSB_STATUS_RESUME_MASK) {
+ /* Enable the reset and suspend */
+ intrreg = udc-read_fn(udc-base_address +
+ XUSB_IER_OFFSET);
+ intrreg |= XUSB_STATUS_RESET_MASK |
+ XUSB_STATUS_SUSPEND_MASK;
+ udc-write_fn(udc-base_address, XUSB_IER_OFFSET,
+ intrreg);
+ }
+ udc-usb_state = 0;
+
+ if (udc-driver-resume)
+ udc-driver-resume(udc-gadget);
this is wrong, note that you would call -resume() *every time*
usb_state == SUSPENDED and there's an interrupt. This means that if
gadget is suspended and you remove the cable, then you first call
-resume() and then -disconnect().
Here. calling driver-resume.
Here's what I would do:
if (intrstatus XUSB_STATUS_RESUME_MASK) {
bool condition = udc-usb_state != USB_STATE_SUSPENDED;
dev_WARN_ONCE(dev, condition, Resume IRQ while not suspended\n);
/* Enable the reset and suspend */
intrreg = udc-read_fn(udc-base_address + XUSB_IER_OFFSET);
intrreg |= XUSB_STATUS_RESET_MASK | XUSB_STATUS_SUSPEND_MASK;
udc-write_fn(udc-base_address, XUSB_IER_OFFSET, intrreg);
if (udc-driver-resume)
udc-driver_resume(udc-gadget);
}
Resume Interrupt bit is set only when Resume happens by device sending
Remote wakeup.
so if the host drives resume signalling there will be no interrupt ?
Well, this is wrong :-) The gadget driver needs to know about that too.
The host side can decide to wake you up.
I am assuming we need to call driver-resume for every
driver-suspend. Hence I implemented
no you don't, you need to let host wake you up or you drive remote
wakeup on the bus. The thing is: if the bus is suspended, there will be
*no* activity on the bus prior to host driving Resume signal or device
driving Remote Wakeup signal.
Re: about possible port reset when disconnect
On Tue, 8 Apr 2014, vichy wrote:
That's a different bit. USB_PORT_FEAT_C_RESET isn't the same as
USB_PORT_FEAT_RESET.
what I am curious is,
if port reset bit will clear to 0 within 2ms, why we still need to
clear_port_feature with USB_PORT_FEAT_C_RESET
(clear Port reset )
if (hub_is_superspeed(hub-hdev)) {
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_BH_PORT_RESET);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_PORT_LINK_STATE);
clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_CONNECTION);
}
Because if we leave these bits set, the hub will send messages on its
interrupt endpoint telling us that these bits need to be cleared.
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: Fwd: Isochronos audio
On Tue, 8 Apr 2014, Russel Hughes wrote: Hi, I put in a new kernel and get the response from uname -r of 3.14.0-031400-generic, apologies for the pedantry I am not that sure what I am doing. The device behaves exactly the same as default Linux kernel, buffer is erratic not stable like USB 2.0 and audio droputs every couple of seconds. The HDMI audio output does not work after installing the new kernel. I captured some data with usbmon but its a big file 4MB so I can email it separately if you are interested but a sample is as below. Maybe it will help with the debugging if I point out that this usbmon trace definitely shows signs of something not working right. The URB completions for the isochronous-OUT endpoint are all delayed by 6 ms or so. Here's the first example: 880036e15c00 2003753507 C Zo:2:003:1 0:1::0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 880036e15c00 2003753516 S Zo:2:003:1 -115:1: 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 1537ea16 c9e808b1 f60dd5f1 f7970801 e4fdef09 10fab104 f4e00afb c103fbf6 8800d0237600 2003753520 C Zi:2:003:1 0:1:1123:0 1 0:0:3 4 = 00030b00 The IN transfer was 1 frame long and scheduled for frame 1123, so its completion indicates that the current frame number is = 1123. The OUT transfer was 6 frames long and scheduled for frame , so it should have completed in frame 1117. But the timestamps show that the two URBs completed at the same time (only 13 us between them). 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 v7 01/11] usb: chipidea: usb OTG fsm initialization.
On Sat, Apr 05, 2014 at 01:37:14PM +0800, Li Jun wrote:
This patch adds OTG fsm related initialization when do otg init,
add a seperate file for OTG fsm related utilities.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/Makefile |1 +
drivers/usb/chipidea/ci.h | 17 ++
drivers/usb/chipidea/otg.c |1 +
drivers/usb/chipidea/otg_fsm.c | 68
drivers/usb/chipidea/otg_fsm.h | 29 +
5 files changed, 116 insertions(+)
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 480bd4d..2f099c7 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -6,6 +6,7 @@ ci_hdrc-y := core.o otg.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC) += udc.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST) += host.o
ci_hdrc-$(CONFIG_USB_CHIPIDEA_DEBUG) += debug.o
+ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
# Glue/Bridge layers go here
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 7ae8cb6..bd3529f 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -17,6 +17,7 @@
#include linux/irqreturn.h
#include linux/usb.h
#include linux/usb/gadget.h
+#include linux/usb/otg-fsm.h
/**
* DEFINE
@@ -139,6 +140,7 @@ struct hw_bank {
* @roles: array of supported roles for this controller
* @role: current role
* @is_otg: if the device is otg-capable
+ * @fsm: otg finite state machine
* @work: work for role changing
* @wq: workqueue thread
* @qh_pool: allocation pool for queue heads
@@ -174,6 +176,7 @@ struct ci_hdrc {
struct ci_role_driver *roles[CI_ROLE_END];
enum ci_rolerole;
boolis_otg;
+ struct otg_fsm fsm;
struct work_struct work;
struct workqueue_struct *wq;
@@ -319,6 +322,20 @@ static inline u32 hw_test_and_write(struct ci_hdrc *ci,
enum ci_hw_regs reg,
return (val mask) __ffs(mask);
}
+/**
+ * ci_otg_is_fsm_mode: runtime check if otg controller
+ * is in otg fsm mode.
+ */
+static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
+{
+#ifdef CONFIG_USB_OTG_FSM
+ return ci-is_otg ci-roles[CI_ROLE_HOST]
+ ci-roles[CI_ROLE_GADGET];
+#else
+ return false;
+#endif
+}
+
u32 hw_read_intr_enable(struct ci_hdrc *ci);
u32 hw_read_intr_status(struct ci_hdrc *ci);
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index c694340..f978fa9 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -22,6 +22,7 @@
#include ci.h
#include bits.h
#include otg.h
+#include otg_fsm.h
/**
* hw_read_otgsc returns otgsc register bits value.
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
new file mode 100644
index 000..eddfe53
--- /dev/null
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -0,0 +1,68 @@
+/*
+ * otg_fsm.c - ChipIdea USB IP core OTG FSM driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ * Author: Jun Li
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * This file mainly handles OTG fsm, it includes OTG fsm operations
+ * for HNP and SRP.
+ */
+
+#include linux/usb/otg.h
+#include linux/usb/gadget.h
+#include linux/usb/hcd.h
+#include linux/usb/chipidea.h
+
+#include ci.h
+#include bits.h
+#include otg.h
+#include otg_fsm.h
+
+int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
+{
+ struct usb_otg *otg;
+
+ otg = devm_kzalloc(ci-dev,
+ sizeof(struct usb_otg), GFP_KERNEL);
+ if (!otg) {
+ dev_err(ci-dev,
+ Failed to allocate usb_otg structure for ci hdrc otg!\n);
+ return -ENOMEM;
+ }
+
+ otg-phy = ci-transceiver;
+ otg-gadget = ci-gadget;
+ if (ci-hcd)
+ otg-host = ci-hcd-self;
What's the purpose for this?
+ ci-fsm.otg = otg;
+ ci-transceiver-otg = ci-fsm.otg;
+ ci-fsm.power_up = 1;
+ ci-fsm.id = hw_read_otgsc(ci, OTGSC_ID) ? 1 : 0;
+ ci-transceiver-state = OTG_STATE_UNDEFINED;
+
+ mutex_init(ci-fsm.lock);
+
+ /* Enable A vbus valid irq */
+ hw_write_otgsc(ci, OTGSC_AVVIE, OTGSC_AVVIE);
+
+ if (ci-fsm.id) {
+ ci-fsm.b_ssend_srp =
+ hw_read_otgsc(ci, OTGSC_BSV) ? 0 : 1;
+ ci-fsm.b_sess_vld =
+ hw_read_otgsc(ci, OTGSC_BSV) ? 1 : 0;
+ }
+
+ if (ci-role == CI_ROLE_HOST)
+ ci-fsm.protocol = PROTO_HOST;
+ else if (ci-role ==
Re: [PATCH v7 03/11] usb: chipidea: host: init otg port number.
On Sat, Apr 05, 2014 at 01:37:16PM +0800, Li Jun wrote:
Init otg_port number of otg capable host to be 1 at host start.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/host.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index ffb4168..c9c645b 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -82,10 +82,17 @@ static int host_start(struct ci_hdrc *ci)
}
ret = usb_add_hcd(hcd, 0, 0);
- if (ret)
+ if (ret) {
goto disable_reg;
- else
+ } else {
+ struct usb_otg *otg = ci-transceiver-otg;
+
ci-hcd = hcd;
+ if (ci_otg_is_fsm_mode(ci))
+ hcd-self.otg_port = 1;
+ if (otg)
+ otg-host = hcd-self;
Why update this patch? The ci-transceiver-otg is only allocated
at otg_fsm_mode, isn't it?
+ }
if (ci-platdata-flags CI_HDRC_DISABLE_STREAMING)
hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS);
--
1.7.9.5
--
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: [PATCH v7 00/11] Add USB OTG HNP and SRP support on Chipidea usb driver
On Sat, Apr 05, 2014 at 01:37:13PM +0800, Li Jun wrote:
From: Li Jun b47...@freescale.com
This patchset adds USB OTG HNP and SRP support on chipidea usb driver,
existing OTG port role swtich function by ID pin status kept unchanged,
based on that, if select CONFIG_USB_OTG_FSM, OTG HNP and SRP will be
supported.
Reference to:
On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
July 27, 2012
Revision 2.0 version 1.1a
Changes since v6:
- Move ci_hdrc_otg_fsm_start() into ci_hdrc_otg_fsm_init()
Where is the above change?
Peter
- Call ci_hdrc_otg_fsm_init() in ci_hdrc_probe()
- Add fsm-protocol init in ci_hdrc_otg_fsm_init()
- Remove role check in start/stop host/gadget.
- Add ci_otg_is_fsm_mode() check when start fsm in ci_udc_start().
- Add struct usb_otg *otg in ci_hdrc_otg_fsm_init() for easy read when
do init, set otg-host if host role start before otg fsm init(power up
with ID is 0).
- set otg-host in host_start() if otg fsm init happens before host start
(power up with ID is 1) in host.c
- Add comments of ci_hdrc structure for added fileds(fsm and fsm_timer)
in ci.h
Changes since v5:
- Move ci_otg_is_fsm_mode() check into caller functions.
- Update comments alignment in otg_fsm.h
- Revert the ci_hdrc_otg_fsm_start() change to be v4
- Revert the role check removal of start host/gadget to be v4 since
ci_start_role may be called out of otg fsm.
- Set controller to be device mode after stop host, to be able to
generate data pulse correctly.
- Update some fsm variables to align with otg state.
- Update test documents for A device start new seesion in step 6):
need set a_bus_drop to be 0 and set a_bus_req to be 1.
- Typo fix.
Changes since v4:
- Fix compile warnings if USB_OTG_FSM is not enabled.
- Add ci_otg_is_fsm_mode() to replace ci-is_otg for checking if ci is in
OTG FSM mode.
- Move ci_hdrc_otg_fsm_start() at end of ci_hdrc_otg_fsm_init().
- Fix patch splict problem(a later patch changes a previous one).
- Remove unnecessary role check in start host/gadget.
- Add {} in start_host.c to fix Coding style problem and declar a variable
equal to ci-transceiver-otg firstly when init otg port number.
- Update some driver comments of chipidea drivers if this patchset applied.
Changes since v3:
- Move out 2 patches from this patchset, as which are not directly related to
otg fsm.
- Add a new file chipidea.txt under Documentation/usb/ to show how to test
OTG HNP and SRP.
- Directly embed struct otg_fsm into ci_hdrc instead of pointer of otg_fsm.
- Remove flag check in ci_otg_del_timer().
- Remove ADP related code and comments since ADP is not supported by chip.
- Start OTG fsm before request_irq.
- For B-device, do not do OTG fsm transitions when gadget driver
is not registered, and start OTG fsm in register gadget driver.
- Directly call ci_otg_fsm_work() in ci_hdrc_otg_fsm_start().
- Enable data pulse when a_wait_vfall timer time out.
- Update a_wait_vrise time out function.
- UPdate comments of OTG time macro definitions in otg_fsm.h according to
OTG and EH 2.0.
- Some typo and comments format changes.
Changes since v2:
- Add ABI document for sysfs input files description:
Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg
- Add a debug file for show some USB registers value.
- Split host driver change to be 2 patches, one for otg_port number init;
the other one for vbus control change.
- Export interrupt enable and status read functions from udc driver.
- Only enable AVV irq in otg fsm init.
- Remove duplicated USBSTS bits definitions.
- Add HowTo demo role switch with 2 Freescale i.MX6Q sabre SD boards
in cover letter.
- typo correction.
Changes since v1:
- Move out HNP polling patch from this series, which will be a seperated
patchset
followed this one
- Change fsm timers global variables to be a structure embeded in ci_hdrc,
to make multiple OTG instances can exist in one system
- Change some otg fsm functions to be static
- Re-split timer init patch to avoid a later patch changing a previous one
in the same series
- Change timer structure memory allocation to be devm_kzalloc
- Update some format alignment and spelling errors
Li Jun (11):
usb: chipidea: usb OTG fsm initialization.
usb: chipidea: host: vbus control change for OTG HNP.
usb: chipidea: host: init otg port number.
usb: chipidea: udc: driver update for OTG HNP.
usb: chipidea: add OTG fsm operation functions implemenation.
usb: chipidea: OTG fsm timers initialization.
usb: chipidea: OTG HNP and SRP fsm implementation.
usb: chipidea: add sys inputs for OTG fsm input.
usb: chipidea: debug: add debug file for OTG variables
Documentation: ABI: usb: sysfs Description for chipidea USB OTG HNP
and SRP
Documentation: usb: add chipidea.txt for how to demo usb OTG HNP and
SRP
.../ABI/testing/sysfs-platform-chipidea-usb-otg| 56 ++
Re: [PATCH RESEND] usb: ohci-exynos: Remove locks for 'ohci' in suspend callback
On Tuesday, April 08, 2014 11:41 PM, Vivek Gautam 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.
Right, this spin_lock/unlock is unnecessary, because it is
already used in ohci_suspend().
Acked-by: Jingoo Han jg1@samsung.com
Best regards,
Jingoo Han
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
[PATCH 2/2] usb: ehci-platform: Return immediately from suspend if ehci_suspend fails
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race' adds a check for possible race between suspend and wakeup interrupt, and thereby it returns -EBUSY as error code if there's a wakeup interrupt. So the platform host controller should not proceed further with its suspend callback, rather should return immediately to avoid powering down the essential things, like phy. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Hauke Mehrtens ha...@hauke-m.de Cc: Hans de Goede hdego...@redhat.com --- Based on 'usb-next' branch of Greg's usb tree. drivers/usb/host/ehci-platform.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index b3a0e11..60d3d1a 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -303,11 +303,13 @@ static int ehci_platform_suspend(struct device *dev) int ret; ret = ehci_suspend(hcd, do_wakeup); + if (ret) + return ret; if (pdata-power_suspend) pdata-power_suspend(pdev); - return ret; + return 0; } static int ehci_platform_resume(struct device *dev) -- 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 1/2] usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails
Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race' adds a check for possible race between suspend and wakeup interrupt, and thereby it returns -EBUSY as error code if there's a wakeup interrupt. So the platform host controller should not proceed further with its suspend callback, rather should return immediately to avoid powering down the essential things, like phy. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Jingoo Han jg1@samsung.com --- Based on 'usb-next' branch of Greg's usb tree. drivers/usb/host/ehci-exynos.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index d1d8c47..a4550eb 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -212,6 +212,8 @@ static int exynos_ehci_suspend(struct device *dev) int rc; rc = ehci_suspend(hcd, do_wakeup); + if (rc) + return rc; if (exynos_ehci-otg) exynos_ehci-otg-set_host(exynos_ehci-otg, hcd-self); @@ -221,7 +223,7 @@ static int exynos_ehci_suspend(struct device *dev) clk_disable_unprepare(exynos_ehci-clk); - return rc; + return 0; } static int exynos_ehci_resume(struct device *dev) -- 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 1/2] usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails
On Wednesday, April 09, 2014 1:01 PM, Vivek Gautam wrote: Patch 'b8efdaf USB: EHCI: add check for wakeup/suspend race' adds a check for possible race between suspend and wakeup interrupt, and thereby it returns -EBUSY as error code if there's a wakeup interrupt. So the platform host controller should not proceed further with its suspend callback, rather should return immediately to avoid powering down the essential things, like phy. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Alan Stern st...@rowland.harvard.edu Cc: Jingoo Han jg1@samsung.com Acked-by: Jingoo Han jg1@samsung.com Best regards, Jingoo Han --- Based on 'usb-next' branch of Greg's usb tree. drivers/usb/host/ehci-exynos.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c index d1d8c47..a4550eb 100644 --- a/drivers/usb/host/ehci-exynos.c +++ b/drivers/usb/host/ehci-exynos.c @@ -212,6 +212,8 @@ static int exynos_ehci_suspend(struct device *dev) int rc; rc = ehci_suspend(hcd, do_wakeup); + if (rc) + return rc; if (exynos_ehci-otg) exynos_ehci-otg-set_host(exynos_ehci-otg, hcd-self); @@ -221,7 +223,7 @@ static int exynos_ehci_suspend(struct device *dev) clk_disable_unprepare(exynos_ehci-clk); - return rc; + return 0; } static int exynos_ehci_resume(struct device *dev) -- 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
