From: Phillip Susi <phill@thesusis.net>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management
Date: Fri, 03 Nov 2023 14:05:17 -0400 [thread overview]
Message-ID: <87h6m24srm.fsf@vps.thesusis.net> (raw)
In-Reply-To: <969790e6-7050-43b9-bb0b-4b55baa21cc9@kernel.org>
Sorry for the delay, I've been out sick all week.
Damien Le Moal <dlemoal@kernel.org> writes:
> Sure, but I think we can skip the spinup only and only if the drive has PUIS
> enabled and reported a complete IDENTIFY: in this case, we can skip the SET
> FEATURES command that spins up the drive to leave the drive spun down. Some more
> code will be needed though so that we track that the drive is spun sdown because
> of PUIS and not because of STANDBY IMMEDIATE, so that ata_dev_power_set_active()
> issues a SET FEATURES to spinup the drive instead of the regular VERIFY command.
I don't see why the revalidation MUST be performed at system resume.
The patch I've been working on leaves the error flags and also sets the
DFLAG_SLEEPING flag on the disk when it's PuiS. Then later when the
disk is accessed, the SLEEPING flag schedules another round of eh, which
resets the link, and revalidates the disk, and this time the SET
FEATURES command is used to wake the drive. I'll post the patch in a
few hours when I get home.
The basic case of postponing the wakeup of the drive until the disk is
later accessed seems to work fine. Unfortunately, that later access
comes quickly either in the form of a CHECK POWER CONDITION from
udisks2.service, or FLUSH CACHE from the filesystem. These commands
don't cause the drive to spin up when it is in ata STANDBY mode, but do
with runtime suspend. I'm leaning towards modifying the blk_queue to
allow the driver to register a method to be called on a request when the
block device is runtime suspended to possibly handle the request without
activating the block device first.
> Note: I am still not able to see runtime suspend automatically suspend the ata
> port if I enable a scsi disk autosuspend_delay_ms. That does not happen for me.
> In fact, I cannot even read a ata port autosuspend delay:
>
> cat /sys/class/ata_port/ata2/power/autosuspend_delay_ms
> cat: /sys/class/ata_port/ata2/power/autosuspend_delay_ms: Input/output error
Right, there is no activity timer on the port.
> But I have:
>
> cat /sys/class/ata_port/ata2/power/control
> auto
If that is set to auto then it seems to auto suspend once all children
have gone to runtime suspend. For my internal ports, they only have a
single child, so when the drive enters runtime suspend, so does the
port. For the eSATA PMP dock, BOTH drives have to suspend before the
port will.
next prev parent reply other threads:[~2023-11-03 18:05 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <c0b086ab-dcd5-4b7b-b931-4d407dd7ad47()kernel!org>
2023-10-12 19:01 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Phillip Susi
2023-10-13 0:57 ` Damien Le Moal
2023-10-13 14:36 ` Phillip Susi
2023-10-15 22:09 ` Damien Le Moal
2023-10-21 17:56 ` Phillip Susi
2023-10-23 5:49 ` Damien Le Moal
2023-11-03 18:05 ` Phillip Susi [this message]
2023-11-03 23:01 ` Phillip Susi
2023-11-06 2:32 ` Damien Le Moal
2023-11-07 13:27 ` Phillip Susi
2023-11-07 21:59 ` Damien Le Moal
2023-11-08 22:07 ` Phillip Susi
2023-11-06 3:00 ` Damien Le Moal
2023-11-07 13:45 ` Phillip Susi
2023-11-07 21:48 ` Phillip Susi
2023-11-07 23:11 ` Damien Le Moal
2023-11-08 22:15 ` Phillip Susi
2023-11-09 22:09 ` Phillip Susi
2023-11-09 22:57 ` Damien Le Moal
2023-11-10 16:41 ` Phillip Susi
2023-11-10 0:43 ` Damien Le Moal
2023-11-07 22:13 ` Damien Le Moal
2023-11-08 22:25 ` Phillip Susi
2023-09-27 14:18 [PATCH v8 00/23] Fix libata suspend/resume handling and code cleanup Damien Le Moal
2023-09-27 14:18 ` [PATCH v8 04/23] scsi: sd: Differentiate system and runtime start/stop management Damien Le Moal
2023-09-27 19:50 ` Martin K. Petersen
2023-10-10 13:09 ` Phillip Susi
2023-10-10 14:04 ` Damien Le Moal
2023-10-15 16:14 ` Phillip Susi
2023-10-15 22:44 ` Damien Le Moal
2023-10-16 12:39 ` Phillip Susi
2023-10-16 12:55 ` Damien Le Moal
2023-10-17 18:03 ` Phillip Susi
2023-10-17 23:32 ` Damien Le Moal
2023-10-20 19:00 ` Phillip Susi
2023-10-18 6:16 ` Damien Le Moal
2023-10-20 21:23 ` Phillip Susi
2023-10-23 5:51 ` Damien Le Moal
2023-10-26 21:21 ` Phillip Susi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6m24srm.fsf@vps.thesusis.net \
--to=phill@thesusis.net \
--cc=dlemoal@kernel.org \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox