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 of prints as below
> >>>>>>>>>>> [ 81.989827] In UDC irq
> >>>>>>>>>>> [ 81.989871] In usb_gadget_giveback_request
> >>>>>>>>>>> [ 81.989886] In rx_complete
> >>>>>>>>>>> [ 81.989905] In rx_submit
> >>>>>>>>>>> [ 82.989892] In UDC irq
> >>>>>>>>>>> [ 82.989951] In usb_gadget_giveback_request
> >>>>>>>>>>> [ 82.989967] In rx_complete
> >>>>>>>>>>> [ 82.989992] In rx_submit
> >>>>>>>>>>> [ 83.990064] In UDC irq
> >>>>>>>>>>> [ 83.990126] In usb_gadget_giveback_request
> >>>>>>>>>>> [ 83.990142] In rx_complete
> >>>>>>>>>>> [ 83.990167] In rx_submit
> >>>>>>>>>>> [ 84.990007] In UDC irq
> >>>>>>>>>>> [ 84.990049] In usb_gadget_giveback_request
> >>>>>>>>>>> [ 84.990064] In rx_complete
> >>>>>>>>>>> [ 84.990083] In rx_submit
> >>>>>>>>>>> [ 85.990085] In UDC irq
> >>>>>>>>>>> [ 85.990147] In usb_gadget_giveback_request
> >>>>>>>>>>> [ 85.990163] In rx_complete
> >>>>>>>>>>> [ 85.990188] In rx_submit
> >>>>>>>>>>>
> >>>>>>>>>>> If I force a full speed configuration for this USB client port, I get
> >>>>>>>>>>> a slightly more reliable operation where iperf can run for may be half
> >>>>>>>>>>> an hour or so or almost an hour before it falls through. Putting in a
> >>>>>>>>>>> delay of 100-150 microseconds in eth_start_xmit also improves it like
> >>>>>>>>>>> full speed, but, still not reliable. If I run iperf with debug prints
> >>>>>>>>>>> enable, this gives similar results to full speed config. After the
> >>>>>>>>>>> failure of iperf test, even ping doesn't work. Bringing down this usb0
> >>>>>>>>>>> interface and then up again makes ping work again. I do realize that
> >>>>>>>>>>> putting debug prints or delays like this is not the right thing to do,
> >>>>>>>>>>> especially in ISR, but, just trying to debug. This is my first time
> >>>>>>>>>>> digging in the USB stack.
> >>>>>>>>>>>
> >>>>>>>>>>> Based on the above, it seems there might a subtle bug or race
> >>>>>>>>>>> condition somewhere in the execution call chain which I have not been
> >>>>>>>>>>> able to trace yet. Can someone give me some pointers on how I can dig
> >>>>>>>>>>> and debug further?.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I just tried latest usb-next with i.mx6 platform, it works ok with
> >>>>>>>>> 10 mins iperf bi-direction test.
> >>>>>>>>
> >>>>>>>> We did think that it is probably an issue seen with Vybrids only.
> >>>>>>>>
> >>>>>>>
> >>>>>>> - Check Vybrid errata to see if any missing in code
> >>>>>>
> >>>>>> I had not checked the Vybrid errata. There are two erratas and I think one
> >>>>>> of them might be relevant to the issue.
> >>>>>>
> >>>>>> e6857: Adding dTD to Primed Endpoint may not be recognized
> >>>>>>
> >>>>>
> >>>
> >>> Sorry, I made a mistake, it is a new errata, and does not be included in
> >>> the code. All imx project uses 2.0a or 2.50a which does not need this
> >>> errata, and Vybrid uses 2.40a core which needs this errata, I will do a
> >>> patch for this soon, but before that, would you read your ID register
> >>> ($BASE + 0x0) for me? I would like to confirm if your REVISION value
> >>> is 0100b.
> >>>
> >>
> >> As per the reference manual and also the devmem2 readout of the USB ID register
> >> the value is 0xE481FA05. This gives a Revision number 0x81 for the controller
> >> core and 0x05 for the ID viz. configuration number.
> >>
> >
> > Thanks, Revision Number is bit 21 - bit 24, it is 0100b if your ID value
> > is 0xE481FA05.
> >
>
> I was wondering how you got the numbers exactly. The reference manual shows
> bit 16 - bit 23 as the revision of the controller core, bit 0 - bit 5 as the
> ID and bit 24 - bit 31 are reserved. Just for my own information is there a
> different interpretation as well?
>
> Just to be clear so this confirms that the Vybrid has 2.40 core which needs the
> errata and which is presently not implemented in software, which results in the
> issue we are seeing? Otherwise I will just carry on my testing and also try and
> see if I can implement the errata fix.
>
> Thanks for your inputs.
>
> -Regards,
> Sanchayan.
>
Hi Sanchayan,
Please try below patch to see if it can fix your problem:
>From 602a4db2b18f4451dda5b9365f127eae88ff68fb Mon Sep 17 00:00:00 2001
From: Peter Chen <peter.chen@xxxxxxxxxxxxx>
Date: Thu, 18 Dec 2014 12:47:36 +0800
Subject: [PATCH 1/1] for 2.40a errata
Signed-off-by: Peter Chen <peter.chen@xxxxxxxxxxxxx>
---
drivers/usb/chipidea/udc.c | 28 +++++++++++++++++++++++++++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index c0754be..62b4625 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,18 @@ 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, struct td_node *node)
+{
+ hwep->qh.ptr->td.next = cpu_to_le32(node->ptr->next);
+ hwep->qh.ptr->td.token &=
+ cpu_to_le32(~(TD_STATUS_HALTED|TD_STATUS_ACTIVE));
+
+ wmb(); /* synchronize before ep prime */
+
+ 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 +547,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;
@@ -582,6 +595,19 @@ static int _hardware_dequeue(struct ci_hw_ep *hwep, struct ci_hw_req *hwreq)
list_del_init(&node->td);
}
+/* if (ci->rev == CI_REVISION_24) */
+ while ((hwep->qh.ptr->curr == node->dma)) {
+ if (node->ptr->next != TD_TERMINATE) {
+ 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)))
+ reprime_dtd(ci, hwep, node);
+ }
+ udelay(1);
+ }
+
usb_gadget_unmap_request(&hwep->ci->gadget, &hwreq->req, hwep->dir);
hwreq->req.actual += actual;
--
1.9.1
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
