2019-05-19 15:51:48 +02:00
|
|
|
|
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-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
|
|
|
|
|
|
|
|
|
2023-09-08 20:04:52 +09: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
|
|
|
|
2024-07-17 17:39:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 16:58:22 +01:00
|
|
|
|
2008-02-13 09:15:09 +09:00
|
|
|
|
2020-03-26 16:58:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-27 19:14:23 +09:00
|
|
|
|
|
|
|
|
|
2022-07-25 10:01:27 +09:00
|
|
|
|
2023-05-11 03:13:51 +02:00
|
|
|
|
2016-04-04 11:43:57 +02:00
|
|
|
|
|
|
|
|
|
2024-04-02 14:59:52 +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
|
|
|
|
2023-08-29 10:18:34 +09:00
|
|
|
|
|
|
|
|
|
ata: libata-scsi: Disable scsi device manage_system_start_stop
The introduction of a device link to create a consumer/supplier
relationship between the scsi device of an ATA device and the ATA port
of that ATA device fixes the ordering of system suspend and resume
operations. For suspend, the scsi device is suspended first and the ata
port after it. This is fine as this allows the synchronize cache and
START STOP UNIT commands issued by the scsi disk driver to be executed
before the ata port is disabled.
For resume operations, the ata port is resumed first, followed
by the scsi device. This allows having the request queue of the scsi
device to be unfrozen after the ata port resume is scheduled in EH,
thus avoiding to see new requests prematurely issued to the ATA device.
Since libata sets manage_system_start_stop to 1, the scsi disk resume
operation also results in issuing a START STOP UNIT command to the
device being resumed so that the device exits standby power mode.
However, restoring the ATA device to the active power mode must be
synchronized with libata EH processing of the port resume operation to
avoid either 1) seeing the start stop unit command being received too
early when the port is not yet resumed and ready to accept commands, or
after the port resume process issues commands such as IDENTIFY to
revalidate the device. In this last case, the risk is that the device
revalidation fails with timeout errors as the drive is still spun down.
Commit 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
disabled issuing the START STOP UNIT command to avoid issues with it.
But this is incorrect as transitioning a device to the active power
mode from the standby power mode set on suspend requires a media access
command. The IDENTIFY, READ LOG and SET FEATURES commands executed in
libata EH context triggered by the ata port resume operation may thus
fail.
Fix these synchronization issues is by handling a device power mode
transitions for system suspend and resume directly in libata EH context,
without relying on the scsi disk driver management triggered with the
manage_system_start_stop flag.
To do this, the following libata helper functions are introduced:
1) ata_dev_power_set_standby():
This function issues a STANDBY IMMEDIATE command to transitiom a device
to the standby power mode. For HDDs, this spins down the disks. This
function applies only to ATA and ZAC devices and does nothing otherwise.
This function also does nothing for devices that have the
ATA_FLAG_NO_POWEROFF_SPINDOWN or ATA_FLAG_NO_HIBERNATE_SPINDOWN flag
set.
For suspend, call ata_dev_power_set_standby() in
ata_eh_handle_port_suspend() before the port is disabled and frozen.
ata_eh_unload() is also modified to transition all enabled devices to
the standby power mode when the system is shutdown or devices removed.
2) ata_dev_power_set_active() and
This function applies to ATA or ZAC devices and issues a VERIFY command
for 1 sector at LBA 0 to transition the device to the active power mode.
For HDDs, since this function will complete only once the disk spin up.
Its execution uses the same timeouts as for reset, to give the drive
enough time to complete spinup without triggering a command timeout.
For resume, call ata_dev_power_set_active() in
ata_eh_revalidate_and_attach() after the port has been enabled and
before any other command is issued to the device.
With these changes, the manage_system_start_stop and no_start_on_resume
scsi device flags do not need to be set in ata_scsi_dev_config(). The
flag manage_runtime_start_stop is still set to allow the sd driver to
spinup/spindown a disk through the sd runtime operations.
Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-08-26 09:43:39 +09:00
|
|
|
|
|
|
|
|
|
2024-09-05 10:51:19 +09:00
|
|
|
|
2007-02-02 16:22:30 +09:00
|
|
|
|
2010-09-01 17:50:05 +02:00
|
|
|
|
2022-08-16 13:53:28 +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
|
|
|
|
|
|
|
|
|
2010-05-25 12:31:38 -07:00
|
|
|
|
2017-06-04 14:42:20 +02:00
|
|
|
|
|
|
|
|
|
2024-07-17 17:55:31 +09:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2012-06-25 16:13:03 +08:00
|
|
|
|
|
|
|
|
|
2024-07-17 17:39:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-10 19:11:31 +09:00
|
|
|
|
2024-07-17 17:39:29 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-10 19:11:31 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-17 17:39:29 +09: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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2020-03-26 16:58:18 +01:00
|
|
|
|
|
|
|
|
|
2007-04-17 23:44:07 +09:00
|
|
|
|
2023-03-22 12:53:59 -07:00
|
|
|
|
2007-07-16 14:29:40 +09:00
|
|
|
|
2006-05-31 18:28:01 +09:00
|
|
|
|
2022-09-26 20:53:07 +00: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
|
|
|
|
|
|
|
|
|
2010-05-25 12:31:38 -07:00
|
|
|
|
2014-06-25 15:27:36 +02:00
|
|
|
|
2020-03-26 16:58:19 +01:00
|
|
|
|
2024-04-09 16:37:45 +02:00
|
|
|
|
|
|
|
|
|
2020-03-26 16:58:19 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-02 18:51:53 +09:00
|
|
|
|
2022-06-18 23:38:10 +03: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-21 08:20:36 +01: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
|
|
|
|
|
|
|
|
|
2021-12-21 08:20:25 +01:00
|
|
|
|
ata: libata: Add helper ata_eh_decide_disposition()
Every time I see libata code calling scsi_check_sense(), I get confused
why the code path that is working fine for SCSI code, is not sufficient
for libata code.
The reason is that SCSI usually gets the sense data as part of the
completion, and will thus automatically call scsi_check_sense(), which
will set the SCSI ML byte (if any).
However, for libata queued commands, we always need to fetch the sense
data via SCSI EH, and thus do not get the luxury of having
scsi_check_sense() called automatically.
Add a new helper, ata_eh_decide_disposition(), that has a ata_eh_ prefix
to more clearly highlight that this is only needed for code called by EH,
while also having a similar name to scsi_decide_disposition(), such that
it is easier to compare the libata code with the equivalent SCSI code.
Also add a big kdoc comment explaining why this helper is called/needed in
the first place.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2024-08-28 09:27:04 +02: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
|
|
|
|
