TMS320DM8168: USB audio support through a hub

Hi Steven,

This PSP4.01.00.02 is very old and it miss some USB patches. Please try to patch your kernel with all USB related patches available from the latest PSP 4.04.00.02 and see if there will be any improvement.

http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/ti81xx-master

Check also if your DM816x device is PG1.x or PG2.x, as PG1.x do not support USB HUB. The PG 1.0 version of TI816x silicon supports only point-point configuration in Mentor USB IP core and hence hub is not supported. Hence only one device can be connected to each port of USB.



Check also the below wiki pages:

processors.wiki.ti.com/.../TI81XX_PSP_04.04.00.02_Release_Notes
processors.wiki.ti.com/.../TI81XX_PSP_04.04.00.02_Feature_Performance_Guide
processors.wiki.ti.com/.../TI81XX_PSP_User_Guide

Regards,
Pavel

Hi Pavel,

Thanks for quick reply.

I have tried the latest kernel in git://arago-project.org/git/projects/linux-omap3.git  ti81xx-master branch

But the result is the same.

Also, I check my DM816x chip is PG2.1(from kernel message : OMAP chip is TI8168 2.1)

The USB HUB function work fine on our custom board at some usages(such as use usb mouse and usb storage through a hub)

So I think USB HUB function is available on our DM816x custom board.

Please notice that the USB audio function only work failed in capture and playback synchronously and force the USB 2.0 HUB work in full speed mode solve it.

It seems there may have some bugs or compatibilities about DM816X MUSB and USB 2.0 HUB while USB device works at full speed mode.

As I mentioned, this issue is similar with the below:

e2e.ti.com/.../328660

But unfortunately it is no answer.

Could you give me some suggestions about this issue? or MUST STOP to support USB audio function through a hub in our DM816x custom board?

Thank you very much.

BR,

Steven

Steven,

I can provide you several hints:

1. Try to reproduce this issue on the DM816x TI EVM. If you can not reproduce on the EVM, then it might be HW malfunction of your custom board

2. Try to enable debug messages in kernel and check if you will have more verbose console output when you run the full duplex audio use case (arecord | aplay). Share the log. Check also the below wiki pages regarding USB debug.

processors.wiki.ti.com/.../USB_Debug_Techniques
processors.wiki.ti.com/.../Usbgeneralpage

3. Try to improve the USB port performance. USB data traffic initiator have programmable pressure control for L3 interconnect and priority control for EMIF. Adjusting these, you can enable USB initiator to get latency and bandwidth it requires.

Regards,
Pavel

Hi Pavel,

Thanks for help.

1. Try to reproduce this issue on the DM816x TI EVM. If you can not reproduce on the EVM, then it might be HW malfunction of your custom board

After test "arecord | aplay" on the EVM, the result is the same.

2. Try to enable debug messages in kernel and check if you will have more verbose console output when you run the full duplex audio use case (arecord | aplay). Share the log. Check also the below wiki pages regarding USB debug.

After enable debug messages, It seems there is no DMA Rx when I run the full duplex audio use case. so there is no audio data for recording.

Also, the alsa record log show snd_pcm_wait() always timeout because there is no audio data.

# arecord -D hw:S20,0 -r 16000 -f S16_LE /root/sp20_16k_mono.wav | aplay -D hw:S20,0 -f CD /root/48k.wav

[    0.000000] cppi41dma_Interrupt 809: CPPI 4.1 IRQ: Tx 0, Rx 0
[    0.000000] cppi41dma_Interrupt 819: CPPI 4.1 IRQ: Tx 200, Rx 0
[    0.000000] usb_process_tx_queue 1544: wait for TxF-EmptyIntr ep10
[    0.000000] ti81xx_interrupt 930: usbintr (4000000) epintr(0)
[    0.000000] ti81xx_interrupt 934: Isr:TxfifoIntr 200
[    0.000000] cppi41_handle_txfifo_intr 1389: txc: givback ep10
[    0.000000] musb_host_tx 1293: OUT/TX10 end, csr 3400, dma
[    0.000000] cppi41_next_tx_segment 553: TX DMA9, accelerated, maxpkt 192, 1 PDs, addr 0xd784e300, len 192
[    0.000000] cppi41_next_tx_segment 607: TX PD ffc7ff40: buf d784e300, len 000000c0, pkt info 14000086
[    0.000000] cppi41_next_tx_segment 615: txs(ffc7ff40 192) enable txFintr
[    0.000000] txfifoempty_intr_enable 596: enable txF intr ep10 coremask 40001f7

when I run the arecord only. DMA Rx interrupt as expect.

# arecord -D hw:S20,0 -r 16000 -f S16_LE /root/sp20_16k_mono.wav

[    0.000000] cppi41dma_Interrupt 809: CPPI 4.1 IRQ: Tx 0, Rx 0
[    0.000000] cppi41dma_Interrupt 819: CPPI 4.1 IRQ: Tx 0, Rx 800
[    0.000000] usb_process_rx_bd 1583: Rx complete: dma channel(11) ep12 len 32
[    0.000000] usb_process_rx_bd 1607: curr_pd=ffc7ff40, len=32, origlen=32,rxch(alen/len)=32/32
[    0.000000] musb_host_rx 1592: <== hw 12 rxcsr 2000, urb actual 0 (+dma 32)
[    0.000000] musb_host_rx 1758: ep 12 dma off, rxcsr 2000, rxcount 0
[    0.000000] musb_advance_schedule 495: ... next ep12 RX urb d9662cc0
[    0.000000] musb_start_urb 277: qh d979d4c0 urb d9662cc0 dev3 ep3in-iso, hw_ep 12, ffc150e0/32
[    0.000000] musb_ep_program 778: <-- hw12 urb d9662cc0 spd2 dev3 ep3in h_addr02 h_port01 bytes 32
[    0.000000] cppi41_next_rx_segment 787: RX DMA11, transparent, maxpkt 32, addr 0xd97e60e0, rec'd 0/32
[    0.000000] musb_ep_program 975: RXCSR12 := 2020
[    0.000000] musb_giveback 350: complete d9794180 snd_complete_urb+0x0/0xa8 (0), dev3 ep3in, 32/32

3. Try to improve the USB port performance. USB data traffic initiator have programmable pressure control for L3 interconnect and priority control for EMIF. Adjusting these, you can enable USB initiator to get latency and bandwidth it requires.

I have no idea for USB data traffic fine tune. Why USB 2.0 HUB in full speed work fine and high speed failed?

After all, I tried to migrate the MUSB driver to kernel version v3.2.  But no luck...the result is the same.

And after googling, I think the answer from SMSC/Microchip may be useful....please refer to e2e.ti.com/.../328660

The physical layer of USB2.0 host controller, most likely will have ehci and uhci (ehci handles High speed USB protocol and uhci handles the FS/LS). I believe the audio device is a full speed device, then:

1) Normal case, the host must handle the FS device using special split transaction that will be routed to TT (transaction translator) inside the USB2512Bi hub.  These transactions will generate FS packets downstream towards the audio device
2) Failing case, the host failed to produce split transactions.  Thus the host now might using high speed (HS) packets  ...no HS is connected downstream. Thus, no response, or the timeout will occurs or unexpected events occur.

When the audio connect directly to the host, it is directly and transparently communicate with uhci controller bypassing ehci as full speed device.  In other case when USB2512Bi (a HS hub), host will connect the hub via ehci controller and must communicate with FS device connected at hub's downstream port with split transaction. That is why when you configured the hub as full speed hub, which will not needed TT, the audio device works fine.

I believe this is a case of (TI) host driver stack issue.

Any help will appreciate!

Thanks

BR,

Steven