Re: [PATCH v2] xhci: fix usb3 streams
Hi Sarah,
On 10/15/2013 03:54 AM, Gerd Hoffmann wrote:
Gerd, Hans, any objections to this updated patch? The warning is fixed
with it.
No objections, looks good to me.
The patch probably still needs to address the case where the ring
expansion fails because we can't insert the new segments into the radix
tree. The patch should probably allocate the segments, attempt to add
them to the radix tree, and fail without modifying the link TRBs of the
ring. I'd have to look more deeply into the code to see what exactly
should be done there.
I would like that issue fixed before I merge these patches, so if you
want to take a stab at fixing it, please do.
Sarah Sharp
Regards,
Hans
88
xhci maintains a radix tree for each stream endpoint because it must
be able to map a trb address to the stream ring. Each ring segment
must be added to the ring for this to work. Currently xhci sticks
only the first segment of each stream ring into the radix tree.
Result is that things work initially, but as soon as the first segment
is full xhci can't map the trb address from the completion event to the
stream ring any more - BOOM. You'll find this message in the logs:
ERROR Transfer event for disabled endpoint or incorrect stream ring
This patch adds a helper function to update the radix tree, and a
function to remove ring segments from the tree. Both functions loop
over the segment list and handles all segments instead of just the
first.
[Note: Sarah changed this patch to add radix_tree_maybe_preload() and
radix_tree_preload_end() calls around the radix tree insert, since we
can now insert entries in interrupt context. There are now two helper
functions to make the code cleaner, and those functions are moved to
make them static.]
Signed-off-by: Gerd Hoffmann kra...@redhat.com
Signed-off-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-mem.c | 132 +---
drivers/usb/host/xhci.h | 1 +
2 files changed, 90 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 83bcd13..8b1ba5b 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -149,14 +149,95 @@ static void xhci_link_rings(struct xhci_hcd *xhci, struct
xhci_ring *ring,
}
}
+/*
+ * We need a radix tree for mapping physical addresses of TRBs to which stream
+ * ID they belong to. We need to do this because the host controller won't
tell
+ * us which stream ring the TRB came from. We could store the stream ID in an
+ * event data TRB, but that doesn't help us for the cancellation case, since
the
+ * endpoint may stop before it reaches that event data TRB.
+ *
+ * The radix tree maps the upper portion of the TRB DMA address to a ring
+ * segment that has the same upper portion of DMA addresses. For example, say
I
+ * have segments of size 1KB, that are always 64-byte aligned. A segment may
+ * start at 0x10c91000 and end at 0x10c913f0. If I use the upper 10 bits, the
+ * key to the stream ID is 0x43244. I can use the DMA address of the TRB to
+ * pass the radix tree a key to get the right stream ID:
+ *
+ * 0x10c90fff 10 = 0x43243
+ * 0x10c912c0 10 = 0x43244
+ * 0x10c91400 10 = 0x43245
+ *
+ * Obviously, only those TRBs with DMA addresses that are within the segment
+ * will make the radix tree return the stream ID for that ring.
+ *
+ * Caveats for the radix tree:
+ *
+ * The radix tree uses an unsigned long as a key pair. On 32-bit systems, an
+ * unsigned long will be 32-bits; on a 64-bit system an unsigned long will be
+ * 64-bits. Since we only request 32-bit DMA addresses, we can use that as the
+ * key on 32-bit or 64-bit systems (it would also be fine if we asked for
64-bit
+ * PCI DMA addresses on a 64-bit system). There might be a problem on 32-bit
+ * extended systems (where the DMA address can be bigger than 32-bits),
+ * if we allow the PCI dma mask to be bigger than 32-bits. So don't do that.
+ */
+static int xhci_update_stream_mapping(struct xhci_ring *ring, gfp_t mem_flags)
+{
+ struct xhci_segment *seg;
+ unsigned long key;
+ int ret;
+
+ if (WARN_ON_ONCE(ring-trb_address_map == NULL))
+ return 0;
+
+ seg = ring-first_seg;
+ do {
+ key = (unsigned long)(seg-dma TRB_SEGMENT_SHIFT);
+ /* Skip any segments that were already added. */
+ if (radix_tree_lookup(ring-trb_address_map, key))
+ continue;
+
+ ret = radix_tree_maybe_preload(mem_flags);
+ if (ret)
+ return ret;
+ ret = radix_tree_insert(ring-trb_address_map,
+ key, ring);
+ radix_tree_preload_end();
+ if (ret)
+ return ret;
+
[PATCH v2 1/2] usb/gadget: storage_common: use strtobool instead of kstrtouint
strtobool is more flexible for the user and is more appropriate in the
context.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/storage_common.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/gadget/storage_common.c
b/drivers/usb/gadget/storage_common.c
index c7b78a1..8bd5f2d 100644
--- a/drivers/usb/gadget/storage_common.c
+++ b/drivers/usb/gadget/storage_common.c
@@ -375,9 +375,9 @@ ssize_t fsg_store_ro(struct fsg_lun *curlun, struct
rw_semaphore *filesem,
const char *buf, size_t count)
{
ssize_t rc;
- unsignedro;
+ boolro;
- rc = kstrtouint(buf, 2, ro);
+ rc = strtobool(buf, ro);
if (rc)
return rc;
@@ -402,10 +402,10 @@ EXPORT_SYMBOL(fsg_store_ro);
ssize_t fsg_store_nofua(struct fsg_lun *curlun, const char *buf, size_t count)
{
- unsignednofua;
+ boolnofua;
int ret;
- ret = kstrtouint(buf, 2, nofua);
+ ret = strtobool(buf, nofua);
if (ret)
return ret;
@@ -452,10 +452,10 @@ EXPORT_SYMBOL(fsg_store_file);
ssize_t fsg_store_cdrom(struct fsg_lun *curlun, const char *buf, size_t count)
{
- unsignedcdrom;
+ boolcdrom;
int ret;
- ret = kstrtouint(buf, 2, cdrom);
+ ret = strtobool(buf, cdrom);
if (ret)
return ret;
@@ -468,10 +468,10 @@ EXPORT_SYMBOL(fsg_store_cdrom);
ssize_t fsg_store_removable(struct fsg_lun *curlun, const char *buf,
size_t count)
{
- unsignedremovable;
+ boolremovable;
int ret;
- ret = kstrtouint(buf, 2, removable);
+ ret = strtobool(buf, removable);
if (ret)
return ret;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Fixes for mass_storage
A short series to fix 2 issues: - use strtobool instead of kstrtouint with base 2 for: ro, nofua, cdrom, removable attrs (better fits the context and more flexible to users) - setting a lun to be cdrom implies read-only and succeeds only if the lun is not open v1..v2: - fixes after Michal's review; thanks Michal! - added a comment for a function requiring a semaphore - simplified error recovery paths in fsg_store_ro() and fsg_store_cdrom() Andrzej Pietrasiewicz (2): usb/gadget: storage_common: use strtobool instead of kstrtouint usb/gadget: storage_common: pass filesem to fsg_store_cdrom drivers/usb/gadget/f_mass_storage.c |7 +++- drivers/usb/gadget/storage_common.c | 58 +++--- drivers/usb/gadget/storage_common.h |3 +- 3 files changed, 47 insertions(+), 21 deletions(-) -- 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 2/2] usb/gadget: storage_common: pass filesem to fsg_store_cdrom
If cdrom flag is set ro flag is implied. Try setting the ro first, and
only if it succeeds set the cdrom flag.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
drivers/usb/gadget/f_mass_storage.c |7 +-
drivers/usb/gadget/storage_common.c | 42 +-
drivers/usb/gadget/storage_common.h |3 +-
3 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 6e5a6da..6b5f451 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3281,7 +3281,12 @@ static ssize_t fsg_lun_opts_cdrom_show(struct
fsg_lun_opts *opts, char *page)
static ssize_t fsg_lun_opts_cdrom_store(struct fsg_lun_opts *opts,
const char *page, size_t len)
{
- return fsg_store_cdrom(opts-lun, page, len);
+ struct fsg_opts *fsg_opts;
+
+ fsg_opts = to_fsg_opts(opts-group.cg_item.ci_parent);
+
+ return fsg_store_cdrom(opts-lun, fsg_opts-common-filesem, page,
+ len);
}
static struct fsg_lun_opts_attribute fsg_lun_opts_cdrom =
diff --git a/drivers/usb/gadget/storage_common.c
b/drivers/usb/gadget/storage_common.c
index 8bd5f2d..ec20a1f 100644
--- a/drivers/usb/gadget/storage_common.c
+++ b/drivers/usb/gadget/storage_common.c
@@ -371,6 +371,23 @@ ssize_t fsg_show_removable(struct fsg_lun *curlun, char
*buf)
}
EXPORT_SYMBOL(fsg_show_removable);
+/*
+ * The caller must hold fsg-filesem for reading when calling this function.
+ */
+static ssize_t _fsg_store_ro(struct fsg_lun *curlun, bool ro)
+{
+ if (fsg_lun_is_open(curlun)) {
+ LDBG(curlun, read-only status change prevented\n);
+ return -EBUSY;
+ }
+
+ curlun-ro = ro;
+ curlun-initially_ro = ro;
+ LDBG(curlun, read-only status set to %d\n, curlun-ro);
+
+ return 0;
+}
+
ssize_t fsg_store_ro(struct fsg_lun *curlun, struct rw_semaphore *filesem,
const char *buf, size_t count)
{
@@ -386,16 +403,11 @@ ssize_t fsg_store_ro(struct fsg_lun *curlun, struct
rw_semaphore *filesem,
* backing file is closed.
*/
down_read(filesem);
- if (fsg_lun_is_open(curlun)) {
- LDBG(curlun, read-only status change prevented\n);
- rc = -EBUSY;
- } else {
- curlun-ro = ro;
- curlun-initially_ro = ro;
- LDBG(curlun, read-only status set to %d\n, curlun-ro);
+ rc = _fsg_store_ro(curlun, ro);
+ if (!rc)
rc = count;
- }
up_read(filesem);
+
return rc;
}
EXPORT_SYMBOL(fsg_store_ro);
@@ -450,7 +462,8 @@ ssize_t fsg_store_file(struct fsg_lun *curlun, struct
rw_semaphore *filesem,
}
EXPORT_SYMBOL(fsg_store_file);
-ssize_t fsg_store_cdrom(struct fsg_lun *curlun, const char *buf, size_t count)
+ssize_t fsg_store_cdrom(struct fsg_lun *curlun, struct rw_semaphore *filesem,
+ const char *buf, size_t count)
{
boolcdrom;
int ret;
@@ -459,9 +472,16 @@ ssize_t fsg_store_cdrom(struct fsg_lun *curlun, const char
*buf, size_t count)
if (ret)
return ret;
- curlun-cdrom = cdrom;
+ down_read(filesem);
+ ret = cdrom ? _fsg_store_ro(curlun, true) : 0;
- return count;
+ if (!ret) {
+ curlun-cdrom = cdrom;
+ ret = count;
+ }
+ up_read(filesem);
+
+ return ret;
}
EXPORT_SYMBOL(fsg_store_cdrom);
diff --git a/drivers/usb/gadget/storage_common.h
b/drivers/usb/gadget/storage_common.h
index e0f7aa6..c74c2fd 100644
--- a/drivers/usb/gadget/storage_common.h
+++ b/drivers/usb/gadget/storage_common.h
@@ -221,7 +221,8 @@ ssize_t fsg_store_ro(struct fsg_lun *curlun, struct
rw_semaphore *filesem,
ssize_t fsg_store_nofua(struct fsg_lun *curlun, const char *buf, size_t count);
ssize_t fsg_store_file(struct fsg_lun *curlun, struct rw_semaphore *filesem,
const char *buf, size_t count);
-ssize_t fsg_store_cdrom(struct fsg_lun *curlun, const char *buf, size_t count);
+ssize_t fsg_store_cdrom(struct fsg_lun *curlun, struct rw_semaphore *filesem,
+ const char *buf, size_t count);
ssize_t fsg_store_removable(struct fsg_lun *curlun, const char *buf,
size_t count);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Fixes for mass_storage
W dniu 15.10.2013 00:48, Felipe Balbi pisze: Hi, On Mon, Oct 14, 2013 at 11:21:45AM +0200, Andrzej Pietrasiewicz wrote: A short series to fix 2 issues: - use strtobool instead of kstrtouint with base 2 for: ro, nofua, cdrom, removable attrs (better fits the context and more flexible to users) - setting a lun to be cdrom implies read-only and succeeds only if the lun is not open Andrzej Pietrasiewicz (2): usb/gadget: storage_common: use strtobool instead of kstrtouint usb/gadget: storage_common: pass filesem to fsg_store_cdrom it's getting quite late for this merge window. I'll wait until tomorrow for a v2, planning to send a pull request this friday at the latest. Done. Thanks, AP -- 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 0/2] Adapt phy-omap-usb2 for AM437x platform
This series adapts the phy-omap-usb2 generic phy driver for AM437x. While at that arrange the include files alphabetically (PATCH 1) V2 of 2nd Patch which fixes the following from v1 - List comaptible entries in Documentaion - Add usb_phy_data instead of checking compatible each time. George Cherian (2): phy: omap-usb2: Arrange the include in alphabetical order phy: omap-usb2: Adapt phy-omap-usb2 for AM437x Documentation/devicetree/bindings/usb/usb-phy.txt | 4 +- drivers/phy/phy-omap-usb2.c | 72 +++ include/linux/usb/omap_usb.h | 10 3 files changed, 62 insertions(+), 24 deletions(-) -- 1.8.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/1] ARM: dts: omap3: Adapt USB OTG to generic PHY framework
Hi Roger, On 14/10/2013 11:20, Roger Quadros wrote: Hi Benoit, On 10/10/2013 06:34 PM, Felipe Balbi wrote: On Mon, Oct 07, 2013 at 04:28:13PM +0300, Roger Quadros wrote: The generic PHY framewrok expects different properties than the old USB PHY framework. Supply those properties. Fixes USB OTG port on GAT04 and N900 after the Generic PHY framework was merged in greg/usb-next. [1] [1] - https://lkml.org/lkml/2013/9/27/581 Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Felipe Balbi ba...@ti.com Could you please pick this one for 3.13? Thanks. I don't see it in your 3.13 take 2 pull request. It was not in it. I've just applied it. Thanks Benoit -- Benoît Cousson BayLibre Embedded Linux Technology Lab www.baylibre.com -- 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 1/2] phy: omap-usb2: Arrange the include in alphabetical order
This patch arranges the includes in alphabetical order Signed-off-by: George Cherian george.cher...@ti.com --- drivers/phy/phy-omap-usb2.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index bfc5c33..3e5f08c 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -16,20 +16,20 @@ * */ +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h #include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/phy/phy.h #include linux/platform_device.h +#include linux/pm_runtime.h #include linux/slab.h -#include linux/of.h -#include linux/io.h #include linux/usb/omap_usb.h -#include linux/usb/phy_companion.h -#include linux/clk.h -#include linux/err.h -#include linux/pm_runtime.h -#include linux/delay.h #include linux/usb/omap_control_usb.h -#include linux/phy/phy.h -#include linux/of_platform.h +#include linux/usb/phy_companion.h /** * omap_usb2_set_comparator - links the comparator present in the sytem with -- 1.8.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 v2 2/2] phy: omap-usb2: Adapt phy-omap-usb2 for AM437x
This patch adds a compatible for AM437x ti,am43xx-usb2 to
reuse the same phy-omap-usb2 driver.
Also updated the documentation to add the new compatible.
Signed-off-by: George Cherian george.cher...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 4 +-
drivers/phy/phy-omap-usb2.c | 54 +--
include/linux/usb/omap_usb.h | 10 +
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index c0245c8..309ab27 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -3,7 +3,9 @@ USB PHY
OMAP USB2 PHY
Required properties:
- - compatible: Should be ti,omap-usb2
+ - compatible: Should be either of
+ * ti,omap-usb2 for OMAP4,OMAP5,DRA7
+ * ti,am437x-usb2 for AM437x
- reg : Address and length of the register set for the device.
- #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 3e5f08c..7c0bc6c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -144,6 +144,35 @@ static struct phy_ops ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct usb_phy_data omap_usb2_data = {
+ .label = omap_usb2,
+ .set_host = omap_usb_set_host,
+ .set_peripheral = omap_usb_set_peripheral,
+ .set_vbus = omap_usb_set_vbus,
+ .start_srp = omap_usb_start_srp,
+};
+
+static const struct usb_phy_data am437x_usb2_data = {
+ .label = am437x_usb2,
+ .set_host = omap_usb_set_host,
+ .set_peripheral = omap_usb_set_peripheral,
+};
+
+static const struct of_device_id omap_usb2_id_table[] = {
+ {
+ .compatible = ti,omap-usb2,
+ .data = omap_usb2_data,
+ },
+ {
+ .compatible = ti,am437x-usb2,
+ .data = am437x_usb2_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#endif
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
@@ -153,9 +182,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
struct device_node *node = pdev-dev.of_node;
struct device_node *control_node;
struct platform_device *control_pdev;
+ const struct of_device_id *of_id;
+ struct usb_phy_data *phy_data;
+
+ of_id = of_match_device(of_match_ptr(omap_usb2_id_table), pdev-dev);
- if (!node)
+ if (!of_id)
return -EINVAL;
+ phy_data = (struct usb_phy_data *)of_id-data;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -172,7 +206,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-dev= pdev-dev;
phy-phy.dev= phy-dev;
- phy-phy.label = omap-usb2;
+ phy-phy.label = phy_data-label;
phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
@@ -199,10 +233,10 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
- otg-set_host = omap_usb_set_host;
- otg-set_peripheral = omap_usb_set_peripheral;
- otg-set_vbus = omap_usb_set_vbus;
- otg-start_srp = omap_usb_start_srp;
+ otg-set_host = phy_data-set_host;
+ otg-set_peripheral = phy_data-set_peripheral;
+ otg-set_vbus = phy_data-set_vbus;
+ otg-start_srp = phy_data-start_srp;
otg-phy= phy-phy;
platform_set_drvdata(pdev, phy);
@@ -297,14 +331,6 @@ static const struct dev_pm_ops omap_usb2_pm_ops = {
#define DEV_PM_OPS NULL
#endif
-#ifdef CONFIG_OF
-static const struct of_device_id omap_usb2_id_table[] = {
- { .compatible = ti,omap-usb2 },
- {}
-};
-MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
-#endif
-
static struct platform_driver omap_usb2_driver = {
.probe = omap_usb2_probe,
.remove = omap_usb2_remove,
diff --git a/include/linux/usb/omap_usb.h b/include/linux/usb/omap_usb.h
index 6ae2936..0c6b71c 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/usb/omap_usb.h
@@ -42,6 +42,16 @@ struct omap_usb {
u8 is_suspended:1;
};
+struct usb_phy_data {
+ const char *label;
+ int (*set_host)(struct usb_otg *otg, struct usb_bus *host);
+ int (*set_peripheral)(struct usb_otg *otg,
+ struct usb_gadget *gadget);
+ int (*set_vbus)(struct usb_otg *otg, bool enabled);
+ int (*start_srp)(struct usb_otg
Re: [PATCH v3 01/13] usb: phy: msm: Move mach depndend code to platform data
On Mon, 2013-10-14 at 17:52 -0500, Felipe Balbi wrote:
Hi,
On Mon, Oct 14, 2013 at 06:24:28PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
This patch fix compilation error and is an intermediate step
before the addition of DeviceTree support for newer targets.
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
arch/arm/mach-msm/board-msm7x30.c | 35
+++
arch/arm/mach-msm/board-qsd8x50.c | 35
+++
drivers/usb/phy/phy-msm-usb.c | 34 ++
include/linux/usb/msm_hsusb.h |3 +++
4 files changed, 87 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-msm/board-msm7x30.c
b/arch/arm/mach-msm/board-msm7x30.c
index f9af5a4..46de789 100644
--- a/arch/arm/mach-msm/board-msm7x30.c
+++ b/arch/arm/mach-msm/board-msm7x30.c
@@ -30,6 +30,7 @@
#include asm/memory.h
#include asm/setup.h
+#include mach/clk.h
#include mach/msm_iomap.h
#include mach/dma.h
@@ -60,10 +61,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err(usb hs_clk assert failed\n);
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err(usb hs_clk deassert failed\n);
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err(usb phy clk assert failed\n);
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err(usb phy clk deassert failed\n);
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .link_clk_reset = hsusb_link_clk_reset,
+ .phy_clk_reset = hsusb_phy_clk_reset,
};
struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
diff --git a/arch/arm/mach-msm/board-qsd8x50.c
b/arch/arm/mach-msm/board-qsd8x50.c
index 5f933bc..9169ec3 100644
--- a/arch/arm/mach-msm/board-qsd8x50.c
+++ b/arch/arm/mach-msm/board-qsd8x50.c
@@ -31,6 +31,7 @@
#include mach/irqs.h
#include mach/sirc.h
#include mach/vreg.h
+#include mach/clk.h
#include linux/platform_data/mmc-msm_sdcc.h
#include devices.h
@@ -81,10 +82,44 @@ static int hsusb_phy_init_seq[] = {
-1
};
+static int hsusb_link_clk_reset(struct clk *link_clk, bool assert)
+{
+ int ret;
+
+ if (assert) {
+ ret = clk_reset(link_clk, CLK_RESET_ASSERT);
+ if (ret)
+ pr_err(usb hs_clk assert failed\n);
+ } else {
+ ret = clk_reset(link_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err(usb hs_clk deassert failed\n);
+ }
+ return ret;
+}
+
+static int hsusb_phy_clk_reset(struct clk *phy_clk)
+{
+ int ret;
+
+ ret = clk_reset(phy_clk, CLK_RESET_ASSERT);
+ if (ret) {
+ pr_err(usb phy clk assert failed\n);
+ return ret;
+ }
+ usleep_range(1, 12000);
+ ret = clk_reset(phy_clk, CLK_RESET_DEASSERT);
+ if (ret)
+ pr_err(usb phy clk deassert failed\n);
+ return ret;
+}
+
static struct msm_otg_platform_data msm_otg_pdata = {
.phy_init_seq = hsusb_phy_init_seq,
.mode = USB_PERIPHERAL,
.otg_control= OTG_PHY_CONTROL,
+ .link_clk_reset = hsusb_link_clk_reset,
+ .phy_clk_reset = hsusb_phy_clk_reset,
};
static struct platform_device *devices[] __initdata = {
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index e9d4cd9..118798d 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -40,8 +40,6 @@
#include linux/usb/msm_hsusb_hw.h
#include linux/regulator/consumer.h
-#include mach/clk.h
-
#define MSM_USB_BASE (motg-regs)
#define DRIVER_NAMEmsm_otg
@@ -308,33 +306,29 @@ static void ulpi_init(struct msm_otg *motg)
static int msm_otg_link_clk_reset(struct msm_otg *motg, bool assert)
{
- int ret;
+ int ret = 0;
+
+ if (!motg-pdata-link_clk_reset)
+ return ret;
+
+ ret = motg-pdata-link_clk_reset(motg-clk, assert);
+ if (ret)
+
Re: [PATCH] usb: phy: omap: Add omap-control Support for AM437x
On 10/14/2013 6:49 PM, Roger Quadros wrote:
Hi George,
On 10/14/2013 03:51 PM, George Cherian wrote:
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian george.cher...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 2 ++
drivers/usb/phy/phy-omap-control.c | 17 +
include/linux/usb/omap_control_usb.h | 6 ++
3 files changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 090e5e2..c495135 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -87,6 +87,8 @@ Required properties:
e.g. USB3 PHY and SATA PHY on OMAP5.
ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
DRA7 platform.
+ ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on
+ AM437 platform.
- reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
for other types.
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 09c5ace..c453b81 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -84,6 +84,18 @@ void omap_control_usb_phy_power(struct device *dev, int on)
else
val |= OMAP_CTRL_USB2_PHY_PD;
break;
+
+ case OMAP_CTRL_TYPE_AM437USB2:
+ if (on) {
+ val = ~(AM437X_CTRL_USB2_PHY_PD |
+ AM437X_CTRL_USB2_OTG_PD);
+ val |= (AM437X_CTRL_USB2_OTGVDET_EN |
+ AM437X_CTRL_USB2_OTGSESSEND_EN);
The ON and OFF operations are not symmetric because of this. Shouldn't the
OTG specific stuff go in otg specific ops?
AM437X_CTRL_USB2_OTGVDET_EN - this is basically the VBUS detect comparator.
AM437X_CTRL_USB2_OTGSESSEND_EN - this is Session End Comparator.
The TRM names these bits with OTG. Without these enabled the peripheral mode
does not
work properly with HW UTMI mode (UTMI mode in DWC).
These bits have no effect when AM437X_CTRL_USB2_OTG_PD and
AM437X_CTRL_USB2_PHY_PD are enabled
(powered down).
Anyways I will make it symmetric during OFF also .
+ } else {
+ val |= (AM437X_CTRL_USB2_PHY_PD |
+AM437X_CTRL_USB2_OTG_PD);
+ }
+ break;
default:
dev_err(dev, %s: type %d not recognized\n,
__func__, control_usb-type);
@@ -197,6 +209,7 @@ static const enum omap_control_usb_type otghs_data =
OMAP_CTRL_TYPE_OTGHS;
static const enum omap_control_usb_type usb2_data = OMAP_CTRL_TYPE_USB2;
static const enum omap_control_usb_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
static const enum omap_control_usb_type dra7usb2_data =
OMAP_CTRL_TYPE_DRA7USB2;
+static const enum omap_control_usb_type am437usb2_data =
OMAP_CTRL_TYPE_AM437USB2;
static const struct of_device_id omap_control_usb_id_table[] = {
{
@@ -215,6 +228,10 @@ static const struct of_device_id
omap_control_usb_id_table[] = {
.compatible = ti,control-phy-dra7usb2,
.data = dra7usb2_data,
},
+ {
+ .compatible = ti,control-phy-am437usb2,
+ .data = am437usb2_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 596b019..69ae383 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -24,6 +24,7 @@ enum omap_control_usb_type {
OMAP_CTRL_TYPE_USB2,/* USB2_PHY, power down in CONTROL_DEV_CONF */
OMAP_CTRL_TYPE_PIPE3, /* PIPE3 PHY, DPLL seperate Rx/Tx power */
OMAP_CTRL_TYPE_DRA7USB2, /* USB2 PHY, power and power_aux e.g. DRA7 */
+ OMAP_CTRL_TYPE_AM437USB2, /* USB2 PHY, power e.g. AM437x */
};
struct omap_control_usb {
@@ -64,6 +65,11 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
+#define AM437X_CTRL_USB2_PHY_PD BIT(0)
+#define AM437X_CTRL_USB2_OTG_PDBIT(1)
+#define AM437X_CTRL_USB2_OTGVDET_ENBIT(19)
+#define AM437X_CTRL_USB2_OTGSESSEND_EN BIT(20)
+
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
cheers,
-roger
--
-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
Re: [PATCH v3 12/13] usb: phy: msm: Properly check core interrupt number
On Mon, 2013-10-14 at 17:59 -0500, Felipe Balbi wrote:
On Mon, Oct 14, 2013 at 06:24:39PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
IRQ with number 0 is valid case, so check for negative
not entirelly correct... IRQ 0 isn't supposed to be used as a linux IRQ
number IIRC.
I am not really sure. NO_IRQ is -1 at least on ARM. Also when
taking into account irqdomain's zero as interrupt number is valid??
numbers instead.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
---
drivers/usb/phy/phy-msm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index ca2abe6..f34c8a9 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1415,7 +1415,7 @@ static int __init msm_otg_probe(struct
platform_device *pdev)
dev_info(pdev-dev, OTG regs = %p\n, motg-regs);
motg-irq = platform_get_irq(pdev, 0);
- if (!motg-irq) {
+ if (motg-irq 0) {
this check is correct though, since platform_get_irq() will return
-ENXIO if it doesn't find IRQ resource.
Thanks,
Ivan
--
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-storage: scsiglue: Changing the command result
On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve vannapu...@nvidia.com wrote: Hi, There was a recent commit in mainline for the scsi devices which do not respond properly to medium access command: commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8 [SCSI] Handle disk devices which can not process medium access commands We have experienced several devices which fail in a fashion we do not currently handle gracefully in SCSI. After a failure these devices will respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.) but any command accessing the storage medium will time out. I came across a USB drive which showed similar problem and what I see is usb storage is still not able to cope with such devices properly. The control flow downwards is like: scsi_times_out -- Setting cmd-result as DID_TIME_OUT scsi_error_handler scsi_unjam_host scsi_eh_abort_cmds command_abort(sets US_FLIDX_TIMED_OUT for us-dflags calls stop_transport, and waits for)usb_stor_control_thread (which is waiting for transport call to return inside usb_stor_invoke_transport) both usb_stor_control_thread and usb_stor_invoke_transport check for us-dflags timed_out bit and set the result as DID_ABORT and signal completion for command_abort to complete .. sd_eh_action checks for cmd-result and finds out that it's DID_ABORT rather than DID_TIME_OUT. This patch updates the command result to be TIME_OUT explicitly before returning from command_abort in scsiglue.c. I would like to know if this patch can work out for such USB Storage devices? What would be the better way to do the same? Looks your diagnose is correct, and patch should be doable, the only side effect is that previous returned DID_ABORT in srb-result is replaced with DID_TIME_OUT now. Another way is to implement .eh_timed_out callback to return different error for the two failure, but looks not a big deal. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] usb: musb: dsps, OTG detection
On Mon, Oct 14, 2013 at 03:43:35PM -0500, Bin Liu wrote:
On Mon, Oct 14, 2013 at 10:22 AM, Markus Pargmann m...@pengutronix.de wrote:
Hi,
On Mon, Oct 14, 2013 at 08:54:09AM -0500, Bin Liu wrote:
On Mon, Oct 14, 2013 at 8:35 AM, Markus Pargmann m...@pengutronix.de
wrote:
The USB Controller does not support ID pin change interrupts. So we have
to use a polling function to detect changes of A/B device state
(otg_timer). This poll function has to check in several states if a
other device type might be connected to the USB port. This check is
triggered by manually starting/stopping a USB Session.
I think this is an arguable approach. Toggling the SESSION in
otg_timer() causes voltage pulses on VBUS, which will not pass the USB
certification.
This is only done when no device is connected, so I am not sure if it is
important. Unfortunately we do not see the A/B state changes until
That is right, and I don't think it hurts. The only problem is that
the USB certification test sees the VBUS pulses and fails.
toggling the SESSION. Is there another way to check this?
Unfortunately, toggling SESSION in b_idle is the only way I am aware of.
I have not seen any products required the dynamic dual role switching
yet. It always fixed in either device mode or host mode.
OTG is explicitly listed in the devicetree bindings documentation, so
I think the driver should be able to detect different roles.
Yes, MUSB supports OTG. But I have not seen anyone use OTG yet, and I
not sure if it is a good idea to add the OTG support, but fail the usb
certification test.
For example beaglebone does not overwrite the dr_mode = otg; property
of am33xx.dtsi and it is a device where OTG could be useful. You may
want to connect beaglebone to a PC or a keyboard while the other usb
port has a USB storage device attached. With the current implementation
this is only possible if the host or device is connected when the driver
is probing.
I could limit the SESSION toggling to OTG mode. If someone needs a
system that passes the USB certification test, he could simply set the
correct dr_mode in the DT and the device would pass the test.
Regards,
Markus Pargmann
Regards,
-Bin.
Regards,
Markus Pargmann
Regards,
-Bin.
So in A mode, we cancel the currently running session which also
disables the possibility to detect new devices via interrupt. In B mode,
we start a session to check for ID-Pin and possibly connected devices.
Whenever a real USB session ends, we have to trigger the otg_timer poll
function again.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 84
1 file changed, 78 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index b24b697..0245e8d 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -178,6 +178,43 @@ static const struct file_operations
musb_regdump_fops = {
#endif /* IS_ENABLED(CONFIG_DEBUG_FS) */
+/*
+ * Compare driver and hardware mode and update driver state if
necessary.
+ * Not all hardware changes actually reach the driver through
interrupts.
+ */
+static void dsps_update_mode(struct musb *musb)
+{
+ u8 devctl;
+
+ devctl = dsps_readb(musb-mregs, MUSB_DEVCTL);
+
+ switch (musb-xceiv-state) {
+ case OTG_STATE_A_IDLE:
+ if (devctl MUSB_DEVCTL_BDEVICE) {
+ dev_dbg(musb-controller, detected controller
state B, software state A\n);
+ musb-xceiv-state = OTG_STATE_B_IDLE;
+ }
+ break;
+ case OTG_STATE_B_IDLE:
+ if (!(devctl MUSB_DEVCTL_BDEVICE)) {
+ dev_dbg(musb-controller, detected controller
state A, software state B\n);
+ musb-xceiv-state = OTG_STATE_A_IDLE;
+ }
+ break;
+ default:
+ if (!(devctl MUSB_DEVCTL_SESSION)) {
+ dev_dbg(musb-controller, detected controller
out of session (%x), software state %s\n,
+ devctl,
+
usb_otg_state_string(musb-xceiv-state));
+ if (devctl MUSB_DEVCTL_BDEVICE)
+ musb-xceiv-state = OTG_STATE_B_IDLE;
+ else
+ musb-xceiv-state = OTG_STATE_A_IDLE;
+ }
+ break;
+ }
+}
+
/**
* dsps_musb_enable - enable interrupts
*/
@@ -229,6 +266,8 @@ static void otg_timer(unsigned long _musb)
u8 devctl;
unsigned long flags;
+ dsps_update_mode(musb);
+
/*
Re: [PATCH v6 14/14] usb/gadget: f_mass_storage: add configfs support
W dniu 14.10.2013 22:39, Michal Nazarewicz pisze:
I generally agree, but please see inline. I will post the corrected
patch as a reply to this thread.
On Wed, Oct 09 2013, Andrzej Pietrasiewicz andrze...@samsung.com wrote:
From this commit on f_mass_storage is available through configfs.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
Just tiny nit-picking to follow:
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index d80be5f..00d3687 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -3295,6 +3296,342 @@ static int fsg_bind_config(struct usb_composite_dev
*cdev,
#else
+static inline struct fsg_lun_opts *to_fsg_lun_opts(struct config_item *item)
+{
+ return container_of(to_config_group(item), struct fsg_lun_opts, group);
+}
+
+static inline struct fsg_opts *to_fsg_opts(struct config_item *item)
+{
+ return container_of(to_config_group(item), struct fsg_opts,
+ func_inst.group);
+}
Personally I'd prefer “fsg_lun_opts_from_config_item” and
“fsg_opts_from_config_item”, but whatever.
I wouldn't mind changing it according to your taste, but the
CONFIGFS_ATTR_OPS macro (defined in include/linux/configfs.h) expects
that there is a to_##item() function available, where the item is
CONFIGFS_ATTR_OPS's argument.
AP
--
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/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 08:31 AM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+
[PATCH v6 resend 14/14] usb/gadget: f_mass_storage: add configfs support
From this commit on f_mass_storage is available through configfs.
Signed-off-by: Andrzej Pietrasiewicz andrze...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Michal Nazarewicz min...@mina86.com
---
.../ABI/testing/configfs-usb-gadget-mass-storage | 31 ++
drivers/usb/gadget/Kconfig | 11 +
drivers/usb/gadget/f_mass_storage.c| 359
drivers/usb/gadget/f_mass_storage.h| 17 +
4 files changed, 418 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-mass-storage
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
new file mode 100644
index 000..ad72a37
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
@@ -0,0 +1,31 @@
+What: /config/usb-gadget/gadget/functions/mass_storage.name
+Date: Oct 2013
+KenelVersion: 3.13
+Description:
+ The attributes:
+
+ stall - Set to permit function to halt bulk endpoints.
+ Disabled on some USB devices known not to work
+ correctly. You should set it to true.
+ num_buffers - Number of pipeline buffers. Valid numbers
+ are 2..4. Available only if
+ CONFIG_USB_GADGET_DEBUG_FILES is set.
+
+What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
+Date: Oct 2013
+KenelVersion: 3.13
+Description:
+ The attributes:
+
+ file- The path to the backing file for the LUN.
+ Required if LUN is not marked as removable.
+ ro - Flag specifying access to the LUN shall be
+ read-only. This is implied if CD-ROM emulation
+ is enabled as well as when it was impossible
+ to open filename in R/W mode.
+ removable - Flag specifying that LUN shall be indicated as
+ being removable.
+ cdrom - Flag specifying that LUN shall be reported as
+ being a CD-ROM.
+ nofua - Flag specifying that FUA flag
+ in SCSI WRITE(10,12)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 22781e0..c95b192 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -668,6 +668,17 @@ config USB_CONFIGFS_PHONET
help
The Phonet protocol implementation for USB device.
+config USB_CONFIGFS_MASS_STORAGE
+ boolean Mass storage
+ depends on USB_CONFIGFS
+ select USB_U_MS
+ select USB_F_MASS_STORAGE
+ help
+ The Mass Storage Gadget acts as a USB Mass Storage disk drive.
+ As its storage repository it can use a regular file or a block
+ device (in much the same way as the loop device driver),
+ specified as a module parameter or sysfs option.
+
config USB_ZERO
tristate Gadget Zero (DEVELOPMENT)
select USB_LIBCOMPOSITE
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index d80be5f..c0a5ca0 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -220,6 +220,7 @@
#include linux/usb/composite.h
#include gadget_chips.h
+#include configfs.h
/**/
@@ -3295,6 +3296,341 @@ static int fsg_bind_config(struct usb_composite_dev
*cdev,
#else
+static inline struct fsg_lun_opts *to_fsg_lun_opts(struct config_item *item)
+{
+ return container_of(to_config_group(item), struct fsg_lun_opts, group);
+}
+
+static inline struct fsg_opts *to_fsg_opts(struct config_item *item)
+{
+ return container_of(to_config_group(item), struct fsg_opts,
+ func_inst.group);
+}
+
+CONFIGFS_ATTR_STRUCT(fsg_lun_opts);
+CONFIGFS_ATTR_OPS(fsg_lun_opts);
+
+static void fsg_lun_attr_release(struct config_item *item)
+{
+ struct fsg_lun_opts *lun_opts;
+
+ lun_opts = to_fsg_lun_opts(item);
+ kfree(lun_opts);
+}
+
+static struct configfs_item_operations fsg_lun_item_ops = {
+ .release= fsg_lun_attr_release,
+ .show_attribute = fsg_lun_opts_attr_show,
+ .store_attribute= fsg_lun_opts_attr_store,
+};
+
+static ssize_t fsg_lun_opts_file_show(struct fsg_lun_opts *opts, char *page)
+{
+ struct fsg_opts *fsg_opts;
+
+ fsg_opts = to_fsg_opts(opts-group.cg_item.ci_parent);
+
+ return fsg_show_file(opts-lun, fsg_opts-common-filesem, page);
+}
+
+static ssize_t fsg_lun_opts_file_store(struct fsg_lun_opts *opts,
+
Scheduling of interrupt transfer delayed on ehci when interval not 1?
Hello, I made a change to the rts5139 driver that got included in kernel 3.11 (see second patch at end of this email), but Lutz Vieweg reported that the patch causes issues for him, because the driver falsely detects that the SD card is no longer present after transfer of a few 100 MBs. I do not have this issue with xhci. He is using ehci. The USB endpoint specifies a transfer interval of 10. The rts5139 driver uses the interrupt transfer to infrequently poll for card presence, but doesn't queue multiple urbs for periodic transfers. The issue seems to be a difference in how early the (first) interrupt transfer is scheduled by xhci and ehci when the interval specified in the urb is not 1. With ehci it seems to be delayed when the interval is not 1. With xhci you get warning messages in syslog if interval is not 10. My USB knowledge is too limited to properly fix this in xhci or ehci hcd. Can somebody help me? what is the correct fix for this problem? It is possible that the following patch, that increases the timeout the driver waits for the interrupt transfer, will fix the problem with ehci. However, I expect that the transfer is slightly slower then with ehci, compared to kernel 3.10. regards Marcus == Proposed fix (workaround) diff --git a/drivers/staging/rts5139/ rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c index c172f4a..c4ede32 100644 --- a/drivers/staging/rts5139/rts51x_transport.c +++ b/drivers/staging/rts5139/rts51x_transport.c @@ -640,7 +640,7 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status) usb_fill_int_urb(chip-usb-intr_urb, chip-usb-pusb_dev, pipe, status, 2, urb_done_completion, urb_done, 10); - result = rts51x_msg_common(chip, chip-usb-intr_urb, 100); + result = rts51x_msg_common(chip, chip-usb-intr_urb, 500); return interpret_urb_result(chip, pipe, 2, result, chip-usb-intr_urb-actual_length); == === Patch that went into kernel 3.11 Using correct transfer interval as specified by the USB endpoint when doing the interrupt transfer fixes the warning printed by xhci USB core on every transfer that resulted in spamming xhci_queue_intr_tx: 74 callbacks suppressed to syslog every 5 seconds. Signed-off-by: Marcus Overhagen marcus.overha...@gmail.com --- drivers/staging/rts5139/ rts51x_transport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/rts5139/rts51x_transport.c b/drivers/staging/rts5139/rts51x_transport.c index c573618..c172f4a 100644 --- a/drivers/staging/rts5139/rts51x_transport.c +++ b/drivers/staging/rts5139/rts51x_transport.c @@ -635,10 +635,10 @@ int rts51x_get_epc_status(struct rts51x_chip *chip, u16 *status) ep = chip-usb-pusb_dev-ep_in[usb_pipeendpoint(pipe)]; /* fill and submit the URB */ - /* We set interval to 1 here, so the polling interval is controlled -* by our polling thread */ + /* Set interval to 10 here to match the endpoint descriptor, +* the polling interval is controlled by the polling thread */ usb_fill_int_urb(chip-usb-intr_urb, chip-usb-pusb_dev, pipe, -status, 2, urb_done_completion, urb_done, 1); +status, 2, urb_done_completion, urb_done, 10); result = rts51x_msg_common(chip, chip-usb-intr_urb, 100); === -- 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: Moxa UPORT 12XX/14XX/16XX driver
Hi Andrew,
We can do the interface testing but I want to know how to get the latest
source. We need about 5 days to do the testing for all models and give you a
testing report.
Thanks.
Danny.
-Original Message-
From: Andrew Lunn [mailto:and...@lunn.ch]
Sent: Thursday, October 10, 2013 3:55 AM
To: Johan Hovold
Cc: Andrew Lunn; linux-usb@vger.kernel.org; Danny Lin (林政易); Ray Chen (陳松昱)
Subject: Re: [PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver
On Wed, Oct 09, 2013 at 07:27:42PM +0200, Johan Hovold wrote:
On Wed, Oct 09, 2013 at 12:57:45PM +0200, Johan Hovold wrote:
On Wed, Sep 25, 2013 at 11:53:00AM +0200, Andrew Lunn wrote:
[...]
+#define MX_INT_RS232 0
+#define MX_INT_2W_RS485 1
+#define MX_INT_RS422 2
+#define MX_INT_4W_RS485 3
+static ssize_t show_four_wire(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct usb_serial_port *port = to_usb_serial_port(dev);
+ struct mxuport_port *mxport = usb_get_serial_port_data(port);
+
+ return sprintf(buf, %i\n, mxport-four_wire_rs485);
Use scnprintf (and PAGE_SIZE) even if it's a bool.
+}
+
+static ssize_t store_four_wire(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t size)
+{
+ struct usb_serial_port *port = to_usb_serial_port(dev);
+ struct mxuport_port *mxport = usb_get_serial_port_data(port);
+
+ if (strtobool(buf, mxport-four_wire_rs485) 0)
+ return -EINVAL;
+
+ return size;
+}
+
+static DEVICE_ATTR(4_wire_rs485, S_IWUSR | S_IRUGO,
+show_four_wire, store_four_wire);
Use DEVICE_ATTR_RW.
You dropped RS422-support from v3. Was that intentional?
Hmmm. I've been thinking a bit how best to handle this, and I think we
should consider adding a SER_RS485_4_WIRE flag to serial_rs485 instead
of having a custom attribute. That still leaves RS422, which could
possibly be enabled using the RS485-ioctl as well (or we use a
rs422-attribute for now).
I'll get back to you on this.
After giving this some more thought I don't really think the
TIOCSRS485-ioctl interface is appropriate after all. The
RQ_VENDOR_SET_INTERFACE-request doesn't just enable 2-wire-rs485-style
signalling, but also changes which pins on the DB9-connector that are
used.
This should probably remain a device-specific parameter. We already have
the MOXA mxser-driver with similar configuration options. This one uses
a custom ioctl to set the interface, but I think we should use a sysfs
parameter for this.
What do you say about a simple interface-parameter representing the
four MX_INT-values above? A string parameter would perhaps be even
better if you combine it with an interface_available-parameter, for
example:
# cat /sys/bus/usb-serial/devices/ttyUSB0/interface_available
rs232 rs422 rs485-2w rs485-4w
for devices which can use all four modes.
Sorry about the confusion.
Hi Johan
No problems.
I'm actually tempted to drop the support for anything over than RS232.
That is all the hardware i have can do. So anything we do add i cannot
test.
If somebody does have the necessary hardware and the need for these
extra modes we can come back to this.
Andrew
Re: [PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver
On Tue, Oct 15, 2013 at 08:30:51AM +, Danny Lin (林政易) wrote: Hi Andrew, We can do the interface testing but I want to know how to get the latest source. We need about 5 days to do the testing for all models and give you a testing report. Hi Danny Thanks for the offer of testing. However, I already removed the support from my working tree. How about we leave it out for the moment, get the driver accepted and included in mainline, and then add back the interface support? 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: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Hi everyone, Sorry for the late test but I had other tasks... I just had some time to look at it and test it. Le 30/09/2013 09:47, Mylene Josserand a écrit : Le 29/09/2013 19:08, Christoph Fritz a écrit : On Sun, 2013-09-29 at 12:19 -0300, Fabio Estevam wrote: On Sun, Sep 29, 2013 at 11:32 AM, Christoph Fritz chf.fr...@googlemail.com wrote: Le 26/09/2013 17:59, Christoph Fritz a écrit : Their software fix: As first attemp at fixing this issue, one may try to switch LINK to ULPI mode before configuring MUX and pads for USB operation. Fear is that this could cause unexpected transfer from PHY to LINK, somehow preventing proper initialization I'll try that here with the smsc3340-phy. What a mess, it is also important in what order the muxing of USB-Pins is done beside the fact that some USBOTG pins had a GPIO_OUT configured wrongly. Don't ask how I hit this, but with that and the info from above finally both smsc3340 phys on OTG and USBH2 get detected: pure Can you show a patch or code so that others could fix this problem as well? Sure, attached to this mail are 4 of my work-in-progress patches, two for barebox and two for the kernel. Consider them RFC. The ULPI-mode switching before muxing is already part of barebox. Thanks -- Christoph Thank you very much, Christoph ! I really like having good news like this to start the working week :D I will try to test it this week ! I hope it will work for me too :) Unfortunately, I don't know if I missed any configurations but the SMSC 3340 is still not working in my case.. :( I test it with a 2.6.32 kernel. The phy seems to be detected (same thing before the patches) but when I plug an USB-key, no reaction in the kernel. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver mxc-ehci mxc-ehci.2: initializing i.MX USB Controller navocap_cedalion_h2_gpioinit done mxc-ehci mxc-ehci.2: Freescale On-Chip EHCI Host Controller mxc-ehci mxc-ehci.2: new USB bus registered, assigned bus number 1 mxc-ehci mxc-ehci.2: irq 55, io mem 0x10024400 mxc-ehci mxc-ehci.2: USB 2.0 started, EHCI 1.00 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected mxc-ehci mxc-ehci.0: initializing i.MX USB Controller navocap_cedalion_otg_gpioinit done mxc-ehci mxc-ehci.0: Freescale On-Chip EHCI Host Controller mxc-ehci mxc-ehci.0: new USB bus registered, assigned bus number 2 mxc-ehci mxc-ehci.0: irq 56, io mem 0x10024000 mxc-ehci mxc-ehci.0: USB 2.0 started, EHCI 1.00 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected I test it with a 8.2 kernel too and I have the same previous error timeout polling : ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-mxc: Freescale On-Chip EHCI Host driver mxc-ehci mxc-ehci.0: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.0: unable to init transceiver, probably missing mxc-ehci mxc-ehci.2: initializing i.MX USB Controller timeout polling for ULPI device mxc-ehci mxc-ehci.2: unable to init transceiver, probably missing Initializing USB Mass Storage driver... Christoph, you are using a 3.4 kernel, is not it ? I will continue to search but I have no experience on USB (and I am learning with it how works BSP too) so any help would be very appreciated. If I make any progress, I will post it on this mail-list, of course ! Best regards, -- Mylène JOSSERAND
RE: [PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver
Hi Andrew, Since all the models are putting on the configuration file, I hope it should be a full function before put in mainline even if it needs more time to verify. I think it is the right thing for us. Danny. -Original Message- From: Andrew Lunn [mailto:and...@lunn.ch] Sent: Tuesday, October 15, 2013 4:40 PM To: Danny Lin (林政易) Cc: Andrew Lunn; linux-usb@vger.kernel.org; Johan Hovold; Ray Chen (陳松昱) Subject: Re: [PATCH v3] usb-serial: Moxa UPORT 12XX/14XX/16XX driver On Tue, Oct 15, 2013 at 08:30:51AM +, Danny Lin (林政易) wrote: Hi Andrew, We can do the interface testing but I want to know how to get the latest source. We need about 5 days to do the testing for all models and give you a testing report. Hi Danny Thanks for the offer of testing. However, I already removed the support from my working tree. How about we leave it out for the moment, get the driver accepted and included in mainline, and then add back the interface support? Andrew
transmit lockup using smsc95xx ethernet on usb3
We are seeing complete lockups of the transmit side when using the smsc95xx driver connected to a USB3 port on an i7 (Ivybridge) cpu. These errors are very intermittent - less than once a day, and it isn't actually clear that they are related to traffic load. Most of the systems are running the 3.2 kernel from Ubuntu 12.04 but I've seen the same problem when running a 3.4 kernel. Looking at the changelog for xhci-ring.c I can see that some 'nasty' bugs were fixed between 3.2 and 3.4 (and possibly since) but the usbmon trace I've now got doesn't seem to match any of the changelog entries. We are also seeing similar problems if we connect to a USB2 header. Since we can't reproduce the problem quickly it is difficult to do any analysis. Any suggestions for increasing the error rate would be welcome. Below is an annotated extract from a usbmon trace while running a netperf test that was sending 8192 byte TCP packets (nagle off). I've deleted the Bi entries (packets are received throughout) and numbered all the others (modulo 1) so it is easier to see when the requests complete, I've also calculated the elapsed time and the number of Setup entries between the S and C traces. The USB ring seems to have 60 outstanding transmits in it, each time one completes another is sent. There are a few 1 traces of that then: start:9870 88020ea16000 293811125 S Bo:3:003:2 -115 1514 = e235 e245 22003200 00224d98 d8460002 1f0057d7 08004500 05d0ff11 done:9811:6969:60 88020c7c8000 293811236 C Bo:3:003:2 0 1090 start:9871 88020ea16a80 293811242 S Bo:3:003:2 -115 1090 = 3a34 3a44 22003200 00224d98 d8460002 1f0057d7 08004500 0428ff12 ... start:9929 88020ea16780 293817964 S Bo:3:003:2 -115 1514 = e235 e245 22003200 00224d98 d8460002 1f0057d7 08004500 05d0ff4c Last successful completion. done:9870:6968:60 88020ea16000 293818093 C Bo:3:003:2 0 1514 start:9930 88020ea16000 293818099 S Bo:3:003:2 -115 1514 = e235 e245 22003200 00224d98 d8460002 1f0057d7 08004500 05d0ff4d At this point something (untraced) seems to have gone horribly wrong in the transmit ring. dmesg shows nothing. Two Bo 'fail -71', 6 succeed, one fails -32 the rest fail -104. done:9871:6913:60 88020ea16a80 293818155 C Bo:3:003:2 -71 512 done:9872:6927:59 88020ea16f00 293818235 C Bo:3:003:2 -71 0 done:9873:6875:58 88020ea16480 293818313 C Bo:3:003:2 0 1514 done:9874:6786:57 88020c7c83c0 293818353 C Bo:3:003:2 0 1514 done:9875:6794:56 88020c7c80c0 293818470 C Bo:3:003:2 0 1514 done:9876:6789:55 88020c7c8e40 293818589 C Bo:3:003:2 0 1514 done:9877:6775:54 88020c7c8240 293818702 C Bo:3:003:2 0 1090 done:9878:6751:53 88020c7c8180 293818803 C Bo:3:003:2 0 1514 done:9879:6735:52 88020c7c89c0 293818885 C Bo:3:003:2 -32 0 done:9880:6671:51 88020c7c8900 293818925 C Bo:3:003:2 -104 0 ... done:9927:1292:4 88020cf0c480 293819015 C Bo:3:003:2 -104 0 done:9928:1170:3 88020ea160c0 293819016 C Bo:3:003:2 -104 0 Something is known to be wrong... start:9931 88020ea160c0 293819037 S Co:3:003:0 s 02 01 0002 0 done:9929:1080:3 88020ea16780 293819044 C Bo:3:003:2 -104 0 done:9930:945:2 88020ea16000 293819044 C Bo:3:003:2 -104 0 done:9931:48:1 88020ea160c0 293819085 C Co:3:003:0 0 0 These 10 transmits never finish: start:9932 88020ea160c0 293819098 S Bo:3:003:2 -115 1090 = 3a34 3a44 22003200 00224d98 d8460002 1f0057d7 08004500 0428ff4e ... 9933 to 9940 deleted start:9941 88020ea16b40 293819111 S Bo:3:003:2 -115 1514 = e235 e245 22003200 00224d98 d8460002 1f0057d7 08004500 05d0ff57 All further transmits fail immediately E -12 and generate the 'xhci_hcd :00:14.0: ERROR no room on ep ring' message. (There are 1070 'E' traces and 1070 'no room' messages.) Receives are still working. start:9942 88020ea16240 293819113 S Bo:3:003:2 -115 1514 = e235 e245 22003200 00224d98 d8460002 1f0057d7 08004500 05d0ff58 done:9942:1550:1 88020ea16240 293820663 E Bo:3:003:2 -12 0 start:9943 88020ea16240 293820675 S Bo:3:003:2 -115 1514 = e235 e245 22003200 00224d98 d8460002 1f0057d7 08004500 05d0ff59 done:9943:1507:1 88020ea16240 293822182 E Bo:3:003:2 -12 0 Eventually something causes a device remove and insert - everything re-initialises. This is over 12 hours later. done:unknown 88020c8570c0 3637139297 C Ii:3:001:1 0:2048 1 =
Re: some questions about ehci period scheduling
hi alan:
BTW, I have another question about iso_stream_schedule.
When if (likely (!list_empty (stream-td_list))) happen,
why don't we just take last scheduled microframe, stream-next_uframe
as start point directly?
We do exactly that if URB_ISO_ASAP isn't set. But first the routine
has to check and see if the schedule is already full, and it prints a
debugging message if all the assigned microframes have already expired.
Does below source show us what you mean?
if (unlikely(start period)) {
ehci_dbg(ehci, iso sched full %p (%u-%u %u mod %u)\n,
urb, stream-next_uframe, base,
period, mod);
status = -ENOSPC;
goto fail;
}
That's the first part (checking if the schedule is already full).
This is the second part (printing a debug message if all the assigned
microframes have already expired):
Does this expired come from (controller frame pointer)
(stream-next_uframe)?
Suppose controller frame pointer = 640 and stream-next_uframe = 600.
And that mean Controller have scan our last schedule uframe?
/*
* Not ASAP: Use the next slot in the stream,
* no matter what.
*/
else if (start + span - period now2) {
ehci_dbg(ehci, iso underrun %p (%u+%u %u)\n,
urb, start + base,
span - period, now2 + base);
}
if so, I have one question, why we use ( (last scan frame and last
schedule frame) end point interval) to determine schedule is full?
If start period, it means that the last packet on the schedule (which
is assigned to uframe start - period) comes before base. The only way
this can happen is if the packets occupy the entire schedule and wrap
around.
base in your example base should be 8's multiple, right?
if so, I try to rewrite your example.
(if anything wrong, please correct me)
(rewrite version)
If you think about a few examples, you'll understand. Suppose the
endpoint's interval is 8 uframes, starting from uframe 3. Suppose base
is 496, and suppose the schedule really is full. Then there will be
packets scheduled for uframes 507, 515, ..., 8187, 3, 11, ..., 491, 499
(note that 491 is slightly before 496), and stream-next_uframe will be
499. So start will be set to (499 - 496) 8191 = 3. The fact that 3
8 indicates the schedule is full.
(rewrite version)
Now suppose everything else is the same, but the schedule isn't
completely full. For this example, let's suppose the last scheduled
packet is in uframe 483, so stream-next_uframe is equal to 491. Then
start will be set to (491 - 496) 8191 = 8196. The fact that 8196 =
8 indicates the schedule isn't full.
In above case, driver should try to stop this urb if it try to
schedule more than 1 packet, right?
(rewrite version)
Consider one more example: Everything else is the same, but there's
only one packet in the schedule. It is assigned to uframe 507, and
stream-next_uframe is 515. Then start will be set to (515 - 496)
8191 = 19, and the fact that 19 = 8 indicates the schedule isn't full.
Does this help?
Yes, it did help me a lot. :)
Below is where we handle URB_ISO_ASAP,
if (urb-transfer_flags URB_ISO_ASAP)
start += (next - start + period - 1) -period;
Why don't we just use start as next?
If start next then we don't want to use it. Packets scheduled before
next might not be seen by the hardware, because of the isochronous
scheduling threshold (see section 4.7.2.1 in the EHCI spec).
when we calculate next, we have already put isochronous scheduling threshold.
if (ehci-i_thresh)
next = now + ehci-i_thresh;/* uframe cache */
else
next = (now + 2 + 7) ~0x07;/* full frame cache */
so when handling URB_ISO_ASAP, is it possible to change as below
if (urb-transfer_flags URB_ISO_ASAP)
-start += (next - start + period - 1) -period;
+ start = (next + base);
Appreciate your kind help,
--
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: phy: omap: Add omap-control Support for AM437x
This adds omap control module support for USBSS in AM437x SoC.
Update DT binding information to reflect these changes.
Signed-off-by: George Cherian george.cher...@ti.com
---
Changes from v1:
Make ON and OFF operations symmetric.
Documentation/devicetree/bindings/usb/omap-usb.txt | 2 ++
drivers/usb/phy/phy-omap-control.c | 19 +++
include/linux/usb/omap_control_usb.h | 6 ++
3 files changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 090e5e2..c495135 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -87,6 +87,8 @@ Required properties:
e.g. USB3 PHY and SATA PHY on OMAP5.
ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
DRA7 platform.
+ ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on
+ AM437 platform.
- reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
for other types.
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 09c5ace..e725318 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -84,6 +84,20 @@ void omap_control_usb_phy_power(struct device *dev, int on)
else
val |= OMAP_CTRL_USB2_PHY_PD;
break;
+
+ case OMAP_CTRL_TYPE_AM437USB2:
+ if (on) {
+ val = ~(AM437X_CTRL_USB2_PHY_PD |
+ AM437X_CTRL_USB2_OTG_PD);
+ val |= (AM437X_CTRL_USB2_OTGVDET_EN |
+ AM437X_CTRL_USB2_OTGSESSEND_EN);
+ } else {
+ val = ~(AM437X_CTRL_USB2_OTGVDET_EN |
+ AM437X_CTRL_USB2_OTGSESSEND_EN);
+ val |= (AM437X_CTRL_USB2_PHY_PD |
+AM437X_CTRL_USB2_OTG_PD);
+ }
+ break;
default:
dev_err(dev, %s: type %d not recognized\n,
__func__, control_usb-type);
@@ -197,6 +211,7 @@ static const enum omap_control_usb_type otghs_data =
OMAP_CTRL_TYPE_OTGHS;
static const enum omap_control_usb_type usb2_data = OMAP_CTRL_TYPE_USB2;
static const enum omap_control_usb_type pipe3_data = OMAP_CTRL_TYPE_PIPE3;
static const enum omap_control_usb_type dra7usb2_data =
OMAP_CTRL_TYPE_DRA7USB2;
+static const enum omap_control_usb_type am437usb2_data =
OMAP_CTRL_TYPE_AM437USB2;
static const struct of_device_id omap_control_usb_id_table[] = {
{
@@ -215,6 +230,10 @@ static const struct of_device_id
omap_control_usb_id_table[] = {
.compatible = ti,control-phy-dra7usb2,
.data = dra7usb2_data,
},
+ {
+ .compatible = ti,control-phy-am437usb2,
+ .data = am437usb2_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_control_usb_id_table);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 596b019..69ae383 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -24,6 +24,7 @@ enum omap_control_usb_type {
OMAP_CTRL_TYPE_USB2,/* USB2_PHY, power down in CONTROL_DEV_CONF */
OMAP_CTRL_TYPE_PIPE3, /* PIPE3 PHY, DPLL seperate Rx/Tx power */
OMAP_CTRL_TYPE_DRA7USB2, /* USB2 PHY, power and power_aux e.g. DRA7 */
+ OMAP_CTRL_TYPE_AM437USB2, /* USB2 PHY, power e.g. AM437x */
};
struct omap_control_usb {
@@ -64,6 +65,11 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
+#define AM437X_CTRL_USB2_PHY_PDBIT(0)
+#define AM437X_CTRL_USB2_OTG_PDBIT(1)
+#define AM437X_CTRL_USB2_OTGVDET_ENBIT(19)
+#define AM437X_CTRL_USB2_OTGSESSEND_EN BIT(20)
+
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
--
1.8.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 v3 1/2] phy: omap-usb2: Sort the headers alphabetically
This makes checking for duplicates easier while adding new #include. Signed-off-by: George Cherian george.cher...@ti.com --- drivers/phy/phy-omap-usb2.c | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c index bfc5c33..3e5f08c 100644 --- a/drivers/phy/phy-omap-usb2.c +++ b/drivers/phy/phy-omap-usb2.c @@ -16,20 +16,20 @@ * */ +#include linux/clk.h +#include linux/delay.h +#include linux/err.h +#include linux/io.h #include linux/module.h +#include linux/of.h +#include linux/of_platform.h +#include linux/phy/phy.h #include linux/platform_device.h +#include linux/pm_runtime.h #include linux/slab.h -#include linux/of.h -#include linux/io.h #include linux/usb/omap_usb.h -#include linux/usb/phy_companion.h -#include linux/clk.h -#include linux/err.h -#include linux/pm_runtime.h -#include linux/delay.h #include linux/usb/omap_control_usb.h -#include linux/phy/phy.h -#include linux/of_platform.h +#include linux/usb/phy_companion.h /** * omap_usb2_set_comparator - links the comparator present in the sytem with -- 1.8.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 v3 2/2] phy: omap-usb2: Adapt phy-omap-usb2 for AM437x
This patch adds a compatible for AM437x ti,am43xx-usb2 to
reuse the same phy-omap-usb2 driver.
Also updated the documentation to add the new compatible.
Signed-off-by: George Cherian george.cher...@ti.com
---
Documentation/devicetree/bindings/usb/usb-phy.txt | 4 +-
drivers/phy/phy-omap-usb2.c | 54 +--
include/linux/usb/omap_usb.h | 10 +
3 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/usb/usb-phy.txt
index c0245c8..309ab27 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -3,7 +3,9 @@ USB PHY
OMAP USB2 PHY
Required properties:
- - compatible: Should be ti,omap-usb2
+ - compatible: Should be either of
+ * ti,omap-usb2 for OMAP4,OMAP5,DRA7
+ * ti,am437x-usb2 for AM437x
- reg : Address and length of the register set for the device.
- #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 3e5f08c..7c0bc6c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -144,6 +144,35 @@ static struct phy_ops ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct usb_phy_data omap_usb2_data = {
+ .label = omap_usb2,
+ .set_host = omap_usb_set_host,
+ .set_peripheral = omap_usb_set_peripheral,
+ .set_vbus = omap_usb_set_vbus,
+ .start_srp = omap_usb_start_srp,
+};
+
+static const struct usb_phy_data am437x_usb2_data = {
+ .label = am437x_usb2,
+ .set_host = omap_usb_set_host,
+ .set_peripheral = omap_usb_set_peripheral,
+};
+
+static const struct of_device_id omap_usb2_id_table[] = {
+ {
+ .compatible = ti,omap-usb2,
+ .data = omap_usb2_data,
+ },
+ {
+ .compatible = ti,am437x-usb2,
+ .data = am437x_usb2_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#endif
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
@@ -153,9 +182,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
struct device_node *node = pdev-dev.of_node;
struct device_node *control_node;
struct platform_device *control_pdev;
+ const struct of_device_id *of_id;
+ struct usb_phy_data *phy_data;
+
+ of_id = of_match_device(of_match_ptr(omap_usb2_id_table), pdev-dev);
- if (!node)
+ if (!of_id)
return -EINVAL;
+ phy_data = (struct usb_phy_data *)of_id-data;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -172,7 +206,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-dev= pdev-dev;
phy-phy.dev= phy-dev;
- phy-phy.label = omap-usb2;
+ phy-phy.label = phy_data-label;
phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
@@ -199,10 +233,10 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
- otg-set_host = omap_usb_set_host;
- otg-set_peripheral = omap_usb_set_peripheral;
- otg-set_vbus = omap_usb_set_vbus;
- otg-start_srp = omap_usb_start_srp;
+ otg-set_host = phy_data-set_host;
+ otg-set_peripheral = phy_data-set_peripheral;
+ otg-set_vbus = phy_data-set_vbus;
+ otg-start_srp = phy_data-start_srp;
otg-phy= phy-phy;
platform_set_drvdata(pdev, phy);
@@ -297,14 +331,6 @@ static const struct dev_pm_ops omap_usb2_pm_ops = {
#define DEV_PM_OPS NULL
#endif
-#ifdef CONFIG_OF
-static const struct of_device_id omap_usb2_id_table[] = {
- { .compatible = ti,omap-usb2 },
- {}
-};
-MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
-#endif
-
static struct platform_driver omap_usb2_driver = {
.probe = omap_usb2_probe,
.remove = omap_usb2_remove,
diff --git a/include/linux/usb/omap_usb.h b/include/linux/usb/omap_usb.h
index 6ae2936..0c6b71c 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/usb/omap_usb.h
@@ -42,6 +42,16 @@ struct omap_usb {
u8 is_suspended:1;
};
+struct usb_phy_data {
+ const char *label;
+ int (*set_host)(struct usb_otg *otg, struct usb_bus *host);
+ int (*set_peripheral)(struct usb_otg *otg,
+ struct usb_gadget *gadget);
+ int (*set_vbus)(struct usb_otg *otg, bool enabled);
+ int (*start_srp)(struct usb_otg
[PATCH v3 0/2] Adapt phy-omap-usb2 for AM437x platform
This series adapts the phy-omap-usb2 generic phy driver for AM437x. While at that sort the include files alphabetically (PATCH 1) Patch1 - v2-v3 Amend the commit log V2 of 2nd Patch which fixes the following from v1 - List comaptible entries in Documentaion - Add usb_phy_data instead of checking compatible each time. George Cherian (2): phy: omap-usb2: Sort the headers alphabetically phy: omap-usb2: Adapt phy-omap-usb2 for AM437x Documentation/devicetree/bindings/usb/usb-phy.txt | 4 +- drivers/phy/phy-omap-usb2.c | 72 +++ include/linux/usb/omap_usb.h | 10 3 files changed, 62 insertions(+), 24 deletions(-) -- 1.8.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: [help] imx27 - isp1504 : unable to init transceiver, probably missing
Le 15/10/2013 11:48, Mylene Josserand a écrit : Unfortunately, I don't know if I missed any configurations but the SMSC 3340 is still not working in my case.. :( I test it with a 2.6.32 kernel. The phy seems to be detected (same thing before the patches) but when I plug an USB-key, no reaction in the kernel. ah ! I was wrong, in fact, the OTG port did not react but the H2 reacts with an USB key : usb 1-1: new low speed USB device using mxc-ehci and address 2 usb 1-1: device descriptor read/64, error -71 usb 1-1: device descriptor read/64, error -71 usb 1-1: new low speed USB device using mxc-ehci and address 3 usb 1-1: device descriptor read/64, error -71 usb 1-1: device descriptor read/64, error -71 usb 1-1: new low speed USB device using mxc-ehci and address 4 usb 1-1: device not accepting address 4, error -71 usb 1-1: new low speed USB device using mxc-ehci and address 5 usb 1-1: device not accepting address 5, error -71 hub 1-0:1.0: unable to enumerate USB device on port 1 What is the code error -71 ? In this thread (https://bbs.archlinux.org/viewtopic.php?id=149708), seems to be a EPROTO error. Is it right ? What is it due to ? -- Mylène JOSSERAND
Re: [PATCH 01/11] usb: chipidea: Add power management support
On Tue, Oct 15, 2013 at 10:18:15AM +0800, Peter Chen wrote: So, the lessons for this topic are: - If one atomic variable's operation only includes one instruction like atomic_read and atomic_set, it is not meaningful for using atomic operation, we can just use bool instead of it. The lesson here is that these are 100% equivalent as far as safety from races is concerned: a = atomic_read(v);a = v-counter; atomic_set(v, b); v-counter = b; and in general, whenever atomic_read() gets used it's almost certainly a sign of a bug. Consider this (similar has been submitted): a = atomic_read(v); if (a != 0) a += 1; atomic_set(v, a); and people have thought that somehow this is magically safe from races because they're using atomic_t, and somehow that saves the universe. The above is in fact no safer than: a = *v; if (a != 0) a += 1; *v = a; The only thing that using atomic_* does is add a false sense of security and a level of obfuscation to catch the unwary reviewer. The reason is quite simple: a single access read in itself is atomic. Either it has read the value, or it hasn't. A single access store is itself atomic. Either the data has been written, or it hasn't. The issue is _always_ what you do around it. -- 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 2/2] phy: omap-usb2: Adapt phy-omap-usb2 for AM437x
Hi,
On Tue, Oct 15, 2013 at 12:23:45PM +0530, George Cherian wrote:
This patch adds a compatible for AM437x ti,am43xx-usb2 to
reuse the same phy-omap-usb2 driver.
it does more than just adding a new compatible flag.
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 3e5f08c..7c0bc6c 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -144,6 +144,35 @@ static struct phy_ops ops = {
.owner = THIS_MODULE,
};
+#ifdef CONFIG_OF
+static const struct usb_phy_data omap_usb2_data = {
+ .label = omap_usb2,
+ .set_host = omap_usb_set_host,
+ .set_peripheral = omap_usb_set_peripheral,
+ .set_vbus = omap_usb_set_vbus,
+ .start_srp = omap_usb_start_srp,
+};
+
+static const struct usb_phy_data am437x_usb2_data = {
+ .label = am437x_usb2,
+ .set_host = omap_usb_set_host,
+ .set_peripheral = omap_usb_set_peripheral,
+};
+
+static const struct of_device_id omap_usb2_id_table[] = {
+ {
+ .compatible = ti,omap-usb2,
+ .data = omap_usb2_data,
+ },
+ {
+ .compatible = ti,am437x-usb2,
+ .data = am437x_usb2_data,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_usb2_id_table);
+#endif
+
static int omap_usb2_probe(struct platform_device *pdev)
{
struct omap_usb *phy;
@@ -153,9 +182,14 @@ static int omap_usb2_probe(struct platform_device *pdev)
struct device_node *node = pdev-dev.of_node;
struct device_node *control_node;
struct platform_device *control_pdev;
+ const struct of_device_id *of_id;
+ struct usb_phy_data *phy_data;
+
+ of_id = of_match_device(of_match_ptr(omap_usb2_id_table), pdev-dev);
- if (!node)
+ if (!of_id)
return -EINVAL;
+ phy_data = (struct usb_phy_data *)of_id-data;
phy = devm_kzalloc(pdev-dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -172,7 +206,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-dev= pdev-dev;
phy-phy.dev= phy-dev;
- phy-phy.label = omap-usb2;
+ phy-phy.label = phy_data-label;
label can be set based on compatible flag:
if (of_device_is_compatible(node, ti,omap-usb2))
phy-phy.label = omap-usb2;
else /* if (of_device_is_compatible(node, ti,am437x-usb2)) */ /* default to
newest */
phy-phy.label = am437x-usb2;/* keep name
consistency */
phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
@@ -199,10 +233,10 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
- otg-set_host = omap_usb_set_host;
- otg-set_peripheral = omap_usb_set_peripheral;
- otg-set_vbus = omap_usb_set_vbus;
- otg-start_srp = omap_usb_start_srp;
+ otg-set_host = phy_data-set_host;
+ otg-set_peripheral = phy_data-set_peripheral;
+ otg-set_vbus = phy_data-set_vbus;
+ otg-start_srp = phy_data-start_srp;
this doesn't look right. I would rather have feature flags so that you
could:
if (test_bit(phy_data-flags, OMAP_USB2_HAS_SRP))
otg-start_srp = omap_usb_start_srp;
and so on. Note that you might need to add __maybe_unused annotations to
those functions otherwise you'll get unused warnings.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v3 2/2] phy: omap-usb2: Adapt phy-omap-usb2 for AM437x
On Tue, Oct 15, 2013 at 04:07:43PM +0530, George Cherian wrote: This patch adds a compatible for AM437x ti,am43xx-usb2 to reuse the same phy-omap-usb2 driver. Also updated the documentation to add the new compatible. Signed-off-by: George Cherian george.cher...@ti.com I commented on oldler series, sorry. Same comments are still valid though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Tue, Oct 15, 2013 at 11:01:16AM +0530, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(),
phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of
all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+if (dwc-usb2_generic_phy)
+phy_init(dwc-usb2_generic_phy);
+if (dwc-usb3_generic_phy)
+phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+if (dwc-usb2_generic_phy)
+phy_power_off(dwc-usb2_generic_phy);
+if (dwc-usb3_generic_phy)
+phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
}
+if (of_property_read_bool(node, phys) || pdata-has_phy) {
+dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+if (IS_ERR(dwc-usb2_generic_phy)) {
+dev_err(dev, no usb2 phy configured yet);
+return PTR_ERR(dwc-usb2_generic_phy);
+}
+
+dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+if (IS_ERR(dwc-usb3_generic_phy)) {
+dev_err(dev, no usb3 phy configured yet);
+return PTR_ERR(dwc-usb3_generic_phy);
+}
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+} else {
not required as we've used kzalloc for dwc.
+dwc-usb2_generic_phy = NULL;
+dwc-usb3_generic_phy = NULL;
+}
+
/* default to superspeed if no maximum_speed passed */
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Mon, Oct 14, 2013 at 01:21:29PM +0300, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Tue, Oct 15, 2013 at 10:57:16AM +0300, Roger Quadros wrote:
On 10/15/2013 08:31 AM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Monday 14 October 2013 03:51 PM, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(),
phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of
all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+if (dwc-usb2_phy)
+usb_phy_init(dwc-usb2_phy);
+if (dwc-usb3_phy)
+usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+/* Don't use USB PHY if generic PHY was found */
+dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 02:57 PM, Felipe Balbi wrote:
Hi,
On Mon, Oct 14, 2013 at 01:21:29PM +0300, Roger Quadros wrote:
+Vivek
On 10/14/2013 12:26 PM, Kishon Vijay Abraham I wrote:
Hi Roger,
On Friday 11 October 2013 08:39 PM, Roger Quadros wrote:
Hi,
On 09/02/2013 06:43 PM, Kishon Vijay Abraham I wrote:
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 49
drivers/usb/dwc3/core.h|7
4 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index cfc16dd..ad7ce83 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -3,6 +3,7 @@ config USB_DWC3
depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA
depends on EXTCON
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 428c29e..485d365 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
How about adding
+ if (dwc-usb2_phy)
+ usb_phy_init(dwc-usb2_phy);
+ if (dwc-usb3_phy)
+ usb_phy_init(dwc-usb3_phy);
Thankfully that usb_phy_init will check if phy is NULL.
both usb phy and generic phy shouldn't be present together.
ok.
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
here as well
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK (16 - 1)
@@ -427,6 +438,23 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ if (of_property_read_bool(node, phys) || pdata-has_phy) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
better to add
+ /* Don't use USB PHY if generic PHY was found */
+ dwc-usb2_phy = dwc-usb3_phy = NULL;
ok.
+ } else {
not required as we've used kzalloc for dwc.
+ dwc-usb2_generic_phy = NULL;
+ dwc-usb3_generic_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -450,6 +478,11 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-usb2_phy)
usb_phy_set_suspend(dwc-usb2_phy, 0);
if (dwc-usb3_phy)
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+
[PATCH] USB: OHCI: Only use ohci_driver_overrides if they are defined
Overrides are optional and many drivers pass NULL, in this case don't process the overrides so we don't deference a NULL pointer. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/usb/host/ohci-hcd.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 21d937a..e26abd5 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1161,6 +1161,9 @@ void ohci_init_driver(struct hc_driver *drv, /* Copy the generic table to drv and then apply the overrides */ *drv = ohci_hc_driver; + if (!over) + return; + drv-product_desc = over-product_desc; drv-hcd_priv_size += over-extra_priv_size; if (over-reset) -- 1.7.2.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] usb: serial: option: blacklist Olivetti Olicard200
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 80a7104..d7c10d6 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1257,7 +1257,9 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD145) },
- { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200),
+ .driver_info = (kernel_ulong_t)net_intf6_blacklist
+ },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA
450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung
GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] net: qmi_wwan: Olivetti Olicard 200 support
This is a QMI device, manufactured by TCT Mobile Phones.
A companion patch blacklisting this device's QMI interface in the option.c
driver has been sent.
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3d6aaf7..818ce90 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -714,6 +714,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
+ {QMI_FIXED_INTF(0x0b3c, 0xc005, 6)},/* Olivetti Olicard 200 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
/* 4. Gobi 1000 devices */
--
1.8.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/7] USB: OHCI: Properly handle OHCI controller suspend
From: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of OHCI was not properly
handled in ochi_suspend()routine. Alan Stern
suggested, properly handle OHCI suspend scenario.
This does generic proper handling of suspend
scenario to all OHCI SOC.
V1-V2:
- No change.
Due to build failure on ep93xx reverted this patch. This patch is
needed as Alan mentioned, it is having common ohci suspend features
w/o this following patches(still in usb-next) are not useful.
Commit id 10abfa13[PATCH 7/11] Properly handle ohci-omap suspend.
Commit id 39dbd7df[PATCH 8/11] Properly handle ohci-platform suspend.
Commit id 4ceaa893[PATCH 9/11] Properly handle ohci-pxa suspend.
Commit id f3c60599[PATCH 10/11] Properly handle ohci-sm501 suspend.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-hcd.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 8ada13f..310bcfe 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1036,6 +1036,7 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
unsigned long flags;
+ int rc = 0;
/* Disable irq emission and mark HW unaccessible. Use
* the spinlock to properly synchronize with possible pending
@@ -1048,7 +1049,13 @@ int ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
spin_unlock_irqrestore (ohci-lock, flags);
- return 0;
+ synchronize_irq(hcd-irq);
+
+ if (do_wakeup HCD_WAKEUP_PENDING(hcd)) {
+ ohci_resume(hcd, false);
+ rc = -EBUSY;
+ }
+ return rc;
}
EXPORT_SYMBOL_GPL(ohci_suspend);
--
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 V2 2/7] USB: OHCI: Properly handle ohci-at91 suspend
From: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of ohci-at91 glue was not properly handled
as it was not suspending generic part of ohci controller. Alan Stern
suggested, properly handle ohci-at91 suspend scenario.
Calling explicitly the ohci_suspend() routine in ohci_hcd_at91_drv_suspend()
will ensure proper handling of suspend scenario. This task is sugested
by Alan Stern.
V1-V2:
Due to version mismatch and build failure on ep93xx reverted this patch.
This is a proper patch for ohci-at91 suspend as Alan Stern mentioned.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-at91.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 476b5a5..f2d8403 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -636,8 +636,14 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
- if (device_may_wakeup(pdev-dev))
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
+ if (do_wakeup)
enable_irq_wake(hcd-irq);
/*
@@ -658,7 +664,7 @@ ohci_hcd_at91_drv_suspend(struct platform_device *pdev,
pm_message_t mesg)
at91_stop_clock();
}
- return 0;
+ return ret;
}
static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
--
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 V2 4/7] USB: OHCI: Properly handle ohci-da8xx suspend
From: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of ohci-da8xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-da8xx suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_da8xx_suspend() will ensure proper
handling of suspend scenario.
V1-V2:
-No change.
Due to the build failure on ep93xx reverted this patch.
This patch is needed as Alan Stern suggestion.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-da8xx.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index 9be59f1..f8238a4 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -406,19 +406,26 @@ static int ohci_hcd_da8xx_drv_remove(struct
platform_device *dev)
}
#ifdef CONFIG_PM
-static int ohci_da8xx_suspend(struct platform_device *dev, pm_message_t
message)
+static int ohci_da8xx_suspend(struct platform_device *pdev,
+ pm_message_t message)
{
- struct usb_hcd *hcd= platform_get_drvdata(dev);
+ struct usb_hcd *hcd= platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ booldo_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
ohci_da8xx_clock(0);
hcd-state = HC_STATE_SUSPENDED;
- dev-dev.power.power_state = PMSG_SUSPEND;
- return 0;
+
+ return ret;
}
static int ohci_da8xx_resume(struct platform_device *dev)
--
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 V2 3/7] USB: OHCI: Properly handle ohci-s3c2410 suspend
From: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of ohci-s3c2410 glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-s3c2410 suspend scenario.
Calling explicitly the ohci_suspend()
routine in ohci_hcd_s3c2410_drv_suspend() will ensure
proper handling of suspend scenario.
V1-V2:
-No changes.
Due to the build failure on ep93xx reverted this patch.
This patch is needed as Alan Stern suggestion.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-s3c2410.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index be3429e..b5bf9b7 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -426,28 +426,15 @@ static int ohci_hcd_s3c2410_drv_remove(struct
platform_device *pdev)
static int ohci_hcd_s3c2410_drv_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
- struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
- unsigned long flags;
+ bool do_wakeup = device_may_wakeup(dev);
int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(ohci-lock, flags);
- if (ohci-rh_state != OHCI_RH_SUSPENDED) {
- rc = -EINVAL;
- goto bail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
s3c2410_stop_hc(pdev);
-bail:
- spin_unlock_irqrestore(ohci-lock, flags);
return rc;
}
--
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 V2 5/7] USB: OHCI: Properly handle ohci-ep93xx suspend
From: Majunath Goudar manju.gou...@lge.com
Suspend scenario in case of ohci-ep93xx glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-ep93xx suspend scenario.
Calling explicitly the ohci_suspend() routine in
ohci_hcd_ep93xx_drv_suspend() will ensure proper handling of
suspend scenario.
Signed-off-by: Manjunath Goudar manju.gou...@lge.com
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
V1-V2:
-Fixed Olof Johansson reported build error:
drivers/usb/host/ohci-ep93xx.c: In function 'ohci_hcd_ep93xx_drv_suspend':
drivers/usb/host/ohci-ep93xx.c:126:2: error: implicit declaration of
function 'ep93xx_stop_hc'
---
drivers/usb/host/ohci-ep93xx.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index 492f681..77ebdc8 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -112,12 +112,15 @@ static int ohci_hcd_ep93xx_drv_suspend(struct
platform_device *pdev, pm_message_
{
struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
-
- clk_disable(usb_host_clock);
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
return 0;
}
--
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
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ break;
+ }
[PATCH V2 7/7] USB: OHCI: Properly handle ohci-spear suspend
From: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of ohci-spear glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-spear suspend scenario.
Calling explicitly the ohci_suspend() routine in
spear_ohci_hcd_drv_suspend() will ensure proper
handling of suspend scenario.
V1-V2:
-No changes.
Due to the build failure on ep93xx reverted this patch.
This patch is needed as Alan Stern suggestion.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-spear.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
index 31ff3fc..41148f8 100644
--- a/drivers/usb/host/ohci-spear.c
+++ b/drivers/usb/host/ohci-spear.c
@@ -130,20 +130,26 @@ static int spear_ohci_hcd_drv_remove(struct
platform_device *pdev)
}
#if defined(CONFIG_PM)
-static int spear_ohci_hcd_drv_suspend(struct platform_device *dev,
+static int spear_ohci_hcd_drv_suspend(struct platform_device *pdev,
pm_message_t message)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct spear_ohci *sohci_p = to_spear_ohci(hcd);
+ bool do_wakeup = device_may_wakeup(pdev-dev);
+ int ret;
if (time_before(jiffies, ohci-next_statechange))
msleep(5);
ohci-next_statechange = jiffies;
+ ret = ohci_suspend(hcd, do_wakeup);
+ if (ret)
+ return ret;
+
clk_disable_unprepare(sohci_p-clk);
- return 0;
+ return ret;
}
static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
--
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 V2 6/7] USB: OHCI: Properly handle ohci-exynos suspend
From: Manjunath Goudar manjunath.gou...@linaro.org
Suspend scenario in case of ohci-exynos glue was not
properly handled as it was not suspending generic part
of ohci controller. Alan Stern suggested, properly handle
ohci-exynos suspend scenario.
Calling explicitly the ohci_suspend() routine in
exynos_ohci_suspend() will ensure proper handling of suspend
scenario.
V1-V2:
-No changes.
Due to the build failure on ep93xx reverted this patch.
This patch is needed as Alan Stern suggestion.
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Signed-off-by: Manjunath Goudar csmanjuvi...@gmail.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Arnd Bergmann a...@arndb.de
Cc: Greg KH g...@kroah.com
Cc: linux-usb@vger.kernel.org
---
drivers/usb/host/ohci-exynos.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index a87baed..aa50e18 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -192,24 +192,15 @@ static int exynos_ohci_suspend(struct device *dev)
struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
struct ohci_hcd *ohci = hcd_to_ohci(hcd);
struct platform_device *pdev = to_platform_device(dev);
+ bool do_wakeup = device_may_wakeup(dev);
unsigned long flags;
int rc = 0;
- /*
-* Root hub was already suspended. Disable irq emission and
-* mark HW unaccessible, bail out if RH has been resumed. Use
-* the spinlock to properly synchronize with possible pending
-* RH suspend or resume activity.
-*/
- spin_lock_irqsave(ohci-lock, flags);
- if (ohci-rh_state != OHCI_RH_SUSPENDED
- ohci-rh_state != OHCI_RH_HALTED) {
- rc = -EINVAL;
- goto fail;
- }
-
- clear_bit(HCD_FLAG_HW_ACCESSIBLE, hcd-flags);
+ rc = ohci_suspend(hcd, do_wakeup);
+ if (rc)
+ return rc;
+ spin_lock_irqsave(ohci-lock, flags);
if (exynos_ohci-otg)
exynos_ohci-otg-set_host(exynos_ohci-otg, hcd-self);
@@ -217,7 +208,6 @@ static int exynos_ohci_suspend(struct device *dev)
clk_disable_unprepare(exynos_ohci-clk);
-fail:
spin_unlock_irqrestore(ohci-lock, flags);
return rc;
--
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
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ break;
+
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like
only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On 10/15/2013 04:56 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like
only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed is
super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email it
seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
Re: [PATCH 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
On Tue, Oct 15, 2013 at 05:03:50PM +0300, Roger Quadros wrote:
On 10/15/2013 04:56 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 04:48:51PM +0300, Roger Quadros wrote:
On 10/15/2013 04:19 PM, Felipe Balbi wrote:
Hi,
On Tue, Oct 15, 2013 at 03:10:42PM +0300, Roger Quadros wrote:
@@ -665,6 +669,9 @@ struct dwc3 {
struct usb_phy *usb2_phy;
struct usb_phy *usb3_phy;
+ struct phy *usb2_generic_phy;
+ struct phy *usb3_generic_phy;
+
void __iomem*regs;
size_t regs_size;
Do you have any suggestions on how to get only individual PHYs? like
only
usb2phy or usb3phy?
My earlier understanding was that both PHYs are needed only if .speed
is super-speed
and only usb2phy is needed for high-speed. But as per Vivek's email
it seems
Samsung's exynos5 SoC doesn't need usb2phy for super-speed.
So to keeps things flexible, I can propose the following approach
- if speed == 'high-speed' usb2phy must be present. usb3phy will be
ignored if supplied.
- if speed == 'super-speed' usb3phy must be present and usb2phy is
optional but must be
initialized if supplied.
- if speed is not specified, we default to 'super-speed'.
Felipe, does this address the issue you were facing with OMAP5?
on OMAP5 we cannot skip USB3 PHY initialization. But then it becomes a
question of supporting a test feature (in OMAP5 case it would be cool to
force controller to lower speeds for testing) or coping with a broken
DTS.
I don't think we can protect ourselves from all possible broken
configurations of DTS.
I would vote for simplicity and maximum flexibility.
So IMO we should just depend on DTS to provide the phys that are
needed by the platform.
In the driver we initialize whatever PHY is provided and don't
complain if any or even all PHYs are missing.
considering that DTS is an ABI, I really think eventually we *will* have
broken DTBs burned into ROM and we will have to find ways to work with
those too. Same thing already happens today with ACPI tables.
If this is not good enough then could you please suggest an
alternative? Thanks.
The alternative would be to mandate nop xceiv for the missing PHY, but
that doesn't solve anything, really, as DTS authors might still forget
about the NOP xceiv and you can argue that forcing NOP xceiv would be a
SW configuration.
So, perhaps we go with the approach that all PHYs are optional, and
here's my original patch which makes USB3 PHY optional:
commit 979b84f96e4b7559b596b2933ae198aba267f260
Author: Felipe Balbi ba...@ti.com
Date: Sun Jun 30 18:39:23 2013 +0300
usb: dwc3: core: make USB3 PHY optional
If we want a port to work at any speed lower
than Superspeed, it makes no sense to even
initialize/power up the USB3 transceiver,
provided it won't be used.
We can use the oportunity to save some power
and leave the superspeed transceiver powered
off.
There is at least one such case which is
Texas Instruments' AM437x which has one
of its USB3 ports without a matching USB3
PHY (that port is hardwired to work on USB2
only).
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 74f9cf0..7a5ab93 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -387,16 +387,34 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 1);
+ break;
+ case USB_SPEED_HIGH:
+ case USB_SPEED_FULL:
+ case USB_SPEED_LOW:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
usb-phy, 0);
+ break;
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ switch (dwc-maximum_speed) {
+ case USB_SPEED_SUPER:
+ dwc-usb2_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB2);
+ dwc-usb3_phy = devm_usb_get_phy(dev,
USB_PHY_TYPE_USB3);
+ break;
+ case USB_SPEED_HIGH:
+
[RFC] Using UVC as a monitor
I'm pulling together code at the moment which I'll post for comment later in the week. What I want to do is combine the operations of 2 drivers to create a virtual monitor via UVC, uvcfbsource It involves configuring the UVC video-streaming capability of the USB Webcam Gadget to use a framebuffer as it's source. The SimpleFB driver currently in the kernel requires the framebuffer memory to be allocated by some other program/driver - so it seems a good choice for the framebuffer. Using the current capabilities of the USB webcam gadget, it seems for a simple solution all I need to do is have a userspace application which grabs the framebuffer data, wraps it into a videobuf2 format and inserts it into the queue. In this mode, the Monitor becomes any application capable of displaying streaming video - for that matter, if multiple instances of the userspace application are executed then you can have multiple monitors all displayed on the same computer. Purpose: I am working with a couple of ARM development boards, primarily the BeagleBoneBlack. Using a usb montor gadget, I can give my BBB a monitor without actually having to plug in a monitor. In simple mode, the framebuffer would be configured with a resolution of 720p and to store data in the YUV format so it matches one of the currently defined formats in the Webcam gadget. Beyond that though, I'd like to extend this to a smarter kernel driver which could: 1) Use the start streaming/stop streaming USB events to emulate hotplugging the monitor. 2) Allow for different resolutions to be supported and controlled by the remote computer[IE show different options, and allow the webcam viewer application to choose one of the streams] 3) Allow for the complete set of UVC supported YUV formats for frames 4) Switch from the video stream UVC encapsulation to the frame buffer stream Using UVC in this manner has the downside that full uncompressed frame data is being transmitted over USB - however UVC does provide a number of optional compression and encoding methods - so it's possible to improve performance if there is demand for it. It is also possible to use 'vendor defined' compression and encoding methods if those are not sufficient. Since UVC allows the gadget to advertise multiple capabilities - a device using the uvcfbsource driver could be used by any system supporting standard Webcams - Mac, Windows, Android, Linux, etc via the uncompressed format - while the compressed format can be used if the viewer application supports it. I wanted to check now to see if there is something I'm missing, or known projects already working on this sort of thing, before I start coding. My long term goal is to use the code developed for a fully functional uvcfbsink driver to create a uvcfbsource driver: ie an application which reverses the process and receives data from a uvc webcam and pushes it into a framebuffer. That would allow for creating an open source alternative to DisplayLink while avoiding any usage of their API and any potential patent issues. -Gary -- 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: serial: option: blacklist Olivetti Olicard200
On Tue, 2013-10-15 at 15:06 +0200, Enrico Mioso wrote:
Interface 6 of this device speaks QMI as per tests done by us.
Credits go to Antonella for providing the hardware.
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
Tested-by: Dan Williams d...@redhat.com
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 80a7104..d7c10d6 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1257,7 +1257,9 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD100) },
{ USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD145) },
- { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200) },
+ { USB_DEVICE(OLIVETTI_VENDOR_ID, OLIVETTI_PRODUCT_OLICARD200),
+ .driver_info = (kernel_ulong_t)net_intf6_blacklist
+ },
{ USB_DEVICE(CELOT_VENDOR_ID, CELOT_PRODUCT_CT680M) }, /* CT-650 CDMA
450 1xEVDO modem */
{ USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID,
SAMSUNG_PRODUCT_GT_B3730, USB_CLASS_CDC_DATA, 0x00, 0x00) }, /* Samsung
GT-B3730 LTE USB modem.*/
{ USB_DEVICE(YUGA_VENDOR_ID, YUGA_PRODUCT_CEM600) },
--
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] net: qmi_wwan: Olivetti Olicard 200 support
On Tue, 2013-10-15 at 15:06 +0200, Enrico Mioso wrote:
This is a QMI device, manufactured by TCT Mobile Phones.
A companion patch blacklisting this device's QMI interface in the option.c
driver has been sent.
Signed-off-by: Enrico Mioso mrkiko...@gmail.com
Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
Good find. For the record, mine has:
PX1522E16X 1 [Oct 15 2010 02:00:00]
ctl (1.4)
wds (1.8)
dms (1.3)
nas (1.2)
qos (1.2)
wms (1.1)
pds (1.4)
auth (1.0)
voice (1.0)
cat2 (1.1)
Tested-by: Dan Williams d...@redhat.com
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3d6aaf7..818ce90 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -714,6 +714,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
{QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
+ {QMI_FIXED_INTF(0x0b3c, 0xc005, 6)},/* Olivetti Olicard 200 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
/* 4. Gobi 1000 devices */
--
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: ohci: remove ep93xx bus glue platform driver
On Mon, 14 Oct 2013, Hartley Sweeten wrote: config USB_OHCI_HCD_PLATFORM tristate Generic OHCI driver for a platform device - default n + default y if ARCH_EP93XX Shouldn't we select USB_OHCI_HCD_PLATFORM, e.g. something like: config ARCH_EP93XX_USB tristate USB OHCI support default y select USB_OHCI_HCD_PLATFORM In arch/arm/mach-ep93xx/Kconfig rather than polluting drivers/usb/host/Kconfig with arch specific stuff? I wasn't sure where the best place to enable USB_OHCI_HCD_PLATFORM would be. Currently USB support on the EP93xx only needs USB_OHCI_HCD enabled, which is already enabled in the ep93xx_defconfig. I'm not sure if adding the config option above would create a problem where the user would need to enable USB_OHCI_HCD in drivers/usb then have to go back to the arch stuff to enable ARCH_EP93XX_USB. With the default y above they just have to enable USB_OHCI_HCD like they currently do. I'm hoping Alan can provide some feedback. In the past this sort of thing has been done in two different ways, depending on whether or not OHCI support was previously configurable. In cases where it was, we kept the old Kconfig entry and made it select USB_OHCI_HCD_PLATFORM, but added a notice that the entry was now deprecated. For example, in drivers/usb/host/Kconfig see the entry for USB_OHCI_ATH79. In cases where support was always present (i.e., not configurable), we added an entry for USB_OHCI_HCD_PLATFORM to the platform's defconfig file. For example, see arch/arm/configs/marzen_defconfig. This is probably what you want to do. 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: ohci: remove ep93xx bus glue platform driver
On Mon, 14 Oct 2013, H Hartley Sweeten wrote:
Convert ep93xx to use the OHCI platform driver and remove the
ohci-ep93xx bus glue driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Ryan Mallon rmal...@gmail.com
...
@@ -297,22 +298,58 @@ static struct platform_device ep93xx_rtc_device = {
.resource = ep93xx_rtc_resource,
};
+/*
+ * EP93xx OHCI USB Host
+ */
+
+static struct clk *ep93xx_ohci_host_clock;
+
+static int ep93xx_ohci_power_on(struct platform_device *pdev)
+{
+ if (!ep93xx_ohci_host_clock) {
+ ep93xx_ohci_host_clock = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(ep93xx_ohci_host_clock))
+ return PTR_ERR(ep93xx_ohci_host_clock);
+ }
+
+ clk_enable(ep93xx_ohci_host_clock);
+
+ return 0;
+}
+
+static void ep93xx_ohci_power_off(struct platform_device *pdev)
+{
+ clk_disable(ep93xx_ohci_host_clock);
+}
+
+static void ep93xx_ohci_power_suspend(struct platform_device *pdev)
+{
+ ep93xx_ohci_power_off(pdev);
+}
+
+static struct usb_ohci_pdata ep93xx_ohci_pdata = {
+ .power_on = ep93xx_ohci_power_on,
+ .power_off = ep93xx_ohci_power_off,
+ .power_suspend = ep93xx_ohci_power_suspend,
+};
You don't need to have a separate ep93xx_ohci_power_suspend() routine.
Just initialize the method entry for .power_suspend to point to
ep93xx_ohci_power_off.
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
[PATCH] Input: usbtouchscreen - separate report and transmit buffer size handling
This patch supports the separate handling of the USB transfer buffer length
and the length of the buffer used for multi packet support. The USB transfer
size can now be explicitly configured via the device_info record. Otherwise
it defaults to the configured report packet size as before. For devices
supporting multiple report or diagnostic packets, the USB transfer size is
now reduced to the USB endpoints wMaxPacketSize if not explicitly set.
This fixes an issue where event reporting can be delayed for an arbitrary
time for multi packet devices. For instance the report size for eGalax devices
is defined to the 16 byte maximum diagnostic packet size as opposed to the 5
byte report packet size. In case the driver requests 16 byte from the USB
interrupt endpoint, the USB host controller driver needs to split up the
request into 2 accesses according to the endpoints wMaxPacketSize of 8 byte.
When the first transfer is answered by the eGalax device with not less than
the full 8 byte requested, the host controller has got no way of knowing
whether the touch controller has got additional data queued and will issue
the second transfer. If per example a liftoff event finishes at such a
wMaxPacketSize boundary, the data will not be available to the usbtouch driver
until a further event is triggered and transfered to the host. From user
perspective the BTN_TOUCH release event in this case is stuck until the next
touch down event.
Signed-off-by: Christian Engelmayer christian.engelma...@frequentis.com
---
drivers/input/touchscreen/usbtouchscreen.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/usbtouchscreen.c
b/drivers/input/touchscreen/usbtouchscreen.c
index 721fdb3..aa1f6a7 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -76,6 +76,7 @@ struct usbtouch_device_info {
int min_yc, max_yc;
int min_press, max_press;
int rept_size;
+ int xmit_size;
/*
* Always service the USB devices irq not just when the input device is
@@ -1523,7 +1524,7 @@ static int usbtouch_reset_resume(struct usb_interface
*intf)
static void usbtouch_free_buffers(struct usb_device *udev,
struct usbtouch_usb *usbtouch)
{
- usb_free_coherent(udev, usbtouch-type-rept_size,
+ usb_free_coherent(udev, usbtouch-type-xmit_size,
usbtouch-data, usbtouch-data_dma);
kfree(usbtouch-buffer);
}
@@ -1567,8 +1568,15 @@ static int usbtouch_probe(struct usb_interface *intf,
usbtouch-type = type;
if (!type-process_pkt)
type-process_pkt = usbtouch_process_pkt;
+ if (!type-xmit_size) {
+ if ((type-get_pkt_len)
+ (type-rept_size le16_to_cpu(endpoint-wMaxPacketSize)))
+ type-xmit_size = le16_to_cpu(endpoint-wMaxPacketSize);
+ else
+ type-xmit_size = type-rept_size;
+ }
- usbtouch-data = usb_alloc_coherent(udev, type-rept_size,
+ usbtouch-data = usb_alloc_coherent(udev, type-xmit_size,
GFP_KERNEL, usbtouch-data_dma);
if (!usbtouch-data)
goto out_free;
@@ -1628,12 +1636,12 @@ static int usbtouch_probe(struct usb_interface *intf,
if (usb_endpoint_type(endpoint) == USB_ENDPOINT_XFER_INT)
usb_fill_int_urb(usbtouch-irq, udev,
usb_rcvintpipe(udev, endpoint-bEndpointAddress),
-usbtouch-data, type-rept_size,
+usbtouch-data, type-xmit_size,
usbtouch_irq, usbtouch, endpoint-bInterval);
else
usb_fill_bulk_urb(usbtouch-irq, udev,
usb_rcvbulkpipe(udev, endpoint-bEndpointAddress),
-usbtouch-data, type-rept_size,
+usbtouch-data, type-xmit_size,
usbtouch_irq, usbtouch);
usbtouch-irq-dev = udev;
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] xhci: fix usb3 streams
On Mon, 14 Oct 2013, Gerd Hoffmann wrote: Gerd, Hans, any objections to this updated patch? The warning is fixed with it. The patch probably still needs to address the case where the ring expansion fails because we can't insert the new segments into the radix tree. The patch should probably allocate the segments, attempt to add them to the radix tree, and fail without modifying the link TRBs of the ring. I'd have to look more deeply into the code to see what exactly should be done there. I would like that issue fixed before I merge these patches, so if you want to take a stab at fixing it, please do. Sarah Sharp Sarah, how did you manage to send an email with the From: line set to Gerd's name and address? 88 xhci maintains a radix tree for each stream endpoint because it must be able to map a trb address to the stream ring. Each ring segment must be added to the ring for this to work. Currently xhci sticks only the first segment of each stream ring into the radix tree. Result is that things work initially, but as soon as the first segment is full xhci can't map the trb address from the completion event to the stream ring any more - BOOM. You'll find this message in the logs: ERROR Transfer event for disabled endpoint or incorrect stream ring This patch adds a helper function to update the radix tree, and a function to remove ring segments from the tree. Both functions loop over the segment list and handles all segments instead of just the first. There may be a simpler approach to this problem. When using a new ring segment, keep the first TRB entry in reserve. Don't put a normal TRB in there, instead leave it as a no-op entry containing a pointer to the stream ring. (Make the prior Link TRB point to the second entry in the new segment instead of the first.) Then you won't have to add to or remove anything from the radix tree. 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: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Mon, Oct 14, 2013 at 05:24:10PM -0700, Sarah Sharp wrote: The following changes since commit f4c19b8e165cff1a6607c21f8809441d61cab7ec: USB: serial: option: add support for Inovia SEW858 device (2013-10-11 16:17:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-10-14 for you to fetch changes up to 0ef7a36cb604c65ca1c84d3dd9a9363498ed028a: xhci: correct the usage of USB_CTRL_SET_TIMEOUT (2013-10-14 17:12:10 -0700) xHCI bug fixes for 3.12 (Link PM and misc) Hi Greg, I hope you're recovered from your trip. :) Thanks, just in time to leave again in 4 days... Here's five patches for 3.12. The first four patches address issues with USB 2.0 Link PM that were causing distros to report that attaching a USB 3.0 device to a USB 2.0 port makes the device not enumerate on Intel Haswell ULT systems with USB 2.0 hardware-enabled Link PM. This issue has been reproduced under both Ubuntu and ChromeOS. The patches are marked for stable. The last patch is a simple fix to use jiffies instead of msec on a completion timeout. The issue that caused the timeout to expire was fixed in commit ec7e43e2d98173483866fe2e4e690143626b659c xhci: Ensure a command structure points to the correct trb on the command ring. The driver wouldn't normally hit this timeout if the host and driver were functioning correctly, and I don't have any reports of other systems that hit this timeout. This makes it low-priority, so I'm not marking it for stable. All of these are for issues that do not look like regressions to me, but rather, long-standing bugs. While I'm all about fixing bugs and problems, none of these seem like urgent fixes for things that have been recently broken. So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. I can take these as patches for my usb-next branch by hand if you want, or I can take a new pull request for that branch. 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 05/11] USB: OHCI: Properly handle ohci-ep93xx suspend
On Tue, Oct 15, 2013 at 10:34:53AM +0530, manju goudar wrote: Alan, I am very sorry for this mistake. I will fix this issue and sending back series. Greg, I am really sorry :(( Next time I will not make this kind of mistake. If any issue reported related to my patches I will fix it and send back to you. Now I am using my personal id to support my patches. Thanks for continuing to work on this, that's great to hear. Please test your patches on all arches that you are modifying, simple build bugs shouldn't happen. 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 V2 1/7] USB: OHCI: Properly handle OHCI controller suspend
On Tue, Oct 15, 2013 at 06:49:56PM +0530, Majunath Goudar wrote: From: Manjunath Goudar manjunath.gou...@linaro.org Suspend scenario in case of OHCI was not properly handled in ochi_suspend()routine. Alan Stern suggested, properly handle OHCI suspend scenario. This does generic proper handling of suspend scenario to all OHCI SOC. V1-V2: - No change. Due to build failure on ep93xx reverted this patch. This patch is needed as Alan mentioned, it is having common ohci suspend features w/o this following patches(still in usb-next) are not useful. Commit id 10abfa13[PATCH 7/11] Properly handle ohci-omap suspend. Commit id 39dbd7df[PATCH 8/11] Properly handle ohci-platform suspend. Commit id 4ceaa893[PATCH 9/11] Properly handle ohci-pxa suspend. Commit id f3c60599[PATCH 10/11] Properly handle ohci-sm501 suspend. Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org This is an invalid email address, please don't continue to use it, I'm tired of seeing the bounce response :( And v2 for this series? Really? I seem to recall many different versions of the series, so we should be on a much higher number by now... How have you tested these patches? 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 V2 5/7] USB: OHCI: Properly handle ohci-ep93xx suspend
On Tue, 15 Oct 2013, Majunath Goudar wrote: From: Majunath Goudar manju.gou...@lge.com Suspend scenario in case of ohci-ep93xx glue was not properly handled as it was not suspending generic part of ohci controller. Alan Stern suggested, properly handle ohci-ep93xx suspend scenario. Calling explicitly the ohci_suspend() routine in ohci_hcd_ep93xx_drv_suspend() will ensure proper handling of suspend scenario. This patch isn't needed any more. H Hartley Sweeten has just submitted a patch to remove ohci-ep93xx entirely. 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: ohci: remove ep93xx bus glue platform driver
Hi,
On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
hartl...@visionengravers.com wrote:
Convert ep93xx to use the OHCI platform driver and remove the
ohci-ep93xx bus glue driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Ryan Mallon rmal...@gmail.com
---
arch/arm/mach-ep93xx/clock.c | 2 +-
arch/arm/mach-ep93xx/core.c| 45 +-
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/ohci-ep93xx.c | 184
-
drivers/usb/host/ohci-hcd.c| 18
5 files changed, 43 insertions(+), 208 deletions(-)
delete mode 100644 drivers/usb/host/ohci-ep93xx.c
diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
index c95dbce..39ef3b6 100644
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c
@@ -212,7 +212,7 @@ static struct clk_lookup clocks[] = {
INIT_CK(NULL, hclk, clk_h),
INIT_CK(NULL, apb_pclk, clk_p),
INIT_CK(NULL, pll2, clk_pll2),
- INIT_CK(ep93xx-ohci, NULL, clk_usb_host),
+ INIT_CK(ohci-platform,NULL, clk_usb_host),
INIT_CK(ep93xx-keypad,NULL, clk_keypad),
INIT_CK(ep93xx-fb,NULL, clk_video),
INIT_CK(ep93xx-spi.0, NULL, clk_spi),
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 3f12b88..5489824 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -36,6 +36,7 @@
#include linux/export.h
#include linux/irqchip/arm-vic.h
#include linux/reboot.h
+#include linux/usb/ohci_pdriver.h
#include mach/hardware.h
#include linux/platform_data/video-ep93xx.h
@@ -297,22 +298,58 @@ static struct platform_device ep93xx_rtc_device = {
.resource = ep93xx_rtc_resource,
};
+/*
+ * EP93xx OHCI USB Host
+ */
+
+static struct clk *ep93xx_ohci_host_clock;
+
+static int ep93xx_ohci_power_on(struct platform_device *pdev)
+{
+ if (!ep93xx_ohci_host_clock) {
+ ep93xx_ohci_host_clock = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(ep93xx_ohci_host_clock))
+ return PTR_ERR(ep93xx_ohci_host_clock);
+ }
+
+ clk_enable(ep93xx_ohci_host_clock);
+
+ return 0;
+}
+
+static void ep93xx_ohci_power_off(struct platform_device *pdev)
+{
+ clk_disable(ep93xx_ohci_host_clock);
+}
+
+static void ep93xx_ohci_power_suspend(struct platform_device *pdev)
+{
+ ep93xx_ohci_power_off(pdev);
+}
+
+static struct usb_ohci_pdata ep93xx_ohci_pdata = {
+ .power_on = ep93xx_ohci_power_on,
+ .power_off = ep93xx_ohci_power_off,
+ .power_suspend = ep93xx_ohci_power_suspend,
+};
This is definitely not a show-stopper in any way, but since this is
just standard clock management, could you even move these clock ops
into the driver? Are any other platforms already doing similar things
so you could remove code from their platform that way as well, per
chance?
-Olof
--
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-storage: scsiglue: Changing the command result
On Tue, 15 Oct 2013, Ming Lei wrote: On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve vannapu...@nvidia.com wrote: Hi, There was a recent commit in mainline for the scsi devices which do not respond properly to medium access command: commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8 [SCSI] Handle disk devices which can not process medium access commands We have experienced several devices which fail in a fashion we do not currently handle gracefully in SCSI. After a failure these devices will respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.) but any command accessing the storage medium will time out. I came across a USB drive which showed similar problem and what I see is usb storage is still not able to cope with such devices properly. The control flow downwards is like: scsi_times_out -- Setting cmd-result as DID_TIME_OUT scsi_error_handler scsi_unjam_host scsi_eh_abort_cmds command_abort(sets US_FLIDX_TIMED_OUT for us-dflags calls stop_transport, and waits for)usb_stor_control_thread (which is waiting for transport call to return inside usb_stor_invoke_transport) both usb_stor_control_thread and usb_stor_invoke_transport check for us-dflags timed_out bit and set the result as DID_ABORT and signal completion for command_abort to complete .. sd_eh_action checks for cmd-result and finds out that it's DID_ABORT rather than DID_TIME_OUT. This patch updates the command result to be TIME_OUT explicitly before returning from command_abort in scsiglue.c. I would like to know if this patch can work out for such USB Storage devices? What would be the better way to do the same? Looks your diagnose is correct, and patch should be doable, the only side effect is that previous returned DID_ABORT in srb-result is replaced with DID_TIME_OUT now. Another way is to implement .eh_timed_out callback to return different error for the two failure, but looks not a big deal. Instead of overriding the result code, a better way to do this would simply be to change the places where srb-result is currently set to DID_ABORT 16. Just make it DID_TIME_OUT 16 instead. 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: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On Tue, 15 Oct 2013, Marcus Overhagen wrote: Hello, I made a change to the rts5139 driver that got included in kernel 3.11 (see second patch at end of this email), but Lutz Vieweg reported that the patch causes issues for him, because the driver falsely detects that the SD card is no longer present after transfer of a few 100 MBs. Why does the driver make this mistake? I do not have this issue with xhci. He is using ehci. The USB endpoint specifies a transfer interval of 10. The rts5139 Does the device connect at high speed (480 Mb/s)? driver uses the interrupt transfer to infrequently poll for card presence, but doesn't queue multiple urbs for periodic transfers. The issue seems to be a difference in how early the (first) interrupt transfer is scheduled by xhci and ehci when the interval specified in the urb is not 1. With ehci it seems to be delayed when the interval is not 1. With xhci you get warning messages in syslog if interval is not 10. My USB knowledge is too limited to properly fix this in xhci or ehci hcd. What needs to be fixed? It sounds like xhci-hcd and ehci-hcd are working correctly and the problem is in the rts5139 driver. Can somebody help me? what is the correct fix for this problem? It is possible that the following patch, that increases the timeout the driver waits for the interrupt transfer, will fix the problem with ehci. However, I expect that the transfer is slightly slower then with ehci, compared to kernel 3.10. bInterval = 10 means the polling period is 64 ms (for a high-speed device). So a timeout of 100 ms should be adequate -- provided the device always sends data over the interrupt endpoint without any further delay. 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] net: qmi_wwan: Olivetti Olicard 200 support
:) I'm very happy you got it working.
The firmware of our device seems so fragile still - and several QMI calls can
bring it to a crashing state, especially when asking a network scan to the NAS
service.
On Tue, 15 Oct 2013, Dan Williams wrote:
==Date: Tue, 15 Oct 2013 09:49:57 -0500
==From: Dan Williams d...@redhat.com
==To: Enrico Mioso mrkiko...@gmail.com
==Cc: gre...@linuxfoundation.org, da...@davemloft.net, bj...@mork.no,
==christian.schmi...@gemalto.com, linux-usb@vger.kernel.org,
==net...@vger.kernel.org, linux-ker...@vger.kernel.org,
==Antonella Pellizzari anto.pellizzar...@gmail.com
==Subject: Re: [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
==
==On Tue, 2013-10-15 at 15:06 +0200, Enrico Mioso wrote:
== This is a QMI device, manufactured by TCT Mobile Phones.
== A companion patch blacklisting this device's QMI interface in the option.c
== driver has been sent.
==
== Signed-off-by: Enrico Mioso mrkiko...@gmail.com
== Signed-off-by: Antonella Pellizzari anto.pellizzar...@gmail.com
==
==Good find. For the record, mine has:
==
==PX1522E16X 1 [Oct 15 2010 02:00:00]
==
== ctl (1.4)
== wds (1.8)
== dms (1.3)
== nas (1.2)
== qos (1.2)
== wms (1.1)
== pds (1.4)
== auth (1.0)
== voice (1.0)
== cat2 (1.1)
==
==Tested-by: Dan Williams d...@redhat.com
==
== diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
== index 3d6aaf7..818ce90 100644
== --- a/drivers/net/usb/qmi_wwan.c
== +++ b/drivers/net/usb/qmi_wwan.c
== @@ -714,6 +714,7 @@ static const struct usb_device_id products[] = {
== {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
== {QMI_FIXED_INTF(0x2357, 0x9000, 4)},/* TP-LINK MA260 */
== {QMI_FIXED_INTF(0x1bc7, 0x1200, 5)},/* Telit LE920 */
== + {QMI_FIXED_INTF(0x0b3c, 0xc005, 6)},/* Olivetti Olicard 200 */
== {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
==
== /* 4. Gobi 1000 devices */
==
==
==
--
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
musb: remaining fixes for OTG mode
Hi Felipe, this small series includes the remaining fixes to the OTG mode tested on am335x-evm. What works with these: - modprobe musb_dsps; plug device; no crash (#1) - plug a host or device into the OTG port and they will be recognized and served. Also after unplug :) (mainline #4) What still does not work: - configure musb as HOST or DEVICE only and try to plug something. Host does not work at all due to the missing timer (for the session bit) and with the timer it isn't really better. In DEVICE-only mode it seems to work a little better but if you plug a host instead things will end badly. So I *think* we can live without this. If it is OTG, run as OTG and don't try something fancy. I could add a warning if you want :) Sebastian -- 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-storage: scsiglue: Changing the command result
Hi Alan, This issue seems more related to the devices using SCSI protocol and the changes otherwise will be at more places giving the same end result. I think as the comment says over the command_abort function, intentional result change should only happen in case of timeout. Regards, Vishal -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Tuesday, October 15, 2013 5:55 PM To: Ming Lei Cc: Vishal Annapurve; Linux Kernel Mailing List; linux-usb Subject: Re: [PATCH] usb-storage: scsiglue: Changing the command result On Tue, 15 Oct 2013, Ming Lei wrote: On Thu, Sep 26, 2013 at 7:35 PM, Vishal Annapurve vannapu...@nvidia.com wrote: Hi, There was a recent commit in mainline for the scsi devices which do not respond properly to medium access command: commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8 [SCSI] Handle disk devices which can not process medium access commands We have experienced several devices which fail in a fashion we do not currently handle gracefully in SCSI. After a failure these devices will respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.) but any command accessing the storage medium will time out. I came across a USB drive which showed similar problem and what I see is usb storage is still not able to cope with such devices properly. The control flow downwards is like: scsi_times_out -- Setting cmd-result as DID_TIME_OUT scsi_error_handler scsi_unjam_host scsi_eh_abort_cmds command_abort(sets US_FLIDX_TIMED_OUT for us-dflags calls stop_transport, and waits for)usb_stor_control_thread (which is waiting for transport call to return inside usb_stor_invoke_transport) both usb_stor_control_thread and usb_stor_invoke_transport check for us-dflags timed_out bit and set the result as DID_ABORT and signal completion for command_abort to complete .. sd_eh_action checks for cmd-result and finds out that it's DID_ABORT rather than DID_TIME_OUT. This patch updates the command result to be TIME_OUT explicitly before returning from command_abort in scsiglue.c. I would like to know if this patch can work out for such USB Storage devices? What would be the better way to do the same? Looks your diagnose is correct, and patch should be doable, the only side effect is that previous returned DID_ABORT in srb-result is replaced with DID_TIME_OUT now. Another way is to implement .eh_timed_out callback to return different error for the two failure, but looks not a big deal. Instead of overriding the result code, a better way to do this would simply be to change the places where srb-result is currently set to DID_ABORT 16. Just make it DID_TIME_OUT 16 instead. 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
[PATCH 1/5] usb: musb: call musb_start() only once in OTG mode
In commit 001dd84 (usb: musb: start musb on the udc side, too) it was
ensured that the state engine is started also in OTG mode after a
removal / insertion of the gadget.
Unfortunately this change also introduced a bug: If the device is
configured as OTG and it connected with a remote host _without_ loading
a gadget then we bug() later (because musb-otg-gadget is not
initialized).
Initially I assumed it might be nice to have the host part of musb in
OTG mode working without having a gadget loaded. This bug and fact that
it wasn't working like this before the host/gadget split made me realize
that this was a silly idea.
This patch now introduces back the old behavior where in OTG mode the
host mode is only working after the gadget has been loaded.
Cc: sta...@vger.kernel.org # v3.11
Cc: Daniel Mack zon...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_virthub.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index d1d6b83..9af6bba 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -220,6 +220,23 @@ int musb_hub_status_data(struct usb_hcd *hcd, char *buf)
return retval;
}
+static int musb_has_gadget(struct musb *musb)
+{
+ /*
+* In host-only mode we start a connection right away. In OTG mode
+* we have to wait until we loaded a gadget. We don't really need a
+* gadget if we operate as a host but we should not start a session
+* as a device without a gadget or else we explode.
+*/
+#ifdef CONFIG_USB_MUSB_HOST
+ return 1;
+#else
+ if (musb-port_mode == MUSB_PORT_MODE_HOST)
+ return 1;
+ return musb-g.dev.driver != NULL;
+#endif
+}
+
int musb_hub_control(
struct usb_hcd *hcd,
u16 typeReq,
@@ -362,7 +379,7 @@ int musb_hub_control(
* initialization logic, e.g. for OTG, or change any
* logic relating to VBUS power-up.
*/
- if (!hcd-self.is_b_host)
+ if (!hcd-self.is_b_host musb_has_gadget(musb))
musb_start(musb);
break;
case USB_PORT_FEAT_RESET:
--
1.8.4.rc3
--
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/5] usb: musb: dsps: remove declartion for dsps_musb_try_idle()
This patch moves dsps_musb_try_idle() before dsps_musb_enable() so the
declaration (of dsps_musb_try_idle() can be removed.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_dsps.c | 75 ++--
1 file changed, 37 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 35190eb..97d1f13 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -121,7 +121,43 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
};
-static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout);
+static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
+{
+ struct device *dev = musb-controller;
+ struct dsps_glue *glue = dev_get_drvdata(dev-parent);
+
+ if (timeout == 0)
+ timeout = jiffies + msecs_to_jiffies(3);
+
+ /* Never idle if active, or when VBUS timeout is not set as host */
+ if (musb-is_active || (musb-a_wait_bcon == 0
+ musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
+ dev_dbg(musb-controller, %s active, deleting timer\n,
+ usb_otg_state_string(musb-xceiv-state));
+ del_timer(glue-timer);
+ glue-last_timer = jiffies;
+ return;
+ }
+ if (musb-port_mode == MUSB_PORT_MODE_HOST)
+ return;
+
+ if (!musb-g.dev.driver)
+ return;
+
+ if (time_after(glue-last_timer, timeout)
+ timer_pending(glue-timer)) {
+ dev_dbg(musb-controller,
+ Longer idle timer already pending, ignoring...\n);
+ return;
+ }
+ glue-last_timer = timeout;
+
+ dev_dbg(musb-controller, %s inactive, starting idle timer for %u
ms\n,
+ usb_otg_state_string(musb-xceiv-state),
+ jiffies_to_msecs(timeout - jiffies));
+ mod_timer(glue-timer, timeout);
+}
+
/**
* dsps_musb_enable - enable interrupts
*/
@@ -216,43 +252,6 @@ static void otg_timer(unsigned long _musb)
spin_unlock_irqrestore(musb-lock, flags);
}
-static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
-{
- struct device *dev = musb-controller;
- struct dsps_glue *glue = dev_get_drvdata(dev-parent);
-
- if (timeout == 0)
- timeout = jiffies + msecs_to_jiffies(3);
-
- /* Never idle if active, or when VBUS timeout is not set as host */
- if (musb-is_active || (musb-a_wait_bcon == 0
- musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
- dev_dbg(musb-controller, %s active, deleting timer\n,
- usb_otg_state_string(musb-xceiv-state));
- del_timer(glue-timer);
- glue-last_timer = jiffies;
- return;
- }
- if (musb-port_mode == MUSB_PORT_MODE_HOST)
- return;
-
- if (!musb-g.dev.driver)
- return;
-
- if (time_after(glue-last_timer, timeout)
- timer_pending(glue-timer)) {
- dev_dbg(musb-controller,
- Longer idle timer already pending, ignoring...\n);
- return;
- }
- glue-last_timer = timeout;
-
- dev_dbg(musb-controller, %s inactive, starting idle timer for %u
ms\n,
- usb_otg_state_string(musb-xceiv-state),
- jiffies_to_msecs(timeout - jiffies));
- mod_timer(glue-timer, timeout);
-}
-
static irqreturn_t dsps_interrupt(int irq, void *hci)
{
struct musb *musb = hci;
--
1.8.4.rc3
--
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/5] usb: musb: dsps: redo the otg timer
According to the comments, we rely on the OTG timer because the core
does not expose some important OTG details. So far this is all I
know. After playing with OTG I stumbled over a problem:
musb is recognized as a B-device without a problem. Whenever a cable is
plugged, the VBUS rises, musb recognizes this as a starting session,
sets the MUSB_DEVCTL_SESSION bit by itself and a RESET interrupt occurs,
the session starts. Good.
After a disconnect, the timer is started and re-starts itself because
it remains in B_IDLE with the BDEVICE set. I didn't figure the the
reason or the need for it. Nothing changes here except for OTG state
from B to A device if the BDEVICE bit disappears. This doesn't make much
sense to me because nothing happens after this. _IF_ we receive an
interrupt before the state change then we may act on wrong condition.
Plugging a B-device (and letting MUSB act as host) doesn't work here.
The reason seems to be that the MUSB tries to start a session, it fails
and then it removes the bit. So we never start as a host.
This patch sets the MUSB_DEVCTL_SESSION bit in the IDLE state so musb
can try to establish a session as host. After the bit is set, musb tries
to start a session and if it fails it clears the bit. Therefore it will
try over and over again until a session either as host or as device is
established.
The readout of the MUSB_DEVCTL register after the removal the
MUSB_DEVCTL_SESSION (in A_WAIT_BCON) has been removed because it did not
contain the BDEVICE bit set (in the second read) leading to A_IDLE. After
plugging a host musb assumed that it is also a host and complained about
a missing reset. However a third read of the register has has the BDEVICE
bit set so it seems that it is not stable.
This mostly what da8xx.c is doing except that we set the timer also
after A_WAIT_BCON so the session bit can be triggered.
Whit this change I was able to keep am335x-evm in OTG mode and plug in
either a HOST or a DEVICE and in a random order and the device was
recognized.
Cc: sta...@vger.kernel.org # v3.11
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_dsps.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 97d1f13..e3dce9b 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -209,6 +209,7 @@ static void otg_timer(unsigned long _musb)
const struct dsps_musb_wrapper *wrp = glue-wrp;
u8 devctl;
unsigned long flags;
+ int skip_session = 0;
/*
* We poll because DSPS IP's won't expose several OTG-critical
@@ -221,10 +222,12 @@ static void otg_timer(unsigned long _musb)
spin_lock_irqsave(musb-lock, flags);
switch (musb-xceiv-state) {
case OTG_STATE_A_WAIT_BCON:
- devctl = ~MUSB_DEVCTL_SESSION;
- dsps_writeb(musb-mregs, MUSB_DEVCTL, devctl);
+ dsps_writeb(musb-mregs, MUSB_DEVCTL, 0);
+ skip_session = 1;
+ /* fall */
- devctl = dsps_readb(musb-mregs, MUSB_DEVCTL);
+ case OTG_STATE_A_IDLE:
+ case OTG_STATE_B_IDLE:
if (devctl MUSB_DEVCTL_BDEVICE) {
musb-xceiv-state = OTG_STATE_B_IDLE;
MUSB_DEV_MODE(musb);
@@ -232,20 +235,15 @@ static void otg_timer(unsigned long _musb)
musb-xceiv-state = OTG_STATE_A_IDLE;
MUSB_HST_MODE(musb);
}
+ if (!(devctl MUSB_DEVCTL_SESSION) !skip_session)
+ dsps_writeb(mregs, MUSB_DEVCTL, MUSB_DEVCTL_SESSION);
+ mod_timer(glue-timer, jiffies + wrp-poll_seconds * HZ);
break;
case OTG_STATE_A_WAIT_VFALL:
musb-xceiv-state = OTG_STATE_A_WAIT_VRISE;
dsps_writel(musb-ctrl_base, wrp-coreintr_set,
MUSB_INTR_VBUSERROR wrp-usb_shift);
break;
- case OTG_STATE_B_IDLE:
- devctl = dsps_readb(mregs, MUSB_DEVCTL);
- if (devctl MUSB_DEVCTL_BDEVICE)
- mod_timer(glue-timer,
- jiffies + wrp-poll_seconds * HZ);
- else
- musb-xceiv-state = OTG_STATE_A_IDLE;
- break;
default:
break;
}
--
1.8.4.rc3
--
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/5] usb: musb: dsps: move try_idle to start hook
The timer is initialized right after musb is probed. There is actually
no need to have this timer running because _nothing_ will happen until
we have the gadget loaded. Also we need this timer only if we run in OTG
mode _and_ we need it also after the gadget has been replaced with
another one.
I've been looking at am35x.c, da8xx.c, omap2430.c, tusb6010.c. da8xx
seem to have the same problem as dsps and doing mostly the same thing.
tusb6010 seem to do something different and do some actual idle / power
saving work so I am not too comfortable to remove
musb_platform_try_idle() from musb_gadget_setup().
Therefore this patch does not start the timer if there is no gadget
active (which is at musb_gadget_setup() at time). In order to have the
timer active after the gadget is loaded it will be triggered from
dsps_musb_enable().
Cc: sta...@vger.kernel.org # v3.11
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_dsps.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index bd4138d..35190eb 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -121,6 +121,7 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
};
+static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout);
/**
* dsps_musb_enable - enable interrupts
*/
@@ -143,6 +144,7 @@ static void dsps_musb_enable(struct musb *musb)
/* Force the DRVVBUS IRQ so we can start polling for ID change. */
dsps_writel(reg_base, wrp-coreintr_set,
(1 wrp-drvvbus) wrp-usb_shift);
+ dsps_musb_try_idle(musb, 0);
}
/**
@@ -234,6 +236,9 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned
long timeout)
if (musb-port_mode == MUSB_PORT_MODE_HOST)
return;
+ if (!musb-g.dev.driver)
+ return;
+
if (time_after(glue-last_timer, timeout)
timer_pending(glue-timer)) {
dev_dbg(musb-controller,
--
1.8.4.rc3
--
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/5] usb: musb: dsps: run the timer only on OTG systems
I introduced this check here because it looked wrong in HOST only configurions. The timer would remove that session bit and will never come back and so there would not be another session. Now that I played with OTG for a while I belive this workaround is only required for the OTG mode because we have to end the session and then we have to try to start manually. Therefore, this patch limits this timer to the OTG only port mode so we don't need to poll around in device only mode. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/usb/musb/musb_dsps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index e3dce9b..c5010ef 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -138,7 +138,7 @@ static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout) glue-last_timer = jiffies; return; } - if (musb-port_mode == MUSB_PORT_MODE_HOST) + if (musb-port_mode != MUSB_PORT_MODE_DUAL_ROLE) return; if (!musb-g.dev.driver) -- 1.8.4.rc3 -- 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-storage: scsiglue: Changing the command result
On Tue, 15 Oct 2013, Vishal Annapurve wrote: Hi Alan, This issue seems more related to the devices using SCSI protocol and the changes otherwise will be at more places giving the same end result. I think as the comment says over the command_abort function, intentional result change should only happen in case of timeout. usb-storage doesn't know _why_ a command was aborted; it knows only that the abort occurred. If you look carefully at the code, you'll see that the result is set to DID_ABORT only when the US_FLIDX_TIMED_OUT bit is set, and this bit gets set only when a SCSI abort occurs. 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: OHCI: Only use ohci_driver_overrides if they are defined
Apologies looks like I was on an earlier RC there and the users that did this have been removed. I assume this patch can be ignored sorry for the noise. Thanks, Charles -- 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 questions about ehci period scheduling
On Tue, 15 Oct 2013, vichy wrote: This is the second part (printing a debug message if all the assigned microframes have already expired): Does this expired come from (controller frame pointer) (stream-next_uframe)? It comes from frame_pointer next_uframe + period * (number_of_packets - 1). Note that period * (number_of_packets - 1) is the same as span - period. Suppose controller frame pointer = 640 and stream-next_uframe = 600. And that mean Controller have scan our last schedule uframe? If the period was 16 and the number of packets was 3, those packets would be scheduled for uframes 600, 616, and 632. Since all three values are 640, they have already expired. However if there were 4 packets then they would be scheduled for uframes 600, 616, 632, and 648. Since 640 648, not all the assigned uframes would be expired. if so, I try to rewrite your example. (if anything wrong, please correct me) (rewrite version) If you think about a few examples, you'll understand. Suppose the endpoint's interval is 8 uframes, starting from uframe 3. Suppose base is 496, and suppose the schedule really is full. Then there will be packets scheduled for uframes 507, 515, ..., 8187, 3, 11, ..., 491, 499 (note that 491 is slightly before 496), That's not quite right. If base if 496 then the first scheduled packet will be for uframe 499 and the last will be for 491. Packets cannot be scheduled more than 8192 uframes in advance of base. and stream-next_uframe will be 499. So start will be set to (499 - 496) 8191 = 3. The fact that 3 8 indicates the schedule is full. Right. (rewrite version) Now suppose everything else is the same, but the schedule isn't completely full. For this example, let's suppose the last scheduled packet is in uframe 483, so stream-next_uframe is equal to 491. Then start will be set to (491 - 496) 8191 = 8196. The fact that 8196 = (491 - 496) 8191 = 8187, not 8196. 8 indicates the schedule isn't full. In above case, driver should try to stop this urb if it try to schedule more than 1 packet, right? Yes. (rewrite version) Consider one more example: Everything else is the same, but there's only one packet in the schedule. It is assigned to uframe 507, and stream-next_uframe is 515. Then start will be set to (515 - 496) 8191 = 19, and the fact that 19 = 8 indicates the schedule isn't full. Right. Below is where we handle URB_ISO_ASAP, if (urb-transfer_flags URB_ISO_ASAP) start += (next - start + period - 1) -period; Why don't we just use start as next? If start next then we don't want to use it. Packets scheduled before next might not be seen by the hardware, because of the isochronous scheduling threshold (see section 4.7.2.1 in the EHCI spec). when we calculate next, we have already put isochronous scheduling threshold. if (ehci-i_thresh) next = now + ehci-i_thresh;/* uframe cache */ else next = (now + 2 + 7) ~0x07;/* full frame cache */ so when handling URB_ISO_ASAP, is it possible to change as below if (urb-transfer_flags URB_ISO_ASAP) -start += (next - start + period - 1) -period; + start = (next + base); next + base might not be one of the uframes assigned to this endpoint. For example, suppose period is 8, base is 496, next_uframe is 491, and next is 501. Then we don't want start to be set to 501, because that's not one of the uframes in the endpoint's schedule. The endpoint is only allowed to use uframes 3, 11, ..., 491, 499, 507, ... We want start to be set to the first uframe available to the endpoint after 501, which is 507. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] usb: musb: call musb_start() only once in OTG mode
Hi,
On Tue, Oct 15, 2013 at 06:29:22PM +0200, Sebastian Andrzej Siewior wrote:
In commit 001dd84 (usb: musb: start musb on the udc side, too) it was
ensured that the state engine is started also in OTG mode after a
removal / insertion of the gadget.
Unfortunately this change also introduced a bug: If the device is
configured as OTG and it connected with a remote host _without_ loading
a gadget then we bug() later (because musb-otg-gadget is not
initialized).
Initially I assumed it might be nice to have the host part of musb in
OTG mode working without having a gadget loaded. This bug and fact that
it wasn't working like this before the host/gadget split made me realize
that this was a silly idea.
This patch now introduces back the old behavior where in OTG mode the
host mode is only working after the gadget has been loaded.
Cc: sta...@vger.kernel.org # v3.11
Cc: Daniel Mack zon...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/musb/musb_virthub.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index d1d6b83..9af6bba 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -220,6 +220,23 @@ int musb_hub_status_data(struct usb_hcd *hcd, char *buf)
return retval;
}
+static int musb_has_gadget(struct musb *musb)
+{
+ /*
+ * In host-only mode we start a connection right away. In OTG mode
+ * we have to wait until we loaded a gadget. We don't really need a
+ * gadget if we operate as a host but we should not start a session
+ * as a device without a gadget or else we explode.
+ */
+#ifdef CONFIG_USB_MUSB_HOST
+ return 1;
+#else
+ if (musb-port_mode == MUSB_PORT_MODE_HOST)
+ return 1;
+ return musb-g.dev.driver != NULL;
+#endif
the logic looks inverted :-s has_gadget() is true when port mode is host
or we're in host-only builds :-(
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/5] usb: musb: call musb_start() only once in OTG mode
On 10/15/2013 07:43 PM, Felipe Balbi wrote:
Hi,
Hi,
index d1d6b83..9af6bba 100644 ---
a/drivers/usb/musb/musb_virthub.c +++
b/drivers/usb/musb/musb_virthub.c @@ -220,6 +220,23 @@ int
musb_hub_status_data(struct usb_hcd *hcd, char *buf) return
retval; }
+static int musb_has_gadget(struct musb *musb) +{ + /* + * In
host-only mode we start a connection right away. In OTG mode +*
we have to wait until we loaded a gadget. We don't really need a
+ * gadget if we operate as a host but we should not start a
session + * as a device without a gadget or else we explode. +
*/ +#ifdef CONFIG_USB_MUSB_HOST +return 1; +#else + if
(musb-port_mode == MUSB_PORT_MODE_HOST) + return 1; + return
musb-g.dev.driver != NULL; +#endif
the logic looks inverted :-s has_gadget() is true when port mode is
host or we're in host-only builds :-(
No, that is okay. As the comment says in host-only mode we never have a
gadget therefore we always return 1 (as we never get a second chance to
power up the port).
If you don't like the has_gadget part here I could rename it to
musb_can_power_port how about it?
Sebastian
--
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-storage: scsiglue: Changing the command result
Hi Alan, USB storage maybe just has to say that the abort occurred. By setting the US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the reason was time out and the command is being aborted. Now, it's arguable whether to change the implication of US_FLIDX_TIMED_OUT bit for scsi - USB storage bridge or for entire usb storage Or maybe scsi has decided to abort so it should override the result. Regards, Vishal -Original Message- From: Alan Stern [mailto:st...@rowland.harvard.edu] Sent: Tuesday, October 15, 2013 7:03 PM To: Vishal Annapurve Cc: Ming Lei; Linux Kernel Mailing List; linux-usb Subject: RE: [PATCH] usb-storage: scsiglue: Changing the command result On Tue, 15 Oct 2013, Vishal Annapurve wrote: Hi Alan, This issue seems more related to the devices using SCSI protocol and the changes otherwise will be at more places giving the same end result. I think as the comment says over the command_abort function, intentional result change should only happen in case of timeout. usb-storage doesn't know _why_ a command was aborted; it knows only that the abort occurred. If you look carefully at the code, you'll see that the result is set to DID_ABORT only when the US_FLIDX_TIMED_OUT bit is set, and this bit gets set only when a SCSI abort occurs. 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: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On 10/15/2013 06:07 PM, Alan Stern wrote: The USB endpoint specifies a transfer interval of 10. The rts5139 Does the device connect at high speed (480 Mb/s)? I can say that the rts5139 card reader in my laptop does use the 480 MBit/s rate. (I don't know whether there are derivatives of that reader that would support higher rates.) Regards, Lutz Vieweg -- 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: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Tue, Oct 15, 2013 at 08:09:01AM -0700, Greg Kroah-Hartman wrote: All of these are for issues that do not look like regressions to me, but rather, long-standing bugs. While I'm all about fixing bugs and problems, none of these seem like urgent fixes for things that have been recently broken. I agree, they're not regressions. The support for USB 2.0 Link PM on Haswell ULT was added in 3.11, and the code has always caused these broken USB 3.0 devices to not enumerate when plugged into USB 2.0 ports. We just didn't catch it until now. And yes, the first patch fixes a long-standing bug. So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. Ok, fine with me. Just to be clear though: are you asking me to delay these long-standing bugs because we're now at -rc5, or do you always want me to delay them for the next kernel release? I can take these as patches for my usb-next branch by hand if you want, or I can take a new pull request for that branch. I'll send you a separate pull request tomorrow. I've got a bunch of patches for usb-next anyway. Sarah Sharp -- 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: linux-next: Tree for Oct 15 (usb gadget f_mass_storage and storage_common)
On 10/15/13 07:02, Thierry Reding wrote: Hi all, I've uploaded today's linux-next tree to the master branch of the repository below: git://gitorious.org/thierryreding/linux-next.git A next-20131015 tag is also provided for convenience. Gained a new conflict, but nothing too exciting. x86 and ARM default configurations build fine. I've also used an x86 allmodconfig build to check for build errors. Mark fixed most of those in the trees that he created last Thursday and Friday, so I've cherry-picked them on top of the final merge. There was one new build failure in the staging tree that was trivial to fix so I added a patch to the tree as well. on x86_64: drivers/usb/gadget/f_mass_storage.c: In function 'fsg_main_thread': drivers/usb/gadget/f_mass_storage.c:2509:2: error: implicit declaration of function 'set_fs' [-Werror=implicit-function-declaration] drivers/usb/gadget/f_mass_storage.c:2509:2: error: implicit declaration of function 'get_ds' [-Werror=implicit-function-declaration] (needs #include linux/uaccess.h) and when CONFIG_BLOCK is not enabled: drivers/usb/gadget/storage_common.c: In function 'fsg_lun_open': drivers/usb/gadget/storage_common.c:241:3: error: implicit declaration of function 'bdev_logical_block_size' [-Werror=implicit-function-declaration] drivers/usb/gadget/storage_common.c:242:3: error: implicit declaration of function 'blksize_bits' [-Werror=implicit-function-declaration] Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.12.0-rc5 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_HWEIGHT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_BZIP2=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SYSVIPC is not set # CONFIG_FHANDLE is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_USER_QS is not set CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set CONFIG_TREE_RCU_TRACE=y # CONFIG_RCU_NOCB_CPU is not set CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_HUGETLB=y
[PATCH v2 7/7] arm/dts: added dt properties to adapt to the new phy framwork
Added device tree bindings for dwc3, usb2 and usb3 PHYs. The documentation
of these can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt
and Documentation/devicetree/bindings/phy/ti-phy.txt.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index edc801f..998f198 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -661,7 +661,8 @@
compatible = snps,dwc3;
reg = 0x4a03 0x1;
interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
- usb-phy = usb2_phy, usb3_phy;
+ phys = usb2_phy, usb3_phy;
+ phy-names = usb2-phy, usb3-phy;
tx-fifo-resize;
};
};
@@ -677,6 +678,7 @@
compatible = ti,omap-usb2;
reg = 0x4a084000 0x7c;
ctrl-module = omap_control_usb2phy;
+ #phy-cells = 0;
};
usb3_phy: usb3phy@4a084400 {
@@ -686,6 +688,7 @@
0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb3phy;
+ #phy-cells = 0;
};
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/phy-omap-usb2.c |2 +-
include/linux/{usb = phy}/omap_usb.h |3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
rename include/linux/{usb = phy}/omap_usb.h (95%)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 9b3e867..d738dc3 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/io.h
-#include linux/usb/omap_usb.h
+#include linux/phy/omap_usb.h
#include linux/usb/phy_companion.h
#include linux/clk.h
#include linux/err.h
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
struct omap_usb {
struct usb_phy phy;
struct phy_companion*comparator;
- void __iomem*pll_ctrl_base;
struct device *dev;
struct device *control_dev;
struct clk *wkupclk;
- struct clk *sys_clk;
struct clk *optclk;
- u8 is_suspended:1;
};
#definephy_to_omapusb(x) container_of((x), struct omap_usb, phy)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
Now that omap-usb2 is adapted to the new generic PHY framework,
*set_suspend* ops can be removed from omap-usb2 driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
This patch was deferred from Generic PHY framework series since dwc3 uses the
same driver and it has to be adapted to the Generic PHY Framework.
drivers/phy/phy-omap-usb2.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index bfc5c33..9b3e867 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -98,28 +98,6 @@ static int omap_usb_set_peripheral(struct usb_otg *otg,
return 0;
}
-static int omap_usb2_suspend(struct usb_phy *x, int suspend)
-{
- struct omap_usb *phy = phy_to_omapusb(x);
- int ret;
-
- if (suspend !phy-is_suspended) {
- omap_control_usb_phy_power(phy-control_dev, 0);
- pm_runtime_put_sync(phy-dev);
- phy-is_suspended = 1;
- } else if (!suspend phy-is_suspended) {
- ret = pm_runtime_get_sync(phy-dev);
- if (ret 0) {
- dev_err(phy-dev, get_sync failed with err %d\n, ret);
- return ret;
- }
- omap_control_usb_phy_power(phy-control_dev, 1);
- phy-is_suspended = 0;
- }
-
- return 0;
-}
-
static int omap_usb_power_off(struct phy *x)
{
struct omap_usb *phy = phy_get_drvdata(x);
@@ -173,7 +151,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
phy-phy.dev= phy-dev;
phy-phy.label = omap-usb2;
- phy-phy.set_suspend= omap_usb2_suspend;
phy-phy.otg= otg;
phy-phy.type = USB_PHY_TYPE_USB2;
@@ -195,8 +172,6 @@ static int omap_usb2_probe(struct platform_device *pdev)
}
phy-control_dev = control_pdev-dev;
-
- phy-is_suspended = 1;
omap_control_usb_phy_power(phy-control_dev, 0);
otg-set_host = omap_usb_set_host;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
power_on and power_off the following APIs are used phy_init(), phy_exit(),
phy_power_on() and phy_power_off().
However using the old USB phy library wont be removed till the PHYs of all
other SoC's using dwc3 core is adapted to the Generic PHY Framework.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/dwc3.txt |6 ++-
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c| 52
drivers/usb/dwc3/core.h|7
drivers/usb/dwc3/platform_data.h |2 +
5 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635..471366d 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
- compatible: must be snps,dwc3
- reg : Address and length of the register set for the device
- interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
- usb-phy : array of phandle for the PHY device. The first element
in the array is expected to be a handle to the USB2/HS PHY and
the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
- tx-fifo-resize: determines if the FIFO *has* to be reallocated.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 8e385b4..64eed6f 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -2,6 +2,7 @@ config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) HAS_DMA
select USB_PHY
+ select GENERIC_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index cb91d70..28bfa5b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -82,6 +82,12 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
usb_phy_init(dwc-usb2_phy);
usb_phy_init(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_init(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_init(dwc-usb3_generic_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -343,6 +349,11 @@ static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
usb_phy_shutdown(dwc-usb3_phy);
+
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_off(dwc-usb3_generic_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -439,6 +450,26 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
+ count = of_property_match_string(node, phy-names, usb2-phy);
+ if (count = 0 || (pdata pdata-usb2_generic_phy)) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+ dwc-usb2_phy = NULL;
+ }
+
+ count = of_property_match_string(node, phy-names, usb3-phy);
+ if (count = 0 || (pdata pdata-usb3_generic_phy)) {
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
+ dwc-usb3_phy = NULL;
+ }
+
/* default to superspeed if no maximum_speed passed */
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
@@ -462,6 +493,11 @@ static int dwc3_probe(struct platform_device *pdev)
usb_phy_set_suspend(dwc-usb2_phy, 0);
usb_phy_set_suspend(dwc-usb3_phy, 0);
+ if (dwc-usb2_generic_phy)
+ phy_power_on(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+ phy_power_on(dwc-usb3_generic_phy);
+
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
@@ -588,6 +624,11 @@ static int dwc3_remove(struct platform_device *pdev)
usb_phy_set_suspend(dwc-usb2_phy, 1);
usb_phy_set_suspend(dwc-usb3_phy, 1);
+ if (dwc-usb2_generic_phy)
+ phy_power_off(dwc-usb2_generic_phy);
+ if (dwc-usb3_generic_phy)
+
[PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
There can be systems which does not have a external usb_phy, so get
usb_phy only if dt data indicates the presence of PHY in the case of dt boot or
if platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
In usb_get_phy_by_phandle, index 0 always refers to usb2 phy and index 1 always
refers to usb3 phy. Since we've lived so long with this, this patch will make
an assumption that if only one entry is populated in *usb-phy* property, it will
be usb2 phy and the next entry will be usb3 phy.
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 72 --
drivers/usb/dwc3/platform_data.h |2 ++
3 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 70fc430..8e385b4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,7 @@
config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) HAS_DMA
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..cb91d70 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -354,6 +354,7 @@ static int dwc3_probe(struct platform_device *pdev)
struct device_node *node = dev-of_node;
struct resource *res;
struct dwc3 *dwc;
+ int count;
int ret = -ENOMEM;
@@ -387,16 +388,49 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ count = of_count_phandle_with_args(node, usb-phy, NULL);
+ switch (count) {
+ case 2:
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy)) {
+ dev_err(dev, usb3 phy not found\n);
+ return PTR_ERR(dwc-usb3_phy);
+ }
+ case 1:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy)) {
+ dev_err(dev, usb2 phy not found\n);
+ return PTR_ERR(dwc-usb2_phy);
+ }
+ break;
+ default:
+ dev_err(dev, usb phy nodes not configured\n);
+ }
dwc-needs_fifo_resize = of_property_read_bool(node,
tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
- dwc-usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
- dwc-usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
+ if (pdata-usb2_phy) {
+ dwc-usb2_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB2);
+ if (IS_ERR(dwc-usb2_phy)) {
+ dev_err(dev, usb2 phy not found\n);
+ return PTR_ERR(dwc-usb2_phy);
+ }
+ }
+
+ if (pdata-usb3_phy) {
+ dwc-usb3_phy = devm_usb_get_phy(dev,
+ USB_PHY_TYPE_USB3);
+ if (IS_ERR(dwc-usb3_phy)) {
+ dev_err(dev, usb3 phy not found\n);
+ return PTR_ERR(dwc-usb3_phy);
+ }
+ }
dwc-needs_fifo_resize = pdata-tx_fifo_resize;
dwc-dr_mode = pdata-dr_mode;
@@ -409,36 +443,6 @@ static int dwc3_probe(struct platform_device *pdev)
if (dwc-maximum_speed == USB_SPEED_UNKNOWN)
dwc-maximum_speed = USB_SPEED_SUPER;
- if (IS_ERR(dwc-usb2_phy)) {
- ret = PTR_ERR(dwc-usb2_phy);
-
- /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb2 phy configured\n);
- return -EPROBE_DEFER;
- }
-
- if (IS_ERR(dwc-usb3_phy)) {
[PATCH v2 4/7] drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
Adapted omap-usb3 PHY driver to Generic PHY Framework and moved phy-omap-usb3
driver in drivers/usb/phy to drivers/phy and also renamed the file to
phy-ti-pipe3 since this same driver will be used for SATA PHY and
PCIE PHY.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/phy/Kconfig| 10 +
drivers/phy/Makefile |1 +
.../phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} | 206 +++-
drivers/usb/phy/Kconfig| 11 --
drivers/usb/phy/Makefile |1 -
include/linux/phy/ti_pipe3.h | 52 +
6 files changed, 174 insertions(+), 107 deletions(-)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} (57%)
create mode 100644 include/linux/phy/ti_pipe3.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ac239ac..1158943 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -27,6 +27,16 @@ config OMAP_USB2
The USB OTG controller communicates with the comparator using this
driver.
+config TI_PIPE3
+ tristate TI PIPE3 PHY Driver
+ select GENERIC_PHY
+ select OMAP_CONTROL_USB
+ help
+ Enable this to support the PIPE3 PHY that is part of TI SOCs. This
+ driver takes care of all the PHY functionality apart from comparator.
+ This driver interacts with the OMAP Control PHY Driver to power
+ on/off the PHY.
+
config TWL4030_USB
tristate TWL4030 USB Transceiver Driver
depends on TWL4030_CORE REGULATOR_TWL4030 USB_MUSB_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 0dd8a98..42ccab4 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,4 +4,5 @@
obj-$(CONFIG_GENERIC_PHY) += phy-core.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
+obj-$(CONFIG_TI_PIPE3) += phy-ti-pipe3.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/phy/phy-ti-pipe3.c
similarity index 57%
rename from drivers/usb/phy/phy-omap-usb3.c
rename to drivers/phy/phy-ti-pipe3.c
index 0c6ba29..31e8397 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/phy/phy-ti-pipe3.c
@@ -1,5 +1,5 @@
/*
- * omap-usb3 - USB PHY, talking to dwc3 controller in OMAP.
+ * phy-ti-pipe3 - PIPE3 PHY driver for SATA, USB and PCIE.
*
* Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
* This program is free software; you can redistribute it and/or modify
@@ -19,7 +19,8 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
-#include linux/usb/omap_usb.h
+#include linux/phy/ti_pipe3.h
+#include linux/phy/phy.h
#include linux/of.h
#include linux/clk.h
#include linux/err.h
@@ -52,17 +53,17 @@
/*
* This is an Empirical value that works, need to confirm the actual
- * value required for the USB3PHY_PLL_CONFIGURATION2.PLL_IDLE status
- * to be correctly reflected in the USB3PHY_PLL_STATUS register.
+ * value required for the PIPE3PHY_PLL_CONFIGURATION2.PLL_IDLE status
+ * to be correctly reflected in the PIPE3PHY_PLL_STATUS register.
*/
# define PLL_IDLE_TIME 100;
-struct usb_dpll_map {
+struct pipe3_dpll_map {
unsigned long rate;
- struct usb_dpll_params params;
+ struct pipe3_dpll_params params;
};
-static struct usb_dpll_map dpll_map[] = {
+static struct pipe3_dpll_map dpll_map[] = {
{1200, {1250, 5, 4, 20, 0} }, /* 12 MHz */
{1680, {3125, 20, 4, 20, 0} }, /* 16.8 MHz */
{1920, {1172, 8, 4, 20, 65537} }, /* 19.2 MHz */
@@ -71,7 +72,7 @@ static struct usb_dpll_map dpll_map[] = {
{3840, {3125, 47, 4, 20, 92843} }, /* 38.4 MHz */
};
-static struct usb_dpll_params *omap_usb3_get_dpll_params(unsigned long rate)
+static struct pipe3_dpll_params *ti_pipe3_get_dpll_params(unsigned long rate)
{
int i;
@@ -83,110 +84,113 @@ static struct usb_dpll_params
*omap_usb3_get_dpll_params(unsigned long rate)
return NULL;
}
-static int omap_usb3_suspend(struct usb_phy *x, int suspend)
+static int ti_pipe3_power_off(struct phy *x)
{
- struct omap_usb *phy = phy_to_omapusb(x);
- int val;
+ struct ti_pipe3 *phy = phy_get_drvdata(x);
+ int val;
int timeout = PLL_IDLE_TIME;
- if (suspend !phy-is_suspended) {
- val = omap_usb_readl(phy-pll_ctrl_base, PLL_CONFIGURATION2);
- val |= PLL_IDLE;
- omap_usb_writel(phy-pll_ctrl_base, PLL_CONFIGURATION2, val);
-
- do {
- val = omap_usb_readl(phy-pll_ctrl_base, PLL_STATUS);
- if (val PLL_TICOPWDN)
- break;
- udelay(1);
- } while (--timeout);
-
- omap_control_usb_phy_power(phy-control_dev, 0);
-
- phy-is_suspended = 1;
-
[PATCH v2 0/7] Make dwc3 use Generic PHY Framework
Felipe,
Looks like most of the patches are dependent on Generic PHY Framework except
the first one. Let me know if I have to take these patches with your ACK or
you'll take it yourself.
**
Modified dwc3 core to find PHYs only if the platform indicates that it has
to use a PHY. Adapted DWC3 and USB3 PHY to use Generic PHY framework. Also
changed the name of USB3 PHY driver to PIPE3 PHY driver since the same driver
has to be used for SATA and PCIE too.
Changes from v1:
* The logic in which the driver detects the presence of PHYs has changed.
* patch ordering has changed
* udelay is replaced with usleep_range
* A patch to remove set_suspend callback which was deferred from Generic
PHY Framework series has been included.
Kishon Vijay Abraham I (7):
usb: dwc3: get usb_phy only if the platform indicates the presence
of PHY's
usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Documentation: dt bindings: move ..usb/usb-phy.txt to
..phy/ti-phy.txt
drivers: phy: usb3/pipe3: Adapt pipe3 driver to Generic PHY Framework
usb: phy: omap-usb2: remove *set_suspend* callback from omap-usb2
phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
arm/dts: added dt properties to adapt to the new phy framwork
.../bindings/{usb/usb-phy.txt = phy/ti-phy.txt} |9 +-
Documentation/devicetree/bindings/usb/dwc3.txt |6 +-
arch/arm/boot/dts/omap5.dtsi |5 +-
drivers/phy/Kconfig| 10 +
drivers/phy/Makefile |1 +
drivers/phy/phy-omap-usb2.c| 27 +--
.../phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} | 206 +++-
drivers/usb/dwc3/Kconfig |2 +
drivers/usb/dwc3/core.c| 124
drivers/usb/dwc3/core.h|7 +
drivers/usb/dwc3/platform_data.h |4 +
drivers/usb/phy/Kconfig| 11 --
drivers/usb/phy/Makefile |1 -
include/linux/{usb = phy}/omap_usb.h |3 -
include/linux/{usb/omap_usb.h = phy/ti_pipe3.h} | 33 +---
15 files changed, 248 insertions(+), 201 deletions(-)
rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt}
(86%)
rename drivers/{usb/phy/phy-omap-usb3.c = phy/phy-ti-pipe3.c} (57%)
copy include/linux/{usb = phy}/omap_usb.h (95%)
rename include/linux/{usb/omap_usb.h = phy/ti_pipe3.h} (53%)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] Documentation: dt bindings: move ..usb/usb-phy.txt to ..phy/ti-phy.txt
Since now we have a separate folder for phy, move the PHY dt binding
documentation of TI to that folder.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt} |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/{usb/usb-phy.txt = phy/ti-phy.txt}
(86%)
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
similarity index 86%
rename from Documentation/devicetree/bindings/usb/usb-phy.txt
rename to Documentation/devicetree/bindings/phy/ti-phy.txt
index c0245c8..355acf0 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -1,4 +1,4 @@
-USB PHY
+TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
OMAP USB2 PHY
@@ -21,10 +21,11 @@ usb2phy@4a0ad080 {
#phy-cells = 0;
};
-OMAP USB3 PHY
+TI PIPE3 PHY
Required properties:
- - compatible: Should be ti,omap-usb3
+ - compatible: Should be ti,phy-usb3, ti,phy-pcie or ti,phy-sata.
+ ti,omap-usb3 is deprecated.
- reg : Address and length of the register set for the device.
- reg-names: The names of the register addresses corresponding to the
registers
filled in reg.
@@ -38,7 +39,7 @@ Optional properties:
This is usually a subnode of ocp2scp to which it is connected.
usb3phy@4a084400 {
- compatible = ti,omap-usb3;
+ compatible = ti,phy-usb3;
reg = 0x4a084400 0x80,
0x4a084800 0x64,
0x4a084c00 0x40;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Pull Request] xHCI bug fixes for 3.12 (Link PM and misc)
On Tue, Oct 15, 2013 at 12:44:08PM -0700, Sarah Sharp wrote: So I'd like to take these for 3.13-rc1, and if they are fixes, take them into the 3.12-stable tree (and older ones) when they hit Linus's tree then. Ok, fine with me. Just to be clear though: are you asking me to delay these long-standing bugs because we're now at -rc5, or do you always want me to delay them for the next kernel release? Because we are at -rc5. Maybe something like this could go into -rc2 and possibly -rc3, but come on, -rc5? Look at all of the pushback Linus has been giving maintainers on lkml, this shouldn't be news. 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: OHCI: Only use ohci_driver_overrides if they are defined
On Tue, 15 Oct 2013, Charles Keepax wrote: Apologies looks like I was on an earlier RC there and the users that did this have been removed. I assume this patch can be ignored sorry for the noise. Actually it's the other way around. The change you submitted has already been merged: https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/drivers/usb/host/ohci-hcd.c?h=usb-nextid=c80ad6d1cd6c6662d0cff752d94a1a9fde6de4ac 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-storage: scsiglue: Changing the command result
On Tue, 15 Oct 2013, Vishal Annapurve wrote: Hi Alan, USB storage maybe just has to say that the abort occurred. By setting the US_FLIDX_TIMED_OUT bit USB storage is getting signaled that the reason was time out and the command is being aborted. No. By setting the US_FLIDX_TIMED_OUT bit, usb-storage indicates that the command was aborted. This doesn't indicate anything about the reason for the abort. (Maybe this bit's name wasn't chosen very well.) Now, it's arguable whether to change the implication of US_FLIDX_TIMED_OUT bit for scsi - USB storage bridge or for entire usb storage I don't understand this. What's the difference between scsi - USB storage bridge and entire usb storage? Aren't they the same thing? Or maybe scsi has decided to abort so it should override the result. Of course the SCSI midlayer has decided to abort. That's the only way this bit can get set. But usb-storage doesn't know why SCSI decided to abort. 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: Scheduling of interrupt transfer delayed on ehci when interval not 1?
On Tue, Oct 15, 2013 at 6:07 PM, Alan Stern st...@rowland.harvard.edu wrote: Why does the driver make this mistake? My initial assumption was wrong, the driver doesn't infrequently poll, but does so more often. I was misled by the confusing source. However, I now made usbmon traces and analyzed them with LibreOffice. During data transfer, the driver does a interrupt transfer about 48ms after the last one, and has to wait about 15ms for the result. But every 40 transfers, it executes 3 transfers without waiting inbetween and has to wait 63ms for the result. This is with transfer interval set to 10 on xhci. I also compiled the driver with transfer interval set to 1 (the original setting before my patch [1]), but the result is similar, an interrupt transfer every 44ms, and waiting of 19ms for the result. I don't have ehci hardware to test it. When the URB completition callback is executed, it calles complete(), while the driver is using wait_for_completion_interruptible_timeout() for this signal with 100ms timeout (originally that was 50ms but I changed it in patch [2] to make it work with xhci) This function seems to timeout on ehci hardware after about 700MB to 7GB transfered. I guess that the thread isn't scheduled fast enough under load, although the USB transfer was successful. Does the device connect at high speed (480 Mb/s)? Yes, even with xhci it is only using 480Mb/s. What needs to be fixed? It sounds like xhci-hcd and ehci-hcd are working correctly and the problem is in the rts5139 driver. After looking at the usbmon traces, i have to agree. bInterval = 10 means the polling period is 64 ms (for a high-speed device). So a timeout of 100 ms should be adequate -- provided the device always sends data over the interrupt endpoint without any further delay. What i do not understand: with ehci hardware, the driver works when interval in the urb is set to 1 and the timeout is 50ms. With xhci, the urb appears to be scheduled not more often then every 64ms even if the interval in the urb is set to 1. I'm just looking for the correct solution for this issue. regards Marcus below some more info: [1] patch I made to get rid of syslog warnings because of wrong interval with xhci (that broke it for ehci hardware) https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6441a57887281106ed01222c2b0561ab25f77212 [2] patch I made to get it working on xhci (increasing timeout from 50 to 100): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c5c141dfe737706d8bd57f40b4a9a8818c5ce4der T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=0bda ProdID=0129 Rev=39.60 S: Manufacturer=Generic S: Product=USB2.0-CRW S: SerialNumber=2010020139600 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=50 Driver=rts5139 E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 3 Ivl=64ms root@goetterdaemmerung:/home/marcus/linux# lsusb -v -s 3:2 Bus 003 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0129 bcdDevice 39.60 iManufacturer 1 Generic iProduct2 USB2.0-CRW iSerial 3 2010020139600 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 CARD READER bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 6 bInterfaceProtocol 80 iInterface 5 Bulk-In, Bulk-Out, Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2
[PATCH] ehci: remove old TT sched code
This removes the old EHCI transaction translator scheduling code,
leaving only the new (now over 7 years old) scheduling code.
---
I think it's been long enough to prove the new tt sched
code works, and we can drop the old stuff. Alan, Greg,
and reason to keep the old tt sched code?
This patch is against usb-next branch.
(Sorry if anyone got multiples of this email, I had send-email
config problems that blocked delivery to the list)
drivers/usb/host/Kconfig | 20
drivers/usb/host/ehci-sched.c | 115 --
2 files changed, 135 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 80e72fb..20cc435 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -64,26 +64,6 @@ config USB_EHCI_ROOT_HUB_TT
This supports the EHCI implementation that's originally
from ARC, and has since changed hands a few times.
-config USB_EHCI_TT_NEWSCHED
- bool Improved Transaction Translator scheduling
- depends on USB_EHCI_HCD
- default y
- ---help---
- This changes the periodic scheduling code to fill more of the low
- and full speed bandwidth available from the Transaction Translator
- (TT) in USB 2.0 hubs. Without this, only one transfer will be
- issued in each microframe, significantly reducing the number of
- periodic low/fullspeed transfers possible.
-
- If you have multiple periodic low/fullspeed devices connected to a
- highspeed USB hub which is connected to a highspeed USB Host
- Controller, and some of those devices will not work correctly
- (possibly due to ENOSPC or -28 errors), say Y. Conversely, if
- you have only one such device and it doesn't work, you could try
- saying N.
-
- If unsure, say Y.
-
config USB_FSL_MPH_DR_OF
tristate
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index 7ce5c2a..eaff175 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -318,8 +318,6 @@ static int __maybe_unused same_tt(struct usb_device *dev1,
return 1;
}
-#ifdef CONFIG_USB_EHCI_TT_NEWSCHED
-
/* Which uframe does the low/fullspeed transfer start in?
*
* The parameter is the mask of ssplits in H-frame terms
@@ -429,87 +427,6 @@ static int tt_available (
return 1;
}
-#else
-
-/* return true iff the device's transaction translator is available
- * for a periodic transfer starting at the specified frame, using
- * all the uframes in the mask.
- */
-static int tt_no_collision (
- struct ehci_hcd *ehci,
- unsignedperiod,
- struct usb_device *dev,
- unsignedframe,
- u32 uf_mask
-)
-{
- if (period == 0)/* error */
- return 0;
-
- /* note bandwidth wastage: split never follows csplit
-* (different dev or endpoint) until the next uframe.
-* calling convention doesn't make that distinction.
-*/
- for (; frame ehci-periodic_size; frame += period) {
- union ehci_shadow here;
- __hc32 type;
- struct ehci_qh_hw *hw;
-
- here = ehci-pshadow [frame];
- type = Q_NEXT_TYPE(ehci, ehci-periodic [frame]);
- while (here.ptr) {
- switch (hc32_to_cpu(ehci, type)) {
- case Q_TYPE_ITD:
- type = Q_NEXT_TYPE(ehci, here.itd-hw_next);
- here = here.itd-itd_next;
- continue;
- case Q_TYPE_QH:
- hw = here.qh-hw;
- if (same_tt(dev, here.qh-ps.udev)) {
- u32 mask;
-
- mask = hc32_to_cpu(ehci,
- hw-hw_info2);
- /* knows no gap is needed */
- mask |= mask 8;
- if (mask uf_mask)
- break;
- }
- type = Q_NEXT_TYPE(ehci, hw-hw_next);
- here = here.qh-qh_next;
- continue;
- case Q_TYPE_SITD:
- if (same_tt (dev, here.sitd-urb-dev)) {
- u16 mask;
-
- mask = hc32_to_cpu(ehci, here.sitd
- -hw_uframe);
- /* FIXME assumes no gap for IN! */
- mask |= mask 8;
-
RE: [PATCH] usb: ohci: remove ep93xx bus glue platform driver
On Tuesday, October 15, 2013 8:50 AM, Olof Johansson wrote:
On Mon, Oct 14, 2013 at 2:35 PM, H Hartley Sweeten
hartl...@visionengravers.com wrote:
Convert ep93xx to use the OHCI platform driver and remove the
ohci-ep93xx bus glue driver.
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Ryan Mallon rmal...@gmail.com
---
arch/arm/mach-ep93xx/clock.c | 2 +-
arch/arm/mach-ep93xx/core.c| 45 +-
drivers/usb/host/Kconfig | 2 +-
drivers/usb/host/ohci-ep93xx.c | 184
-
drivers/usb/host/ohci-hcd.c| 18
5 files changed, 43 insertions(+), 208 deletions(-)
delete mode 100644 drivers/usb/host/ohci-ep93xx.c
diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
index c95dbce..39ef3b6 100644
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c
@@ -212,7 +212,7 @@ static struct clk_lookup clocks[] = {
INIT_CK(NULL, hclk, clk_h),
INIT_CK(NULL, apb_pclk, clk_p),
INIT_CK(NULL, pll2, clk_pll2),
- INIT_CK(ep93xx-ohci, NULL, clk_usb_host),
+ INIT_CK(ohci-platform,NULL, clk_usb_host),
INIT_CK(ep93xx-keypad,NULL, clk_keypad),
INIT_CK(ep93xx-fb,NULL, clk_video),
INIT_CK(ep93xx-spi.0, NULL, clk_spi),
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 3f12b88..5489824 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -36,6 +36,7 @@
#include linux/export.h
#include linux/irqchip/arm-vic.h
#include linux/reboot.h
+#include linux/usb/ohci_pdriver.h
#include mach/hardware.h
#include linux/platform_data/video-ep93xx.h
@@ -297,22 +298,58 @@ static struct platform_device ep93xx_rtc_device = {
.resource = ep93xx_rtc_resource,
};
+/*
+ * EP93xx OHCI USB Host
+ */
+
+static struct clk *ep93xx_ohci_host_clock;
+
+static int ep93xx_ohci_power_on(struct platform_device *pdev)
+{
+ if (!ep93xx_ohci_host_clock) {
+ ep93xx_ohci_host_clock = devm_clk_get(pdev-dev, NULL);
+ if (IS_ERR(ep93xx_ohci_host_clock))
+ return PTR_ERR(ep93xx_ohci_host_clock);
+ }
+
+ clk_enable(ep93xx_ohci_host_clock);
+
+ return 0;
+}
+
+static void ep93xx_ohci_power_off(struct platform_device *pdev)
+{
+ clk_disable(ep93xx_ohci_host_clock);
+}
+
+static void ep93xx_ohci_power_suspend(struct platform_device *pdev)
+{
+ ep93xx_ohci_power_off(pdev);
+}
+
+static struct usb_ohci_pdata ep93xx_ohci_pdata = {
+ .power_on = ep93xx_ohci_power_on,
+ .power_off = ep93xx_ohci_power_off,
+ .power_suspend = ep93xx_ohci_power_suspend,
+};
This is definitely not a show-stopper in any way, but since this is
just standard clock management, could you even move these clock ops
into the driver? Are any other platforms already doing similar things
so you could remove code from their platform that way as well, per
chance?
It does not appear any of the other users of the ohci-platform driver do
anything similar.
The clock ops could be moved into the driver but I will need to add a
flag or something to the usb_ohci_pdata so that the platform can
indicated that a clock is required and the clock ops should be done.
Regards,
Hartley
--
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: hub: Clear Port Reset Change during init/resume
This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around with USB devices without cleaning up
correctly. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..c9ef5b8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1130,6 +1130,11 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
usb_clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_ENABLE);
}
+ if ((portchange USB_PORT_STAT_C_RESET)) {
+ need_debounce_delay = true;
+ usb_clear_port_feature(hub-hdev, port1,
+ USB_PORT_FEAT_C_RESET);
+ }
if ((portchange USB_PORT_STAT_C_BH_RESET)
hub_is_superspeed(hub-hdev)) {
need_debounce_delay = true;
--
1.7.12.4
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: hub: Clear Port Reset Change during init/resume
Hello.
On 10/16/2013 01:23 AM, Julius Werner wrote:
This patch adds the Port Reset Change flag to the set of bits that are
preemptively cleared on init/resume of a hub. In theory this bit should
never be set unexpectedly... in practice it can still happen if BIOS,
SMM or ACPI code plays around with USB devices without cleaning up
correctly. This is especially dangerous for XHCI root hubs, which don't
generate any more Port Status Change Events until all change bits are
cleared, so this is a good precaution to have (similar to how it's
already done for the Warm Port Reset Change flag).
Signed-off-by: Julius Werner jwer...@chromium.org
---
drivers/usb/core/hub.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..c9ef5b8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1130,6 +1130,11 @@ static void hub_activate(struct usb_hub *hub, enum
hub_activation_type type)
usb_clear_port_feature(hub-hdev, port1,
USB_PORT_FEAT_C_ENABLE);
}
+ if ((portchange USB_PORT_STAT_C_RESET)) {
Hm, why these double parens?
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
Errot compiling 3.1.-rc4
Hello, I get a compile error with the kernel 3.12-rc4 : Kernel: arch/x86/boot/bzImage is ready (#8) ERROR: devm_regmap_init_i2c [drivers/usb/misc/usb3503.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 If I set : # CONFIG_USB_HSIC_USB3503 is not set the kernel compile OK. Regards JP P -- 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: Errot compiling 3.1.-rc4
On 10/15/13 14:48, jpliste wrote: Hello, I get a compile error with the kernel 3.12-rc4 : Kernel: arch/x86/boot/bzImage is ready (#8) ERROR: devm_regmap_init_i2c [drivers/usb/misc/usb3503.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 If I set : # CONFIG_USB_HSIC_USB3503 is not set the kernel compile OK. Please post your failing kernel .config file. thanks. -- ~Randy -- 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
