Re: [PATCH v2 1/6] usb: otg: Add an API to bind the USB controller and PHY
Hi,
On Saturday 02 February 2013 02:43 AM, Marc Kleine-Budde wrote:
On 01/25/2013 03:33 AM, Kishon Vijay Abraham I wrote:
In order to support platforms which has multiple PHY's (of same type) and
which has multiple USB controllers, a new design is adopted wherin the binding
information (between the PHY and the USB controller) should be passed to the
PHY library from platform specific file (board file).
So added a new API to pass the binding information.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/otg/otg.c | 37 +
include/linux/usb/phy.h | 22 ++
2 files changed, 59 insertions(+)
diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
index a30c041..8e756d9 100644
--- a/drivers/usb/otg/otg.c
+++ b/drivers/usb/otg/otg.c
@@ -18,6 +18,7 @@
#include
static LIST_HEAD(phy_list);
+static LIST_HEAD(phy_bind_list);
static DEFINE_SPINLOCK(phy_lock);
static struct usb_phy *__usb_find_phy(struct list_head *list,
@@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
}
EXPORT_SYMBOL(usb_remove_phy);
+/**
+ * usb_bind_phy - bind the phy and the controller that uses the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @index: index to specify the port number
+ * @phy_dev_name: the device name of the phy
+ *
+ * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
+ * be used when the phy driver registers the phy and when the controller
+ * requests this phy.
+ *
+ * To be used by platform specific initialization code.
+ */
+int __init usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ struct usb_phy_bind *phy_bind;
+ unsigned long flags;
+
+ phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
+ if (!phy_bind) {
+ pr_err("phy_bind(): No memory for phy_bind");
+ return -ENOMEM;
+ }
+
+ phy_bind->dev_name = dev_name;
+ phy_bind->phy_dev_name = phy_dev_name;
+ phy_bind->index = index;
+
+ spin_lock_irqsave(&phy_lock, flags);
+ list_add_tail(&phy_bind->list, &phy_bind_list);
+ spin_unlock_irqrestore(&phy_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(usb_bind_phy);
+
const char *otg_state_string(enum usb_otg_state state)
{
switch (state) {
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index a29ae1e..e7eb429 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -106,6 +106,21 @@ struct usb_phy {
enum usb_device_speed speed);
};
+/**
+ * struct usb_phy_bind - represent the binding for the phy
+ * @dev_name: the device name of the device that will bind to the phy
+ * @phy_dev_name: the device name of the phy
+ * @index: used if a single controller uses multiple phys
+ * @phy: reference to the phy
+ * @list: to maintain a linked list of the binding information
+ */
+struct usb_phy_bind {
+ const char *dev_name;
+ const char *phy_dev_name;
+ u8 index;
+ struct usb_phy *phy;
+ struct list_head list;
+};
/* for board-specific init logic */
extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
@@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
enum usb_phy_type type);
extern void usb_put_phy(struct usb_phy *);
extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
+extern int usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name);
#else
static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
{
@@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev,
struct usb_phy *x)
{
}
+static inline int usb_bind_phy(const char *dev_name, u8 index,
+ const char *phy_dev_name)
+{
+ return NULL;
The return value looks bogus.
Yes. Felipe has fixed this and has merged the patch already.
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] USB: add devicetree helpers for determining dr_mode and phy_type
On Fri, Feb 01, 2013 at 06:53:52PM +0100, Sascha Hauer wrote: > Apparantly I was not fully awake while sending this series :( > > On Fri, Feb 01, 2013 at 08:52:03AM +0100, Sascha Hauer wrote: > > (resend because I got the linux-usb address wrong) > > > > Here's another round of the dr_mode/phy_type patches. I think they should > > be ready for merging now. Greg, will you apply them should there be no > > problems anymore? I need all chipidea patches to come from the maintainer of the driver, I don't take git pull requests, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Continuous stream of small bulk transfers hangs on OHCI-based systems
Reports like this should always be sent to the mailing list as well as to me. And please instruct your mail client to wrap lines after 72 columns or so -- long lines are hard to deal with. On Fri, 1 Feb 2013, Mark Ferrell wrote: > Hello Alan, > > I have been attempting to debug a hang with the OHCI layer when I ran across > your August conversation with Tomas Sokorai regarding similar behaviour, > though the behaviour did not exist for us in 2.6.27 on the same hardware. What version of the kernel are you using? > The hardware in question is an AMD Geode LX900 with 3 FTDI Dual-Port USB > Serial interfaces attached to the OHCI bus. We have an application which > manages the serial ports and at some point the ports stop responding. If we > attempt to close() the ports the application will hang and attempting to kill > -9 the application triggers a whole slew of issues within the kernel. For > example, since the USB device in question is a tty device the 'ps' goes into > D state while attempting to display the Applications process information. I > presume their is secondary contention in tty_lock() at this point. The problem probably is connected with the OHCI controller and not with the FTDI devices. Once the problem occurs, it is too late to do any debugging. > Like Tomas we noticed that the OHCI interface "feels" very slow. We also > noticed a physical performance drop in the system as a whole when disabling > the EHCI interface on an Intel E660/620 and enabling the OHCI to run > comparison tests against the Geode to see if the Intel would also lock-up. > > Unfortunately I do not have a reliable way to reproduce the bug outside of > running test-cases on multiple systems waiting for the ports to hang. Any > advice/pointers/insight would be appreciated. You should build a test kernel with CONFIG_USB_DEBUG enabled. When the problem occurs, post the output from the "dmesg" command -- not the contents of the system log file. > Feb 1 18:15:40 A303152068 kernel: [ 8404.370974] INFO: task java:3677 > blocked for more than 120 seconds. > Feb 1 18:15:40 A303152068 kernel: [ 8404.378724] "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Feb 1 18:15:40 A303152068 kernel: [ 8404.381100] javaD > c103a90b 0 3677 1 0x0004 > Feb 1 18:15:40 A303152068 kernel: [ 8404.398733] dd72fe54 0096 > dd72fe20 c103a90b c1444530 dd512d80 de2690c0 dd6e0100 > Feb 1 18:15:40 A303152068 kernel: [ 8404.435612] 0046 dd512d80 > c103a90b dd72fe2c 0046 c1444520 0001 c1444520 > Feb 1 18:15:40 A303152068 kernel: [ 8404.476415] 0246 dd72fe2c > c1052801 dd72fe40 0246 dd72fe70 dd72fe70 c1444520 > Feb 1 18:15:40 A303152068 kernel: [ 8404.513915] Call Trace: > Feb 1 18:15:40 A303152068 kernel: [ 8404.515689] [] ? > prepare_to_wait+0x4f/0x56 > Feb 1 18:15:40 A303152068 kernel: [ 8404.521019] [] ? > prepare_to_wait+0x4f/0x56 > Feb 1 18:15:40 A303152068 kernel: [ 8404.526174] [] ? > trace_hardirqs_on+0xb/0xd > Feb 1 18:15:40 A303152068 kernel: [ 8404.531238] [] ? > prepare_to_wait+0x4f/0x56 > Feb 1 18:15:40 A303152068 kernel: [ 8404.536154] [] > schedule+0x3b/0x3d > Feb 1 18:15:40 A303152068 kernel: [ 8404.540189] [] > usb_kill_urb+0x86/0x9f > Feb 1 18:15:40 A303152068 kernel: [ 8404.544126] [] ? > wake_up_bit+0x1b/0x1b > Feb 1 18:15:40 A303152068 kernel: [ 8404.548990] [] > generic_cleanup+0x98/0xa4 > Feb 1 18:15:40 A303152068 kernel: [ 8404.552549] [] > usb_serial_generic_close+0x35/0x3a > Feb 1 18:15:40 A303152068 kernel: [ 8404.556484] [] > ftdi_close+0x3b/0x54 [ftdi_sio] > Feb 1 18:15:40 A303152068 kernel: [ 8404.561561] [] > serial_down+0x23/0x25 > Feb 1 18:15:40 A303152068 kernel: [ 8404.564128] [] > tty_port_shutdown+0x3c/0x4a > Feb 1 18:15:40 A303152068 kernel: [ 8404.568926] [] > tty_port_close+0x19/0x37 > Feb 1 18:15:40 A303152068 kernel: [ 8404.574519] [] > serial_close+0x44/0x4c > Feb 1 18:15:40 A303152068 kernel: [ 8404.579157] [] > tty_release+0x98/0x2e9 > Feb 1 18:15:40 A303152068 kernel: [ 8404.586850] [] > __fput+0xdc/0x17a > Feb 1 18:15:40 A303152068 kernel: [ 8404.589187] [] > fput+0x17/0x19 > Feb 1 18:15:40 A303152068 kernel: [ 8404.592384] [] > filp_close+0x57/0x61 > Feb 1 18:15:40 A303152068 kernel: [ 8404.598120] [] > sys_close+0x6d/0xa8 > Feb 1 18:15:41 A303152068 kernel: [ 8404.603033] [] > syscall_call+0x7/0xb > Feb 1 18:15:41 A303152068 kernel: [ 8404.608536] [] ? > quirk_triton+0x7/0x25 This is useless. We need to see what happens when the problem occurs, not 2 minutes later. 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: Continuous stream of small bulk transfers hangs on OHCI-based systems
On 02/02/2013 09:01 AM, Alan Stern wrote: Reports like this should always be sent to the mailing list as well as to me. And please instruct your mail client to wrap lines after 72 columns or so -- long lines are hard to deal with. Understood. What version of the kernel are you using? The previous output was from a 3.3.8 kernel w/ commit 50ce5c0683aa83eb161624ea89daa5a9eee0c2ce applied. You should build a test kernel with CONFIG_USB_DEBUG enabled. When the problem occurs, post the output from the "dmesg" command -- not the contents of the system log file. I have already enabled CONFIG_USB_DEBUG, as well as a large number of other debug options attempting to get something more than the previous back-trace. I have also enabled CONFIG_OHCI_VERBOSE_DEBUG (overkill?) on a few systems in hopes that something useful would be made more self-evident. This is useless. We need to see what happens when the problem occurs, not 2 minutes later. Unfortunately the previous back-trace is the only data that shows up. Even with CONFIG_USB_DEBUG there isn't anything actively arriving in the kernel log buffer as reported by dmesg. -- 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: Official TO-DO List
On Sat, Feb 02, 2013 at 09:27:59PM +0530, Anil Nair wrote: > Hello All, > > Can anyone in the mailing list point me to the official TODO list of > kernel Janitors project? > Is this list up to date "http://kernelnewbies.org/KernelJanitors/Todo";? > > I just want a confirmation. It's not a bad list. It pretty much still applies. It's probably best to start with staging/ because churn is welcome in staging. regards, dan carpenter -- 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: Continuous stream of small bulk transfers hangs on OHCI-based systems
On Sat, 2 Feb 2013, Mark Ferrell wrote: > > What version of the kernel are you using? > > The previous output was from a 3.3.8 kernel w/ commit > 50ce5c0683aa83eb161624ea89daa5a9eee0c2ce applied. In general it's better to test with the most up-to-date kernel you can, but in this case I don't think there have been any other significant changes to ohci-hcd since 3.3. > > You should build a test kernel with CONFIG_USB_DEBUG enabled. When the > > problem occurs, post the output from the "dmesg" command -- not the > > contents of the system log file. > > I have already enabled CONFIG_USB_DEBUG, as well as a large number of > other debug options attempting to get something more than the previous > back-trace. I have also enabled CONFIG_OHCI_VERBOSE_DEBUG (overkill?) Almost certainly overkill. :-) > on a few systems in hopes that something useful would be made more > self-evident. > > > This is useless. We need to see what happens when the problem occurs, > > not 2 minutes later. > > Unfortunately the previous back-trace is the only data that shows up. > Even with CONFIG_USB_DEBUG there isn't anything actively arriving in the > kernel log buffer as reported by dmesg. Then the next step is to go into the appropriate subdirectory under /sys/kernel/debug/usb/ohci/ (the one that corresponds to the controller having problems) and see what the files in there say. It may also be possible to get useful information from usbmon, but that's not easy to do if you don't have a good way to trigger the problem. 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: Continuous stream of small bulk transfers hangs on OHCI-based systems
On 02/02/2013 11:39 AM, Alan Stern wrote: Then the next step is to go into the appropriate subdirectory under /sys/kernel/debug/usb/ohci/ (the one that corresponds to the controller having problems) and see what the files in there say. The following output is from /sys/kernel/debug/usb/ohci/:00:0f.4 when the OCHI bus appears to stop receiving data from the FTDI device, but URB cleanup has not yet been attempted as there are still open TTY's. Unfortunately the ports are already in a bad state at this point so I do not know how useful it is. /sys/kernel/debug/usb/ohci/:00:0f.4/periodic: size = 32 0 [ 11]: ed32/dd5f9040 (fs dev2 ep1in-int qlen 1 max 1 00011082) /sys/kernel/debug/usb/ohci/:00:0f.4/registers: bus pci, device :00:0f.4 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x2af RWC HCFS=operational BLE IE PLE CBSR=3 cmdstatus 0x4 SOC=0 BLF intrstatus 0x0024 FNO SF intrenable 0x805a MIE RHSC UE RD WDH ed_controlhead 1d5f90c0 ed_bulkhead 1d5f9140 ed_bulkcurrent 1d5f9300 hcca frame 0x46d6 fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x8000222a FRT FR=0x222a periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 03000204 POTPGT=3 NPS NDP=4(4) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0103 PPS PES CCS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0103 PPS PES CCS roothub.portstatus [3] 0x0103 PPS PES CCS Here is the output from /sys/kernel/debug/usb/ohci/:00:0f.4 after attempting to kill -9 the process holding the tty open, and subsequently triggering the cleanup of the port (usb_kill_urb()). /sys/kernel/debug/usb/ohci/:00:0f.4/periodic: size = 32 0 [ 11]: ed32/dd5f9040 (fs dev2 ep1in-int qlen 1 max 1 00011082) /sys/kernel/debug/usb/ohci/:00:0f.4/registers: bus pci, device :00:0f.4 OHCI Host Controller ohci_hcd OHCI 1.0, NO legacy support registers, rh state running control 0x2af RWC HCFS=operational BLE IE PLE CBSR=3 cmdstatus 0x4 SOC=0 BLF intrstatus 0x0020 FNO intrenable 0x805e MIE RHSC UE RD SF WDH ed_controlhead 1d5f90c0 ed_bulkhead 1d5f9240 ed_bulkcurrent 1d5f9280 donehead 19ca4180 hcca frame 0xda2e fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf fmremaining 0x80001f0d FRT FR=0x1f0d periodicstart 0x2a2f lsthresh 0x0628 hub poll timer off roothub.a 03000204 POTPGT=3 NPS NDP=4(4) roothub.b PPCM= DR= roothub.status 8000 DRWE roothub.portstatus [0] 0x0103 PPS PES CCS roothub.portstatus [1] 0x0103 PPS PES CCS roothub.portstatus [2] 0x0103 PPS PES CCS roothub.portstatus [3] 0x0103 PPS PES CCS It may also be possible to get useful information from usbmon, but that's not easy to do if you don't have a good way to trigger the problem. Will try to find a way to continuously collect this data and see if we can acquire some "before" and "after" information, and maybe get some "during" in there as 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
[PATCH] usb: gadget: make userial_init() static
Signed-off-by: Fengguang Wu
---
drivers/usb/gadget/u_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next.orig/drivers/usb/gadget/u_serial.c 2013-02-03
09:50:18.422689811 +0800
+++ linux-next/drivers/usb/gadget/u_serial.c2013-02-03 09:50:27.570690026
+0800
@@ -1288,7 +1288,7 @@ void gserial_disconnect(struct gserial *
}
EXPORT_SYMBOL_GPL(gserial_disconnect);
-int userial_init(void)
+static int userial_init(void)
{
unsignedi;
int status;
--
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: gadget: make gzero_options static
Signed-off-by: Fengguang Wu
---
drivers/usb/gadget/zero.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next.orig/drivers/usb/gadget/zero.c 2013-02-03 09:50:18.426689812
+0800
+++ linux-next/drivers/usb/gadget/zero.c2013-02-03 09:53:35.162694484
+0800
@@ -63,7 +63,7 @@ static const char longname[] = "Gadget Z
static bool loopdefault = 0;
module_param(loopdefault, bool, S_IRUGO|S_IWUSR);
-struct usb_zero_options gzero_options = {
+static struct usb_zero_options gzero_options = {
.isoc_interval = 4,
.isoc_maxpacket = 1024,
.bulk_buflen = 4096,
--
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
