In previous part I have shown where SATA Framework and SATA HBA drivers are placed in Solaris and what are SATA Framework features/functionality. Let's see what SATA HBA driver has to offer:
SATA HBA driver role is to take care of the SATA controller hardware and its operation. SATA HBA driver is not aware of SCSA interface requirements nor SCSI-to-SATA translations.
The SATA HBA driver compatible with SATA framework compatible has to take care of:- Any hardware specific mapping of the SATA controller registers and resources.
- Controller-related DMA setup and control (controller's registers and controller-specific data structures accessed via DMA).
- PHY link control and device detection.
- Interrupt registration and handling.
- Detection of hotplugging events.
- Hardware specific setup and transfer of ATA/ATAPI commands, data and error information via serial link.
- Perform power management operations requested by the system.
- Register itself with the SATA HBA framework.
- Expose its capability and configuration.
- Report state and changes of state of the SATA device ports.
- Execute operation requests specified by SATA framework in sata packets.
- Return status of the operations to the SATA framework. All access to the SATA HBA driver (and SATA HBA) is via SATA framework. SATA HBA framework presents to the system each registered instance of the SATA HBA as the SCSI HBA instance. It means, that the rest of the system really see only the scsi HBA and is not aware of the type if the interconnect (serial ATA in this case). The basic functionality of a scsi HBA driver is provided by the combined SATA framework and SATA HBA driver functionality. Attached SATA devices are treated by the system as SCSI devices and are controlled by the sd target driver via scsi transport layer.
Devices
SATA devices, similarly to scsi devices, are represented in the device tree by the target nodes. Unlike scsi devices, which are connected to a shared scsi bus, SATA devices are connected point-to-point to SATA controller device ports. The classical mechanism of scsi device discovery and configuration is therefore not needed, because there is no need to scan any bus. SATA controller knows that a device is connected to given SATA device port and the link with a device is established automatically. With this understanding we can consider SATA target devices as self-identifying devices, that do not depend on driver.conf entries to be recognized by the system (see Solaris man page for 'scsi').
So the target nodes (corresponding to attached and configured devices) and their properties are created dynamically (using standard nexus mechanisms) by SATA framework. This operation is performed during SATA HBA instance attachment process and when a connected device is configured for use by the system via cfgadm operation (more about it later). Target nodes are also destroyed by SATA framework when a device is disconnected/removed from a SATA device port. From the application point of view, SATA device is referred to like a scsi device, using the same naming convention and device path, e.g. /dev/dsk/cXtYd0.
I/O Operations
Operations for scsi device are specified by the target driver using scsi packet (see man page for 'scsi_pkt'). Since SATA framwork/SATA HBA pair registers itself as scsi HBA, it receives operational directives from the target driver in scsi packets and, optionally, as IOCTL request.
Operations specified by scsi packets are translated by SATA HBA framework into equivalent SATA device operations (in SATA packet envelope) or are emulated within the SATA framework, or are rejected if none of the above could be
done. The translation may be quite involved (even multi-phased), particularly for scsi commands that do not have direct equivalent is SATA command set.
Any data transfer to/from the SATA device involves data buffer. Some data may be transfered via PIO transfer, but majority of the data transfer is performed using DMA. SATA framework assumes that all data is transfered via DMA. To relieve SATA HBA driver from data transfer DMA setup operations, SATA framework performs data buffer DMA mapping and DMA resources allocation, based on the information in the scsi packet. Even when the operation involving data transfer originates in the SATA framework (no scsi packet involved), the DMA setup is performed by the framework. What is involved here: DMA handle allocation and binding, partial DMA mapping management, DMA windows and cookies management, and occasionally an intermediate buffer allocation. While allocating DMA resources, SATA HBA framework takes into consideration SATA HBA capabilities and attached device capabilities - this needs to be done, because SATA devices use different command set and have different I/O capabilities than scsi devices and scsi-type requests needs to be adjusted such a way that they could be performed by SATA device.
SATA framework sends to a SATA HBA driver (via SATA HBA Interface) a sata packet, one packet per single SATA device operation. Sata packet contains (among other data) a fully formed SATA device command, including standard registers (ATA task file registers) setup. SATA HBA driver uses this data in the sata packet without any further translation to set-up, in the controller-specific way, an I/O operation.
The status of the SATA operation, including potential error information, is translated into SCSI
format (as needed for scsi packet) by SATA HBA framework and send back to the scsi target driver.
Control
SATA HBA framework creates also control node for each SATA controller. This is an equivalent of the control node for scsi controller. All IOCTLs for a given controller are addressed to its control node. Device control IOCTLs are processed by the SATA HBA framework and are translated into SATA operations, if necessary. IOCTLs that are not handled by SATA HBA framework are passed either to standard nexus IOCTL handler (ndi_devctl_ioctl()) or to the SATA HBA driver, if possible (i.e. if HBA driver registered entry point for IOCTL requests).
Hotplugging
As I mentioned before, SATA controllers detects device physical (electrical) connection and disconnection. Device electrical connect/disconnect - hotplugging events - detected by the SATA HBA driver are passed to the SATA
framework, which in response performs device detection, internal configuration/reconfiguration and error handling operations and informs the system about hotplugging events via sysevents. Hot-plugged devices are not immediately usable by the system - an explicit operator intervention is needed to configure such device and make it accessible by the system (more about this later).
The brief descriptions above will be expanded in following sections, where we will talk about interfaces, driver attach operations, device configuration, scsi operation setup/translation, sample read/write operations, events handling, internal structures, cfgadm operations and details of various operations.
