[U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite

[J. William Campbell]

On 7/15/2011 11:34 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4E208227.6010903 at comcast.net>  you wrote:
>>         If the I2C protocol must be available before interrupts are
>> available, then udelay must be used. In the above examples, there are
>> some loops in i2c and spi that appear to be waiting a full second. I
>> assume they are using udelay because the get_timer feature is not yet
>> available to them. I also assume that the example in common/usb.c uses
> No, this is usually not the case.  This long delay is the error case,
> which most probably will never happen.  For the normal case, you want
> a tight spinning loop that introduces as little additional delay as
> possible.
Hi All,
         I understand why one would want to use udelay in those cases 
where there are other conditions that should cause the loop to exit. 
However, in the 16 examples you cited,  7 of those usages are for delays 
of multiple milliseconds with no tests or escape conditions included. I 
therefore pointed out that I assume that it was being done that way (as 
opposed to using  get_timer) because this code would be executed 
"early", before get_timer was available.
>> True, although I expect you will find the statement "on all the other
>> architectures" to be false. Many other architectures, yes, all, no.
>> These other architectures just don't have spi or I2C yet, or if they do,
>> they don't use it "early".
> Are you aware of another architecture that cannot provide
> sub-microsecond timer resolution?  Which is it?

      No, but I am aware of some that do not provide udelay at all until 
after interrupts are enabled and the get_timer interface is available. 
Several ARM implementations have this property. There are one or two 
others (SPARC) that are similar as I recall. There were also some that 
called reset_timer, which would mess up nested timing loops, but this 
has already been fixed. There also quite a few udelay implementations 
that do not actually provide 1 µs resolution.  For instance, the first 
thing that happens in arm720t/interrupts.c  __udelay is that the input 
microseconds is divided by 1000 and the remainder discarded. A 
udelay(10) won't work so well here. The lh7a40x/timer.c uses a 508 kHz 
clock, so delays are accurate to at best 2 µs. There are other examples. 
For instance, I am pretty sure some u-boot based CPUs use a 32kHz clock 
as the timebase for udelay. The resolution in that case is 30 µs, which 
would be a problem for your example code. I am sure further digging will 
reveal other resolution issues.

These udelay issues would need fixing if all u-boot options are to work 
"out of the box". In some cases of low resolution, the fix is not easy, 
or maybe not even possible. However, this problem has not prevented the 
use of u-boot on these CPUs. It does mean that some things do not work 
"out of the box", and these non-compliant udelays should be fixed 
wherever practical. In any case, this shouldn't stop progress on 
get_timer and the delay_at_least (or whatever it ends up being called) 
function being adopted. That is independent of the udelay issues. udelay 
must be implemented in a "compliant" manner, which may or may not use 
the same hardware as get_timer() does. It certainly can't use the same 
code (although some ARM version in effect do, resulting in a 
non-compliant, low resolution  udelay).

It might be interesting to utilize something like "jiffies" for the loop 
delays that are looking for error exits. In those cases, the error case 
should be infrequent. It may not matter that the total delay is quite a 
bit longer than the user requested, as long as it isn't vastly shorter. 
If a 10 µsec delay became a 30 µsec delay inside the loop examples where 
we expect to exit due to another cause, it probably wouldn't matter 
much. It would matter a lot though if the delay were setting a baud rate 
on a "bit-banged" output, so jiffies may not be worth it. I put it out 
there for consideration, as it is easier to produce than a udelay that 
has a guaranteed low absolute error.

Best Regards,
Bill Campbell
>
> Best regards,
>
> Wolfgang Denk
>