[PATCH V4 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 V3-V4 - Edited the commit message to provide more information regarding the new test cases added - Rebased the code in Kernel v3.16-rc5 - No change in the code 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 V4 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.
The two new tests added are
- Test 25: To verify Interrupt OUT transfer
- Test 26: To verify Interrupt IN transfer
Since the default value of wMaxPacketSize is set as 1024, so interrupt
IN transfers must be specified with the size parameter = multiple of
1024. Otherwise the default value (512) in the usbtest application fails
the transfer. See [RUN 4] for sample logs
The application logs (usbtest) and corresponding kernel logs are as
following:
---
[Run 1]
./testusb -a -c 10 -s 2048 -t 26 -v 511
Jul 17 10:31:13 dlhl1014 kernel: [72056.950910] usbtest 7-1:3.0: TEST
26: read 2048 bytes 10 times
[Run 2]
./testusb -a -c 10 -s 1024 -t 25 -v 511
Jul 17 10:31:29 dlhl1014 kernel: [72072.834853] usbtest 7-1:3.0: TEST
25: write 1024 bytes 10 times
[Run 3]
./testusb -a -c 10 -s 1098 -t 25 -v 511
Jul 17 10:31:39 dlhl1014 kernel: [72082.322219] usbtest 7-1:3.0: TEST
25: write 1098 bytes 10 times
[Run 4 - Failure case scenario]
./testusb -a -t 26
unknown speed /dev/bus/usb/007/0040
/dev/bus/usb/007/004 test 26 -- 75 (Value too large for defined data
type)
Jul 17 11:11:30 dlhl1014 kernel: [74473.347219] usbtest 7-1:3.0: TEST
26: read 512 bytes 1000 times
Jul 17 11:11:30 dlhl1014 kernel: [74473.348959] usb 7-1: test26 failed,
iterations left 999, status -75 (not 0)
---
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 amit.vi...@st.com
---
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 829f446064ea..90e6644dc886 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)) {
[PATCH V4 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 amit.vi...@st.com
---
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 4557cd03f0b1..bf04389137e6 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 d3cd52db78fe..7c091a328228 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 = {
Re: [PATCH 0/9] usb: musb: several bugfixes for the musb driver
Hi, Felipe Balbi wrote: Hi, On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote: Hi Lothar, On 18 Jul 11:31 AM, Lothar Waßmann wrote: The first three patches do some source code cleanup in the files that are modified in the subsequent patches. I've applied patches 4 and 9 on a recent -next, after fixing a conflict due to patch 3 (usb: musb_am335x: source cleanup): Patch 4 carries the proper fix reported in commit: 7adb5c876e9c (usb: musb: Fix panic upon musb_am335x module removal) Patch 9 reinstates module unloading support for the musb_am335x driver which was disabled due to a false failure analysis For these two patches, Tested-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Tested on a beaglebone with a mass storage USB device, module load/unload works without issues. The module_get/put in the phy is now preventing the musb_am335x driver unload, which seems to be the real cause of the issue I reported. Thanks for providing a proper fix! I don't that's a good fix. The problem is that even after am335x removing all its child, someone else tried to release the PHY. That ordering is the one that needs to be fixed. Doing a module_get on the parent device looks like a hack to me. No. It guarantees that the module cannot be unloaded when its resources are still in use! Lothar Waßmann -- ___ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | i...@karo-electronics.de ___ -- 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 8/9] usb: phy: am335x: call usb_gen_phy_init()/usb_gen_phy_shutdown() in am335x_init()/am335x_shutdown()
Hi,
On Fri, Jul 18, 2014 at 11:31:29AM +0200, Lothar Waßmann wrote:
This patch makes it possible to use the musb driver with HW that
requires external regulators or clocks.
can you provide an example of such HW ? Are you not using the internal
PHYs ?
The Ka-Ro electronics TX48 module uses the mmc0_clk pin as VBUSEN
rathern than usb0_drvvbus. This patch makes it possible to use an
external regulator to handle the VBUS switch through the 'vcc-supply'
property of the underlying generic_phy device.
Signed-off-by: Lothar Waßmann l...@karo-electronics.de
---
drivers/usb/phy/phy-am335x.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index 6522fa7..de25674 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -22,6 +22,7 @@ static int am335x_init(struct usb_phy *phy)
{
struct am335x_phy *am_phy = dev_get_drvdata(phy-dev);
+ usb_gen_phy_init(phy);
phy_ctrl_power(am_phy-phy_ctrl, am_phy-id, true);
return 0;
}
@@ -31,6 +32,7 @@ static void am335x_shutdown(struct usb_phy *phy)
struct am335x_phy *am_phy = dev_get_drvdata(phy-dev);
phy_ctrl_power(am_phy-phy_ctrl, am_phy-id, false);
+ usb_gen_phy_shutdown(phy);
}
static int am335x_phy_probe(struct platform_device *pdev)
--
1.7.10.4
--
___
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | i...@karo-electronics.de
___
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb:serial:pl2303: add GPIOs interface on PL2303
On Mon, Jul 21, 2014 at 07:46:46AM +0200, Andreas Mohr wrote:
Hi,
Did some more review, sorry ;)
On Mon, Jul 21, 2014 at 10:46:24AM +0800, Wang YanQing wrote:
+static struct gpio_chip template_chip = {
+ .label = pl2303-gpio,
+ .owner = THIS_MODULE,
+ .direction_input= pl2303_gpio_direction_in,
+ .get= pl2303_gpio_get,
+ .direction_output = pl2303_gpio_direction_out,
+ .set= pl2303_gpio_set,
+ .can_sleep = 1,
+};
Could this be made static const? (since it's for one-time copy purposes only)
OK, I will add const.
+struct pl2303_gpio {
+ /*
+* 0..3: unknown (zero)
+* 4: gp0 output enable (1: gp0 pin is output, 0: gp0 pin is input)
+* 5: gp1 output enable (1: gp1 pin is output, 0: gp1 pin is input)
+* 6: gp0 pin value
+* 7: gp1 pin value
+*/
+ u8 index;
Most frequently accessed member at first position - good.
+static inline struct pl2303_gpio *to_pl2303_gpio(struct gpio_chip
*chip)
+{
+ return container_of(chip, struct pl2303_gpio, gpio_chip);
+}
Nicely cast-avoiding helper :)
+ spriv-gpio-index = 0x00;
+ spriv-gpio-serial = serial;
+ spriv-gpio-gpio_chip = template_chip;
+ spriv-gpio-gpio_chip.ngpio = GPIO_NUM;
+ spriv-gpio-gpio_chip.base = -1;
+ spriv-gpio-gpio_chip.dev = serial-interface-dev;
+ /* initialize GPIOs, input mode as default */
+ pl2303_vendor_write(spriv-gpio-serial, 1, spriv-gpio-index);
Perhaps the index line should better be moved
right before the pl2303_vendor_write() line,
to more obviously hint at why it's input mode
(but OTOH currently you're cleanly initializing things in correct member
order,
so it's probably better to keep it that way).
Also, it's perhaps a better idea to do this initial init call
via calls of actual GPIO API rather than implementation-specific call
(e.g. that way one could simple reuse the generic GPIO call for devices
which happen to implement GPIO via a different mechanism...).
(hmm, nope, from a layering POV it's not recommendable,
since we clearly are at hardware-specific init here,
where you want to firmly guarantee
that the hardware is directly and fully initialized).
Thanks very much for review :)
Since there are several repeated
pl2303_vendor_write(...serial, 1, ...index) calls,
it's possibly a good idea to wrap these calls in a convenience
pl2303_gpio_state_update(gpio)
This would also increase GPIO hardware abstraction,
by then simply having to provide an alternative for this single function
if needed.
Also, it may (depending on the number of callers,
which is on the low side here unfortunately)
reduce instruction cache footprint.
The reason I don't want to add more abstraction here are:
1: Abstraction don't reduce code lines, then reuse
pl2303_vendor_write|read is a better choice, i think.
2: pl2303_vendor_write|read is more generic than abstraction,
then someone maybe could use pl2303_vendor_write|read to support
another two Auxiliary GPIOs on PL2303HXD(I don't have one) directly
without play with abstraction.
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
[PATCH] usb: phy: tegra: Avoid use of sizeof(void)
From: Thierry Reding tred...@nvidia.com
The PHY configuration is stored in an opaque config field, but when
allocating the structure, its proper size needs to be known. In the case
of UTMI, the proper structure is tegra_utmip_config of which a local
variable already exists, so we can use that to obtain the size from.
Fixes the following warning from the sparse checker:
drivers/usb/phy/phy-tegra-usb.c:882:17: warning: expression using
sizeof(void)
Fixes: 81d5dfe6d8b3 (usb: phy: tegra: Read UTMIP parameters from device tree)
Cc: sta...@vger.kernel.org
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/usb/phy/phy-tegra-usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 13b4fa287da8..886f1807a67b 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -878,8 +878,8 @@ static int utmi_phy_probe(struct tegra_usb_phy *tegra_phy,
return -ENOMEM;
}
- tegra_phy-config = devm_kzalloc(pdev-dev,
- sizeof(*tegra_phy-config), GFP_KERNEL);
+ tegra_phy-config = devm_kzalloc(pdev-dev, sizeof(*config),
+GFP_KERNEL);
if (!tegra_phy-config) {
dev_err(pdev-dev,
unable to allocate memory for USB UTMIP config\n);
--
2.0.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 V2] usb: core: allow zero packet flag for interrupt urbs
On Mon, 21 Jul 2014, Amit Virdi wrote:
Section 4.4.7.2 Interrupt Transfer Bandwidth Requirements of the USB3.0 spec
says:
A zero-length data payload is a valid transfer and may be useful for
some implementations.
So, extend the logic of allowing URB_ZERO_PACKET to interrupt urbs too.
Otherwise, the kernel throws warning of BOGUS transfer flags.
Signed-off-by: Amit Virdi amit.vi...@st.com
Acked-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/urb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 991386ceb4ec..c9e8ee81b6b7 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -454,6 +454,7 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
URB_FREE_BUFFER);
switch (xfertype) {
case USB_ENDPOINT_XFER_BULK:
+ case USB_ENDPOINT_XFER_INT:
if (is_out)
allowed |= URB_ZERO_PACKET;
/* FALLTHROUGH */
Acked-by: Alan Stern st...@rowland.harvard.edu
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
Hi Felipe, What happened to these two patches ? On Monday 16 December 2013 17:48:29 Felipe Balbi wrote: On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131216 13:31]: On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com Here it is, let me know if you prefer a signed tag: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb-phy-binding-omap3 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18: arm: omap: remove *.auto* from device names given in usb_bind_phy (2013-12-16 17:44:43 -0600) Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy arch/arm/mach-omap2/board-2430sdp.c| 2 +- arch/arm/mach-omap2/board-3430sdp.c| 2 +- arch/arm/mach-omap2/board-cm-t35.c | 2 +- arch/arm/mach-omap2/board-devkit8000.c | 2 +- arch/arm/mach-omap2/board-ldp.c| 2 +- arch/arm/mach-omap2/board-omap3beagle.c| 2 +- arch/arm/mach-omap2/board-omap3logic.c | 2 +- arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-omap3stalker.c | 2 +- arch/arm/mach-omap2/board-omap3touchbook.c | 2 +- arch/arm/mach-omap2/board-overo.c | 2 +- arch/arm/mach-omap2/board-rx51.c | 2 +- drivers/usb/musb/musb_core.c | 31 ++- drivers/usb/musb/musb_core.h | 2 ++ drivers/usb/musb/omap2430.c| 19 -- 15 files changed, 61 insertions(+), 15 deletions(-) -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH 8/9] usb: phy: am335x: call usb_gen_phy_init()/usb_gen_phy_shutdown() in am335x_init()/am335x_shutdown()
Hi,, On Mon, Jul 21, 2014 at 10:03:07AM +0200, Lothar Waßmann wrote: Hi, On Fri, Jul 18, 2014 at 11:31:29AM +0200, Lothar Waßmann wrote: This patch makes it possible to use the musb driver with HW that requires external regulators or clocks. can you provide an example of such HW ? Are you not using the internal PHYs ? The Ka-Ro electronics TX48 module uses the mmc0_clk pin as VBUSEN rathern than usb0_drvvbus. This patch makes it possible to use an external regulator to handle the VBUS switch through the 'vcc-supply' property of the underlying generic_phy device. OK, I get it now. But why would not use usb0_drvvbus ? You could still route usb0_drvvbus to the regulator enable pin and the regulator would be enabled for you once correct values are written to the IP's mailbox. I suppose this has something to do with layout constraints ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/9] usb: musb: several bugfixes for the musb driver
On Mon, Jul 21, 2014 at 09:34:30AM +0200, Lothar Waßmann wrote: Hi, Felipe Balbi wrote: Hi, On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote: Hi Lothar, On 18 Jul 11:31 AM, Lothar Waßmann wrote: The first three patches do some source code cleanup in the files that are modified in the subsequent patches. I've applied patches 4 and 9 on a recent -next, after fixing a conflict due to patch 3 (usb: musb_am335x: source cleanup): Patch 4 carries the proper fix reported in commit: 7adb5c876e9c (usb: musb: Fix panic upon musb_am335x module removal) Patch 9 reinstates module unloading support for the musb_am335x driver which was disabled due to a false failure analysis For these two patches, Tested-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Tested on a beaglebone with a mass storage USB device, module load/unload works without issues. The module_get/put in the phy is now preventing the musb_am335x driver unload, which seems to be the real cause of the issue I reported. Thanks for providing a proper fix! I don't that's a good fix. The problem is that even after am335x removing all its child, someone else tried to release the PHY. That ordering is the one that needs to be fixed. Doing a module_get on the parent device looks like a hack to me. No. It guarantees that the module cannot be unloaded when its resources are still in use! it's still a hack. You have a child incrementing the usage count on its parent just because a sibbling isn't doing the right thing. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
Hi, On Mon, Jul 21, 2014 at 05:04:57PM +0200, Laurent Pinchart wrote: Hi Felipe, What happened to these two patches ? looks like I lost them. On Monday 16 December 2013 17:48:29 Felipe Balbi wrote: On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131216 13:31]: On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com Here it is, let me know if you prefer a signed tag: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb-phy-binding-omap3 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18: arm: omap: remove *.auto* from device names given in usb_bind_phy (2013-12-16 17:44:43 -0600) Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy Kishon, are these still valid ? -- balbi signature.asc Description: Digital signature
Re: high cpu load on omap3 using musb
Hi Adam,
On Wednesday 29 January 2014 08:44:57 Adam Wozniak wrote:
With a USB 2.0 webcam attached to the OTG port on an OMAP3 (applies to
overo gumstix, beagleboard, probably others) we see a high CPU load in a
kworker thread.
Between 2.6.33 and 2.6.34 musb_core.c changed.
IRQ handlers changed with the result that a worker in musb_core.c got
scheduled far more frequently than needed.
I've included a patch below against 3.7, but i think it'll apply against
mainline.
[I apologize for any whitespace mangling. I've also attached the patch.]
I'd like more eyeballs to tell me if this is right. I'd also like to
know who I need to talk to to get this pushed into mainline.
Running the scripts/get_maintainer.pl script on your patch produces
Felipe Balbi ba...@ti.com (maintainer:MUSB MULTIPOINT H...)
Greg Kroah-Hartman gre...@linuxfoundation.org (supporter:USB SUBSYSTEM)
linux-usb@vger.kernel.org (open list:MUSB MULTIPOINT H...)
linux-ker...@vger.kernel.org (open list)
Felipe Balbi (CC'ed) is the person who you should talk to.
While we're touching the subject of scripts, you should run the
scripts/checkpatch.pl script and fix errors and warnings before submitting
patches. Please see Documentation/SubmittingPatches.
Last (but not least) piece of advice, don't give up if you don't receive
replies to your patches. People are busy and mails fall to cracks from time to
time.
Felipe, apart from the coding style violation and the possibly missing
locking, what's your opinion on this ? Does the patch make sense ?
# The MUSB IRQ schedules work on every interrupt.
# This is unnecessary, and causes excessive CPU load.
#
# Here we only schedule work if there is something for
# the worker to do.
Index: git/drivers/usb/musb/musb_core.c
===
--- git.orig/drivers/usb/musb/musb_core.c
+++ git/drivers/usb/musb/musb_core.c
@@ -925,7 +925,9 @@ b_host:
}
#endif
- schedule_work(musb-irq_work);
+ if (musb-xceiv-state != musb-xceiv_old_state) {
+ schedule_work(musb-irq_work);
+ }
return handled;
}
--
Regards,
Laurent Pinchart
--
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
[GIT PULL] USB changes for v3.17
Hi Greg, Here's my big set of patches containing 97 commits. While it looks big and all, most commits are just cleanups moving code around, using devm_*, etc. I tested these patches on a couple TI platforms and couldn't find any regressions on my setup. This tree has also been on linux-next for a while. Please consider merging on top of your usb-next branch or let me know if you want anything to change. cheers The following changes since commit 4c834452aad01531db949414f94f817a86348d59: Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.17 for you to fetch changes up to 8346b33fad01cfe93f0fd0e64cd32ff40bd4ba41: Documentation: DocBook: elieminate doc build break (2014-07-17 12:21:16 -0500) usb: patches for v3.17 merge window Surprisingly enough, while a big set of patches, the majority is composed of cleanups (using devm_*, fixing sparse errors, moving code around, adding const, etc). The highlights are addition of new support for PLX USB338x devices, and support for USB 2.0-only configurations of the DWC3 IP core. Signed-of-by: Felipe Balbi ba...@ti.com Andrzej Pietrasiewicz (8): usb: gadget: f_fs: rename descriptor parsing functions usb: gadget: u_os_desc: helper functions for accessing ext prop buffer usb: gadget: f_fs: OS descriptors support usb: gadget: Gadget directory cleanup - group legacy gadgets usb: gadget: Gadget directory cleanup - group UDC drivers usb: gadget: Gadget directory cleanup - group usb functions usb: gadget: f_rndis: fix interface id for OS descriptors Documentation: DocBook: elieminate doc build break Apelete Seketeli (1): usb: musb: register nop transceiver driver for jz4740 Arnd Bergmann (1): usb: gadget: pxa25x_udc: use correct header for gpio devm_ functions Ben Dooks (8): usb: gadget: r8a66597-udc: use devm_ioremap_resource() for registers usb: gadget: r8a66597-udc: keep dev as reference to pdev-dev usb: gadget: r8a66597-udc: use devm_kzalloc() to allocate driver state usb: gadget: r8a66597-udc: handle sudmac registers with devm_ioremap_resource() usb: gadget: r8a66597-udc: cleanup error path usb: gadget: r8a66597-udc: use devm_clk_get() to get clock usb: gadget: r8a66597-udc: use devm_request_irq() to get device irq usb: gadget: r8a66597-udc: remove now unused clean_up and clean_up3 label. Benoit Taine (1): usb: gadget: Use kmemdup instead of kmalloc + memcpy Daniel Mack (8): 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 mask for CSR in musb_h_tx_flush_fifo() usb: musb: introduce dma_channel.rx_packet_done usb: musb/cppi41: call musb_ep_select() before accessing an endpoint's CSR usb: musb: fix wrong indentation in musb_host.c Revert usb: musb: musb_cppi41: Handle ISOCH differently and not use the hrtimer. usb: musb: cppi41: fire hrtimer according to programmed channel length Felipe Balbi (3): usb: gadget: udc: fsl_udc_core: fix sparse errors usb: gadget: udc: net2280: fix sparse error usb: gadget: udc: fsl_mxc_udc: fix sparse error George Cherian (9): usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset() usb: dwc3: omap: remove x_major calculation from revision register usb: dwc3: omap: add dwc3_omap_map_offset() function usb: dwc3: omap: add dwc3_omap_set_utmi_mode() function usb: dwc3: omap: add dwc3_omap_extcon_register function usb: musb: core: Handle Babble condition only in HOST mode usb: musb: core: Convert babble recover work to delayed work usb: musb: core: Convert the musb_platform_reset to have a return value. usb: musb: dsps: Add the sw_babble_control() and Enable for newer silicon Himangi Saraogi (7): usb: gadget: pxa25x_udc: use devm_ functions usb: musb: ux500: use devm_ functions usb: gadget: fsl_qe_udc: Introduce use of managed version of kzalloc usb: phy: phy-gpio-vbus-usb: use devm_ functions usb: musb: davinci: use devm_ functions. usb: musb: tusb6010: Introduce the use of the managed version of kzalloc usb: musb: backfin: Introduce the use of the managed version of kzalloc Jim Baxter (3): usb: gadget: NCM: RX function support multiple NDPs usb: gadget: NCM: Add transmit multi-frame. usb: gadget: NCM: Stop RX TCP Bursts getting dropped. Jingoo Han (6): usb: phy: msm: Make of_device_id array const usb: phy: tegra: Make of_device_id array const usb: gadget: gr_udc: Make of_device_id array const usb: gadget: lpc32xx_udc: Make of_device_id array
Re: high cpu load on omap3 using musb
On Mon, Jul 21, 2014 at 05:28:58PM +0200, Laurent Pinchart wrote:
Hi Adam,
On Wednesday 29 January 2014 08:44:57 Adam Wozniak wrote:
With a USB 2.0 webcam attached to the OTG port on an OMAP3 (applies to
overo gumstix, beagleboard, probably others) we see a high CPU load in a
kworker thread.
Between 2.6.33 and 2.6.34 musb_core.c changed.
IRQ handlers changed with the result that a worker in musb_core.c got
scheduled far more frequently than needed.
I've included a patch below against 3.7, but i think it'll apply against
mainline.
[I apologize for any whitespace mangling. I've also attached the patch.]
I'd like more eyeballs to tell me if this is right. I'd also like to
know who I need to talk to to get this pushed into mainline.
Running the scripts/get_maintainer.pl script on your patch produces
Felipe Balbi ba...@ti.com (maintainer:MUSB MULTIPOINT H...)
Greg Kroah-Hartman gre...@linuxfoundation.org (supporter:USB SUBSYSTEM)
linux-usb@vger.kernel.org (open list:MUSB MULTIPOINT H...)
linux-ker...@vger.kernel.org (open list)
Felipe Balbi (CC'ed) is the person who you should talk to.
While we're touching the subject of scripts, you should run the
scripts/checkpatch.pl script and fix errors and warnings before submitting
patches. Please see Documentation/SubmittingPatches.
Last (but not least) piece of advice, don't give up if you don't receive
replies to your patches. People are busy and mails fall to cracks from time
to
time.
Felipe, apart from the coding style violation and the possibly missing
locking, what's your opinion on this ? Does the patch make sense ?
It's a duplication of the check which is already in musb_irq_work():
1742 static void musb_irq_work(struct work_struct *data)
1743 {
1744 struct musb *musb = container_of(data, struct musb, irq_work);
1745
1746 if (musb-xceiv-state != musb-xceiv_old_state) {
1747 musb-xceiv_old_state = musb-xceiv-state;
1748 sysfs_notify(musb-controller-kobj, NULL, mode);
1749 }
1750 }
That does look better, but I'd need the check inside musb_irq_work() to
be removed and commit log would have to improve a bit.
ps: there's no missing locking, musb_stage0_irq() is called within
musb_interrupt() which is called within a locked IRQ handler.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/9] usb: musb: several bugfixes for the musb driver
On 21 Jul 10:11 AM, Felipe Balbi wrote: On Mon, Jul 21, 2014 at 09:34:30AM +0200, Lothar Waßmann wrote: Hi, Felipe Balbi wrote: Hi, On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote: Hi Lothar, On 18 Jul 11:31 AM, Lothar Waßmann wrote: The first three patches do some source code cleanup in the files that are modified in the subsequent patches. I've applied patches 4 and 9 on a recent -next, after fixing a conflict due to patch 3 (usb: musb_am335x: source cleanup): Patch 4 carries the proper fix reported in commit: 7adb5c876e9c (usb: musb: Fix panic upon musb_am335x module removal) Patch 9 reinstates module unloading support for the musb_am335x driver which was disabled due to a false failure analysis For these two patches, Tested-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Tested on a beaglebone with a mass storage USB device, module load/unload works without issues. The module_get/put in the phy is now preventing the musb_am335x driver unload, which seems to be the real cause of the issue I reported. Thanks for providing a proper fix! I don't that's a good fix. The problem is that even after am335x removing all its child, someone else tried to release the PHY. That ordering is the one that needs to be fixed. Doing a module_get on the parent device looks like a hack to me. No. It guarantees that the module cannot be unloaded when its resources are still in use! it's still a hack. You have a child incrementing the usage count on its parent just because a sibbling isn't doing the right thing. How about having the musb_am335x (glue driver) call request_module and module_get on the phy-am335x? Wouldn't this be a cleaner approach? I haven't checked if this possible, though. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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/9] usb: musb: several bugfixes for the musb driver
On Mon, Jul 21, 2014 at 12:53:52PM -0300, Ezequiel Garcia wrote: On 21 Jul 10:11 AM, Felipe Balbi wrote: On Mon, Jul 21, 2014 at 09:34:30AM +0200, Lothar Waßmann wrote: Hi, Felipe Balbi wrote: Hi, On Fri, Jul 18, 2014 at 01:16:36PM -0300, Ezequiel Garcia wrote: Hi Lothar, On 18 Jul 11:31 AM, Lothar Waßmann wrote: The first three patches do some source code cleanup in the files that are modified in the subsequent patches. I've applied patches 4 and 9 on a recent -next, after fixing a conflict due to patch 3 (usb: musb_am335x: source cleanup): Patch 4 carries the proper fix reported in commit: 7adb5c876e9c (usb: musb: Fix panic upon musb_am335x module removal) Patch 9 reinstates module unloading support for the musb_am335x driver which was disabled due to a false failure analysis For these two patches, Tested-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Tested on a beaglebone with a mass storage USB device, module load/unload works without issues. The module_get/put in the phy is now preventing the musb_am335x driver unload, which seems to be the real cause of the issue I reported. Thanks for providing a proper fix! I don't that's a good fix. The problem is that even after am335x removing all its child, someone else tried to release the PHY. That ordering is the one that needs to be fixed. Doing a module_get on the parent device looks like a hack to me. No. It guarantees that the module cannot be unloaded when its resources are still in use! it's still a hack. You have a child incrementing the usage count on its parent just because a sibbling isn't doing the right thing. How about having the musb_am335x (glue driver) call request_module and module_get on the phy-am335x? Wouldn't this be a cleaner approach? I haven't checked if this possible, though. at most, you would have the phy layer do that so that all PHYs get usage counter incremented when they're in use. We can't have this 'fixed' for MUSB only. -- balbi signature.asc Description: Digital signature
Re: non-working UVC device 058f:5608
On Monday 09 June 2014 12:27:37 Johannes Berg wrote: On Mon, 2014-06-09 at 11:59 +0200, Johannes Berg wrote: Johannes, could you enable USB debugging in the linus/master kernel and provide a kernel log ? I'll try to get some logs (wasn't there tracing added to xhci too? will check) Here we go - log + tracing: log: http://p.sipsolutions.net/d5926c43d531e3af.txt trace: http://johannes.sipsolutions.net/files/xhci.trace.dat.xz I plugged in the device, waited a bit, tried to run a camera application (didn't work) and then ran lsusb -t and lsusb -v. Mathias, would you have time to give this a quick look ? -- Regards, Laurent Pinchart -- 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 changes for v3.17
On Mon, Jul 21, 2014 at 10:35:29AM -0500, Felipe Balbi wrote: Hi Greg, Here's my big set of patches containing 97 commits. While it looks big and all, most commits are just cleanups moving code around, using devm_*, etc. I tested these patches on a couple TI platforms and couldn't find any regressions on my setup. This tree has also been on linux-next for a while. Please consider merging on top of your usb-next branch or let me know if you want anything to change. cheers The following changes since commit 4c834452aad01531db949414f94f817a86348d59: Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.17 I've now merged and pushed this out. I did have some merge conflicts in these files: drivers/usb/musb/musb_core.c drivers/usb/musb/musb_cppi41.c include/uapi/linux/usb/functionfs.h and I _think_ I resolved them properly, but getting verification of this would be great. 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: high cpu load on omap3 using musb
Hi Felipe and Adam,
On Monday 21 July 2014 10:40:52 Felipe Balbi wrote:
On Mon, Jul 21, 2014 at 05:28:58PM +0200, Laurent Pinchart wrote:
On Wednesday 29 January 2014 08:44:57 Adam Wozniak wrote:
With a USB 2.0 webcam attached to the OTG port on an OMAP3 (applies to
overo gumstix, beagleboard, probably others) we see a high CPU load in a
kworker thread.
Between 2.6.33 and 2.6.34 musb_core.c changed.
IRQ handlers changed with the result that a worker in musb_core.c got
scheduled far more frequently than needed.
I've included a patch below against 3.7, but i think it'll apply against
mainline.
[I apologize for any whitespace mangling. I've also attached the
patch.]
I'd like more eyeballs to tell me if this is right. I'd also like to
know who I need to talk to to get this pushed into mainline.
Running the scripts/get_maintainer.pl script on your patch produces
Felipe Balbi ba...@ti.com (maintainer:MUSB MULTIPOINT H...)
Greg Kroah-Hartman gre...@linuxfoundation.org (supporter:USB SUBSYSTEM)
linux-usb@vger.kernel.org (open list:MUSB MULTIPOINT H...)
linux-ker...@vger.kernel.org (open list)
Felipe Balbi (CC'ed) is the person who you should talk to.
While we're touching the subject of scripts, you should run the
scripts/checkpatch.pl script and fix errors and warnings before submitting
patches. Please see Documentation/SubmittingPatches.
Last (but not least) piece of advice, don't give up if you don't receive
replies to your patches. People are busy and mails fall to cracks from
time to time.
Felipe, apart from the coding style violation and the possibly missing
locking, what's your opinion on this ? Does the patch make sense ?
It's a duplication of the check which is already in musb_irq_work():
1742 static void musb_irq_work(struct work_struct *data)
1743 {
1744 struct musb *musb = container_of(data, struct musb, irq_work);
1745
1746 if (musb-xceiv-state != musb-xceiv_old_state) {
1747 musb-xceiv_old_state = musb-xceiv-state;
1748 sysfs_notify(musb-controller-kobj, NULL, mode);
1749 }
1750 }
That does look better, but I'd need the check inside musb_irq_work() to
be removed and commit log would have to improve a bit.
OK. Adam, could you please modify the patch accordingly and resubmit it ?
ps: there's no missing locking, musb_stage0_irq() is called within
musb_interrupt() which is called within a locked IRQ handler.
I hadn't checked that, thank you for the confirmation.
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Retro-fit USB monitor
I'm at a loss. I want to retrofit a USB host driver with the calls necessary to implement USB monitoring but I can't find any good reference material. Can someone point me in the right direction? The usbmon.txt file does a nice job on using the facility but doesn't say much about the driver side. Thanks Sent from my iPhone-- 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: Retro-fit USB monitor
On Mon, 21 Jul 2014, Dave wrote: I'm at a loss. I want to retrofit a USB host driver with the calls necessary to implement USB monitoring but I can't find any good reference material. Can someone point me in the right direction? The usbmon.txt file does a nice job on using the facility but doesn't say much about the driver side. You're in luck -- no changes to the driver are needed. The usbmon module and usbcore take care of everything for you. :-) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Retro-fit USB monitor
On Mon, Jul 21, 2014 at 04:52:40PM -0400, Dave wrote: I'm at a loss. I want to retrofit a USB host driver with the calls necessary to implement USB monitoring but I can't find any good reference material. Can someone point me in the right direction? The usbmon.txt file does a nice job on using the facility but doesn't say much about the driver side. What USB host driver are you using that doesn't support the usbmon interface? You shouldn't need to add any hooks into the host driver, the USB core should handle all of this automatically for you. 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: [GIT PULL] USB changes for v3.17
On Mon, Jul 21, 2014 at 11:34:50AM -0700, Greg KH wrote: On Mon, Jul 21, 2014 at 10:35:29AM -0500, Felipe Balbi wrote: Hi Greg, Here's my big set of patches containing 97 commits. While it looks big and all, most commits are just cleanups moving code around, using devm_*, etc. I tested these patches on a couple TI platforms and couldn't find any regressions on my setup. This tree has also been on linux-next for a while. Please consider merging on top of your usb-next branch or let me know if you want anything to change. cheers The following changes since commit 4c834452aad01531db949414f94f817a86348d59: Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git tags/usb-for-v3.17 I've now merged and pushed this out. I did have some merge conflicts in these files: drivers/usb/musb/musb_core.c drivers/usb/musb/musb_cppi41.c include/uapi/linux/usb/functionfs.h and I _think_ I resolved them properly, but getting verification of this would be great. your resolution looks correct to me, thank you. -- balbi signature.asc Description: Digital signature
Re: Retro-fit USB monitor
It's the gadget driver for the Freescale Dual role controller. Sent from my iPhone On Jul 21, 2014, at 5:01 PM, Greg KH g...@kroah.com wrote: On Mon, Jul 21, 2014 at 04:52:40PM -0400, Dave wrote: I'm at a loss. I want to retrofit a USB host driver with the calls necessary to implement USB monitoring but I can't find any good reference material. Can someone point me in the right direction? The usbmon.txt file does a nice job on using the facility but doesn't say much about the driver side. What USB host driver are you using that doesn't support the usbmon interface? You shouldn't need to add any hooks into the host driver, the USB core should handle all of this automatically for you. 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: Retro-fit USB monitor
A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Mon, Jul 21, 2014 at 05:17:16PM -0400, Dave wrote: It's the gadget driver for the Freescale Dual role controller. gadget drivers do not use usbmon on the gadget side, sorry. That's a host-controller-only interface for now. 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: [PATCH 01/12] usb: dwc2: Update Kconfig to support dual-role
From: dingu...@altera.com [mailto:dingu...@altera.com] Sent: Wednesday, July 16, 2014 1:33 PM Update DWC2 kconfig and makefile to support dual-role mode. The platform file will always get compiled for the case where the controller is directly connected to the CPU. So for loadable modules, only dwc2.ko is needed. Signed-off-by: Dinh Nguyen dingu...@altera.com --- drivers/usb/dwc2/Kconfig | 59 ++--- drivers/usb/dwc2/Makefile | 21 2 files changed, 45 insertions(+), 35 deletions(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..5f32e62 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,40 +1,31 @@ config USB_DWC2 - bool DesignWare USB2 DRD Core Support + tristate DesignWare USB2 DRD Core Support depends on USB help Say Y here if your system has a Dual Role Hi-Speed USB controller based on the DesignWare HSOTG IP Core. - For host mode, if you choose to build the driver as dynamically - linked modules, the core module will be called dwc2.ko, the PCI - bus interface module (if you have a PCI bus system) will be - called dwc2_pci.ko, and the platform interface module (for - controllers directly connected to the CPU) will be called - dwc2_platform.ko. For gadget mode, there will be a single - module called dwc2_gadget.ko. + If you choose to build the driver as dynamically + linked modules, a single dwc2.ko(regardless of mode of operation) + will get built for both platform IPs and PCI. - NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. The - host and gadget drivers are still currently separate drivers. - There are plans to merge the dwc2_gadget driver with the dwc2 - host driver in the near future to create a dual-role driver. + NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. Looks like this line is incorrect, dwc2_gadget.ko no longer exists, right? -- 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: Retro-fit USB monitor
Sorry about the poor form! Bad habit I suppose. That's a host-controller-only interface for now. That being usbmon - right? But there is no intrinsic reason I couldn't use the USB core as a model for retrofitting the Freescale DR driver is there? BTW - I haven't found any thing describing the difference between the uN and sN (eg u0 and s0) files. Sent from my iPhone -- 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 01/12] usb: dwc2: Update Kconfig to support dual-role
On Mon, 2014-07-21 at 21:39 +, Paul Zimmerman wrote: From: dingu...@altera.com [mailto:dingu...@altera.com] Sent: Wednesday, July 16, 2014 1:33 PM Update DWC2 kconfig and makefile to support dual-role mode. The platform file will always get compiled for the case where the controller is directly connected to the CPU. So for loadable modules, only dwc2.ko is needed. Signed-off-by: Dinh Nguyen dingu...@altera.com --- drivers/usb/dwc2/Kconfig | 59 ++--- drivers/usb/dwc2/Makefile | 21 2 files changed, 45 insertions(+), 35 deletions(-) diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig index f93807b..5f32e62 100644 --- a/drivers/usb/dwc2/Kconfig +++ b/drivers/usb/dwc2/Kconfig @@ -1,40 +1,31 @@ config USB_DWC2 - bool DesignWare USB2 DRD Core Support + tristate DesignWare USB2 DRD Core Support depends on USB help Say Y here if your system has a Dual Role Hi-Speed USB controller based on the DesignWare HSOTG IP Core. - For host mode, if you choose to build the driver as dynamically - linked modules, the core module will be called dwc2.ko, the PCI - bus interface module (if you have a PCI bus system) will be - called dwc2_pci.ko, and the platform interface module (for - controllers directly connected to the CPU) will be called - dwc2_platform.ko. For gadget mode, there will be a single - module called dwc2_gadget.ko. + If you choose to build the driver as dynamically + linked modules, a single dwc2.ko(regardless of mode of operation) + will get built for both platform IPs and PCI. - NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. The - host and gadget drivers are still currently separate drivers. - There are plans to merge the dwc2_gadget driver with the dwc2 - host driver in the near future to create a dual-role driver. + NOTE: The s3c-hsotg driver is now renamed to dwc2_gadget. Looks like this line is incorrect, dwc2_gadget.ko no longer exists, right? Yes, that is correct. Thanks, Dinh -- 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: Retro-fit USB monitor
On Mon, Jul 21, 2014 at 06:08:05PM -0400, Dave wrote: Sorry about the poor form! Bad habit I suppose. That's a host-controller-only interface for now. That being usbmon - right? Yes. But there is no intrinsic reason I couldn't use the USB core as a model for retrofitting the Freescale DR driver is there? I have no idea what driver you are referring to, why isn't it merged into the kernel tree already? BTW - I haven't found any thing describing the difference between the uN and sN (eg u0 and s0) files. Did you read the usbmon documentation? 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: [PATCH 0/4] Allow xHCI drivers to be built as separate modules
On Wed, Jul 9, 2014 at 6:05 PM, Andrew Bresticker abres...@chromium.org wrote: It was suggested in the review of the Tegra xHCI driver [1] that we allow xHCI drivers to be built as individual modules (like EHCI) instead of building them all into the single xhci-hcd module as they are today. Patches 1-3 prepare for making the xHCI PCI and platform drivers able to be built as individual modules and patch 4 actually creates the 3 separate modules (core, platform, PCI). Based on 3.16-rc4. [1] http://patchwork.ozlabs.org/patch/361265/ Andrew Bresticker (4): xhci: Introduce xhci_init_driver() xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold xhci: Export symbols used by host-controller drivers xhci: Allow xHCI drivers to be built as separate modules Ping. I was hoping to get these in for 3.17 (though it may be too late now...) as they're a dependency for the upcoming Tegra XHCI driver. Thanks! Andrew -- 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/6] vf610: Add USB support
On Fri, Jul 18, 2014 at 07:01:36PM +0200, Stefan Agner wrote: This patchset adds USB support for Vybrid VF610 SoC. It extends the clock framework to support the USB PHY cocks, extends the device tree files and adds support for the non-core registers in the usbmisc_imx driver. This patchset needs the eSDHC length fix available in Shawn's for-next branch. Why it is related to USB patchset? The whole patchset proved to be working on a Colibri VF61. The first USB controller runs in peripheral mode. I could successfully use RNDIS, however with some stability issues: Suddenly the other side was not reachable anymore and the interface needed to brought down and back up again. I'm still investigating this. Do you use ubuntu as host distribution? I find ubuntu will lost the first connection for usb-ethernet-gadget(usb0) as network interface, but once you re-config usb0 again (ifconfig usb0 ip up), it should work and will not lose connection any more. The second USB controller, running in USB host mode, showed no issues so far. Stefan Agner (6): ARM: dts: vf610: add USB PHY and controller ARM: imx: clk-vf610: add USBPHY clocks ARM: dts: vf610: Add usbmisc for non-core registers chipidea: usbmisc_imx: Add USB support for VF610 SoCs usb: phy: mxs: Add VF610 USB PHY support ARM: dts: vf610-colibri: add USB support arch/arm/boot/dts/vf610-colibri.dts | 10 + arch/arm/boot/dts/vf610.dtsi| 55 ++-- arch/arm/mach-imx/clk-vf610.c | 12 +- drivers/usb/chipidea/usbmisc_imx.c | 76 +++-- drivers/usb/phy/phy-mxs-usb.c | 5 +++ include/dt-bindings/clock/vf610-clock.h | 5 ++- 6 files changed, 135 insertions(+), 28 deletions(-) -- 2.0.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 -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] usb: phy: mxs: Add VF610 USB PHY support
On Fri, Jul 18, 2014 at 07:01:41PM +0200, Stefan Agner wrote:
This adds support for the USB PHY in Vybrid VF610. We assume that
the disconnection without VBUS is also needed for Vybrid. For all
other flags, the presumption of innocence applies.
Signed-off-by: Stefan Agner ste...@agner.ch
---
drivers/usb/phy/phy-mxs-usb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index c42bdf0..207946b 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -125,10 +125,15 @@ static const struct mxs_phy_data imx6sl_phy_data = {
MXS_PHY_NEED_IP_FIX,
};
+static const struct mxs_phy_data vf610_phy_data = {
+ .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+};
+
static const struct of_device_id mxs_phy_dt_ids[] = {
{ .compatible = fsl,imx6sl-usbphy, .data = imx6sl_phy_data, },
{ .compatible = fsl,imx6q-usbphy, .data = imx6q_phy_data, },
{ .compatible = fsl,imx23-usbphy, .data = imx23_phy_data, },
+ { .compatible = fsl,vf610-usbphy, .data = vf610_phy_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
--
2.0.1
Acked-by: Peter Chen peter.c...@freescale.com
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] chipidea: usbmisc_imx: Add USB support for VF610 SoCs
On Fri, Jul 18, 2014 at 07:01:40PM +0200, Stefan Agner wrote:
This adds Vybrid VF610 SoC support. The IP is very similar to i.MX6,
however the non-core registers are spread in two different register
areas. Hence we support multiple registers which are addressed by
the index of usbmisc.
Signed-off-by: Stefan Agner ste...@agner.ch
---
I tried first to create two usbmisc nodes and hoped it would instanciate
the driver twice, however, the driver currently only supports one instance.
In an short attempt to add support for that, I realized that since the
data structure holding the information for each instance is within the
driver ci_hdrc_imx. For Vybrid two instances would make much more sense,
however, a i.MX6Q shares all the non-core registers in one register area,
hence only one driver can map this area. I ended up with this multiple
registers solution, altough for the Vybrid multiple instances would
probably make more sense. Any thoughts on this?
I prefer rename current usbmisc_imx as usbmisc_mix_v1 and create the
new usbmisc_imx_v2 for multiple instances case.
Peter
drivers/usb/chipidea/usbmisc_imx.c | 76
+++---
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c
b/drivers/usb/chipidea/usbmisc_imx.c
index 85293b8..61c2350 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -57,6 +57,10 @@
#define MX6_BM_OVER_CUR_DIS BIT(7)
+#define VF610_OVER_CUR_DIS BIT(7)
+
+#define MAX_BASE_ADDR2
+
struct usbmisc_ops {
/* It's called once when probe a usb device */
int (*init)(struct imx_usbmisc_data *data);
@@ -65,7 +69,7 @@ struct usbmisc_ops {
};
struct imx_usbmisc {
- void __iomem *base;
+ void __iomem *base[MAX_BASE_ADDR];
spinlock_t lock;
struct clk *clk;
const struct usbmisc_ops *ops;
@@ -84,20 +88,20 @@ static int usbmisc_imx25_init(struct imx_usbmisc_data
*data)
spin_lock_irqsave(usbmisc-lock, flags);
switch (data-index) {
case 0:
- val = readl(usbmisc-base);
+ val = readl(usbmisc-base[0]);
val = ~(MX25_OTG_SIC_MASK | MX25_OTG_PP_BIT);
val |= (MX25_EHCI_INTERFACE_DIFF_UNI
MX25_EHCI_INTERFACE_MASK) MX25_OTG_SIC_SHIFT;
val |= (MX25_OTG_PM_BIT | MX25_OTG_OCPOL_BIT);
- writel(val, usbmisc-base);
+ writel(val, usbmisc-base[0]);
break;
case 1:
- val = readl(usbmisc-base);
+ val = readl(usbmisc-base[0]);
val = ~(MX25_H1_SIC_MASK | MX25_H1_PP_BIT |
MX25_H1_IPPUE_UP_BIT);
val |= (MX25_EHCI_INTERFACE_SINGLE_UNI
MX25_EHCI_INTERFACE_MASK) MX25_H1_SIC_SHIFT;
val |= (MX25_H1_PM_BIT | MX25_H1_OCPOL_BIT | MX25_H1_TLL_BIT |
MX25_H1_USBTE_BIT | MX25_H1_IPPUE_DOWN_BIT);
- writel(val, usbmisc-base);
+ writel(val, usbmisc-base[0]);
break;
}
@@ -115,7 +119,7 @@ static int usbmisc_imx25_post(struct imx_usbmisc_data
*data)
if (data-index 2)
return -EINVAL;
- reg = usbmisc-base + MX25_USB_PHY_CTRL_OFFSET;
+ reg = usbmisc-base[0] + MX25_USB_PHY_CTRL_OFFSET;
if (data-evdo) {
spin_lock_irqsave(usbmisc-lock, flags);
@@ -149,10 +153,10 @@ static int usbmisc_imx27_init(struct imx_usbmisc_data
*data)
spin_lock_irqsave(usbmisc-lock, flags);
if (data-disable_oc)
- val = readl(usbmisc-base) | val;
+ val = readl(usbmisc-base[0]) | val;
else
- val = readl(usbmisc-base) ~val;
- writel(val, usbmisc-base);
+ val = readl(usbmisc-base[0]) ~val;
+ writel(val, usbmisc-base[0]);
spin_unlock_irqrestore(usbmisc-lock, flags);
return 0;
@@ -168,29 +172,29 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data
*data)
return -EINVAL;
/* Select a 24 MHz reference clock for the PHY */
- reg = usbmisc-base + MX53_USB_OTG_PHY_CTRL_1_OFFSET;
+ reg = usbmisc-base[0] + MX53_USB_OTG_PHY_CTRL_1_OFFSET;
val = readl(reg);
val = ~MX53_USB_PHYCTRL1_PLLDIV_MASK;
val |= MX53_USB_PLL_DIV_24_MHZ;
- writel(val, usbmisc-base + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
+ writel(val, usbmisc-base[0] + MX53_USB_OTG_PHY_CTRL_1_OFFSET);
if (data-disable_oc) {
spin_lock_irqsave(usbmisc-lock, flags);
switch (data-index) {
case 0:
- reg = usbmisc-base + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
+ reg = usbmisc-base[0] + MX53_USB_OTG_PHY_CTRL_0_OFFSET;
val = readl(reg) | MX53_BM_OVER_CUR_DIS_OTG;
break;
case 1:
- reg = usbmisc-base +
Re: [PATCH 0/4] Allow xHCI drivers to be built as separate modules
On Mon, Jul 21, 2014 at 04:41:08PM -0700, Andrew Bresticker wrote: On Wed, Jul 9, 2014 at 6:05 PM, Andrew Bresticker abres...@chromium.org wrote: It was suggested in the review of the Tegra xHCI driver [1] that we allow xHCI drivers to be built as individual modules (like EHCI) instead of building them all into the single xhci-hcd module as they are today. Patches 1-3 prepare for making the xHCI PCI and platform drivers able to be built as individual modules and patch 4 actually creates the 3 separate modules (core, platform, PCI). Based on 3.16-rc4. [1] http://patchwork.ozlabs.org/patch/361265/ Andrew Bresticker (4): xhci: Introduce xhci_init_driver() xhci: Check for XHCI_COMP_MODE_QUIRK when disabling D3cold xhci: Export symbols used by host-controller drivers xhci: Allow xHCI drivers to be built as separate modules Ping. I was hoping to get these in for 3.17 (though it may be too late now...) as they're a dependency for the upcoming Tegra XHCI driver. That's up to Mathias, when he sends them on to me, or not... -- 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: ci_hdrc_imx doc: fsl,usbphy is required
From: Markus Pargmann m...@pengutronix.de fsl,usbphy is no optional property. This patch moves it to the list of required properties. Signed-off-by: Markus Pargmann m...@pengutronix.de Signed-off-by: Peter Chen peter.c...@freescale.com --- .../devicetree/bindings/usb/ci-hdrc-imx.txt|2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index a6a32cb..1bae71e 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Should be fsl,imx27-usb - reg: Should contain registers location and length - interrupts: Should contain controller interrupt +- fsl,usbphy: phandle of usb phy that connects to the port Recommended properies: - phy_type: the type of the phy connected to the core. Should be one @@ -12,7 +13,6 @@ Recommended properies: - dr_mode: One of host, peripheral or otg. Defaults to otg Optional properties: -- fsl,usbphy: phandler of usb phy that connects to the only one port - fsl,usbmisc: phandler of non-core register device, with one argument that indicate usb controller index - vbus-supply: regulator for vbus -- 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 patchset for v3.17
Hi Greg, Only some tiny changes for this patchset, like fix building warning and change return value, thanks. Markus Pargmann (2): usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY usb: ci_hdrc_imx doc: fsl,usbphy is required Wei Yongjun (1): usb: chipidea: debug: fix sparse non static symbol warnings .../devicetree/bindings/usb/ci-hdrc-imx.txt|2 +- drivers/usb/chipidea/ci_hdrc_imx.c |3 +++ drivers/usb/chipidea/debug.c |4 ++-- 3 files changed, 6 insertions(+), 3 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 5/6] usb: phy: mxs: Add VF610 USB PHY support
On Fri, Jul 18, 2014 at 07:01:41PM +0200, Stefan Agner wrote:
This adds support for the USB PHY in Vybrid VF610. We assume that
the disconnection without VBUS is also needed for Vybrid. For all
other flags, the presumption of innocence applies.
Signed-off-by: Stefan Agner ste...@agner.ch
---
drivers/usb/phy/phy-mxs-usb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index c42bdf0..207946b 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -125,10 +125,15 @@ static const struct mxs_phy_data imx6sl_phy_data = {
MXS_PHY_NEED_IP_FIX,
};
+static const struct mxs_phy_data vf610_phy_data = {
+ .flags = MXS_PHY_DISCONNECT_LINE_WITHOUT_VBUS,
+};
+
static const struct of_device_id mxs_phy_dt_ids[] = {
{ .compatible = fsl,imx6sl-usbphy, .data = imx6sl_phy_data, },
{ .compatible = fsl,imx6q-usbphy, .data = imx6q_phy_data, },
{ .compatible = fsl,imx23-usbphy, .data = imx23_phy_data, },
+ { .compatible = fsl,vf610-usbphy, .data = vf610_phy_data, },
This new compatible string should be documented in
Documentation/devicetree/bindings/usb/mxs-phy.txt.
Shawn
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxs_phy_dt_ids);
--
2.0.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
[PATCH 3/3] usb: chipidea: debug: fix sparse non static symbol warnings
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fixes the following sparse warnings:
drivers/usb/chipidea/debug.c:211:5: warning:
symbol 'ci_otg_show' was not declared. Should it be static?
drivers/usb/chipidea/debug.c:334:5: warning:
symbol 'ci_registers_show' was not declared. Should it be static?
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/debug.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 7cccab6..795d653 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -208,7 +208,7 @@ static const struct file_operations ci_requests_fops = {
.release= single_release,
};
-int ci_otg_show(struct seq_file *s, void *unused)
+static int ci_otg_show(struct seq_file *s, void *unused)
{
struct ci_hdrc *ci = s-private;
struct otg_fsm *fsm;
@@ -331,7 +331,7 @@ static const struct file_operations ci_role_fops = {
.release= single_release,
};
-int ci_registers_show(struct seq_file *s, void *unused)
+static int ci_registers_show(struct seq_file *s, void *unused)
{
struct ci_hdrc *ci = s-private;
u32 tmp_reg;
--
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 1/3] usb: ci_hdrc_imx: Return -EINVAL for missing USB PHY
From: Markus Pargmann m...@pengutronix.de
-ENODEV is interpreted by the generic driver probing function as a
non-matching driver. This leads to a missing probe failure message.
Also a missing USB PHY is more of an invalid configuration of the usb
driver because it is necessary.
This patch returns -EINVAL if devm_usb_get_phy_by_phandle() returned -ENODEV.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/ci_hdrc_imx.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c
b/drivers/usb/chipidea/ci_hdrc_imx.c
index 2e58f8d..65444b0 100644
--- a/drivers/usb/chipidea/ci_hdrc_imx.c
+++ b/drivers/usb/chipidea/ci_hdrc_imx.c
@@ -133,6 +133,9 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
data-phy = devm_usb_get_phy_by_phandle(pdev-dev, fsl,usbphy, 0);
if (IS_ERR(data-phy)) {
ret = PTR_ERR(data-phy);
+ /* Return -EINVAL if no usbphy is available */
+ if (ret == -ENODEV)
+ ret = -EINVAL;
goto err_clk;
}
--
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 1/6] ARM: dts: vf610: add USB PHY and controller
On Fri, Jul 18, 2014 at 07:01:37PM +0200, Stefan Agner wrote:
This adds USB PHY and USB controller nodes. Vybrid SoCs have two
independent USB cores which each supports DR (dual role). However,
real OTG is not supported since the OTG ID pin is not available.
The PHYs are located within the anadig register range, hence we need
to change the length of the anadig registers.
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf610.dtsi | 46
+---
1 file changed, 43 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 6a6190c..f6c3f02 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -25,6 +25,8 @@
gpio2 = gpio3;
gpio3 = gpio4;
gpio4 = gpio5;
+ usbphy0 = usbphy0;
+ usbphy1 = usbphy1;
};
cpus {
@@ -285,9 +287,25 @@
gpio-ranges = iomuxc 0 128 7;
};
- anatop@4005 {
- compatible = fsl,vf610-anatop;
- reg = 0x4005 0x1000;
+ anatop: anatop@4005 {
+ compatible = fsl,vf610-anatop, syscon;
+ reg = 0x4005 0x400;
+ };
+
+ usbphy0: usbphy@40050800 {
+ compatible = fsl,vf610-usbphy,
fsl,imx23-usbphy;
Since phy driver will match fsl,vf610-usbphy anyway, we do not need
fsl,imx23-usbphy here.
+ reg = 0x40050800 0x400;
+ interrupts = 0 50 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_USBPHY0;
+ fsl,anatop = anatop;
+ };
+
+ usbphy1: usbphy@40050c00 {
+ compatible = fsl,vf610-usbphy,
fsl,imx23-usbphy;
+ reg = 0x40050c00 0x400;
+ interrupts = 0 51 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_USBPHY1;
+ fsl,anatop = anatop;
};
i2c0: i2c@40066000 {
@@ -309,6 +327,18 @@
reg = 0x4006b000 0x1000;
#clock-cells = 1;
};
+
+ usbdev0: usb@40034000 {
+ compatible = fsl,imx6q-usb, fsl,imx27-usb;
It doesn't really make any sense to have fsl,imx6q-usb here. The
following one should be less confusing.
compatible = fsl,vf610-usb, fsl,imx27-usb;
Shawn
+ reg = 0x40034000 0x800;
+ interrupts = 0 75 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_USBC0;
+ fsl,usbphy = usbphy0;
+ dr_mode = peripheral;
+ status = disabled;
+ };
+
+
};
aips1: aips-bus@4008 {
@@ -371,6 +401,16 @@
status = disabled;
};
+ usbh1: usb@400b4000 {
+ compatible = fsl,imx6q-usb, fsl,imx27-usb;
+ reg = 0x400b4000 0x800;
+ interrupts = 0 76 IRQ_TYPE_LEVEL_HIGH;
+ clocks = clks VF610_CLK_USBC1;
+ fsl,usbphy = usbphy1;
+ dr_mode = host;
+ status = disabled;
+ };
+
ftm: ftm@400b8000 {
compatible = fsl,ftm-timer;
reg = 0x400b8000 0x1000 0x400b9000 0x1000;
--
2.0.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 2/6] ARM: imx: clk-vf610: add USBPHY clocks
On Fri, Jul 18, 2014 at 07:01:38PM +0200, Stefan Agner wrote: This commit adds PLL7 which is required for USBPHY1. It also adds the USB PHY and USB Controller clocks and the gates to enable them. Signed-off-by: Stefan Agner ste...@agner.ch Jingchang, Does the patch look good to you? Shawn --- All the main PLLs are currently turned on by boot ROM or boot loader, within the kernel we only set the fixed factor. Altough, the function imx_clk_pllv3 would provide enabling and rate calculation support. Because PLL7 is _not_ enabled at boot up, we need enable support. With this, we make use of the imx_clk_pllv3 function the first time in clk-vf610. In order to be aligned, would it make sense to use the function for all the main PLLs? I think support for all types of PLL available in Vybrid is already there, altough this need to be verified first. arch/arm/mach-imx/clk-vf610.c | 12 ++-- include/dt-bindings/clock/vf610-clock.h | 5 - 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-imx/clk-vf610.c b/arch/arm/mach-imx/clk-vf610.c index 22dc3ee..159c5c4 100644 --- a/arch/arm/mach-imx/clk-vf610.c +++ b/arch/arm/mach-imx/clk-vf610.c @@ -58,6 +58,8 @@ #define PFD_PLL1_BASE(anatop_base + 0x2b0) #define PFD_PLL2_BASE(anatop_base + 0x100) #define PFD_PLL3_BASE(anatop_base + 0xf0) +#define PLL3_CTRL(anatop_base + 0x10) +#define PLL7_CTRL(anatop_base + 0x20) static void __iomem *anatop_base; static void __iomem *ccm_base; @@ -148,6 +150,9 @@ static void __init vf610_clocks_init(struct device_node *ccm_node) clk[VF610_CLK_PLL5_MAIN] = imx_clk_fixed_factor(pll5_main, fast_clk_sel, 125, 6); /* pll6: default 960Mhz */ clk[VF610_CLK_PLL6_MAIN] = imx_clk_fixed_factor(pll6_main, fast_clk_sel, 40, 1); + /* pll7: USB1 PLL at 480MHz */ + clk[VF610_CLK_PLL7_MAIN] = imx_clk_pllv3(IMX_PLLV3_USB, pll7_main, fast_clk_sel, PLL7_CTRL, 0x2); + clk[VF610_CLK_PLL1_PFD_SEL] = imx_clk_mux(pll1_pfd_sel, CCM_CCSR, 16, 3, pll1_sels, 5); clk[VF610_CLK_PLL2_PFD_SEL] = imx_clk_mux(pll2_pfd_sel, CCM_CCSR, 19, 3, pll2_sels, 5); clk[VF610_CLK_SYS_SEL] = imx_clk_mux(sys_sel, CCM_CCSR, 0, 3, sys_sels, ARRAY_SIZE(sys_sels)); @@ -160,8 +165,11 @@ static void __init vf610_clocks_init(struct device_node *ccm_node) clk[VF610_CLK_PLL4_MAIN_DIV] = clk_register_divider_table(NULL, pll4_main_div, pll4_main, 0, CCM_CACRR, 6, 3, 0, pll4_main_div_table, imx_ccm_lock); clk[VF610_CLK_PLL6_MAIN_DIV] = imx_clk_divider(pll6_main_div, pll6_main, CCM_CACRR, 21, 1); - clk[VF610_CLK_USBC0] = imx_clk_gate2(usbc0, pll3_main, CCM_CCGR1, CCM_CCGRx_CGn(4)); - clk[VF610_CLK_USBC1] = imx_clk_gate2(usbc1, pll3_main, CCM_CCGR7, CCM_CCGRx_CGn(4)); + clk[VF610_CLK_USBPHY0] = imx_clk_gate(usbphy0, pll3_main, PLL3_CTRL, 6); + clk[VF610_CLK_USBPHY1] = imx_clk_gate(usbphy1, pll7_main, PLL7_CTRL, 6); + + clk[VF610_CLK_USBC0] = imx_clk_gate2(usbc0, ipg_bus, CCM_CCGR1, CCM_CCGRx_CGn(4)); + clk[VF610_CLK_USBC1] = imx_clk_gate2(usbc1, ipg_bus, CCM_CCGR7, CCM_CCGRx_CGn(4)); clk[VF610_CLK_QSPI0_SEL] = imx_clk_mux(qspi0_sel, CCM_CSCMR1, 22, 2, qspi_sels, 4); clk[VF610_CLK_QSPI0_EN] = imx_clk_gate(qspi0_en, qspi0_sel, CCM_CSCDR3, 4); diff --git a/include/dt-bindings/clock/vf610-clock.h b/include/dt-bindings/clock/vf610-clock.h index a916029..6593757 100644 --- a/include/dt-bindings/clock/vf610-clock.h +++ b/include/dt-bindings/clock/vf610-clock.h @@ -164,6 +164,9 @@ #define VF610_CLK_DMAMUX1151 #define VF610_CLK_DMAMUX2152 #define VF610_CLK_DMAMUX3153 -#define VF610_CLK_END154 +#define VF610_CLK_PLL7_MAIN 154 +#define VF610_CLK_USBPHY0155 +#define VF610_CLK_USBPHY1156 +#define VF610_CLK_END157 #endif /* __DT_BINDINGS_CLOCK_VF610_H */ -- 2.0.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 4/6] chipidea: usbmisc_imx: Add USB support for VF610 SoCs
On Fri, Jul 18, 2014 at 07:01:40PM +0200, Stefan Agner wrote:
@@ -283,6 +307,10 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
.compatible = fsl,imx6q-usbmisc,
.data = imx6q_usbmisc_ops,
},
+ {
+ .compatible = fsl,vf610-usbmisc,
Update Documentation/devicetree/bindings/usb/usbmisc-imx.txt please.
Shawn
+ .data = vf610_usbmisc_ops,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
--
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-core: Quirk support for non-standard bInterval
On Mon, Jul 21, 2014 at 10:33:31PM -0400, James Michels wrote:
From: James P Michels III james.p.mich...@gmail.com
This patch adds usb quirks to improve support for devices
with non standard bInterval values. Quirks are added to support devices with
bInterval values expressed as microframes or frames. The quirks cause the
parse endpoint function to modify the reported bInterval to the standards
conforming value.
There is currently code in the endpoint parser that checks for bIntervals that
are outside
of the valid range (0-16 for USB 2+). In this case, the code assumes the
bInterval is being
reported in 1ms frames. However, the correction is only applied if the
original
bInterval
value is out of the 0-16 range.
With one of these quirks applied to the device, the bInterval will be
accurately adjusted
even when the misreported bInterval is in the 0-16 range.
Applies to 3.16-rc5
Signed-off-by: James P Michels III james.p.mich...@gmail.com
---
drivers/usb/core/config.c | 38 ++
drivers/usb/core/quirks.c | 4
include/linux/usb/quirks.h | 13 +
3 files changed, 55 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 1ab4df1..4f71708 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -228,6 +228,44 @@ static int usb_parse_endpoint(struct device *ddev, int
cfgno, int inum,
endpoint-desc.bInterval = n;
}
+ /* Adjust bInterval reported as frames for quirked devices */
+ if (to_usb_device(ddev)-quirks USB_QUIRK_INTERVAL_AS_FRAMES) {
+ endpoint-desc.bInterval = fls(d-bInterval * 8);
+ if (endpoint-desc.bInterval 16)
+ endpoint-desc.bInterval = 16;
+ dev_warn(ddev, bInterval adjusted from %d to %d\n,
+ d-bInterval,
+ endpoint-desc.bInterval);
+/* checkpatch warns about this message even though this
+ * format is used extensively in this file. I replaced it
+ * so the patch-bot wouldn't automatically reject the patch.
+ *
+ * dev_warn(ddev, config %d interface %d altsetting %d
All the tabs got eaten by your email client, making this patch
impossible to apply :(
Take a look at Documentation/email_clients.txt for how to fix this up.
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: [PATCH] USB: core: hcd-pci: free IRQ before disabling PCI device when shutting down
On Mon, Jul 21, 2014 at 10:17:44AM +0800, Jiang Liu wrote:
The assigned IRQ should be freed before calling pci_disable_device()
when shutting down system, otherwise it will cause following warning.
[ 568.879482] [ cut here ]
[ 568.884236] WARNING: CPU: 1 PID: 3300 at
/home/konrad/ssd/konrad/xtt-i386/bootstrap/linux-usb/fs/proc/generic.c:521
remove_proc_entry+0x165/0x170()
[ 568.897846] remove_proc_entry: removing non-empty directory 'irq/16',
leaking at least 'ohci_hcd:usb4'
[ 568.907430] Modules linked in: dm_multipath dm_mod iscsi_boot_sysfs
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c_generic
sg sd_mod crct10dif_generic crc_t10dif crct10dif_common radeon fbcon tileblit
ttm font bitblit softcursor ata_generic ahci libahci drm_kms_helper skge
r8169 libata mii scsi_mod wmi acpi_cpufreq
[ 568.938539] CPU: 1 PID: 3300 Comm: init Tainted: GW
3.16.0-rc5upstream-01651-g03b9189 #1
[ 568.947946] Hardware name: ECS A780GM-A Ultra/A780GM-A Ultra, BIOS 080015
04/01/2010
[ 568.956008] 0209 ed0f1cd0 c1617946 c175403c ed0f1d00 c1090c3f
c1754084 ed0f1d2c
[ 568.964068] 0ce4 c175403c 0209 c11f22a5 c11f22a5 f755e8c0
ed0f1d78 f755e90d
[ 568.972128] ed0f1d18 c1090cde 0009 ed0f1d10 c1754084 ed0f1d2c
ed0f1d60 c11f22a5
[ 568.980194] Call Trace:
[ 568.982715] [c1617946] dump_stack+0x48/0x60
[ 568.987294] [c1090c3f] warn_slowpath_common+0x7f/0xa0
[ 569.003887] [c1090cde] warn_slowpath_fmt+0x2e/0x30
[ 569.009092] [c11f22a5] remove_proc_entry+0x165/0x170
[ 569.014476] [c10da6ca] unregister_irq_proc+0xaa/0xc0
[ 569.019858] [c10d582f] free_desc+0x1f/0x60
[ 569.024346] [c10d58aa] irq_free_descs+0x3a/0x80
[ 569.029283] [c10d9e9d] irq_dispose_mapping+0x2d/0x50
[ 569.034666] [c1078fd3] mp_unmap_irq+0x73/0xa0
[ 569.039423] [c107196b] acpi_unregister_gsi_ioapic+0x2b/0x40
[ 569.045431] [c107180f] acpi_unregister_gsi+0xf/0x20
[ 569.050725] [c1339cad] acpi_pci_irq_disable+0x4b/0x50
[ 569.056196] [c14daa38] pcibios_disable_device+0x18/0x20
[ 569.061848] [c130123d] do_pci_disable_device+0x4d/0x60
[ 569.067410] [c13012b7] pci_disable_device+0x47/0xb0
[ 569.077814] [c14800b1] usb_hcd_pci_shutdown+0x31/0x40
[ 569.083285] [c1304b19] pci_device_shutdown+0x19/0x50
[ 569.088667] [c13fda64] device_shutdown+0x14/0x120
[ 569.093777] [c10ac29d] kernel_restart_prepare+0x2d/0x30
[ 569.099429] [c10ac41e] kernel_restart+0xe/0x60
[ 569.109028] [c10ac611] SYSC_reboot+0x191/0x220
[ 569.159269] [c10ac6ba] SyS_reboot+0x1a/0x20
[ 569.163843] [c161c718] sysenter_do_call+0x12/0x16
[ 569.168951] ---[ end trace ccc1ec4471c289c9 ]---
Tested-by: Aaron Lu aaron...@intel.com
Signed-off-by: Jiang Liu jiang@linux.intel.com
Reviewed-by: Huang Rui ray.hu...@amd.com
---
Hi Greg,
This issue was triggered when testing patch set use irqdomain
to dynamically allocate IRQ for IOAPIC, please refer to
https://lkml.org/lkml/2014/6/9/44 for more information.
Regards!
Gerry
---
drivers/usb/core/hcd-pci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/hcd-pci.c b/drivers/usb/core/hcd-pci.c
index 82044b5d6113..efc953119ce2 100644
--- a/drivers/usb/core/hcd-pci.c
+++ b/drivers/usb/core/hcd-pci.c
@@ -380,6 +380,8 @@ void usb_hcd_pci_shutdown(struct pci_dev *dev)
if (test_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags)
hcd-driver-shutdown) {
hcd-driver-shutdown(hcd);
+ if (usb_hcd_is_primary_hcd(hcd) hcd-irq 0)
+ free_irq(hcd-irq, hcd);
pci_disable_device(dev);
}
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
