• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 102 subscribers
  • Views 247 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

PROCESSOR-SDK-AM69: How to set CPU affinity of GPIO interrupt.

PROCESSOR-SDK-AM69: support for smp_affinity for GPIO interrupts (need function on AM62 as well)

Victor Chan
Intellectual 705 points
Part Number: PROCESSOR-SDK-AM69
Other Parts Discussed in Thread: AM69

Tool/software:

Hello,

Is there any status on setting the smp_affinity for GPIO interrupts for AM69?  I need this same function for AM62.

Thanks,

Victor

  • 0
    TI__Genius 10225 points

    Hi Victor,

    I don't have a status update for the smp_affinity on AM69. I will add to the JIRA ticket to include the AM62. Since they use the same driver, it should be a 1 to 1 change.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    TI__Genius 10225 points

    Hi Victor,

    This feature is not in our roadmap. How necessary is this feature?

    What are you trying to accomplish with it?

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Intellectual 705 points

    My system has a highest priority 2KHz GPIO interrupt.    Since all of our interrupts are now being handled by core 0, we want to move this one interrupt to core 2 since that core currently is not handling any interrupts.

  • 0 in reply to Victor Chan
    TI__Genius 10225 points

    Hi Victor,

    Is it possible to move other interrupts to core 2?

    Additionally, are you seeing latency/jitter issues due to the interrupt?

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Intellectual 705 points

    Hello,

    Our system has two high priority GPIO triggered interrupts.

    One interrupt runs at 2KHz and processing this interrupt will take up on average 250 to 300 usecs.  This does not leave much time left to process other interrupts or threads.  We are seeing latency/jitter. 

    The other interrupt runs at 8KHz if not using DMA. It uses the OSPI bus to read in data from our ASIC.  In test mode, when the other interrupt is not working, I still see corrupt data once in a while due to the other interrupts still running on core 0.  If the 2KHz interrupt is running, then this 8KHz interrupt will not work.  I am trying to get this 8KHz interrupt to use DMA.  This will allow the interrupt rate to go down to 1KHz.  But so far, I am getting corrupt data.

    It is critical that I move both of these interrupts, one to core 1 and one to core 2.  Both of these cores only have the Linux system interrupts.

    Moving the non GPIO interrupts from core 0 to other cores won't solve the problem since my two interrupts can't share core 0 together.

    Thanks,

    Victor

  • 0 in reply to Victor Chan
    TI__Genius 10225 points

    Hi Victor,

    Is it possible for one of the interrupts to be handled by an R5?

    Another question, could the majority of the compute in the 2KHz thread be handled by a main thread instead of within the interrupt?

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Intellectual 705 points
    Hello,
    We have already considered that option but it was not viable for several reasons.
    The 2KHz interrupt uses the GPMC interface.  We don't believe the R5 has access to that controller. And we don't believe the R5 is capable of running the software.  And we really want to move this interrupt away from core 0.
    We used up one R5 for another application.  We can use the second R5 for the 8Hz interrupt but we are not certain that the R5 has access to the OSPI controller.  However, we do want to reserve that second R5 for another application.
    So, having the ability to move the GPIO interrupt to another core will solve two issues with us.
    The 2KHz spends most of the time reading the data from our ASIC via the GPMC and puts it into a structure. The interrupt will wake up a thread to process that data.  This has been our bread and butter implementation for the past 25 years with the exception that is our first implementation using Linux.  The previous systems used a different OS and we were able to move this same GPIO interrupt to a different core.
    Thanks,
    Victor
  • 0 in reply to Victor Chan
    TI__Genius 10225 points

    Hi Victor,

    I see. I will relay this information to the development team, and update you if there any changes in status with the JIRA ticket.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Intellectual 705 points

    I did some more work on the 8KHz interrupt and it appears that I may have issues getting this to work.  This 8KHz interrupt uses the OSPI in QSPI mode to read in data from our ASIC.    This will not work in core 0.  It might work if I can move it to another core.  But doing so will take up 27us sitting on the QSPI waiting for data to transfer which is a huge waste of resources.

    I also tried using DMA to pull in the data.  But the DMA doesn't have a cyclic mode.  It appears that starting the DMA every time at 8KHz results in corrupt data.

    If I can move it to the WakeUp R5 since it is still available, I would.   But I need a GPIO Trigger Interrupt and it appears that the WakeUp R5 has no such capability.  As for the MCU R5, it has been fully utilized to handle data at 200Hz and and there is only free time window of 40usec per interrupt which is not enough time to handle the 8KHz interrupt. 

  • 0 in reply to Victor Chan
    TI__Genius 10225 points

    Hi Victor,

    This thread is beginning to delve into other questions than the smp_affinity question. Please open another E2E thread about the new topics.

    I will update this thread if there are any changes in the smp_affinity JIRA ticket.

    Best,
    Jared