| commit | 2d3bc628ad9b9c883f94a2d5a9ad48b0a95101a3 | |
| author | David S. Miller <davem@davemloft.net> | |
| Thu, 8 Mar 2007 07:17:20 +0000 (8 08:17 +0100) | ||
| committer | Adrian Bunk <bunk@stusta.de> | |
| Thu, 8 Mar 2007 07:17:20 +0000 (8 08:17 +0100) | ||
| tree | 045cdc817322e6b890815842ed27c78420293dee | treesnapshot (tar.gz zip) |
| parent | 1a6b8d666d090d821cbc9c07d788ac85639d74c8 | commitdiff |
video/aty/mach64_ct.c: fix bogus delay loop
CT based mach64 cards were reported to hang on sparc64 boxes when
compiled with gcc-4.1.x and later.
Looking at this piece of code, it's no surprise. A critical
delay was implemented as an empty for() loop, and gcc 4.0.x
and previous did not optimize it away, so we did get a delay.
But gcc-4.1.x and later can optimize it away, and we get crashes.
Use a real udelay() to fix this. Fix verified on SunBlade100.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
CT based mach64 cards were reported to hang on sparc64 boxes when
compiled with gcc-4.1.x and later.
Looking at this piece of code, it's no surprise. A critical
delay was implemented as an empty for() loop, and gcc 4.0.x
and previous did not optimize it away, so we did get a delay.
But gcc-4.1.x and later can optimize it away, and we get crashes.
Use a real udelay() to fix this. Fix verified on SunBlade100.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
| drivers/video/aty/mach64_ct.c | diffblobblamehistory |