+103
−38
Loading
davinci: Add compare register support to timer code
The Timer64p timer has 8 compare registers that can be used to generate interrupts when the timer value matches the compare reg's value. They do not disturb the timer itself. This can be useful when there is only one timer available for both clock events and clocksource. When enabled, the clocksource remains a continuous 32-bit counter but the clock event will no longer support periodic interrupts. Instead only oneshot timers will be supported and implemented by setting the compare register to the current timer value plus the period that the clock event subsystem is requesting. Compare registers support is enabled automatically when the following conditions are met: 1) The same timer is being used for clock events and clocksource. 2) The timer is the bottom half (32 bits) of the 64-bit timer (hardware limitation). 3) The the compare register offset and irq are not zero. Since the timer is always running, there is a hardware race in timer32_config() between reading the current timer value, and adding the period to the current timer value and writing the compare register. Testing on a da830 evm board with the timer clocked at 24 MHz and the processor clocked at 300 MHz, showed the number of counter ticks to do this ranged from 20-53 (~1-2.2 usecs) but usually around 41 ticks. This includes some artifacts from collecting the information. So, the minimum period should be at least 5 usecs to be safe. There is also an non-critical lower limit that the period should be since there is no point in setting an event that is much shorter than the time it takes to set the event, and get & handle the timer interrupt for that event. There can also be all sorts of delays from activities occuring elsewhere in the system (including hardware activitis like cache & TLB management). These are virtually impossible to quantify so a minimum period of 50 usecs was chosen. That will certianly be enough to avoid the actual hardware race but hopefully not large enough to cause unreasonably course-grained timers. Signed-off-by:Mark A. Greer <mgreer@mvista.com> Signed-off-by: