t13 forum,
I accepted the task to write text to add to Section 18 of Volume 3 regarding a Device use of nIEN in the Serial Implementation of ATA. The proposed text follows:
18.1 Device Emulation of nIEN with Interrupt Pending (Informative)
This standard defines the I bit in Register Device to Host FIS's as the Interrupt pending state of the device, and it is not modified by the state of nIEN in received Host to Device FIS's. In this standard, devices ignore the nIEN bit in received Host to Device FIS's and always perform as if nIEN is cleared to zero. See clauses 16.5.3 and 16.5.4.
Prior to the development of this standard, some devices used the nIEN bit of the Register Host to Device FIS as a pre-condition to the setting the interrupt pending flag (I-bit) of the Register Device to Host, and Set Device Bits FIS's.
The purpose of using nIEN to enable the I-bit was to emulate the operation of the parallel implementation of ATA (See Clause 13.2). In the parallel implementation, when nIEN is cleared to zero, the driver is enabled for the INTRQ line to the host. When nIEN is set to one, the INTRQ line is put into the high impedance state by the device. This function is typically used in devices that support Device 0 and Device 1 operation (See 13.2.3), and it is also required for Overlapped operation (See Volume 1).
In this standard, the implementation of Device 0/Device 1 emulation is performed exclusively by the Host (see 13.2.3).
Since operation prior to this standard was not uniformly implemented, the system designer should be aware of the limitations of those implementations. In most cases, the prior implementations are compatible with this standard. Some commands, however, may not operate in the same manner, or may require new device drivers for compatible operation. One example of this is when Overlapped/Queued operations are implemented with host host-parallel to device-serial bridges. With proper management of the nIEN and INTRQ bit to the parallel host, it is possible to emulate the parallel operation.
One serious side effect of device emulation of nIEN is the possibility of lost interrupts. In the parallel implementation, a host can disable interrupts, and upon re-enabling interrupts (by clearing nIEN to zero) see the INTRQ line again asserted. If a serial device is performing I-bit masking based on the state of nIEN, a Register Device to Host FIS may be received with I=0 (since it is masked by nIEN). The device, however, may have an interrupt pending at that time. When the host writes the Control Register with nIEN cleared to zero, it will not see the pending interrupt reflected by the assertion of INTRQ as in the parallel case. There is no way for the device to "re-send" the I=1 condition to the host. In this instance, the host will have to resort to a polling operation to resume the operation.
The system designer should be aware of the following:
1) The “I” bit is the interrupt pending flag for Serial ATA devices.
2) The behavior of the “I” bit may be modified by the state of the nIEN bit in devices implemented prior to this standard. Devices implemented prior to this standard may change the behavior of the “I” bit based on the current state of the nIEN bit, as last written by a Register Host to Device FIS with C=0 or C=1. Some devices do not write the nIEN bit when C=1.
3) There is no defined behavior for a device when nIEN bit changes and the modification of the behavior of the “I” bit by nIEN is vendor specific.
4) The host should only set nIEN=0 in Register HD FIS’s. This will result in the highest compatibility with this standard.
5) If a device supports nIEN emulation, and the nIEN bit is set to 1 by the host, the device drivers should accommodate the case of no interrupt generation when nIEN is cleared to zero and the device has a pending interrupt.
(end of proposed text)
John Masiewicz
Senior Technical Staff
Advanced Concepts
Western Digital
949-672-7686
