From: "Adam J. Richter" <adam@yggdrasil.com>
To: linux-kernel@vger.kernel.org
Subject: PATCH: __bad_udelay fixes(?) for linux-2.4.0-prerelease
Date: Sun, 31 Dec 2000 21:34:59 -0800 [thread overview]
Message-ID: <20001231213459.A17636@baldur.yggdrasil.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
linux-2.4.0-prerelease changes the udelay() macro defined
in linux/include/asm-i386/delay.h to reference the undefined symbol
__bad_udelay if udelay is called with a constant exceeding 20000
(that is, 20 milliseconds). I guess the purpose of this change is
to tell driver maintainers to either take a harder look at whether they
really need to do a busy sleep for that long (you can still do it with
a loop) or have them give up the CPU during the sleep (although I do not see
a simple helper routine in the kernel to do this). This change prevents
four modules in 2.4.0-prerelease from linking. I have attached a patch
allowing them to link, but I would appreciate feedback on whether my
patches are the best approach. Here is a summary:
drivers/net/tokenring/smctr.c - I think this is the only file that had
a real bug. The comments say it is
delaying for 2ms in two places, but the
code actually asks for a delay of 200ms
in each place. I have changed it to
really only delay 2ms in each place.
I would like to know if it still drives
the hardware correctly. PLEASE TEST.
drivers/net/irda/tohoboe.c - The code already has a FIXME and it
currently does 10 iterations of 100ms
delays, checking a register at each loop.
I have changed it to do 1000 iterations of
1ms. It is the same maximum delay, but
it will exit faster once the event that
it is looking for occurs. Is there a
better fix?
drivers/video/atyfb.c - An intentional 50ms delay.
drivers/video/clgenfb.c - An intentional 100ms delay.
I've changed both files to keep the
delays by using mdelay instead of udelay.
Perhaps somebody could check the
approaprirate documentation and test
on real hardware to determine if the
delays really need to be this long.
Anyhow, I think we should try to resolve the __bad_udelay
problems somehow by, say, linux-2.4.0-prerelease79. :-)
--
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
[-- Attachment #2: udelay.diffs --]
[-- Type: text/plain, Size: 2147 bytes --]
--- linux-2.4.0-prerelease/drivers/net/tokenring/smctr.c Mon Oct 16 12:58:51 2000
+++ linux/drivers/net/tokenring/smctr.c Sun Dec 31 21:23:07 2000
@@ -4445,10 +4445,10 @@
int ioaddr = dev->base_addr;
/* Reseting the NIC will put it in a halted and un-initialized state. */ smctr_set_trc_reset(ioaddr);
- udelay(200000); /* ~2 ms */
+ udelay(2000); /* ~2 ms */
smctr_clear_trc_reset(ioaddr);
- udelay(200000); /* ~2 ms */
+ udelay(2000); /* ~2 ms */
/* Remove any latched interrupts that occured prior to reseting the
* adapter or possibily caused by line glitches due to the reset.
--- linux-2.4.0-prerelease/drivers/net/irda/toshoboe.c Sun Nov 12 20:43:11 2000
+++ linux/drivers/net/irda/toshoboe.c Sun Dec 31 21:23:07 2000
@@ -881,7 +892,7 @@
static void
toshoboe_gotosleep (struct toshoboe_cb *self)
{
- int i = 10;
+ int i = 1000;
printk (KERN_WARNING "ToshOboe: suspending\n");
@@ -896,7 +907,7 @@
/*FIXME: can't sleep here wait one second */
while ((i--) && (self->txpending))
- udelay (100000);
+ udelay (1000);
toshoboe_stopchip (self);
toshoboe_disablebm (self);
--- linux-2.4.0-prerelease/drivers/video/atyfb.c Sun Dec 3 17:45:23 2000
+++ linux/drivers/video/atyfb.c Sun Dec 31 21:23:07 2000
@@ -1754,7 +1797,7 @@
aty_st_8(CLOCK_CNTL + info->clk_wr_offset, old_clock_cntl | CLOCK_STROBE,
info);
- udelay(50000); /* delay for 50 (15) ms */
+ mdelay(50); /* delay for 50 (15) ms */
aty_st_8(CLOCK_CNTL + info->clk_wr_offset,
((pll->locationAddr & 0x0F) | CLOCK_STROBE), info);
--- linux-2.4.0-prerelease/drivers/video/clgenfb.c Tue Nov 7 10:59:43 2000
+++ linux/drivers/video/clgenfb.c Sun Dec 31 21:23:07 2000
@@ -1899,7 +1926,7 @@
break;
case BT_PICASSO4:
vga_wcrt (fb_info->regs, CL_CRT51, 0x00); /* disable flickerfixer */
- udelay (100000);
+ mdelay (100);
vga_wgfx (fb_info->regs, CL_GR2F, 0x00); /* from Klaus' NetBSD driver: */
vga_wgfx (fb_info->regs, CL_GR33, 0x00); /* put blitter into 542x compat */
vga_wgfx (fb_info->regs, CL_GR31, 0x00); /* mode */
next reply other threads:[~2001-01-01 6:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-01 5:34 Adam J. Richter [this message]
2001-01-01 16:04 ` PATCH: __bad_udelay fixes(?) for linux-2.4.0-prerelease Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20001231213459.A17636@baldur.yggdrasil.com \
--to=adam@yggdrasil.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).