From: Phillip Susi <phill@thesusis.net>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH 1/1] libata: only wake a drive once on system resume
Date: Thu, 04 Jan 2024 09:05:39 -0500 [thread overview]
Message-ID: <87y1d5kxcc.fsf@vps.thesusis.net> (raw)
In-Reply-To: <0f53d7b2-9980-4223-92f5-519207e9b486@kernel.org>
Damien Le Moal <dlemoal@kernel.org> writes:
> Correct, if it succeeds, no need to do it again. The problem with clearing the
> flag though is that ATA_EH_SET_ACTIVE is for the device and that is set only if
> ATA_PFLAG_RESUMING is set, but that one is for the port. So if resume for the
> device succeeds, you can clear the ATA_PFLAG_RESUMING flag *only* if there is
> only a single link/device for that port. If not, other devices on the port may
> need a retry so we cannot clear ATA_PFLAG_RESUMING.
Rather than clear ATA_PFLAG_RESUMING, I was thinking of keeping my
previus change to specify ATA_EH_SET_ACTIVE in the request_pm path
rather than by setting it based on ATA_PFLAG_RESUMING, but just adding a
check to see if the VERIFY fails, and if so, set ATA_EH_SET_ACTIVE again.
> Ah, now I think I understand: is it your patch that prevents resuming a drive if
> it has PUIS on ? If yes, then sure, the verify command to spin-up the drive will
> indeed fail immediately if the drive is in standby from PUIS, since getting out
> of standby state driven by PUIS requires a set features spinup. So... with your
> patch, things will not work.
Right... unless you also apply this patch to make sure that
ATA_EH_SET_ACTIVE isn't turned on again after it is cleared when PuiS is detected.
> If PUIS is not enabled, the only thing wasted is a check power mode command. If
> the drive confirms that it is active, verify command is not issued.
Ahh, right... I forgot you did add a CHECK POWER MODE first.
> With PUIS enabled though, if you leave the drive in standby mode, when/how do
> you actually wake it up ?
Initially I just set the ATA_DFLAG_SLEEPING flag as if the drive had been
put into SLEEP mode, which triggers EH to wake it up when the drive is
accessed. I have since switched to actually putting the drive to SLEEP
mode when PuiS is detected since it will save a little more power than
leaving it in STANDBY.
> Scratching my head about this, I think that doing this cleanly should be
> possible if:
> 1) The dive gives complete identify data when that command is issued with the
> drive in standby state driven by PUIS.
I think you can do it even if the IDENTIFY data is incomplete, as long
as a revalidate_and_attach is done eventually, when waking the drive up.
> 2) The call to ata_dev_configure() executed by ata EH started from system resume
> does not spinup the device if requested not to (libata module & sysfs parameter
> can do that). But I think this requires that the drive be instead put into a
> state equivalent to *runtime* suspend, that is, with the scsi disk associated
> with the device must also be in runtime suspend state.
Yea, I was trying to make it work with runtime suspend before, but you
indicated that the current device hierarchy seems to make that
impossible, so I put that aside for now. Currently runtime pm thinks
the drive is running even though it isn't, but that isn't any different
than when you hdparm -y or hdparm -Y, or hdparm -S and let the drive
decide to auto standby. Eventually I'll try to get the runtime pm
sorted but I figured I'd try to get the basic concept working first.
> With that, it would only be a matter of adding a device flag to remember that
> the drive is in "PUIS stnadby" instead of regular standby, and then have
> ata_dev_power_set_active() use a set feature spinup command instead of a verify.
> Drive spinup will then be cleanly driven by accesses to the scsi disk, similarly
> to a regular runtime suspend.
Right now I'm using the SLEEP flag to do this, and when the disk is
accessed, it triggers a round of EH that does the revalidate_and_attach
and in the process, issues the SET FEATURES command to wake the drive.
> With such changes, everything would be cleaner and safer and all work as
> expected. The exception will be drives that do not give complete identify data
> when PUIS is on. For these, it is too risky to not wake them up to get the full
> information first.
>
> Do you want to try to tackle this ? If you do not feel like it, I can give it a
> try too.
I've already got it working ;)
I think I sent you an earlier version of the patch a few weeks ago.
I'll post my whole series tonight, after I fix the case of retrying the
VERIFY if it fails.
next prev parent reply other threads:[~2024-01-04 14:05 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-25 15:19 [PATCH 0/1] Only activate drive once during system resume Phillip Susi
2023-12-25 15:19 ` [PATCH 1/1] libata: only wake a drive once on " Phillip Susi
2023-12-30 18:21 ` [PATCH 0/1 v2] Only activate drive once during " Phillip Susi
2023-12-30 18:21 ` [PATCH 1/1] libata: only wake a drive once on " Phillip Susi
2023-12-30 19:42 ` Sergey Shtylyov
2024-01-02 23:17 ` Damien Le Moal
2024-01-03 21:00 ` Phillip Susi
2024-01-04 1:21 ` Damien Le Moal
2024-01-04 14:05 ` Phillip Susi [this message]
2024-01-04 22:39 ` [PATCH 1/4] " Phillip Susi
2024-01-04 22:39 ` [PATCH 2/4] libata: don't wake sleeping disk during system suspend Phillip Susi
2024-01-05 12:25 ` Damien Le Moal
2024-01-05 16:18 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 3/4] libata: avoid waking disk for several commands Phillip Susi
2024-01-05 8:46 ` Sergei Shtylyov
2024-01-05 16:24 ` Phillip Susi
2024-01-05 18:33 ` Sergei Shtylyov
2024-01-06 19:49 ` Phillip Susi
2024-01-06 20:29 ` Phillip Susi
2024-01-08 8:57 ` Sergei Shtylyov
2024-01-05 12:29 ` Damien Le Moal
2024-01-05 16:30 ` Phillip Susi
2024-01-06 23:14 ` Damien Le Moal
2024-01-07 17:57 ` Phillip Susi
2024-01-07 18:02 ` [PATCH 0/3] Let sleeping disks lie Phillip Susi
2024-01-07 18:02 ` [PATCH 1/3] libata: avoid waking disk for several commands Phillip Susi
2024-01-08 6:25 ` Damien Le Moal
2024-01-08 13:27 ` Phillip Susi
2024-01-10 2:39 ` Damien Le Moal
2024-01-16 17:06 ` Phillip Susi
2024-01-19 20:43 ` Phillip Susi
2024-01-20 18:08 ` Phillip Susi
2024-01-21 0:37 ` Damien Le Moal
2024-01-21 0:37 ` Damien Le Moal
2024-01-24 16:04 ` Phillip Susi
2024-01-24 21:51 ` Damien Le Moal
2024-02-01 20:01 ` Phillip Susi
2024-02-02 1:08 ` Damien Le Moal
2024-02-02 19:53 ` Phillip Susi
2024-02-02 23:17 ` Damien Le Moal
2024-02-05 19:52 ` Phillip Susi
2024-01-08 8:48 ` Sergey Shtylyov
2024-01-08 13:30 ` Phillip Susi
2024-01-07 18:02 ` [PATCH 2/3] libata: only wake a drive once on system resume Phillip Susi
2024-01-08 6:04 ` Damien Le Moal
2024-01-07 18:02 ` [PATCH 3/3] libata: don't start PuiS disks on resume Phillip Susi
2024-01-08 6:03 ` Damien Le Moal
2024-01-08 13:39 ` Phillip Susi
2024-01-10 2:19 ` Damien Le Moal
2024-01-16 17:13 ` Phillip Susi
2024-01-04 22:39 ` [PATCH 4/4] " Phillip Susi
2024-01-05 8:57 ` Sergei Shtylyov
2024-01-05 12:42 ` Damien Le Moal
2024-01-05 16:44 ` Phillip Susi
2024-01-05 12:13 ` [PATCH 1/4] libata: only wake a drive once on system resume Damien Le Moal
2024-01-05 17:03 ` Phillip Susi
2024-01-06 23:06 ` Damien Le Moal
2024-01-05 12:44 ` Damien Le Moal
2024-01-09 15:20 ` [PATCH 0/1 v2] Only activate drive once during " Niklas Cassel
2024-01-16 17:23 ` Phillip Susi
2024-01-02 22:46 ` [PATCH 0/1] " Damien Le Moal
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=87y1d5kxcc.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).