• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 836 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.

MUSB Controller Interrupts IRQ on AM335x

Avinash Kumar33
Prodigy 160 points


Hi All,

I have been trying to understand the Gadget Driver, Peripheral Controller Driver (SW) and Peripheral Device Controller (HW) interactions in AM335x. The PDC, as I understand is MUSB-HDRC. I can see in the MUSB Controller Datasheet (we got after signing an NDA with TI) that there are at least 3 Interrupt possibilities - INTRUSB, INTRTX and INTRRX. I have the following assumptions and doubts:

1. INTRUSB is called when events such as Connect/Disconnect, Suspend/Resume occur and this comes to the function "musb_stage0_irq" in "musb_core.c". The first doubt is that when I try to see the source of this Interrupt for USB1 - the code tells me it is IRQ No: 35. This is shown as reserved in the AM335x TRM. Am I right in understanding that this Interrupt has been routed here?

2. For the other 2 sources (which I assume should be 2 interrupts) - I could not find any code registering an interrupt or anything in the DTB to show where this interrupt would arrive. Since, I am able to receive and transmit data with a Gadget driver, I'm sure these interrupts should be received by the AM335x, I do not understand how.

Any light on how the MUSB Core interrupts are received and with what IRQ numbers in the AM335x unit would be very helpful. We are working on developing a USB Gadget driver and this is a part of understanding the entire flow.

Thanks in advance,

Best Regards,

Avinash

  • 0
    TI__Guru**** 393215 points

    Hi Avinash,

    What software are you looking at? The AM335X USB has three MPU interrupts connected to the INTC - No. 17, 18 and 19. There is also a wakeup interrupt No. 34.

  • 0
    TI__Guru**** 171781 points

    Avinash,

    It seems you are looking at the very low layers of the stack and did not get the whole picture.

    am33xx.dtsi defines the interrupts: #17 for cppi, #18 for musb0. and #19 for musb1.

    INTRUSB, INTRTX, and INTRRX all come from the same interrupt line, #18 or #19 for each controller.

    The ISR dsps_interrupt() for #18 or #19 is registered in dsps_musb_init() in musb_dsps.c.

    When any of those interrupt happens, dsps_interrupt() might call musb_interrupt() depending on the interrupt signal.

    BTY, unless you are implementing a gadget driver for non-Linux OS, I don't think a Linux gadget driver has to care about this interrupt detail, musb_gadget.c and musb_core.c should take care of it.

  • 0 in reply to Bin Liu
    Prodigy 160 points
    Thank you very much for that insight. I was not paying enough attention to the glue layer and these interactions.
    Yes, I understand that I won't actually be using the Interrupt directly while developing the Gadget driver. The question was more out of curiosity and study.

    Thank you for the prompt and detailed response.
    Regards,
    Avinash