[U-Boot] [PATCH v2 01/15] arm: zynq: U-Boot udelay < 1000 FIX

From: David Andrey Rework the __udelay function of U-Boot Zynq Arch to handle delay < 1000 usec Signed-off-by: David Andrey Signed-off-by: Michal Simek --- Changes in v2: None arch/arm/cpu/armv7/zynq/timer.c | 46 + 1 file changed, 37 insertions(+), 9

[U-Boot] [PATCH 01/14] arm: zynq: U-Boot udelay < 1000 FIX

From: David Andrey Rework the __udelay function of U-Boot Zynq Arch to handle delay < 1000 usec Signed-off-by: David Andrey Signed-off-by: Michal Simek --- arch/arm/cpu/armv7/zynq/timer.c | 46 + 1 file changed, 37 insertions(+), 9 deletions(-) diff --

[U-Boot] udelay

Dear all, Looking at the several udelay implementations for several different architectures (an example is cpu/arm926ejs/davinci/timer.c), it seemed to me that udelay implementations ( and other timer functions ) does not handle timestamp overflow. This might cause unexpected timer problems. By th

Re: [U-Boot] udelay/udelay_masked problems

On 11:52 Tue 07 Apr , E Robertson wrote: > Hi all, > Is their a problem using udelay in board_init functions? actually yes I'll send some patch to cleanuo the timer/interrupt init this week > When I do this on my at91, arm926ejs board, it seems to be in an endless loop. > I thought this was a t

Re: [U-Boot] udelay/udelay_masked problems

Hi E Robertson, 2009/4/8 E Robertson : > Hi all, > Is their a problem using udelay in board_init functions? > When I do this on my at91, arm926ejs board, it seems to be in an endless loop. > I thought this was a timer issue but I only have this problem with > board init and not in the drivers. > D

[U-Boot] udelay/udelay_masked problems

Hi all, Is their a problem using udelay in board_init functions? When I do this on my at91, arm926ejs board, it seems to be in an endless loop. I thought this was a timer issue but I only have this problem with board init and not in the drivers. Does anyone have any ideas? Is timer_init a arch spec

[U-Boot] udelay(100000000) in drivers/net/3c589.c

Hi, I do not quite follow these two code-fragments from drivers/net/3c589.c::el_reset(): /* must wait for at least 1ms */ udelay(1); ... /* wait for another 1ms */ udelay(1); The comments and the code don't seem to quite agree? Thanks Guennadi