that output has completed, or
Are interrupts [also] used to signify that output is ready?
Consider writing to a serial port device. The device has a receive buffer called a FIFO, to store a small amount of data e.g. 16 bytes.
There may be an interrupt both when
- the buffer falls empty, and output is complete. This is used to implement
tcdrain() on Linux. Allegedly "this function should be used when changing parameters that affect output". E.g. when you want to change the "baud rate" (frequency) of the serial port, you can use this to wait until all buffered data has been transmitted using the current baud rate.
- a byte has been transmitted out from the buffer. There is now space available. The device is now ready for the CPU to push another byte in to the buffer.
that input data are available, or
Are interrupts [also] used to signify that input has completed?
Maybe. I'm not sure there's two different things here though, at least in my example.
Consider reading from a serial port device. The device has a transmit buffer called a FIFO, to store a small amount of data e.g. 16 bytes.
When the FIFO has collected at least one byte from the input, the device sends an interrupt. For example it may change from a low to a high voltage on a line connected to the CPU.
The CPU can consume bytes from the buffer, by reading from an IO port or from IO memory.
Sidenote: such transactions may be allowed to take longer than reading from system RAM. To allow this, the IO device must insert "wait states" on the bus. I.e. there is a brief handshake, where it may take several cycles of the bus frequency before the IO device sets a "data ready" bit. Wait states may equally be applied when writing to an IO port / IO memory. However, wait states are only used to cover a known difference in operation frequency/latency between different devices. They are not used to wait for external input or output. This is because they block the CPU from continuing and doing anything else.
So when input is available, an interrupt is signalled. If you like, you can say the input is "completed" when the CPU has read in the input byte. But no interrupt is required to signal this. Just as no interrupt is required to signal that a read from memory is complete.
A condition where the input buffer is full actually seems more like an error condition - it suggests a buffer overflow. That condition may indeed be recorded by the device, allowing the OS to detect the error. However, I don't think there is reason to send an interrupt specifically for overflow. Because the device could already have sent an interrupt when input became available.