[PATCH]is_power_of_2-scsi/NCR53C9x.c
Replacing (n & (n-1)) in the context of power of 2 checks with is_power_of_2 Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/NCR53C9x.c b/drivers/scsi/NCR53C9x.c index 8b5334c..2868b1a 100644 --- a/drivers/scsi/NCR53C9x.c +++ b/drivers/scsi/NCR53C9x.c @@ -33,6 +33,7 @@ #include #include #include +#include #include "scsi.h" #include @@ -1651,7 +1652,7 @@ static inline int reconnect_target(struct NCR_ESP *esp, struct ESP_regs *eregs) if(!(it & me)) return -1; it &= ~me; - if(it & (it - 1)) + if(!is_power_of_2(it)) return -1; while(!(it & 1)) targ++, it >>= 1; -- Vignesh Babu BM _ "Why is it that every time I'm with you, makes me believe in magic?" - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]is_power_of_2-scsi/esp_scsi.c
Replacing (n & (n-1)) in the context of power of 2 checks with is_power_of_2 Signed-off-by: vignesh babu <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c index ec71061..c416154 100644 --- a/drivers/scsi/esp_scsi.c +++ b/drivers/scsi/esp_scsi.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include @@ -1130,7 +1131,7 @@ static int esp_reconnect(struct esp *esp) if (!(bits & esp->scsi_id_mask)) goto do_reset; bits &= ~esp->scsi_id_mask; - if (!bits || (bits & (bits - 1))) + if (!is_power_of_2(bits)) goto do_reset; target = ffs(bits) - 1; -- Vignesh Babu BM _ "Why is it that every time I'm with you, makes me believe in magic?" - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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-scsi" 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: 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? Pavel, if you have time, could you measure this with Kristen's patch? 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 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. 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) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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, 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?". that's a temporary shortcoming; even with these power savings you can do hotplug as long as you're willing to poll for it at a reasonable interval and are willing to wait the time between polls for a hotplug to take effect.. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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-scsi" 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-scsi" 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-scsi" 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-scsi" 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-scsi" 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-scsi" 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.
Dagfinn Ilmari Mannsåker wrote: 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)? The original proposal seems far more intuitive than these alternatives. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" 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-scsi" 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-scsi" 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-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] aacraid: probe related code cleanup
Sundry cleanups: 1) Use kzalloc instead of kmalloc. 2) Make sure probe worked before recalling the SCSI command to finalize processing. 3) _aac_probe_container2 and _aac_probe_container1 return value goes unused, change return to void. 4) Use a lower depth pointer reference to pick up the driver instance variable. 5) Although effectively unused except to fake for scsicmd validity, set the scsi_done in probe code to aac_probe_container_callback1 instead of the less valid dummy reference to _aac_probe_container1. 6) SCp.phase is set in aac_valid_context, drop setting up this value in caller when unnecessary. 7) take container target id at the beginning, rather than referencing scmd_id() to pick it up. There should be no side effects or functionality changes. This attached patch is against current scsi-misc-2.6, scsi-rc-fixes-2.6 & scsi-pending-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]> drivers/scsi/aacraid/aachba.c | 64 ++- 1 file changed, 31 insertions(+), 33 deletions(-) aacraid_probe_cleanup.patch Description: aacraid_probe_cleanup.patch
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-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2/3] Expose Power Management Policy option to users
Kristen Carlson Accardi wrote: 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]> seems OK at first glance, though I request that ata and scsi portions be split into separate patches - To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi disk help file is not complete
On Mon, 11 Jun 2007 20:28:16 +0200 api wrote: > Good day, > When doing make menuconfig one comes across CONFIG_BLK_DEV_SD. > The help file states that this is for scsi disks.NO MENTION IS MADE THAT > IT IS NEEDE FOR SATA DISKS AS WELL! > Would have saved me a lot of time if the help was up to date. > I hope this can be changed so others can make a kernel for sata systems > quicker. From: Randy Dunlap <[EMAIL PROTECTED]> Add help info for BLK_DEV_SD referring to its use in SATA or PATA driver configurations. Add help text for "ATA" indicating that it probably needs some SCSI config symbols enabled in order to be useful. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/ata/Kconfig |5 + drivers/scsi/Kconfig |1 + 2 files changed, 6 insertions(+) --- linux-2622-rc4.orig/drivers/scsi/Kconfig +++ linux-2622-rc4/drivers/scsi/Kconfig @@ -60,6 +60,7 @@ config BLK_DEV_SD depends on SCSI ---help--- If you want to use SCSI hard disks, Fibre Channel disks, + Serial ATA (SATA) or Parallel ATA (PATA) hard disks, USB storage or the SCSI or parallel port version of the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO, the Disk-HOWTO and the Multi-Disk-HOWTO, available from --- linux-2622-rc4.orig/drivers/ata/Kconfig +++ linux-2622-rc4/drivers/ata/Kconfig @@ -17,6 +17,11 @@ menuconfig ATA that "speaks" the ATA protocol, also called ATA controller), because you will be asked for it. + NOTE: ATA enables basic SCSI support; *however*, + 'SCSI disk support', 'SCSI tape support', or + 'SCSI CDROM support' may also be needed, + depending on your hardware configuration. + if ATA config ATA_NONSTANDARD - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[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_VERSION"2.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 <<
[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_perfo
[patch 1/3] Store interrupt value
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]>
Index: 2.6-git/drivers/ata/ahci.c
===
--- 2.6-git.orig/drivers/ata/ahci.c
+++ 2.6-git/drivers/ata/ahci.c
@@ -211,6 +211,7 @@ struct ahci_port_priv {
unsigned intncq_saw_d2h:1;
unsigned intncq_saw_dmas:1;
unsigned intncq_saw_sdb:1;
+ u32 intr_mask; /* interrupts to enable */
};
static u32 ahci_scr_read (struct ata_port *ap, unsigned int sc_reg);
@@ -1384,6 +1385,7 @@ static void ahci_thaw(struct ata_port *a
void __iomem *mmio = ap->host->iomap[AHCI_PCI_BAR];
void __iomem *port_mmio = ahci_port_base(ap);
u32 tmp;
+ struct ahci_port_priv *pp = ap->private_data;
/* clear IRQ */
tmp = readl(port_mmio + PORT_IRQ_STAT);
@@ -1391,7 +1393,7 @@ static void ahci_thaw(struct ata_port *a
writel(1 << ap->port_no, mmio + HOST_IRQ_STAT);
/* turn IRQ back on */
- writel(DEF_PORT_IRQ, port_mmio + PORT_IRQ_MASK);
+ writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
}
static void ahci_error_handler(struct ata_port *ap)
@@ -1547,6 +1549,12 @@ static int ahci_port_start(struct ata_po
pp->cmd_tbl = mem;
pp->cmd_tbl_dma = mem_dma;
+ /*
+* Save off initial list of interrupts to be enabled.
+* This could be changed later
+*/
+ pp->intr_mask = DEF_PORT_IRQ;
+
ap->private_data = pp;
/* power up port */
--
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi_debug: correct parameter default text
Randy Dunlap wrote: > From: Randy Dunlap <[EMAIL PROTECTED]> > > Correct the module info text for the default value of > "every_nth" to 0. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Signed-off-by: Douglas Gilbert <[EMAIL PROTECTED]> Doug Gilbert > --- > drivers/scsi/scsi_debug.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-2622-rc4.orig/drivers/scsi/scsi_debug.c > +++ linux-2622-rc4/drivers/scsi/scsi_debug.c > @@ -2405,7 +2405,7 @@ MODULE_PARM_DESC(add_host, "0..127 hosts > MODULE_PARM_DESC(delay, "# of jiffies to delay response(def=1)"); > MODULE_PARM_DESC(dev_size_mb, "size in MB of ram shared by devs(def=8)"); > MODULE_PARM_DESC(dsense, "use descriptor sense format(def=0 -> fixed)"); > -MODULE_PARM_DESC(every_nth, "timeout every nth command(def=100)"); > +MODULE_PARM_DESC(every_nth, "timeout every nth command(def=0)"); > MODULE_PARM_DESC(fake_rw, "fake reads/writes instead of copying (def=0)"); > MODULE_PARM_DESC(max_luns, "number of LUNs per target to simulate(def=1)"); > MODULE_PARM_DESC(no_lun_0, "no LU number 0 (def=0 -> have lun 0)"); > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi_debug: correct parameter default text
From: Randy Dunlap <[EMAIL PROTECTED]> Correct the module info text for the default value of "every_nth" to 0. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/scsi/scsi_debug.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2622-rc4.orig/drivers/scsi/scsi_debug.c +++ linux-2622-rc4/drivers/scsi/scsi_debug.c @@ -2405,7 +2405,7 @@ MODULE_PARM_DESC(add_host, "0..127 hosts MODULE_PARM_DESC(delay, "# of jiffies to delay response(def=1)"); MODULE_PARM_DESC(dev_size_mb, "size in MB of ram shared by devs(def=8)"); MODULE_PARM_DESC(dsense, "use descriptor sense format(def=0 -> fixed)"); -MODULE_PARM_DESC(every_nth, "timeout every nth command(def=100)"); +MODULE_PARM_DESC(every_nth, "timeout every nth command(def=0)"); MODULE_PARM_DESC(fake_rw, "fake reads/writes instead of copying (def=0)"); MODULE_PARM_DESC(max_luns, "number of LUNs per target to simulate(def=1)"); MODULE_PARM_DESC(no_lun_0, "no LU number 0 (def=0 -> have lun 0)"); - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi_debug fault-injection question
Randy Dunlap wrote: > Hi Doug, > > scsi_debug.c says: > > MODULE_PARM_DESC(every_nth, "timeout every nth command(def=100)"); > > I don't see where the default of 100 is set. > > #define DEF_EVERY_NTH 0 > ... > static int scsi_debug_every_nth = DEF_EVERY_NTH; > > > Can you clarify for me, please? Randy, s/100/0/ The string in MODULE_PARM_DESC is wrong. The support web page, http://www.torque.net/sg/sdebug26.html is accurate stating the default is 0 and notes: "for error injection: 0 -> off". Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Question: vport_disable attribute under /sys/class/fc_vport
Hello James, I've got a question on NPIV framwork that is included in FC transport layer. I'm using 2.6.22-rc3 with your NPIV-based vport patchset. If I understood correctly, vport_disable and vport_delete attributes have to be listed under /sys/class/fc_vport/vport-2:0-2/, once the 'vport-2:0-2' created successfully. To make this happen, fc_function_template for the vport has modified to add wrapper function for vport_disable and vport_delete in the driver. However, in my result, I am only able to see vport_delete. For some reason, vport_disable is not listed under the directory. Can you please comment what possible reasons are there for this? Thank you, Seokmann - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
scsi_debug fault-injection question
Hi Doug, scsi_debug.c says: MODULE_PARM_DESC(every_nth, "timeout every nth command(def=100)"); I don't see where the default of 100 is set. #define DEF_EVERY_NTH 0 ... static int scsi_debug_every_nth = DEF_EVERY_NTH; Can you clarify for me, please? Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
