I'm restarting this case as a fast-track, timing out
7/1/09.
The project team has removed all of the interfaces which
do not have current consumers from this case.
In particular the pm-* properties which described the
attributes of the different power states, and the new
argument "dip" to pm_trans_check(9F) are removed.
The case now just brings the disk IO stack power
management up to date with new transport types
(particularly SATA).
Below is a summary and some explanation to help make
the case more obvious.
Summary
This case is now composed of 4 parts.
1. a property used to communicate between the transport layer
and the target driver code (sd) about what support the
device has for power management features,
eliminating the need for the target driver to know which
transport is being used and which commands it supports.
2. extend pm_trans_check(9F) support to SATA devices
3. a tunable used to override information that disk/transport
HW might present;
4. a USCSI flag to allow power management to stop FMA from
bringing up a power managed disk to see if it is ok.
Explanation
1. target-transport communication property (pm-capable)
The sd/scsa system is designed to allow the target driver (sd)
not to have to know about the details ofthe transport used to
control the drive (one of SCSI, SATA, SAS, FCAL, IEEEE-1394,
USB, etc.), and the transport driver not to have to know
the details of the target device.
Unfortunately, there are several different schemes for
identifying and controlling the power states of a disk,
depending on the transport and the set of power states supported
by the disk, and to provide access to information about how many
power cycles the disk has experienced (so that they can be meted
out over the desired lifetime of the disk and not squandered
immediately upon putting the disk in service).
In particular, for control the current options are the
Start field of the Start Stop Unit command, and the
Power Condition field of the Start Stop Unit command.
For getting the start-stop history information, the options
are check or ignore log page 0Eh, and to expect (if not
ignored) for log page 0Eh to contain SMART attribute data
or SCSI native log page 0Eh information.
The pm-capable property is extended to communicate this
information to the target driver.
This information is needed to allow the sd driver to
support the existing autopm framework behavior on the new
transports.
This scheme was worked out by/in collaboration with the owners of
all of the drivers involved. While the specific values in
this property may not be obvious to those not familiar with the
detailed specs of the various transports, I submit that using
a property which already conveys related information to convey
this info rather than perturbing the scsa/sd interface is obvious.
2. pm_trans_check change
The modification of pm_trans_check() allows for the slightly
different flavor of information (native SCSI vs. SMART)
provided by different transports to be used in making power
down decisions.
3. tunable
Sometimes the firmware is buggy and lies about the capabilities
of the device. The "power-condition" tunable allows a way to
override the information presented by firmware for a specific
device identified by Product ID and Vendor ID.
4. USCSI_PMFAILFAST flag
There is a problem where an FMA disk health checking thread spins
up disks periodically to test device status. This flag allows
for the device driver to not spin up the device to get this
information.
The full text of the new proposal is in the materials directory as
"proposal".
thanks,
sarito
