From: Jeff Garzik <jeff@garzik.org>
To: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: linux-ide@vger.kernel.org, arjan@linux.intel.com
Subject: Re: [patch 2/2] libata: power off unused ports
Date: Sat, 12 Apr 2008 00:28:13 -0400 [thread overview]
Message-ID: <48003A5D.9000306@garzik.org> (raw)
In-Reply-To: <20080325152813.0b34761f@appleyard>
Kristen Carlson Accardi wrote:
> If a port doesn't support hot plug, there's no reason to keep the phy powered
> on unoccupied ports.
>
> Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
>
> Index: linux-2.6.25-rc3/drivers/ata/ahci.c
> ===================================================================
> --- linux-2.6.25-rc3.orig/drivers/ata/ahci.c
> +++ linux-2.6.25-rc3/drivers/ata/ahci.c
> @@ -52,6 +52,7 @@
> static int ahci_enable_alpm(struct ata_port *ap,
> enum link_pm policy);
> static void ahci_disable_alpm(struct ata_port *ap);
> +static int ahci_is_hotplug_capable(struct ata_port *ap);
>
> enum {
> AHCI_PCI_BAR = 5,
> @@ -163,6 +164,7 @@ enum {
> PORT_CMD_ASP = (1 << 27), /* Aggressive Slumber/Partial */
> PORT_CMD_ALPE = (1 << 26), /* Aggressive Link PM enable */
> PORT_CMD_ATAPI = (1 << 24), /* Device is ATAPI */
> + PORT_CMD_HPCP = (1 << 18), /* port is hot plug capable */
Under which conditions is this bit set?
The conclusion reached by this patch seems correct, but I am not sure
about the premise...
I was under the impression that AHCI ports were hotplug capable, from
libata's point of view, simply due to the fundamentals of SATA.
Thinking about the bigger pictures, powering off the phy is something we
want to do in a lot more cases than this, but there is a stumbling
block: we wander into the realm of policy.
For most users most of the time, empty SATA ports are needlessly
powered. The problem is that, at any given moment, a device may be
hot-plugged, so we must be ready for that. We need some way for the
user to let the driver know that they will not be hotplugging anything
anytime soon, permitting power savings to be enabled.
A compromise solution that avoids adding a userspace "knob" has also
been proposed (by Tejun, I think?): power up the phy every N seconds,
check for device, power down phy if nothing. That should provide some
power savings, though not as much as with a "knob" switched to "hotplug:
off"
Jeff
next prev parent reply other threads:[~2008-04-12 4:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080325221646.567639335@intel.com>
2008-03-25 22:28 ` [patch 1/2] ahci: Dont start port DMA engines unless a device is present Kristen Carlson Accardi
2008-04-12 4:21 ` Jeff Garzik
2008-03-25 22:28 ` [patch 2/2] libata: power off unused ports Kristen Carlson Accardi
2008-03-28 7:43 ` Andi Kleen
2008-03-28 17:00 ` Kristen Carlson Accardi
2008-04-12 4:28 ` Jeff Garzik [this message]
2008-04-14 23:11 ` Kristen Carlson Accardi
2008-04-15 19:02 ` Mark Lord
2008-04-24 17:45 ` Kristen Carlson Accardi
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=48003A5D.9000306@garzik.org \
--to=jeff@garzik.org \
--cc=arjan@linux.intel.com \
--cc=kristen.c.accardi@intel.com \
--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 NNTP newsgroup(s).