Linux/DSP Timer Interaction

Hello,

Can you please let us know which EVM you are using and which SDK version?

Regards, Niclas

I'm using the Logic Zoom OMAP-L138 (SOM-M1) eXperimenter kit with no additional hardware at the moment.  I'm not using the SDK but am using a kernel that is based on a 2.6.27 version of the TI kernel so the arch/arm/mach-davinci directory contents are the same.

Dennis

I can only comment on timer 0 and timer 1 from a DSP perspective.  If you are using DSP/BIOS 5.x on the DSP core,  the real-time OS will allow you to configure the bottom half of these timers using 32-bit unchained mode (default) which makes the 64-bit timer act as two independent 32-bit timers.  DSP/BIOS programs, its bottom half of the timer in continuous mode which should allow you to set the upper half to any mode.  If you are not using DSP/BIOS or don't have the need to have any time based calls on the DSP then the Linux kernel is free to use both halves of the timer.

Thanks Arnie,

I will try to get more information on the DSP code to be used with OS.  In the mean time...assuming similar DSP code will be used our option would be to swap the timer usage in the current Linux kernel so that the system clock is running from the top half of timer 0 (using unchained 32-bit mode) instead of the bottom half it's using now.

The only issue I have now is if the DSP/BIOS code uses time based calls on both halves of the unchained timer 0.  The system clock in the kernel currently uses an event mechanism that continually resets the 32-bit timer's period.  Could this be used in either a tickless configuration or can I change it so it doen't use events and configures the timer in continuous mode?

DSP/BIOS has two main options regarding timer configuration.  As previous noted DSP/BIOS will only use the bottom half of either timer 0 and timer 1 depending on application configuration.  The DSP-side also contain a configuration option to allow the DSP-side to reset the entire timer (both bottom and top half) and set the TIMMODE for the timer.

By default, the DSP/BIOS will not set any of these. The only thing it will do is assume 32-bit unchained mode and set the PRD, TDDR registers for the bottom half of the timer selected (by default timer 1).   Therefore you have a couple main options:

1. From the ARM-side (Linux) set timer 1 to 32-bit unchained and reset the bottom half on the timer.  When the DSP application starts to run, it will program to timer appropriately (default 1msec clock ticks).

2. Let DSP/BIOS set-up the TIMEMODE and reset the timer (both halves) by enabling the option in the DSP configuration.  You can even select either timer 0 or 1, and set it to either 32-bit chained or 32-bit unchained mode.

Note: The DSP/BIOS configuration allows for a few combination and permutation of the above but I've only outlined the typical cases.

Ok, thanks for the info.  I've settled on two options...  One is to move both the free running and system clocks to timer 1 and remove the watchdog from the Linux kernel configuration.  The other option is to keep the freerun counter at the top half of timer 0 but use the bottom half of timer 1 as you suggested in your post. 

After re-reading the system reference guide I realized that from the OS point of view we're really stuck with timers 0 and 1.  I may be mistaken but I didn't see any compare interrupts for the last two GP timers and in the case of timer 3 there is a common interrupt for the top and bottom halves of the timer. Some parts of the documentation mention 4 general purpose timers while other pages say 3 plus a watchdog.   Am I missing something?  Is there a way to get compare register interrupts for timer 3?

The customer has come back and said that they will be using the watchdog timer (timer 1) in their DSP code and asked if I have Linux use timer 2.  With this timer the interrupts for both halves of the 64-bit timer are shared so it looked like I'd have to add code to check the period interrupt status bits in the timer interrupt control and status register (INTCTLSTAT).  Even though their are defines in the code for compare register interrupts belonging to this timer they are mapped to the same numbers as those for timer 0.  I've tried this configuration but even though it boots it looks like the interrupt is firing too frequently.

Is using either timer 2 or 3 actually possible?  Do I need to change the clock tick rate on the Linux side?  Is it possible for the Linux system clock and free run timer to share the top half of timer 0?

Arnie,

   I work with Dennis.

Hello Arnie.
I'm working with an EVM OMAP-L137.
My goal is to start at first the DSP application, then the application ARM with the sequence UBL-uboot-Linux, without resetting the DSP.
It happened, however, that uboot cleared and configured the same timer used by DSP stopping the DSP application. I solved this problem by assigning the DSP timer 1 and timer all'Uboot 0. The new problem arises with the launch of the Linux kernel because it reconfigures both timers. Is there a way to set the kernel to  use only the timer 0 without affecting in any way the timer used by the DSP?

Thanks

Danilo

Hi!

I'm also working with an OMAP-L137 and I need to work with the timers... I need to generate an interruption every 16ms and catch it with an application on the ARM, to regulate some processes. The thing is I'm very new to embedded programming and I don't know how to use this peripherals. Can anyone point me to how to do this or with some example code of using the timers from Linux... I've found some stuff in the DSP but not much for the ARM.

Thanks in advance,

Aquiles