Re: [PATCH] usb: phy: Restore deferred probing path
On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> failure") broke platforms that rely on deferred probing to order probing
> of PHY and host controller drivers. The reason is that the commit simply
> propagates errors from __of_usb_find_phy(), which returns -ENODEV if no
> PHY has been registered yet for a given device tree node. The only case
> in which -EPROBE_DEFER would now be returned is if try_module_get() did
> fail, which does not make sense.
>
> The correct thing to do is to return -EPROBE_DEFER if a PHY hasn't been
> registered yet. The only condition under which it makes sense to return
> -ENODEV is if the device tree node representing the PHY has been
> disabled (via the status property) because in that case the PHY will
> never be registered.
>
> This patch addresses the problem by making __of_usb_find_phy() return an
> appropriate error code while keeping in line with the above-mentioned
> commit to propagate error codes rather than overwriting them. At the
> same time the check for a valid PHY is decoupled from the check for the
> try_module_get() call and a separate error code is returned if the
> latter fails.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/usb/phy/phy.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
Ping?
Thierry
pgprB24PmQbbS.pgp
Description: PGP signature
[PATCH 1/2] USB: gadget: udc: atmel: change setting for DMA
According to the datasheet, when transfer using DMA, the control setting for IN packet only need END_BUF_EN, END_BUF_IE, CH_EN, while for OUT packet, need more two bits END_TR_EN and END_TR_IE to be configured. Signed-off-by: Bo Shen --- drivers/usb/gadget/udc/atmel_usba_udc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c index ce88237..63e90f5 100644 --- a/drivers/usb/gadget/udc/atmel_usba_udc.c +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c @@ -716,10 +716,10 @@ static int queue_dma(struct usba_udc *udc, struct usba_ep *ep, req->using_dma = 1; req->ctrl = USBA_BF(DMA_BUF_LEN, req->req.length) | USBA_DMA_CH_EN | USBA_DMA_END_BUF_IE - | USBA_DMA_END_TR_EN | USBA_DMA_END_TR_IE; + | USBA_DMA_END_BUF_EN; - if (ep->is_in) - req->ctrl |= USBA_DMA_END_BUF_EN; + if (!ep->is_in) + req->ctrl |= USBA_DMA_END_TR_EN | USBA_DMA_END_TR_IE; /* * Add this request to the queue and submit for DMA if -- 2.1.0.24.g4109c28 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: gadget: udc: atmel: fix possible IN hang issue
When receive data, the RXRDY in status register set by hardware
after a new packet has been stored in the endpoint FIFO. When it
is copied from FIFO, this bit is cleared which make the FIFO can
be accessed again.
In the receive_data() function, this bit RXRDY has been cleared.
So, after the receive_data() function return, this bit should
not be cleared again, or else it may cause the accessing FIFO
corrupt, which will make the data loss.
Signed-off-by: Bo Shen
---
drivers/usb/gadget/udc/atmel_usba_udc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 63e90f5..93328ea 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1563,7 +1563,6 @@ static void usba_ep_irq(struct usba_udc *udc, struct
usba_ep *ep)
if ((epstatus & epctrl) & USBA_RX_BK_RDY) {
DBG(DBG_BUS, "%s: RX data ready\n", ep->ep.name);
receive_data(ep);
- usba_ep_writel(ep, CLR_STA, USBA_RX_BK_RDY);
}
}
--
2.1.0.24.g4109c28
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] usb: chipidea: add one errata for revision 2.40a
Hi all, At the first two patches, I add identification registers APIs, we can get controller's revision by using this APIs. Since I don't have enough spec, if there are any errors, tell me. At the third patch, I implement an errata for revision 2.40a, hope it can fix the problem Sanchayan Maity reported. http://www.spinics.net/lists/linux-usb/msg118544.html @Sanchayan, would you please have a test? Peter Chen (3): usb: chipidea: add identification registers access APIs usb: chipidea: add chipidea revision information usb: chipidea: udc: add errata for revision 2.40a drivers/usb/chipidea/bits.h | 10 + drivers/usb/chipidea/ci.h | 53 + drivers/usb/chipidea/core.c | 23 ++-- drivers/usb/chipidea/udc.c | 18 ++- 4 files changed, 101 insertions(+), 3 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] usb: chipidea: add identification registers access APIs
Using hw_write_id_reg and hw_read_id_reg to write and read identification
registers contents, they can be used to get controller information, change
some system configurations, and so on.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/ci.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 65913d4..62948d0 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -29,6 +29,15 @@
/**
* REGISTERS
*/
+/* Identification Registers */
+#define ID_ID 0x0
+#define ID_HWGENERAL 0x4
+#define ID_HWHOST 0x8
+#define ID_HWDEVICE0xc
+#define ID_HWTXBUF 0x10
+#define ID_HWRXBUF 0x14
+#define ID_SBUSCFG 0x90
+
/* register indices */
enum ci_hw_regs {
CAP_CAPLENGTH,
@@ -248,6 +257,36 @@ static inline void ci_role_stop(struct ci_hdrc *ci)
}
/**
+ * hw_read_id_reg: reads from a identification register
+ * @ci: the controller
+ * @offset: offset from the beginning of identification registers region
+ * @mask: bitfield mask
+ *
+ * This function returns register contents
+ */
+static inline u32 hw_read_id_reg(struct ci_hdrc *ci, u32 offset, u32 mask)
+{
+ return ioread32(ci->hw_bank.abs + offset) & mask;
+}
+
+/**
+ * hw_write_id_reg: writes to a identification register
+ * @ci: the controller
+ * @offset: offset from the beginning of identification registers region
+ * @mask: bitfield mask
+ * @data: new value
+ */
+static inline void hw_write_id_reg(struct ci_hdrc *ci, u32 offset,
+ u32 mask, u32 data)
+{
+ if (~mask)
+ data = (ioread32(ci->hw_bank.abs + offset) & ~mask)
+ | (data & mask);
+
+ iowrite32(data, ci->hw_bank.abs + offset);
+}
+
+/**
* hw_read: reads from a hw register
* @ci: the controller
* @reg: register index
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] usb: chipidea: add chipidea revision information
Define ci_get_revision API to know the controller revision
information according to chipidea 1.1a, 2.0a and 2.5a spec.
Besides, add one entry at struct ci_hdrc to indicate revision
information, it can be used for adding different code for
revisions, eg kinds of errata.
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/bits.h | 10 ++
drivers/usb/chipidea/ci.h | 14 ++
drivers/usb/chipidea/core.c | 23 +--
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
index ca57e3d..e935ccc 100644
--- a/drivers/usb/chipidea/bits.h
+++ b/drivers/usb/chipidea/bits.h
@@ -15,6 +15,16 @@
#include
+/*
+ * ID
+ * For 1.x revision, bit24 - bit31 are reserved
+ * For 2.x revision, bit25 - bit28 are 0x2
+ */
+#define TAG(0x1F << 16)
+#define REVISION (0xF << 21)
+#define VERSION(0xF << 25)
+#define CIVERSION (0x7 << 29)
+
/* HCCPARAMS */
#define HCCPARAMS_LEN BIT(17)
diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 62948d0..971a0f5 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -106,6 +106,18 @@ enum ci_role {
CI_ROLE_END,
};
+enum CI_REVISION {
+ CI_REVISION_1X = 10,/* Revision 1.x */
+ CI_REVISION_20 = 20, /* Revision 2.0 */
+ CI_REVISION_21, /* Revision 2.1 */
+ CI_REVISION_22, /* Revision 2.2 */
+ CI_REVISION_23, /* Revision 2.3 */
+ CI_REVISION_24, /* Revision 2.4 */
+ CI_REVISION_25, /* Revision 2.5 */
+ CI_REVISION_25_PLUS, /* Revision above than 2.5 */
+ CI_REVISION_UNKNOWN = 99, /* Unknown Revision */
+};
+
/**
* struct ci_role_driver - host/gadget role driver
* @start: start this role
@@ -178,6 +190,7 @@ struct hw_bank {
* @b_sess_valid_event: indicates there is a vbus event, and handled
* at ci_otg_work
* @imx28_write_fix: Freescale imx28 needs swp instruction for writing
+ * @rev: The revision number for controller
*/
struct ci_hdrc {
struct device *dev;
@@ -220,6 +233,7 @@ struct ci_hdrc {
boolid_event;
boolb_sess_valid_event;
boolimx28_write_fix;
+ enum CI_REVISIONrev;
};
static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 4f3c5a0..efafef3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -137,6 +137,22 @@ static int hw_alloc_regmap(struct ci_hdrc *ci, bool is_lpm)
return 0;
}
+static enum CI_REVISION ci_get_revision(struct ci_hdrc *ci)
+{
+ int ver = hw_read_id_reg(ci, ID_ID, VERSION) >> __ffs(VERSION);
+ enum CI_REVISION rev = CI_REVISION_UNKNOWN;
+
+ if (ver == 0x2) {
+ int rev_reg = hw_read_id_reg
+ (ci, ID_ID, REVISION) >> __ffs(REVISION);
+ rev = rev_reg + CI_REVISION_20;
+ } else if (ver == 0x0) {
+ rev = CI_REVISION_1X;
+ }
+
+ return rev;
+}
+
/**
* hw_read_intr_enable: returns interrupt enable register
*
@@ -251,8 +267,11 @@ static int hw_device_init(struct ci_hdrc *ci, void __iomem
*base)
/* Clear all interrupts status bits*/
hw_write(ci, OP_USBSTS, 0x, 0x);
- dev_dbg(ci->dev, "ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n",
- ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
+ ci->rev = ci_get_revision(ci);
+
+ dev_dbg(ci->dev,
+ "ChipIdea HDRC found, revision: %d, lpm: %d; cap: %p op: %p\n",
+ ci->rev, ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
/* setup lock mode ? */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: chipidea: udc: add errata for revision 2.40a
At chipidea revision 2.40a, there is a below errata:
9000531823 B2-Medium Adding a dTD to a Primed Endpoint May Not Get
Recognized
Title: Adding a dTD to a Primed Endpoint May Not Get Recognized
Impacted Configuration: All device mode configurations.
Description:
There is an issue with the add dTD tripwire semaphore (ATDTW bit in USBCMD
register)
that can cause the controller to ignore a dTD that is added to a primed
endpoint.
When this happens, the software can read the tripwire bit and the status bit at
'1'
even though the endpoint is unprimed.
After executing a dTD, the device controller endpoint state machine executes a
final
read of the dTD terminate bit to check if the application added a dTD to the
linked
list at the last moment. This read is done in the finpkt_read_latest_next_td
(44) state.
After the read is performed, if the terminate bit is still set, the state
machine moves
to unprime the endpoint. The decision to unprime the endpoint is done in the
checkqh_decision (59) state, based on the value of the terminate bit.
Before reaching the checkqh_decision state, the state machine traverses the
writeqhtd_status (57), writeqh_status (56), and release_prime_mask (42) states.
As shown in the waveform, the ep_addtd_tripwire_clr signal is not set to clear
the tripwire bit in these states.
Workaround: The software must implement a periodic poll cycle, and check for
each dTD
pending on execution (Active = 1), if the enpoint is primed. It can do this by
reading
the corresponding bits in the ENDPTPRIME and ENDPTSTAT registers. If these bits
are
read at 0, the software needs to re-prime the endpoint by writing 1 to the
corresponding
bit in the ENDPTPRIME register. This can be done for every microframe, every
frame or
with a larger interval, depending on the urgency of transfer execution for the
application.
Cc: Sanchayan Maity
Signed-off-by: Peter Chen
---
drivers/usb/chipidea/udc.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index c0754be..aefc1ae 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -201,7 +201,7 @@ static int hw_ep_prime(struct ci_hdrc *ci, int num, int
dir, int is_ctrl)
if (is_ctrl && dir == RX && hw_read(ci, OP_ENDPTSETUPSTAT, BIT(num)))
return -EAGAIN;
- /* status shoult be tested according with manual but it doesn't work */
+ /* status should be tested according with manual but it doesn't work */
return 0;
}
@@ -522,6 +522,19 @@ static void free_pending_td(struct ci_hw_ep *hwep)
kfree(pending);
}
+static int reprime_dtd(struct ci_hdrc *ci, struct ci_hw_ep *hwep)
+{
+ int n = hw_ep_bit(hwep->num, hwep->dir);
+
+ /* Only do re-prime when both ENDPTPRIME bit and ENDPTSTAT bit are 0 */
+ if (hw_read(ci, OP_ENDPTPRIME, BIT(n)) ||
+ hw_read(ci, OP_ENDPTSTAT, BIT(n)))
+ return 0;
+
+ return hw_ep_prime(ci, hwep->num, hwep->dir,
+ hwep->type == USB_ENDPOINT_XFER_CONTROL);
+}
+
/**
* _hardware_dequeue: handles a request at hardware level
* @gadget: gadget
@@ -535,6 +548,7 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct
ci_hw_req *hwreq)
struct td_node *node, *tmpnode;
unsigned remaining_length;
unsigned actual = hwreq->req.length;
+ struct ci_hdrc *ci = hwep->ci;
if (hwreq->req.status != -EALREADY)
return -EINVAL;
@@ -544,6 +558,8 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct
ci_hw_req *hwreq)
list_for_each_entry_safe(node, tmpnode, &hwreq->tds, td) {
tmptoken = le32_to_cpu(node->ptr->token);
if ((TD_STATUS_ACTIVE & tmptoken) != 0) {
+ if (ci->rev == CI_REVISION_24)
+ reprime_dtd(ci, hwep);
hwreq->req.status = -EALREADY;
return -EBUSY;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: hcd: add OTG ID signal sensing
Hello. On 12/17/2014 5:08 AM, Peter Chen wrote: On the Renesas R8A7791 SoC based boards there's MAX3355 USB OTG chip and mini-AB USB connector corresponding to USB port 0 driven either by EHCI/OHCI or Renesas USBHS gadget controller. And we'd like the host/gadget drivers to work based on the cable type connected. An 'extcon' driver for MAX3355 has been written, so we only need to bind to it via device tree which I'm doing in this patch. I wasn't able to find a solution better than checking the cable type at the host driver probe time and refusing to drive a host if B-cable is connected. You may need a dual-role/otg driver to do it, which can enable host/device function according to ID pin. It would have been too good if I had a dual-role controller. :-) But I have what I have. IIUC, such configuration (OHCI and UDC sharing a USB port) has been used on OMAP1. WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] usb: chipidea: add one errata for revision 2.40a
On 12/17/2014 02:05 PM, Peter Chen wrote: > Hi all, > > At the first two patches, I add identification registers APIs, we can get > controller's revision by using this APIs. Since I don't have enough spec, > if there are any errors, tell me. > > At the third patch, I implement an errata for revision 2.40a, hope it can fix > the problem Sanchayan Maity reported. > > http://www.spinics.net/lists/linux-usb/msg118544.html > > @Sanchayan, would you please have a test? > > Peter Chen (3): > usb: chipidea: add identification registers access APIs > usb: chipidea: add chipidea revision information > usb: chipidea: udc: add errata for revision 2.40a > > drivers/usb/chipidea/bits.h | 10 + > drivers/usb/chipidea/ci.h | 53 > + > drivers/usb/chipidea/core.c | 23 ++-- > drivers/usb/chipidea/udc.c | 18 ++- > 4 files changed, 101 insertions(+), 3 deletions(-) > Thanks for the patches. I tested the patches with iperf and tried a few times to be sure. The condition is still the same. -Sanchayan. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] usb: chipidea: add one errata for revision 2.40a
On Wed, Dec 17, 2014 at 05:31:40PM +0530, Sanchayan Maity wrote: > On 12/17/2014 02:05 PM, Peter Chen wrote: > > Hi all, > > > > At the first two patches, I add identification registers APIs, we can get > > controller's revision by using this APIs. Since I don't have enough spec, > > if there are any errors, tell me. > > > > At the third patch, I implement an errata for revision 2.40a, hope it can > > fix > > the problem Sanchayan Maity reported. > > > > http://www.spinics.net/lists/linux-usb/msg118544.html > > > > @Sanchayan, would you please have a test? > > > > Peter Chen (3): > > usb: chipidea: add identification registers access APIs > > usb: chipidea: add chipidea revision information > > usb: chipidea: udc: add errata for revision 2.40a > > > > drivers/usb/chipidea/bits.h | 10 + > > drivers/usb/chipidea/ci.h | 53 > > + > > drivers/usb/chipidea/core.c | 23 ++-- > > drivers/usb/chipidea/udc.c | 18 ++- > > 4 files changed, 101 insertions(+), 3 deletions(-) > > > > Thanks for the patches. > > I tested the patches with iperf and tried a few times to be sure. The > condition is > still the same. > Oh, bad luck. Be sure the code I added for 2.40a is ran at your board. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc2: add support for initial state for dual-role mode
DWC2 module on Exynos SoCs is used only as peripheral controller (UDC),
so add support for selecting default initial state for dual-role mode. The
default init mode can be overridden by device tree 'dr_mode' property.
This patch enables to use usb gadget on Exynos SoCs, when DWC2 driver has
been compiled as 'dual-role driver'.
Signed-off-by: Marek Szyprowski
---
drivers/usb/dwc2/core.h | 3 +++
drivers/usb/dwc2/platform.c | 62 ++---
2 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 7a70a13..b0fed4e 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -354,6 +354,7 @@ struct dwc2_core_params {
int reload_ctl;
int ahbcfg;
int uframe_sched;
+ int default_dr_mode;
};
/**
@@ -570,6 +571,8 @@ struct dwc2_hsotg {
struct dwc2_core_params *core_params;
enum usb_otg_state op_state;
enum usb_dr_mode dr_mode;
+ unsigned int hcd_enabled:1;
+ unsigned int gadget_enabled:1;
struct phy *phy;
struct usb_phy *uphy;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 6a795aa..8abf437 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -76,6 +76,7 @@ static const struct dwc2_core_params params_bcm2835 = {
.reload_ctl = 0,
.ahbcfg = 0x10,
.uframe_sched = 0,
+ .default_dr_mode= USB_DR_MODE_OTG,
};
static const struct dwc2_core_params params_rk3066 = {
@@ -104,6 +105,36 @@ static const struct dwc2_core_params params_rk3066 = {
.reload_ctl = -1,
.ahbcfg = 0x7, /* INCR16 */
.uframe_sched = -1,
+ .default_dr_mode= USB_DR_MODE_OTG,
+};
+
+static const struct dwc2_core_params params_s3c_hsotg = {
+ .otg_cap= -1,
+ .otg_ver= -1,
+ .dma_enable = 0,
+ .dma_desc_enable= 0,
+ .speed = -1,
+ .enable_dynamic_fifo= -1,
+ .en_multiple_tx_fifo= -1,
+ .host_rx_fifo_size = -1,
+ .host_nperio_tx_fifo_size = -1,
+ .host_perio_tx_fifo_size= -1,
+ .max_transfer_size = -1,
+ .max_packet_count = -1,
+ .host_channels = -1,
+ .phy_type = -1,
+ .phy_utmi_width = -1,
+ .phy_ulpi_ddr = -1,
+ .phy_ulpi_ext_vbus = -1,
+ .i2c_enable = -1,
+ .ulpi_fs_ls = -1,
+ .host_support_fs_ls_low_power = -1,
+ .host_ls_low_power_phy_clk = -1,
+ .ts_dline = -1,
+ .reload_ctl = -1,
+ .ahbcfg = -1,
+ .uframe_sched = -1,
+ .default_dr_mode= USB_DR_MODE_PERIPHERAL,
};
/**
@@ -121,8 +152,10 @@ static int dwc2_driver_remove(struct platform_device *dev)
{
struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
- dwc2_hcd_remove(hsotg);
- s3c_hsotg_remove(hsotg);
+ if (hsotg->hcd_enabled)
+ dwc2_hcd_remove(hsotg);
+ if (hsotg->gadget_enabled)
+ s3c_hsotg_remove(hsotg);
return 0;
}
@@ -131,7 +164,7 @@ static const struct of_device_id dwc2_of_match_table[] = {
{ .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
{ .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
{ .compatible = "snps,dwc2", .data = NULL },
- { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
+ { .compatible = "samsung,s3c6400-hsotg", .data = ¶ms_s3c_hsotg },
{},
};
MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
@@ -211,15 +244,26 @@ static int dwc2_driver_probe(struct platform_device *dev)
(unsigned long)res->start, hsotg->regs);
hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
+ if (hsotg->dr_mode == USB_DR_MODE_UNKNOWN &&
+ params->default_dr_mode > USB_DR_MODE_UNKNOWN)
+ hsotg->dr_mode = params->default_dr_mode;
spin_lock_init(&hsotg->lock);
mutex_init(&hsotg->init_mutex);
- retval = dwc2_gadget_init(hsotg, irq);
- if (retval)
- return retval;
- retval = dwc2_hcd_init(hsotg, irq, params);
- if (retval)
- return retval;
+
+ if (hsotg->dr_mode != USB_DR_MODE_HOST) {
+ retval = dwc2_gadget_init(hsotg, irq);
+ if (retval)
+ return retval;
+ hsotg->gadget_enabled = 1;
+ }
+
+ if (hsotg->dr_mode != USB_DR_MODE_PERIPHERA
bugreport: Netdev watchdog timeout on wwan0, huawei E3276 modem always fails on GSM UDP up/downlink iperf3
Problem: up/dowlink UDP with iperf3 over GSM crashes Huawei E3276 USB modem on 32-bit Debian-stable (wheezy) with 3.13 kernel and newer kernels. Error also seen on 64-bit machines/Linux kernels. Keywords: huawei_cdc_ncm, GSM, cdc-wdm, wwan0, netdev watchdog Detailed problem description: Sending/receiving UDP 100+100kbit/s up-and-downlink UDP traffic with 2 iperf3 processes over a Huawei E3276 USB modem in GSM mode (GSM RAT) *always* fails after 3-15 minutes. Modem disconnects and kernel log shows 'NETDEV WATCHDOG: wwan0 (huawei_cdc_ncm): transmit queue 0 timed out'. Reproduced on a range of real and virtualized systems, all running Debian or Kubuntu Linux with Linux kernel supporting the modem (3.13 and higher). Output below is from a debian-jessie (unstable) system with custom-built dbg kernel, but debian wheezy (stable) also reproduces same bug. A clean way to reproduce is to use a clean debian wheezy install and only adding iperf3 and a 3.16 kernel from debian-unstable. At the end of this post I paste an excerpt from kern.log, if more logs etc are needed I can provide them. Command line of test application (showing uplink iperf UDP/GSM, downlink is the same but with -R switch): './iperf3 -B -u -t 3600 -i 5 -p 5503 -b 100K -c ' Distribution: debian-unstable Kernel version: 3.16.7, vanilla debian unstable 3.17.0-trunk-686-pae, 3.17.2. All kernels that support the E3276 modem (kernels from 3.13 and upward) seem to fail. Kernel modules: huawei_cdc_ncm, cdc_ncm, cdc_wdm, usb_wwan Modem firmware version: 21.436.03.00.00 Lsusb showing modem/vendor id: Bus 003 Device 027: ID 12d1:1506 Huawei Technologies Co., Ltd. E398 LTE/UMTS/GSM Modem/Networkcard Output of lsb_release -a: Distributor ID: Debian Description:Debian GNU/Linux 8.0 (jessie) Release:8.0 Codename: jessie Additional info: E3276 modem seems to be stable in Windows, so it may be an issue with the huawei_cdc_ncm driver in Linux. But it may still be a modem hw/firmware issue, and the netdev watchdog timeout on wwan0 could be caused by modem firmware crash. Modem also works much better in Linux when using 3G (WCDMA) or 4G (LTE) instead of 2G (GSM). Merry Christmas, /Erik Alapää Excerpt from kern.log: Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877612] [ cut here ] Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877647] WARNING: CPU: 0 PID: 0 at /build/linux-n7UL8Q/linux-3.17.4/net/sched/sch_generic.c:264 dev_watchdog+0x1ec/0x200() Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877649] NETDEV WATCHDOG: wwan0 (huawei_cdc_ncm): transmit queue 0 timed out Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877650] Modules linked in: huawei_cdc_ncm nls_utf8 udf isofs crc_itu_t ppdev lp rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc loop cdc_wdm option usb_storage usb_wwan cdc_ncm usbserial usbnet snd_ens1371 snd_seq_midi snd_seq_midi_event snd_rawmidi ecb btusb bluetooth rfkill snd_ac97_codec snd_pcm snd_seq snd_seq_device snd_timer snd coretemp soundcore psmouse vmw_balloon ac97_bus serio_raw crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul ablk_helper cryptd evdev gameport pcspkr parport_pc parport vmwgfx shpchp ttm drm_kms_helper drm i2c_piix4 i2c_core processor thermal_sys vmw_vmci button battery ac ext4 crc16 mbcache jbd2 sr_mod cdrom sg ata_generic hid_generic usbhid hid sd_mod crc_t10dif crct10dif_common crc32c_intel floppy ehci_pci uhci_hcd ehci_hcd pcnet32 mii usbcore usb_common ata_piix mptspi scsi_transport_spi mptscsih mptbase libata scsi_mod [last unloaded: huawei_cdc_ncm] Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877768] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-trunk-686-pae #1 Debian 3.17.4-1~exp1 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877769] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.80] de409ef4 c149bcff de409f04 c10598a8 c15d8868 de409f20 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.82] c15d88a4 0108 c13de8bc 0108 c13de8bc 0009 db25b800 fff09a96 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.83] fb7e de409f0c c10598f3 0009 de409f04 c15d8868 de409f20 de409f40 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.85] Call Trace: Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877780] [] ? dump_stack+0x3e/0x4e Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877785] [] ? warn_slowpath_common+0x88/0xa0 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877787] [] ? dev_watchdog+0x1ec/0x200 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877788] [] ? dev_watchdog+0x1ec/0x200 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877789] [] ? warn_slowpath_fmt+0x33/0x40 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877790] [] ? dev_watchdog+0x1ec/0x200 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877796] [] ? call_timer_fn+0x30/0x100 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.877799] [] ? __wake_up+0x37/0x50 Dec 15 13:12:10 vmw-wheezy kernel: [ 4336.
RE: PROBLEM: USB isochronous urb leak on EHCI driver
>> >> My configuration: >> - >> >> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) >> Linux >> kernel: 2.6.31, using EHCI USB driver >> Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) >> Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) >> >> Note: each codec is being used in R/W access, so with 4 codecs, I have >> 4 playback and 4 capture streams. >> >> My problem: >> --- >> >> I have usb urb leaks when connecting more than 1 codec to the USB 1.1 Hub. >> (the result is that some of the audio data is not transferred, part of >> the sound is simply missing) No problem when using only 1 of the 4 >> codecs connected to the hub; When I connect a second codec, the sound >> quality starts to degrade. With >> 3 codecs, we just cannot recognize a speach. >> >> Tests and observations: >> --- >> >> Since I have 3 usb ports available on the i.MX512, I tried to connect >> 3 codecs directly on USB ports: the sound is perfect on each of the three >> ports. >> >> I bought a consumer USB 2.0 Hub: no problem when using 3 codecs >> connected to that Hub, however, the audio will completly stop on all >> channels when connecting the 4th codec. >> >> I checked the communication between the Hub (USB 1.1) and the Host >> controller (USB 2.0) with a scope and concluded that the communication >> speed is 1.5 MBytes/s has expected (so the communication is downgraded >> to USB 1.1, since codecs and hub are USB >> 1.1 devices). >> >> Also, I know that there is physically enough bandwidth to transfer the >> data for two reasons: >> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI >> driver), using the same hub and the same codecs: works like a champ, >> using less than 50% of the available bandwidth (observed with a >> scope) >> 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s, >> 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s) >> >> I noticed that my sound problem starts happening with only 2 codecs >> (4 streams, 256 kB/s). I first thought that it was a bandwidth >> limitation, so I decided to connect only 1 codec using more bandwidth. >> I configured it to 48khz-stereo (16-bits), using 384 kB/s for both >> read and write >> streams: no problem. With that configuration, the scope shows about >> 30% of total bandwidth usage (300us used out of 1ms periods). Then, I >> added a second codec (48khz-stereo-16bits): very strange, now the >> total bandwidth usage felt down to about 200us, which seems to keep >> the same, whatever the number of codec I add (I also tried 3 and >> 4...). So it looks like the scheduler is not able to properly allocate >> Isochronous time slots when more than one device is connected to the >> hub. However, without the hub, it works perfectly. >> > > I am wonder if it is similar problem I met when using multiple interrupt > transfers, when you find you lose the data, try to run 'top' to show cpu > utilization, if > it is close to 100%, it means the ehci can't queue request > in time, so the host can't send IN token in time. > > Using a USB bus analyzer can also verify it. > > Peter Thanks Peter, I did it, the CPU usage varies between 0% and 4% so this is not the case here. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] usb: host: f_usb20ho: add support for Fujitsu ehci/ohci USB 2.0 host controller
On Wednesday 17 December 2014 23:33:02 Sneeker. Yeh wrote:
> >
> >No need for playing games with child devices, just see how the other drivers
> >do
> >it.
>
> I am wondering if this is what you mentioned here? :
> Hcd21: f_usb20ho {
> compatible = "fujitsu,f_usb20ho";
> ...
> Ehci {
> compatible = "generic-ehci";
> reg = <>;
> }
> ohci {
> compatible = "generic-ohci";
> reg = <>;
> }
> }
> By doing that, I can just use of_platform_populate() to create platform
> device more gracefully,
> than using platform_device_xxx() those have been done in
> of_platform_populate().
> And also, managing register offset is totally done via dts description, not
> in the code.
What I mean is leaving out the fujitsu,f_usb20ho node entirely, just put the
two USB controllers on the bus directly and remove this driver.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [xhci_hcd] USB3 device unplug breaks system suspend
On Tue, 16 Dec 2014, Tobias Jakobi wrote: > Alan Stern wrote: > > How about providing some information (system logs, etc.)? > > > > Alan Stern > > Hello, > > I've just added dmesg and lsusb output. If you need anything else, > please let me know! You didn't say which device was the one causing the problem. I assume it was the 4-3 device; that's the only thing which appears to be a USB-3 drive. The log doesn't include much useful information, partly because your kernel was built with several debugging flags turned off and partly because there is very little debugging info available for wakeup events. The one thing that stood out was the series of error messages starting at timestamp 129.858. It's hard to tell if they are related to the early wakeup problem. Have you tried unloading or unbinding the xhci-hcd driver before starting the second suspend? 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: PROBLEM: USB isochronous urb leak on EHCI driver
On Mon, 15 Dec 2014, Michael Tessier wrote: > Hi, > > I am dealing with a USB EHCI driver bug. Here is the info: > > My configuration: > - > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) > Linux kernel: 2.6.31, using EHCI USB driver As mentioned by other people, the age of that kernel makes any bug report completely irrelevant. It's hard to count the number of non-trivial changes that have been made to the isochronous code in ehci-hcd since 2.6.31, but there have been quite a few. > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) > > Note: each codec is being used in R/W access, so with 4 codecs, I have > 4 playback and 4 capture streams. > > My problem: > --- > > I have usb urb leaks when connecting more than 1 codec to the USB 1.1 > Hub. What do you mean by "urb leak"? Normally, people use the word "leak" to refer to memory that is dynamically allocated and never deallocated, but you seem to mean something else. > (the result is that some of the audio data is not transferred, > part of the sound is simply missing) No problem when using only 1 > of the 4 codecs connected to the hub; When I connect a second codec, > the sound quality starts to degrade. With 3 codecs, we just cannot > recognize a speach. > > Tests and observations: > --- > > Since I have 3 usb ports available on the i.MX512, I tried to connect > 3 codecs directly on USB ports: the sound is perfect on each of the > three ports. > > I bought a consumer USB 2.0 Hub: no problem when using 3 codecs > connected to that Hub, however, the audio will completly stop on all > channels when connecting the 4th codec. Above you said the sound started to degrade when the second codec was connected; here you say there is no problem when using 3 of them. Which is it? Do you mean that the high-speed hub works better than the full-speed hub? > I checked the communication between the Hub (USB 1.1) and the Host > controller (USB 2.0) with a scope and concluded that the > communication speed is 1.5 MBytes/s has expected (so the > communication is downgraded to USB 1.1, since codecs and hub are USB > 1.1 devices). > > Also, I know that there is physically enough bandwidth to > transfer the data for two reasons: > 1) I have an older CPU with a USB 1.1 host controller (using the OHCI > driver), using the same hub and the same codecs: works like a champ, > using less than 50% of the available bandwidth (observed with a > scope) > 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s, > 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s) The amount of bandwidth available is usually not as much of an issue as the ability of the scheduling alogorithm to divide the bandwidth among the streams. The algorithm is not very smart and it often runs into a wall even when lots of physical bandwidth is still available. > I noticed that my sound problem starts happening with only 2 codecs > (4 streams, 256 kB/s). I first thought that it was a bandwidth > limitation, so I decided to connect only 1 codec using more bandwidth. > I configured it to 48khz-stereo (16-bits), using 384 kB/s for both > read and write streams: no problem. With that configuration, the > scope shows about 30% of total bandwidth usage (300us used out of 1ms > periods). Then, I added a second codec (48khz-stereo-16bits): very > strange, now the total bandwidth usage felt down to about 200us, which > seems to keep the same, whatever the number of codec I add (I also > tried 3 and 4...). So it looks like the scheduler is not able to > properly allocate Isochronous time slots when more than one device is > connected to the hub. However, without the hub, it works perfectly. How does your hardware connect the host controller to a full-speed device? Is there an internal hub (Intel motherboards have used this approach)? Is there a companion USB-1.1 controller (older motherboards from Intel and other companys have used this approach)? Does the EHCI controller have a built-in Transaction Translator (some SOC systems use this approach)? > Another interresting fact is that at application level, the Read and > Write operations are returning the good amount of bytes read/written. > This is not the case at kernel level: I noticed that function > "usb_submit_urb" (from /drivers/usb/core/urb.c) will only tranfer > part of the "urbs" when the sound is degraded. I tried to figure out > where the leak comes from without success. Also, there are no error > messages from kernel so everything appears to work well, excepted > that part of the sound is missing! > > I can't change my hardware (this is in the hand of customers), so > the only possible solution for me is to correct the software. > > I tried to change my ehci driver with the one from kernel 2.6.39.4 > but did not work, same problem. > > Question: > - > > Before attem
Re: [xhci_hcd] USB3 device unplug breaks system suspend
Alan Stern wrote: > You didn't say which device was the one causing the problem. I assume > it was the 4-3 device; that's the only thing which appears to be a > USB-3 drive. Correct, at the moment I'm using a USB3 enclosure with a JMicron ATA-USB bridge. However the same problem already occured with a different USB3 enclosure (ASMedia ATA-USB bridge). I don't have more USB3 device with me at the moment, but I know at least that it doesn't happen with the Logitech USB mouse (hence my guess that it's an issue with xhci_hcd). > The log doesn't include much useful information, partly because your > kernel was built with several debugging flags turned off and partly > because there is very little debugging info available for wakeup > events. The one thing that stood out was the series of error messages > starting at timestamp 129.858. It's hard to tell if they are related > to the early wakeup problem. If you tell me which debugging options I should enable, then I can create more verbose logs. > Have you tried unloading or unbinding the xhci-hcd driver before > starting the second suspend? Not yet, going to give this a try later. With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: [ums-realtek] media change events incorrectly implemented?
Please use Reply-To-All so that your messages get sent to the mailing list as well as to me. On Thu, 11 Dec 2014, Rubén Herrero wrote: > There you go. > > On Thu, Dec 11, 2014 at 8:22 PM, Alan Stern wrote: > > On Tue, 9 Dec 2014, Rubén Herrero wrote: > > > >> With systemd 217, systemd-udevd complains every ~10 seconds (see below). > >> No error shows up on 216. The systemd people claim this is a drivers issue. > >> (See: https://bugs.freedesktop.org/show_bug.cgi?id=86414#c5) > >> > >> >Lennart Poettering: > >> >Seems to be your card reader. The "ums-realtek" kernel USB driver seems to > >> >implement media change events incorrectly. Please contact the > >> >kernel/driver > >> >folks about this, there's little we can do about this from the systemd > >> >side. > > > > What does a usbmon trace show? > > > > Alan Stern The usbmon trace shows that about every 21.3 seconds, the card reader is polled and it reports Not Ready; Medium Not Present. This is appropriate when no card is inserted in the reader, and it does not indicate a medium change. 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: usb2 and usb3 ports drop samples while recording from airspy to /dev/null
On Sat, 13 Dec 2014, Udo van den Heuvel wrote: > Hello, > > I noticed an usb related issue when recording from my airspy device; > so I created a bug in the bugzilla: > https://bugzilla.kernel.org/show_bug.cgi?id=89671 > > Please let me know what info I should add to help find the root cause. What are we supposed to see? The lsusb output in the bug report lists a bunch of devices, but it's not clear which one is the airspy. The bug report says there should be 10 M samples per second. How many bytes are in a sample? 2? The usbmon trace you attached to the bug report shows a bunch of bulk data being transferred in from the device, at an average rate close to 262144 bytes every 10.8 ms. This works out to a little more than 24 MB/s, or 12 MS/s assuming 2 bytes per sample. If the data transfer really was running at 20 MB/s, then 262144 bytes would require 13.11 ms. Since the usbmon trace shows that many bytes coming in every 10.5 - 11 ms (with slight variations due to other loads but almost always less than 11 ms), it's hard to see what could be wrong. Now, maybe the transfer isn't just raw data. Protocol overhead would reduce the total throughput. But since I don't know what the protocol is, all I can tell you is the raw data rate. 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: phy: Restore deferred probing path
On Wed, Dec 17, 2014 at 09:30:03AM +0100, Thierry Reding wrote:
> On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> > failure") broke platforms that rely on deferred probing to order probing
> > of PHY and host controller drivers. The reason is that the commit simply
> > propagates errors from __of_usb_find_phy(), which returns -ENODEV if no
> > PHY has been registered yet for a given device tree node. The only case
> > in which -EPROBE_DEFER would now be returned is if try_module_get() did
> > fail, which does not make sense.
> >
> > The correct thing to do is to return -EPROBE_DEFER if a PHY hasn't been
> > registered yet. The only condition under which it makes sense to return
> > -ENODEV is if the device tree node representing the PHY has been
> > disabled (via the status property) because in that case the PHY will
> > never be registered.
> >
> > This patch addresses the problem by making __of_usb_find_phy() return an
> > appropriate error code while keeping in line with the above-mentioned
> > commit to propagate error codes rather than overwriting them. At the
> > same time the check for a valid PHY is decoupled from the check for the
> > try_module_get() call and a separate error code is returned if the
> > latter fails.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > drivers/usb/phy/phy.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
>
> Ping?
It's the middle of the merge window, we can't do anything until 3.19-rc1
is out at the earliest.
And then my vacation kicks in, so it will be a week or so more after
that :)
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: [xhci_hcd] USB3 device unplug breaks system suspend
On Wed, 17 Dec 2014, Tobias Jakobi wrote: > Alan Stern wrote: > > You didn't say which device was the one causing the problem. I assume > > it was the 4-3 device; that's the only thing which appears to be a > > USB-3 drive. > Correct, at the moment I'm using a USB3 enclosure with a JMicron ATA-USB > bridge. However the same problem already occured with a different USB3 > enclosure (ASMedia ATA-USB bridge). I don't have more USB3 device with > me at the moment, but I know at least that it doesn't happen with the > Logitech USB mouse (hence my guess that it's an issue with xhci_hcd). I don't follow your reasoning. The Logitech mouse is also driven by xhci-hcd, and so is the Azurewave webcam. > > The log doesn't include much useful information, partly because your > > kernel was built with several debugging flags turned off and partly > > because there is very little debugging info available for wakeup > > events. The one thing that stood out was the series of error messages > > starting at timestamp 129.858. It's hard to tell if they are related > > to the early wakeup problem. > If you tell me which debugging options I should enable, then I can > create more verbose logs. I don't know what would be appropriate. Someone more familiar with the xhci-hcd driver might be able to help. It's not always easy to tell why a device sends a wakeup signal. 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] extcon: add MAX3355 driver
Hello.
On 12/17/2014 03:31 AM, Chanwoo Choi wrote:
MAX3355E chip integrates a charge pump and comparators to enable a system with
an integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru the
ID signal from the USB OTG connector. On some Renesas boards, this signal is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller, only
host and gadget USB controllers sharing the same USB bus; however, we'd like
to allow host or gadget drivers to be loaded depending on the cable type, hence
the need for the MAX3355 extcon driver. The Vbus status signals are also wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS# signal
is controlled by the host controllers, there's also the SHDN# signal wired to
GPIO, which should be high for normal operation.
Signed-off-by: Sergei Shtylyov
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
Need manufactor information as following :
-> Maxim MAX3355
Would be Maxim enough? Or perhaps I should use Maxim Integrated [Products]?
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpio = <&gpio2 4 GPIO_ACTIVE_LOW>;
+ maxim,id-gpio = <&gpio5 31 GPIO_ACTIVE_HIGH>;
Kernel already supported the gpio helper function to get gpio from devicetree.
I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
include/linux/of_gpio.h.
gpios = <&gpio2 4 GPIO_ACTIVE_LOW>, <&gpio5 31
GPIO_ACTIVE_HIGH>;
OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
to insist on using this one...
[...]
Index: extcon/drivers/extcon/extcon-max3355.c
===
--- /dev/null
+++ extcon/drivers/extcon/extcon-max3355.c
@@ -0,0 +1,122 @@
+/*
+ * MAX3355 USB OTG chip extcon driver
ditto.
OK, though the other Maxim extcon drivers don't serve as a good example
here...
[...]
+static irqreturn_t max3355_id_irq(int irq, void *dev_id)
+{
+ struct max3355_data *data = dev_id;
+ int id = gpio_get_value(data->id_gpio);
+
+ extcon_set_cable_state(data->edev, "USB-HOST", !id);
You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
function
and then you would set the cable state according to gpio state and flag.
I'm sorry but I just don't see why I have to do it. This is not a generic
GPIO driver, and the polarities of the GPIOs are determined solely by the
MAX3355 specs.
[...]
+static int max3355_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct max3355_data *data;
+ int gpio, irq, ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(struct max3355_data),
+ GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->edev = devm_extcon_dev_allocate(&pdev->dev, max3355_cable);
+ if (IS_ERR(data->edev)) {
+ dev_err(&pdev->dev, "failed to allocate extcon device\n");
+ return PTR_ERR(data->edev);
+ }
+ data->edev->name = kstrdup(np->name, GFP_KERNEL);
+
+ gpio = of_get_named_gpio(np, "maxim,id-gpio", 0);
Use of_get_gpio() or of_get_gpio_flags().
OK, I'll use the first one.
"maxim,id-gpio" property has strong dependency on this driver and it is not
standard.
I indented it to be Maxim specific. Not sure what using the standard
property buys...
+ if (gpio < 0)
+ return gpio;
Need to add error message.
OK for all cases; extcon-gpio.c was probably a bad example...
[...]
+
+ ret = devm_gpio_request_one(&pdev->dev, gpio, GPIOF_DIR_OUT |
+ GPIOF_INIT_HIGH, pde
RE: [PATCH v2] renesas_usbhs: fix platform init error message
Hi,
I'm very sorry for the delayed response.
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi
> Sent: Wednesday, November 05, 2014 8:01 AM
>
> Hi,
>
> On Wed, Nov 05, 2014 at 01:55:17AM +0300, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 11/05/2014 01:53 AM, Felipe Balbi wrote:
> >
> > >>There is a typo ("prove" instead of "probe") in the error message printed
> > >>when
> > >>the platform initialization fails. Replace that word with more fitting
> > >>"init".
> >
> > >>Signed-off-by: Sergei Shtylyov
> >
> > >this actually goes through me, I'll take it in a bit.
> >
> >Er, OK. Could you update MAINTAINERS?
>
> there is no entry for renesas driver in MAINTAINERS.
>
> Shimoda-san, care to send a patch adding yourself or Morimoto-san as
> maintainers for Renesas driver and pointing to my tree in kernel.org ?
I would like to move the renesas_usbhs driver to drivers/usb/gadget/udc somehow.
Because the driver is almost used for a gadget driver.
The driver has a host driver support now. But, it is not used recently.
After that, this MAINTAINERS issue becomes clear, I think.
Felipe-san and Sergei-san, what do you think?
Best regards,
Yoshihiro Shimoda
> Thank you
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb2 and usb3 ports drop samples while recording from airspy to /dev/null
On 2014-12-17 18:25, Alan Stern wrote: > On Sat, 13 Dec 2014, Udo van den Heuvel wrote: > What are we supposed to see? The lsusb output in the bug report lists > a bunch of devices, but it's not clear which one is the airspy. I did not program the tools. But the other devices are keyboard, webcam and some USB erupters. > The bug report says there should be 10 M samples per second. How many > bytes are in a sample? 2? I and Q samples are two bytes each. > Now, maybe the transfer isn't just raw data. Protocol overhead would > reduce the total throughput. But since I don't know what the protocol > is, all I can tell you is the raw data rate. I'll ask some usbmon folks to comment. Kind regards, Udo -- 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: Query regarding USB gadget driver
On Wed, Dec 17, 2014 at 10:04:35AM +0530, Sanchayan Maity wrote: > On 12/17/2014 05:46 AM, Peter Chen wrote: > > On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: > >> On 12/16/2014 02:15 PM, Peter Chen wrote: > >>> On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: > On 12/16/2014 06:16 AM, Peter Chen wrote: > > On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: > >> Hello, > >> > >> On 12/15/2014 07:42 AM, Peter Chen wrote: > >>> On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: > Hello, > > On 12/12/2014 07:21 AM, Peter Chen wrote: > > On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: > >> Hi, > >> > >> On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > >>> Hello, > >>> > >>> I am working on a Freescale Cortex-A5 Vybrid Processor. The chip > >>> core > >>> is clocked at 500MHz and the USB IP core for this is by > >>> Chip-idea. I > >>> am running a 3.18-rc5 kernel on it and trying to use the USB > >>> gadget > >>> functionality. To be more specific the CDC ECM class. Currently, I > >>> cannot use this properly. If I use just "ping" to check, it works > >>> fine, but, after running iperf, even one transaction doesn't > >>> complete > >>> or completes rarely. Checking the CDC Ether interface with > >>> Wireshark > >>> shows, TCP Dup Ack messages and checking the USB bus with > >>> Wireshark, > >>> shows packets with USB Protocol Error -71 at one point and after > >>> that > >>> packets with USB connection Reset -104 error. If it's of any > >>> significance, I have Arch Linux with the 3.18 kernel running on my > >>> laptop with which the Vybrid connects. On the host side, the only > >>> error dmesg shows is "kevent 12 may have been dropped". I guess > >>> this > >>> is connected to the "TCP Previous Segment not captured" and "TCP > >>> Dup > >>> ACK" messages. > >>> > >>> My script for the gadget configuration is as below: > >>> > >>> /bin/mount none /mnt -t configfs > >>> /bin/mkdir /mnt/usb_gadget/g1 > >>> cd /mnt/usb_gadget/g1 > >>> /bin/mkdir configs/c.1 > >>> /bin/mkdir functions/ecm.0 > >>> /bin/mkdir strings/0x409 > >>> /bin/mkdir configs/c.1/strings/0x409 > >>> echo 0xa4a2 > idProduct > >>> echo 0x0525 > idVendor > >>> echo Freescale123 > strings/0x409/serialnumber > >>> echo Freescale > strings/0x409/manufacturer > >>> echo "USB Serial Gadget" > strings/0x409/product > >>> echo "Conf 1" > configs/c.1/strings/0x409/configuration > >>> echo 200 > configs/c.1/MaxPower > >>> ln -s functions/ecm.0 configs/c.1 > >>> echo ci_hdrc.0 > UDC > >>> /sbin/ifconfig usb0 up > >>> /sbin/ifconfig usb0 192.168.1.10 > >>> > >>> I have debug prints in the udc.c and u_ether.c using pr_debug and > >> > >> just a little hint, use any of the dev_*() macros next time, > >> they'll > >> print the device name which helps figuring out which UDC you're > >> using. > >> > >> Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen > >> maintains that one, it really helps adding maintainers to Cc list. > >> > >>> enable them when required using dynamic debug. Without running > >>> iperf, > >>> using ping gives me a sequence of prints as below: > >>> > >>> [ 277.434409] In eth_start_xmit > >>> [ 277.434517] In UDC irq > >>> [ 277.434553] In usb_gadget_giveback_request > >>> [ 277.434567] In tx_complete > >>> [ 277.435443] In UDC irq > >>> [ 277.435477] In usb_gadget_giveback_request > >>> [ 277.435491] In rx_complete > >>> [ 277.435517] In rx_submit > >>> [ 277.435601] In eth_start_xmit > >>> [ 277.436441] In UDC irq > >>> [ 277.436465] In usb_gadget_giveback_request > >>> [ 277.436478] In rx_complete > >>> [ 277.436493] In rx_submit > >>> [ 277.436520] In usb_gadget_giveback_request > >>> [ 277.436533] In tx_complete > >>> [ 278.434865] In eth_start_xmit > >>> [ 278.434959] In UDC irq > >>> [ 278.434993] In usb_gadget_giveback_request > >>> [ 278.435006] In tx_complete > >>> [ 278.435881] In UDC irq > >>> [ 278.435910] In usb_gadget_giveback_request > >>> [ 278.435923] In rx_complete > >>> [ 278.435946] In rx_submit > >>> > >>> After running iperf without debug prints and then enabling before > >>> using ping gives me a sequence
Re: usb2 and usb3 ports drop samples while recording from airspy to /dev/null
On 2014-12-17 18:25, Alan Stern wrote: >> Please let me know what info I should add to help find the root cause. > > What are we supposed to see? The lsusb output in the bug report lists > a bunch of devices, but it's not clear which one is the airspy. Perhaps bus 4, device 10? Udo -- 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: Query regarding USB gadget driver
On 12/18/2014 10:24 AM, Peter Chen wrote: > On Wed, Dec 17, 2014 at 10:04:35AM +0530, Sanchayan Maity wrote: >> On 12/17/2014 05:46 AM, Peter Chen wrote: >>> On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: On 12/16/2014 02:15 PM, Peter Chen wrote: > On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: >> On 12/16/2014 06:16 AM, Peter Chen wrote: >>> On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: Hello, On 12/15/2014 07:42 AM, Peter Chen wrote: > On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: >> Hello, >> >> On 12/12/2014 07:21 AM, Peter Chen wrote: >>> On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: Hi, On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > Hello, > > I am working on a Freescale Cortex-A5 Vybrid Processor. The chip > core > is clocked at 500MHz and the USB IP core for this is by > Chip-idea. I > am running a 3.18-rc5 kernel on it and trying to use the USB > gadget > functionality. To be more specific the CDC ECM class. Currently, I > cannot use this properly. If I use just "ping" to check, it works > fine, but, after running iperf, even one transaction doesn't > complete > or completes rarely. Checking the CDC Ether interface with > Wireshark > shows, TCP Dup Ack messages and checking the USB bus with > Wireshark, > shows packets with USB Protocol Error -71 at one point and after > that > packets with USB connection Reset -104 error. If it's of any > significance, I have Arch Linux with the 3.18 kernel running on my > laptop with which the Vybrid connects. On the host side, the only > error dmesg shows is "kevent 12 may have been dropped". I guess > this > is connected to the "TCP Previous Segment not captured" and "TCP > Dup > ACK" messages. > > My script for the gadget configuration is as below: > > /bin/mount none /mnt -t configfs > /bin/mkdir /mnt/usb_gadget/g1 > cd /mnt/usb_gadget/g1 > /bin/mkdir configs/c.1 > /bin/mkdir functions/ecm.0 > /bin/mkdir strings/0x409 > /bin/mkdir configs/c.1/strings/0x409 > echo 0xa4a2 > idProduct > echo 0x0525 > idVendor > echo Freescale123 > strings/0x409/serialnumber > echo Freescale > strings/0x409/manufacturer > echo "USB Serial Gadget" > strings/0x409/product > echo "Conf 1" > configs/c.1/strings/0x409/configuration > echo 200 > configs/c.1/MaxPower > ln -s functions/ecm.0 configs/c.1 > echo ci_hdrc.0 > UDC > /sbin/ifconfig usb0 up > /sbin/ifconfig usb0 192.168.1.10 > > I have debug prints in the udc.c and u_ether.c using pr_debug and just a little hint, use any of the dev_*() macros next time, they'll print the device name which helps figuring out which UDC you're using. Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen maintains that one, it really helps adding maintainers to Cc list. > enable them when required using dynamic debug. Without running > iperf, > using ping gives me a sequence of prints as below: > > [ 277.434409] In eth_start_xmit > [ 277.434517] In UDC irq > [ 277.434553] In usb_gadget_giveback_request > [ 277.434567] In tx_complete > [ 277.435443] In UDC irq > [ 277.435477] In usb_gadget_giveback_request > [ 277.435491] In rx_complete > [ 277.435517] In rx_submit > [ 277.435601] In eth_start_xmit > [ 277.436441] In UDC irq > [ 277.436465] In usb_gadget_giveback_request > [ 277.436478] In rx_complete > [ 277.436493] In rx_submit > [ 277.436520] In usb_gadget_giveback_request > [ 277.436533] In tx_complete > [ 278.434865] In eth_start_xmit > [ 278.434959] In UDC irq > [ 278.434993] In usb_gadget_giveback_request > [ 278.435006] In tx_complete > [ 278.435881] In UDC irq > [ 278.435910] In usb_gadget_giveback_request > [ 278.435923] In rx_complete > [ 278.435946] In rx_submit > > After running iperf without debug prints and then enabling before
Re: Query regarding USB gadget driver
On Thu, Dec 18, 2014 at 12:25:41PM +0530, Sanchayan Maity wrote: > On 12/18/2014 10:24 AM, Peter Chen wrote: > > On Wed, Dec 17, 2014 at 10:04:35AM +0530, Sanchayan Maity wrote: > >> On 12/17/2014 05:46 AM, Peter Chen wrote: > >>> On Tue, Dec 16, 2014 at 04:15:08PM +0530, Sanchayan Maity wrote: > On 12/16/2014 02:15 PM, Peter Chen wrote: > > On Tue, Dec 16, 2014 at 10:50:59AM +0530, Sanchayan Maity wrote: > >> On 12/16/2014 06:16 AM, Peter Chen wrote: > >>> On Mon, Dec 15, 2014 at 02:59:31PM +0530, Sanchayan Maity wrote: > Hello, > > On 12/15/2014 07:42 AM, Peter Chen wrote: > > On Fri, Dec 12, 2014 at 06:55:36PM +0530, Sanchayan Maity wrote: > >> Hello, > >> > >> On 12/12/2014 07:21 AM, Peter Chen wrote: > >>> On Thu, Dec 11, 2014 at 08:34:45AM -0600, Felipe Balbi wrote: > Hi, > > On Thu, Dec 11, 2014 at 04:08:43PM +0530, Sanchayan Maity wrote: > > Hello, > > > > I am working on a Freescale Cortex-A5 Vybrid Processor. The > > chip core > > is clocked at 500MHz and the USB IP core for this is by > > Chip-idea. I > > am running a 3.18-rc5 kernel on it and trying to use the USB > > gadget > > functionality. To be more specific the CDC ECM class. > > Currently, I > > cannot use this properly. If I use just "ping" to check, it > > works > > fine, but, after running iperf, even one transaction doesn't > > complete > > or completes rarely. Checking the CDC Ether interface with > > Wireshark > > shows, TCP Dup Ack messages and checking the USB bus with > > Wireshark, > > shows packets with USB Protocol Error -71 at one point and > > after that > > packets with USB connection Reset -104 error. If it's of any > > significance, I have Arch Linux with the 3.18 kernel running on > > my > > laptop with which the Vybrid connects. On the host side, the > > only > > error dmesg shows is "kevent 12 may have been dropped". I guess > > this > > is connected to the "TCP Previous Segment not captured" and > > "TCP Dup > > ACK" messages. > > > > My script for the gadget configuration is as below: > > > > /bin/mount none /mnt -t configfs > > /bin/mkdir /mnt/usb_gadget/g1 > > cd /mnt/usb_gadget/g1 > > /bin/mkdir configs/c.1 > > /bin/mkdir functions/ecm.0 > > /bin/mkdir strings/0x409 > > /bin/mkdir configs/c.1/strings/0x409 > > echo 0xa4a2 > idProduct > > echo 0x0525 > idVendor > > echo Freescale123 > strings/0x409/serialnumber > > echo Freescale > strings/0x409/manufacturer > > echo "USB Serial Gadget" > strings/0x409/product > > echo "Conf 1" > configs/c.1/strings/0x409/configuration > > echo 200 > configs/c.1/MaxPower > > ln -s functions/ecm.0 configs/c.1 > > echo ci_hdrc.0 > UDC > > /sbin/ifconfig usb0 up > > /sbin/ifconfig usb0 192.168.1.10 > > > > I have debug prints in the udc.c and u_ether.c using pr_debug > > and > > just a little hint, use any of the dev_*() macros next time, > they'll > print the device name which helps figuring out which UDC you're > using. > > Based on ci_hdrc.0 above, I suppose it's chipidea and Peter Chen > maintains that one, it really helps adding maintainers to Cc > list. > > > enable them when required using dynamic debug. Without running > > iperf, > > using ping gives me a sequence of prints as below: > > > > [ 277.434409] In eth_start_xmit > > [ 277.434517] In UDC irq > > [ 277.434553] In usb_gadget_giveback_request > > [ 277.434567] In tx_complete > > [ 277.435443] In UDC irq > > [ 277.435477] In usb_gadget_giveback_request > > [ 277.435491] In rx_complete > > [ 277.435517] In rx_submit > > [ 277.435601] In eth_start_xmit > > [ 277.436441] In UDC irq > > [ 277.436465] In usb_gadget_giveback_request > > [ 277.436478] In rx_complete > > [ 277.436493] In rx_submit > > [ 277.436520] In usb_gadget_giveback_request > > [ 277.436533] In tx_complete > > [ 278.434865] In eth_start_xmit > > [ 278.434959] In UDC irq > > [ 27
