[U-Boot-Users] [PATCH 3/7 v6] ARM: Add arm1176 core with S3C6400 SoC

[Jens Gehrlein]

Hi Guennadi,

Guennadi Liakhovetski schrieb:
> On Thu, 7 Aug 2008, Jens Gehrlein wrote:
> 
>> Hi Guennadi,
>>
>> Guennadi Liakhovetski schrieb:
>>
>>> diff --git a/cpu/arm1176/s3c64xx/interrupts.c
>>> b/cpu/arm1176/s3c64xx/interrupts.c
>> [snip]
>>> +void udelay(unsigned long usec)
>>> +{
>>> +	unsigned long long tmp;
>>> +	ulong tmo;
>>> +
>>> +	tmo = (usec + 9) / 10;
>>> +	tmp = get_ticks() + tmo;	/* get current timestamp */
>>> +
>>> +	while (get_ticks() < tmp)/* loop till event */
>>> +		 /*NOP*/;
>>> +}
>> I tried to follow the interrupt init function, but it's difficult.
>> What is the least possible delay with the udelay function?
>> I remember that i.mx31 udelay cannot currently be below 30 microsseconds due
>> to the low input clock. If someone uses udelay(1) in polling loops with
>> timeout, the actual duration is much more longer than assumed.
> 
> Actually, the "/ 10" and this comment
> 
> 	/*
> 	 * We use the following scheme for the timer:
> 	 * Prescaler is hard fixed at 167, divider at 1/4.
> 	 * This gives at PCLK frequency 66MHz approx. 10us ticks
> 	 * The timer is set to wrap after 100s, at 66MHz this obviously
> 	 * happens after 10,000,000 ticks. A long variable can thus
> 	 * keep values up to 40,000s, i.e., 11 hours. This should be
> 	 * enough for most uses:-) Possible optimizations: select a
> 	 * binary-friendly frequency, e.g., 1ms / 128. Also calculate
> 	 * the prescaler automatically for other PCLK frequencies.
> 	 */
> 
> shall make it clear, that the timer resolution is configured to 10us, 
> which is also the minimum udelay. The timer could also do better, but then 
> we get other disadvantages, e.g., shorter wrap-around time.

Okay. Thank you.
I think, it's very useful for a developer to know the limits of high 
resolution timers and to see it immediately, so he can consider it in 
his code.

Kind regards,
Jens