RE: xhci-hcd (millions of) Too many fragments error on LUKS-encrypted device
From: Sascha Weaver Sent: 15 January 2014 06:49 To: linux-usb@vger.kernel.org Subject: xhci-hcd (millions of) Too many fragments error on LUKS-encrypted device Hi there, this bug was reported to Arch Linux community but they say I need to take this upstream: https://bugs.archlinux.org/task/38508 I've also found a (possible) similar bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733826 I am not very sure if here is the right place to report this. This is a known problem. A side effect of trying to fix USB ethernet. There is a patch lurking to increase the ring size from 64 to 256. David
RE: [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Arnaud Ebalard Sent: 14 January 2014 21:54 To: Sarah Sharp Cc: linux-usb@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Bjørn Mork Subject: Re: [BUG] FL1009: xHCI host not responding to stop endpoint command. Hi Sarah, Sarah Sharp sarah.a.sh...@linux.intel.com writes: I can add the following: 2) I just tested the copy of the small files using the ICY DOCK MB981U3S-1S connected to my ReadyNAS 102 *on a 3.11.7 kernel* and it completed successfully. Please try a 3.13-rc7 kernel after running `git revert 35773dac5f86`. I tried current 3.13.0-rc8 w/ 35773dac5f86 reverted and the result is the same: That patch only affects an error code and stops the fs code retrying for ever. Does everything work if you comment out the code in xhci-ring.c that adds NOP TRBs to the ring end in order to stop the LINK TRB appearing in the middle of a TB. The ethernet code needs it, but the disk transfers are (probably) aligned such that they don't. If that all works I'll look at writing a patch that either doesn't use NOPs or checks the alignment of all the fragments. David
RE: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.
From: tatxarata Update on my current research status. 1. To get normal read/write speed over USB3 I have to set max_sector_kb to 64. Otherwise write is fine, but read is very slow (about 300kb/s). Maybe this is hardware issue of this reader/card. However over USB2 all works fine without any tweaks. All that said below is for case of max_sector_kb = 64. I can't remember if you've said before... Is that USB2 on ehci or xhci? ie in a USB2 only port or a USB3 port with a USB2 cable. David -- 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 02/10] usb: chipidea: usb OTG fsm initlization.
Regards
Li Jun
Tel: 0512-6805 6912
-Original Message-
From: Peter Chen [mailto:peter.c...@freescale.com]
Sent: Thursday, January 09, 2014 3:11 PM
To: Li Jun-B47624
Cc: ba...@ti.com; linux-usb@vger.kernel.org
Subject: Re: [PATCH 02/10] usb: chipidea: usb OTG fsm initlization.
On Wed, Jan 08, 2014 at 05:06:17PM +0800, Li Jun wrote:
This patch adds OTG fsm related initizations 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 |1 +
drivers/usb/chipidea/otg.c |6 +++
drivers/usb/chipidea/otg_fsm.c | 70
drivers/usb/chipidea/otg_fsm.h | 27 +++
5 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/chipidea/Makefile
b/drivers/usb/chipidea/Makefile index 7345d21..5e1ecc5 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 1c94fc5..0f1abc1 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -144,6 +144,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;
diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
index 39bd7ec..2e13f2f 100644
--- a/drivers/usb/chipidea/otg.c
+++ b/drivers/usb/chipidea/otg.c
@@ -95,6 +95,12 @@ static void ci_otg_work(struct work_struct *work)
*/
int ci_hdrc_otg_init(struct ci_hdrc *ci) {
+ int retval = 0;
+
+ retval = ci_hdrc_otg_fsm_init(ci);
+ if (retval)
+ return retval;
+
INIT_WORK(ci-work, ci_otg_work);
ci-wq = create_singlethread_workqueue(ci_otg);
if (!ci-wq) {
diff --git a/drivers/usb/chipidea/otg_fsm.c
b/drivers/usb/chipidea/otg_fsm.c new file mode 100644 index
000..1f8907d
--- /dev/null
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -0,0 +1,70 @@
+/*
+ * 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 otgsc register, it may include OTG
+operation
+ * in the future.
+ */
Please update description for both this file and otg.c.
[Li Jun] ok, I will update.
+
+#include linux/usb/otg.h
+#include linux/usb/otg-fsm.h
+#include linux/usb/gadget.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) {
+ if (ci-transceiver == NULL)
+ return -EPROBE_DEFER;
+
Since ci_usb_phy_init is run before that, this check should be there.
I will have a patch for that.
[Li Jun]I will remove this since you plan another patch for it.
+ ci-transceiver-otg = devm_kzalloc(ci-dev,
+ sizeof(struct usb_otg), GFP_KERNEL);
+ if (!ci-transceiver-otg) {
+ dev_err(ci-dev,
+ Failed to allocate usb_otg structure for ci hdrc otg!\n);
+ return -ENOMEM;
+ }
+
+ ci-fsm = devm_kzalloc(ci-dev,
+ sizeof(struct otg_fsm), GFP_KERNEL);
+ if (!ci-fsm) {
+ dev_err(ci-dev,
+ Failed to allocate otg_fsm structure for ci hdrc otg!\n);
+ return -ENOMEM;
+ }
+
+ ci-fsm-power_up = 1;
+ ci-fsm-id = hw_read(ci, OP_OTGSC, OTGSC_ID);
+ ci-fsm-otg = ci-transceiver-otg;
+ ci-fsm-otg-phy = ci-transceiver;
+ ci-fsm-otg-gadget = ci-gadget;
+ ci-transceiver-state = OTG_STATE_UNDEFINED;
+
+ mutex_init(ci-fsm-lock);
+
+ /* enable ID and A vbus valid irq */
+ hw_write(ci, OP_OTGSC, OTGSC_INT_EN_BITS | OTGSC_INT_STATUS_BITS,
+ OTGSC_IDIE | OTGSC_AVVIE);
One or two TAB between two lines for one statement is better.
Peter
[Li Jun] The line OTGSC_IDIE | OTGSC_AVVIE); is placed substantially to the
right already.
+
+ if (ci-fsm-id) {
+ ci-fsm-b_ssend_srp =
+ hw_read(ci, OP_OTGSC, OTGSC_BSV) ? 0 : 1;
+ ci-fsm-b_sess_vld =
+ hw_read(ci, OP_OTGSC,
RE: [PATCH 08/10] usb: chipidea: add OTG HNP polling support.
-Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Thursday, January 09, 2014 5:07 AM To: Li Jun-B47624 Cc: ba...@ti.com; Chen Peter-B29397; linux-usb@vger.kernel.org Subject: Re: [PATCH 08/10] usb: chipidea: add OTG HNP polling support. Hi, On Wed, Jan 08, 2014 at 05:06:23PM +0800, Li Jun wrote: This patch add OTG HNP polling support for both A and B device. After A/B in host state, host request polling message will be sent from host to peripheral every 1.5s, if host found the host request flag is set to be 1 by peripheral, a role switch will be started. Signed-off-by: Li Jun b47...@freescale.com --- drivers/usb/chipidea/ci.h |2 + drivers/usb/chipidea/otg_fsm.c | 80 drivers/usb/chipidea/otg_fsm.h |3 + drivers/usb/chipidea/udc.c | 11 - drivers/usb/phy/phy-fsm-usb.c |6 +++ you need to figure out a way to split this patch, the dependency you created here is really pointless. [Li Jun] I will split this patch and create a separate patch set for it. -- balbi -- 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 (millions of) Too many fragments error on LUKS-encrypted device
2014/1/15 David Laight david.lai...@aculab.com: This is a known problem. A side effect of trying to fix USB ethernet. There is a patch lurking to increase the ring size from 64 to 256. Thanks, but where could I get the patch? I searched a bit but cannot find it. -- Sascha Weaver -- 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 (millions of) Too many fragments error on LUKS-encrypted device
From: Sascha 2014/1/15 David Laight david.lai...@aculab.com: This is a known problem. A side effect of trying to fix USB ethernet. There is a patch lurking to increase the ring size from 64 to 256. Thanks, but where could I get the patch? I searched a bit but cannot find it. I'm no good at finding patches! Edit drivers/usb/host/xhci.h and change the definition of TRBS_PER_SEGMENT from 64 to 256. David
Re: Suspend issues with a LaCie USB hard disk connected
Hi, Sorry for the long, primarily holiday-related delay on this. On 12/18/2013 09:46 PM, Alan Stern wrote: On Wed, 18 Dec 2013, Daniel Mack wrote: I'm facing an issue putting an embedded system to sleep while a Lacie external USB hard disk is connected. Relevant kernel messages that occur at the attempt are: [ 13.834731] PM: Sending message for entering DeepSleep mode [ 13.846575] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 13.858818] sd 0:0:0:0: [sda] [ 13.862432] Result: hostbyte=0x00 driverbyte=0x08 [ 13.867349] sd 0:0:0:0: [sda] [ 13.870626] Sense Key : 0x5 [current] [ 13.874602] sd 0:0:0:0: [sda] [ 13.877879] ASC=0x20 ASCQ=0x0 [ 13.885053] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns -5 [ 13.901130] PM: Device 0:0:0:0 failed to suspend async: error -5 [ 13.907507] PM: Some devices failed to suspend, or early wake event detected What happens is that in sd_sync_cache(), scsi_execute_req_flags() returns 0x0802, so driver_byte(res) evaluates to DRIVER_SENSE and host_byte(res) is DID_OK, which is an unhandled case that leads to -EIO eventually. I have admittedly not much clue about the SCSI layer, so I wonder what would be the best way to fix this. Should DID_OK just be handled as non-error condition in the switch? Should the suspend call chain ignore such errors from sd_sync_cache()? I'm open to suggestions and happy to test patches. The Sense Key and ASC values indicate that the drive did not understand the SYNCHRONIZE CACHE command. A usbmon trace would verify this; see the instructions in Documentation/usb/usbmon.txt. Assuming that really is what happened, we have to decide how to handle the situation. Ok, this is the usbmon trace that I captured when the system goes to suspend with the USB storage media connected but unmounted: cebe5e00 3629314504 S Bo:1:003:2 -115 31 = 55534243 1000 0a35 00 cebe5e00 3629315214 C Bo:1:003:2 0 31 cebe5e00 3629315413 S Bi:1:003:1 -115 13 cebe5e00 3629315492 C Bi:1:003:1 0 13 = 55534253 1000 01 cebe5e00 3629315571 S Bo:1:003:2 -115 31 = 55534243 1100 1200 8603 0012 00 cebe5e00 3629315606 C Bo:1:003:2 0 31 cecd4580 3629315681 S Bi:1:003:1 -115 18 cecd4580 3629315744 C Bi:1:003:1 0 18 = 7500 000a 2000 cebe5e00 3629315772 S Bi:1:003:1 -115 13 cebe5e00 3629315817 C Bi:1:003:1 0 13 = 55534253 1100 00 cebe5e00 3629319750 S Bo:1:003:2 -115 31 = 55534243 1200 0a35 00 cebe5e00 3629319826 C Bo:1:003:2 0 31 cebe5e00 3629319856 S Bi:1:003:1 -115 13 cebe5e00 3629319910 C Bi:1:003:1 0 13 = 55534253 1200 01 cebe5e00 3629319964 S Bo:1:003:2 -115 31 = 55534243 1300 1200 8603 0012 00 cebe5e00 3629319996 C Bo:1:003:2 0 31 cecd4300 3629320026 S Bi:1:003:1 -115 18 cecd4300 3629320086 C Bi:1:003:1 0 18 = 7500 000a 2000 cebe5e00 3629320111 S Bi:1:003:1 -115 13 cebe5e00 3629320152 C Bi:1:003:1 0 13 = 55534253 1300 00 cebe5e00 3629320360 S Bo:1:003:2 -115 31 = 55534243 1400 0a35 00 cebe5e00 3629320610 C Bo:1:003:2 0 31 cebe5e00 3629320670 S Bi:1:003:1 -115 13 cebe5e00 3629320714 C Bi:1:003:1 0 13 = 55534253 1400 01 cebe5e00 3629320752 S Bo:1:003:2 -115 31 = 55534243 1500 1200 8603 0012 00 cebe5e00 3629320809 C Bo:1:003:2 0 31 cecd4300 3629320834 S Bi:1:003:1 -115 18 cecd4300 3629320863 C Bi:1:003:1 0 18 = 7500 000a 2000 cebe5e00 3629320885 S Bi:1:003:1 -115 13 cebe5e00 3629320923 C Bi:1:003:1 0 13 = 55534253 1500 00 ceb36280 3629350243 C Ii:1:001:1 -2:2048 0 cecd4800 3630011191 S Ci:1:001:0 s a3 00 0001 0004 4 cecd4800 3630011333 C Ci:1:001:0 0 4 = 07051200 cecd4800 3630011574 S Co:1:001:0 s 23 01 0011 0001 0 cecd4800 3630011699 C Co:1:001:0 0 0 cecd4800 3630011745 S Co:1:001:0 s 23 01 0014 0001 0 cecd4800 3630011789 C Co:1:001:0 0 0 ceb36280 3630112579 S Ii:1:001:1 -115:2048 4 cecd4500 3630112825 S Ci:1:001:0 s a3 00 0001 0004 4 cecd4500 3630112952 C Ci:1:001:0 0 4 = 0705 cecd4500 3630113001 S Co:1:001:0 s 23 01 0002 0001 0 cecd4500 3630113084 C Co:1:001:0 0 0 ceb36280 3630122552 C Ii:1:001:1 0:2048 1 = 02 ceb36280 3630122566 S Ii:1:001:1 -115:2048 4 cecd4500 3630152573 S Ci:1:001:0 s a3 00 0001 0004 4 cecd4500 3630152625 C Ci:1:001:0 0 4 = 0305 cecd4500 3630172588 S Ci:1:003:0 s 80 00 0002 2 cecd4500 3630172603 E Ci:1:003:0 -19 0 cecd4500 3630172744 S Co:1:001:0 s 23 03 0004 0001 0 cecd4500 3630184219 C Co:1:001:0 0 0 cecd4500 3630242590 S Ci:1:001:0 s a3 00 0001 0004 4 cecd4500 3630242657 C Ci:1:001:0 0 4 = 1305 cecd4500 3630302564 S Ci:1:001:0 s a3 00 0001 0004 4 cecd4500 3630302609 C Ci:1:001:0 0 4 = 1305
Re: xhci-hcd (millions of) Too many fragments error on LUKS-encrypted device
2014/1/15 David Laight david.lai...@aculab.com: Edit drivers/usb/host/xhci.h and change the definition of TRBS_PER_SEGMENT from 64 to 256. Thanks David! I re-compiled my kernel after changing 64 to 256 and it works! No more errors are produced! -- Sascha Weaver -- 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 (millions of) Too many fragments error on LUKS-encrypted device
On Wed, Jan 15, 2014 at 10:51:28AM +, David Laight wrote: From: Sascha 2014/1/15 David Laight david.lai...@aculab.com: This is a known problem. A side effect of trying to fix USB ethernet. There is a patch lurking to increase the ring size from 64 to 256. Thanks, but where could I get the patch? I searched a bit but cannot find it. I'm no good at finding patches! Edit drivers/usb/host/xhci.h and change the definition of TRBS_PER_SEGMENT from 64 to 256. Probably those: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733907#25 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733826#69 HTH, Johannes -- 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: Bug#704242: Driver for PL-2303 HX not working
On Tue, Jan 14, 2014 at 12:01:30AM +0100, Karsten Malcher wrote: Hello together, i will close this bug at Debian now. After the last update this error seems to disappear in Debian stable. http://ftp.debian.org/debian/dists/wheezy/ChangeLog USB: pl2303: fix device initialisation at open That's good to hear. The source for this patch can be found here: http://www.spinics.net/lists/stable/msg30311.html This is not directly related to commit you refer to above (it fixes a different problem). It's possible that this will not fix the bug under all circumstances depending on the application. Summary: == I did need some time to realize that this bug will occur only with PL2303HX chips that are China clones. In fact this type of chips run out of production at Profilic. http://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41showlevel=0017-0037-0041 Only the PL2303HXD can be buyed as original, so any new PL2303HX is a China clone. I have been contacted by Frank Schäfer and so we tested some of his driver improvements in combination with newer kernels. Up to now this could not be backported to kernel 3.2.x, but i could test a kernel 3.12.6 on Debian wheezy and the PL2303HX is running fine. There are really much products with this clone chips out there, so some further improvements of the driver would be really helpful. I will make further tests together with Frank and hope that this improvements will find a place into the next kernel versions starting with Debian jessie and 3.12.6 The pl2303 has been cleaned up quite a bit lately (will show up in v3.14), so it should be even easier to add support for further device types with all their quirks. Patches are most welcome. 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
[PATCH] usb: musb: do not sleep in atomic context
musb_port_reset() is called from musb_hub_control() which in turn holds
a spinlock, so musb_port_reset() is not allowed to call msleep().
With the asynchronous work helpers in place, this is fortunately easy to
fix by rescheduling the reset deassertion function to after the time
when the wait period is finished.
Note, however, that the MUSB_POWER_RESUME bit is only set on AM33xx
processors under rare conditions such as when to another driver
reporting an error during suspend. Hence, this didn't hit me yet in
normal operation.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/usb/musb/musb_core.c| 2 ++
drivers/usb/musb/musb_virthub.c | 20 +++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 202456b..c147d66 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -478,6 +478,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
musb-port1_status |=
(USB_PORT_STAT_C_SUSPEND 16)
| MUSB_PORT_STAT_RESUME;
+ musb-rh_timer = jiffies
++ msecs_to_jiffies(20);
schedule_delayed_work(
musb-finish_resume_work, 20);
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 966cf95..64a4ee7 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -159,7 +159,6 @@ void musb_port_reset(struct musb *musb, bool do_reset)
*/
power = musb_readb(mbase, MUSB_POWER);
if (do_reset) {
-
/*
* If RESUME is set, we must make sure it stays minimum 20 ms.
* Then we must clear RESUME and wait a bit to let musb start
@@ -168,11 +167,22 @@ void musb_port_reset(struct musb *musb, bool do_reset)
* detected.
*/
if (power MUSB_POWER_RESUME) {
- while (time_before(jiffies, musb-rh_timer))
- msleep(1);
+ long remain = (unsigned long) musb-rh_timer - jiffies;
+
+ if (musb-rh_timer 0 remain 0) {
+ /* take into account the minimum delay after
resume */
+ schedule_delayed_work(
+ musb-deassert_reset_work,
+ jiffies_to_msecs(remain));
+ return;
+ }
+
musb_writeb(mbase, MUSB_POWER,
- power ~MUSB_POWER_RESUME);
- msleep(1);
+ power ~MUSB_POWER_RESUME);
+
+ /* Give the core 1 ms to clear MUSB_POWER_RESUME */
+ schedule_delayed_work(musb-deassert_reset_work, 1);
+ return;
}
power = 0xf0;
--
1.8.4.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
usb audio breaks ohci-pci
When listening to my usb-bluetooth audio headset, the usb subsystem (I think) on my laptop crashes, the bluetooth/audio is lost, and my mplayer program is left in an uninterruptible sleep (D) state and cannot be killed. The only way to get my usb-audio working again is to reboot. Interestingly, after the usb/audio crash occurs, when I plug in my usb mouse to another port, it does get power, but isn't fully detected/usable. My syslog shows many messages like: kernel: hub 3-0:1.0: port 4 not reset yet, waiting 200ms ohci-pci :00:13.1: port[3] reset timeout, stat 0311 hub 3-0:1.0: unable to enumerate USB device on port 4 And lastly: kernel: hub 3-0:1.0: Cannot enable port 4. Maybe the USB cable is bad? In this state however, I am able to use my ehci-pci based usb-storage thumbdrive. However, after I disconnect the original usb audio device (that I suspect somehow causes this problem), none of my usb devices (mouse, thumbdrive, usb-bluetooth headset) work at all -- no power, no syslog messages. The last message from syslog is from when I disconnect the usb-audio device: kernel: ohci-pci :00:13.1: GetStatus roothub.portstatus [0] = 0x00030100 PESC CSC PPS kernel: hub 3-0:1.0: port 1, status 0100, change 0003, 12 Mb/s kernel: usb 3-1: USB disconnect, device number 3 kernel: usb 3-1: unregistering device kernel: usb 3-1: unregistering interface 3-1:1.0 The crash is difficult to reproduce, sometimes it can occur after a few minutes of a clean boot, and sometimes after a few days. After the audio/usb abruptly stops, the syslog simply says: kernel: ALSA sound/usb/endpoint.c:501 timeout: still 3 active urbs on EP #3 And then after a few minutes (after enabling some kernel debugging options), I get some call traces of the hung task(s), which have ohci_urb_dequeue in common. http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash1.log http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash2.log http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash3.log The problem is not with my device, since it occurs with another identical piece of hardware. It maybe be a problem with my laptop, since my friend does not seem to be experiencing this problem, although her laptop does not use ohci-pci. My usb controllers are: 1002:4374 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB Host Controller (prog-if 10 [OHCI]) 1002:4375 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB Host Controller (prog-if 10 [OHCI]) 1002:4373 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB2 Host Controller (prog-if 20 [EHCI]) The hardware device that seems to trigger the problem is the Logitech one: Bus 003 Device 002: ID 046d:0a29 Logitech, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Gadget Patches
Hi, On Wed, Jan 15, 2014 at 10:12:44AM +, suresh.gu...@freescale.com wrote: Please pick my below patches http://www.spinics.net/lists/linux-usb/msg97752.html http://www.spinics.net/lists/linux-usb/msg97753.html as I have already said, my tree is closed for v3.14, so is Greg's. You'll get no special treatment for sending a private email demanding that your patches get applied. Wait until v3.15 -- balbi signature.asc Description: Digital signature
xhci ASMedia lockups - a theory
I have a theory, I'll try to write a non-invasive patch. In spite of the comments and some code paths inc_enq() is only called by (and has only ever been called by) queue_trb(), so is only called for transfer and command rings. It takes care to avoid advancing past the LINK TRB. The coding would be much simpler if it did, and I postulate that the reason for this was that some hardware didn't like it. In particular doing so with TRB_CHAIN set could well cause issues. So assume that the ASMedia controller doesn't like LINK TRB if the link-to trb can't be processed. If the hardware test vectors don't test this is could easily be a bug. Now, under normal conditions the controller will be idle and won't look at the ring until the doorbell is rung - by which time the ownership bits are set through to the end of the command. But consider what happens if the controller is active and is looking for work prepare_ring() will change the ownership bit of any NOP TRB it writes and of the LINK TRB. The ownership on the first transfer TRB is set much later. This makes it not impossible for the controller to find a TRB it doesn't own after processing a LINK TRB. First thoughts are that you'd need to be setting up a transfer just as the last active one completes. But I've a different scenario: C1) Active transfer completes, controller: C2) Writes to the event ring C3) Raises a hardware interrupt D1) Driver interrupt routing runs: D2) Completes the transfer D3) Requests another transfer D4) Calls prepare_ring() for it C4) Controller try to read the next ring entry. (or the read finally completes) and it gets one it owns. This would be timing critical, typically requiring a fast host and a slow(ish) controller. Note that the latency on PCIe accesses (eg the one the controller does to read the ring entry) is massive - think ISA bus speeds! so the host has plenty of time to execute a few 1000 instructions. What the NOP TRBs do is make it much more likely that a TB will start at the beginning of a ring segment. David -- 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] ARM: sunxi: Add driver for sunxi usb phy
On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of registers. Besides this there are also some other
phy related bits which need poking, which are per phy, but shared between the
ohci and ehci controllers, so these are also controlled from this new phy
driver.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-sun4i-usb.c| 318
+
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
create mode 100644 drivers/phy/phy-sun4i-usb.c
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000..6c54b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,26 @@
+Allwinner sun4i USB PHY
+---
+
+Required properties:
+- compatible : should be one of allwinner,sun4i-a10-usb-phy,
+ allwinner,sun5i-a13-usb-phy or allwinner,sun7i-a20-usb-phy
+- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
+ 1 pair for the pmu-irq register of each hcd
+- #phy-cells : from the generic phy bindings, must be 1
+
+Optional properties:
+- clocks : phandle + clock specifier for the phy clock
+- clock-names : usb_phy
+- resets : a list of phandle + reset specifier pairs
+- reset-names : usb0_reset, usb1_reset, and / or usb2_reset
+
+Example:
+ usbphy: phy@0x01c13400 {
+ #phy-cells = 1;
+ compatible = allwinner,sun4i-a10-usb-phy;
+ reg = 0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4;
+ clocks = usb_clk 8;
+ clock-names = usb_phy;
+ resets = usb_clk 1, usb_clk 2;
+ reset-names = usb1_reset, usb2_reset;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..dcce4cf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_SUN4I_USB
+ tristate Allwinner sunxi SoC USB PHY driver
+ depends on ARCH_SUNXI
+ select GENERIC_PHY
+ help
+ Enable this to support the transceiver that is part of Allwinner
+ sunxi SoCs.
+
+ This driver controls the entire USB PHY block, both the USB OTG
+ parts, as well as the 2 regular USB 2 host PHYs.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..e9e82f0 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
+obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
new file mode 100644
index 000..a15ecc1
--- /dev/null
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -0,0 +1,318 @@
+/*
+ * Allwinner sun4i USB phy driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Based on code from
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ *
+ * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki s.nawro...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/reset.h
+
+#define REG_ISCR 0x00
+#define REG_PHYCTL 0x04
+#define REG_PHYBIST 0x08
+#define REG_PHYTUNE 0x0c
+
+#define SUNXI_AHB_ICHR8_EN BIT(10)
+#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
+#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
+#define
usb disk recognized but fails
The SATA adapter has a power input, but it is not used, it is connected to the PC with Y-type USB cable. The disk works with my smart TV, it works with Windows on the same machine, it also had worked some time ago with Linux, but now it shows the following: [ 2192.027213] usb 1-3: new high-speed USB device number 5 using xhci_hcd [ 2192.042323] ums-cypress 1-3:1.0: USB Mass Storage device detected [ 2192.042500] scsi9 : usb-storage 1-3:1.0 [ 2193.044219] scsi 9:0:0:0: Direct-Access WDC WD64 00BPVT-00HXZT0 PQ: 0 ANSI: 0 [ 2193.045083] sd 9:0:0:0: [sdb] 1250263728 512-byte logical blocks: (640 GB/596 GiB) [ 2193.045240] sd 9:0:0:0: [sdb] Write Protect is off [ 2193.045245] sd 9:0:0:0: [sdb] Mode Sense: 03 00 00 00 [ 2193.045384] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.045388] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.046259] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.046264] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.054389] sdb: sdb1 [ 2193.055092] sd 9:0:0:0: [sdb] No Caching mode page found [ 2193.055095] sd 9:0:0:0: [sdb] Assuming drive cache: write through [ 2193.055098] sd 9:0:0:0: [sdb] Attached SCSI disk [ 2200.821345] usb 1-3: reset high-speed USB device number 5 using xhci_hcd [ 2200.835063] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e480 [ 2200.835068] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800bc71e4c0 [ 2267.897715] sd 9:0:0:0: [sdb] Unhandled sense code [ 2267.897719] sd 9:0:0:0: [sdb] [ 2267.897721] Result: hostbyte=0x07 driverbyte=0x08 [ 2267.897722] sd 9:0:0:0: [sdb] [ 2267.897724] Sense Key : 0x4 [current] [ 2267.897735] sd 9:0:0:0: [sdb] [ 2267.897736] ASC=0x0 ASCQ=0x0 [ 2267.897738] sd 9:0:0:0: [sdb] CDB: [ 2267.897740] cdb[0]=0x28: 28 00 4a 85 6e af 00 00 08 00 [ 2267.897746] end_request: I/O error, dev sdb, sector 1250258607 [ 2267.897750] Buffer I/O error on device sdb1, logical block 625129272 [ 2267.897752] Buffer I/O error on device sdb1, logical block 625129273 [ 2267.897753] Buffer I/O error on device sdb1, logical block 625129274 [ 2267.897754] Buffer I/O error on device sdb1, logical block 625129275 [ 2270.884154] usb 1-3: USB disconnect, device number 5 Bus 001 Device 010: ID 14cd:6116 Super Top M6116 SATA Bridge Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x14cd Super Top idProduct 0x6116 M6116 SATA Bridge bcdDevice1.50 iManufacturer 1 Super Top iProduct3 USB 2.0 SATA BRIDGE iSerial 2 M6116018VE15 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x0001 Self Powered -- 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 v5 1/2] ohci-platform: Add support for devicetree instantiation
Hi,
On 01/14/2014 08:08 PM, Alan Stern wrote:
On Mon, 13 Jan 2014, Hans de Goede wrote:
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should allow using ohci-platform from devicetree in various cases.
Specifically after this commit it can be used for the ohci controller found
on Allwinner sunxi SoCs.
This is fine as far as I am concerned, except for one thing.
@@ -60,17 +127,23 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_hcd *hcd;
struct resource *res_mem;
struct usb_ohci_pdata *pdata = dev_get_platdata(dev-dev);
- int irq;
- int err = -ENOMEM;
-
- if (!pdata) {
- WARN_ON(1);
- return -ENODEV;
- }
+ struct ohci_platform_priv *priv;
+ int clk, irq, err;
clk isn't initialized to anything...
Good catch, will fix and then do a v6 with this + the issue from your other
mail fixed
and I'll add your ack.
-err_put_hcd:
- usb_put_hcd(hcd);
err_power:
if (pdata-power_off)
pdata-power_off(dev);
+err_put_clks:
+ while (--clk = 0)
+ clk_put(priv-clks[clk]);
... but it gets used here. The compiler should have warned about this.
Should have yes, but it doesn't (I've just double checked).
After fixing that, you can add
Acked-by: Alan Stern st...@rowland.harvard.edu
Thanks Regards,
Hans
--
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 ASMedia lockups - a theory
On Wed, 15 Jan 2014, David Laight wrote: I have a theory, I'll try to write a non-invasive patch. In spite of the comments and some code paths inc_enq() is only called by (and has only ever been called by) queue_trb(), so is only called for transfer and command rings. It takes care to avoid advancing past the LINK TRB. The coding would be much simpler if it did, and I postulate that the reason for this was that some hardware didn't like it. In particular doing so with TRB_CHAIN set could well cause issues. So assume that the ASMedia controller doesn't like LINK TRB if the link-to trb can't be processed. If the hardware test vectors don't test this is could easily be a bug. Now, under normal conditions the controller will be idle and won't look at the ring until the doorbell is rung - by which time the ownership bits are set through to the end of the command. But consider what happens if the controller is active and is looking for work prepare_ring() will change the ownership bit of any NOP TRB it writes and of the LINK TRB. The ownership on the first transfer TRB is set much later. This makes it not impossible for the controller to find a TRB it doesn't own after processing a LINK TRB. Doesn't this mean you shouldn't change the ownership of a LINK TRB until after you change the ownership of the TRB it points to? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/10] xhci: re-work command queue management
On 01/14/2014 02:37 PM, David Laight wrote: From: Mathias Nyman ... The fact that you are having to allocate memory ion an ISR ought also to be ringing alarm bells. It did. Other options are as you said to use a 'software command ring'. Either just pre-allocate a full command ring (64 trbs * sizeof(struct xhci_command)), roughly 2300 bytes when driver loads, or then a smaller pool of commands just used for ISR submitted commands. (We then need to either either expand pool, or start allocating in isr if pool is empty) If you pre-allocate mapping 1-1 with the command ring entries you don't need many of the fields of xhci_command at all. So the allocated size will be much smaller. True, then the struct list_head could be removed. Even the trb pointer could be removed if the command ring stays in one segment(just use the trb - base as an index ) ... Looking at the number of fields in xci_command, why do you need the caller to pass a structure at all? Just make the fields parameters to the 'send a command' function along with a parameter that says whether it can sleep (in kmalloc() or if the ring is full depending on the implementation). Command completion events only tell which trb completed and its status. The structure is needed to map the trb to the right completion so that the caller can continue running, check status and move on. The xhci_command fields forISR allocated commands are really not used that much. Only status is used if the command timeouts. But we want these command structures on the command list to make sure eveything else works (timeout works, commands completion events are in the same order as commands on our command list etc) So in a way we're allocating memory in ISR which is not really even used. I'll try to create something to that avoid that -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: [PATCH v3 03/10] usb: find internal hub tier mismatch via acpi
On Tue, 14 Jan 2014, Sarah Sharp wrote: It's always possible for xhci-hcd to prevent the USB-2 root hub from being suspended by calling pm_runtime_get_noresume. The corresponding _put can be done after the USB-3 root hub has been registered. Sure, it's on my todo list to fix that. I just wondered if there were other race conditions present, given that I could find one off the top of my head. What do you think about the rest of the patchset? I regret that I haven't taken the time to look through it yet. :-( I'll do my best to go through it soon. 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: [Bug 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.
On 01/15/2014 02:03 PM, David Laight wrote: From: tatxarata Update on my current research status. 1. To get normal read/write speed over USB3 I have to set max_sector_kb to 64. Otherwise write is fine, but read is very slow (about 300kb/s). Maybe this is hardware issue of this reader/card. However over USB2 all works fine without any tweaks. All that said below is for case of max_sector_kb = 64. I can't remember if you've said before... Is that USB2 on ehci or xhci? ie in a USB2 only port or a USB3 port with a USB2 cable. David When I say USB2 i mean ehci. However I've tested reader in xhci USB3 port using USB2 cable. In that case all works like device is in ehci USB2 port: no issues observed without any tweaks needed, all works as expected. ps. lspci says i have 3 USB controllers: 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) All of mentioned cardreaders use GenesysLogic GL3220 USB 3.0 compliant Mulit-LUN card reader controller. http://www.genesyslogic.com/en/product_view.php?show=12 On ginzzu it originally has been flashed with firmware 0566, now with 0570. Both firmwares works the same. Transcend device is flashed with TS22 from official site. As stated at transcend site UDMA7 mode for CF is supported starting from firmware version TS17. I'm not trying to say that microsoft Windows 8 contains reference USB 3.0 implementation, but my Transcend cardreader and CF card works without any issues in Windows 8. Maybe some bugs in reader firmware made friends with bugs from USB3.0 stack from microsoft and together they are doing their job well? -- 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] ARM: sunxi: Add driver for sunxi usb phy
Hi,
On 01/15/2014 04:00 PM, Kishon Vijay Abraham I wrote:
On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of registers. Besides this there are also some other
phy related bits which need poking, which are per phy, but shared between the
ohci and ehci controllers, so these are also controlled from this new phy
driver.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-sun4i-usb.c| 318 +
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
create mode 100644 drivers/phy/phy-sun4i-usb.c
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000..6c54b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,26 @@
+Allwinner sun4i USB PHY
+---
+
+Required properties:
+- compatible : should be one of allwinner,sun4i-a10-usb-phy,
+ allwinner,sun5i-a13-usb-phy or allwinner,sun7i-a20-usb-phy
+- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
+ 1 pair for the pmu-irq register of each hcd
+- #phy-cells : from the generic phy bindings, must be 1
+
+Optional properties:
+- clocks : phandle + clock specifier for the phy clock
+- clock-names : usb_phy
+- resets : a list of phandle + reset specifier pairs
+- reset-names : usb0_reset, usb1_reset, and / or usb2_reset
+
+Example:
+ usbphy: phy@0x01c13400 {
+ #phy-cells = 1;
+ compatible = allwinner,sun4i-a10-usb-phy;
+ reg = 0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4;
+ clocks = usb_clk 8;
+ clock-names = usb_phy;
+ resets = usb_clk 1, usb_clk 2;
+ reset-names = usb1_reset, usb2_reset;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..dcce4cf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_SUN4I_USB
+ tristate Allwinner sunxi SoC USB PHY driver
+ depends on ARCH_SUNXI
+ select GENERIC_PHY
+ help
+ Enable this to support the transceiver that is part of Allwinner
+ sunxi SoCs.
+
+ This driver controls the entire USB PHY block, both the USB OTG
+ parts, as well as the 2 regular USB 2 host PHYs.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..e9e82f0 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
new file mode 100644
index 000..a15ecc1
--- /dev/null
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -0,0 +1,318 @@
+/*
+ * Allwinner sun4i USB phy driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Based on code from
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ *
+ * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki s.nawro...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/reset.h
+
+#define REG_ISCR 0x00
+#define REG_PHYCTL 0x04
+#define REG_PHYBIST0x08
+#define REG_PHYTUNE0x0c
+
+#define SUNXI_AHB_ICHR8_EN BIT(10)
+#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
+#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
+#define
RE: xhci ASMedia lockups - a theory
From: Alan Stern On Wed, 15 Jan 2014, David Laight wrote: I have a theory, I'll try to write a non-invasive patch. In spite of the comments and some code paths inc_enq() is only called by (and has only ever been called by) queue_trb(), so is only called for transfer and command rings. It takes care to avoid advancing past the LINK TRB. The coding would be much simpler if it did, and I postulate that the reason for this was that some hardware didn't like it. In particular doing so with TRB_CHAIN set could well cause issues. So assume that the ASMedia controller doesn't like LINK TRB if the link-to trb can't be processed. If the hardware test vectors don't test this is could easily be a bug. Now, under normal conditions the controller will be idle and won't look at the ring until the doorbell is rung - by which time the ownership bits are set through to the end of the command. But consider what happens if the controller is active and is looking for work prepare_ring() will change the ownership bit of any NOP TRB it writes and of the LINK TRB. The ownership on the first transfer TRB is set much later. This makes it not impossible for the controller to find a TRB it doesn't own after processing a LINK TRB. Doesn't this mean you shouldn't change the ownership of a LINK TRB until after you change the ownership of the TRB it points to? That is what I assume. In practise this means that the 'first_trb' (whose ownership is set last) has to be the one that is valid when prepare_ring() is called. The plan for the patch is: - Save the enq pointer in prepare_ring (in the ep_ring structure). - When writing a trb set the ownership unless it is the saved one (ignoring the value set by the caller). - At the end invert the ownership on the saved entry. This is made slightly more complex by the way the isoc code abuses prepare_ring() and prepare_transfer(). If I get the code right a lot of stuff can get deleted. For instance the 'more_trbs_coming' flag to inc_enc() could cause the ownership of the first entry be inverted and the correct doorbell rung. I also think the doorbell address and value are fixed properties of a ring and could usefully be saved in the ring structure. David -- 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 v6 0/2] ohci and ehci-platform clks, phy and dt support
Hi all, And here is v6 of my ohci and ehci-platform clks, phy and dt support patch-set, this version addresses the 2 small bugs Alan found. Other then that there are no changes compared to v5. Regards, Hans -- 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 v6 1/2] ohci-platform: Add support for devicetree instantiation
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should allow using ohci-platform from devicetree in various cases.
Specifically after this commit it can be used for the ohci controller found
on Allwinner sunxi SoCs.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 22 +++
drivers/usb/host/ohci-platform.c | 164 ++---
2 files changed, 162 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-ohci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
new file mode 100644
index 000..f9d6c73
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -0,0 +1,22 @@
+USB OHCI controllers
+
+Required properties:
+- compatible : usb-ohci
+- reg : ohci controller register range (address and length)
+- interrupts : ohci controller interrupt
+
+Optional properties:
+- clocks : a list of phandle + clock specifier pairs
+- phys : phandle + phy specifier pair
+- phy-names : usb
+
+Example:
+
+ ohci0: ohci@0x01c14400 {
+ compatible = allwinner,sun4i-a10-ohci, usb-ohci;
+ reg = 0x01c14400 0x100;
+ interrupts = 64;
+ clocks = usb_clk 6, ahb_gates 2;
+ phys = usbphy 1;
+ phy-names = usb;
+ };
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index f351ff5..0262b13 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -3,6 +3,7 @@
*
* Copyright 2007 Michael Buesch m...@bues.ch
* Copyright 2011-2012 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
*
* Derived from the OCHI-SSB driver
* Derived from the OHCI-PCI driver
@@ -14,11 +15,14 @@
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include linux/clk.h
+#include linux/dma-mapping.h
#include linux/hrtimer.h
#include linux/io.h
#include linux/kernel.h
#include linux/module.h
#include linux/err.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
@@ -27,6 +31,13 @@
#include ohci.h
#define DRIVER_DESC OHCI generic platform driver
+#define OHCI_MAX_CLKS 3
+#define hcd_to_ohci_priv(h) ((struct ohci_platform_priv *)hcd_to_ohci(h)-priv)
+
+struct ohci_platform_priv {
+ struct clk *clks[OHCI_MAX_CLKS];
+ struct phy *phy;
+};
static const char hcd_name[] = ohci-platform;
@@ -48,11 +59,67 @@ static int ohci_platform_reset(struct usb_hcd *hcd)
return ohci_setup(hcd);
}
+static int ohci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk, ret;
+
+ for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++) {
+ ret = clk_prepare_enable(priv-clks[clk]);
+ if (ret)
+ goto err_disable_clks;
+ }
+
+ if (priv-phy) {
+ ret = phy_init(priv-phy);
+ if (ret)
+ goto err_disable_clks;
+
+ ret = phy_power_on(priv-phy);
+ if (ret)
+ goto err_exit_phy;
+ }
+
+ return 0;
+
+err_exit_phy:
+ phy_exit(priv-phy);
+err_disable_clks:
+ while (--clk = 0)
+ clk_disable_unprepare(priv-clks[clk]);
+
+ return ret;
+}
+
+static void ohci_platform_power_off(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk;
+
+ if (priv-phy) {
+ phy_power_off(priv-phy);
+ phy_exit(priv-phy);
+ }
+
+ for (clk = OHCI_MAX_CLKS - 1; clk = 0; clk--)
+ if (priv-clks[clk])
+ clk_disable_unprepare(priv-clks[clk]);
+}
+
static struct hc_driver __read_mostly ohci_platform_hc_driver;
static const struct ohci_driver_overrides platform_overrides __initconst = {
- .product_desc = Generic Platform OHCI controller,
- .reset =ohci_platform_reset,
+ .product_desc = Generic Platform OHCI controller,
+ .reset =ohci_platform_reset,
+ .extra_priv_size = sizeof(struct ohci_platform_priv),
+};
+
+static struct usb_ohci_pdata ohci_platform_defaults = {
+ .power_on = ohci_platform_power_on,
+ .power_suspend =ohci_platform_power_off,
+ .power_off =ohci_platform_power_off,
};
static int ohci_platform_probe(struct platform_device *dev)
@@ -60,17 +127,23 @@ static int
[PATCH v6 2/2] ehci-platform: Add support for clks and phy passed through devicetree
Currently ehci-platform is only used in combination with devicetree when used
with some Via socs. By extending it to (optionally) get clks and a phy from
devicetree, and enabling / disabling those on power_on / off, it can be used
more generically. Specifically after this commit it can be used for the
ehci controller on Allwinner sunxi SoCs.
Since ehci-platform is intended to handle any generic enough non pci ehci
device, add a usb-ehci compatibility string.
There already is a usb-ehci device-tree bindings document, update this
with clks and phy bindings info.
Although actually quite generic so far the via,vt8500 compatibilty string
had its own bindings document. Somehow we even ended up with 2 of them. Since
these provide no extra information over the generic usb-ehci documentation,
this patch removes them.
The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
2 drivers claiming the same compatibility string getting build on ppc.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 25 +++-
.../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 ---
.../devicetree/bindings/usb/vt8500-ehci.txt| 12 --
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ehci-platform.c | 149 +
5 files changed, 142 insertions(+), 60 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index fa18612..fad10f3 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -7,13 +7,14 @@ Required properties:
(debug-port or other) can be also specified here, but only after
definition of standard EHCI registers.
- interrupts : one EHCI interrupt should be described here.
-If device registers are implemented in big endian mode, the device
-node should have big-endian-regs property.
-If controller implementation operates with big endian descriptors,
-big-endian-desc property should be specified.
-If both big endian registers and descriptors are used by the controller
-implementation, big-endian property can be specified instead of having
-both big-endian-regs and big-endian-desc.
+
+Optional properties:
+ - big-endian-regs : boolean, set this for hcds with big-endian registers
+ - big-endian-desc : boolean, set this for hcds with big-endian descriptors
+ - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
+ - clocks : a list of phandle + clock specifier pairs
+ - phys : phandle + phy specifier pair
+ - phy-names : usb
Example (Sequoia 440EPx):
ehci@e300 {
@@ -23,3 +24,13 @@ Example (Sequoia 440EPx):
reg = 0 e300 90 0 e390 70;
big-endian;
};
+
+Example (Allwinner sun4i A10 SoC):
+ ehci0: ehci@0x01c14000 {
+ compatible = allwinner,sun4i-a10-ehci, usb-ehci;
+ reg = 0x01c14000 0x100;
+ interrupts = 39;
+ clocks = ahb_gates 1;
+ phys = usbphy 1;
+ phy-names = usb;
+ };
diff --git a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
deleted file mode 100644
index 17b3ad1..000
--- a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 EHCI Controller
--
-
-Required properties:
-- compatible : via,vt8500-ehci
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : ehci controller interrupt
-
-Example:
-
- ehci@d8007900 {
- compatible = via,vt8500-ehci;
- reg = 0xd8007900 0x200;
- interrupts = 43;
- };
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
deleted file mode 100644
index 5fb8fd6..000
--- a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
-
-Required properties:
- - compatible: Should be via,vt8500-ehci or wm,prizm-ehci.
- - reg: Address range of the ehci registers. size should be 0x200
- - interrupts: Should contain the ehci interrupt.
-
-usb: ehci@D8007100 {
- compatible = wm,prizm-ehci, usb-ehci;
- reg = 0xD8007100 0x200;
- interrupts = 1;
-};
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a9707da..e28cbe0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -255,6 +255,7 @@ config
Re: [PATCH v6 1/2] ohci-platform: Add support for devicetree instantiation
On Wed, 15 Jan 2014, Hans de Goede wrote:
+static int ohci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk, ret;
+
+ for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++) {
You fixed this one...
@@ -125,13 +225,22 @@ static int ohci_platform_remove(struct platform_device
*dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(dev-dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk;
usb_remove_hcd(hcd);
- usb_put_hcd(hcd);
if (pdata-power_off)
pdata-power_off(dev);
+ for (clk = 0; priv-clks[clk] clk OHCI_MAX_CLKS; clk++)
but not this one. :-( Same for the ehci-platform patch.
In fact, it might be easier to make this loop go backward, like
you do in the *_platform_power_off routines.
Is there a devm-type routine that will take care of all this for you?
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 1/2] usb: gadget: f_fs: add poll for endpoint 0
On Tue, Jan 14 2014, Robert Baldyga wrote:
This patch adds poll function for file representing ep0.
Ability of read from or write to ep0 file is related with actual state of ffs:
- When desctiptors or strings are not written yet, POLLOUT flag is set.
- If there is any event to read, POLLIN flag is set.
- If setup request was read, POLLIN and POLLOUT flag is set, to allow
send response (by performing I/O operation consistent with setup request
direction) or set stall (by performing I/O operation opposite setup
request direction).
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/gadget/f_fs.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
@@ -726,6 +725,45 @@ static long ffs_ep0_ioctl(struct file *file, unsigned
code, unsigned long value)
return ret;
}
+static unsigned int ffs_ep0_poll(struct file *file, poll_table *wait)
+{
+ struct ffs_data *ffs = file-private_data;
+ unsigned int mask = POLLWRNORM;
+ int ret;
+
+ ret = ffs_mutex_lock(ffs-mutex, file-f_flags O_NONBLOCK);
+ if (unlikely(ret 0))
+ return mask;
+
+ switch (ffs-state) {
+ case FFS_READ_DESCRIPTORS:
+ case FFS_READ_STRINGS:
+ mask |= POLLOUT;
+ break;
+
+ case FFS_ACTIVE:
+ switch (FFS_SETUP_STATE(ffs)) {
+ case FFS_NO_SETUP:
+ if(ffs-ev.count)
+ mask |= POLLIN;
+ break;
+
+ case FFS_SETUP_PENDING:
This should also be the case for:
case FFS_SETUP_CANCELED:
After all, we are waiting for user space to write/read something to the
end point so that we can return -EIDRM.
+ mask |= (POLLIN | POLLOUT);
+ break;
+
+ default:
+ break;
This default is then unnecessary.
+ }
+ default:
+ break;
Having an explicit:
case FFS_CLOSING:
might assist the compiler in producing warnings later on if someone
decided to add some more values to ffs_state enum.
+ }
+
+ mutex_unlock(ffs-mutex);
+
+ return mask;
+}
+
static const struct file_operations ffs_ep0_operations = {
.llseek = no_llseek,
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz(o o)
ooo +--m...@google.com--xmpp:min...@jabber.org--ooO--(_)--Ooo--
signature.asc
Description: PGP signature
RE: xhci ASMedia lockups - a theory and a patch
From: David Laight
From: Alan Stern
On Wed, 15 Jan 2014, David Laight wrote:
I have a theory, I'll try to write a non-invasive patch.
...
Doesn't this mean you shouldn't change the ownership of a LINK TRB
until after you change the ownership of the TRB it points to?
That is what I assume.
In practise this means that the 'first_trb' (whose ownership is set
last) has to be the one that is valid when prepare_ring() is called.
The plan for the patch is:
- Save the enq pointer in prepare_ring (in the ep_ring structure).
- When writing a trb set the ownership unless it is the saved one
(ignoring the value set by the caller).
- At the end invert the ownership on the saved entry.
Below is a possible patch, I've only compile tested it.
I've minimalised the patch by not removing all the code that saves
'start_trb' and modifies the TRB_CYCLE bit.
If the patch works those parts can also be tidied up.
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 53c2e29..589d336 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2928,6 +2928,11 @@ static void queue_trb(struct xhci_hcd *xhci, struct
xhci_ring *ring,
struct xhci_generic_trb *trb;
trb = ring-enqueue-generic;
+
+ field4 = (field4 ~TRB_CYCLE) | ring-cycle_state;
+ if (trb == ring-enqueue_first-generic)
+ field4 ^= TRB_CYCLE;
+
trb-field[0] = cpu_to_le32(field1);
trb-field[1] = cpu_to_le32(field2);
trb-field[2] = cpu_to_le32(field3);
@@ -2972,6 +2977,8 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
return -EINVAL;
}
+ /* Save entry whose owner needs flipping at the end */
+ ep_ring-enqueue_first = ep_ring-enqueue;
while (1) {
if (room_on_ring(xhci, ep_ring, num_trbs)) {
union xhci_trb *trb = ep_ring-enqueue;
@@ -3014,13 +3021,16 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
ep_ring-cycle_state);
ep_ring-num_trbs_free -= usable;
- do {
+ trb-generic.field[3] = nop_cmd ^
cpu_to_le32(TRB_CYCLE);
+ for (;;) {
trb-generic.field[0] = 0;
trb-generic.field[1] = 0;
trb-generic.field[2] = 0;
- trb-generic.field[3] = nop_cmd;
trb++;
- } while (--usable);
+ if (!--usable)
+ break;
+ trb-generic.field[3] = nop_cmd;
+ }
ep_ring-enqueue = trb;
if (room_on_ring(xhci, ep_ring, num_trbs))
break;
@@ -3059,7 +3069,8 @@ static int prepare_ring(struct xhci_hcd *xhci, struct
xhci_ring *ep_ring,
next-link.control |= cpu_to_le32(TRB_CHAIN);
wmb();
- next-link.control ^= cpu_to_le32(TRB_CYCLE);
+ if (next != ep_ring-enqueue_first)
+ next-link.control ^= cpu_to_le32(TRB_CYCLE);
/* Toggle the cycle bit after the last ring segment. */
if (last_trb_on_last_seg(xhci, ring, ring-enq_seg,
next)) {
@@ -3096,11 +3107,13 @@ static int prepare_transfer(struct xhci_hcd *xhci,
return -EINVAL;
}
- ret = prepare_ring(xhci, ep_ring,
- le32_to_cpu(ep_ctx-ep_info) EP_STATE_MASK,
- num_trbs, mem_flags);
- if (ret)
- return ret;
+ if (td_index == 0) {
+ ret = prepare_ring(xhci, ep_ring,
+ le32_to_cpu(ep_ctx-ep_info) EP_STATE_MASK,
+ num_trbs, mem_flags);
+ if (ret)
+ return ret;
+ }
urb_priv = urb-hcpriv;
td = urb_priv-td[td_index];
@@ -3175,19 +3188,24 @@ static void check_trb_math(struct urb *urb, int
num_trbs, int running_total)
}
static void giveback_first_trb(struct xhci_hcd *xhci, int slot_id,
- unsigned int ep_index, unsigned int stream_id, int start_cycle,
- struct xhci_generic_trb *start_trb)
+ unsigned int ep_index, struct xhci_ring *ring)
{
/*
* Pass all the TRBs to the hardware at once and make sure this write
* isn't reordered.
*/
wmb();
- if (start_cycle)
- start_trb-field[3] |= cpu_to_le32(start_cycle);
- else
- start_trb-field[3] = cpu_to_le32(~TRB_CYCLE);
-
Re: [PATCH 2/2] usb: gadget: f_fs: add aio support
On Tue, Jan 14 2014, Robert Baldyga wrote:
This patch adds asynchronous I/O support for FunctionFS endpoint
files.
Thanks for doing this. I never had enough time to finish this feature.
@@ -343,6 +345,25 @@ static char *ffs_prepare_buffer(const char __user *buf,
size_t len)
__attribute__((warn_unused_result, nonnull));
+/* ffs_io_data structure
***/
+
+struct ffs_io_data {
+ int aio:1;
+ int read:1;
Just make those bools.
+
Nit: trailing white-space here in in other places. ;)
+ struct kiocb *kiocb;
+ const struct iovec *iovec;
+ unsigned long nr_segs;
+ char __user *buf;
+ size_t len;
+
+ struct mm_struct *mm;
+ struct work_struct work;
+
+ struct usb_ep *ep;
+ struct usb_request *req;
+};
+
/* Control file aka ep0
*/
static void ffs_ep0_complete(struct usb_ep *ep, struct usb_request *req)
@@ -788,8 +809,51 @@ static void ffs_epfile_io_complete(struct usb_ep *_ep,
struct usb_request *req)
}
}
-static ssize_t ffs_epfile_io(struct file *file,
- char __user *buf, size_t len, int read)
+static void ffs_user_copy_worker(struct work_struct *work)
+{
+ size_t len = 0;
+ int i = 0;
+ int ret;
+
+ struct ffs_io_data *io_data = container_of(work, struct ffs_io_data,
work);
Nit: Over 80 characters.
+
+ use_mm(io_data-mm);
+ for (i=0; i io_data-nr_segs; i++) {
+ ret = copy_to_user(io_data-iovec[i].iov_base,
+io_data-buf[len],
+io_data-iovec[i].iov_len);
+ len += io_data-iovec[i].iov_len;
+ }
+ unuse_mm(io_data-mm);
+
+ aio_complete(io_data-kiocb, 0, 0);
+
+ kfree(io_data-iovec);
+ kfree(io_data-buf);
+ kfree(io_data);
+}
+static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
{
struct ffs_epfile *epfile = file-private_data;
struct ffs_ep *ep;
@@ -825,25 +889,12 @@ first_try:
}
/* Do we halt? */
- halt = !read == !epfile-in;
+ halt = !io_data-read == !epfile-in;
if (halt epfile-isoc) {
ret = -EINVAL;
goto error;
}
- /* Allocate copy */
- if (!halt !data) {
- data = kzalloc(len, GFP_KERNEL);
- if (unlikely(!data))
- return -ENOMEM;
-
- if (!read
- unlikely(__copy_from_user(data, buf, len))) {
- ret = -EFAULT;
- goto error;
- }
- }
-
/* We will be using request */
ret = ffs_mutex_lock(epfile-mutex,
file-f_flags O_NONBLOCK);
@@ -869,33 +920,86 @@ first_try:
spin_unlock_irq(epfile-ffs-eps_lock);
ret = -EBADMSG;
} else {
- /* Fire the request */
- DECLARE_COMPLETION_ONSTACK(done);
+ struct usb_request *req;
- struct usb_request *req = ep-req;
- req-context = done;
- req-complete = ffs_epfile_io_complete;
- req-buf = data;
- req-length = len;
+ data = kzalloc(io_data-len, GFP_KERNEL);
+ if (unlikely(!data))
+ return -ENOMEM;
+
+ if(io_data-aio) {
+ size_t len = 0;
+ int i;
+ for (i=0; !io_data-read i io_data-nr_segs; i++) {
+ if (unlikely(copy_from_user(data[len],
The whole if-else-if-else is under a spin lock so you cannot
copy_from_user. This is why in original code copying was done prior to
this piece of code.
+ io_data-iovec[i].iov_base,
+ io_data-iovec[i].iov_len) != 0)) {
+ ret = -EFAULT;
+ goto error;
+ }
+ len += io_data-iovec[i].iov_len;
+ }
- ret = usb_ep_queue(ep-ep, req, GFP_ATOMIC);
+ req = usb_ep_alloc_request(ep-ep, GFP_KERNEL);
+ if(unlikely(!req))
+ goto error;
- spin_unlock_irq(epfile-ffs-eps_lock);
+ req-buf = data;
+ req-length = io_data-len;
- if (unlikely(ret 0)) {
- /* nop */
- } else if (unlikely(wait_for_completion_interruptible(done))) {
-
Re: Suspend issues with a LaCie USB hard disk connected
On Wed, 15 Jan 2014, Daniel Mack wrote:
Hi,
Sorry for the long, primarily holiday-related delay on this.
On 12/18/2013 09:46 PM, Alan Stern wrote:
On Wed, 18 Dec 2013, Daniel Mack wrote:
I'm facing an issue putting an embedded system to sleep while a Lacie
external USB hard disk is connected. Relevant kernel messages that occur
at the attempt are:
[ 13.834731] PM: Sending message for entering DeepSleep mode
[ 13.846575] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 13.858818] sd 0:0:0:0: [sda]
[ 13.862432] Result: hostbyte=0x00 driverbyte=0x08
[ 13.867349] sd 0:0:0:0: [sda]
[ 13.870626] Sense Key : 0x5 [current]
[ 13.874602] sd 0:0:0:0: [sda]
[ 13.877879] ASC=0x20 ASCQ=0x0
[ 13.885053] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns -5
[ 13.901130] PM: Device 0:0:0:0 failed to suspend async: error -5
[ 13.907507] PM: Some devices failed to suspend, or early wake event
detected
What happens is that in sd_sync_cache(), scsi_execute_req_flags()
returns 0x0802, so driver_byte(res) evaluates to DRIVER_SENSE and
host_byte(res) is DID_OK, which is an unhandled case that leads to -EIO
eventually.
I have admittedly not much clue about the SCSI layer, so I wonder what
would be the best way to fix this. Should DID_OK just be handled as
non-error condition in the switch? Should the suspend call chain ignore
such errors from sd_sync_cache()?
I'm open to suggestions and happy to test patches.
The Sense Key and ASC values indicate that the drive did not understand
the SYNCHRONIZE CACHE command. A usbmon trace would verify this; see
the instructions in Documentation/usb/usbmon.txt.
Assuming that really is what happened, we have to decide how to handle
the situation.
Ok, this is the usbmon trace that I captured when the system goes to
suspend with the USB storage media connected but unmounted:
cebe5e00 3629314504 S Bo:1:003:2 -115 31 = 55534243 1000
0a35 00
cebe5e00 3629315214 C Bo:1:003:2 0 31
cebe5e00 3629315413 S Bi:1:003:1 -115 13
cebe5e00 3629315492 C Bi:1:003:1 0 13 = 55534253 1000 01
That's the SYNCHRONIZE CACHE command, with an error return status.
cebe5e00 3629315571 S Bo:1:003:2 -115 31 = 55534243 1100 1200
8603 0012 00
cebe5e00 3629315606 C Bo:1:003:2 0 31
cecd4580 3629315681 S Bi:1:003:1 -115 18
cecd4580 3629315744 C Bi:1:003:1 0 18 = 7500 000a
2000
cebe5e00 3629315772 S Bi:1:003:1 -115 13
cebe5e00 3629315817 C Bi:1:003:1 0 13 = 55534253 1100 00
And that's the sense data, confirming SK=5 and ASC=20. This means the
drive doesn't understand the command.
There's more stuff later on in the usbmon trace that I don't
understand. But if everything else works okay, it won't matter.
FWIW, the following patch seems to work fine on our machines, but as I
said, I'm uncertain wrt to whether that's the right approach.
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 69725f7..ec99787 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1469,6 +1469,7 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
return 0;
switch (host_byte(res)) {
+ case DID_OK:
/* ignore errors due to racing a disconnection */
case DID_BAD_TARGET:
case DID_NO_CONNECT:
I don't think that is the right thing to do. Try this patch instead.
Alan Stern
Index: usb-3.13/drivers/scsi/sd.c
===
--- usb-3.13.orig/drivers/scsi/sd.c
+++ usb-3.13/drivers/scsi/sd.c
@@ -1463,8 +1463,8 @@ static int sd_sync_cache(struct scsi_dis
sd_print_sense_hdr(sdkp, sshdr);
/* we need to evaluate the error return */
if (scsi_sense_valid(sshdr)
- /* 0x3a is medium not present */
- sshdr.asc == 0x3a)
+ (sshdr.asc == 0x3a || /* medium not present */
+sshdr.asc == 0x20))/* invalid command */
/* this is no error here */
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend issues with a LaCie USB hard disk connected
Hi Alan, On 01/15/2014 06:19 PM, Alan Stern wrote: On Wed, 15 Jan 2014, Daniel Mack wrote: Hi, Sorry for the long, primarily holiday-related delay on this. On 12/18/2013 09:46 PM, Alan Stern wrote: On Wed, 18 Dec 2013, Daniel Mack wrote: I'm facing an issue putting an embedded system to sleep while a Lacie external USB hard disk is connected. Relevant kernel messages that occur at the attempt are: [ 13.834731] PM: Sending message for entering DeepSleep mode [ 13.846575] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 13.858818] sd 0:0:0:0: [sda] [ 13.862432] Result: hostbyte=0x00 driverbyte=0x08 [ 13.867349] sd 0:0:0:0: [sda] [ 13.870626] Sense Key : 0x5 [current] [ 13.874602] sd 0:0:0:0: [sda] [ 13.877879] ASC=0x20 ASCQ=0x0 [ 13.885053] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns -5 [ 13.901130] PM: Device 0:0:0:0 failed to suspend async: error -5 [ 13.907507] PM: Some devices failed to suspend, or early wake event detected What happens is that in sd_sync_cache(), scsi_execute_req_flags() returns 0x0802, so driver_byte(res) evaluates to DRIVER_SENSE and host_byte(res) is DID_OK, which is an unhandled case that leads to -EIO eventually. I have admittedly not much clue about the SCSI layer, so I wonder what would be the best way to fix this. Should DID_OK just be handled as non-error condition in the switch? Should the suspend call chain ignore such errors from sd_sync_cache()? I'm open to suggestions and happy to test patches. The Sense Key and ASC values indicate that the drive did not understand the SYNCHRONIZE CACHE command. A usbmon trace would verify this; see the instructions in Documentation/usb/usbmon.txt. Assuming that really is what happened, we have to decide how to handle the situation. Ok, this is the usbmon trace that I captured when the system goes to suspend with the USB storage media connected but unmounted: cebe5e00 3629314504 S Bo:1:003:2 -115 31 = 55534243 1000 0a35 00 cebe5e00 3629315214 C Bo:1:003:2 0 31 cebe5e00 3629315413 S Bi:1:003:1 -115 13 cebe5e00 3629315492 C Bi:1:003:1 0 13 = 55534253 1000 01 That's the SYNCHRONIZE CACHE command, with an error return status. cebe5e00 3629315571 S Bo:1:003:2 -115 31 = 55534243 1100 1200 8603 0012 00 cebe5e00 3629315606 C Bo:1:003:2 0 31 cecd4580 3629315681 S Bi:1:003:1 -115 18 cecd4580 3629315744 C Bi:1:003:1 0 18 = 7500 000a 2000 cebe5e00 3629315772 S Bi:1:003:1 -115 13 cebe5e00 3629315817 C Bi:1:003:1 0 13 = 55534253 1100 00 And that's the sense data, confirming SK=5 and ASC=20. This means the drive doesn't understand the command. Ok. There's more stuff later on in the usbmon trace that I don't understand. But if everything else works okay, it won't matter. The host controller tried to reset the port and the device, whatever that results in. You're right, that is unrelated. I don't think that is the right thing to do. Try this patch instead. [...] Index: usb-3.13/drivers/scsi/sd.c === --- usb-3.13.orig/drivers/scsi/sd.c +++ usb-3.13/drivers/scsi/sd.c @@ -1463,8 +1463,8 @@ static int sd_sync_cache(struct scsi_dis sd_print_sense_hdr(sdkp, sshdr); /* we need to evaluate the error return */ if (scsi_sense_valid(sshdr) - /* 0x3a is medium not present */ - sshdr.asc == 0x3a) + (sshdr.asc == 0x3a || /* medium not present */ + sshdr.asc == 0x20))/* invalid command */ /* this is no error here */ return 0; That seems to work equally well for me, thanks! Feel free to add when submitting: Reported-by: Sven Neumann s.neum...@raumfeld.com Tested-by: Daniel Mack zon...@gmail.com Thanks for your help! Daniel -- 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 issues: WD MyBook 1230 - reset SuperSpeed USB device
On Wed, 15 Jan 2014, Peter Palúch wrote: The interesting thing is that the same happens even if the drive is plugged into an USB 2.0 port in the same notebook: That is an important point. root@bach:~# dmesg -c usb 3-1.1: new high-speed USB device number 5 using ehci-pci usb 3-1.1: New USB device found, idVendor=1058, idProduct=1230 usb 3-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 usb 3-1.1: Product: My Book 1230 usb 3-1.1: Manufacturer: Western Digital usb 3-1.1: SerialNumber: 574D43344E30323438393836 usb-storage 3-1.1:1.0: USB Mass Storage device detected scsi10 : usb-storage 3-1.1:1.0 scsi 10:0:0:0: Direct-Access WD My Book 1230 1050 PQ: 0 ANSI: 6 scsi 10:0:0:1: Enclosure WD SES Device 1050 PQ: 0 ANSI: 6 sd 10:0:0:0: Attached scsi generic sg2 type 0 scsi 10:0:0:1: Attached scsi generic sg3 type 13 sd 10:0:0:0: [sdb] Spinning up disk... .ready sd 10:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) sd 10:0:0:0: [sdb] Write Protect is off sd 10:0:0:0: [sdb] Mode Sense: 53 00 10 08 sd 10:0:0:0: [sdb] No Caching mode page found sd 10:0:0:0: [sdb] Assuming drive cache: write through sd 10:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) sd 10:0:0:0: [sdb] No Caching mode page found sd 10:0:0:0: [sdb] Assuming drive cache: write through sdb: unknown partition table sd 10:0:0:0: [sdb] 732558336 4096-byte logical blocks: (3.00 TB/2.72 TiB) sd 10:0:0:0: [sdb] No Caching mode page found sd 10:0:0:0: [sdb] Assuming drive cache: write through sd 10:0:0:0: [sdb] Attached SCSI disk root@bach:~# time gdisk -l /dev/sdb GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: not present BSD: not present APM: not present GPT: not present Creating new GPT entries. Disk /dev/sdb: 732558336 sectors, 2.7 TiB Logical sector size: 4096 bytes Disk identifier (GUID): E2D26EE9-FC4F-49C8-94A7-92B599334779 Partition table holds up to 128 entries First usable sector is 6, last usable sector is 732558330 Partitions will be aligned on 256-sector boundaries Total free space is 732558325 sectors (2.7 TiB) Number Start (sector)End (sector) Size Code Name real0m31.631s user0m0.008s sys0m0.002s root@bach:~# dmesg usb 3-1.1: reset high-speed USB device number 5 using ehci-pci Any ideas or suggestions? Can you post a usbmon trace similar to the earlier one, but with the drive plugged into the USB-2 port? 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 (linux-stm) 1/2] usb: dwc3: fix kernel compilation in gadget mode
On Wed, Jan 15, 2014 at 04:36:25PM +0100, Giuseppe Condorelli wrote:
The following set of patches, from the mainline, were applied to the tree
(after reworking) to solve build time issues about implicit declaration
of irq function and on arguments number mismatch in given functions
(example: __dwc3_gadget_ep_enable).
[giuseppe.condore...@st.com: reworked patch to fit current gadget code)
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Giuseppe Condorelli giuseppe.condore...@st.com
wait, what ?
I don't remember seeing this patch ever been sent upstream. This patch
seems to be a merge of several other patches, none of which you
Authored, so how come you:
a) put yourself as author of the code; and
b) add my Signed-off-by without asking me permission for it ?
In fact, you have *never* authored any patch on the dwc3 driver (I just
checked). If you want to get your tree in sync with the code which is
mainline, you should be using git cherry-pick -x to make sure that you
maintain authorship and make it clear which commit you cherry-picked so
things can be tracked down.
Copyright law is a serious business, I wonder what other patches have
been taken from mainline, changed author and applied to your vendor
kernel with my SoB.
I will be very clear:
. Do *NOT* apply *any* patch you take from mainline with
yourself as author.
. Make sure to use git cherry-pick -xs and solve merge conflicts
where applicable.
. Do *NOT* use somebody else's {Signed-off,Acked,Tested,etc}-by
tags without their permission.
Patch below so other people see what ST has been doing.
---
drivers/usb/dwc3/core.h |1 +
drivers/usb/dwc3/gadget.c | 101
++---
2 files changed, 60 insertions(+), 42 deletions(-)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index e91ddf8..610875b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -705,6 +705,7 @@ struct dwc3 {
unsigneddelayed_status:1;
unsignedneeds_fifo_resize:1;
unsignedresize_fifos:1;
+ unsignedpullups_connected:1;
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index c0cc8f6..2c5f24b 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -433,7 +433,8 @@ static int dwc3_gadget_start_config(struct dwc3 *dwc,
struct dwc3_ep *dep)
static int dwc3_gadget_set_ep_config(struct dwc3 *dwc, struct dwc3_ep *dep,
const struct usb_endpoint_descriptor *desc,
- const struct usb_ss_ep_comp_descriptor *comp_desc)
+ const struct usb_ss_ep_comp_descriptor *comp_desc,
+ bool ignore)
{
struct dwc3_gadget_ep_cmd_params params;
@@ -443,6 +444,9 @@ static int dwc3_gadget_set_ep_config(struct dwc3 *dwc,
struct dwc3_ep *dep,
| DWC3_DEPCFG_MAX_PACKET_SIZE(usb_endpoint_maxp(desc))
| DWC3_DEPCFG_BURST_SIZE(dep-endpoint.maxburst);
+ if (ignore)
+ params.param0 |= DWC3_DEPCFG_IGN_SEQ_NUM;
+
params.param1 = DWC3_DEPCFG_XFER_COMPLETE_EN
| DWC3_DEPCFG_XFER_NOT_READY_EN;
@@ -500,7 +504,8 @@ static int dwc3_gadget_set_xfer_resource(struct dwc3
*dwc, struct dwc3_ep *dep)
*/
static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
const struct usb_endpoint_descriptor *desc,
- const struct usb_ss_ep_comp_descriptor *comp_desc)
+ const struct usb_ss_ep_comp_descriptor *comp_desc,
+ bool ignore)
{
struct dwc3 *dwc = dep-dwc;
u32 reg;
@@ -512,7 +517,7 @@ static int __dwc3_gadget_ep_enable(struct dwc3_ep *dep,
return ret;
}
- ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc);
+ ret = dwc3_gadget_set_ep_config(dwc, dep, desc, comp_desc, ignore);
if (ret)
return ret;
@@ -658,7 +663,7 @@ static int dwc3_gadget_ep_enable(struct usb_ep *ep,
dev_vdbg(dwc-dev, Enabling %s\n, dep-name);
spin_lock_irqsave(dwc-lock, flags);
- ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc);
+ ret = __dwc3_gadget_ep_enable(dep, desc, ep-comp_desc, false);
spin_unlock_irqrestore(dwc-lock, flags);
return ret;
@@ -1364,8 +1369,10 @@ static void dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on)
if (dwc-revision = DWC3_REVISION_194A)
reg = ~DWC3_DCTL_KEEP_CONNECT;
reg |= DWC3_DCTL_RUN_STOP;
+ dwc-pullups_connected = true;
} else {
reg = ~DWC3_DCTL_RUN_STOP;
+ dwc-pullups_connected = false;
}
dwc3_writel(dwc-regs, DWC3_DCTL, reg);
@@ -1405,6 +1412,32 @@
Re: [PATCH v6 1/2] ohci-platform: Add support for devicetree instantiation
Hi,
On 01/15/2014 05:30 PM, Alan Stern wrote:
On Wed, 15 Jan 2014, Hans de Goede wrote:
+static int ohci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk, ret;
+
+ for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++) {
You fixed this one...
@@ -125,13 +225,22 @@ static int ohci_platform_remove(struct platform_device
*dev)
{
struct usb_hcd *hcd = platform_get_drvdata(dev);
struct usb_ohci_pdata *pdata = dev_get_platdata(dev-dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk;
usb_remove_hcd(hcd);
- usb_put_hcd(hcd);
if (pdata-power_off)
pdata-power_off(dev);
+ for (clk = 0; priv-clks[clk] clk OHCI_MAX_CLKS; clk++)
but not this one. :-( Same for the ehci-platform patch.
Oops, sorry about that, v7 coming up.
In fact, it might be easier to make this loop go backward, like
you do in the *_platform_power_off routines.
I prefer keep doing things forward here, the backward loop in
power_off is because the disable_unprepare must be done in reverse
order if the prepare_enable calls.
Is there a devm-type routine that will take care of all this for you?
Nope, the downside of getting the clocks by index rather then by name
is that there are no devm routines for that.
Regards,
Hans
--
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: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Hi David, David Laight david.lai...@aculab.com writes: I tried current 3.13.0-rc8 w/ 35773dac5f86 reverted and the result is the same: That patch only affects an error code and stops the fs code retrying for ever. Are you sure? ... Does everything work if you comment out the code in xhci-ring.c that adds NOP TRBs to the ring end in order to stop the LINK TRB appearing in the middle of a TB. The ethernet code needs it, but the disk transfers are (probably) aligned such that they don't. ... AFAICT, this is exactly what commit 35773dac5f86 does and reverting it does not help. If I am mistaken, can you point which part you want me to remove in the code to test? I am slowly starting to see a bisect session coming ;-) Cheers, a+ -- 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 v7 1/2] ohci-platform: Add support for devicetree instantiation
Add support for ohci-platform instantiation from devicetree, including
optionally getting clks and a phy from devicetree, and enabling / disabling
those on power_on / off.
This should allow using ohci-platform from devicetree in various cases.
Specifically after this commit it can be used for the ohci controller found
on Allwinner sunxi SoCs.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 22 +++
drivers/usb/host/ohci-platform.c | 164 ++---
2 files changed, 162 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-ohci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
b/Documentation/devicetree/bindings/usb/usb-ohci.txt
new file mode 100644
index 000..f9d6c73
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -0,0 +1,22 @@
+USB OHCI controllers
+
+Required properties:
+- compatible : usb-ohci
+- reg : ohci controller register range (address and length)
+- interrupts : ohci controller interrupt
+
+Optional properties:
+- clocks : a list of phandle + clock specifier pairs
+- phys : phandle + phy specifier pair
+- phy-names : usb
+
+Example:
+
+ ohci0: ohci@0x01c14400 {
+ compatible = allwinner,sun4i-a10-ohci, usb-ohci;
+ reg = 0x01c14400 0x100;
+ interrupts = 64;
+ clocks = usb_clk 6, ahb_gates 2;
+ phys = usbphy 1;
+ phy-names = usb;
+ };
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index f351ff5..b2d0e1e 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -3,6 +3,7 @@
*
* Copyright 2007 Michael Buesch m...@bues.ch
* Copyright 2011-2012 Hauke Mehrtens ha...@hauke-m.de
+ * Copyright 2014 Hans de Goede hdego...@redhat.com
*
* Derived from the OCHI-SSB driver
* Derived from the OHCI-PCI driver
@@ -14,11 +15,14 @@
* Licensed under the GNU/GPL. See COPYING for details.
*/
+#include linux/clk.h
+#include linux/dma-mapping.h
#include linux/hrtimer.h
#include linux/io.h
#include linux/kernel.h
#include linux/module.h
#include linux/err.h
+#include linux/phy/phy.h
#include linux/platform_device.h
#include linux/usb/ohci_pdriver.h
#include linux/usb.h
@@ -27,6 +31,13 @@
#include ohci.h
#define DRIVER_DESC OHCI generic platform driver
+#define OHCI_MAX_CLKS 3
+#define hcd_to_ohci_priv(h) ((struct ohci_platform_priv *)hcd_to_ohci(h)-priv)
+
+struct ohci_platform_priv {
+ struct clk *clks[OHCI_MAX_CLKS];
+ struct phy *phy;
+};
static const char hcd_name[] = ohci-platform;
@@ -48,11 +59,67 @@ static int ohci_platform_reset(struct usb_hcd *hcd)
return ohci_setup(hcd);
}
+static int ohci_platform_power_on(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk, ret;
+
+ for (clk = 0; clk OHCI_MAX_CLKS priv-clks[clk]; clk++) {
+ ret = clk_prepare_enable(priv-clks[clk]);
+ if (ret)
+ goto err_disable_clks;
+ }
+
+ if (priv-phy) {
+ ret = phy_init(priv-phy);
+ if (ret)
+ goto err_disable_clks;
+
+ ret = phy_power_on(priv-phy);
+ if (ret)
+ goto err_exit_phy;
+ }
+
+ return 0;
+
+err_exit_phy:
+ phy_exit(priv-phy);
+err_disable_clks:
+ while (--clk = 0)
+ clk_disable_unprepare(priv-clks[clk]);
+
+ return ret;
+}
+
+static void ohci_platform_power_off(struct platform_device *dev)
+{
+ struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct ohci_platform_priv *priv = hcd_to_ohci_priv(hcd);
+ int clk;
+
+ if (priv-phy) {
+ phy_power_off(priv-phy);
+ phy_exit(priv-phy);
+ }
+
+ for (clk = OHCI_MAX_CLKS - 1; clk = 0; clk--)
+ if (priv-clks[clk])
+ clk_disable_unprepare(priv-clks[clk]);
+}
+
static struct hc_driver __read_mostly ohci_platform_hc_driver;
static const struct ohci_driver_overrides platform_overrides __initconst = {
- .product_desc = Generic Platform OHCI controller,
- .reset =ohci_platform_reset,
+ .product_desc = Generic Platform OHCI controller,
+ .reset =ohci_platform_reset,
+ .extra_priv_size = sizeof(struct ohci_platform_priv),
+};
+
+static struct usb_ohci_pdata ohci_platform_defaults = {
+ .power_on = ohci_platform_power_on,
+ .power_suspend =ohci_platform_power_off,
+ .power_off =ohci_platform_power_off,
};
static int ohci_platform_probe(struct platform_device *dev)
@@ -60,17 +127,23 @@ static int
[PATCH v7 2/2] ehci-platform: Add support for clks and phy passed through devicetree
Currently ehci-platform is only used in combination with devicetree when used
with some Via socs. By extending it to (optionally) get clks and a phy from
devicetree, and enabling / disabling those on power_on / off, it can be used
more generically. Specifically after this commit it can be used for the
ehci controller on Allwinner sunxi SoCs.
Since ehci-platform is intended to handle any generic enough non pci ehci
device, add a usb-ehci compatibility string.
There already is a usb-ehci device-tree bindings document, update this
with clks and phy bindings info.
Although actually quite generic so far the via,vt8500 compatibilty string
had its own bindings document. Somehow we even ended up with 2 of them. Since
these provide no extra information over the generic usb-ehci documentation,
this patch removes them.
The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
2 drivers claiming the same compatibility string getting build on ppc.
Signed-off-by: Hans de Goede hdego...@redhat.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 25 +++-
.../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 ---
.../devicetree/bindings/usb/vt8500-ehci.txt| 12 --
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ehci-platform.c | 149 +
5 files changed, 142 insertions(+), 60 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index fa18612..fad10f3 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -7,13 +7,14 @@ Required properties:
(debug-port or other) can be also specified here, but only after
definition of standard EHCI registers.
- interrupts : one EHCI interrupt should be described here.
-If device registers are implemented in big endian mode, the device
-node should have big-endian-regs property.
-If controller implementation operates with big endian descriptors,
-big-endian-desc property should be specified.
-If both big endian registers and descriptors are used by the controller
-implementation, big-endian property can be specified instead of having
-both big-endian-regs and big-endian-desc.
+
+Optional properties:
+ - big-endian-regs : boolean, set this for hcds with big-endian registers
+ - big-endian-desc : boolean, set this for hcds with big-endian descriptors
+ - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
+ - clocks : a list of phandle + clock specifier pairs
+ - phys : phandle + phy specifier pair
+ - phy-names : usb
Example (Sequoia 440EPx):
ehci@e300 {
@@ -23,3 +24,13 @@ Example (Sequoia 440EPx):
reg = 0 e300 90 0 e390 70;
big-endian;
};
+
+Example (Allwinner sun4i A10 SoC):
+ ehci0: ehci@0x01c14000 {
+ compatible = allwinner,sun4i-a10-ehci, usb-ehci;
+ reg = 0x01c14000 0x100;
+ interrupts = 39;
+ clocks = ahb_gates 1;
+ phys = usbphy 1;
+ phy-names = usb;
+ };
diff --git a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
deleted file mode 100644
index 17b3ad1..000
--- a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 EHCI Controller
--
-
-Required properties:
-- compatible : via,vt8500-ehci
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : ehci controller interrupt
-
-Example:
-
- ehci@d8007900 {
- compatible = via,vt8500-ehci;
- reg = 0xd8007900 0x200;
- interrupts = 43;
- };
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
deleted file mode 100644
index 5fb8fd6..000
--- a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
-
-Required properties:
- - compatible: Should be via,vt8500-ehci or wm,prizm-ehci.
- - reg: Address range of the ehci registers. size should be 0x200
- - interrupts: Should contain the ehci interrupt.
-
-usb: ehci@D8007100 {
- compatible = wm,prizm-ehci, usb-ehci;
- reg = 0xD8007100 0x200;
- interrupts = 1;
-};
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a9707da..e28cbe0 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -255,6 +255,7 @@ config
[PATCH v7 0/2] ohci and ehci-platform clks, phy and dt support
Hi All, This version of my ohci and ehci-platform clks, phy and dt support patch-set, really fixes the 2 small bugs Alan found. Regards, Hans -- 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 0/2] ohci and ehci-platform clks, phy and dt support
On Wed, 15 Jan 2014, Hans de Goede wrote: Hi All, This version of my ohci and ehci-platform clks, phy and dt support patch-set, really fixes the 2 small bugs Alan found. All okay -- this time I can't find anything to complain about. :-) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb audio breaks ohci-pci
On Wed, 15 Jan 2014, Dennis New wrote: When listening to my usb-bluetooth audio headset, the usb subsystem (I think) on my laptop crashes, the bluetooth/audio is lost, and my mplayer program is left in an uninterruptible sleep (D) state and cannot be killed. The only way to get my usb-audio working again is to reboot. ... The crash is difficult to reproduce, sometimes it can occur after a few minutes of a clean boot, and sometimes after a few days. After the audio/usb abruptly stops, the syslog simply says: kernel: ALSA sound/usb/endpoint.c:501 timeout: still 3 active urbs on EP #3 And then after a few minutes (after enabling some kernel debugging options), I get some call traces of the hung task(s), which have ohci_urb_dequeue in common. http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash1.log http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash2.log http://dennisn.dyndns.org/guest/pubstuff/debug-usbaudio/crash3.log The logs show that the khubd thread is hung, waiting for the ohci-hcd driver to finish cancelling a transfer. The problem is not with my device, since it occurs with another identical piece of hardware. It maybe be a problem with my laptop, since my friend does not seem to be experiencing this problem, although her laptop does not use ohci-pci. My usb controllers are: 1002:4374 00:13.0 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB Host Controller (prog-if 10 [OHCI]) 1002:4375 00:13.1 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB Host Controller (prog-if 10 [OHCI]) 1002:4373 00:13.2 USB controller: Advanced Micro Devices [AMD] nee ATI IXP SB400 USB2 Host Controller (prog-if 20 [EHCI]) Your first step in attacking this problem should be to use the most up-to-date kernel available, which at the moment is 3.13-rc8. Be sure to enable CONFIG_FRAME_POINTER along with CONFIG_USB_DEBUG. If the problem occurs again, collect a copy of the output from the dmesg command (_not_ a copy of the system log). Then go into /sys/kernel/debug/usb/ohci and collect copies of all the files in the two subdirectories. It may be necessary to apply some debugging patches to get more information. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] Just the essential port power control fixes for 3.14
On Tue, 2014-01-14 at 15:22 -0800, Sarah Sharp wrote:
On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote:
Alan, Sarah,
This revision boils down the port power control fixes to the
bare minimum to get the implementation functional and reliable.
Data structure changes are constrained to struct usb_port and
gone are the clumsier attempts at wider reworks from v1 [1] and
v2 [2]. No device model changes to consider or changes to the
meaning of 'runtime_status' for port devices. Three disconnect
bugs are fixed:
1/ Superspeed devices downgrade to their hi-speed connection: fix this by
preventing superspeed poweroff until the peer port is suspended. See
patch 5.
I've been testing these a bit, and run into some unexpected behavior.
First, just checking: what do you expect to happen if a USB 2.0 port has
port power off enabled, but its peer USB 3.0 port has power off
disabled? I had expected that the port would remained powered on, but
this does not seem to be what the code actually does.
Say I have one xHCI host that registers bus 1 (USB 2.0) and bus 2 (USB
3.0). Port 1 on both buses are peer ports, and both ports have power
off disabled. Then I do the following:
1. Plug in a USB mouse into the USB 2.0 port.
2. Enable port power off for the USB 2.0 port.
4. Enable suspend for the mouse. Port should be prevented from being
powered off, since usbhid enables remote wakeup for the device, and
the port's runtime_status does reflect that it's active.
3. Unbind usbhid.
5. Check that the USB 2.0 port's runtime_status is 'suspended' while the
USB 3.0 port's runtime_status is 'active'. (Note, at this point,
according to my assumption, the port should still be powered, but
it's not.)
6. Unplug the USB mouse. No disconnect event observed.
7. Disable port power off for the USB 2.0 port. Still no disconnect.
8. Run `sudo lsusb` and note that the mouse is still listed in lsusb
output. Further, the sysfs directories are still there. The device
remains even after running `sudo lsusb -v` (which should trigger a
get port status for the roothub, where the disconnect should be
noticed.
A command line history of that procedure is attached.
It seems like there needs to be a way to detect whether a USB device is
really disconnected after the port is powered back on. ISTR asking
Tianyu to fix this, but I'm not sure if it ever did get fixed.
Actually, this appears to be behaving as intended. The bug is in the
test, here:
echo 1-1 usb1/1-0\:1.0/port1/device/driver/unbind
That unbinds the usb_device from the usb_generic_driver and removes the
ability of the usb core to resume the device. Without that ability we
will never notice the disconnect since usb_resume() will hit:
/* Can't resume it if it doesn't have a driver. */
if (udev-dev.driver == NULL) {
status = -ENOTCONN;
goto done;
}
The documentation does cover this, but I think it can be more explicit
about the pitfalls and consequences. I have folded in the following
change:
diff --git a/Documentation/usb/power-management.txt
b/Documentation/usb/power-management.txt
index 94230439fe9c..2ceea37d8fbc 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -587,7 +587,14 @@ suspended.
Note, some interface devices/drivers do not support autosuspend. Userspace may
need to unbind the interface drivers before the usb_device will suspend. An
-unbound interface device is suspended by default.
+unbound interface device is suspended by default. When unbinding, be careful
+to unbind interface drivers, not the driver of the parent usb device. Also,
+leave hub interface drivers bound. If the driver for the usb device (not
+interface) is unbound the kernel is no longer able to resume the device. If a
+hub interface driver is unbound, control of its child ports is lost and all
+attached child-devices will disconnect. A good rule of thumb is that if the
+'driver/module' link for a device points to /sys/module/usbcore then unbinding
+it will interfere with port power control.
Example of the relevant files for port power control.
@@ -599,7 +606,10 @@ Example of the relevant files for port power control.
/sys/bus/devices/usb2/2-0:1.0/port1/power/pm_qos_no_power_off
/sys/bus/devices/usb2/2-0:1.0/port1/device/power/control
- /sys/bus/devices/usb2/2-0:1.0/port1/device/intf/driver/unbind
+ /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:intf0/driver/unbind
+ /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:intf1/driver/unbind
+ ...
+ /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:intfN/driver/unbind
In addition to these files some ports may have a 'peer' link to a port on
another hub. The expectation is that all superspeed ports have a
---
When the usb_device stays bound we do attempt recovery,
Re: [PATCH] ARM: sunxi: Add driver for sunxi usb phy
Hi Hans,
Please keep me in CC for all the Allwinner-related patches.
On Tue, Jan 14, 2014 at 11:58:25PM +0100, Hans de Goede wrote:
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of registers. Besides this there are also some other
phy related bits which need poking, which are per phy, but shared between the
ohci and ehci controllers, so these are also controlled from this new phy
driver.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-sun4i-usb.c| 318
+
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
create mode 100644 drivers/phy/phy-sun4i-usb.c
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000..6c54b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,26 @@
+Allwinner sun4i USB PHY
+---
+
+Required properties:
+- compatible : should be one of allwinner,sun4i-a10-usb-phy,
It is sun4i-usb-phy.
+ allwinner,sun5i-a13-usb-phy or allwinner,sun7i-a20-usb-phy
+- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
+ 1 pair for the pmu-irq register of each hcd
In which order they should be set? Maybe you should use reg-names here
to clarify things. From that documentation, I have no idea how I
should put the values if I just want the common stuff and the (for
example) usb1 configuration.
+- #phy-cells : from the generic phy bindings, must be 1
+
+Optional properties:
+- clocks : phandle + clock specifier for the phy clock
+- clock-names : usb_phy
+- resets : a list of phandle + reset specifier pairs
+- reset-names : usb0_reset, usb1_reset, and / or usb2_reset
+
+Example:
+ usbphy: phy@0x01c13400 {
+ #phy-cells = 1;
+ compatible = allwinner,sun4i-a10-usb-phy;
+ reg = 0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4;
If you prefer not to use reg-names after all, please put a comment
stating what each pair correspond to.
+ clocks = usb_clk 8;
+ clock-names = usb_phy;
+ resets = usb_clk 1, usb_clk 2;
+ reset-names = usb1_reset, usb2_reset;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..dcce4cf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_SUN4I_USB
+ tristate Allwinner sunxi SoC USB PHY driver
+ depends on ARCH_SUNXI
+ select GENERIC_PHY
+ help
+ Enable this to support the transceiver that is part of Allwinner
+ sunxi SoCs.
+
+ This driver controls the entire USB PHY block, both the USB OTG
+ parts, as well as the 2 regular USB 2 host PHYs.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..e9e82f0 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
+obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
new file mode 100644
index 000..a15ecc1
--- /dev/null
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -0,0 +1,318 @@
+/*
+ * Allwinner sun4i USB phy driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Based on code from
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ *
+ * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki s.nawro...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
Re: [PATCH v3 03/10] usb: find internal hub tier mismatch via acpi
On Tue, Jan 14, 2014 at 1:47 PM, Dan Williams dan.j.willi...@intel.com wrote: On Tue, Jan 14, 2014 at 1:42 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote: On Mon, 13 Jan 2014, Sarah Sharp wrote: On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote: I haven't looked at this too closely, but what happens if: - the USB 2.0 roothub is registered - userspace immediately sets autosuspend_delay to zero and pm_qos_no_port_poweroff to zero - usb_acpi_find_device changes the connect_type to something other than unknown - before usb_acpi_check_port_peer() is called, the port is suspended Or that call finishes, but no peer port is set yet, because the USB 3.0 roothub isn't registered yet. The USB 2.0 bus can be suspended before the USB 3.0 bus has finished registering, as I've seen from this thread: http://marc.info/?l=linux-usbm=138914518219334w=2 It's always possible for xhci-hcd to prevent the USB-2 root hub from being suspended by calling pm_runtime_get_noresume. The corresponding _put can be done after the USB-3 root hub has been registered. Sure, it's on my todo list to fix that. I just wondered if there were other race conditions present, given that I could find one off the top of my head. At least as far as this patchset is concerned there is no race/requirement to hold off usb-2 root hub power management. The patchset expects usb2 ports to suspend independent of their peer usb3 port state, and forces usb3 ports to always resume before usb2 peers. Let me qualify that, there is no requirement to hold off usb-2 root hub power management *unless* the root hub fails to maintain VBUS like an external hub. The patchset assumes that ACPI port power off needs to be called for both ports in a peer before VBUS goes away. My test platform seems to enforce that, but we may need to quirk platforms that violate this assumption. For that quirk we would need to disable port poweroff until ACPI enumeration completed. -- 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 2/2] ehci-platform: Add support for clks and phy passed through devicetree
2014/1/15 Hans de Goede hdego...@redhat.com: Currently ehci-platform is only used in combination with devicetree when used with some Via socs. By extending it to (optionally) get clks and a phy from devicetree, and enabling / disabling those on power_on / off, it can be used more generically. Specifically after this commit it can be used for the ehci controller on Allwinner sunxi SoCs. Since ehci-platform is intended to handle any generic enough non pci ehci device, add a usb-ehci compatibility string. There already is a usb-ehci device-tree bindings document, update this with clks and phy bindings info. Although actually quite generic so far the via,vt8500 compatibilty string had its own bindings document. Somehow we even ended up with 2 of them. Since these provide no extra information over the generic usb-ehci documentation, this patch removes them. The ehci-ppc-of.c driver also claims the usb-ehci compatibility string, even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid 2 drivers claiming the same compatibility string getting build on ppc. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Alan Stern st...@rowland.harvard.edu --- Documentation/devicetree/bindings/usb/usb-ehci.txt | 25 +++- .../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 --- .../devicetree/bindings/usb/vt8500-ehci.txt| 12 -- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-platform.c | 149 + 5 files changed, 142 insertions(+), 60 deletions(-) delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index fa18612..fad10f3 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -7,13 +7,14 @@ Required properties: (debug-port or other) can be also specified here, but only after definition of standard EHCI registers. - interrupts : one EHCI interrupt should be described here. -If device registers are implemented in big endian mode, the device -node should have big-endian-regs property. -If controller implementation operates with big endian descriptors, -big-endian-desc property should be specified. -If both big endian registers and descriptors are used by the controller -implementation, big-endian property can be specified instead of having -both big-endian-regs and big-endian-desc. + +Optional properties: + - big-endian-regs : boolean, set this for hcds with big-endian registers + - big-endian-desc : boolean, set this for hcds with big-endian descriptors + - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc These properties are specified here in the documentation binding, but they are not handled by the ehci-platform driver, is that intentional? Fairly quickly people will start adopting the ehci-platform driver on DT-aware platforms, so it would be nice to support those 2 (3) properties right away? -- Florian -- 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: usbnet / ax88179_178a: Panic in usb_hcd_map_urb_for_dma
On Mon, Jan 13, 2014 at 9:26 PM, David Laight david.lai...@aculab.com wrote: I believe all processing use the urb-num_sgs field to limit the number of entries. Common interfaces like dma_map_sg() and for_each_sg() limit their processing to nents entries, and the USB code use the value of urb-num_sgs for this parameter. Which mostly means that the sg_xxx functions are doing a whole load of unnecessary instructions and memory accesses... This probably has a lot to do with the significant difference in the cpu use for the usb3 and 'normal' ethernet interfaces. While each bit doesn't seem significant, they soon add up. If you plan to remove the 'nents' parameter, I am wondering if it is a good idea, because sg_nents() should be more heavy. Not mention sometimes the callers just want to map/unmap part of entries. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: USB Gadget Patches
Thanks Balbi for reply. I was not aware of this. Please accept my apologize. Thanks SuresH -Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Wednesday, January 15, 2014 7:18 PM To: Gupta Suresh-B42813 Cc: ba...@ti.com; Greg Kroah-Hartman; Linux USB Mailing List Subject: Re: USB Gadget Patches Hi, On Wed, Jan 15, 2014 at 10:12:44AM +, suresh.gu...@freescale.com wrote: Please pick my below patches http://www.spinics.net/lists/linux-usb/msg97752.html http://www.spinics.net/lists/linux-usb/msg97753.html as I have already said, my tree is closed for v3.14, so is Greg's. You'll get no special treatment for sending a private email demanding that your patches get applied. Wait until v3.15 -- balbi -- 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] ARM: sunxi: Add driver for sunxi usb phy
Hi,
On Wednesday 15 January 2014 09:18 PM, Hans de Goede wrote:
Hi,
On 01/15/2014 04:00 PM, Kishon Vijay Abraham I wrote:
On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of registers. Besides this there are also some other
phy related bits which need poking, which are per phy, but shared between
the
ohci and ehci controllers, so these are also controlled from this new phy
driver.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-sun4i-usb.c| 318
+
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
create mode 100644 drivers/phy/phy-sun4i-usb.c
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000..6c54b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,26 @@
+Allwinner sun4i USB PHY
+---
+
+Required properties:
+- compatible : should be one of allwinner,sun4i-a10-usb-phy,
+ allwinner,sun5i-a13-usb-phy or allwinner,sun7i-a20-usb-phy
+- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
+ 1 pair for the pmu-irq register of each hcd
+- #phy-cells : from the generic phy bindings, must be 1
+
+Optional properties:
+- clocks : phandle + clock specifier for the phy clock
+- clock-names : usb_phy
+- resets : a list of phandle + reset specifier pairs
+- reset-names : usb0_reset, usb1_reset, and / or usb2_reset
+
+Example:
+usbphy: phy@0x01c13400 {
+#phy-cells = 1;
+compatible = allwinner,sun4i-a10-usb-phy;
+reg = 0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4;
+clocks = usb_clk 8;
+clock-names = usb_phy;
+resets = usb_clk 1, usb_clk 2;
+reset-names = usb1_reset, usb2_reset;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..dcce4cf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_SUN4I_USB
+tristate Allwinner sunxi SoC USB PHY driver
+depends on ARCH_SUNXI
+select GENERIC_PHY
+help
+ Enable this to support the transceiver that is part of Allwinner
+ sunxi SoCs.
+
+ This driver controls the entire USB PHY block, both the USB OTG
+ parts, as well as the 2 regular USB 2 host PHYs.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..e9e82f0 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)+=
phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
+obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
new file mode 100644
index 000..a15ecc1
--- /dev/null
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -0,0 +1,318 @@
+/*
+ * Allwinner sun4i USB phy driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * Based on code from
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ *
+ * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki s.nawro...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/phy/phy.h
+#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/reset.h
+
+#define REG_ISCR0x00
+#define REG_PHYCTL0x04
+#define REG_PHYBIST0x08
+#define REG_PHYTUNE0x0c
+
+#define SUNXI_AHB_ICHR8_ENBIT(10)
+#define SUNXI_AHB_INCR4_BURST_ENBIT(9)
+#define
Re: [linux-sunxi] Re: [PATCH] ARM: sunxi: Add driver for sunxi usb phy
Hi Hans,
On Wed, Jan 15, 2014 at 11:48 PM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 01/15/2014 04:00 PM, Kishon Vijay Abraham I wrote:
On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
[...]
+static int sun4i_usb_phy_init(struct phy *_phy)
+{
+ struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
+ struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ int ret;
+
+ ret = clk_prepare_enable(data-clk);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(phy-reset);
+ if (ret) {
+ clk_disable_unprepare(data-clk);
+ return ret;
+ }
+
+ /* Adjust PHY's magnitude and rate */
+ sun4i_usb_phy_write(phy, 0x20, 0x14, 5);
No magic values. Use macros instead.
We don't have docs, these values come from the Android code (and the comment
above has been translated from Chinese). I can make up some random
macros for this, but seems counter-productive, it seems best to just leave
this as magic until the day we actually have documentation and thus can use
defines with the proper register names, etc.
We have some names for the registers from Allwinner code:
https://github.com/linux-sunxi/linux-sunxi/blob/lichee-3.0.8-sun4i/drivers/usb/sun4i_usb/usbc/usbc_phy.c#L39
And the comments in the file also suggests valid values for some of them,
though the actual code in the sunxi usb drivers (not the otg one) don't
seem to match.
[...]
Cheers
ChenYu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/10] usb: chipidea: host:vbus control change for OTG HNP.
Hi
-Original Message-
From: Peter Chen [mailto:peter.c...@freescale.com]
Sent: Thursday, January 09, 2014 4:00 PM
To: Li Jun-B47624
Cc: ba...@ti.com; linux-usb@vger.kernel.org
Subject: Re: [PATCH 03/10] usb: chipidea: host:vbus control change for OTG HNP.
A blank space between host: and vbus
[Li Jun] OK, I will update.
Reply-To:
In-Reply-To: 1389171985-9282-4-git-send-email-b47...@freescale.com
On Wed, Jan 08, 2014 at 05:06:18PM +0800, Li Jun wrote:
Leave vbus on/off hanlded by OTG fsm if in OTG mode, init OTG port number.
^and
What does the OTG port number mean? It is always 1?
If there are two OTG port, how about the value of the otg_port?
[Li Jun] Here the OTG port number means the USB host port number to which a
device attaches, which is 1 based, since HNP does not support hub(i.e. no
intervening hub between the Host and the B-device), and only one OTG port per
one OTG controller, so I set it to be 1. If there are 2 OTG controllers in one
device, each OTG port will work the same way.
Signed-off-by: Li Jun b47...@freescale.com
---
drivers/usb/chipidea/host.c | 13 +
drivers/usb/chipidea/host.h |9 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index 526cd77..bba54c3 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -66,7 +66,7 @@ static int host_start(struct ci_hdrc *ci)
ehci-has_hostpc = ci-hw_bank.lpm;
ehci-has_tdi_phy_lpm = ci-hw_bank.lpm;
- if (ci-platdata-reg_vbus) {
+ if ((ci-platdata-reg_vbus) !ci_host_is_otg(ci)) {
The first () is not needed.
[Li Jun] I will remove it.
Any ways to unify the vbus controller for both OTG and non-OTG cases?
[Li Jun] Both cases have diff V-bus handling, in OTG HNP case, V-bus is
controlled by HNP fsm, it's not always on when in host mode.
ret = regulator_enable(ci-platdata-reg_vbus);
if (ret) {
dev_err(ci-dev,
@@ -79,8 +79,13 @@ static int host_start(struct ci_hdrc *ci)
ret = usb_add_hcd(hcd, 0, 0);
if (ret)
goto disable_reg;
- else
+ else {
ci-hcd = hcd;
+ if (ci_host_is_otg(ci)) {
+ ci-transceiver-otg-host = hcd-self;
+ ci-transceiver-otg-host-otg_port = 1;
+ }
+ }
if (ci-platdata-flags CI_HDRC_DISABLE_STREAMING)
hw_write(ci, OP_USBMODE, USBMODE_CI_SDIS, USBMODE_CI_SDIS); @@
-88,7 +93,7 @@ static int host_start(struct ci_hdrc *ci)
return ret;
disable_reg:
- if (ci-platdata-reg_vbus)
+ if ((ci-platdata-reg_vbus) !ci_host_is_otg(ci))
regulator_disable(ci-platdata-reg_vbus);
put_hcd:
@@ -104,7 +109,7 @@ static void host_stop(struct ci_hdrc *ci)
if (hcd) {
usb_remove_hcd(hcd);
usb_put_hcd(hcd);
- if (ci-platdata-reg_vbus)
+ if ((ci-platdata-reg_vbus) !ci_host_is_otg(ci))
regulator_disable(ci-platdata-reg_vbus);
}
}
diff --git a/drivers/usb/chipidea/host.h b/drivers/usb/chipidea/host.h
index 5707bf3..f98d084 100644
--- a/drivers/usb/chipidea/host.h
+++ b/drivers/usb/chipidea/host.h
@@ -6,6 +6,15 @@
int ci_hdrc_host_init(struct ci_hdrc *ci); void
ci_hdrc_host_destroy(struct ci_hdrc *ci);
+static inline bool ci_host_is_otg(struct ci_hdrc *ci) { #ifdef
+CONFIG_USB_OTG_FSM
CONFIG_USB_OTG?
[Li Jun] Both can work for me, CONFIG_USB_OTG_FSM is more dedicated for OTG fsm.
+ return (ci-is_otg) (ci-platdata-dr_mode == USB_DR_MODE_OTG);
Why ci-platdata-dr_mode == USB_DR_MODE_OTG is needed to judge if a host port
is OTG port?
[Li Jun] This is used to judge if a OTG port is working in OTG mode with HNP
enabled.
Besides, if the user chooses dr_mode as non USB_DR_MODE_OTG, and kernel
configuration chooses CONFIG_USB_OTG, the port should responds as host only
port. DT entries can always override kernel configuration.
[Li Jun] yes, if dr_mode is not USB_DR_MODE_OTG, OTG port will work in
host-only or device-only mode, even CONFIG_USB_OTG_FSM is selected.
+#else
+ return false;
+#endif
+}
+
#else
static inline int ci_hdrc_host_init(struct ci_hdrc *ci)
--
1.7.8
--
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
