Page 1 of 1

why 'Delay is needed after doing I/O'?

Posted: Mon Aug 05, 2019 11:40 pm
by kingwah
When I read the Linux kernel source code(Linux 3.10.0), I noticed following codes in the file 'arch/x86/boot/pm.c':

Code: Select all

 22 static void realmode_switch_hook(void)
 23 {
 24         if (boot_params.hdr.realmode_swtch) {
 25                 asm volatile("lcallw *%0"
 26                              : : "m" (boot_params.hdr.realmode_swtch)
 27                              : "eax", "ebx", "ecx", "edx");
 28         } else {
 29                 asm volatile("cli");
 30                 outb(0x80, 0x70); /* Disable NMI */
 31                 io_delay();
 32         }
 33 }
The function call 'io_delay()' here is to let the CPU wait for some time (by 'outb' a byte to the diagnostics IO Port 0x80), and my question is:
Why does it need to wait for some delay after doing I/O?

Re: why 'Delay is needed after doing I/O'?

Posted: Mon Aug 05, 2019 11:52 pm
by iansjack
Most devices require a delay after writing to their command registers to give the device time to respond to the command. Alternatively, there may be a status register that can be polled to indicate when a command has been processed.

Ignoring ths is the sort of thing that can cause an OS to run on an emulator but not a real CPU.

Re: why 'Delay is needed after doing I/O'?

Posted: Tue Aug 06, 2019 12:34 am
by kingwah
iansjack wrote:Most devices require a delay after writing to their command registers to give the device time to respond to the command. Alternatively, there may be a status register that can be polled to indicate when a command has been processed.

Ignoring ths is the sort of thing that can cause an OS to run on an emulator but not a real CPU.
Thank you very much, :)

Re: why 'Delay is needed after doing I/O'?

Posted: Tue Aug 06, 2019 2:58 am
by iansjack
I should have mentioned another possibility. Some devices can be configured to issue an interrupt to notify the cpu that an operation has completed. Typically this is used with network controllers or drive controllers, where the time to complete some operations may be relatively long. That way the whole system doesn't have to stop waiting for an i/o operation. And, of course, a keyboard controller is normally configured this way.