SRIO interrupt pacing example

Shivang

Here is a link to a wiki on configuring interrupts. Hope this helps.

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

Elush Shirazpour

SThakkar said:

I use 6678 DSP SRIO driver in an interrupt mode (compared to the polling mode demonstrated in the SRIO Loopback example code in the PDK). The chip also supports SRIO interrupt pacing described in section 2.3.9.4 of the SRIO user guide.  I am not clear about how it works. For example, the down counter mentioned in the document, does it decrement very clock cycle or a specific time period, or is does the counter decrement for each (valid?) SRIO segments the physical layer receives?

The way it works is that the peripheral won't fire an interrupt on the given INTDSTn interrupt line until the counter decrements to 0.  The countdown start value is in the corresponding INTDSTn_RATE_CNTL register.  It decrements every clock cycle, which is the VBUS (SYSCLK10) or 1/3 CPU.  It has nothing to do with packet count.  If an interrupt is pending but the count is not zero, then it waits to fire the interrupt.  Once it is zero it fires.  If the counter reaches zero and there is no interrupt pending, then of course no interrupt is fired, however, as soon as the next interrupt does get set, it fires immediately.  Once the interrupt is fired, it will not fire again EVER unless you re-write the pacing register.

SThakkar said:

Also, if the messages are buffered until the interrupts is generated, I would have to make sure I have configured enough buffers so that segments are not dropped at that level, correct? How can I do that?

Not sure which SRIO loopback example you are using, but the SRIO Interrupt pacing can only be used with DirectIO packets not the messaging type 11/9 packets.

C:\ti\pdk_C6678_x_x_x_x\packages\ti\drv\srio\example\SRIOLoopbackDioIsr

If you are using directIO packets you are fine, but the reason I say this is that when you talk about buffers and segments it sounds like messaging.  DirectIO will write directly to memory, so as long as you have allocated enough memory space to hold all the incoming packets you will be ok.  RapidIO will not drop any packets, the receiving device will just keep moving the data to DSP memory, only the interrupt is delayed in using pacing.

SThakkar said:

I would be great if there is an example code that demonstrates how the feature can be used.

The only difference to the example above that you would have to make is to use INTDST 0-15 and write the corresponding INTDSTn_RATE_CNTL register with a non-zero number.

Regards,

Travis

Thanks Travis. You guessed it right, I am using type 11 messages. I did not realiaze the interrupt pacing mode cannot be used for SRIO messaging type packets. I could have missed some fineprint. (Or is it not part of the RapidIO spec?)

I use the SRIO driver in application managed mode, and I have configured the accumulator to generate interrupts for each SRIO transmits and recieves (type 11 messages) instead of going for polling approach. The approach is functional, but it generates an interrupt for each SRIO transmit and recieve segment. Now, I am looking at ways I can optimize our application for CPU cycles. One of the things that came up in profiling was that the interrupt handlers for SRIO were called many times. Having reading about interrupt pacing mode, I wanted to see if I could reduce the frequency of interrupts to reduce the number of context switches. Since I am using SRIO type 11 messages, do I have other ways to do it? I mean can it be done at all? One option seems to be I could enable and disable SRIO interrupts to the core for small periods of time...

Thanks,

Shivang

Shivang,

Yes you can still do interrupt pacing with type 11, but it is done by the Multicore Navigator not the SRIO peripheral itself.  Elush can help you dig into the software details here, but essentially you accumulate RX descriptors, I think you can do it by count or time based before firing an interrupt.  This is done by configuring the PDSP firmware to accumulate on certain channels/queues.  TX doesn't really need any interrupts, as the descriptors are automatically recycled to a free queue when the sending completion is done.  Take a look at:

http://www.ti.com/lit/ug/sprugr9e/sprugr9e.pdf

section 4.3.1

Regards,

Travis