[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

[Graeme Russ <graeme.russ@gmail.com>]

Hi Bill,

On 28/05/11 00:23, J. William Campbell wrote:
> On 5/27/2011 12:35 AM, Graeme Russ wrote:
>> Hi Wolfgang,
>>
>> On 27/05/11 17:13, Wolfgang Denk wrote:
>>> Dear Graeme Russ,
>>>
>>> In message<BANLkTinWvY9b4QzeLNawF7MKT9z1zeMXyg@mail.gmail.com>  you wrote:
>>>> I think we will need to define get_timer() weak - Nios will have to
>>>> override the default implementation to cater for it's (Nios') limitations
>>> Please don't  - isn't the purpose of this whole discussion to use
>>> common code for this ?
>>>
>> Yes, but Nios is particularly bad - It has a 10ms tick counter :(
> Hi All,
>      And a hardware timer that you can't read to subdivide the 10 ms. Note
> that this is not necessarily a problem with all NIOS implementations. The
> timer characteristics can be controlled when you generate the bitstream for
> the FPGA. You can make the counter both faster and readable if you want. It
> just uses a bit more silicon. Sad to say, it probably will require  per
> board get_ticks routine. For the "old" nios2 timers however, overriding
> get_timer with a /board routine is probably the only way to go.
> 

Actually, using the logic you presented in the "Remove calls to
[get,reset]_timer outside arch/" thread, we could have a common get_timer()
implementation which deals with all timer resolution issues:

#if !defined(CONFIG_MIN_TIMER_RESOLUTION)
#define CONFIG_MIN_TIMER_RESOLUTION 1
#endif

u32 get_timer(u32 base)
{
	if (base != 0) {
		if (timer - base < (CONFIG_MIN_TIMER_RESOLUTION * 2))
			return 0;
		else
			return timer - base - CONFIG_MIN_TIMER_RESOLUTION;
	} else {
		return timer;
	}
}

This would also guarantee that timeout loops run for _at least_ the timeout
period

Regards,

Graeme