Revision as of 05:49, 5 March 2010 view source osdev>Bewing m →‎48 bit PIO: minor wording change ← Older edit		Revision as of 22:51, 9 May 2010 view source osdev>Bewing →‎400ns delays: minor rewording Newer edit →
Line 29: The method suggested in the ATA specs for sending ATA commands tells you to check the BSY and DRQ bits before trying to send a command. This means that you need to read a Status Register (Alternate Status is a good choice) <i>for the proper drive</i> before sending the next command. Which means that you need to select the correct device <i>first</i>, before you can read that status (and then send all the other values to the other IO ports). Which means that a drive select may always happen <i>just before</i> a status read. This is bad. Many drives require a little time to respond to a "select", and push their status onto the bus. The suggestion is to read the Status register <b>FIVE TIMES</b>, and only pay attention to the value returned by the last one -- after selecting a new master or slave device. ~~This~~The ~~wastes~~point being that you can assume an IO port read takes approximately 100ns, so doing the first four creates a ~~lot~~400ns delay -- which allows the drive time to push the correct voltages ofonto ~~CPU~~the ~~cycles~~bus. Reading IO ports to create delays wastes a lot of CPU cycles. So, it is ~~smartest~~actually smarter to have your driver remember the last value sent to each Drive Select IO port, to avoid doing unneeded drive selections, if the value did not change. If you do not send a drive select, then you only have to read the Status Register <b>once</b>. Alternately, you never want to send new commands to a drive that is already servicing a previous command, anyway. Your driver <b>always</b> needs to block if the current device is actively modifying BSY/DRQ/ERR, and your device driver always already knows that the device is in that condition (because the driver just sent the command to the device, and it hasn't been marked "complete" yet). Once a drive has actually completed a command, it will always clear BSY and DRQ. You can simply verify this, <i>before</i> your next Device Select command -- that the previously selected device cleared BSY and DRQ properly at command completion. Then you will never have to check if they are clear <b>after</b> a Device Select -- so you will not have to read the Status Register after the Device Select at all. There is a similar problem after writing the Command Register, with the ERR/DF bits. They are two slightly different kinds of errors, that can terminate a command. BSY and DRQ will be cleared, but ERR or DF remain set <i>until just after you write a new command to the Command Register</i>. If you are using polling (see below), you should account for the fact that your first four reads of the Status Register, after sending your command byte, may have the ERR or DF bits still set accidentally. (If you are using IRQs, the Status will always be correct by the time the IRQ is serviced.) ==Cache Flush==

ATA PIO Mode: Difference between revisions