AM3352: AM3352 endpoint

baoguo xu

Part Number: AM3352

In my am3352 system, connect a USB HUB0(USB2514) on musb-hdrc.0 which has 4 ports. Then connected a USB HUB1(USB2514) on Port1 of HUB0, connected a USB HUB2(USB2514)
on Port2 of HUB0.

Every port of HUB1 connected one FTDI module(USB to 4*UART converter), each UART need 2 endpoint(RX, TX), so each module need 8 endpoint.

Every port of HUB2 connected one AX88772B module(USB to ETH converter), each module need 5 endpoint.

so there is 32 bulk endpoint for HUB1, 4 int endpoint and 16 bulk endpoint for HUB2.

When all UART devices are turned on and sending data at the same time, the following error message will be prompted when I execute the command "ifconfig eth1 up".

"No space left on device"

Is this problem because the maximum number of endpoints is exceeded? Is there a defect in the hardware design?

Here is the relevant USB information:

T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1
P: Vendor=0424 ProdID=2514 Rev= b.b3
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 2mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=01 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms

T: Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0403 ProdID=6011 Rev= 8.00
S: Manufacturer=FTDI
S: Product=Quad RS232-HS
C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

T: Bus=01 Lev=03 Prnt=04 Port=03 Cnt=02 Dev#= 11 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0b95 ProdID=772b Rev= 0.01
S: Manufacturer=ASIX Elec. Corp.
S: Product=AX88772B
S: SerialNumber=000001
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 4mA
I:* If#= 0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=ff Prot=00 Driver=asix
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=160ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms

over 5 years ago

0 Bin Liu over 5 years ago

TI__Guru**** 167581 points

Hi Baoguo,

What is the Linux kernel version?

baoguo xu said:

When all UART devices are turned on and sending data at the same time, the following error message will be prompted when I execute the command "ifconfig eth1 up".

"No space left on device"

Is this problem because the maximum number of endpoints is exceeded?

If you see the following kernel message when this issue happens, the issue is because of running out of hardware endpoints. Otherwise, the root cause is something else.

"... hwep alloc failed for ..."

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

the linux kernel version is 3.2.0

Now， I connect 8 ftdi serial ports, communication is no problem，But when I connect 12, There will be errors in communication。

The following is the relevant kernel debugging information in musb_schedule function.

[ 67.078177]
libpng warning: iCCP: known incorrect sRGB profile
[ 70.947833] musb_schedule , epnum = 1, 1, musb=DF1420E8, hw=DF142424, in=DE0B1540, out=0
[ 70.956502] musb_schedule , epnum = 2, 1, musb=DF1420E8, hw=DF14250C, in=DE0B1600, out=0
[ 70.965152] musb_schedule , epnum = 3, 1, musb=DF1420E8, hw=DF1425F4, in=DE0B1240, out=0
[ 70.973802] musb_schedule , epnum = 4, 1, musb=DF1420E8, hw=DF1426DC, in=DE0B19C0, out=0
[ 70.982451] musb_schedule , epnum = 5, 1, musb=DF1420E8, hw=DF1427C4, in=0, out=0
[ 70.990464] musb_schedule , epnum = 6, 1, musb=DF1420E8, hw=DF1428AC, in=0, out=0
[ 70.998476] musb_schedule , epnum = 7, 1, musb=DF1420E8, hw=DF142994, in=0, out=0
[ 71.006488] musb_schedule , epnum = 8, 1, musb=DF1420E8, hw=DF142A7C, in=0, out=0
[ 71.014501] musb_schedule , epnum = 9, 1, musb=DF1420E8, hw=DF142B64, in=DE0B1200, out=0
[ 71.023151] musb_schedule , epnum = 10, 1, musb=DF1420E8, hw=DF142C4C, in=DF5F3480, out=0
[ 71.031891] musb_schedule , epnum = 11, 1, musb=DF1420E8, hw=DF142D34, in=DF5F3180, out=0
[ 71.040632] musb_schedule , epnum = 12, 1, musb=DF1420E8, hw=DF142E1C, in=DF302940, out=0
[ 71.049373] musb_schedule , epnum = 13, 1, musb=DF1420E8, hw=DF142F04, in=DE0B1AC0, out=DE0B1AC0
[ 71.058751] musb_schedule , epnum = 14, 1, musb=DF1420E8, hw=DF142FEC, in=DE0B1340, out=DE0B1340
[ 71.068157] musb_schedule , epnum = 15, 1, musb=DF1420E8, hw=DF1430D4, in=DE0B17C0, out=DE0B17C0
[ 71.077558]
[ 71.077561]
[ 74.948058] musb_schedule , epnum = 1, 1, musb=DF1420E8, hw=DF142424, in=DE0B1340, out=0
[ 74.956728] musb_schedule , epnum = 2, 1, musb=DF1420E8, hw=DF14250C, in=0, out=0
[ 74.964743] musb_schedule , epnum = 3, 1, musb=DF1420E8, hw=DF1425F4, in=0, out=0
[ 74.972758] musb_schedule , epnum = 4, 1, musb=DF1420E8, hw=DF1426DC, in=0, out=0
[ 74.980773] musb_schedule , epnum = 5, 1, musb=DF1420E8, hw=DF1427C4, in=DE0B1140, out=0
[ 74.989425] musb_schedule , epnum = 6, 1, musb=DF1420E8, hw=DF1428AC, in=DE0B1240, out=0
[ 74.998076] musb_schedule , epnum = 7, 1, musb=DF1420E8, hw=DF142994, in=DE0B1200, out=0
[ 75.006729] musb_schedule , epnum = 8, 1, musb=DF1420E8, hw=DF142A7C, in=DE0B1500, out=0
[ 75.015381] musb_schedule , epnum = 9, 1, musb=DF1420E8, hw=DF142B64, in=DE0B1600, out=0
[ 75.024033] musb_schedule , epnum = 10, 1, musb=DF1420E8, hw=DF142C4C, in=DF5F3480, out=0
[ 75.032775] musb_schedule , epnum = 11, 1, musb=DF1420E8, hw=DF142D34, in=DF5F3180, out=0
[ 75.041518] musb_schedule , epnum = 12, 1, musb=DF1420E8, hw=DF142E1C, in=DF302940, out=0
[ 75.050261] musb_schedule , epnum = 13, 1, musb=DF1420E8, hw=DF142F04, in=DE0B11C0, out=DE0B11C0
[ 75.059641] musb_schedule , epnum = 14, 1, musb=DF1420E8, hw=DF142FEC, in=DE0B1180, out=DE0B1180
[ 75.069065] musb_schedule , epnum = 15, 1, musb=DF1420E8, hw=DF1430D4, in=DE0B17C0, out=DE0B17C0
[ 75.078468]
[ 75.078471]
[ 78.948102] musb_schedule , epnum = 1, 1, musb=DF1420E8, hw=DF142424, in=DE0B1380, out=0
[ 78.956794] musb_schedule , epnum = 2, 1, musb=DF1420E8, hw=DF14250C, in=DE0B1200, out=0
[ 78.965471] musb_schedule , epnum = 3, 1, musb=DF1420E8, hw=DF1425F4, in=DE0B1340, out=0
[ 78.974153] musb_schedule , epnum = 4, 1, musb=DF1420E8, hw=DF1426DC, in=DE0B1600, out=0
[ 78.982827] musb_schedule , epnum = 5, 1, musb=DF1420E8, hw=DF1427C4, in=0, out=0
[ 78.990855] musb_schedule , epnum = 6, 1, musb=DF1420E8, hw=DF1428AC, in=0, out=0
[ 78.998883] musb_schedule , epnum = 7, 1, musb=DF1420E8, hw=DF142994, in=0, out=0
[ 79.006928] musb_schedule , epnum = 8, 1, musb=DF1420E8, hw=DF142A7C, in=0, out=0
[ 79.014966] musb_schedule , epnum = 9, 1, musb=DF1420E8, hw=DF142B64, in=DE0B1480, out=0
[ 79.023649] musb_schedule , epnum = 10, 1, musb=DF1420E8, hw=DF142C4C, in=DF5F3480, out=0
[ 79.032414] musb_schedule , epnum = 11, 1, musb=DF1420E8, hw=DF142D34, in=DF5F3180, out=0
[ 79.041183] musb_schedule , epnum = 12, 1, musb=DF1420E8, hw=DF142E1C, in=DF302940, out=0
[ 79.049959] musb_schedule , epnum = 13, 1, musb=DF1420E8, hw=DF142F04, in=DE0B1500, out=DE0B1500
[ 79.059376] musb_schedule , epnum = 14, 1, musb=DF1420E8, hw=DF142FEC, in=DF7F9A80, out=DF7F9A80
[ 79.068792] musb_schedule , epnum = 15, 1, musb=DF1420E8, hw=DF1430D4, in=DE0B17C0, out=DE0B17C0

This is the usb infomation of FTDI chip:

T: Bus=01 Lev=03 Prnt=03 Port=01 Cnt=02 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0403 ProdID=6011 Rev= 8.00
S: Manufacturer=FTDI
S: Product=Quad RS232-HS
C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=ftdi_sio
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

0 Bin Liu over 5 years ago in reply to baoguo xu

TI__Guru**** 167581 points

Baoguo,

It seems the original TI v3.2 kernel doesn't print the this debug log. Is this added by you? Please share the kernel patch which adds the debug info.

Around which timestamp in the log when the issue happened? Doess the log show before or after the issue happened?

In the 3.2 kernel musb_schedule() please change the line

dev_dbg(musb->controller, "qh %p periodic slot %d\n", qh, best_end);

dev_err(musb->controller, "qh %p periodic slot %d\n", qh, best_end);

which will shows the message when runs out of endpoints.

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

Yes, the debug log is added by myself. The method you mentioned will print a lot of information and cause my app to fail to run.

This is the kernel patch which adds the debug info. The terminal prints the current information regularly every 4 seconds.

static int musb_schedule(
struct musb *musb,
struct musb_qh *qh,
int is_in)
{
int idle;
int best_diff;
int best_end, epnum;
struct musb_hw_ep *hw_ep = NULL;
struct list_head *head = NULL;
u8 toggle;
u8 txtype;
struct urb *urb = next_urb(qh);

/* use fixed hardware for control and bulk */
if (qh->type == USB_ENDPOINT_XFER_CONTROL) {
head = &musb->control;
hw_ep = musb->control_ep;
goto success;
}

/* else, periodic transfers get muxed to other endpoints */

/*
* We know this qh hasn't been scheduled, so all we need to do
* is choose which hardware endpoint to put it on ...
*
* REVISIT what we really want here is a regular schedule tree
* like e.g. OHCI uses.
*/
best_diff = 4096;
best_end = -1;

#if 1 //for test
{
static int testflag=0;
if ((jiffies%400) > 390)
{
if (testflag == 0)
{
testflag = 1;
for (epnum = 1, hw_ep = musb->endpoints + 1;
epnum < musb->nr_endpoints;
epnum++, hw_ep++) {
printk("musb_schedule , epnum = %d, 1, musb=%X, hw=%X, in=%X, out=%X \r\n", epnum,musb, hw_ep, hw_ep->in_qh, hw_ep->out_qh);
}
printk("\r\n\r\n");
}
}
else
{
testflag = 0;
}
}
#endif

for (epnum = 1, hw_ep = musb->endpoints + 1;
epnum < musb->nr_endpoints;
epnum++, hw_ep++) {
int diff;

if (musb_ep_get_qh(hw_ep, is_in) != NULL)
continue;

if (hw_ep == musb->bulk_ep)
continue;

if (is_in)
diff = hw_ep->max_packet_sz_rx;
else
diff = hw_ep->max_packet_sz_tx;
diff -= (qh->maxpacket * qh->hb_mult);

if (diff >= 0 && best_diff > diff) {

/*
* Mentor controller has a bug in that if we schedule
* a BULK Tx transfer on an endpoint that had earlier
* handled ISOC then the BULK transfer has to start on
* a zero toggle. If the BULK transfer starts on a 1
* toggle then this transfer will fail as the mentor
* controller starts the Bulk transfer on a 0 toggle
* irrespective of the programming of the toggle bits
* in the TXCSR register. Check for this condition
* while allocating the EP for a Tx Bulk transfer. If
* so skip this EP.
*/
hw_ep = musb->endpoints + epnum;
toggle = usb_gettoggle(urb->dev, qh->epnum, !is_in);
txtype = (musb_readb(hw_ep->regs, MUSB_TXTYPE)
>> 4) & 0x3;
if (!is_in && (qh->type == USB_ENDPOINT_XFER_BULK) &&
toggle && (txtype == USB_ENDPOINT_XFER_ISOC))
continue;

best_diff = diff;
best_end = epnum;
}
}

/* use bulk reserved ep1 if no other ep is free */
if (best_end < 0 && qh->type == USB_ENDPOINT_XFER_BULK) {
hw_ep = musb->bulk_ep;
if (is_in)
head = &musb->in_bulk;
else
head = &musb->out_bulk;

/* Enable bulk RX/TX NAK timeout scheme when bulk requests are
* multiplexed. This scheme doen't work in high speed to full
* speed scenario as NAK interrupts are not coming from a
* full speed device connected to a high speed device.
* NAK timeout interval is 8 (128 uframe or 16ms) for HS and
* 4 (8 frame or 8ms) for FS device.
*/
if (qh->dev)
qh->intv_reg =
(USB_SPEED_HIGH == qh->dev->speed) ? 8 : 4;
goto success;
} else if (best_end < 0) {
return -ENOSPC;
}

idle = 1;
qh->mux = 0;
hw_ep = musb->endpoints + best_end;
dev_dbg(musb->controller, "qh %p periodic slot %d\n", qh, best_end);
success:
if (head) {
idle = list_empty(head);
list_add_tail(&qh->ring, head);
qh->mux = 1;
}
qh->hw_ep = hw_ep;
qh->hep->hcpriv = qh;
if (idle)
musb_start_urb(musb, is_in, qh);
return 0;
}

This is the log I printed according to your method，So much so that my app doesn't work.

[ 83.868163] musb-hdrc musb-hdrc.0: qh df6da940 periodic slot 2
[ 83.874304] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 3
[ 83.880465] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.886614] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.892778] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.898934] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.905086] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.911236] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.917378] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.923533] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.929693] musb-hdrc musb-hdrc.0: qh df6da940 periodic slot 2
[ 83.935838] musb-hdrc musb-hdrc.0: qh df6da940 periodic slot 2
[ 83.942003] musb-hdrc musb-hdrc.0: qh df6da940 periodic slot 2
[ 83.948162] musb-hdrc musb-hdrc.0: qh df6da940 periodic slot 2
[ 83.954304] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 3
[ 83.960465] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.966614] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.972771] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2
[ 83.978923] musb-hdrc musb-hdrc.0: qh df7efc80 periodic slot 2

0 Bin Liu over 5 years ago in reply to baoguo xu

TI__Guru**** 167581 points

Hi Baoguo,

Thanks for the code.

Please remove my previous debug patch and your debug code, but apply the following kernel patch and let me know if you see the newly added message "... hwep alloc failed for ..." in the kernel dmesg log when the issue happens.

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 802388bb42ba..2efea4188d5c 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2148,10 +2148,6 @@ static int musb_schedule(
                                (USB_SPEED_HIGH == qh->dev->speed) ? 8 : 4;
                goto success;
        } else if (best_end < 0) {
+               dev_err(musb->controller,
+                               "%s hwep alloc failed for %dx%d\n",
+                               musb_ep_xfertype_string(qh->type),
+                               qh->hb_mult, qh->maxpacket);
                return -ENOSPC;
        }

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

Hi Bin,

I added debugging information in your way，When I only connect the serial device, there is no error message output. If I add two more USB to network card devices, it will output an error message

“musb-hdrc musb-hdrc.0: int hwep alloc failed for 1x8.

It seems that the int endpoint has no resources，I do not understand why there is no network card equipment, serial devices will also abnormal communication.

Is the MUSB of AM3352 also limited the number of bulk type endpoints？

0 Bin Liu over 5 years ago in reply to baoguo xu

TI__Guru**** 167581 points

Hi Baoguo,

baoguo xu said:

If I add two more USB to network card devices, it will output an error message

“musb-hdrc musb-hdrc.0: int hwep alloc failed for 1x8.

It seems that the int endpoint has no resources

Yes, there is no hw endpoint for the network device.

baoguo xu said:
I do not understand why there is no network card equipment, serial devices will also abnormal communication.

Do you mean if you don't connect any USB network devices but only attach the FTDI serial devices, the serial device still doesn't work properly? This sounds like a new issue to me. Can you please describe what exactly the serial device doesn't communicate?

baoguo xu said:
Is the MUSB of AM3352 also limited the number of bulk type endpoints？

No.

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

Hi，

When I am not connected to any network devices, only access to ftdi serial devices. If I connect two ftdi devices, each has four UARTS,The communication effect of these 8 UARTS is very good.But when I access three ftdi devices (12 UARTS),the error rate of communication will be very high.It looks like there's something wrong with the reception.This problem doesn't seem to be the cause of the ftdi driver.What are the reasons for this phenomenon？

0 Bin Liu over 5 years ago in reply to baoguo xu

TI__Guru**** 167581 points

Do you mean that you don't see issues when reading/writing to 8 UARTs of the 2 FTDI devices, but the UART error rate is high when reading/writing to 12 UARTs of the 3 FTDI devices?

Can you please provide details of the "error rate of communication"? what is it?

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

I connect an electric meter outside each serial port, and then send commands to meter equipment through ftdi serial port. The meter equipment will respond to a command after receiving the command.At the same time, I record the sending and receiving times of each serial port.When I access 8 serial ports to communicate at the same time, there is no problem. The number of times of sending and receiving is always the same.But when I access 12 serial ports, the number of times each serial port sends and receives will be unequal.

I monitor communication by paralleling the RS485 converter outside the serial port,It is found that the data sent by the serial port is normal, and the meter equipment also responds normally, but the data is not received normally.I think since there is no problem with 8 serial ports, the driver of ftdi should be no problem.Is it because I have too many serial ports, the problem is still the USB endpoint? The USB endpoints of all serial ports are bulk type, and each serial port has two endpoints(in and out).

0 Bin Liu over 5 years ago in reply to baoguo xu

TI__Guru**** 167581 points

So the issue is that the RX data sent from the meters are correct on the UART bus, but your application on AM335x doesn't receive the RX data, right? The issue could be anywhere in the kernel, the USB drivers, FTDI driver, or even the UART drivers.

We would have to debug the kernel to understand where the data are lost. But given that the kernel v3.2 is very old and no longer supported, there isn't much I can help in debug this kernel. But here are a few pointers in checking the MUSB controller driver.

- If you have MUSB CPPI41 DMA enabled in your kernel, please disable it to see if the issue still happens.

- If the issue still happens with CPPI41 DMA disabled, please modify the endpoint settings in variable mode_4_cfg[] in musb_core.c, so that hw_ep_num 10-15 to be the same as 9, then test if the issue still happens:

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index ff17e94ef465..55887ac2a959 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1188,15 +1188,18 @@ static struct musb_fifo_cfg mode_4_cfg[] = {
 { .hw_ep_num =  8, .style = FIFO_RX,   .maxpacket = 512, },
 { .hw_ep_num =  9, .style = FIFO_TX,   .maxpacket = 512, },
 { .hw_ep_num =  9, .style = FIFO_RX,   .maxpacket = 512, },
-{ .hw_ep_num = 10, .style = FIFO_TX,   .maxpacket = 256, },
-{ .hw_ep_num = 10, .style = FIFO_RX,   .maxpacket = 64, },
-{ .hw_ep_num = 11, .style = FIFO_TX,   .maxpacket = 256, },
-{ .hw_ep_num = 11, .style = FIFO_RX,   .maxpacket = 64, },
-{ .hw_ep_num = 12, .style = FIFO_TX,   .maxpacket = 256, },
-{ .hw_ep_num = 12, .style = FIFO_RX,   .maxpacket = 64, },
-{ .hw_ep_num = 13, .style = FIFO_RXTX, .maxpacket = 4096, },
-{ .hw_ep_num = 14, .style = FIFO_RXTX, .maxpacket = 1024, },
-{ .hw_ep_num = 15, .style = FIFO_RXTX, .maxpacket = 1024, },
+{ .hw_ep_num =  10, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num =  10, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num =  11, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num =  11, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num =  12, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num =  12, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num =  13, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num =  13, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num =  14, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num =  14, .style = FIFO_RX,   .maxpacket = 512, },
+{ .hw_ep_num =  15, .style = FIFO_TX,   .maxpacket = 512, },
+{ .hw_ep_num =  15, .style = FIFO_RX,   .maxpacket = 512, },
 };

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

I'm happy to tell you that, the way you told me works. Now I can access 24 serial ports and none of them has a problem. ^_^

Can you explain why?Since these endpoints are shared, why must they all be set like this？

0 Bin Liu over 5 years ago in reply to baoguo xu

TI__Guru**** 167581 points

Baoguo,

I am glad the issue is solved. But do you mean the kernel patch above which adjusts the EP FIFO solves the issue?

What the patch does is re-arranging the EP FIFO memory so that more EPs are suitable to high-speed bulk transfer. However without further debug details to understand the root cause of the original issue, I am unable to explain why providing more EPs for bulk transfer solves the issue. The MUSB driver is implemented in the way that one pair of TX/RX EP (reserved by EP1) handles all bulk transfer requests if no more EP is available for bulk transfers, so without understanding the root cause I cannot explain why the fixes the issue.

0 baoguo xu over 5 years ago in reply to Bin Liu

Prodigy 110 points

Yes， I modify musb_core.c as you told me，then solves the issue.

Processors

Processors forum

AM3352: AM3352 endpoint