[PATCH] pata_it821x: (partially) fix DMA in RAID mode
Code intended to check DMA status was checking DMA command register.
Moreover firmware seems to forget to set DMA capable bit for the
slave device (at least in RAID mode but without ITE RAID volumes) so
check device ID for DMA capable bit when deciding whether to use DMA
and remove DMA status check completely.
Thanks to Pavol Simo for the bugreport and testing the initial fix.
This change unfortunately still doesn't fix DMA in RAID mode (which
works fine with IDE it821x) but Alan is working on the missing pieces
(pata_it821x vs libata EH issues).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Acked-by: Alan Cox [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
---
removed non-ASCII char from the patch description + added Alan's ACK
drivers/ata/pata_it821x.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
Index: b/drivers/ata/pata_it821x.c
===
--- a/drivers/ata/pata_it821x.c
+++ b/drivers/ata/pata_it821x.c
@@ -2,6 +2,7 @@
* pata_it821x.c - IT821x PATA for new ATA layer
* (C) 2005 Red Hat Inc
* Alan Cox [EMAIL PROTECTED]
+ * (C) 2007 Bartlomiej Zolnierkiewicz
*
* based upon
*
@@ -79,7 +80,7 @@
#define DRV_NAME pata_it821x
-#define DRV_VERSION 0.3.6
+#define DRV_VERSION 0.3.7
struct it821x_dev
{
@@ -460,14 +461,8 @@ static unsigned int it821x_passthru_qc_i
static int it821x_smart_set_mode(struct ata_port *ap, struct ata_device
**unused)
{
- int dma_enabled = 0;
int i;
- /* Bits 5 and 6 indicate if DMA is active on master/slave */
- /* It is possible that BMDMA isn't allocated */
- if (ap-ioaddr.bmdma_addr)
- dma_enabled = ioread8(ap-ioaddr.bmdma_addr + ATA_DMA_CMD);
-
for (i = 0; i ATA_MAX_DEVICES; i++) {
struct ata_device *dev = ap-device[i];
if (ata_dev_enabled(dev)) {
@@ -476,7 +471,7 @@ static int it821x_smart_set_mode(struct
dev-dma_mode = XFER_MW_DMA_0;
/* We do need the right mode information for DMA or PIO
and this comes from the current configuration flags
*/
- if (dma_enabled (1 (5 + i))) {
+ if (ata_id_has_dma(dev-id)) {
ata_dev_printk(dev, KERN_INFO, configured for
DMA\n);
dev-xfer_mode = XFER_MW_DMA_0;
dev-xfer_shift = ATA_SHIFT_MWDMA;
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AHCI powersaving and port-stopping (2.6.22-rc4)
I just wanted to have a look at the patch and see if it works for me - looks like somethings not all straight, I get this while booting: ahci :00:1f.2: version 2.2 ACPI: PCI Interrupt :00:1f.2[C] - GSI 19 (level, low) - IRQ 19 ahci :00:1f.2: nr_ports (3) and implemented port map (0x1) don't match ahci :00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x1 impl SATA mode ahci :00:1f.2: flags: 64bit ncq pm led clo pio slum part PCI: Setting latency timer of device :00:1f.2 to 64 scsi0 : ahci ata1: SATA max UDMA/133 cmd 0xc2048100 ctl 0x bmdma 0x irq 0 WARNING: at drivers/ata/libata-eh.c:1917 ata_eh_set_powersave() Call Trace: [804a99ce] ata_eh_set_powersave+0x34e/0x370 [8048c7b0] scsi_error_handler+0x0/0x330 [804a9e27] ata_do_eh+0xb7/0x16f0 [80229f9d] find_busiest_group+0x1bd/0x800 [804aece0] ahci_postreset+0x0/0x80 [804ada70] ahci_hardreset+0x0/0xf0 [804aee20] ahci_softreset+0x0/0x270 [804a40f0] ata_std_prereset+0x0/0xf0 [8023b134] lock_timer_base+0x34/0x70 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c7b0] scsi_error_handler+0x0/0x330 [804abc27] ata_scsi_error+0x297/0x730 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c893] scsi_error_handler+0xe3/0x330 [80229507] __wake_up_common+0x47/0x80 [8048c7b0] scsi_error_handler+0x0/0x330 [8024675b] kthread+0x4b/0x80 [8020a9a8] child_rip+0xa/0x12 [80246710] kthread+0x0/0x80 [8020a99e] child_rip+0x0/0x12 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: ATA-7: Hitachi HTS541616J9SA00, SB4OC7DP, max UDMA/100 ata1.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 31/32) ata1.00: ata_hpa_resize 1: sectors = 312581808, hpa_sectors = 312581808 ata1.00: configured for UDMA/100 scsi 0:0:0:0: Direct-Access ATA Hitachi HTS54161 SB4O PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 I hope this output from dmesg helps to make the patch better - if I can do any further testing please let me know! Peter John Fremlin wrote: Tejun Heo has made an excellent patch for saving power with the AHCI chipset. It saves about 1 W on my Thinkpad X60s. This patch will stop the ports when they are idle. To turn it on, echo 1 /sys/module/libata/parameters/powersave This is very different from the patch I posted a while ago turning on a few bits in the CMD register (ALPE and ASP) and which Intel is apparently now trying. That only saves around 250mW. Tejun's patch saves about 1 W. It should also make the ALPE and ASP stuff irrelevant because it performs the same operation in software where better information about usage is (theoretically) available. I have updated the patch for 2.6.22-rc4. That is the extent of my involvement - if it works, thank Tejun Heo. But problems are quite likely to have been introduced by my clumsy update, so if it doesn't work, blame me first. ___ Power mailing list [EMAIL PROTECTED] http://www.bughost.org/mailman/listinfo/power - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized
Problem Sata disks are connected to onboard sata ports of PowerEdge 1900 (ESB2 southbridge chipset). If one of the port is disabled in the bios then they get enabled again by the ata_piix driver because of a default port map being written to the Port control and status register(0x91-93). Instead the driver should preserve the bios setting by way of a fix like this. What happens if the port is enabled by the kernel? The BIOS tests for the device will not be performed for the port since it is disabled by the BIOS, and there is a potential security problem here if they get reenabled in the kernel. If the user decides to disable the port through the BIOS, the driver needs to respect the user's wish to not use the port and carry on. Here the end result is a forceful reinitialization of the port by the driver against the user's wishes. Fix: The BIOS configured PCS value must be anded logically with the default port map for the chipset. This way the BIOS information will not be lost by the reinitialization of the config space by the ata_piix driver. The below patch is against 2.6.21 kernel. I'm not sure whether this is a good idea and it has potential to break a lot of other configurations. That part of code is used for *all* ata_piix out there, so we need a really really good reason to change that. So, please explain what you're trying to fix better. If the fix has a potential to break other things then there could be a module parameter that would let the driver accept the bios configuration for the pcs register and not modify the config space through the driver. -- Shyam -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/message/linux-ide@vger.kernel.org/6886790.html - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AHCI powersaving and port-stopping (2.6.22-rc4)
This is very different from the patch I posted a while ago turning on a few bits in the CMD register (ALPE and ASP) and which Intel is we've not seen a patch that actually works in this area unfortunately. We know Kristen's patch does work apparently now trying. That only saves around 250mW. Tejun's patch .. and saves close to a watt on a laptop in our measurements the patch is available on http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm/ maybe worth a try as well.. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AHCI powersaving and port-stopping (2.6.22-rc4)
Peter Ganzhorn [EMAIL PROTECTED] writes: I just wanted to have a look at the patch and see if it works for me - looks like somethings not all straight, I get this while booting: ahci :00:1f.2: version 2.2 ACPI: PCI Interrupt :00:1f.2[C] - GSI 19 (level, low) - IRQ 19 ahci :00:1f.2: nr_ports (3) and implemented port map (0x1) don't match ahci :00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x1 impl SATA mode ahci :00:1f.2: flags: 64bit ncq pm led clo pio slum part PCI: Setting latency timer of device :00:1f.2 to 64 scsi0 : ahci ata1: SATA max UDMA/133 cmd 0xc2048100 ctl 0x bmdma 0x irq 0 WARNING: at drivers/ata/libata-eh.c:1917 ata_eh_set_powersave() [...] I hope this output from dmesg helps to make the patch better - if I can do any further testing please let me know! That is fine. The warning is expected. There is nothing wrong with it. This patch will stop the ports when they are idle. To turn it on, echo 1 /sys/module/libata/parameters/powersave [...] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PROBLEM + PATCH] Sata port disabled by BIOS gets initialized
Hello, [EMAIL PROTECTED] wrote: What happens if the port is enabled by the kernel? The BIOS tests for the device will not be performed for the port since it is disabled by the BIOS, and there is a potential security problem here if they get reenabled in the kernel. You're trying to protect security by making OS not initialize PCS bits? I'm sorry but there are millions of ways to breach that once one has root access to the OS (e.g. two liner script with setpci and echo to scsi scan sysfs node) or physical access to the machine (connect the drive to a different port or host). If the user doesn't have either, OS security mechanisms work pretty well and are much more flexible and useful. Security-by-preserving-PCS just doesn't fly. Please use Security Mode feature set for that. If the user decides to disable the port through the BIOS, the driver needs to respect the user's wish to not use the port and carry on. Here the end result is a forceful reinitialization of the port by the driver against the user's wishes. Well, currently, the Linux driver policy is to exploit the hardware capability to the maximum - e.g. we unlock HPA unconditionally and force multi-mode controllers into its best possible mode. We try hard to ignore BIOS imposed settings/limits. I'm not sure whether this is a good idea and it has potential to break a lot of other configurations. That part of code is used for *all* ata_piix out there, so we need a really really good reason to change that. So, please explain what you're trying to fix better. If the fix has a potential to break other things then there could be a module parameter that would let the driver accept the bios configuration for the pcs register and not modify the config space through the driver. If reprogramming PCS does break specific cases, I'm willing to modify the driver such that it detects the condition and preserves PCS setting which is far better than requiring the user to enter some kernel parameter but you need to give me much better reason if we're gonna go that way. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/3] AHCI Link Power Management
Hi, This series of patches enables Aggressive Link Power Management for AHCI devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this saves me a full watt of power. On other systems, reported power savings range from .5-1.5 Watts. It has been tested by the kind folks at #powertop with similar results. Please give it a try and let me know what you think. thanks, Kristen -- - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/3] Expose Power Management Policy option to users
This patch will modify the scsi and ata subsystem to allow
users to set a power management policy for the link.
libata drivers can define a function (enable_pm) that will
perform hardware specific actions to enable whatever power
management policy the user sets up if the driver supports
it. This power management policy will be activated after
all disks have been enumerated and intialized.
The scsi subsystem will create a new sysfs file for each
host in /sys/class/scsi_host called link_power_management_policy.
This file can have 3 possible values:
Value Meaning
---
min_power User wishes the link to conserve power as much as
possible, even at the cost of some performance
max_performance User wants priority to be on performance, not power
savings
medium_powerUser wants power savings, with less performance cost
than min_power (but less power savings as well).
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/drivers/ata/libata-scsi.c
===
--- 2.6-git.orig/drivers/ata/libata-scsi.c
+++ 2.6-git/drivers/ata/libata-scsi.c
@@ -2890,6 +2890,51 @@ void ata_scsi_simulate(struct ata_device
}
}
+int ata_scsi_set_link_pm_policy(struct Scsi_Host *shost,
+ enum scsi_host_link_pm policy)
+{
+ struct ata_port *ap = ata_shost_to_port(shost);
+ int rc = -EINVAL;
+ int i;
+
+ /*
+* make sure no broken devices are on this port,
+* and that all devices support interface power
+* management
+*/
+ for (i = 0; i ATA_MAX_DEVICES; i++) {
+ struct ata_device *dev = ap-device[i];
+
+ /* only check drives which exist */
+ if (!ata_dev_enabled(dev))
+ continue;
+
+ /*
+* do we need to handle the case where we've hotplugged
+* a broken drive (since hotplug and ALPM are mutually
+* exclusive) ?
+*
+* If so, if we detect a broken drive on a port with
+* alpm already enabled, then we should reset the policy
+* to off for the entire port.
+*/
+ if ((dev-horkage ATA_HORKAGE_ALPM) ||
+ !(dev-flags ATA_DFLAG_IPM)) {
+ ata_dev_printk(dev, KERN_ERR,
+ Unable to set Link PM policy\n);
+ ap-pm_policy = SHOST_MAX_PERFORMANCE;
+ }
+ }
+
+ if (ap-ops-enable_pm)
+ rc = ap-ops-enable_pm(ap, policy);
+
+ if (!rc)
+ shost-shost_link_pm_policy = ap-pm_policy;
+ return rc;
+}
+EXPORT_SYMBOL_GPL(ata_scsi_set_link_pm_policy);
+
int ata_scsi_add_hosts(struct ata_host *host, struct scsi_host_template *sht)
{
int i, rc;
@@ -2912,7 +2957,7 @@ int ata_scsi_add_hosts(struct ata_host *
shost-max_lun = 1;
shost-max_channel = 1;
shost-max_cmd_len = 16;
-
+ shost-shost_link_pm_policy = ap-pm_policy;
rc = scsi_add_host(ap-scsi_host, ap-host-dev);
if (rc)
goto err_add;
Index: 2.6-git/drivers/scsi/hosts.c
===
--- 2.6-git.orig/drivers/scsi/hosts.c
+++ 2.6-git/drivers/scsi/hosts.c
@@ -54,6 +54,25 @@ static struct class shost_class = {
};
/**
+ * scsi_host_set_link_pm - Change the link power management policy
+ * @shost: scsi host to change the policy of.
+ * @policy:policy to change to.
+ *
+ * Returns zero if successful or an error if the requested
+ * transition is illegal.
+ **/
+int scsi_host_set_link_pm(struct Scsi_Host *shost,
+ enum scsi_host_link_pm policy)
+{
+ struct scsi_host_template *sht = shost-hostt;
+ if (sht-set_link_pm_policy)
+ sht-set_link_pm_policy(shost, policy);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(scsi_host_set_link_pm);
+
+/**
* scsi_host_set_state - Take the given host through the host
* state model.
* @shost: scsi host to change the state of.
Index: 2.6-git/drivers/scsi/scsi_sysfs.c
===
--- 2.6-git.orig/drivers/scsi/scsi_sysfs.c
+++ 2.6-git/drivers/scsi/scsi_sysfs.c
@@ -189,6 +189,74 @@ show_shost_state(struct class_device *cl
static CLASS_DEVICE_ATTR(state, S_IRUGO | S_IWUSR, show_shost_state,
store_shost_state);
+static const struct {
+ enum scsi_host_link_pm value;
+ char*name;
+} shost_link_pm_policy[] = {
+ { SHOST_NOT_AVAILABLE, max_performance },
+ { SHOST_MIN_POWER, min_power },
+ { SHOST_MAX_PERFORMANCE, max_performance },
+ {
[patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive with Hot Plug, so when ALPM is enabled, Hot Plug
is disabled. ALPM will be enabled by default, but it is
settable via the scsi host syfs interface. Possible
settings for this feature are:
Setting Effect
--
min_power ALPM is enabled, and link set to enter
lowest power state (SLUMBER) when idle
Hot plug not allowed.
max_performance ALPM is disabled, Hot Plug is allowed
medium_powerALPM is enabled, and link set to enter
second lowest power state (PARTIAL) when
idle. Hot plug not allowed.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -48,6 +48,9 @@
#define DRV_NAME ahci
#define DRV_VERSION2.2
+static int ahci_enable_alpm(struct ata_port *ap,
+ enum scsi_host_link_pm policy);
+static int ahci_disable_alpm(struct ata_port *ap);
enum {
AHCI_PCI_BAR= 5,
@@ -97,6 +100,7 @@ enum {
/* HOST_CAP bits */
HOST_CAP_SSC= (1 14), /* Slumber capable */
HOST_CAP_CLO= (1 24), /* Command List Override support */
+ HOST_CAP_ALPM = (1 26), /* Aggressive Link PM support */
HOST_CAP_SSS= (1 27), /* Staggered Spin-up */
HOST_CAP_NCQ= (1 30), /* Native Command Queueing */
HOST_CAP_64 = (1 31), /* PCI DAC (64-bit DMA) support */
@@ -151,6 +155,8 @@ enum {
PORT_IRQ_PIOS_FIS | PORT_IRQ_D2H_REG_FIS,
/* PORT_CMD bits */
+ 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_LIST_ON= (1 15), /* cmd list DMA engine running */
PORT_CMD_FIS_ON = (1 14), /* FIS DMA engine running */
@@ -171,6 +177,7 @@ enum {
AHCI_FLAG_HONOR_PI = (1 26), /* honor PORTS_IMPL */
AHCI_FLAG_IGN_SERR_INTERNAL = (1 27), /* ignore SERR_INTERNAL */
AHCI_FLAG_32BIT_ONLY= (1 28), /* force 32bit */
+ AHCI_FLAG_NO_HOTPLUG= (1 29), /* ignore PxSERR.DIAG.N */
AHCI_FLAG_COMMON= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
ATA_FLAG_MMIO | ATA_FLAG_PIO_DMA |
@@ -253,6 +260,7 @@ static struct scsi_host_template ahci_sh
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ .set_link_pm_policy = ata_scsi_set_link_pm_policy,
};
static const struct ata_port_operations ahci_ops = {
@@ -284,6 +292,7 @@ static const struct ata_port_operations
.port_suspend = ahci_port_suspend,
.port_resume= ahci_port_resume,
#endif
+ .enable_pm = ahci_enable_alpm,
.port_start = ahci_port_start,
.port_stop = ahci_port_stop,
@@ -695,6 +704,152 @@ static void ahci_power_up(struct ata_por
writel(cmd | PORT_CMD_ICC_ACTIVE, port_mmio + PORT_CMD);
}
+static int ahci_disable_alpm(struct ata_port *ap)
+{
+ void __iomem *port_mmio = ahci_port_base(ap);
+ u32 cmd, scontrol;
+ struct ahci_port_priv *pp = ap-private_data;
+
+ /*
+* disable Interface Power Management State Transitions
+* This is accomplished by setting bits 8:11 of the
+* SATA Control register
+*/
+ scontrol = readl(port_mmio + PORT_SCR_CTL);
+ scontrol |= (0x3 8);
+ writel(scontrol, port_mmio + PORT_SCR_CTL);
+
+ /* get the existing command bits */
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* disable ALPM and ASP */
+ cmd = ~PORT_CMD_ASP;
+ cmd = ~PORT_CMD_ALPE;
+
+ /* force the interface back to active */
+ cmd |= PORT_CMD_ICC_ACTIVE;
+
+ /* write out new cmd value */
+ writel(cmd, port_mmio + PORT_CMD);
+ cmd = readl(port_mmio + PORT_CMD);
+
+ /* wait 10ms to be sure we've come out of any low power state */
+ msleep(10);
+
+ /* clear out any PhyRdy stuff from interrupt status */
+ writel(PORT_IRQ_PHYRDY, port_mmio + PORT_IRQ_STAT);
+
+ /* go ahead and clean out PhyRdy Change from Serror too */
+ ahci_scr_write(ap, SCR_ERROR, (1 16));
+
+ /*
+* Clear flag
Re: [PATCH] AHCI powersaving and port-stopping (2.6.22-rc4)
On Mon, 11 Jun 2007 07:05:38 -0700 Arjan van de Ven [EMAIL PROTECTED] wrote: This is very different from the patch I posted a while ago turning on a few bits in the CMD register (ALPE and ASP) and which Intel is we've not seen a patch that actually works in this area unfortunately. We know Kristen's patch does work apparently now trying. That only saves around 250mW. Tejun's patch .. and saves close to a watt on a laptop in our measurements the patch is available on http://www.kernel.org/pub/linux/kernel/people/kristen/patches/SATA/alpm/ maybe worth a try as well.. - I've updated the hardware based patches and posted to the mailing list - they do indeed save anywhere from .6-1.5 watts depending on the system, on my X60 they save about a watt. I don't think that a hardware based solution is irrelevant at all - it will usually be able to make faster and more accurrate decisions about when to place the link into lower power state than software could. Note that the previous implementation that was posted didn't work for me, so I just redid everything. http://marc.info/?l=linux-kernelm=118158780117084w=2 Kristen - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/3] Store interrupt value
Kristen Carlson Accardi wrote: Use a stored value for which interrupts to enable. Changing this allows us to selectively turn off certain interrupts later and have them stay off. Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED] Seems OK, though a bit disappointing that this cannot be initial set in ahci_save_initial_config() [which admittedly only saves per-HBA settings at the moment, but due to new init model, need not be limited as such] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
Kristen Carlson Accardi wrote: This patch will set the correct bits to turn on Aggressive Link Power Management (ALPM) for the ahci driver. This will cause the controller and disk to negotiate a lower power state for the link when there is no activity (see the AHCI 1.x spec for details). This feature is mutually exclusive with Hot Plug, so when ALPM is enabled, Hot Plug is disabled. ALPM will be enabled by default, but it is settable via the scsi host syfs interface. Possible settings for this feature are: Setting Effect -- min_power ALPM is enabled, and link set to enter lowest power state (SLUMBER) when idle Hot plug not allowed. max_performance ALPM is disabled, Hot Plug is allowed medium_powerALPM is enabled, and link set to enter second lowest power state (PARTIAL) when idle. Hot plug not allowed. Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED] seems OK at first glance, though I'll have questions about hardware behavior once I get off this day-long Intel conference call :) - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/7] libata: check for AN support
On Thu, 24 May 2007 23:15:56 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:
Kristen Carlson Accardi wrote:
Check to see if an ATAPI device supports Asynchronous Notification.
If so, enable it.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
---
Andrew, I cleaned up the function header to properly comply with kernel
doc requirements. Other than that, this patch is the same.
I would ask for a simple revision: update ata_dev_set_AN() such that it
takes a second argument 'enable'. This boolean indicates to the
function whether SETFEATURES_SATA_ENABLE or SETFEATURES_SATA_DISABLE
should be passed to the device.
Otherwise than that, it's ready to merge I would say.
Jeff - can you fold this into the original patch, or would you like me
to resubmit the whole thing?
Kristen
Modify ata_dev_set_AN to take a second argument 'enable'. This
boolean indicates to the function whether SETFEATURES_SATA_ENABLE
or SETFEATURES_SATA_DISABLE should be passed to the device.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/drivers/ata/libata-core.c
===
--- 2.6-git.orig/drivers/ata/libata-core.c
+++ 2.6-git/drivers/ata/libata-core.c
@@ -70,7 +70,7 @@ const unsigned long sata_deb_timing_long
static unsigned int ata_dev_init_params(struct ata_device *dev,
u16 heads, u16 sectors);
static unsigned int ata_dev_set_xfermode(struct ata_device *dev);
-static unsigned int ata_dev_set_AN(struct ata_device *dev);
+static unsigned int ata_dev_set_AN(struct ata_device *dev, u8 enable);
static void ata_dev_xfermask(struct ata_device *dev);
unsigned int ata_print_id = 1;
@@ -2010,7 +2010,7 @@ int ata_dev_configure(struct ata_device
if ((ap-flags ATA_FLAG_AN) ata_id_has_AN(id)) {
int err;
/* issue SET feature command to turn this on */
- err = ata_dev_set_AN(dev);
+ err = ata_dev_set_AN(dev, SETFEATURES_SATA_ENABLE);
if (err)
ata_dev_printk(dev, KERN_ERR,
unable to set AN, err %x\n,
@@ -3966,6 +3966,7 @@ static unsigned int ata_dev_set_xfermode
/**
* ata_dev_set_AN - Issue SET FEATURES - SATA FEATURES
* @dev: Device to which command will be sent
+ * @enable: Whether to enable or disable the feature
*
* Issue SET FEATURES - SATA FEATURES command to device @dev
* on port @ap with sector count set to indicate Asynchronous
@@ -3977,7 +3978,7 @@ static unsigned int ata_dev_set_xfermode
* RETURNS:
* 0 on success, AC_ERR_* mask otherwise.
*/
-static unsigned int ata_dev_set_AN(struct ata_device *dev)
+static unsigned int ata_dev_set_AN(struct ata_device *dev, u8 enable)
{
struct ata_taskfile tf;
unsigned int err_mask;
@@ -3987,7 +3988,7 @@ static unsigned int ata_dev_set_AN(struc
ata_tf_init(dev, tf);
tf.command = ATA_CMD_SET_FEATURES;
- tf.feature = SETFEATURES_SATA_ENABLE;
+ tf.feature = enable;
tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
tf.protocol = ATA_PROT_NODATA;
tf.nsect = SATA_AN;
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata and legacy ide pcmcia failure
Mark Lord wrote: Russell King wrote: Before you do, it might help to build the ide-disk module and insert that as well? ARrrggghh!! Of course, that would explain the utter lack of disk partition check messages, now wouldn't it! Thanks Russell ! Doh! yes that would obviously help. With this I can declare success!! I was able to read and write to the card without any problems, although I did not try to stress it. Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into slot 0 Jun 12 00:19:42 localhost kernel: cs: memory probe 0xe800-0xefff: excluding 0xe800-0xefff Jun 12 00:19:42 localhost kernel: cs: memory probe 0xc020-0xcfff: excluding 0xc020-0xc11f 0xc1a0-0xc21f 0xc2a0-0xc31f 0xc3a0-0xcc1f 0xcca0-0xcd1f 0xcda0-0xce1f 0xcea0-0xcf1f 0xcfa0-0xd01f Jun 12 00:19:42 localhost kernel: pcmcia: registering new device pcmcia0.0 Jun 12 00:19:42 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Jun 12 00:19:42 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Jun 12 00:19:45 localhost kernel: hda: Memory Card Adapter, CFA DISK drive Jun 12 00:19:45 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3 Jun 12 00:19:45 localhost kernel: ide-cs: hda: Vpp = 0.0 Jun 12 00:19:45 localhost udevd-event[20730]: udev_rules_apply_format: unknown format variable '$modalias' Jun 12 00:19:45 localhost kernel: hda: max request size: 128KiB Jun 12 00:19:45 localhost kernel: hda: 253696 sectors (129 MB) w/1KiB Cache, CHS=991/16/16 Jun 12 00:19:45 localhost kernel: hda: hda1 Jun 12 00:19:48 localhost hald: mounted /dev/hda1 on behalf of uid 0 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AHCI powersaving and port-stopping (2.6.22-rc4)
Well actually I did not worry about the warning, this particular part made me worry much more: Call Trace: [804a99ce] ata_eh_set_powersave+0x34e/0x370 [8048c7b0] scsi_error_handler+0x0/0x330 [804a9e27] ata_do_eh+0xb7/0x16f0 [80229f9d] find_busiest_group+0x1bd/0x800 [804aece0] ahci_postreset+0x0/0x80 [804ada70] ahci_hardreset+0x0/0xf0 [804aee20] ahci_softreset+0x0/0x270 [804a40f0] ata_std_prereset+0x0/0xf0 [8023b134] lock_timer_base+0x34/0x70 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c7b0] scsi_error_handler+0x0/0x330 [804abc27] ata_scsi_error+0x297/0x730 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c893] scsi_error_handler+0xe3/0x330 [80229507] __wake_up_common+0x47/0x80 [8048c7b0] scsi_error_handler+0x0/0x330 [8024675b] kthread+0x4b/0x80 [8020a9a8] child_rip+0xa/0x12 [80246710] kthread+0x0/0x80 [8020a99e] child_rip+0x0/0x12 Looks like the kernel complains about a bug or something at this point?! Because I am not a developer I can't tell for sure, but I don't think this is all good. It is printed to dmesg when booting and a second time when enabling the feature via sysfs. Peter John Fremlin wrote: Peter Ganzhorn [EMAIL PROTECTED] writes: I just wanted to have a look at the patch and see if it works for me - looks like somethings not all straight, I get this while booting: ahci :00:1f.2: version 2.2 ACPI: PCI Interrupt :00:1f.2[C] - GSI 19 (level, low) - IRQ 19 ahci :00:1f.2: nr_ports (3) and implemented port map (0x1) don't match ahci :00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x1 impl SATA mode ahci :00:1f.2: flags: 64bit ncq pm led clo pio slum part PCI: Setting latency timer of device :00:1f.2 to 64 scsi0 : ahci ata1: SATA max UDMA/133 cmd 0xc2048100 ctl 0x bmdma 0x irq 0 WARNING: at drivers/ata/libata-eh.c:1917 ata_eh_set_powersave() [...] I hope this output from dmesg helps to make the patch better - if I can do any further testing please let me know! That is fine. The warning is expected. There is nothing wrong with it. This patch will stop the ports when they are idle. To turn it on, echo 1 /sys/module/libata/parameters/powersave [...] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata and legacy ide pcmcia failure
Robert de Rooy wrote: (after applying the ide-polling experimental patch) With this I can declare success!! I was able to read and write to the card without any problems, although I did not try to stress it. Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into slot 0 Jun 12 00:19:42 localhost kernel: cs: memory probe 0xe800-0xefff: excluding 0xe800-0xefff Jun 12 00:19:42 localhost kernel: cs: memory probe 0xc020-0xcfff: excluding 0xc020-0xc11f 0xc1a0-0xc21f 0xc2a0-0xc31f 0xc3a0-0xcc1f 0xcca0-0xcd1f 0xcda0-0xce1f 0xcea0-0xcf1f 0xcfa0-0xd01f Jun 12 00:19:42 localhost kernel: pcmcia: registering new device pcmcia0.0 Jun 12 00:19:42 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Jun 12 00:19:42 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Jun 12 00:19:45 localhost kernel: hda: Memory Card Adapter, CFA DISK drive Jun 12 00:19:45 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3 Jun 12 00:19:45 localhost kernel: ide-cs: hda: Vpp = 0.0 Jun 12 00:19:45 localhost udevd-event[20730]: udev_rules_apply_format: unknown format variable '$modalias' Jun 12 00:19:45 localhost kernel: hda: max request size: 128KiB Jun 12 00:19:45 localhost kernel: hda: 253696 sectors (129 MB) w/1KiB Cache, CHS=991/16/16 Jun 12 00:19:45 localhost kernel: hda: hda1 Jun 12 00:19:48 localhost hald: mounted /dev/hda1 on behalf of uid 0 Okay, Tejun / Bart / Alan: This proves that the device does work correctly in most respects except for interrupt delivery. The status bits are working and it can be probed for, configured, and used. So, next step might be to try and understand the interrupt mis-delivery problem some more. I've lost the history of the original issue, but we now know that everything except the actual interrupt seems good. Cheers -- Mark Lord Real-Time Remedies Inc. [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AHCI powersaving and port-stopping (2.6.22-rc4)
Peter Ganzhorn [EMAIL PROTECTED] writes: Well actually I did not worry about the warning, this particular part made me worry much more: This comes with the warning. The warning prints this stack trace. Call Trace: [804a99ce] ata_eh_set_powersave+0x34e/0x370 [8048c7b0] scsi_error_handler+0x0/0x330 [804a9e27] ata_do_eh+0xb7/0x16f0 [80229f9d] find_busiest_group+0x1bd/0x800 [804aece0] ahci_postreset+0x0/0x80 [804ada70] ahci_hardreset+0x0/0xf0 [804aee20] ahci_softreset+0x0/0x270 [804a40f0] ata_std_prereset+0x0/0xf0 [8023b134] lock_timer_base+0x34/0x70 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c7b0] scsi_error_handler+0x0/0x330 [804abc27] ata_scsi_error+0x297/0x730 [8048c7b0] scsi_error_handler+0x0/0x330 [8048c893] scsi_error_handler+0xe3/0x330 [80229507] __wake_up_common+0x47/0x80 [8048c7b0] scsi_error_handler+0x0/0x330 [8024675b] kthread+0x4b/0x80 [8020a9a8] child_rip+0xa/0x12 [80246710] kthread+0x0/0x80 [8020a99e] child_rip+0x0/0x12 Looks like the kernel complains about a bug or something at this point?! Because I am not a developer I can't tell for sure, but I don't think this is all good. It is printed to dmesg when booting and a second time when enabling the feature via sysfs. Peter John Fremlin wrote: Peter Ganzhorn [EMAIL PROTECTED] writes: I just wanted to have a look at the patch and see if it works for me - looks like somethings not all straight, I get this while booting: ahci :00:1f.2: version 2.2 ACPI: PCI Interrupt :00:1f.2[C] - GSI 19 (level, low) - IRQ 19 ahci :00:1f.2: nr_ports (3) and implemented port map (0x1) don't match ahci :00:1f.2: AHCI 0001.0100 32 slots 3 ports 3 Gbps 0x1 impl SATA mode ahci :00:1f.2: flags: 64bit ncq pm led clo pio slum part PCI: Setting latency timer of device :00:1f.2 to 64 scsi0 : ahci ata1: SATA max UDMA/133 cmd 0xc2048100 ctl 0x bmdma 0x irq 0 WARNING: at drivers/ata/libata-eh.c:1917 ata_eh_set_powersave() [...] I hope this output from dmesg helps to make the patch better - if I can do any further testing please let me know! That is fine. The warning is expected. There is nothing wrong with it. This patch will stop the ports when they are idle. To turn it on, echo 1 /sys/module/libata/parameters/powersave [...] - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AHCI aggressive powersaving
Kristen Carlson Accardi [EMAIL PROTECTED] writes: [...] I've updated the hardware based patches and posted to the mailing list - they do indeed save anywhere from .6-1.5 watts depending on the system, on my X60 they save about a watt. I don't think that a hardware based solution is irrelevant at all - it will usually be able to make faster and more accurrate decisions about when to place the link into lower power state than software could. Fair enough. But could I point out that the patch I posted from Tejun Heo actually does stop the port, not just putting it into low power slumber modes. So, I think it might be able to save more power. Please take a look at it. It is quite sophisticated and could be generalised to more chipsets. Perhaps, on AHCI it can be used in combination with the aggressive link power management. Note that the previous implementation that was posted didn't work for me, so I just redid everything. Was that my implementation? I posted it in November last year. It certainly isn't as good as yours http://marc.info/?l=linux-kernelm=116343039621877w=2 As you can see, I too thought it saved about 1 W, but Pavel Machek measured 250mW. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
On Mon, 11 Jun 2007, Kristen Carlson Accardi wrote: Setting Effect -- min_power ALPM is enabled, and link set to enter lowest power state (SLUMBER) when idle Hot plug not allowed. max_performance ALPM is disabled, Hot Plug is allowed medium_power ALPM is enabled, and link set to enter second lowest power state (PARTIAL) when idle. Hot plug not allowed. Just some food for thought: If you split it into a enable/disable (0/1) attribute, and a level attribute (some sort of integer scale, or min, medium, max if you must use strings. You could use four levels to mimic the PCI device power state, for example), it might make its usage more generic, and easier from userspace, as it decouples the need to turn it on/off from the need to know which level the user wants it set to when you turn it on. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
Henrique de Moraes Holschuh wrote: On Mon, 11 Jun 2007, Kristen Carlson Accardi wrote: Setting Effect -- min_power ALPM is enabled, and link set to enter lowest power state (SLUMBER) when idle Hot plug not allowed. max_performance ALPM is disabled, Hot Plug is allowed medium_powerALPM is enabled, and link set to enter second lowest power state (PARTIAL) when idle. Hot plug not allowed. Just some food for thought: If you split it into a enable/disable (0/1) attribute, and a level attribute on/off doesn't really make sense if the question is do you favor power or do you favor performance... - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Kristen Carlson Accardi wrote: Hi, This series of patches enables Aggressive Link Power Management for AHCI devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this saves me a full watt of power. On other systems, reported power savings range from .5-1.5 Watts. It has been tested by the kind folks at #powertop with similar results. Please give it a try and let me know what you think. I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, they need to be turned off completely I don't think scsi sysfs is the right place to export this interface. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Tejun Heo wrote: Kristen Carlson Accardi wrote: Hi, This series of patches enables Aggressive Link Power Management for AHCI devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this saves me a full watt of power. On other systems, reported power savings range from .5-1.5 Watts. It has been tested by the kind folks at #powertop with similar results. Please give it a try and let me know what you think. I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, they need to be turned off A better PM framework would definitely be nice :) completely I don't think scsi sysfs is the right place to export this interface. That's about the only place we have right now. Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Tejun Heo wrote: Kristen Carlson Accardi wrote: Hi, This series of patches enables Aggressive Link Power Management for AHCI devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this saves me a full watt of power. On other systems, reported power savings range from .5-1.5 Watts. It has been tested by the kind folks at #powertop with similar results. Please give it a try and let me know what you think. I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, do you have data to support this? The data we have from this patch is that it saves typically a Watt of power (depends on the machine of course, but the range is 0.5W to 1.5W). If you want to also have an even more agressive thing where you want to start disabling the entire controller... I don't see how this is in conflict with saving power on the link level by just enabling a hardware feature - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
Arjan van de Ven [EMAIL PROTECTED] writes: Henrique de Moraes Holschuh wrote: On Mon, 11 Jun 2007, Kristen Carlson Accardi wrote: Setting Effect -- min_power ALPM is enabled, and link set to enter lowest power state (SLUMBER) when idle Hot plug not allowed. max_performance ALPM is disabled, Hot Plug is allowed medium_powerALPM is enabled, and link set to enter second lowest power state (PARTIAL) when idle. Hot plug not allowed. Just some food for thought: If you split it into a enable/disable (0/1) attribute, and a level attribute on/off doesn't really make sense if the question is do you favor power or do you favor performance... How about just making it a numeric scale with 0 meaning no power saving and then some fixed number of levels (e.g 0-9)? -- ilmari A disappointingly low fraction of the human race is, at any given time, on fire. - Stig Sandbeck Mathisen - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Arjan van de Ven wrote: Tejun Heo wrote: Kristen Carlson Accardi wrote: Hi, This series of patches enables Aggressive Link Power Management for AHCI devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this saves me a full watt of power. On other systems, reported power savings range from .5-1.5 Watts. It has been tested by the kind folks at #powertop with similar results. Please give it a try and let me know what you think. I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, do you have data to support this? The data we have from this patch is that it saves typically a Watt of power (depends on the machine of course, but the range is 0.5W to 1.5W). If you want to also have an even more agressive thing where you want to start disabling the entire controller... I don't see how this is in conflict with saving power on the link level by just enabling a hardware feature SATA standard defines lower power phy states. So the same argument you're using for AHCI applies there too -- just enabling an existing hardware feature. Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Jeff Garzik wrote: Arjan van de Ven wrote: Tejun Heo wrote: Kristen Carlson Accardi wrote: Hi, This series of patches enables Aggressive Link Power Management for AHCI devices, as documented in the AHCI spec. On my laptop (a Lenovo X60), this saves me a full watt of power. On other systems, reported power savings range from .5-1.5 Watts. It has been tested by the kind folks at #powertop with similar results. Please give it a try and let me know what you think. I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, do you have data to support this? The data we have from this patch is that it saves typically a Watt of power (depends on the machine of course, but the range is 0.5W to 1.5W). If you want to also have an even more agressive thing where you want to start disabling the entire controller... I don't see how this is in conflict with saving power on the link level by just enabling a hardware feature SATA standard defines lower power phy states. So the same argument you're using for AHCI applies there too -- just enabling an existing hardware feature. yes I'm not arguing against that. I was trying to find out (and suggest-unless-proven-otherwise) that the 2 are not exclusive or conflicting... in fact I assume both are wanted concurrently. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Arjan van de Ven wrote: Jeff Garzik wrote: SATA standard defines lower power phy states. So the same argument you're using for AHCI applies there too -- just enabling an existing hardware feature. yes I'm not arguing against that. I was trying to find out (and suggest-unless-proven-otherwise) that the 2 are not exclusive or conflicting... in fact I assume both are wanted concurrently. Yes and no. As I understand it, AHCI's capability is an automatic version of what standard SATA phys provide manually. In AHCI's case, the hardware automatically manages the link power, possibly cycling it hundreds of times per second. In the standard case, software must determine when a different power state is appropriate based on current conditions, and update the phy appropriately. Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata and legacy ide pcmcia failure
Mark Lord wrote: Robert de Rooy wrote: (after applying the ide-polling experimental patch) With this I can declare success!! I was able to read and write to the card without any problems, although I did not try to stress it. Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into slot 0 Jun 12 00:19:42 localhost kernel: cs: memory probe 0xe800-0xefff: excluding 0xe800-0xefff Jun 12 00:19:42 localhost kernel: cs: memory probe 0xc020-0xcfff: excluding 0xc020-0xc11f 0xc1a0-0xc21f 0xc2a0-0xc31f 0xc3a0-0xcc1f 0xcca0-0xcd1f 0xcda0-0xce1f 0xcea0-0xcf1f 0xcfa0-0xd01f Jun 12 00:19:42 localhost kernel: pcmcia: registering new device pcmcia0.0 Jun 12 00:19:42 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Jun 12 00:19:42 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Jun 12 00:19:45 localhost kernel: hda: Memory Card Adapter, CFA DISK drive Jun 12 00:19:45 localhost kernel: ide0 at 0x4100-0x4107,0x410e on irq 3 Jun 12 00:19:45 localhost kernel: ide-cs: hda: Vpp = 0.0 Jun 12 00:19:45 localhost udevd-event[20730]: udev_rules_apply_format: unknown format variable '$modalias' Jun 12 00:19:45 localhost kernel: hda: max request size: 128KiB Jun 12 00:19:45 localhost kernel: hda: 253696 sectors (129 MB) w/1KiB Cache, CHS=991/16/16 Jun 12 00:19:45 localhost kernel: hda: hda1 Jun 12 00:19:48 localhost hald: mounted /dev/hda1 on behalf of uid 0 Okay, Tejun / Bart / Alan: This proves that the device does work correctly in most respects except for interrupt delivery. The status bits are working and it can be probed for, configured, and used. libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't cover nodata commands tho). -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] Enable Aggressive Link Power management for AHCI controllers.
On Mon, 11 Jun 2007, Jeff Garzik wrote: on/off doesn't really make sense if the question is do you favor power or do you favor performance... Actually, it does if you think of it as do you need hotplug right now or not?. How about just making it a numeric scale with 0 meaning no power saving and then some fixed number of levels (e.g 0-9)? The original proposal seems far more intuitive than these alternatives. There is nothing intuitive about the text or the levels. All cases need proper documentation. I'd never expect link powersaving to kill hotplug, unless I read the AHCI docs. And enable/disable ain't intuitive either :( But enable/disable is useful to get stuff like SATA bay hotplug, dock/undock and other stuff that needs hotplug to be working right, unless we can make that automatic so that power saving is always disabled in all situations we'd need hotplug to be working? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Arjan van de Ven wrote: I'm not sure about this. We need better PM framework to support powersaving in other controllers and some ahcis don't save much when only link power management is used, do you have data to support this? Yeah, it was some Lenovo notebook. Pavel is more familiar with the hardware. Pavel, what was the notebook which didn't save much power with standard SATA power save but needed port to be completely turned off? The data we have from this patch is that it saves typically a Watt of power (depends on the machine of course, but the range is 0.5W to 1.5W). If you want to also have an even more agressive thing where you want to start disabling the entire controller... I don't see how this is in conflict with saving power on the link level by just enabling a hardware feature Well, both implement about the same thing. I prefer software implementation because it's more generic and ALPE/ASP seems too aggressive to me. Here are reasons why sw implementation wasn't merged. 1. It didn't have proper interface with userland. This was mainly because of missing ATA sysfs nodes. I'm not sure whether adding this to scsi node is a good idea. 2. It was focused on SATA link PS and couldn't cover the Lenovo case. I think we need something at the block layer. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
Arjan van de Ven wrote: The data we have from this patch is that it saves typically a Watt of power (depends on the machine of course, but the range is 0.5W to 1.5W). If you want to also have an even more agressive thing where you want to start disabling the entire controller... I don't see how this is in conflict with saving power on the link level by just enabling a hardware feature Well, both implement about the same thing. I prefer software implementation because it's more generic and ALPE/ASP seems too aggressive to me. Too aggressive in what way? There are devices which lock up hard if PHY enters PS mode (only physical power removal can reset it) and I wouldn't be surprised if some devices aren't happy with PS being too aggressive. Well, I actually expect to see such devices. It's ATA after all. This is unknown territory and that's why I was using 'seems ... to me'. There are tradeoffs on either side. Doing things in software is more work for the cpu, and depending on the implementation, will consume more power on the CPU side. (for example if you need regular timers that just consumes the power you are saving back up). The hardware can obviously switch very fast (because it's independent of any software), yet of course the software has higher level knowledge about how idle the link really is (like it knows if any files are open etc etc). To be honest, I would be surprised if software could do significantly better than hardware though; it seems a simple problem: Idle - go to low power, and estimating idle isn't all that hard on a link level... there's not all THAT much the kernel can estimate better I suspect. I don't think the end result will vary in any significant way. My biggest argument for sw implementation is it can be used for other controllers. This debate is very similar to the cpufreq debate from 4 years ago, where there were 3 levels: do it in the CPU, do it in the kernel or do it in userspace. All three are valid; whichever is best depends on the exact hardware that you have... (and you can argue that first everyone started in userspace, then the hardware improved that made a kernelspace implementation better (ondemand) and now Turbo Mode is more or less moving this to the hardware... I wouldn't be surprised if the sata side will show a similar trend) Currently, ahci is the only one which has controller-side automatic PS but some ATA devices (hdds) implement device initiated PS (DIPS). The sw implementation supports SW HIPS and DIPS. We can add HW HIPS support and hook ALPE/ASP support there but I don't think it would have benefits over SW implementation. I think it's a bit different from cpufreq. ATA is cheaper and more broken and much more diverse. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/3] AHCI Link Power Management
We will do AHCI link PM -- presuming that I can be convinced that it does not repeatedly park the hard drive heads, or something similarly annoying on PATA-SATA bridges and similar setups. IF it works as advertised -- a big if considering all the AHCI silicon implementations out there -- we definitely want to use it. Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
