Thanks for your prompt reply,
I am already using the driver in Slave mode.
The DWC OTG driver is apparently treating interrupt endpoints as non-periodic endpoints. See the set_in_ep_tx_fifo function
+ if (pcd->otg_dev->core_if->en_multiple_tx_fifo) {
+ ep->dwc_ep.tx_fifo_num = assign_tx_fifo(pcd->otg_dev->core_if);
+ } else {
+ ep->dwc_ep.tx_fifo_num = 0;
+
+ /* If ISOC EP then assign a Periodic Tx FIFO. */
+ if ((desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==
+ USB_ENDPOINT_XFER_ISOC)
+ ep->dwc_ep.tx_fifo_num =
+ assign_perio_tx_fifo(pcd->otg_dev->core_if);
+ }
Should that be changed so that both interrupt and isochronous endpoints are assigned periodic transmit fifos?
Carolyn
>-----Original Message-----
>From: Fu-Shen Chen [mailto:fushen.chen@xxxxxxxxx]
>Sent: Thursday, July 15, 2010 1:02 PM
>To: Smith, Carolyn J
>Cc: linux-usb@xxxxxxxxxxxxxxx
>Subject: Re: some questions regarding the Synopsys DWC OTG driver
>
>We are not sure why you are getting mismatch with the Interrupt
>endpoint (Periodic) - according to the spec it is only for
>Non-periodic endpoint (Ctrl & BulK) & with shared fifo.
>
>460EX OTG core is configured to use shared fifo. The one suggestion we
>have would be to *try* the
>driver in Slave mode, because the learning queue is processed in slave
>mode, that might work.
>
>We are submitting the open source patch to make sure the fundamental
>structure of the driver aligns
>with the kernel. Once that is in place, additional patches to fix bugs
>would be easier to do.
>
>Thanks,
>Fushen
>
>On Wed, Jul 14, 2010 at 3:17 PM,
><carolyn.j.smith@xxxxxxxxxxxxx> wrote:
>> I am currently using the Synopsys DWC OTG driver from the
>DENX repository and having some problems with it. I have also
>tried the driver recently posted on this list by Fushen Chen
>and am having the same problems.
>>
>> I am using it on an AMCC 460EX in device mode only with the
>gadgetfs filesystem to implement a gadget that has a control
>endpoint, a bulk IN endpoint, a bulk OUT endpoint and an
>interrupt IN endpoint. It is not unusual to transmit very
>large buffers on the bulk IN endpoint, i.e. 100's of KB.
>>
>> I am running into problems with the "in token received with
>endpoint mismatch" interrupt. I believe that while the
>controller is in the process of transmitting a very large
>buffer on the bulk in endpoint, an IN token arrives for the
>interrupt IN endpoint, thus triggering the interrupt. It also
>looks like functionality for the endpoint mismatch interrupt
>isn't complete in the driver.
>>
>> Can anyone familiar with this driver suggest what I should
>be doing to handle this? The 460EX manual says that the
>application must predict the sequence in which the host sends
>IN tokens. I am pretty sure that this is not possible for my
>application. Should I be looking at making my interrupt IN
>endpoint a periodic endpoint?
>>
>> Thanks,
>> Carolyn Smith
>> Tektronix, Inc.
>> --
>> 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
>>
>
>
--
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
