• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 737 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dm8168 USB ISOCHRONOUS TRANSFERS - interrupt pacing

Massimo
Expert 6475 points

question about usb interrupt pacing, using a usb camera as input. DM8168 Linux with eZsdk 5.0.3.

Setting the USBSS_IRQ_DMA_THRESHOLD_RX0_1 register the rate of the cppi41dma_Interrupt ISR is actually reduced, but the rate of pd_cmp_flag interrupt remains the same. From the driver the source code, it’s like if there is a sw workaround related to this interrupt, and we need to serve it at the highest rate anyway. Am I correct?

more details below:

when streaming audio + video data from an external USB webcam, the A8 core has to face a very high IRQ rate, since by default each USB transfer results in an interrupt request.

 On the Netra USB2 port the Inventra MHDRC declares support for Cppi4.1DMA interrupt pacing (see paragraph 24.7.1.1 Subsystem Interrupts of sprugx8.pdf), however, programming the related thresholds was pointless to us, here’s what we tried:

1)      we started setting the USBSS IRQ_DMA_THRESHOLD_XXY_Z to equal tentative values, let’s say 0x03, so for instance, USBSS_IRQ_DMA_THRESHOLD_RX0_1 was set to 0x03030303

2)      we checked that the IRQDMAENABLE_0 register was correctly programmed, and that was already done by ti81xx driver (value was 0xFFFEFFFE)

3)      when profiling the cppi41dma_Interrupt ISR (drivers/usb/musb/ti81xx.c) we correctly saw ONE IRQ of type rx_pkt_cmp_0 every FOUR IRQ’s of type pd_cmp_flag

4)      we then tried to disable the pd_cmp_flag interrupt, which appeared not relevant for processing the dma queues, but that does not work! it looks like the pd_cmp interrupt has to be acknowledged and serviced exactly as the rx/tx_pkt_cmp ones

did we miss something? or is this pacing feature broken in some way?

Thanks, best regards

Massimo

 


  • 0
    TI__Guru**** 170625 points

    Hi Massimo,

    First of all, can you try with our latest EZSDK 5.05.02.00. We have many improvements and bug fixed compared with older EZSDK releases.

    Regards,

    Pavel

  • 0 in reply to Pavel Botev
    TI__Expert 6475 points

    we cannot migrate easily to the latest ezsdk,  it's a pretty big effort. we'll try to compare the source code of the driver to check if something was changed.

    Can you please help me to get the full list of the "known bug fixes" between ezsdk 5.03 and 5.05.02?

    The question I made aims to understand if there is a know silicon limitation related to usb interrupt pacing on dm8168.

    best regards
    Massimo

  • 0 in reply to Massimo
    TI__Guru**** 170625 points

    The known silicon bugs are documented in the DM816x Silicon Errata document (SPRZ329D). There are two bugs related to the USB:

    Advisory 2.1.16 Spurious RX_SOP_STARVATION Interrupt on the First CPPI DMA Rx Descriptor Following USB Module Reset

    Advisory 1.1.15 USB Host Mode Cannot Perform Write Operation to TxFunction/TxHubPort/TxHubAdr Controller Addresses

    The difference in the Linux kernel source code between the different EZSDK versions, can be tracked with looking at the linux kernel patches:

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

    The patches related to the USB are:

    http://arago-project.org/git/projects/?p=linux-omap3.git&a=search&h=refs%2Fheads%2Fti81xx-master&st=commit&s=usb

    You can check whether one of these (or a group of these) will fix the issue.

    BR,

    Pavel

  • 0 in reply to Pavel Botev
    TI__Expert 6475 points

    Hi Pavel,

    from the sources it looks like "interrupt pacing" is a feature not supported by the driver, even if it's highlighted in the TRM.

    we didn't notice any difference about it in drivers/usb/musb

    A couple of functions were defined in drivers/usb/musb/ti81xx.c,  set_frame_threshold() and set_dma_threshold(), but they are not referenced.

    We wonder if there is a known silicon limitation, or driver architecture limitation, or it was jot not prioritized.

    Best regards,

    Massimo

  • 0 in reply to Massimo
    TI__Guru**** 170625 points

    Hi Massimo,

    The USB interrupt pacing feature stated in TRM, is supported by the DM816x USB hardware module, but is not supported from the current PSP USB linux kernel source code.

    The available software features for the USB are stated here:

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_USB_Driver_User_Guide

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_USB_Configuration_Guide

    The "interrupt pacing" is not stated as a supported feature.

    For example, the EMAC module supports interrupt pacing in HW (stated in TRM), and supports interrupt pacing in SW, stated below:

      http://processors.wiki.ti.com/index.php/TI81XX_PSP_Ethernet_Switch_User_Guide

          Interrupt pacing is common for both interfaces

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_04.04.00.01_Feature_Performance_Guide#Ethernet_Driver

    Driver Features

    The driver supports the following features:

    Support for HW interrupt pacing using ethtool interface

    Interrupt pacing feature enabled with pacing interval set to 500usecs (# ethtool -C eth0 rx-usecs 500)

    I will check with the PSP USB team, if there are plans for the 'interrupt pacing' feature to be added in the PSP linux kernel in near future.

    Regards,

    Pavel

  • 0 in reply to Pavel Botev
    TI__Expert 7885 points

    Hi

    This interrupt pacing feature is useful only if musb/cppidma driver supports queueing of multiple usb request . At present the musb/cppi driver supports one request at time, even though mulitple usb request are pending at endpoint pipe, request are handled one by one. At any point of time only one request from ep-pipe is programmed for CPPI DMA for transmit/recieve operation. Next request is programmed completion of current request . The CPPI41 DMA has the capability where multiple transfer PDs (packet descriptors) can be queued and enable the PD completion for last PD. In this logic interrupt pacing will useful to throttle the interrupt load. In current driver design the interrupt pacing logic will not be useful and this feature is not supported.

    Regards

    Ravi B