From owner-freebsd-hackers Fri Mar 24 06:35:17 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id GAA00703 for hackers-outgoing; Fri, 24 Mar 1995 06:35:17 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA00686 for ; Fri, 24 Mar 1995 06:34:58 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id AAA21278; Sat, 25 Mar 1995 00:29:00 +1000 Date: Sat, 25 Mar 1995 00:29:00 +1000 From: Bruce Evans Message-Id: <199503241429.AAA21278@godzilla.zeta.org.au> To: PVinci@ix.netcom.com, hackers@FreeBSD.org Subject: Re: wdcommand() revisited .. Sender: hackers-owner@FreeBSD.org Precedence: bulk >wdcommand ends as follows: > outb(wdc + wd_command, command); > return (0); >} >ATA states that we first have to check the status register to ensure >command is ok. > outb(wdc + wd_command, command); > if ((inb(wdc +wd_status) & WDCS_ERR) != 0) > return (-1) /* or whatever error correction */ > return (0); >} Callers of wdcommand() are required to check the status. Many callers (too many) check it immediately by calling wdwait(). The WDCS_ERR bit in the status register isn't valid until the WDCS_BUSY bit is clear, and it is necessary to wait for up to 31 seconds for it to become clear. Others wait for an interrupt before checking. They call wdwait() too. This is a bit wasteful because the WDCS_BUSY bit is probably already clear and the 450nsec delay before reading the status register is probably guaranteed by the slowness of getting to the interrupt handler. Bruce