OMAP35x MUSB OTG and EHCI driver:

Hi,

Seems like the question is not understandable, below is the more detailed issue.

Our customer is testing USB-AUDIO with OMAP35x EVM,

in this application they want to transfer the USB-Audio data through Ethernet.

So the the USB-Audio device(Slave) inputs the audio data to OMAP35x through 

USB port (OTG or EHCI) and later the OMAP35x transfer this data over Ethernet.

But unfortunately they have some problem with OTG port as below.

- When receiving the USB-Audio data through OMAP OTG port(USB-Audio->OTG port->OMAP35x),

  if they apply a high load on the CPU,  IN request gets aborted as shown below.

Timestamp/Request

0msec  IN

1msec  IN

2msec  IN

3msec  IN

6msec  IN

7msec  IN

note: there is no IN request for 4msec and 5msec timestamp

Whereas they is no problem with EHCI port.

Timestamp/Request

0msec  IN

1msec  IN

2msec  IN

3msec  IN

4msec  IN

5msec  IN

Please let me know if this is a limitation of OMAP35x's OTG port/driver or anything else to be considered in this case.

Thank you and Regards.

Any answer or suggestion?

One explanation could be the USB Host logic that is made using software for the OTG controller and through hardware for the EHCI controller. The OTG controller is designed to act as an Host or as a Device. As a result, the hardware IP is much more open and most of the data transfer management has to be done in the driver using software. I don't know if this could explain the difference you are seeing but this is definitely something to be taken into account.

Thank you so much.

I shall do some more investigation on this difference.

But I am still wondering if there is any know issue like "Mentor DMA lockup hardware issue"

would cause such difference between OTG and EHCI controller.

Actually the OTG port works fine under normal condition,

but whereas under high CPU load, they are observing noise in the received Audio data.  

Regards.

Paddu,

Can you please provide the details of linux kernel used?

Regards,
Ajay

Hello Ajay,

Thank you for considering this issue. 

Our customer is using Linux kernel(version 2.6.32) and the USB drivers which are provided in the latest PSP 03.00.01.06.

Regards.

Paddu,

The problem description shows that musb as host is not able to send IN tokens intime. The PSP kernel 03.00.01.06 does have necessary feature such as workqueue for completion handler. Have you connected other devices also to musb port ? Please provide the details of the devie tree connected to musb port.

Regards,

Ajay

Hello Ajay,

There are no other devices connected to MUSB other than USB-Audio.

Actually they have experienced the same issue (no IN tokens) even during the normal operating condition (i.e during less load)  

when they run the OMAP+USB-Audio for more than 8 hours.

The probabilty of occurance is less during normal load, whereas it occurs everytime when the load is high.

They are using a test loop running in backaground at highest priority (nice -n -20)

to reproduce this issue.

Regards.

Paddu,

Can you ask your customers to enable double buffering for USB audio endpoint. They would require to change the fifo_cfg table in musb_core.c file.

Regards,

Ajay

Hello Ajay,

We need some clarification about how to change double buffering settings

Will it be fine if the maxpacket is set to 1/2 of its present value and mode = BUF_DOUBLE ? as below.

original:

/* mode 4 - fits in 16KB */

static struct fifo_cfg __initdata mode_4_cfg[] = {

{ .hw_ep_num =  1, .style = FIFO_TX,   .maxpacket = 512, },

{ .hw_ep_num =  1, .style = FIFO_RX,   .maxpacket = 512, },

{ .hw_ep_num =  2, .style = FIFO_TX,   .maxpacket = 512, },

{ .hw_ep_num =  2, .style = FIFO_RX,   .maxpacket = 512, },

{ .hw_ep_num =  3, .style = FIFO_TX,   .maxpacket = 512, },

  ....

  ....

  ....

changed to 

static struct fifo_cfg __initdata mode_4_cfg[] = {

{ .hw_ep_num =  1, .style = FIFO_TX,   .maxpacket = 256, .mode = BUF_DOUBLE,  },

{ .hw_ep_num =  1, .style = FIFO_RX,   .maxpacket = 256, .mode = BUF_DOUBLE, },

{ .hw_ep_num =  2, .style = FIFO_TX,   .maxpacket = 256,  .mode = BUF_DOUBLE, },

  ....

  ....

  ....

Please let me know if this is proper way,,

Thankyou and Regards.

Paddu,

This should be fine but make sure that audio max packet size in descriptor is less than or equal to 256.

Regards,

Ajay

Hello Ajay,

Thank you for the details.

It seems that the double buffering settings doesn't solve the issue.

I am sending you the details through mail, could you please have a look.

Best Regards.

Paddu,

Whats the polling interval of the iso endpoint of usb audio device ?

Regards,

ajay