[Patch V3 0/2] usb: gadget: zero: Add support for interrupt EP
This patchset adds support for interrupt EP and the corresponding test cases to gadget zero. The code has been rebased and tested on Kernel v3.15-rc5 V2 -> V3 - Rectified wMaxPacketSize for FS from 1023 to 64 - Modified default value of interrupt interval for FS to 1 ms V1 -> V2 - Modified the alternate interface from having 6 EPs (2 - Interrupt, 2 Bulk, 2 Isoc) to 2 EPs (Interrupt only) RFC -> V1 - Added support for configuring interrupt EP attributes from configfs interface Amit Virdi (2): usb: gadget: zero: Add support for interrupt EP usbtest: Add interrupt EP testcases drivers/usb/gadget/f_loopback.c | 3 +- drivers/usb/gadget/f_sourcesink.c | 511 -- drivers/usb/gadget/g_zero.h | 13 +- drivers/usb/gadget/zero.c | 21 ++ drivers/usb/misc/usbtest.c| 113 +++-- 5 files changed, 624 insertions(+), 37 deletions(-) -- 1.8.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
[Patch V3 1/2] usb: gadget: zero: Add support for interrupt EP
Interrupt endpoints behave quite similar to the bulk endpoints with the
difference that the endpoints expect data sending/reception request at
particular intervals till the whole data has not been transmitted.
The interrupt EP support is added to gadget zero. A new alternate setting (=2)
has been added. It has 2 interrupt endpoints. The default parameters are set as:
bInterval: 1 ms for FS and 8 uFrames (implying 1 ms) for HS/SS
wMaxPacketSize: 64 bytes for FS and 1024 bytes for HS/SS
However, the same can be overridden through the module parameter interface.
The code is tested for HS and SS on a platform having DWC3 controller.
Signed-off-by: Amit Virdi
---
drivers/usb/gadget/f_loopback.c | 3 +-
drivers/usb/gadget/f_sourcesink.c | 511 --
drivers/usb/gadget/g_zero.h | 13 +-
drivers/usb/gadget/zero.c | 21 ++
4 files changed, 526 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/gadget/f_loopback.c b/drivers/usb/gadget/f_loopback.c
index 4557cd0..bf04389 100644
--- a/drivers/usb/gadget/f_loopback.c
+++ b/drivers/usb/gadget/f_loopback.c
@@ -298,7 +298,8 @@ static void disable_loopback(struct f_loopback *loop)
struct usb_composite_dev*cdev;
cdev = loop->function.config->cdev;
- disable_endpoints(cdev, loop->in_ep, loop->out_ep, NULL, NULL);
+ disable_endpoints(cdev, loop->in_ep, loop->out_ep, NULL, NULL, NULL,
+ NULL);
VDBG(cdev, "%s disabled\n", loop->function.name);
}
diff --git a/drivers/usb/gadget/f_sourcesink.c
b/drivers/usb/gadget/f_sourcesink.c
index d3cd52d..7c091a3 100644
--- a/drivers/usb/gadget/f_sourcesink.c
+++ b/drivers/usb/gadget/f_sourcesink.c
@@ -23,6 +23,15 @@
#include "gadget_chips.h"
#include "u_f.h"
+#define USB_MS_TO_SS_INTERVAL(x) USB_MS_TO_HS_INTERVAL(x)
+
+enum eptype {
+ EP_CONTROL = 0,
+ EP_BULK,
+ EP_ISOC,
+ EP_INTERRUPT,
+};
+
/*
* SOURCE/SINK FUNCTION ... a primary testing vehicle for USB peripheral
* controller drivers.
@@ -55,6 +64,8 @@ struct f_sourcesink {
struct usb_ep *out_ep;
struct usb_ep *iso_in_ep;
struct usb_ep *iso_out_ep;
+ struct usb_ep *int_in_ep;
+ struct usb_ep *int_out_ep;
int cur_alt;
};
@@ -68,6 +79,10 @@ static unsigned isoc_interval;
static unsigned isoc_maxpacket;
static unsigned isoc_mult;
static unsigned isoc_maxburst;
+static unsigned int_interval; /* In ms */
+static unsigned int_maxpacket;
+static unsigned int_mult;
+static unsigned int_maxburst;
static unsigned buflen;
/*-*/
@@ -92,6 +107,16 @@ static struct usb_interface_descriptor
source_sink_intf_alt1 = {
/* .iInterface = DYNAMIC */
};
+static struct usb_interface_descriptor source_sink_intf_alt2 = {
+ .bLength = USB_DT_INTERFACE_SIZE,
+ .bDescriptorType = USB_DT_INTERFACE,
+
+ .bAlternateSetting =2,
+ .bNumEndpoints =2,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ /* .iInterface = DYNAMIC */
+};
+
/* full speed support: */
static struct usb_endpoint_descriptor fs_source_desc = {
@@ -130,6 +155,26 @@ static struct usb_endpoint_descriptor fs_iso_sink_desc = {
.bInterval =4,
};
+static struct usb_endpoint_descriptor fs_int_source_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+
+ .bEndpointAddress = USB_DIR_IN,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = cpu_to_le16(64),
+ .bInterval =GZERO_INT_INTERVAL,
+};
+
+static struct usb_endpoint_descriptor fs_int_sink_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+
+ .bEndpointAddress = USB_DIR_OUT,
+ .bmAttributes = USB_ENDPOINT_XFER_INT,
+ .wMaxPacketSize = cpu_to_le16(64),
+ .bInterval =GZERO_INT_INTERVAL,
+};
+
static struct usb_descriptor_header *fs_source_sink_descs[] = {
(struct usb_descriptor_header *) &source_sink_intf_alt0,
(struct usb_descriptor_header *) &fs_sink_desc,
@@ -140,6 +185,10 @@ static struct usb_descriptor_header
*fs_source_sink_descs[] = {
(struct usb_descriptor_header *) &fs_source_desc,
(struct usb_descriptor_header *) &fs_iso_sink_desc,
(struct usb_descriptor_header *) &fs_iso_source_desc,
+ (struct usb_descriptor_header *) &source_sink_intf_alt2,
+#define FS_ALT_IFC_2_OFFSET8
+ (struct usb_descriptor_header *) &fs_int_sink_desc,
+ (struct usb_descriptor_header *) &fs_int_source_desc,
NULL,
};
@@ -179,6 +228,24 @@ static struct usb_endpoint_descriptor hs_iso_sink_desc = {
.bInterval =
[Patch V3 2/2] usbtest: Add interrupt EP testcases
Two simple test cases for interrupt endpoints are added to the usbtest.c file.
These are simple non-queued interrupt IN and interrupt OUT transfers. Currently,
only gadget zero is capable of executing the interrupt EP test cases. However,
extending the same to other gadgets is extremely simple and can be done
on-demand.
This code has been tested only with gadget zero and care has been taken so as to
not break the existing functionality. However, if anyone can test with other
gadgets then that would be great!
Signed-off-by: Amit Virdi
---
drivers/usb/misc/usbtest.c | 113 +++--
1 file changed, 98 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index f6568b5..5c6baaa 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -54,6 +54,7 @@ struct usbtest_info {
unsignedautoconf:1;
unsignedctrl_out:1;
unsignediso:1; /* try iso in/out */
+ unsignedintr:1; /* try interrupt in/out */
int alt;
};
@@ -70,7 +71,10 @@ struct usbtest_dev {
int out_pipe;
int in_iso_pipe;
int out_iso_pipe;
+ int in_int_pipe;
+ int out_int_pipe;
struct usb_endpoint_descriptor *iso_in, *iso_out;
+ struct usb_endpoint_descriptor *int_in, *int_out;
struct mutexlock;
#define TBUF_SIZE 256
@@ -101,6 +105,7 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface
*intf)
struct usb_host_interface *alt;
struct usb_host_endpoint*in, *out;
struct usb_host_endpoint*iso_in, *iso_out;
+ struct usb_host_endpoint*int_in, *int_out;
struct usb_device *udev;
for (tmp = 0; tmp < intf->num_altsetting; tmp++) {
@@ -108,6 +113,7 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface
*intf)
in = out = NULL;
iso_in = iso_out = NULL;
+ int_in = int_out = NULL;
alt = intf->altsetting + tmp;
if (override_alt >= 0 &&
@@ -124,6 +130,9 @@ get_endpoints(struct usbtest_dev *dev, struct usb_interface
*intf)
switch (usb_endpoint_type(&e->desc)) {
case USB_ENDPOINT_XFER_BULK:
break;
+ case USB_ENDPOINT_XFER_INT:
+ if (dev->info->intr)
+ goto try_intr;
case USB_ENDPOINT_XFER_ISOC:
if (dev->info->iso)
goto try_iso;
@@ -139,6 +148,15 @@ get_endpoints(struct usbtest_dev *dev, struct
usb_interface *intf)
out = e;
}
continue;
+try_intr:
+ if (usb_endpoint_dir_in(&e->desc)) {
+ if (!int_in)
+ int_in = e;
+ } else {
+ if (!int_out)
+ int_out = e;
+ }
+ continue;
try_iso:
if (usb_endpoint_dir_in(&e->desc)) {
if (!iso_in)
@@ -148,7 +166,7 @@ try_iso:
iso_out = e;
}
}
- if ((in && out) || iso_in || iso_out)
+ if ((in && out) || iso_in || iso_out || int_in || int_out)
goto found;
}
return -EINVAL;
@@ -183,6 +201,20 @@ found:
iso_out->desc.bEndpointAddress
& USB_ENDPOINT_NUMBER_MASK);
}
+
+ if (int_in) {
+ dev->int_in = &int_in->desc;
+ dev->in_int_pipe = usb_rcvintpipe(udev,
+ int_in->desc.bEndpointAddress
+ & USB_ENDPOINT_NUMBER_MASK);
+ }
+
+ if (int_out) {
+ dev->int_out = &int_out->desc;
+ dev->out_int_pipe = usb_sndintpipe(udev,
+ int_out->desc.bEndpointAddress
+ & USB_ENDPOINT_NUMBER_MASK);
+ }
return 0;
}
@@ -205,14 +237,22 @@ static struct urb *usbtest_alloc_urb(
int pipe,
unsigned long bytes,
unsignedtransfer_flags,
- unsignedoffset)
+ unsignedoffset,
+ u8 bInterval)
{
struct urb *urb;
urb = usb_alloc_urb(0, GFP_KER
Re: [PATCH V2] USB: Add LVS Test device driver
Hi Alan,
On Fri, May 23, 2014 at 01:54:01AM +0800, Alan Stern wrote:
> On Thu, 22 May 2014, Pratyush Anand wrote:
>
> > OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> > system (SS-OVS) which consists of an excersizer and analyzer.
> >
> > USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
> > Link Layer Validation (LVS).
> >
> > Some modifications are needed for an embedded Linux USB host to pass all
> > these tests. Most of these tests require just Link to be in U0. They do
> > not work with default Linux USB stack since, default stack does port
> > reset and then starts sending setup packet, which is not expected by
> > Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
> > There are many Link Layer Tests which need host to generate specific
> > traffic.
> >
> > This patch supports specific traffic generation cases. As of now all the
> > host Lecroy Link Layer-USBIF tests (except TD7.26) passes
> > with this patch for single run using Lecroy USB Compliance Suite
> > Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
> > Build 1603. Therefore patch seems to be a good candidate for inclusion.
> > Further modification can be done on top of it.
> >
> > lvstest driver will not bind to any device by default. It can bind
> > manually to a super speed USB host controller root hub. Therefore, regular
> > hub driver must be unbound before this driver is bound. For example, if
> > 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.
> >
> > echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind
> >
> > Then to bind lvs driver write Linux Foundation's vendor ID and SS root
> > hub's device ID into new_id file.
> >
> > echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id
> >
> > Now connect LVS device with root hub port.
>
> You forgot to include an example here showing how to do this:
>
> echo 2-0\:1.0 > /sys/bus/usb/drivers/lvs/bind
>
We do not need to write into bind file. Writing a valid VID and PID
of SS root hub into new_id file does the binding also.
> > Test case specific traffic can be generated as follows whenever needed:
> >
> > 1. To issue "Get Device descriptor" command for TD.7.06:
> > echo 1 > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc
> >
> > 2. To set U1 timeout to 127 for TD.7.18
> > echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout
> >
> > 3. To set U2 timeout to 0 for TD.7.18
> > echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout
> >
> > 4. To issue "Hot Reset" for TD.7.29
> > echo 1 > /sys/bus/usb/devices/2-0\:1.0/hot_reset
> >
> > 5. To issue "U3 Entry" for TD.7.35
> > echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_entry
> >
> > 6. To issue "U3 Exit" for TD.7.36
> > echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_exit
>
> None of those example need to contain the "1". For instance, the last
> one should be written:
>
> echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit
Yes, any write will do except for ux_timeout.
>
> > diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> > b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> > new file mode 100644
> > index 000..f47e8a3
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> > @@ -0,0 +1,47 @@
> > +Link Layer Validation Device is a standard device for testing of Super
> > +Speed Link Layer tests. These nodes are available in sysfs only when lvs
> > +driver is bound with root hub device.
> > +
> > +What: /sys/bus/usb/devices/.../get_dev_desc
> > +Date: March 2014
> > +Contact: Pratyush Anand
> > +Description:
> > + Write to this node to issue "Get Device Descriptor"
> > + for Link Layer Validation device. It is needed for TD.7.06.
> > +
> > +What: /sys/bus/usb/devices/.../u1_timeout
> > +Date: March 2014
> > +Contact: Pratyush Anand
> > +Description:
> > + Set "U1 timeout" for the downstream port where Link Layer
> > + Validation device is connected. It is needed for TD.7.18,
> > + TD.7.19, TD.7.20 and TD.7.21.
>
> This doesn't say that the value must be between 0 and 127.
OK, that I will specify.
>
> > +
> > +What: /sys/bus/usb/devices/.../u2_timeout
> > +Date: March 2014
> > +Contact: Pratyush Anand
> > +Description:
> > + Set "U2 timeout" for the downstream port where Link Layer
> > + Validation device is connected. It is needed for TD.7.18,
> > + TD.7.19, TD.7.20 and TD.7.21.
>
> Same here.
OK.
>
> > +static void lvs_rh_work(struct work_struct *work)
> > +{
> > + struct lvs_rh *lvs = container_of(work, struct lvs_rh, rh_work);
> > + struct usb_interface *intf = lvs->intf;
> > + struct usb_device *hdev = interface_to_usbdev(intf);
> > + struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
> > + struct usb_hub_descriptor *descriptor = &lvs->descriptor;
> > + struct usb_port_status port_status;
> > + int i, ret = 0
debug info for scheduling
hi all: I have some questions: 1. is it possible to know period bandwidth for ehci controller from sys or other additional configuration? 2. is it possible to know S/C bit in QHs which are linked in a frame? thanks for your help in advance, -- 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 0/3] Chipidea patches for 3.16 merge window
> > > > No big changes for these three patches, just cleanup, refine, update > > TODO list. > > > > Besides, I haven't seen my last 3.16 patch set in your next tree, do I > > need to re-send them (together with this one)? > > > > http://marc.info/?l=linux-usb&m=139917105404965&w=2 > > Sorry, been on the road, now both applied. > Get it, thanks. Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Chipidea patches for 3.16 merge window
On Fri, May 23, 2014 at 08:12:46AM +0800, Peter Chen wrote: > Hi Greg, > > No big changes for these three patches, just cleanup, refine, update > TODO list. > > Besides, I haven't seen my last 3.16 patch set in your next tree, do > I need to re-send them (together with this one)? > > http://marc.info/?l=linux-usb&m=139917105404965&w=2 Sorry, been on the road, now both applied. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] USB patches for v3.16 merge window
On Wed, May 21, 2014 at 05:28:31PM -0500, Felipe Balbi wrote: > Hi Greg, > > Here's my big dump for v3.16 merge window. Even though we have a lot of > patches, most of them are just doing cleanups and small bug fixes. > > Consider merging it to your usb-next branch. There will be a conflict > with drivers/usb/phy/phy-mv-u3d.c (deleted in your tree, modified on > mine). I'll let you decide what you really want to do, but I don't think > that driver should be deleted, even commented on original thread. I like the driver removed, if no one can use it or build it, no need to keep it around. Now merged and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: some question about usb_interrupt_msg
hi Alan: 2014-05-22 22:14 GMT+08:00 Alan Stern : > On Thu, 22 May 2014, vichy wrote: > >> hi all: >> I see usb_interrupt_msg do nothing but call usb_bulk_msg. >> Why we still keep usb_interrupt_msg? >> for old api compatibility? > > That's right. Also because it gives an indication to the reader about > what type of transfer is being performed. I got it. appreciate your kind reply ^^ -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] Re-organize usb common
On Fri, May 23, 2014 at 01:16:37AM +, Peter Chen wrote:
>
> >
> > Hi Greg,
> >
> > This patch set creates usb/common for usb common things, and moves otg
> > fsm implementation from usb/phy/ to usb/common/. I have a discussion with
> > Felipe about it at below link:
> > http://www.spinics.net/lists/linux-usb/msg106357.html
> >
> > Thanks.
> >
> > Changes for v2:
> > - Fix one typo Alan pointed.
> >
> > Peter Chen (2):
> > usb: move usb/usb-common.c to usb/common/usb-common.c
> > usb: common: rename phy-fsm-usb.c to usb-otg-fsm.c
> >
> > drivers/usb/Makefile |2 +-
> > drivers/usb/common/Makefile|6 ++
> > drivers/usb/{ => common}/usb-common.c |0
> > .../{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}|0
> > drivers/usb/core/Kconfig |9 +
> > drivers/usb/phy/Kconfig|9 -
> > drivers/usb/phy/Makefile |1 -
> > 7 files changed, 16 insertions(+), 11 deletions(-) create mode 100644
> > drivers/usb/common/Makefile rename drivers/usb/{ => common}/usb-common.c
> > (100%) rename drivers/usb/{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}
> > (100%)
> >
>
> Hi Greg, does this patch set will in your 3.16 tree? There are coming
> works are related to it, thanks.
It's behind in my patch review queue due to my travels. I'll be back
next week and will get to this, sorry for the delay.
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
[PATCH 3/3] usb: chipidea: using one inline function to cover queue work operations
The otg queue work include operations: one is disable interrupt,
another one is call kernel queue work API. Many codes do this
operation, using one inline function to instead of them.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/core.c|6 +--
drivers/usb/chipidea/otg.h |5 +++
drivers/usb/chipidea/otg_fsm.c | 69 +--
3 files changed, 30 insertions(+), 50 deletions(-)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 95b4dd7..619d13e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -425,8 +425,7 @@ static irqreturn_t ci_irq(int irq, void *data)
ci->id_event = true;
/* Clear ID change irq status */
hw_write_otgsc(ci, OTGSC_IDIS, OTGSC_IDIS);
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
return IRQ_HANDLED;
}
@@ -438,8 +437,7 @@ static irqreturn_t ci_irq(int irq, void *data)
ci->b_sess_valid_event = true;
/* Clear BSV irq */
hw_write_otgsc(ci, OTGSC_BSVIS, OTGSC_BSVIS);
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
return IRQ_HANDLED;
}
diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
index 7349267..9ecb598 100644
--- a/drivers/usb/chipidea/otg.h
+++ b/drivers/usb/chipidea/otg.h
@@ -17,5 +17,10 @@ int ci_hdrc_otg_init(struct ci_hdrc *ci);
void ci_hdrc_otg_destroy(struct ci_hdrc *ci);
enum ci_role ci_otg_role(struct ci_hdrc *ci);
void ci_handle_vbus_change(struct ci_hdrc *ci);
+static inline void ci_otg_queue_work(struct ci_hdrc *ci)
+{
+ disable_irq_nosync(ci->irq);
+ queue_work(ci->wq, &ci->work);
+}
#endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 8d4c33d..caaabc5 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -84,8 +84,7 @@ set_a_bus_req(struct device *dev, struct device_attribute
*attr,
ci->fsm.a_bus_req = 1;
}
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
return count;
@@ -125,8 +124,7 @@ set_a_bus_drop(struct device *dev, struct device_attribute
*attr,
ci->fsm.a_bus_req = 0;
}
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
return count;
@@ -165,8 +163,7 @@ set_b_bus_req(struct device *dev, struct device_attribute
*attr,
else if (buf[0] == '1')
ci->fsm.b_bus_req = 1;
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
return count;
@@ -186,8 +183,7 @@ set_a_clr_err(struct device *dev, struct device_attribute
*attr,
if (buf[0] == '1')
ci->fsm.a_clr_err = 1;
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
mutex_unlock(&ci->fsm.lock);
return count;
@@ -297,8 +293,7 @@ static void set_tmout_and_fsm(void *ptr, unsigned long
indicator)
set_tmout(ci, indicator);
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
}
static void a_wait_vfall_tmout_func(void *ptr, unsigned long indicator)
@@ -312,8 +307,7 @@ static void a_wait_vfall_tmout_func(void *ptr, unsigned
long indicator)
hw_write_otgsc(ci, OTGSC_DPIS, OTGSC_DPIS);
/* Enable data pulse irq */
hw_write_otgsc(ci, OTGSC_DPIE, OTGSC_DPIE);
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
}
static void b_ase0_brst_tmout_func(void *ptr, unsigned long indicator)
@@ -324,8 +318,7 @@ static void b_ase0_brst_tmout_func(void *ptr, unsigned long
indicator)
if (!hw_read_otgsc(ci, OTGSC_BSV))
ci->fsm.b_sess_vld = 0;
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
+ ci_otg_queue_work(ci);
}
static void b_ssend_srp_tmout_func(void *ptr, unsigned long indicator)
@@ -335,10 +328,8 @@ static void b_ssend_srp_tmout_func(void *ptr, unsigned
long indicator)
set_tmout(ci, indicator);
/* only vbus fall below B_sess_vld in b_idle state */
- if (ci->transceiver->state == OTG_STATE_B_IDLE) {
- disable_irq_nosync(ci->irq);
- queue_work(ci->wq, &ci->work);
- }
+ if (ci->transceiver->state == OTG_STATE_B_IDLE)
+ ci_otg_queue_work(ci);
}
static void b_sess_vld_tmout_func(void *ptr, unsigned long indicator)
@@ -349,8
[PATCH 1/3] usb: chipidea: update TODO list
Update TODO list Signed-off-by: Peter Chen --- drivers/usb/chipidea/core.c |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c index 128b92b..95b4dd7 100644 --- a/drivers/usb/chipidea/core.c +++ b/drivers/usb/chipidea/core.c @@ -23,7 +23,7 @@ * - BUS:bus glue code, bus abstraction layer * * Compile Options - * - CONFIG_USB_GADGET_DEBUG_FILES: enable debug facilities + * - CONFIG_USB_CHIPIDEA_DEBUG: enable debug facilities * - STALL_IN: non-empty bulk-in pipes cannot be halted * if defined mass storage compliance succeeds but with warnings * => case 4: Hi > Dn @@ -42,9 +42,6 @@ * - Not Supported: 15 & 16 (ISO) * * TODO List - * - Interrupt Traffic - * - GET_STATUS(device) - always reports 0 - * - Gadget API (majority of optional features) * - Suspend & Remote Wakeup */ #include -- 1.7.8 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: chipidea: udc: delete useless code
Delete useless code
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/udc.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index d683968..69425b3 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -825,7 +825,6 @@ __acquires(hwep->lock)
if ((setup->bRequestType & USB_RECIP_MASK) == USB_RECIP_DEVICE) {
/* Assume that device is bus powered for now. */
*(u16 *)req->buf = ci->remote_wakeup << 1;
- retval = 0;
} else if ((setup->bRequestType & USB_RECIP_MASK) \
== USB_RECIP_ENDPOINT) {
dir = (le16_to_cpu(setup->wIndex) & USB_ENDPOINT_DIR_MASK) ?
--
1.7.8
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Chipidea patches for 3.16 merge window
Hi Greg, No big changes for these three patches, just cleanup, refine, update TODO list. Besides, I haven't seen my last 3.16 patch set in your next tree, do I need to re-send them (together with this one)? http://marc.info/?l=linux-usb&m=139917105404965&w=2 Thanks. Peter Chen (3): usb: chipidea: update TODO list usb: chipidea: udc: delete useless code usb: chipidea: using one inline function to cover queue work operations drivers/usb/chipidea/core.c| 11 ++- drivers/usb/chipidea/otg.h |5 +++ drivers/usb/chipidea/otg_fsm.c | 69 +-- drivers/usb/chipidea/udc.c |1 - 4 files changed, 31 insertions(+), 55 deletions(-) -- 1.7.8 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/2] Re-organize usb common
>
> Hi Greg,
>
> This patch set creates usb/common for usb common things, and moves otg
> fsm implementation from usb/phy/ to usb/common/. I have a discussion with
> Felipe about it at below link:
> http://www.spinics.net/lists/linux-usb/msg106357.html
>
> Thanks.
>
> Changes for v2:
> - Fix one typo Alan pointed.
>
> Peter Chen (2):
> usb: move usb/usb-common.c to usb/common/usb-common.c
> usb: common: rename phy-fsm-usb.c to usb-otg-fsm.c
>
> drivers/usb/Makefile |2 +-
> drivers/usb/common/Makefile|6 ++
> drivers/usb/{ => common}/usb-common.c |0
> .../{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}|0
> drivers/usb/core/Kconfig |9 +
> drivers/usb/phy/Kconfig|9 -
> drivers/usb/phy/Makefile |1 -
> 7 files changed, 16 insertions(+), 11 deletions(-) create mode 100644
> drivers/usb/common/Makefile rename drivers/usb/{ => common}/usb-common.c
> (100%) rename drivers/usb/{phy/phy-fsm-usb.c => common/usb-otg-fsm.c}
> (100%)
>
Hi Greg, does this patch set will in your 3.16 tree? There are coming
works are related to it, thanks.
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Staging: Media: sn9c102: Fixed a pointer declaration coding style issue
Fixed the ERROR thrown off by checkpatch.pl.
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
b/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
index a30bbc4..725de85 100644
--- a/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
+++ b/drivers/staging/media/sn9c102/sn9c102_tas5130d1b.c
@@ -23,7 +23,7 @@
#include "sn9c102_devtable.h"
-static int tas5130d1b_init(struct sn9c102_device* cam)
+static int tas5130d1b_init(struct sn9c102_device *cam)
{
int err;
@@ -36,8 +36,8 @@ static int tas5130d1b_init(struct sn9c102_device* cam)
}
-static int tas5130d1b_set_ctrl(struct sn9c102_device* cam,
- const struct v4l2_control* ctrl)
+static int tas5130d1b_set_ctrl(struct sn9c102_device *cam,
+ const struct v4l2_control *ctrl)
{
int err = 0;
@@ -56,10 +56,10 @@ static int tas5130d1b_set_ctrl(struct sn9c102_device* cam,
}
-static int tas5130d1b_set_crop(struct sn9c102_device* cam,
- const struct v4l2_rect* rect)
+static int tas5130d1b_set_crop(struct sn9c102_device *cam,
+ const struct v4l2_rect *rect)
{
- struct sn9c102_sensor* s = sn9c102_get_sensor(cam);
+ struct sn9c102_sensor *s = sn9c102_get_sensor(cam);
u8 h_start = (u8)(rect->left - s->cropcap.bounds.left) + 104,
v_start = (u8)(rect->top - s->cropcap.bounds.top) + 12;
int err = 0;
@@ -76,8 +76,8 @@ static int tas5130d1b_set_crop(struct sn9c102_device* cam,
}
-static int tas5130d1b_set_pix_format(struct sn9c102_device* cam,
- const struct v4l2_pix_format* pix)
+static int tas5130d1b_set_pix_format(struct sn9c102_device *cam,
+ const struct v4l2_pix_format *pix)
{
int err = 0;
@@ -146,7 +146,7 @@ static const struct sn9c102_sensor tas5130d1b = {
};
-int sn9c102_probe_tas5130d1b(struct sn9c102_device* cam)
+int sn9c102_probe_tas5130d1b(struct sn9c102_device *cam)
{
const struct usb_device_id tas5130d1b_id_table[] = {
{ USB_DEVICE(0x0c45, 0x6024), },
--
1.9.1
--
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/7] dma: cppi41: handle 0-length packets
Hi,
I messed up the register names in the commit log. Will fix in v2.
On 05/22/2014 05:30 PM, Daniel Mack wrote:
> When a 0-length packet is received on the bus, desc->pd6 contains 1, and
... 'desc->pd0' ...
> the current residue calculation reports back that 1 byte has been
> transferred. This is not according to what the datasheet says, but it's
> been the case on an AM335x board, very reproducible.
>
> Fix this by looking at bit 19 in PD2 of the completed packet. This bit
> will tell us if a zero-length packet was received on a queue. If it's
> set, ignore pd2 and report a total length of 0.
... 'ignore pd0' ...
>
> Signed-off-by: Daniel Mack
> ---
> drivers/dma/cppi41.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index d028f36..8f8b0b6 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -86,6 +86,9 @@
>
> #define USBSS_IRQ_PD_COMP(1 << 2)
>
> +/* Packet Descriptor */
> +#define PD2_ZERO_LENGTH (1 << 19)
> +
> struct cppi41_channel {
> struct dma_chan chan;
> struct dma_async_tx_descriptor txd;
> @@ -307,7 +310,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
> __iormb();
>
> while (val) {
> - u32 desc;
> + u32 desc, len;
>
> q_num = __fls(val);
> val &= ~(1 << q_num);
> @@ -319,9 +322,13 @@ static irqreturn_t cppi41_irq(int irq, void *data)
> q_num, desc);
> continue;
> }
> - c->residue = pd_trans_len(c->desc->pd6) -
> - pd_trans_len(c->desc->pd0);
>
> + if (c->desc->pd2 & PD2_ZERO_LENGTH)
> + len = 0;
> + else
> + len = pd_trans_len(c->desc->pd0);
> +
> + c->residue = pd_trans_len(c->desc->pd6) - len;
> dma_cookie_complete(&c->txd);
> c->txd.callback(c->txd.callback_param);
> }
>
--
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: skbuff truesize incorrect.
From: Eric Dumazet Date: Thu, 22 May 2014 14:03:21 -0700 > On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote: > >> I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not >> use high order allocations. > > Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN), > because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align(). I seem to recall that this driver has a lot of strange buffering restrictions and that Bjorn Mork was talking a lot about this recently. Bjorn people are getting really burnt because the driver ends up having a skb->truesize of 32K for the buffers it allocates on receive and this chokes up TCP and SCTP because the socket memory limits are hitting earlier than they should. We've just in the past few postings been discussing whether the just copy every packet into a more appropriately sized buffer, and it isn't clear if that's a good idea of the data rates handled here. -- 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: skbuff truesize incorrect.
On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote: > I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not > use high order allocations. Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN), because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align(). -- 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: skbuff truesize incorrect.
From: Jim Baxter Date: Thu, 22 May 2014 21:21:55 +0100 > If there are multiple clones for an skb all pointing at the same data, > will that distort the memory used when they all have the same truesize? What is distorted about it? Each clone references exactly that much backing memory. -- 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: skbuff truesize incorrect.
On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote: > > I have been investigating a network issue with bursts of network traffic > over USB CDC-NCM, the issue is that the kernel is dropping packets > because sk_rcvqueues_full() returns true due to skb2->truesize is always > 32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800. > > The code I am trying to fix is this code below, it is splitting a set of > multiple network packets compressed into a single 16k packet into > individual skb's and sending them up the network stack. if skb are allocated with 16k = 16384 bytes, adding the struct skb_shared_info overhead and rounding up to power of two gives 32768 bytes. Chances to be able to allocate 32KB contiguous memory are slim after a while. I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not use high order allocations. What is the exact 'overhead' using ~4K instead of 16K exactly on this hardware ? -- 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 v4 1/6] usb: musb: core: Handle Babble condition only in HOST mode
Hi George,
On Mon, May 19, 2014 at 11:32 PM, George Cherian wrote:
> Hi Bin,
>
> On 5/19/2014 9:24 PM, Bin Liu wrote:
>>
>> Hi,
>>
>> On Mon, May 19, 2014 at 8:39 AM, George Cherian
>> wrote:
>>>
>>> BABBLE and RESET share the same interrupt. The interrupt
>>> is considered to be RESET if MUSB is in peripheral mode and
>>> as a BABBLE if MUSB is in HOST mode.
>>>
>>> Handle babble condition iff MUSB is in HOST mode.
>>>
>>> Signed-off-by: George Cherian
>>> ---
>>> drivers/usb/musb/musb_core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>>> index 61da471..eff3c5c 100644
>>> --- a/drivers/usb/musb/musb_core.c
>>> +++ b/drivers/usb/musb/musb_core.c
>>> @@ -849,7 +849,7 @@ b_host:
>>> }
>>>
>>> /* handle babble condition */
>>> - if (int_usb & MUSB_INTR_BABBLE)
>>> + if (int_usb & MUSB_INTR_BABBLE && is_host_active(musb))
>>> schedule_work(&musb->recover_work);
>>
>> I guess my following comments are for Daniel's patch as while which
>> initially added the babble work.
>>
>> Should this if statement be merged into the previous 'if(int_usb &
>> MUSB_INTR_RESET)' one, which handles the same interrupt and already
>> handles host and device mode respectively.
>
>
> Initially I too had the babble handling as part of 'if(int_usb &
> MUSB_INTR_RESET)'
> one. But during my tests I hit a corner case where in we hit a BABBLE
> condition
> on disconnect. In such case the babble interrupt can be handled only if we
> have a seperate
> check, else its considered as a BUS RESET.
>
> When all devices are disconnected MUSB_DEVCTL_HM = 0 and the code always
> enter the
> else path. In this path it treats the BABBLE as a BUS RESET.
The code flow is a bit confusing, two if() handle the same interrupt.
The second one implied using 'handled = IRQ_HANDLED;' from the first
one.
Also does the switch() in else{} in the first if() cause any side effect?
Since this babble handing is AM335x specific, how about handle it in
dsps_interrupt() in musb_dsps.c, which already has an entry for babble
interrupt? TI 3.2 kernel does this way.
Regards,
-Bin.
>
>
>> Regards,
>> -Bin.
>>
>>> #if 0
>>> --
>>> 1.8.3.1
>>>
>>> --
>>> 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
>
>
>
> --
> -George
>
--
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: skbuff truesize incorrect.
On 22/05/14 20:59, Eric Dumazet wrote: > On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote: > >> I now think that the correct solution here is to create a new smaller >> skb and copy the data from the sub packets into it. > > For low speed devices, this is indeed the best way. > > (this is called copybreak in some nic drivers) > > > Thank you Eric. It is USB device that can handle 480Mbits/s so a middle speed device. It looks like it is the normal trade off of speed versus memory. Either I can use skb_clone for speed but that will impact memory with multiple skb's of 16k or I copy the data to keep the memory usage low. Though copying 2k of data into an skb will not likely be a massive overhead. Jim -- 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: skbuff truesize incorrect.
On Thu, 2014-05-22 at 21:21 +0100, Jim Baxter wrote: > OK, so it is the value of the memory that has been allocated for the SKB. > If there are multiple clones for an skb all pointing at the same data, > will that distort the memory used when they all have the same truesize? Its always better to over estimate memory uses, than under estimating. Its all about guarding against OOM. Keep in mind some parts of networking stack do not like clones. TCP coalescing works beautifully with non cloned skbs. Instead of cloning skb or doing copies, you could play with having frame on a page fragment. Only headers might need to be pulled from the frame to linear part of skb. -- 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: skbuff truesize incorrect.
On 22/05/14 20:21, David Miller wrote: > From: Jim Baxter > Date: Thu, 22 May 2014 20:07:41 +0100 > >> My questions are: >> >> 1) Which buffer size does truesize represent, is it the total buffer or >> just the data related to the relevant skb? >> >> 2) If truesize is for the skb it is contained within should it be >> updated during the call to skb_trim? >> >> 3) Why does the truesize default to 32960? > > skb->truesize represents the total amount of memory that the SKB > is holding up. > > This is the size of the sk_buff metadata plus all of the buffer > memory. > > For example, if the buffer is using 16K buffer yet only 1500 of it is > actually used for the packet, 16K is what should be plugged into the > equation to compute truesize. > > Otherwise it would be easy to compromise a system by sending lots of 1 > byte packets to a socket, even though the actual memory consumed by > that "1 byte" packet is significantly larger. > OK, so it is the value of the memory that has been allocated for the SKB. If there are multiple clones for an skb all pointing at the same data, will that distort the memory used when they all have the same truesize? -- 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] Add can_do_streams to dummy_hcd
I was puzzled why uas didn't accept to bind to tcm_usb_gadget via dummy_hcd. Debugging showed that recent commit (14aec589327a6fc4035f5327d90ac5548f501c4c) added the field can_do_streams to hcd structure but only set it to 1 in the xhci driver. dummy_hcd seems to support superspeed and streams fine, so I added can_do_streams = 1 to dummy_hcd as well. This seems to allow uas to bind again and as a result performance increased more than 3x :) --- drivers/usb/gadget/dummy_hcd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c index 8c06430..67ebf90 100644 --- a/drivers/usb/gadget/dummy_hcd.c +++ b/drivers/usb/gadget/dummy_hcd.c @@ -2544,6 +2544,8 @@ static int dummy_hcd_probe(struct platform_device *pdev) retval = usb_add_hcd(ss_hcd, 0, 0); if (retval) goto put_usb3_hcd; + + ss_hcd->can_do_streams = 1; } return 0; -- 1.9.1 -- 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: skbuff truesize incorrect.
On Thu, 2014-05-22 at 20:39 +0100, Jim Baxter wrote: > I now think that the correct solution here is to create a new smaller > skb and copy the data from the sub packets into it. For low speed devices, this is indeed the best way. (this is called copybreak in some nic drivers) -- 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: skbuff truesize incorrect.
On 22/05/14 20:25, Vlad Yasevich wrote:
> On 05/22/2014 03:07 PM, Jim Baxter wrote:
>>
>> skb2 = skb_clone(skb, GFP_ATOMIC);
>> if (skb2 == NULL)
>> goto err;
>>
>> if (!skb_pull(skb2, index)) {
>> ret = -EOVERFLOW;
>> goto err;
>> }
>
> This assumes that you original 16K packet is linear. Is that
> always the case?
The packets within the original packet are linear, however they could be
in an arbitrary order because they are just offsets from the start of
the 16k skb.
>
> This is the very same problem that I ran into with SCTP since it
> has similar code in it. You can play games with truesize manually,
> but you have to be very careful here.
>
> -vlad
I now think that the correct solution here is to create a new smaller
skb and copy the data from the sub packets into it.
Jim
--
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: skbuff truesize incorrect.
On 05/22/2014 03:07 PM, Jim Baxter wrote:
> Hi, I was hoping you can help me with some questions.
>
> I have been investigating a network issue with bursts of network traffic
> over USB CDC-NCM, the issue is that the kernel is dropping packets
> because sk_rcvqueues_full() returns true due to skb2->truesize is always
> 32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800.
>
> The code I am trying to fix is this code below, it is splitting a set of
> multiple network packets compressed into a single 16k packet into
> individual skb's and sending them up the network stack.
>
> skb2 = skb_clone(skb, GFP_ATOMIC);
> if (skb2 == NULL)
> goto err;
>
> if (!skb_pull(skb2, index)) {
> ret = -EOVERFLOW;
> goto err;
> }
This assumes that you original 16K packet is linear. Is that
always the case?
>
> skb_trim(skb2, dg_len - crc_len);
>
> My questions are:
>
> 1) Which buffer size does truesize represent, is it the total buffer or
> just the data related to the relevant skb?
Total buffer size (including the struct sk_buff).
>
> 2) If truesize is for the skb it is contained within should it be
> updated during the call to skb_trim?
No, because the the buffer/memory is still there. skb_trim just
sets the tail pointer and adjusts skb->len.
>
> 3) Why does the truesize default to 32960?
Probably because that's how much buffer space was actually allocated
for the original skb. When you cloned it, you inherited the truesize
since a clone is just the struct sk_buff that points into the data
of the original.
This is the very same problem that I ran into with SCTP since it
has similar code in it. You can play games with truesize manually,
but you have to be very careful here.
-vlad
>
>
> Thank you for any help,
> Jim Baxter.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skbuff truesize incorrect.
From: Jim Baxter Date: Thu, 22 May 2014 20:07:41 +0100 > My questions are: > > 1) Which buffer size does truesize represent, is it the total buffer or > just the data related to the relevant skb? > > 2) If truesize is for the skb it is contained within should it be > updated during the call to skb_trim? > > 3) Why does the truesize default to 32960? skb->truesize represents the total amount of memory that the SKB is holding up. This is the size of the sk_buff metadata plus all of the buffer memory. For example, if the buffer is using 16K buffer yet only 1500 of it is actually used for the packet, 16K is what should be plugged into the equation to compute truesize. Otherwise it would be easy to compromise a system by sending lots of 1 byte packets to a socket, even though the actual memory consumed by that "1 byte" packet is significantly larger. -- 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
skbuff truesize incorrect.
Hi, I was hoping you can help me with some questions.
I have been investigating a network issue with bursts of network traffic
over USB CDC-NCM, the issue is that the kernel is dropping packets
because sk_rcvqueues_full() returns true due to skb2->truesize is always
32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800.
The code I am trying to fix is this code below, it is splitting a set of
multiple network packets compressed into a single 16k packet into
individual skb's and sending them up the network stack.
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2 == NULL)
goto err;
if (!skb_pull(skb2, index)) {
ret = -EOVERFLOW;
goto err;
}
skb_trim(skb2, dg_len - crc_len);
My questions are:
1) Which buffer size does truesize represent, is it the total buffer or
just the data related to the relevant skb?
2) If truesize is for the skb it is contained within should it be
updated during the call to skb_trim?
3) Why does the truesize default to 32960?
Thank you for any help,
Jim Baxter.
--
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] DWC2: intializes the spin_lock earlier in the probe
> From: Jean-Jacques Hiblot [mailto:jjhib...@traphandler.com]
> Sent: Thursday, May 22, 2014 5:10 AM
>
> The spinlock hsotg->lock is intialized at the end of the probe. However it
> may be used from within dwc2_hcd_init(). This patch moves the
> initialization before the call to dwc2_hcd_init(). This make the locking
> correctness validator happy.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
> drivers/usb/dwc2/platform.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 37a8ab0..55fb30d 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -156,6 +156,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
> params.dma_desc_enable = prop;
> }
>
> + spin_lock_init(&hsotg->lock);
> +
> if (IS_ENABLED(CONFIG_USB_DWC2_HOST)) {
> retval = dwc2_hcd_init(hsotg, irq, ¶ms);
> if (retval)
> @@ -175,7 +177,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
> if (retval)
> return retval;
> }
> - spin_lock_init(&hsotg->lock);
>
> platform_set_drvdata(dev, hsotg);
> return retval;
> --
Hmm. What tree is this against? platform.c in both Linus' tree and in
Greg's usb-next tree does not have a call to spin_lock_init().
--
Paul
--
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: Runtime PM workqueue killing system performance with USB
On Thu, 22 May 2014, Will Deacon wrote: > > Anyway, there are two possible ways of handling this. One is to avoid > > changing the error code to -EBUSY when the device in question is a root > > hub. Just let it go into a runtime-PM error state; it won't matter > > since the controller doesn't support runtime PM anyway. You can test > > this by changing the "if (status != 0)" line in usb_runtime_suspend to > > > > if (status != 0 && udev->parent) > > I'd tried something like this already, but I prefer your patch below. Plus, > this hack results in a failure being logged to dmesg on the initial suspend > attempt. > > > The other approach is to disable runtime PM for the root hub when the > > host controller driver doesn't have a bus_suspend or bus_resume method. > > This seems like a cleaner approach; the patch below implements it. > > Thanks for this! I can confirm that your patch below fixes the issue for me, > so: > > Reported-by: Will Deacon > Tested-by: Will Deacon You know, I think it might be best to make both changes. Even though runtime PM will be disabled by default, the user can always override this setting. If that happens, the suspend should fail with the proper error code instead of going into a loop. Do you mind if I add the change to usb_runtime_suspend() in the patch? 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 V2] USB: Add LVS Test device driver
On Thu, 22 May 2014, Pratyush Anand wrote:
> OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification
> system (SS-OVS) which consists of an excersizer and analyzer.
>
> USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for
> Link Layer Validation (LVS).
>
> Some modifications are needed for an embedded Linux USB host to pass all
> these tests. Most of these tests require just Link to be in U0. They do
> not work with default Linux USB stack since, default stack does port
> reset and then starts sending setup packet, which is not expected by
> Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then,
> There are many Link Layer Tests which need host to generate specific
> traffic.
>
> This patch supports specific traffic generation cases. As of now all the
> host Lecroy Link Layer-USBIF tests (except TD7.26) passes
> with this patch for single run using Lecroy USB Compliance Suite
> Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80
> Build 1603. Therefore patch seems to be a good candidate for inclusion.
> Further modification can be done on top of it.
>
> lvstest driver will not bind to any device by default. It can bind
> manually to a super speed USB host controller root hub. Therefore, regular
> hub driver must be unbound before this driver is bound. For example, if
> 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver.
>
> echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind
>
> Then to bind lvs driver write Linux Foundation's vendor ID and SS root
> hub's device ID into new_id file.
>
> echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id
>
> Now connect LVS device with root hub port.
You forgot to include an example here showing how to do this:
echo 2-0\:1.0 > /sys/bus/usb/drivers/lvs/bind
> Test case specific traffic can be generated as follows whenever needed:
>
> 1. To issue "Get Device descriptor" command for TD.7.06:
> echo 1 > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc
>
> 2. To set U1 timeout to 127 for TD.7.18
> echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout
>
> 3. To set U2 timeout to 0 for TD.7.18
> echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout
>
> 4. To issue "Hot Reset" for TD.7.29
> echo 1 > /sys/bus/usb/devices/2-0\:1.0/hot_reset
>
> 5. To issue "U3 Entry" for TD.7.35
> echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_entry
>
> 6. To issue "U3 Exit" for TD.7.36
> echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_exit
None of those example need to contain the "1". For instance, the last
one should be written:
echo > /sys/bus/usb/devices/2-0\:1.0/u3_exit
> diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> new file mode 100644
> index 000..f47e8a3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest
> @@ -0,0 +1,47 @@
> +Link Layer Validation Device is a standard device for testing of Super
> +Speed Link Layer tests. These nodes are available in sysfs only when lvs
> +driver is bound with root hub device.
> +
> +What:/sys/bus/usb/devices/.../get_dev_desc
> +Date:March 2014
> +Contact: Pratyush Anand
> +Description:
> + Write to this node to issue "Get Device Descriptor"
> + for Link Layer Validation device. It is needed for TD.7.06.
> +
> +What:/sys/bus/usb/devices/.../u1_timeout
> +Date:March 2014
> +Contact: Pratyush Anand
> +Description:
> + Set "U1 timeout" for the downstream port where Link Layer
> + Validation device is connected. It is needed for TD.7.18,
> + TD.7.19, TD.7.20 and TD.7.21.
This doesn't say that the value must be between 0 and 127.
> +
> +What:/sys/bus/usb/devices/.../u2_timeout
> +Date:March 2014
> +Contact: Pratyush Anand
> +Description:
> + Set "U2 timeout" for the downstream port where Link Layer
> + Validation device is connected. It is needed for TD.7.18,
> + TD.7.19, TD.7.20 and TD.7.21.
Same here.
> +static void lvs_rh_work(struct work_struct *work)
> +{
> + struct lvs_rh *lvs = container_of(work, struct lvs_rh, rh_work);
> + struct usb_interface *intf = lvs->intf;
> + struct usb_device *hdev = interface_to_usbdev(intf);
> + struct usb_hcd *hcd = bus_to_hcd(hdev->bus);
> + struct usb_hub_descriptor *descriptor = &lvs->descriptor;
> + struct usb_port_status port_status;
> + int i, ret = 0;
> +
> + /* Examine each root port */
> + for (i = 1; i <= descriptor->bNbrPorts; i++) {
> + ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
> + USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, i,
> + &port_status, sizeof(port_status), 1000);
You must not use I/O buffers allocated on the stack. The buffer must
be allocated by kmalloc or something equivalent.
> + if (ret <
Re: Runtime PM workqueue killing system performance with USB
Hi Alan,
On Thu, May 22, 2014 at 04:02:06PM +0100, Alan Stern wrote:
> On Thu, 22 May 2014, Will Deacon wrote:
> > Consequently, I see a kworker thread on each CPU consuming a significant
> > amount of the system resources. Worse, if I enable something like kmemleak
> > (which adds more work to the failed suspend operation), I end up failing
> > to boot entirely (NFS bombs out).
> >
> > Reverting db7c7c0aeef5 ("usb: Always return 0 or -EBUSY to the runtime
> > PM core.") fixes this for me, but the commit log suggests that will break
> > lsusb. That patch has also been in for three and a half years...
> >
> > Any ideas on how to fix this properly? In what ways does the PM core react
> > badly to -ENOENT?
>
> Okay, this is a bad problem.
>
> The PM core takes any error response other than -EBUSY or -EAGAIN as an
> indication that the device is in a runtime-PM error state. While that
> is appropriate for a USB device, perhaps it's not so appropriate for a
> USB host controller.
>
> Anyway, there are two possible ways of handling this. One is to avoid
> changing the error code to -EBUSY when the device in question is a root
> hub. Just let it go into a runtime-PM error state; it won't matter
> since the controller doesn't support runtime PM anyway. You can test
> this by changing the "if (status != 0)" line in usb_runtime_suspend to
>
> if (status != 0 && udev->parent)
I'd tried something like this already, but I prefer your patch below. Plus,
this hack results in a failure being logged to dmesg on the initial suspend
attempt.
> The other approach is to disable runtime PM for the root hub when the
> host controller driver doesn't have a bus_suspend or bus_resume method.
> This seems like a cleaner approach; the patch below implements it.
Thanks for this! I can confirm that your patch below fixes the issue for me,
so:
Reported-by: Will Deacon
Tested-by: Will Deacon
Cheers,
Will
> Index: usb-3.15/drivers/usb/core/hub.c
> ===
> --- usb-3.15.orig/drivers/usb/core/hub.c
> +++ usb-3.15/drivers/usb/core/hub.c
> @@ -1703,8 +1703,19 @@ static int hub_probe(struct usb_interfac
>*/
> pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
>
> - /* Hubs have proper suspend/resume support. */
> - usb_enable_autosuspend(hdev);
> + /*
> + * Hubs have proper suspend/resume support, except for root hubs
> + * where the controller driver doesn't have bus_suspend and
> + * bus_resume methods.
> + */
> + if (hdev->parent) { /* normal device */
> + usb_enable_autosuspend(hdev);
> + } else {/* root hub */
> + const struct hc_driver *drv = bus_to_hcd(hdev->bus)->driver;
> +
> + if (drv->bus_suspend && drv->bus_resume)
> + usb_enable_autosuspend(hdev);
> + }
>
> if (hdev->level == MAX_TOPO_LEVEL) {
> dev_err(&intf->dev,
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: usbtest: add pattern check on pipe in phase of unlink read
On Thu, 22 May 2014, Huang Rui wrote: > TEST 11 unlinks the URB read request for N times. When host and gadget > both initialize pattern 1 (mod 63) data series to do IN transfer, the > host side function should check the data buffer if it is as mod 63 > series, because the data packet which host receivced will follow > pattern 1. So this patch adds this checking action. > > Signed-off-by: Huang Rui Maybe you should also change the unlink_queued() routine, which is used in Test 24. 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] usb: ehci: Enable support for 64bit EHCI host controllers in arm64
On Thu, 2014-05-22 at 16:59 +0100, Catalin Marinas wrote: > On Mon, May 19, 2014 at 09:21:17AM +0100, Jon Medhurst (Tixy) wrote: > > On Fri, 2014-05-16 at 18:40 +0100, Catalin Marinas wrote: > > > On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote: > > > > On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote: > > > > [...] > > > > > > It could if arm64 would restrict the DMA addresses to 32-bit, but > > > > > > it doesn't > > > > > > and I end up on my platform with USB DMA buffers allocated >4GB > > > > > > address. > > > > > > > > > > dma_alloc_coherent() on arm64 should return 32-bit addresses if the > > > > > coherent_dma_mask is set to 32-bit. > > > > > > > > Not if you have CONFIG_DMA_CMA. Unless I have misread the code, enabling > > > > CMA means memory comes from a common pool carved out at boot with no way > > > > for drivers to specify it's restrictions [1]. It's what I've spent most > > > > of the week trying to work around in a clean way, and have finally given > > > > up. > > > > > > The easiest "hack" would be to pass a limit dma_contiguous_reserve() > > > in arm64_memblock_init(), something like this: > > > > That is by far the easiest but I dismissed it because it affects all > > platforms built from that source tree; and if the hack were extended to > > include a kernel config option, that still may not work on a single > > kernel binary expected to work on multiple platforms. Basically, I've > > tried various was to do it 'properly' and after failing am resorting to > > truly hideous hacks to the (out-of-tree driver) code - so at least other > > platforms won't be impacted. > > Can you set a specific reserved memory region in the DT to be used by > CMA (via linux,cma-default), or it's just for the default size? The bindings and infrastructure got half merged in 3.15 but the patches to actually make this usable in drivers are stalled... http://lkml.org/lkml/2014/5/14/201 > On arm64 we enabled CONFIG_DMA_CMA by default but compared to swiotlb it > doesn't honour GFP_DMA. The arm32 port sets the CMA limit to > arm_dma_limit which is 32-bit or a SoC-define one. So I'm tempted to > default to 32-bit as well if it can be overridden via DT. I believe the CMA pool could have been over-ridden if the stalled patches been accepted. I believe the specific patch for that is http://lkml.org/lkml/2014/2/28/278 The bindings for all this CMA stuf is in Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: Enable support for 64bit EHCI host controllers in arm64
On Mon, May 19, 2014 at 09:21:17AM +0100, Jon Medhurst (Tixy) wrote: > On Fri, 2014-05-16 at 18:40 +0100, Catalin Marinas wrote: > > On Fri, May 16, 2014 at 06:08:45PM +0100, Jon Medhurst (Tixy) wrote: > > > On Fri, 2014-05-16 at 13:55 +0100, Catalin Marinas wrote: > > > [...] > > > > > It could if arm64 would restrict the DMA addresses to 32-bit, but it > > > > > doesn't > > > > > and I end up on my platform with USB DMA buffers allocated >4GB > > > > > address. > > > > > > > > dma_alloc_coherent() on arm64 should return 32-bit addresses if the > > > > coherent_dma_mask is set to 32-bit. > > > > > > Not if you have CONFIG_DMA_CMA. Unless I have misread the code, enabling > > > CMA means memory comes from a common pool carved out at boot with no way > > > for drivers to specify it's restrictions [1]. It's what I've spent most > > > of the week trying to work around in a clean way, and have finally given > > > up. > > > > The easiest "hack" would be to pass a limit dma_contiguous_reserve() > > in arm64_memblock_init(), something like this: > > That is by far the easiest but I dismissed it because it affects all > platforms built from that source tree; and if the hack were extended to > include a kernel config option, that still may not work on a single > kernel binary expected to work on multiple platforms. Basically, I've > tried various was to do it 'properly' and after failing am resorting to > truly hideous hacks to the (out-of-tree driver) code - so at least other > platforms won't be impacted. Can you set a specific reserved memory region in the DT to be used by CMA (via linux,cma-default), or it's just for the default size? On arm64 we enabled CONFIG_DMA_CMA by default but compared to swiotlb it doesn't honour GFP_DMA. The arm32 port sets the CMA limit to arm_dma_limit which is 32-bit or a SoC-define one. So I'm tempted to default to 32-bit as well if it can be overridden via DT. -- Catalin -- 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 6/7] usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's CSR
When a DMA request is continued and a new inbound packet is requested,
make sure we're operating on the right endpooint. Otherwise, no new
packet is requested and the stream starves.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_cppi41.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index a11bbb6..e568930 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -173,6 +173,7 @@ static void cppi41_trans_done(struct cppi41_dma_channel
*cppi41_channel)
dma_async_issue_pending(dc);
if (!cppi41_channel->is_tx) {
+ musb_ep_select(musb->mregs, hw_ep->epnum);
csr = musb_readw(epio, MUSB_RXCSR);
csr |= MUSB_RXCSR_H_REQPKT;
musb_writew(epio, MUSB_RXCSR, csr);
--
1.9.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
[PATCH 5/7] usb: musb: introduce dma_channel.packet_done
The musb/cppi41 glue layer is capable of handling transactions that span
over more than one USB packet by reloading the DMA descriptors
partially. An urb is considered completed when either its transfer
buffer has been filled entirely (actual_length ==
transfer_buffer_length) or if a packet in the stream has less bytes than
the endpoint's wMaxPacketSize.
Once one of the above conditions is met, musb_dma_completion() is called
from cppi41_trans_done(). However, the final decision whether or not to
return the urb to its owner is made by the core, which currently has no
way of knowing what the last packet size was, as long as DMA and a glue
layer is involved. Hence, it won't give the urb back, effectively
starving the data stream.
Fix this by introducing a new boolean flag in 'struct dma_channel'
which, and set it from musb_cppi41.c. If set, it will make the core do
what the DMA layer decided and complete the urb.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_cppi41.c | 2 ++
drivers/usb/musb/musb_dma.h| 1 +
drivers/usb/musb/musb_host.c | 3 ++-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index 7b8bbf5..a11bbb6 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -139,6 +139,7 @@ static void cppi41_trans_done(struct cppi41_dma_channel
*cppi41_channel)
cppi41_channel->channel.actual_len =
cppi41_channel->transferred;
cppi41_channel->channel.status = MUSB_DMA_STATUS_FREE;
+ cppi41_channel->channel.packet_done = true;
musb_dma_completion(musb, hw_ep->epnum, cppi41_channel->is_tx);
} else {
/* next iteration, reload */
@@ -450,6 +451,7 @@ static bool cppi41_configure_channel(struct dma_channel
*channel,
dma_desc->callback = cppi41_dma_callback;
dma_desc->callback_param = channel;
cppi41_channel->cookie = dma_desc->tx_submit(dma_desc);
+ cppi41_channel->channel.packet_done = false;
save_rx_toggle(cppi41_channel);
dma_async_issue_pending(dc);
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 1345a4f..7253358 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -129,6 +129,7 @@ struct dma_channel {
size_t actual_len;
enum dma_channel_status status;
booldesired_mode;
+ boolpacket_done;
};
/*
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 9d3a5b2..6531426 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1738,7 +1738,8 @@ void musb_host_rx(struct musb *musb, u8 epnum)
/* done if urb buffer is full or short packet is recd */
done = (urb->actual_length + xfer_len >=
urb->transfer_buffer_length
- || dma->actual_len < qh->maxpacket);
+ || dma->actual_len < qh->maxpacket
+ || dma->packet_done);
}
/* send IN token for next packet, without AUTOREQ */
--
1.9.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
[PATCH 7/7] usb: musb/cppi41: read data toggle from right endpoint
The fixup for Advisory 1.0.13 ("USB: data may be lost when USB subsystem
is operating in DMA mode and more than one endpoint is transferring
data") reads the USB data toggle each time a packet is given back from
the DMA controller. It does so in order to detect mismatches and
restoring the DATA1 toggle which might have erroneously been dropped, as
described as a workaround in the errata.
However, as the endpoint is not explictly selected before reading the
CSR register, the code operates on wrong register data and detects
mismatches where none are. By fixing up in such occasions, the toggle
mechanism is confused, and the controller drops packets that are out of
sync.
Fix this by calling musb_ep_select() in those functions.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_cppi41.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_cppi41.c b/drivers/usb/musb/musb_cppi41.c
index e568930..38fd1d1 100644
--- a/drivers/usb/musb/musb_cppi41.c
+++ b/drivers/usb/musb/musb_cppi41.c
@@ -58,14 +58,17 @@ struct cppi41_dma_controller {
static void save_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
{
+ struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
+ struct musb *musb = hw_ep->musb;
u16 csr;
u8 toggle;
if (cppi41_channel->is_tx)
return;
- if (!is_host_active(cppi41_channel->controller->musb))
+ if (!is_host_active(musb))
return;
+ musb_ep_select(musb->mregs, hw_ep->epnum);
csr = musb_readw(cppi41_channel->hw_ep->regs, MUSB_RXCSR);
toggle = csr & MUSB_RXCSR_H_DATATOGGLE ? 1 : 0;
@@ -74,15 +77,18 @@ static void save_rx_toggle(struct cppi41_dma_channel
*cppi41_channel)
static void update_rx_toggle(struct cppi41_dma_channel *cppi41_channel)
{
+ struct musb_hw_ep *hw_ep = cppi41_channel->hw_ep;
+ struct musb *musb = hw_ep->musb;
u16 csr;
u8 toggle;
if (cppi41_channel->is_tx)
return;
- if (!is_host_active(cppi41_channel->controller->musb))
+ if (!is_host_active(musb))
return;
- csr = musb_readw(cppi41_channel->hw_ep->regs, MUSB_RXCSR);
+ musb_ep_select(musb->mregs, hw_ep->epnum);
+ csr = musb_readw(hw_ep->regs, MUSB_RXCSR);
toggle = csr & MUSB_RXCSR_H_DATATOGGLE ? 1 : 0;
/*
--
1.9.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
[PATCH 4/7] usb: musb: fix bit masks for CSR in musb_h_tx_flush_fifo()
The datasheet says that MUSB_TXCSR_FLUSHFIFO is only valid when MUSB_CSR0_TXPKTRDY is set as well. Also, clear the MUSB_TXCSR_H_RXSTALL which drivers are not supposed to write, according to the docs. With this patch applied, the warning in this function does no longer kicks in when an USB soundcard was unplugged while the stream was active. Signed-off-by: Daniel Mack --- drivers/usb/musb/musb_host.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c index f98a7c0..9d3a5b2 100644 --- a/drivers/usb/musb/musb_host.c +++ b/drivers/usb/musb/musb_host.c @@ -120,7 +120,8 @@ static void musb_h_tx_flush_fifo(struct musb_hw_ep *ep) if (csr != lastcsr) dev_dbg(musb->controller, "Host TX FIFONOTEMPTY csr: %02x\n", csr); lastcsr = csr; - csr |= MUSB_TXCSR_FLUSHFIFO; + csr &= MUSB_TXCSR_H_RXSTALL; + csr |= MUSB_TXCSR_FLUSHFIFO | MUSB_CSR0_TXPKTRDY; musb_writew(epio, MUSB_TXCSR, csr); csr = musb_readw(epio, MUSB_TXCSR); if (WARN(retries-- < 1, -- 1.9.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
[PATCH 2/7] usb: musb: remove unnecessary (void) prefix at function calls
There's no point in casting these return value to void.
Remove it.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index eb06291..f98a7c0 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -1295,7 +1295,7 @@ done:
if (status) {
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
- (void) musb->dma_controller->channel_abort(dma);
+ musb->dma_controller->channel_abort(dma);
}
/* do the proper sequence to abort the transfer in the
@@ -1640,7 +1640,7 @@ void musb_host_rx(struct musb *musb, u8 epnum)
/* clean up dma and collect transfer count */
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
- (void) musb->dma_controller->channel_abort(dma);
+ musb->dma_controller->channel_abort(dma);
xfer_len = dma->actual_len;
}
musb_h_flush_rxfifo(hw_ep, MUSB_RXCSR_CLRDATATOG);
@@ -1671,7 +1671,7 @@ void musb_host_rx(struct musb *musb, u8 epnum)
*/
if (dma_channel_status(dma) == MUSB_DMA_STATUS_BUSY) {
dma->status = MUSB_DMA_STATUS_CORE_ABORT;
- (void) musb->dma_controller->channel_abort(dma);
+ musb->dma_controller->channel_abort(dma);
xfer_len = dma->actual_len;
done = true;
}
--
1.9.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
[PATCH 3/7] usb: musb: use is_host_active() to distinguish between host and gadget mode
On AM33xx platforms, unplugging a device in the middle of an active
transfer leads to a drop of MUSB_DEVCTL_HM in MUSB_DEVCTL before the
system is informed about a disconnect. This consequently makes the musb
core call the gadget code to handle the interrupt request, which then
crashes the kernel because the relevant pointers haven't been set up
for gadget mode.
To fix this, use is_host_active() rather than (devctl & MUSB_DEVCTL_HM)
in musb_interrupt() and musb_dma_completion() to detect whether the
controller is in host or peripheral mode.
Signed-off-by: Daniel Mack
---
drivers/usb/musb/musb_core.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 1f8b175..a496af6 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1518,7 +1518,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
dev_dbg(musb->controller, "** IRQ %s usb%04x tx%04x rx%04x\n",
- (devctl & MUSB_DEVCTL_HM) ? "host" : "peripheral",
+ is_host_active(musb) ? "host" : "peripheral",
musb->int_usb, musb->int_tx, musb->int_rx);
/* the core can interrupt us for multiple reasons; docs have
@@ -1532,7 +1532,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
/* handle endpoint 0 first */
if (musb->int_tx & 1) {
- if (devctl & MUSB_DEVCTL_HM)
+ if (is_host_active(musb))
retval |= musb_h_ep0_irq(musb);
else
retval |= musb_g_ep0_irq(musb);
@@ -1546,7 +1546,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
/* musb_ep_select(musb->mregs, ep_num); */
/* REVISIT just retval = ep->rx_irq(...) */
retval = IRQ_HANDLED;
- if (devctl & MUSB_DEVCTL_HM)
+ if (is_host_active(musb))
musb_host_rx(musb, ep_num);
else
musb_g_rx(musb, ep_num);
@@ -1564,7 +1564,7 @@ irqreturn_t musb_interrupt(struct musb *musb)
/* musb_ep_select(musb->mregs, ep_num); */
/* REVISIT just retval |= ep->tx_irq(...) */
retval = IRQ_HANDLED;
- if (devctl & MUSB_DEVCTL_HM)
+ if (is_host_active(musb))
musb_host_tx(musb, ep_num);
else
musb_g_tx(musb, ep_num);
@@ -1586,15 +1586,13 @@ MODULE_PARM_DESC(use_dma, "enable/disable use of DMA");
void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit)
{
- u8 devctl = musb_readb(musb->mregs, MUSB_DEVCTL);
-
/* called with controller lock already held */
if (!epnum) {
#ifndef CONFIG_USB_TUSB_OMAP_DMA
if (!is_cppi_enabled()) {
/* endpoint 0 */
- if (devctl & MUSB_DEVCTL_HM)
+ if (is_host_active(musb))
musb_h_ep0_irq(musb);
else
musb_g_ep0_irq(musb);
@@ -1603,13 +1601,13 @@ void musb_dma_completion(struct musb *musb, u8 epnum,
u8 transmit)
} else {
/* endpoints 1..15 */
if (transmit) {
- if (devctl & MUSB_DEVCTL_HM)
+ if (is_host_active(musb))
musb_host_tx(musb, epnum);
else
musb_g_tx(musb, epnum);
} else {
/* receive */
- if (devctl & MUSB_DEVCTL_HM)
+ if (is_host_active(musb))
musb_host_rx(musb, epnum);
else
musb_g_rx(musb, epnum);
--
1.9.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
[PATCH 0/7] Multiple fixes for musb and cppi41
I've been trying to use the musb host controller for devices other than USB mass storage like Wifi-Sticks and USB audio cards, and ran into a larger number of nasty issues. After staring at hexdumps for the better part of the last couple of days, I finally fixed all of them. I used an external hardware USB analyzer to track down lost packets, data toggle mismatches and stream starvation. Here are 7 patches to fix the issues I've seen. Most of them affect the musb <-> cppi41 glue layer, and #1 is for the cppi41 DMA driver. Vinod, you can safely merge this one through your tree, as there's no dependency to any other patch, and it's clearly fixing a bug. Also, I'd actually say that all but #2 are candidates for stable@, but I leave it to Felipe to decide that :) Please have a look. More tests on AM335x are very welcome, and so are regression tests for any other platform. Thank, Daniel Daniel Mack (7): dma: cppi41: handle 0-length packets usb: musb: remove unnecessary (void) prefix at function calls usb: musb: use is_host_active() to distinguish between host and gadget mode usb: musb: fix bit masks for CSR in musb_h_tx_flush_fifo() usb: musb: introduce dma_channel.packet_done usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's CSR usb: musb/cppi41: read data toggle from right endpoint drivers/dma/cppi41.c | 13 ++--- drivers/usb/musb/musb_core.c | 16 +++- drivers/usb/musb/musb_cppi41.c | 15 --- drivers/usb/musb/musb_dma.h| 1 + drivers/usb/musb/musb_host.c | 12 +++- 5 files changed, 37 insertions(+), 20 deletions(-) -- 1.9.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
[PATCH 1/7] dma: cppi41: handle 0-length packets
When a 0-length packet is received on the bus, desc->pd6 contains 1, and
the current residue calculation reports back that 1 byte has been
transferred. This is not according to what the datasheet says, but it's
been the case on an AM335x board, very reproducible.
Fix this by looking at bit 19 in PD2 of the completed packet. This bit
will tell us if a zero-length packet was received on a queue. If it's
set, ignore pd2 and report a total length of 0.
Signed-off-by: Daniel Mack
---
drivers/dma/cppi41.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index d028f36..8f8b0b6 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -86,6 +86,9 @@
#define USBSS_IRQ_PD_COMP (1 << 2)
+/* Packet Descriptor */
+#define PD2_ZERO_LENGTH(1 << 19)
+
struct cppi41_channel {
struct dma_chan chan;
struct dma_async_tx_descriptor txd;
@@ -307,7 +310,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
__iormb();
while (val) {
- u32 desc;
+ u32 desc, len;
q_num = __fls(val);
val &= ~(1 << q_num);
@@ -319,9 +322,13 @@ static irqreturn_t cppi41_irq(int irq, void *data)
q_num, desc);
continue;
}
- c->residue = pd_trans_len(c->desc->pd6) -
- pd_trans_len(c->desc->pd0);
+ if (c->desc->pd2 & PD2_ZERO_LENGTH)
+ len = 0;
+ else
+ len = pd_trans_len(c->desc->pd0);
+
+ c->residue = pd_trans_len(c->desc->pd6) - len;
dma_cookie_complete(&c->txd);
c->txd.callback(c->txd.callback_param);
}
--
1.9.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
[PATCH v2 RESEND] PREEMPT_RT: USB serial gadget: Fix locking issue
With CONFIG_PREEMPT_RT_FULL the tty_flip_buffer_push(..) actions are executed
immeditely (same behaviour as if low_latency flag was set). We thus have to
release port_lock before callng tty_flip_buffer_push().
This issue resultst of commits:
44a0c019: USB: g_serial: don't set low_latency flag
dc0cbd1b: serial: 8250: Call flush_to_ldisc when the irq is threaded
Signed-off-by: Jean-Jacques Hiblot
---
changes since v1:
- fix compilation problem: use port.tty instead of port->port_tty
drivers/usb/gadget/u_serial.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index b369292..3d4246d 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -549,12 +549,25 @@ static void gs_rx_push(unsigned long _port)
port->read_started--;
}
- /* Push from tty to ldisc; without low_latency set this is handled by
-* a workqueue, so we won't get callbacks and can hold port_lock
-*/
- if (do_push)
+ /* Push from tty to ldisc */
+ if (do_push) {
+#ifndef CONFIG_PREEMPT_RT_FULL
+ /* without low_latency set this is handled by a workqueue, so
+* we won't get callbacks and can hold port_lock
+ */
tty_flip_buffer_push(&port->port);
-
+#else
+ /* CONFIG_PREEMPT_RT_FULL makes this a synchronous action. and
+* it may trigger synchronous callbacks to this driver. We need
+* to release the lock.
+ */
+ spin_unlock_irq(&port->port_lock);
+ tty_flip_buffer_push(&port->port);
+ spin_lock_irq(&port->port_lock);
+ /* tty may have been closed */
+ tty = port->port.tty;
+#endif
+ }
/* We want our data queue to become empty ASAP, keeping data
* in the tty and ldisc (not here). If we couldn't push any
--
1.9.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
Re: Runtime PM workqueue killing system performance with USB
On Thu, 22 May 2014, Will Deacon wrote:
> Hi all,
>
> Although I don't think this is a new issue, booting mainline on my vexpress
> a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
> CPU being constantly 20-50% loaded. A bit of investigation shows that this
> is due to the runtime-pm callbacks trying to autosuspend USB, despite this
5B> being unsupported by the host-controller (isp1760, which doesn't
have a
> ->bus_suspend callback). I've included a backtrace at the bottom of this mail.
>
> Anyway, since ->bus_suspend is not implemented, hcd_bus_suspend returns
> -ENOENT, which propagates back up to usb_runtime_suspend via usb_suspend_both.
> At this point, we override the return value with -EBUSY:
>
> drivers/usb/core/driver.c:usb_runtime_suspend:
>
> /* The PM core reacts badly unless the return code is 0,
>* -EAGAIN, or -EBUSY, so always return -EBUSY on an error.
>*/
> if (status != 0)
> return -EBUSY;
>
> This then tells the runtime PM code to try again:
>
> drivers/base/power/runtime.c
>
> if (retval == -EAGAIN || retval == -EBUSY) {
> dev->power.runtime_error = 0;
>
> /*
>* If the callback routine failed an autosuspend, and
>* if the last_busy time has been updated so that there
>* is a new autosuspend expiration time, automatically
>* reschedule another autosuspend.
>*/
> if ((rpmflags & RPM_AUTO) &&
> pm_runtime_autosuspend_expiration(dev) != 0)
> goto repeat;
>
> Consequently, I see a kworker thread on each CPU consuming a significant
> amount of the system resources. Worse, if I enable something like kmemleak
> (which adds more work to the failed suspend operation), I end up failing
> to boot entirely (NFS bombs out).
>
> Reverting db7c7c0aeef5 ("usb: Always return 0 or -EBUSY to the runtime
> PM core.") fixes this for me, but the commit log suggests that will break
> lsusb. That patch has also been in for three and a half years...
>
> Any ideas on how to fix this properly? In what ways does the PM core react
> badly to -ENOENT?
Okay, this is a bad problem.
The PM core takes any error response other than -EBUSY or -EAGAIN as an
indication that the device is in a runtime-PM error state. While that
is appropriate for a USB device, perhaps it's not so appropriate for a
USB host controller.
Anyway, there are two possible ways of handling this. One is to avoid
changing the error code to -EBUSY when the device in question is a root
hub. Just let it go into a runtime-PM error state; it won't matter
since the controller doesn't support runtime PM anyway. You can test
this by changing the "if (status != 0)" line in usb_runtime_suspend to
if (status != 0 && udev->parent)
The other approach is to disable runtime PM for the root hub when the
host controller driver doesn't have a bus_suspend or bus_resume method.
This seems like a cleaner approach; the patch below implements it.
Alan Stern
Index: usb-3.15/drivers/usb/core/hub.c
===
--- usb-3.15.orig/drivers/usb/core/hub.c
+++ usb-3.15/drivers/usb/core/hub.c
@@ -1703,8 +1703,19 @@ static int hub_probe(struct usb_interfac
*/
pm_runtime_set_autosuspend_delay(&hdev->dev, 0);
- /* Hubs have proper suspend/resume support. */
- usb_enable_autosuspend(hdev);
+ /*
+* Hubs have proper suspend/resume support, except for root hubs
+* where the controller driver doesn't have bus_suspend and
+* bus_resume methods.
+*/
+ if (hdev->parent) { /* normal device */
+ usb_enable_autosuspend(hdev);
+ } else {/* root hub */
+ const struct hc_driver *drv = bus_to_hcd(hdev->bus)->driver;
+
+ if (drv->bus_suspend && drv->bus_resume)
+ usb_enable_autosuspend(hdev);
+ }
if (hdev->level == MAX_TOPO_LEVEL) {
dev_err(&intf->dev,
--
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: use of isochronous mode
On Thu, 22 May 2014, Russel Hughes wrote: > > > > Does the Linux USB implementation supports both equally well? And also the > > scheduling of a mixture of both pipe types? For both USB 2 and 3? > > Do you have an idea why many commercial devices (e.g. AV applications) > > still would go for bulk? > > > > Thanks a lot & kind regards, > > Yves > > -- > > I have a DAC that use isochronous audio and it worked fine on USB 2.0, > then I bought an intel NUC which had USB 3.0 and it still does not > work after a couple of months of trying. Intel just say its a Linux > issue, however the people here have been very helpful and say its not > a driver issue, also I have heard it reported it works on a non intel > USB 3.0 hardware. Although I cannot say for sure, it looks like the > Intel hardware has a bug and they are reluctant to admit it. See > below. > > forums.presonus.com/posts/list/33427.page It's worth noting that the Intel erratum mentioned on that page applies to Isochronous-IN transfers only, but people report problems with Isochronous-OUT as well. Of course, there could easily be other bugs in Intel's hardware that they aren't aware of. 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: ASMedia AS2105 interface on USB 3.0 corrupts data
From: Alan Stern > On Thu, 22 May 2014, Heinz Diehl wrote: > > > On 21.05.2014, Alan Stern wrote: > > > > > In that case, I have no idea what else could be causing the problem. > > > > Thanks for your efforts! > > > > If somebody of the developers is interested in debugging this, I'm > > willing to provide/give away the device for free. Send me > > an email with your postal adress in this case, and I'll send you > > the controller mentioned in this thread. My GPG-key is available > > from the link given in the header. > > Mathias, this sounds like a pretty good opportunity for somebody at > Intel to use a USB-3 bus analyzer to solve some of the recurring > problems that have been affecting many people using Intel's xHCI > controllers. I'd also suggest you look through the patches I've posted. Some of the changes would make the code much easier to read. In the end we decided to use PCIe ethernet to get the extra connectivity so didn't need to get the usb3 ethernet device working - but I did have it working 100% reliably against an Intel host controller. The Asmedia one has other issues. 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: use of isochronous mode
On Thu, 22 May 2014, Yves Martens wrote: > Hello, > > I read the USB spec, understand when to prefer bulk vs. isochronous pipes. > My usecase requires controlled jitter & guaranteed bandwidth. > But when discussing this with multiple peer engineers, rumor goes isochronous > mode has 'issues' (sic), they advise me against using it altogether. > > But when I try to pinpoint, I find nothing: 'isochronous' does not require > more patches on this mailing list or in the git history; no panic stories on > forums; commercial devices are few but do exist. > > Does the Linux USB implementation supports both equally well? And also the > scheduling of a mixture of both pipe types? For both USB 2 and 3? In general, isochronous support isn't quite as good as bulk support. However, it varies with the driver. For uhci-hcd and ohci-hcd, isochronous is supported just as well as bulk. The same is true for high-speed transfers with ehci-hcd, but for full-speed transfers the isochronous support is a little weak. Isochronous support on xhci-hcd is also somewhat weak. It hasn't been tested very well, and there have been repeated reports of problems on Intel's xHCI controllers (other controllers seem to work better). > Do you have an idea why many commercial devices (e.g. AV applications) still > would go for bulk? Because the designers don't understand the tradeoffs very well. 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 3.0 - Synopsis DWC Host-AHB - on Linux Kernel 3.10.28
Hi, curiosity: do you have Host-only or the DRD core ? On Wed, May 21, 2014 at 02:53:33PM +0530, krishnamurthy holla wrote: > Hello, > > I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian) > > I see that XHCI fails during xhci_device_alloc() because of > wait_for_completion_interruptible_timeout () when I connect a device. > > So, I thought of initializing host controller as BE as my host is BE. > But this time, it failed much earlier, i.e in xhci_handle_event() > itself for the check le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE) > != xhci->event_ring->cycle_state) > > I would like to know if any of you used Synopsis DWC Host-AHB and got > successful device detection. Also, Please let me know if XHCI needs > special configuration on Big Endian system. two things: a) newer kernel, possibly v3.14 or v3.15-rc6 b) enable debug and send logs :-) cheers -- balbi signature.asc Description: Digital signature
Re: some question about usb_interrupt_msg
On Thu, 22 May 2014, vichy wrote: > hi all: > I see usb_interrupt_msg do nothing but call usb_bulk_msg. > Why we still keep usb_interrupt_msg? > for old api compatibility? That's right. Also because it gives an indication to the reader about what type of transfer is being performed. 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: ASMedia AS2105 interface on USB 3.0 corrupts data
On Thu, 22 May 2014, Heinz Diehl wrote: > On 21.05.2014, Alan Stern wrote: > > > In that case, I have no idea what else could be causing the problem. > > Thanks for your efforts! > > If somebody of the developers is interested in debugging this, I'm > willing to provide/give away the device for free. Send me > an email with your postal adress in this case, and I'll send you > the controller mentioned in this thread. My GPG-key is available > from the link given in the header. Mathias, this sounds like a pretty good opportunity for somebody at Intel to use a USB-3 bus analyzer to solve some of the recurring problems that have been affecting many people using Intel's xHCI controllers. 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 v6 10/17] ARM: mvebu: add USB3 support for Armada 38x
On Wed, May 21, 2014 at 03:53:22PM +0200, Gregory CLEMENT wrote:
> On 19/05/2014 13:09, Paul Bolle wrote:
> > On Fri, 2014-05-16 at 15:07 -0400, Jason Cooper wrote:
> >> On Thu, May 15, 2014 at 12:17:35PM +0200, Gregory CLEMENT wrote:
> >>> This patch adds the selection of the config symbol needed to build the
> >>> USB3 support for Armada 38x into mvebu_v7_defconfig.
> >>>
> >>> Signed-off-by: Gregory CLEMENT
> >>> Signed-off-by: Thomas Petazzoni
> >>> ---
> >>> arch/arm/mach-mvebu/Kconfig | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>
> >> Patches 10 and 11 applied to mvebu/soc
> >
> > These two just hit linux-next (in next-20140519). They're pointless, as
> > config USB_ARCH_HAS_XHCI was dropped in commit b797b76fb464 ("usb: host:
> > remove USB_ARCH_HAS_?HCI").
>
> Right! We didn't notice it.
>
> Jason you can simply remove them from mvebu/soc when you will submit the pull
> request
Now dropped from mvebu/soc.
thx,
Jason.
--
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: use of isochronous mode
> > Does the Linux USB implementation supports both equally well? And also the > scheduling of a mixture of both pipe types? For both USB 2 and 3? > Do you have an idea why many commercial devices (e.g. AV applications) still > would go for bulk? > > Thanks a lot & kind regards, > Yves > -- I have a DAC that use isochronous audio and it worked fine on USB 2.0, then I bought an intel NUC which had USB 3.0 and it still does not work after a couple of months of trying. Intel just say its a Linux issue, however the people here have been very helpful and say its not a driver issue, also I have heard it reported it works on a non intel USB 3.0 hardware. Although I cannot say for sure, it looks like the Intel hardware has a bug and they are reluctant to admit it. See below. forums.presonus.com/posts/list/33427.page It might be worth contacting this guy to see if he can help. usb.org/developers/presentations/pres1108/SuperSpeed_USB_DevCon_Isochronous_TengFroelich.pdf BR Russ -- 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] MIPS: MSP71xx: remove checks for two macros
On Thu, May 22, 2014 at 11:34:51AM +0200, Paul Bolle wrote: > Since v2.6.39 there are checks for CONFIG_MSP_HAS_DUAL_USB and checks > for CONFIG_MSP_HAS_TSMAC in the code. The related Kconfig symbols have > never been added. These checks have evaluated to false for three years > now. Remove them and the code they have been hiding. Queued for 3.16. Ralf -- 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 6/6] usb: musb: dsps: Enable sw babble control for newer silicon
On 5/22/2014 5:28 PM, Sergei Shtylyov wrote:
Hello.
On 22-05-2014 10:29, George Cherian wrote:
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_dsps.c | 38
--
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 868caf8..2ced061 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
[...]
@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val &= ~(1 << wrp->otg_disable);
dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);
+/*
+ * Check whether the dsps version has babble control enabled.
One space too many before this sentence.
+ * In latest silicon revision the babble control logic is enabled.
+ * If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+ * logic enabled.
+ */
+val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+if (val == MUSB_BABBLE_RCV_DISABLE) {
+glue->sw_babble_enabled = true;
+val |= MUSB_BABBLE_SW_SESSION_CTRL;
+dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+}
+
Hm, from the register offset that you declared in the previous
patch, I got an impression that this is a new standard MUSB register?
Its very AM335x MUSB specific register, not a standard one.
Unfortunately the designers put it as part of MUSB core regs.
Shouldn't this check be done in the generic MUSB code then?
WBR, Sergei
--
-George
--
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
use of isochronous mode
Hello, I read the USB spec, understand when to prefer bulk vs. isochronous pipes. My usecase requires controlled jitter & guaranteed bandwidth. But when discussing this with multiple peer engineers, rumor goes isochronous mode has 'issues' (sic), they advise me against using it altogether. But when I try to pinpoint, I find nothing: 'isochronous' does not require more patches on this mailing list or in the git history; no panic stories on forums; commercial devices are few but do exist. Does the Linux USB implementation supports both equally well? And also the scheduling of a mixture of both pipe types? For both USB 2 and 3? Do you have an idea why many commercial devices (e.g. AV applications) still would go for bulk? Thanks a lot & kind regards, Yves -- 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] DWC2: intializes the spin_lock earlier in the probe
The spinlock hsotg->lock is intialized at the end of the probe. However it
may be used from within dwc2_hcd_init(). This patch moves the
initialization before the call to dwc2_hcd_init(). This make the locking
correctness validator happy.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/usb/dwc2/platform.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 37a8ab0..55fb30d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -156,6 +156,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
params.dma_desc_enable = prop;
}
+ spin_lock_init(&hsotg->lock);
+
if (IS_ENABLED(CONFIG_USB_DWC2_HOST)) {
retval = dwc2_hcd_init(hsotg, irq, ¶ms);
if (retval)
@@ -175,7 +177,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
if (retval)
return retval;
}
- spin_lock_init(&hsotg->lock);
platform_set_drvdata(dev, hsotg);
return retval;
--
1.9.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
Re: [PATCH v5 6/6] usb: musb: dsps: Enable sw babble control for newer silicon
Hello.
On 22-05-2014 10:29, George Cherian wrote:
Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_dsps.c | 38 --
1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 868caf8..2ced061 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
[...]
@@ -469,6 +470,19 @@ static int dsps_musb_init(struct musb *musb)
val &= ~(1 << wrp->otg_disable);
dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);
+ /*
+* Check whether the dsps version has babble control enabled.
One space too many before this sentence.
+* In latest silicon revision the babble control logic is enabled.
+* If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+* logic enabled.
+*/
+ val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
+ glue->sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+ }
+
Hm, from the register offset that you declared in the previous patch, I
got an impression that this is a new standard MUSB register? Shouldn't this
check be done in the generic MUSB code then?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()
On 22-05-2014 10:29, George Cherian wrote:
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Signed-off-by: George Cherian
---
drivers/usb/musb/musb_dsps.c | 50
drivers/usb/musb/musb_regs.h | 7 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
+static int sw_babble_control(struct musb *musb)
+{
Doesn't gcc complain on this function being unused? I think you should
have added this function along with the caller, not separately.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/6] usb: musb: dsps: Add the sw_babble_control()
Hello.
On 22-05-2014 10:29, George Cherian wrote:
Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.
Babble control register logic is implemented in the latest
revision of AM335x.
Signed-off-by: George Cherian
Sorry for the late comments, I probably didn't pay enough attention to
this series before...
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..868caf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
+static int sw_babble_control(struct musb *musb)
Perhaps the result type should be *bool* instead of *int*?
+{
+ int timeout = 10;
+ u8 babble_ctl, session_restart = 0;
+
+ babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+ dev_dbg(musb->controller, "babble: MUSB_BABBLE_CTL value %x\n",
+ babble_ctl);
+ /*
+* check line monitor flag to check whether babble is
+* due to noise
+*/
+ dev_dbg(musb->controller, "STUCK_J is %s\n",
+ babble_ctl & MUSB_BABBLE_STUCK_J ? "set" : "reset");
+
+ if (babble_ctl & MUSB_BABBLE_STUCK_J) {
'timeout' could be declared here, local to the block using it.
+ /*
+* babble is due to noise, then set transmit idle (d7 bit)
+* to resume normal operation
+*/
+ babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+ babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+ dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+ /* wait till line monitor flag cleared */
+ dev_dbg(musb->controller, "Set TXIDLE, wait J to clear\n");
+ do {
+ babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+ udelay(1);
+ } while ((babble_ctl & MUSB_BABBLE_STUCK_J) && timeout--);
+
+ /* check whether stuck_at_j bit cleared */
+ if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+ /*
+* real babble condition is occured
s/is occured/has occurred/.
+* restart the controller to start the
+* session again
+*/
+ dev_dbg(musb->controller, "J not cleared, misc (%x)\n",
+ babble_ctl);
+ session_restart = 1;
+ }
+
Empty line not needed here.
+ } else {
+ session_restart = 1;
+ }
+
+ return session_restart;
+}
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: usb5303: add support for reference clock specified in device tree
USB3503 chip supports 8 values of reference clock. The value is
specified by REF_SEL[1:0] pins and INT_N line. This patch add support
for getting 'refclk' clock, enabling it and setting INT_N line according
to the value of the gathered clock. If no clock has been specified,
driver defaults to the old behaviour (assuming that clock has been
specified by REF_SEL pins from primary reference clock frequencies
table).
Signed-off-by: Marek Szyprowski
---
Hello,
This extension to USB3503 driver is needed to add support for OdroidU3
board, which uses 24MHz reference clock, sourced directly from CLKOUT
line from Exynos4412 SoC.
Changelog:
v2
- fixed issues pointed by Mark Brown
- added optional refclk-frequency property, clock rate is read from DT
instead of getting it from clock
v1
- initial version
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
---
Documentation/devicetree/bindings/usb/usb3503.txt | 8 +++
drivers/usb/misc/usb3503.c| 59 ++-
2 files changed, 65 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt
b/Documentation/devicetree/bindings/usb/usb3503.txt
index a018da4a7ad7..221ac0dbc678 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -15,6 +15,14 @@ Optional properties:
- reset-gpios: Should specify GPIO for reset.
- initial-mode: Should specify initial mode.
(1 for HUB mode, 2 for STANDBY mode)
+- refclk: Clock used for driving REFCLK signal (optional, if not provided
+ the driver assumes that clock signal is always available, its
+ rate is specified by REF_SEL pins and a value from the primary
+ reference clock frequencies table is used)
+- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL
+ pins (optional, if not provided, driver will not set rate of the
+ REFCLK signal and assume that a value from the primary reference
+ clock frequencies table is used)
Examples:
usb3503@08 {
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index a31641e18d19..f43c61989cef 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include
#include
#include
#include
@@ -57,10 +58,12 @@ struct usb3503 {
enum usb3503_mode mode;
struct regmap *regmap;
struct device *dev;
+ struct clk *clk;
u8 port_off_mask;
int gpio_intn;
int gpio_reset;
int gpio_connect;
+ boolsecondary_ref_clk;
};
static int usb3503_reset(struct usb3503 *hub, int state)
@@ -184,8 +187,58 @@ static int usb3503_probe(struct usb3503 *hub)
hub->gpio_reset = pdata->gpio_reset;
hub->mode = pdata->initial_mode;
} else if (np) {
+ struct clk *clk;
hub->port_off_mask = 0;
+ clk = devm_clk_get(dev, "refclk");
+ if (IS_ERR(clk) && PTR_ERR(clk) != -ENOENT) {
+ dev_err(dev, "unable to request refclk (%d)\n", err);
+ return PTR_ERR(clk);
+ }
+
+ if (!IS_ERR(clk)) {
+ u32 rate = 0;
+ hub->clk = clk;
+
+ if (!of_property_read_u32(np, "refclk-frequency",
+&rate)) {
+
+ switch (rate) {
+ case 3840:
+ case 2600:
+ case 1920:
+ case 1200:
+ hub->secondary_ref_clk = 0;
+ break;
+ case 2400:
+ case 2700:
+ case 2500:
+ case 5000:
+ hub->secondary_ref_clk = 1;
+ break;
+ default:
+ dev_err(dev,
+ "unsupported reference clock
rate (%d)\n",
+ (int) rate);
+ return -EINVAL;
+ }
+ err = clk_set_rate(hub->clk, rate);
+ if (err) {
+ dev_err(dev,
+ "unable to set reference clock
rate to %d\n",
+ (int) rate);
+ return err;
+
[PATCH V2] USB: Add LVS Test device driver
OTG3 and EH Compliance Plan 1.0 talks about Super Speed OTG Verification system (SS-OVS) which consists of an excersizer and analyzer. USB Compliance Suite from Lecroy or Ellisys can act as such SS-OVS for Link Layer Validation (LVS). Some modifications are needed for an embedded Linux USB host to pass all these tests. Most of these tests require just Link to be in U0. They do not work with default Linux USB stack since, default stack does port reset and then starts sending setup packet, which is not expected by Link Layer Validation (LVS) device of Lecroy Compliance Suit. Then, There are many Link Layer Tests which need host to generate specific traffic. This patch supports specific traffic generation cases. As of now all the host Lecroy Link Layer-USBIF tests (except TD7.26) passes with this patch for single run using Lecroy USB Compliance Suite Version 1.98 Build 239 and Lecroy USB Protocol Analyzer version 4.80 Build 1603. Therefore patch seems to be a good candidate for inclusion. Further modification can be done on top of it. lvstest driver will not bind to any device by default. It can bind manually to a super speed USB host controller root hub. Therefore, regular hub driver must be unbound before this driver is bound. For example, if 2-0:1.0 is the xhci root hub, then execute following to unbind hub driver. echo 2-0:1.0 > /sys/bus/usb/drivers/hub/unbind Then to bind lvs driver write Linux Foundation's vendor ID and SS root hub's device ID into new_id file. echo "1D6B 3" > /sys/bus/usb/drivers/lvs/new_id Now connect LVS device with root hub port. Test case specific traffic can be generated as follows whenever needed: 1. To issue "Get Device descriptor" command for TD.7.06: echo 1 > /sys/bus/usb/devices/2-0\:1.0/get_dev_desc 2. To set U1 timeout to 127 for TD.7.18 echo 127 > /sys/bus/usb/devices/2-0\:1.0/u1_timeout 3. To set U2 timeout to 0 for TD.7.18 echo 0 > /sys/bus/usb/devices/2-0\:1.0/u2_timeout 4. To issue "Hot Reset" for TD.7.29 echo 1 > /sys/bus/usb/devices/2-0\:1.0/hot_reset 5. To issue "U3 Entry" for TD.7.35 echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_entry 6. To issue "U3 Exit" for TD.7.36 echo 1 > /sys/bus/usb/devices/2-0\:1.0/u3_exit Signed-off-by: Pratyush Anand --- Documentation/ABI/testing/sysfs-bus-usb-lvstest | 47 +++ drivers/usb/misc/Kconfig| 7 + drivers/usb/misc/Makefile | 1 + drivers/usb/misc/lvstest.c | 434 4 files changed, 489 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-usb-lvstest create mode 100644 drivers/usb/misc/lvstest.c diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest b/Documentation/ABI/testing/sysfs-bus-usb-lvstest new file mode 100644 index 000..f47e8a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest @@ -0,0 +1,47 @@ +Link Layer Validation Device is a standard device for testing of Super +Speed Link Layer tests. These nodes are available in sysfs only when lvs +driver is bound with root hub device. + +What: /sys/bus/usb/devices/.../get_dev_desc +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "Get Device Descriptor" + for Link Layer Validation device. It is needed for TD.7.06. + +What: /sys/bus/usb/devices/.../u1_timeout +Date: March 2014 +Contact: Pratyush Anand +Description: + Set "U1 timeout" for the downstream port where Link Layer + Validation device is connected. It is needed for TD.7.18, + TD.7.19, TD.7.20 and TD.7.21. + +What: /sys/bus/usb/devices/.../u2_timeout +Date: March 2014 +Contact: Pratyush Anand +Description: + Set "U2 timeout" for the downstream port where Link Layer + Validation device is connected. It is needed for TD.7.18, + TD.7.19, TD.7.20 and TD.7.21. + +What: /sys/bus/usb/devices/.../hot_reset +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "Reset" for Link Layer Validation + device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35. + +What: /sys/bus/usb/devices/.../u3_entry +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "U3 entry" for Link Layer + Validation device. It is needed for TD.7.35 and TD.7.36. + +What: /sys/bus/usb/devices/.../u3_exit +Date: March 2014 +Contact: Pratyush Anand +Description: + Write to this node to issue "U3 exit" for Link Layer + Validation device. It is needed for TD.7.36. diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig index 1bca274..76d7720 100644 --- a/drivers/usb/misc/Kconfig +++ b/drivers/usb/misc/Kconfig @@ -248,3 +248,10 @@ config USB_HSIC_US
Runtime PM workqueue killing system performance with USB
Hi all,
Although I don't think this is a new issue, booting mainline on my vexpress
a9x4 (Quad ARMv7 Cortex-A9 board) with USB and PM_RUNTIME results in each
CPU being constantly 20-50% loaded. A bit of investigation shows that this
is due to the runtime-pm callbacks trying to autosuspend USB, despite this
being unsupported by the host-controller (isp1760, which doesn't have a
->bus_suspend callback). I've included a backtrace at the bottom of this mail.
Anyway, since ->bus_suspend is not implemented, hcd_bus_suspend returns
-ENOENT, which propagates back up to usb_runtime_suspend via usb_suspend_both.
At this point, we override the return value with -EBUSY:
drivers/usb/core/driver.c:usb_runtime_suspend:
/* The PM core reacts badly unless the return code is 0,
* -EAGAIN, or -EBUSY, so always return -EBUSY on an error.
*/
if (status != 0)
return -EBUSY;
This then tells the runtime PM code to try again:
drivers/base/power/runtime.c
if (retval == -EAGAIN || retval == -EBUSY) {
dev->power.runtime_error = 0;
/*
* If the callback routine failed an autosuspend, and
* if the last_busy time has been updated so that there
* is a new autosuspend expiration time, automatically
* reschedule another autosuspend.
*/
if ((rpmflags & RPM_AUTO) &&
pm_runtime_autosuspend_expiration(dev) != 0)
goto repeat;
Consequently, I see a kworker thread on each CPU consuming a significant
amount of the system resources. Worse, if I enable something like kmemleak
(which adds more work to the failed suspend operation), I end up failing
to boot entirely (NFS bombs out).
Reverting db7c7c0aeef5 ("usb: Always return 0 or -EBUSY to the runtime
PM core.") fixes this for me, but the commit log suggests that will break
lsusb. That patch has also been in for three and a half years...
Any ideas on how to fix this properly? In what ways does the PM core react
badly to -ENOENT?
Cheers,
Will
--->8
[ 161.385424] CPU: 0 PID: 51 Comm: kworker/0:1 Not tainted 3.15.0-rc5 #2
[ 161.405009] Workqueue: pm pm_runtime_work
[ 161.417019] task: ed0bec00 ti: ed47 task.ti: ed47
[ 161.433195] PC is at kmemleak_free+0x8/0x4c
[ 161.445737] LR is at kfree+0xbc/0x154
[ 161.456699] pc : []lr : []psr: 400f0013
[ 161.456699] sp : ed471c58 ip : 001c fp : ed39adc0
[ 161.491098] r10: r9 : ed59a300 r8 : c09df324
[ 161.506743] r7 : c03e7960 r6 : ee59b340 r5 : ed59a300 r4 : ed001f00
[ 161.526294] r3 : f0e0 r2 : edff r1 : ed59a300 r0 : ed59a300
[ 161.545848] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
kernel
[ 161.567743] Control: 10c5387d Table: 8d5e004a DAC: 0015
[ 161.584955] CPU: 0 PID: 51 Comm: kworker/0:1 Not tainted 3.15.0-rc5 #2
[ 161.604512] Workqueue: pm pm_runtime_work
[ 161.616572] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 161.639794] [] (show_stack) from []
(dump_stack+0x88/0x98)
[ 161.661449] [] (dump_stack) from []
(sysrq_handle_showallcpus+0x5c/0x64)
[ 161.686744] [] (sysrq_handle_showallcpus) from []
(__handle_sysrq+0x128/0x17c)
[ 161.713600] [] (__handle_sysrq) from []
(pl011_fifo_to_tty+0x174/0x1c4)
[ 161.738631] [] (pl011_fifo_to_tty) from []
(pl011_int+0x298/0x5a8)
[ 161.762362] [] (pl011_int) from []
(handle_irq_event_percpu+0x78/0x134)
[ 161.787393] [] (handle_irq_event_percpu) from []
(handle_irq_event+0x40/0x60)
[ 161.813991] [] (handle_irq_event) from []
(handle_fasteoi_irq+0xa8/0x1a8)
[ 161.839562] [] (handle_fasteoi_irq) from []
(generic_handle_irq+0x2c/0x3c)
[ 161.865377] [] (generic_handle_irq) from []
(handle_IRQ+0x40/0x90)
[ 161.889105] [] (handle_IRQ) from []
(gic_handle_irq+0x2c/0x5c)
[ 161.911788] [] (gic_handle_irq) from []
(__irq_svc+0x40/0x50)
[ 161.934204] Exception stack(0xed471c10 to 0xed471c58)
[ 161.949333] 1c00: ed59a300 ed59a300
edff f0e0
[ 161.973840] 1c20: ed001f00 ed59a300 ee59b340 c03e7960 c09df324 ed59a300
ed39adc0
[ 161.998345] 1c40: 001c ed471c58 c00ecc14 c05be7e0 400f0013
[ 162.018168] [] (__irq_svc) from []
(kmemleak_free+0x8/0x4c)
[ 162.040082] [] (kmemleak_free) from [] (kfree+0xbc/0x154)
[ 162.061490] [] (kfree) from []
(usb_hcd_submit_urb+0x2d4/0x804)
[ 162.084447] [] (usb_hcd_submit_urb) from []
(usb_start_wait_urb+0x4c/0xbc)
[ 162.110264] [] (usb_start_wait_urb) from []
(usb_control_msg+0xa0/0xd0)
[ 162.135298] [] (usb_control_msg) from []
(hub_port_status+0x74/0xfc)
[ 162.159548] [] (hub_port_status) from []
(hub_activate+0x164/0x500)
[ 162.183537] [] (hub_activate) from []
(hub_resume+0x14/0x1c)
[ 162.205709] [] (hub_resume) from []
(usb_resume_interface.isra.6+0xe8/0x118)
[ 162.232041] [] (usb_resume_interface.isra.6) from []
(usb_suspend_both+0xbc/0x19c)
[ 162.
some question about usb_interrupt_msg
hi all: I see usb_interrupt_msg do nothing but call usb_bulk_msg. Why we still keep usb_interrupt_msg? for old api compatibility? thanks for your help in advance, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: usbtest: add pattern check on pipe in phase of unlink read
TEST 11 unlinks the URB read request for N times. When host and gadget
both initialize pattern 1 (mod 63) data series to do IN transfer, the
host side function should check the data buffer if it is as mod 63
series, because the data packet which host receivced will follow
pattern 1. So this patch adds this checking action.
Signed-off-by: Huang Rui
---
drivers/usb/misc/usbtest.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 4e31418..f7d37c1 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1345,6 +1345,9 @@ static int unlink1(struct usbtest_dev *dev, int pipe, int
size, int async)
while (!completion_done(&completion)) {
retval = usb_unlink_urb(urb);
+ if (retval == 0 && usb_pipein(urb->pipe))
+ retval = simple_check_buf(dev, urb);
+
switch (retval) {
case -EBUSY:
case -EIDRM:
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: usbtest: fix unlink write error with pattern 1
TEST 12 unlinks the URB write request for N times. When host and
gadget both initialize pattern 1 (mod 63) data series to transfer, the
gadget side will complain the wrong data which is not expected.
Because in host side, usbtest doesn't fill the data buffer as mod 63
and this patch fixed it.
[20285.488974] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready
[20285.489181] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active
[20285.489423] dwc3 dwc3.0.auto: ep1out-bulk: req 8800aa6cb480 dma aeb50800
length 512 last
[20285.489727] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params
a9eaf000
[20285.490055] dwc3 dwc3.0.auto: Command Complete --> 0
[20285.490281] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready
[20285.490492] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Active
[20285.490713] dwc3 dwc3.0.auto: ep1out-bulk: endpoint busy
[20285.490909] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Complete
[20285.491117] dwc3 dwc3.0.auto: request 8800aa6cb480 from ep1out-bulk
completed 512/512 ===> 0
[20285.491431] zero gadget: bad OUT byte, buf[1] = 0
[20285.491605] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Set Stall' params
[20285.491915] dwc3 dwc3.0.auto: Command Complete --> 0
[20285.492099] dwc3 dwc3.0.auto: queing request 8800aa6cb480 to ep1out-bulk
length 512
[20285.492387] dwc3 dwc3.0.auto: ep1out-bulk: Transfer Not Ready
[20285.492595] dwc3 dwc3.0.auto: ep1out-bulk: reason Transfer Not Active
[20285.492830] dwc3 dwc3.0.auto: ep1out-bulk: req 8800aa6cb480 dma aeb51000
length 512 last
[20285.493135] dwc3 dwc3.0.auto: ep1out-bulk: cmd 'Start Transfer' params
a9eaf000
[20285.493465] dwc3 dwc3.0.auto: Command Complete --> 0
Cc:
Signed-off-by: Huang Rui
---
drivers/usb/misc/usbtest.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index f6568b5..4e31418 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -1320,6 +1320,11 @@ static int unlink1(struct usbtest_dev *dev, int pipe,
int size, int async)
urb->context = &completion;
urb->complete = unlink1_callback;
+ if (usb_pipeout(urb->pipe)) {
+ simple_fill_buf(urb);
+ urb->transfer_flags |= URB_ZERO_PACKET;
+ }
+
/* keep the endpoint busy. there are lots of hc/hcd-internal
* states, and testing should get to all of them over time.
*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MIPS: MSP71xx: remove checks for two macros
Since v2.6.39 there are checks for CONFIG_MSP_HAS_DUAL_USB and checks
for CONFIG_MSP_HAS_TSMAC in the code. The related Kconfig symbols have
never been added. These checks have evaluated to false for three years
now. Remove them and the code they have been hiding.
Signed-off-by: Paul Bolle
---
Eyeball tested only.
arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h | 4 -
arch/mips/pmcs-msp71xx/msp_eth.c | 76 ---
arch/mips/pmcs-msp71xx/msp_usb.c | 90 ---
drivers/usb/host/ehci-pmcmsp.c| 40 --
4 files changed, 210 deletions(-)
diff --git a/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
index aa45e6a07126..fe1566f2913e 100644
--- a/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
+++ b/arch/mips/include/asm/mach-pmcs-msp71xx/msp_usb.h
@@ -25,11 +25,7 @@
#ifndef MSP_USB_H_
#define MSP_USB_H_
-#ifdef CONFIG_MSP_HAS_DUAL_USB
-#define NUM_USB_DEVS 2
-#else
#define NUM_USB_DEVS 1
-#endif
/* Register spaces for USB host 0 */
#define MSP_USB0_MAB_START (MSP_USB0_BASE + 0x0)
diff --git a/arch/mips/pmcs-msp71xx/msp_eth.c b/arch/mips/pmcs-msp71xx/msp_eth.c
index c584df393de2..15679b427f44 100644
--- a/arch/mips/pmcs-msp71xx/msp_eth.c
+++ b/arch/mips/pmcs-msp71xx/msp_eth.c
@@ -38,73 +38,6 @@
#define MSP_ETHERNET_GPIO1 15
#define MSP_ETHERNET_GPIO2 16
-#ifdef CONFIG_MSP_HAS_TSMAC
-#define MSP_TSMAC_SIZE 0x10020
-#define MSP_TSMAC_ID "pmc_tsmac"
-
-static struct resource msp_tsmac0_resources[] = {
- [0] = {
- .start = MSP_MAC0_BASE,
- .end= MSP_MAC0_BASE + MSP_TSMAC_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = MSP_INT_MAC0,
- .end= MSP_INT_MAC0,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-static struct resource msp_tsmac1_resources[] = {
- [0] = {
- .start = MSP_MAC1_BASE,
- .end= MSP_MAC1_BASE + MSP_TSMAC_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = MSP_INT_MAC1,
- .end= MSP_INT_MAC1,
- .flags = IORESOURCE_IRQ,
- },
-};
-static struct resource msp_tsmac2_resources[] = {
- [0] = {
- .start = MSP_MAC2_BASE,
- .end= MSP_MAC2_BASE + MSP_TSMAC_SIZE - 1,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = MSP_INT_SAR,
- .end= MSP_INT_SAR,
- .flags = IORESOURCE_IRQ,
- },
-};
-
-
-static struct platform_device tsmac_device[] = {
- [0] = {
- .name = MSP_TSMAC_ID,
- .id = 0,
- .num_resources = ARRAY_SIZE(msp_tsmac0_resources),
- .resource = msp_tsmac0_resources,
- },
- [1] = {
- .name = MSP_TSMAC_ID,
- .id = 1,
- .num_resources = ARRAY_SIZE(msp_tsmac1_resources),
- .resource = msp_tsmac1_resources,
- },
- [2] = {
- .name = MSP_TSMAC_ID,
- .id = 2,
- .num_resources = ARRAY_SIZE(msp_tsmac2_resources),
- .resource = msp_tsmac2_resources,
- },
-};
-#define msp_eth_devs tsmac_device
-
-#else
-/* If it is not TSMAC assume MSP_ETH (100Mbps) */
#define MSP_ETH_ID "pmc_mspeth"
#define MSP_ETH_SIZE 0xE0
static struct resource msp_eth0_resources[] = {
@@ -152,7 +85,6 @@ static struct platform_device mspeth_device[] = {
};
#define msp_eth_devs mspeth_device
-#endif
int __init msp_eth_setup(void)
{
int i, ret = 0;
@@ -161,14 +93,6 @@ int __init msp_eth_setup(void)
msp_gpio_pin_mode(MSP_GPIO_OUTPUT, MSP_ETHERNET_GPIO0);
msp_gpio_pin_hi(MSP_ETHERNET_GPIO0);
-#ifdef CONFIG_MSP_HAS_TSMAC
- /* 3 phys on boards with TSMAC */
- msp_gpio_pin_mode(MSP_GPIO_OUTPUT, MSP_ETHERNET_GPIO1);
- msp_gpio_pin_hi(MSP_ETHERNET_GPIO1);
-
- msp_gpio_pin_mode(MSP_GPIO_OUTPUT, MSP_ETHERNET_GPIO2);
- msp_gpio_pin_hi(MSP_ETHERNET_GPIO2);
-#endif
for (i = 0; i < ARRAY_SIZE(msp_eth_devs); i++) {
ret = platform_device_register(&msp_eth_devs[i]);
printk(KERN_INFO "device: %d, return value = %d\n", i, ret);
diff --git a/arch/mips/pmcs-msp71xx/msp_usb.c b/arch/mips/pmcs-msp71xx/msp_usb.c
index 4dab915696e7..c87c5f810cd1 100644
--- a/arch/mips/pmcs-msp71xx/msp_usb.c
+++ b/arch/mips/pmcs-msp71xx/msp_usb.c
@@ -75,47 +75,6 @@ static struct mspusb_device msp_usbhost0_device = {
.resource = msp_usbhost0_resources,
},
};
-
-/* MSP7140/MSP82XX has two USB2 hosts. */
-#ifdef CONFIG_MSP_HAS_DUAL_USB
-static u64 msp_usbhost1_dma_mask = 0xUL;
-
-static struct resource msp_usbhost1_resources[] = {
- [0] = { /* EHCI-HS operational and capabi
Re: USB 3.0 - Synopsis DWC Host-AHB - on Linux Kernel 3.10.28
On Wed, May 21, 2014 at 05:23:33PM +0800, krishnamurthy holla wrote: > Hello, > > I am using Linux kernel 3.10.28 - MIPS processor (BIG Endian) > > I see that XHCI fails during xhci_device_alloc() because of > wait_for_completion_interruptible_timeout () when I connect a device. > > So, I thought of initializing host controller as BE as my host is BE. > But this time, it failed much earlier, i.e in xhci_handle_event() > itself for the check le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE) > != xhci->event_ring->cycle_state) > > I would like to know if any of you used Synopsis DWC Host-AHB and got > successful device detection. Also, Please let me know if XHCI needs Yes, our SNPS dwc3 xhci host works well with various SS/HS devices. But our system is LE. > special configuration on Big Endian system. I do not think you need any special configuration of xhci register for this. USB and XHCI debug dmesg may help. Pratyush > > Thanks > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ASMedia AS2105 interface on USB 3.0 corrupts data
On 21.05.2014, Alan Stern wrote: > In that case, I have no idea what else could be causing the problem. Thanks for your efforts! If somebody of the developers is interested in debugging this, I'm willing to provide/give away the device for free. Send me an email with your postal adress in this case, and I'll send you the controller mentioned in this thread. My GPG-key is available from the link given in the header. -- 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
