2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-28 20:18:39 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-05-16 09:16:37 -03:00
|
|
|
|
2005-08-28 20:18:39 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-23 13:19:54 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-11-10 18:08:10 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 16:22:30 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-10 18:08:10 +09:00
|
|
|
|
|
|
|
|
|
2012-03-10 23:28:46 -08:00
|
|
|
|
2007-08-08 01:08:45 +09:00
|
|
|
|
2006-02-27 22:31:19 -05:00
|
|
|
|
2007-03-28 01:57:37 -04:00
|
|
|
|
2007-11-04 22:05:49 -05:00
|
|
|
|
2017-09-30 22:10:40 +05:30
|
|
|
|
libata: implement slave_link
Explanation taken from the comment of ata_slave_link_init().
In libata, a port contains links and a link contains devices. There
is single host link but if a PMP is attached to it, there can be
multiple fan-out links. On SATA, there's usually a single device
connected to a link but PATA and SATA controllers emulating TF based
interface can have two - master and slave.
However, there are a few controllers which don't fit into this
abstraction too well - SATA controllers which emulate TF interface
with both master and slave devices but also have separate SCR
register sets for each device. These controllers need separate links
for physical link handling (e.g. onlineness, link speed) but should
be treated like a traditional M/S controller for everything else
(e.g. command issue, softreset).
slave_link is libata's way of handling this class of controllers
without impacting core layer too much. For anything other than
physical link handling, the default host link is used for both master
and slave. For physical link handling, separate @ap->slave_link is
used. All dirty details are implemented inside libata core layer.
From LLD's POV, the only difference is that prereset, hardreset and
postreset are called once more for the slave link, so the reset
sequence looks like the following.
prereset(M) -> prereset(S) -> hardreset(M) -> hardreset(S) ->
softreset(M) -> postreset(M) -> postreset(S)
Note that softreset is called only for the master. Softreset resets
both M/S by definition, so SRST on master should handle both (the
standard method will work just fine).
As slave_link excludes PMP support and only code paths which deal with
the attributes of physical link are affected, all the changes are
localized to libata.h, libata-core.c and libata-eh.c.
* ata_is_host_link() updated so that slave_link is considered as host
link too.
* iterator extended to iterate over the slave_link when using the
underbarred version.
* force param handling updated such that devno 16 is mapped to the
slave link/device.
* ata_link_on/offline() updated to return the combined result from
master and slave link. ata_phys_link_on/offline() are the direct
versions.
* EH autopsy and report are performed separately for master slave
links. Reset is udpated to implement the above described reset
sequence.
Except for reset update, most changes are minor, many of them just
modifying dev->link to ata_dev_phys_link(dev) or using phys online
test instead.
After this update, LLDs can take full advantage of per-dev SCR
registers by simply turning on slave link.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-07-31 17:02:43 +09:00
|
|
|
|
2008-02-13 09:15:09 +09:00
|
|
|
|
2008-03-27 19:14:23 +09:00
|
|
|
|
|
|
|
|
|
2015-01-15 17:32:27 -08:00
|
|
|
|
2006-11-14 22:47:10 +09:00
|
|
|
|
|
|
|
|
|
2016-10-17 11:27:29 -07:00
|
|
|
|
2016-04-04 11:43:57 +02:00
|
|
|
|
|
|
|
|
|
2006-05-15 20:57:53 +09:00
|
|
|
|
2006-04-02 18:51:53 +09:00
|
|
|
|
2007-10-09 15:05:44 +09:00
|
|
|
|
|
|
|
|
|
2006-11-14 22:47:09 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-10-09 15:05:44 +09:00
|
|
|
|
2008-04-07 22:47:19 +09:00
|
|
|
|
|
|
|
|
|
2006-05-31 18:27:44 +09:00
|
|
|
|
2006-11-10 18:08:10 +09:00
|
|
|
|
2007-05-15 03:28:15 +09:00
|
|
|
|
2007-09-23 13:14:12 +09:00
|
|
|
|
|
|
|
|
|
2006-11-01 18:38:52 +09:00
|
|
|
|
2009-01-29 20:31:33 +09:00
|
|
|
|
2007-02-02 16:22:30 +09:00
|
|
|
|
2010-09-01 17:50:05 +02:00
|
|
|
|
|
|
|
|
|
2008-11-10 14:48:21 +09:00
|
|
|
|
2006-03-31 20:41:11 +09:00
|
|
|
|
2006-05-15 20:58:05 +09:00
|
|
|
|
2008-06-17 12:36:26 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
libata: implement slave_link
Explanation taken from the comment of ata_slave_link_init().
In libata, a port contains links and a link contains devices. There
is single host link but if a PMP is attached to it, there can be
multiple fan-out links. On SATA, there's usually a single device
connected to a link but PATA and SATA controllers emulating TF based
interface can have two - master and slave.
However, there are a few controllers which don't fit into this
abstraction too well - SATA controllers which emulate TF interface
with both master and slave devices but also have separate SCR
register sets for each device. These controllers need separate links
for physical link handling (e.g. onlineness, link speed) but should
be treated like a traditional M/S controller for everything else
(e.g. command issue, softreset).
slave_link is libata's way of handling this class of controllers
without impacting core layer too much. For anything other than
physical link handling, the default host link is used for both master
and slave. For physical link handling, separate @ap->slave_link is
used. All dirty details are implemented inside libata core layer.
From LLD's POV, the only difference is that prereset, hardreset and
postreset are called once more for the slave link, so the reset
sequence looks like the following.
prereset(M) -> prereset(S) -> hardreset(M) -> hardreset(S) ->
softreset(M) -> postreset(M) -> postreset(S)
Note that softreset is called only for the master. Softreset resets
both M/S by definition, so SRST on master should handle both (the
standard method will work just fine).
As slave_link excludes PMP support and only code paths which deal with
the attributes of physical link are affected, all the changes are
localized to libata.h, libata-core.c and libata-eh.c.
* ata_is_host_link() updated so that slave_link is considered as host
link too.
* iterator extended to iterate over the slave_link when using the
underbarred version.
* force param handling updated such that devno 16 is mapped to the
slave link/device.
* ata_link_on/offline() updated to return the combined result from
master and slave link. ata_phys_link_on/offline() are the direct
versions.
* EH autopsy and report are performed separately for master slave
links. Reset is udpated to implement the above described reset
sequence.
Except for reset update, most changes are minor, many of them just
modifying dev->link to ata_dev_phys_link(dev) or using phys online
test instead.
After this update, LLDs can take full advantage of per-dev SCR
registers by simply turning on slave link.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2008-07-31 17:02:43 +09:00
|
|
|
|
|
|
|
|
|
2006-05-31 18:27:30 +09:00
|
|
|
|
2007-09-23 13:14:12 +09:00
|
|
|
|
|
|
|
|
|
2005-05-12 15:45:22 -04:00
|
|
|
|
|
|
|
|
|
2007-04-17 23:44:07 +09:00
|
|
|
|
2010-05-25 12:31:38 -07:00
|
|
|
|
2011-01-23 08:28:33 -06:00
|
|
|
|
2012-01-18 20:47:01 -08:00
|
|
|
|
2017-06-04 14:42:20 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-06-25 16:13:03 +08:00
|
|
|
|
|
|
|
|
|
2006-09-28 11:29:01 -07:00
|
|
|
|
2007-05-05 23:50:38 +09:00
|
|
|
|
2009-09-16 04:17:28 +09:00
|
|
|
|
2007-12-15 15:05:01 +09:00
|
|
|
|
2007-05-15 03:28:16 +09:00
|
|
|
|
libata: reimplement ACPI invocation
This patch reimplements ACPI invocation such that, instead of
exporting ACPI details to the rest of libata, ACPI event handlers -
ata_acpi_on_resume() and ata_acpi_on_devcfg() - are used. These two
functions are responsible for determining whether specific ACPI method
is used and when.
On resume, _GTF is scheduled by setting ATA_DFLAG_ACPI_PENDING device
flag. This is done this way to avoid performing the action on wrong
device device (device swapping while suspended).
On every ata_dev_configure(), ata_acpi_on_devcfg() is called, which
performs _SDD and _GTF. _GTF is performed only after resuming and, if
SATA, hardreset as the ACPI spec specifies. As _GTF may contain
arbitrary commands, IDENTIFY page is re-read after _GTF taskfiles are
executed.
If one of ACPI methods fails, ata_acpi_on_devcfg() retries on the
first failure. If it fails again on the second try, ACPI is disabled
on the device. Note that successful configuration clears ACPI failed
status.
With all feature checks moved to the above two functions,
do_drive_set_taskfiles() is trivial and thus collapsed into
ata_acpi_exec_tfs(), which is now static and converted to return the
number of executed taskfiles to be used by ata_acpi_on_resume(). As
failures are handled properly, ata_acpi_push_id() now returns -errno
on errors instead of unconditional zero.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-05-15 03:28:16 +09:00
|
|
|
|
2007-12-15 15:05:01 +09:00
|
|
|
|
|
|
|
|
|
2007-11-02 09:32:38 +08:00
|
|
|
|
ata: acpi: rework the ata acpi bind support
Binding ACPI handle to SCSI device has several drawbacks, namely:
1 During ATA device initialization time, ACPI handle will be needed
while SCSI devices are not created yet. So each time ACPI handle is
needed, instead of retrieving the handle by ACPI_HANDLE macro,
a namespace scan is performed to find the handle for the corresponding
ATA device. This is inefficient, and also expose a restriction on
calling path not holding any lock.
2 The binding to SCSI device tree makes code complex, while at the same
time doesn't bring us any benefit. All ACPI handlings are still done
in ATA module, not in SCSI.
Rework the ATA ACPI binding code to bind ACPI handle to ATA transport
devices(ATA port and ATA device). The binding needs to be done only once,
since the ATA transport devices do not go away with hotplug. And due to
this, the flush_work call in hotplug handler for ATA bay is no longer
needed.
Tested on an Intel test platform for binding and runtime power off for
ODD(ZPODD) and hard disk; on an ASUS S400C for binding and normal boot
and S3, where its SATA port node has _SDD and _GTF control methods when
configured as an AHCI controller and its PATA device node has _GTF
control method when configured as an IDE controller. SATA PMP binding
and ATA hotplug is not tested.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: Dirk Griesbach <spamthis@freenet.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-08-23 10:17:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-09-28 11:29:01 -07:00
|
|
|
|
2007-12-15 15:05:01 +09:00
|
|
|
|
2007-05-15 03:28:16 +09:00
|
|
|
|
libata: reimplement ACPI invocation
This patch reimplements ACPI invocation such that, instead of
exporting ACPI details to the rest of libata, ACPI event handlers -
ata_acpi_on_resume() and ata_acpi_on_devcfg() - are used. These two
functions are responsible for determining whether specific ACPI method
is used and when.
On resume, _GTF is scheduled by setting ATA_DFLAG_ACPI_PENDING device
flag. This is done this way to avoid performing the action on wrong
device device (device swapping while suspended).
On every ata_dev_configure(), ata_acpi_on_devcfg() is called, which
performs _SDD and _GTF. _GTF is performed only after resuming and, if
SATA, hardreset as the ACPI spec specifies. As _GTF may contain
arbitrary commands, IDENTIFY page is re-read after _GTF taskfiles are
executed.
If one of ACPI methods fails, ata_acpi_on_devcfg() retries on the
first failure. If it fails again on the second try, ACPI is disabled
on the device. Note that successful configuration clears ACPI failed
status.
With all feature checks moved to the above two functions,
do_drive_set_taskfiles() is trivial and thus collapsed into
ata_acpi_exec_tfs(), which is now static and converted to return the
number of executed taskfiles to be used by ata_acpi_on_resume(). As
failures are handled properly, ata_acpi_push_id() now returns -errno
on errors instead of unconditional zero.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-05-15 03:28:16 +09:00
|
|
|
|
2007-12-15 15:05:01 +09:00
|
|
|
|
|
|
|
|
|
2007-11-02 09:32:38 +08:00
|
|
|
|
|
|
|
|
|
ata: acpi: rework the ata acpi bind support
Binding ACPI handle to SCSI device has several drawbacks, namely:
1 During ATA device initialization time, ACPI handle will be needed
while SCSI devices are not created yet. So each time ACPI handle is
needed, instead of retrieving the handle by ACPI_HANDLE macro,
a namespace scan is performed to find the handle for the corresponding
ATA device. This is inefficient, and also expose a restriction on
calling path not holding any lock.
2 The binding to SCSI device tree makes code complex, while at the same
time doesn't bring us any benefit. All ACPI handlings are still done
in ATA module, not in SCSI.
Rework the ATA ACPI binding code to bind ACPI handle to ATA transport
devices(ATA port and ATA device). The binding needs to be done only once,
since the ATA transport devices do not go away with hotplug. And due to
this, the flush_work call in hotplug handler for ATA bay is no longer
needed.
Tested on an Intel test platform for binding and runtime power off for
ODD(ZPODD) and hard disk; on an ASUS S400C for binding and normal boot
and S3, where its SATA port node has _SDD and _GTF control methods when
configured as an AHCI controller and its PATA device node has _GTF
control method when configured as an IDE controller. SATA PMP binding
and ATA hotplug is not tested.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: Dirk Griesbach <spamthis@freenet.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
2013-08-23 10:17:54 +08:00
|
|
|
|
|
|
|
|
|
2006-09-28 11:29:01 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-04-17 23:44:07 +09:00
|
|
|
|
|
|
|
|
|
2007-07-16 14:29:40 +09:00
|
|
|
|
2006-05-31 18:28:01 +09:00
|
|
|
|
2016-04-04 11:44:03 +02:00
|
|
|
|
|
|
|
|
|
2016-04-04 11:43:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-23 13:14:13 +09:00
|
|
|
|
2006-11-22 14:55:48 +00:00
|
|
|
|
2006-05-15 20:58:07 +09:00
|
|
|
|
2006-11-22 14:55:48 +00:00
|
|
|
|
2006-08-07 14:27:31 -05:00
|
|
|
|
2010-05-25 12:31:38 -07:00
|
|
|
|
2014-06-25 15:27:36 +02:00
|
|
|
|
2015-01-23 19:52:07 -08:00
|
|
|
|
|
|
|
|
|
2010-05-25 12:31:38 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-02 18:51:53 +09:00
|
|
|
|
2008-05-20 02:17:54 +09:00
|
|
|
|
|
|
|
|
|
libata: implement cross-port EH exclusion
In libata, the non-EH code paths should always take and release
ap->lock explicitly when accessing hardware or shared data structures.
However, once EH is active, it's assumed that the port is owned by EH
and EH methods don't explicitly take ap->lock unless race from irq
handler or other code paths are expected. However, libata EH didn't
guarantee exclusion among EHs for ports of the same host. IOW,
multiple EHs may execute in parallel on multiple ports of the same
controller.
In many cases, especially in SATA, the ports are completely
independent of each other and this doesn't cause problems; however,
there are cases where different ports share the same resource, which
lead to obscure timing related bugs such as the one fixed by commit
213373cf (ata_piix: fix locking around SIDPR access).
This patch implements exclusion among EHs of the same host. When EH
begins, it acquires per-host EH ownership by calling ata_eh_acquire().
When EH finishes, the ownership is released by calling
ata_eh_release(). EH ownership is also released whenever the EH
thread goes to sleep from ata_msleep() or explicitly and reacquired
after waking up.
This ensures that while EH is actively accessing the hardware, it has
exclusive access to it while allowing EHs to interleave and progress
in parallel as they hit waiting stages, which dominate the time spent
in EH. This achieves cross-port EH exclusion without pervasive and
fragile changes while still allowing parallel EH for the most part.
This was first reported by yuanding02@gmail.com more than three years
ago in the following bugzilla. :-)
https://bugzilla.kernel.org/show_bug.cgi?id=8223
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reported-by: yuanding02@gmail.com
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2010-09-06 17:57:14 +02:00
|
|
|
|
|
|
|
|
|
2006-04-11 13:04:39 -04:00
|
|
|
|
2017-10-16 14:56:42 -07:00
|
|
|
|
2006-05-15 20:58:05 +09:00
|
|
|
|
2009-01-29 20:31:30 +09:00
|
|
|
|
2007-09-23 13:14:12 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-14 20:43:39 -06:00
|
|
|
|
2007-09-23 13:14:12 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-27 19:28:55 +09:00
|
|
|
|
2007-09-23 13:14:12 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-25 12:31:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libata: check zero power ready status for ZPODD
Per the Mount Fuji spec, the ODD is considered zero power ready when:
- For slot type ODD, no media inside;
- For tray type ODD, no media inside and tray closed.
The information can be retrieved by either the returned information of
command GET_EVENT_STATUS_NOTIFICATION(the command is used to poll for
media event) or sense code.
The information provided by the media status byte is not accurate, it
is possible that after a new disc is just inserted, the status byte
still returns media not present. So this information can not be used as
the deciding factor, we use sense code to decide if zpready status is
true.
When we first sensed the ODD in the zero power ready state, the
zp_sampled will be set and timestamp will be recoreded. And after ODD
stayed in this state for some pre-defined period, the ODD is considered
as power off ready and the zp_ready flag will be set. The zp_ready flag
serves as the deciding factor other code will use to see if power off is
OK for the ODD.
The Mount Fuji spec suggests a delay should be used here, to avoid the
case user ejects the ODD and then instantly inserts a new one again, so
that we can avoid a power transition. And some ODDs may be slow to place
its head to the home position after disc is ejected, so a delay here is
generally a good idea. And the delay time can be changed via the module
param zpodd_poweroff_delay.
The zero power ready status check is performed in the ata port's runtime
suspend code path, when port is not frozen yet, as we need to issue some
IOs to the ODD.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2013-01-15 17:21:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-04-02 18:51:53 +09:00
|
|
|
|
2008-04-07 22:47:21 +09:00
|
|
|
|
2008-04-07 22:47:22 +09:00
|
|
|
|
2008-04-07 22:47:21 +09:00
|
|
|
|
|
|
|
|
|
2010-09-01 17:50:07 +02:00
|
|
|
|
|
|
|
|
|
2008-04-07 22:47:21 +09:00
|
|
|
|
2008-04-07 22:47:22 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-01 17:50:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-07 22:47:22 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-07 22:47:21 +09:00
|
|
|
|
2006-10-09 11:10:26 +09:00
|
|
|
|
2008-04-07 22:47:21 +09:00
|
|
|
|
2010-05-10 21:41:38 +02:00
|
|
|
|
2010-05-10 21:41:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-10 21:41:38 +02:00
|
|
|
|
|
|
|
|
|
2010-05-10 21:41:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-07 22:47:21 +09:00
|
|
|
|
2007-01-30 00:59:17 -08:00
|
|
|
|
2013-01-15 17:20:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libata: check zero power ready status for ZPODD
Per the Mount Fuji spec, the ODD is considered zero power ready when:
- For slot type ODD, no media inside;
- For tray type ODD, no media inside and tray closed.
The information can be retrieved by either the returned information of
command GET_EVENT_STATUS_NOTIFICATION(the command is used to poll for
media event) or sense code.
The information provided by the media status byte is not accurate, it
is possible that after a new disc is just inserted, the status byte
still returns media not present. So this information can not be used as
the deciding factor, we use sense code to decide if zpready status is
true.
When we first sensed the ODD in the zero power ready state, the
zp_sampled will be set and timestamp will be recoreded. And after ODD
stayed in this state for some pre-defined period, the ODD is considered
as power off ready and the zp_ready flag will be set. The zp_ready flag
serves as the deciding factor other code will use to see if power off is
OK for the ODD.
The Mount Fuji spec suggests a delay should be used here, to avoid the
case user ejects the ODD and then instantly inserts a new one again, so
that we can avoid a power transition. And some ODDs may be slow to place
its head to the home position after disc is ejected, so a delay here is
generally a good idea. And the delay time can be changed via the module
param zpodd_poweroff_delay.
The zero power ready status check is performed in the ata port's runtime
suspend code path, when port is not frozen yet, as we need to issue some
IOs to the ODD.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2013-01-15 17:21:00 +08:00
|
|
|
|
2013-01-15 17:21:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-15 17:20:58 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
libata: check zero power ready status for ZPODD
Per the Mount Fuji spec, the ODD is considered zero power ready when:
- For slot type ODD, no media inside;
- For tray type ODD, no media inside and tray closed.
The information can be retrieved by either the returned information of
command GET_EVENT_STATUS_NOTIFICATION(the command is used to poll for
media event) or sense code.
The information provided by the media status byte is not accurate, it
is possible that after a new disc is just inserted, the status byte
still returns media not present. So this information can not be used as
the deciding factor, we use sense code to decide if zpready status is
true.
When we first sensed the ODD in the zero power ready state, the
zp_sampled will be set and timestamp will be recoreded. And after ODD
stayed in this state for some pre-defined period, the ODD is considered
as power off ready and the zp_ready flag will be set. The zp_ready flag
serves as the deciding factor other code will use to see if power off is
OK for the ODD.
The Mount Fuji spec suggests a delay should be used here, to avoid the
case user ejects the ODD and then instantly inserts a new one again, so
that we can avoid a power transition. And some ODDs may be slow to place
its head to the home position after disc is ejected, so a delay here is
generally a good idea. And the delay time can be changed via the module
param zpodd_poweroff_delay.
The zero power ready status check is performed in the ata port's runtime
suspend code path, when port is not frozen yet, as we need to issue some
IOs to the ODD.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2013-01-15 17:21:00 +08:00
|
|
|
|
2013-01-15 17:21:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-15 17:20:58 +08:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
