Re: [PATCH] sr: Avoid that opening a CD-ROM hangs with runtime power management enabled

This patch avoids that complaints similar to the following appear in > the kernel log if runtime power management is enabled: Applied to 4.18/scsi-fixes, thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] sr: Avoid that opening a CD-ROM hangs with runtime power management enabled

On Fri, Aug 03, 2018 at 10:28:45AM +0200, Johannes Thumshirn wrote: > On Thu, Aug 02, 2018 at 10:44:42AM -0700, Bart Van Assche wrote: > > Surround scsi_execute() calls with scsi_autopm_get_device() and > > scsi_autopm_put_device(). Note: removing sr_mutex protection from > > the scsi_cd_get() and

[PATCH] sr: Avoid that opening a CD-ROM hangs with runtime power management enabled

to the following appear in the kernel log if runtime power management is enabled: INFO: task systemd-udevd:650 blocked for more than 120 seconds. Not tainted 4.18.0-rc7-dbg+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. systemd-udevd D28176 650513 0x

[PATCH v1 4/9] scsi: ufs: add option to change default UFS power management level

rate clock source. +- rpm-level: UFS Runtime power management level. Following PM levels are supported: + 0 - Both UFS device and Link in active state (Highest power consumption) + 1 - UFS device in active state but Link in Hibe

[PATCH v3 07/12] scsi: ufs: set default UFS power management level

UFS device and link can be put in multiple different low power modes hence UFS driver supports multiple different low power modes. This change sets the default UFS power management level which should put the link hibernate state and device in sleep state. This default power management level gives

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

OFF state (Lowest power consumption) +- spm-level : UFS System power management level. Allowed PM levels are same as rpm-level. This looks like you are putting policy for Linux into DT. What I would expect to see here is disabling of states that don't work due to some h/w lim

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

operties: >>> -lanes-per-direction : number of lanes available per direction - >>> either 1 or 2. >>> Note that it is assume same number of lanes is >>> used both >>> directions at once. If not spe

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

assume same number of lanes is used both directions at once. If not specified, default is 2 lanes per direction. +- rpm-level : UFS Runtime power management level. Following PM levels are supported: + 0 - Both UFS device and Link in active state (Highest power consumption) +

Re: [PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

per direction - either 1 or > 2. > Note that it is assume same number of lanes is used > both > directions at once. If not specified, default is 2 > lanes per direction. > +- rpm-level : UFS Runtime power management leve

[PATCH v2 07/12] scsi: ufs: add option to change default UFS power management level

2 lanes per direction. +- rpm-level: UFS Runtime power management level. Following PM levels are supported: + 0 - Both UFS device and Link in active state (Highest power consumption) + 1 - UFS device in active state but Link in Hi

[PATCH v1 07/12] scsi: ufs: add option to change default UFS power management level

2 lanes per direction. +- rpm-level: UFS Runtime power management level. Following PM levels are supported: + 0 - Both UFS device and Link in active state (Highest power consumption) + 1 - UFS device in active state but Link in Hi

Re: [PATCH v2 02/17] scsi: ufs: add option to change default UFS power management level

in the array is "0" then it is > assumed > that the frequency is set by the parent clock or a > fixed rate clock source. > +- rpm-level : UFS Runtime power management level. Following PM > leve

Re: [PATCH v1 02/17] scsi: ufs: add option to change default UFS power management level

> 2015-09-13 23:52 GMT+09:00 Yaniv Gardi : >> UFS device and link can be put in multiple different low power modes >> hence UFS driver supports multiple different low power modes. >> By default UFS driver selects the default (optimal) low power mode >> (which gives moderate

[PATCH v2 02/17] scsi: ufs: add option to change default UFS power management level

: UFS Runtime power management level. Following PM levels are supported: + 0 - Both UFS device and Link in active state (Highest power consumption) + 1 - UFS device in active state but Link in Hibern8 state + 2 - UFS

Re: [PATCH v1 02/17] scsi: ufs: add option to change default UFS power management level

2015-09-13 23:52 GMT+09:00 Yaniv Gardi : > UFS device and link can be put in multiple different low power modes > hence UFS driver supports multiple different low power modes. > By default UFS driver selects the default (optimal) low power mode > (which gives moderate power

[PATCH v1 02/17] scsi: ufs: add option to change default UFS power management level

et by the parent clock or a fixed rate clock source. +- rpm-level : UFS Runtime power management level. Following PM levels are supported: + 0 - Both UFS device and Link in active state (Highest power consumption) + 1 - UFS device in active sta

[PATCH V7 2/9] [SCSI] aacraid: Add Power Management support

Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from V2: Increased msleep(1) to msleep(20) Reverted pci_enable_msix_exact() to

RE: [PATCH V6 02/10] [SCSI] aacraid: Add Power Management support

Rajashekhara Subject: [PATCH V6 02/10] [SCSI] aacraid: Add Power Management support Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from

RE: [PATCH V6 02/10] [SCSI] aacraid: Add Power Management support

Subject: RE: [PATCH V6 02/10] [SCSI] aacraid: Add Power Management support Reviewed-by: Karthikeya Sunkesula karthikeya.sunkes...@pmcs.com -Original Message- From: Mahesh Rajashekhara Sent: Tuesday, August 11, 2015 11:28 AM To: Tomas Henzl; jbottom...@parallels.com; linux-scsi

Re: [PATCH V6 02/10] [SCSI] aacraid: Add Power Management support

On 11.8.2015 07:58, Mahesh Rajashekhara wrote: Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from V2: Increased msleep(1)

[PATCH V6 02/10] [SCSI] aacraid: Add Power Management support

Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from V2: Increased msleep(1) to msleep(20) Reverted pci_enable_msix_exact() to

[PATCH V5 02/11] [SCSI] aacraid: Add Power Management support

From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from V2:

[PATCH V4 02/10] [SCSI] aacraid: Add Power Management support

From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from V2:

[PATCH V3 02/10] [SCSI] aacraid: Add Power Management support

From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Changes from V2:

Re: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support

On 06/11/2015 03:42 AM, rajinikanth.panduran...@pmcs.com wrote: From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown *

RE: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support

; Mahesh Rajashekhara; Rich Bono; Achim Leubner; Murthy Bhat Subject: Re: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support On 06/11/2015 03:42 AM, rajinikanth.panduran...@pmcs.com wrote: From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend

Re: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support

; linux-scsi@vger.kernel.org Cc: aacr...@pmc-sierra.com; Harry Yang; Mahesh Rajashekhara; Rich Bono; Achim Leubner; Murthy Bhat Subject: Re: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support On 06/11/2015 03:42 AM, rajinikanth.panduran...@pmcs.com wrote: From: Rajinikanth Pandurangan

RE: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support

Leubner; Murthy Bhat; Rajinikanth Pandurangan Subject: [Patch V2 2/9] [SCSI] aacraid: Add Power Management support From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources

[Patch V2 2/9] [SCSI] aacraid: Add Power Management support

From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown * aac_acquire_resources re-initializes the host interface Signed-off-by:

Re: [PATCH 2/9] [SCSI] aacraid: Add Power Management support

On Wed, 2015-05-13 at 17:12 -0700, rajinikanth.panduran...@pmcs.com wrote: diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c index 9eec027..be30e43 100644 --- a/drivers/scsi/aacraid/linit.c +++ b/drivers/scsi/aacraid/linit.c @@ -1317,6 +1317,149 @@ static int

RE: [PATCH 2/9] [SCSI] aacraid: Add Power Management support

] aacraid: Add Power Management support On Wed, 2015-05-13 at 17:12 -0700, rajinikanth.panduran...@pmcs.com wrote: diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c index 9eec027..be30e43 100644 --- a/drivers/scsi/aacraid/linit.c +++ b/drivers/scsi/aacraid/linit.c

Re: [PATCH 2/9] [SCSI] aacraid: Add Power Management support

; Rich Bono; Achim Leubner; Murthy Bhat Subject: Re: [PATCH 2/9] [SCSI] aacraid: Add Power Management support On Wed, 2015-05-13 at 17:12 -0700, rajinikanth.panduran...@pmcs.com wrote: diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c index 9eec027..be30e43 100644

Re: [PATCH 2/9] [SCSI] aacraid: Add Power Management support

On 05/14/2015 02:12 AM, rajinikanth.panduran...@pmcs.com wrote: From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown *

Re: [PATCH 2/9] [SCSI] aacraid: Add Power Management support

On 05/14/2015 02:12 AM, rajinikanth.panduran...@pmcs.com wrote: From: Rajinikanth Pandurangan rajinikanth.panduran...@pmcs.com Description: * .suspend() and .resume() routines implemented in the driver * aac_release_resources() initiates firmware shutdown *

RE: ufs: add UFS power management support

Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Thursday, October 02, 2014 6:31 PM To: subha...@codeaurora.org Cc: linux-scsi@vger.kernel.org Subject: re: ufs: add UFS power management support Hello Subhash Jadavani, The patch 57d104c153d3: ufs: add UFS power management

Re: ufs: add UFS power management support

On Thu, Oct 23, 2014 at 10:28:52AM +0300, Dolev Raviv wrote: Hi Dan, This seem like a false alarm, please let me know if it requires a fix. It may not indicate a bug, but it is correct in that the code could be re-written: Old: else if ((req_link_state == UIC_LINK_OFF_STATE)

re: ufs: add UFS power management support

Hello Subhash Jadavani, The patch 57d104c153d3: ufs: add UFS power management support from Sep 25, 2014, leads to the following static checker warning: drivers/scsi/ufs/ufshcd.c:4746 ufshcd_link_state_transition() warn: we tested 'check_for_bkops' before and it was 'true

Re: [PATCH/RESEND V6 00/18] UFS: Power management support

I've had the series in a ufs-for-3.18 branch for a while, and the two issues pointed out by the buildbot were quickly fixed. Unless I get a loud complaint I will merge the entire series including the two core patches into drivers-for-3.18 tomorrow. -- To unsubscribe from this list: send the line

Re: [PATCH V5 11/17] scsi: ufs: add UFS power management support

Thanks Mita, You are right these are careless mistakes. I will fix all of them and upload a new version shortly. __ufshcd_send_uic_cmd() is called with host_lock held here, but host_lock is acquired again in __ufshcd_send_uic_cmd(). So it causes recursive deadlock. Correct I forgot to

[PATCH/RESEND V6 00/18] UFS: Power management support

This patch seies introduces support for power management in the driver as well as vendor specific initialization - registers, clocks, voltage regulators etc. It includes also a rework for the init sequence and other PM pre-requisite such as write protection support, handling well-known LUN

[PATCH V6 12/18] scsi: ufs: add UFS power management support

From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci

Re: [PATCH/RESEND V6 00/18] UFS: Power management support

Please stop putting listname-owner (in this case linux-scsi-owner) in the CC: list, that goes to me not the list. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at

[PATCH V5 11/17] scsi: ufs: add UFS power management support

From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci

[PATCH/RESEND V5 00/17] UFS: Power management support

This patch seies introduces support for power management in the driver as well as vendor specific initialization - registers, clocks, voltage regulators etc. It includes also a rework for the init sequence and other PM pre-requisite such as write protection support, handling well-known LUN

Re: [PATCH V5 11/17] scsi: ufs: add UFS power management support

2014-09-25 0:14 GMT+09:00 Dolev Raviv dra...@codeaurora.org: +int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, struct uic_command *cmd) { - struct uic_command uic_cmd = {0}; - struct completion pwr_done; + struct completion uic_async_done; unsigned long flags;

[PATCH/RESEND V4 00/17] UFS: Power management support

This patch seies introduces support for power management in the driver as well as vendor specific initialization - registers, clocks, voltage regulators etc. It includes also a rework for the init sequence and other PM pre-requisite such as write protection support, handling well-known LUN

[PATCH V4 11/17] scsi: ufs: add UFS power management support

From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci

Re: [PATCH/RESEND V4 00/17] UFS: Power management support

Just from a quick glance this is missing the wlun type fixup we recently talked about, do you plan to send this as a separate series? Also I've already merged the first patch, in case the new one differs from the merged one in any way (doesn't seem so), please send an incremental diff for it. --

Re: [PATCH V4 11/17] scsi: ufs: add UFS power management support

); + + /* + * For selecting the UFS device power mode (Active / UFS_Sleep / + * UFS_PowerDown), SCSI power management command (START STOP UNIT) + * needs to be sent to a UFS device Well known Logical Unit (W-LU). + * As this command would be sent during the UFS host controller

Re: [PATCH V4 11/17] scsi: ufs: add UFS power management support

); + +/* + * For selecting the UFS device power mode (Active / UFS_Sleep / + * UFS_PowerDown), SCSI power management command (START STOP UNIT) + * needs to be sent to a UFS device Well known Logical Unit (W-LU). + * As this command would be sent during the UFS host controller + * runtime

RE: [PATCH V4 11/17] scsi: ufs: add UFS power management support

previous mail (in response to [9/17] patch comments), UFS driver power management is controlled via device W-LUN during the suspend process. As documented in the comment above: * For selecting the UFS device power mode (Active / UFS_Sleep / * UFS_PowerDown), SCSI power management command (START

Re: [PATCH V3 10/16] scsi: ufs: add UFS power management support

...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. snip +vccq_lpm: +ufshcd_config_vreg_lpm(hba, hba-vreg_info.vccq); +vcc_disable: +ufshcd_toggle_vreg(hba-dev, hba-vreg_info.vcc, false); +out: +return ret; +} + +static

Re: [PATCH V3 10/16] scsi: ufs: add UFS power management support

Hi Dolev, On Wednesday 10 September 2014 05:24 PM, Dolev Raviv wrote: From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. snip +vccq_lpm: + ufshcd_config_vreg_lpm(hba, hba-vreg_info.vccq

Re: [PATCH V3 10/16] scsi: ufs: add UFS power management support

2014-09-10 20:54 GMT+09:00 Dolev Raviv dra...@codeaurora.org: +static int ufshcd_config_vreg_load(struct device *dev, struct ufs_vreg *vreg, + int ua) +{ + int ret = 0; + struct regulator *reg = vreg-reg; + const char *name = vreg-name; +

Re: [PATCH V3 10/16] scsi: ufs: add UFS power management support

2014-09-10 20:54 GMT+09:00 Dolev Raviv dra...@codeaurora.org: +static inline void ufshcd_enable_irq(struct ufs_hba *hba) +{ + if (!hba-is_irq_enabled) { + enable_irq(hba-irq); + hba-is_irq_enabled = true; + } +} + +static inline void

[PATCH V3 00/16] UFS: Power management support

This patch seies introduces support for power management in the driver as well as vendor specific initialization - registers, clocks, voltage regulators etc. It includes also a rework for the init sequence and other PM pre-requisite such as write protection support, handling well-known LUN

[PATCH V3 10/16] scsi: ufs: add UFS power management support

From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci

Re: [PATCH V3 10/16] scsi: ufs: add UFS power management support

2014-09-10 20:54 GMT+09:00 Dolev Raviv dra...@codeaurora.org: +static inline void ufshcd_enable_irq(struct ufs_hba *hba) +{ + if (!hba-is_irq_enabled) { + enable_irq(hba-irq); + hba-is_irq_enabled = true; + } +} + +static inline void

RE: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support

Hi all, Thanks for reviewing the patches, I'm sorry for the late replay. I was waiting for some comments before I address all at once and re-send the series. +static int ufshcd_config_vreg_load(struct device *dev, struct ufs_vreg *vreg, + int ua) +{ +int

RE: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support

Hi all, Thanks for reviewing the patches, I'm sorry for the late replay. I was waiting for some comments before I address all at once and re-send the series. +/** + * ufshcd_resume - helper function for resume operations + * @hba: per adapter instance + * @pm_op: runtime PM or system PM

RE: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support

; linux-scsi-ow...@vger.kernel.org; linux-arm-...@vger.kernel.org; santos...@gmail.com; Subhash Jadavani; Sujit Reddy Thumma Subject: RE: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow

Re: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support

FYI: I won't read your mails until you actually make them readable by trimming the quotes back to provide just enough context. Consider this mail (and the one you replied to) unread. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to

RE: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support

...@vger.kernel.org; linux-arm-...@vger.kernel.org; santos...@gmail.com; Subhash Jadavani; Dolev Raviv; Sujit Reddy Thumma Subject: [PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link

[PATCH/RFC V2 10/16] scsi: ufs: add UFS power management support

From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci

[RFC 10/10] scsi: ufs: add UFS power management support

From: Subhash Jadavani subha...@codeaurora.org This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci

Re: [PATCH 4/4] scsi: translate errors for power management

On Thursday 02 August 2012 11:43:44 James Bottomley wrote: this should be inside the switch as default: return -EIO; and no return statment outside of the switch. OK Don't you still want to handle BUSY and QUEUE_FULL as -EBUSY? Right at the moment they'll fall through the

[PATCH 5/5] scsi: more error conditions for power management

BUSY and QUEUE_FULL are retryable errors. Signed-off-by: Oliver Neukum oneu...@suse.de --- drivers/scsi/scsi_error.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 195cc75..2f70a07 100644 ---

Cleanup error handling for power management of sd

Errors happening while sd devices are going to sleep need to interpreted for the generic layer. In particular errors for unplugged devices and removed media must be ignored. This hits mostly users of eSATA devices who unplug external drives right before the system is supposed to go to sleep. -- To

[PATCH 4/4] scsi: translate errors for power management

Synchronizing caches may fail. The reason for these failures need to be translated to the generic layer so that it nows whether to ignore a failure, retry later or give up, aborting sleep. Signed-off-by: Oliver Neukum oneu...@suse.de --- drivers/scsi/scsi_error.c | 33

Re: [PATCH 4/4] scsi: translate errors for power management

On Thu, 2012-08-02 at 12:27 +0200, Oliver Neukum wrote: Synchronizing caches may fail. The reason for these failures need to be translated to the generic layer so that it nows whether to ignore a failure, retry later or give up, aborting sleep. Signed-off-by: Oliver Neukum oneu...@suse.de

[PATCH] mpt fusion: Power Management fixes for MPT SAS PCI-E controllers

the driver to free resources and allocate resources in power management entry points and to enable MSI interrupts for SAS controllers Signed-off-by: Sathya Prakash [EMAIL PROTECTED] --- diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c index bfda731..b3b80bf 100644

Re: [PATCH] mpt fusion: Power Management fixes for MPT SAS PCI-E controllers

are not happening properly with 106XE controllers, this patch modifies the driver to free resources and allocate resources in power management entry points and to enable MSI interrupts for SAS controllers I really wish you hadn't done this. Both MSI and suspend/resume are somewhat bug inducing

Re: SCSI power management for AHCI

Management? Should there be a stronger connection between the two? Link Power Management seems to be hw stuff, and I do not think much linking is neccessary. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky

Re: SCSI power management for AHCI

On Tue, 15 Jan 2008, Pavel Machek wrote: Hi! This is my first attempt at ahci autosuspend. It is _very_ hacky at this moment, I'll seriously need to clean it up. But it seems to work here. How does this interact with Link Power Management? Should there be a stronger connection between

SCSI power management for AHCI

ata_port *a } #ifdef CONFIG_PM +/* This disables link power management */ static void ata_lpm_enable(struct ata_host *host) { struct ata_link *link; @@ -795,6 +796,7 @@ static void ata_lpm_enable(struct ata_ho } } +/* This enables link power management */ static void

Re: [RFC] Implementation of SCSI dynamic power management

Am Mittwoch, 9. Januar 2008 21:36:20 schrieb Alan Stern: On Wed, 9 Jan 2008, Oliver Neukum wrote: Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern: On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with

Re: [linux-pm] Re: [RFC] Implementation of SCSI dynamic power management

On Tue, 8 Jan 2008, Pavel Machek wrote: In fact suspend methods already do take an argument specifying the reason they were called. It wouldn't be hard to add a couple of extra PM_EVENT_* values for manual suspend and autosuspend. The problem is that resume methods don't take a

Re: [RFC] Implementation of SCSI dynamic power management

Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: When all the devices under a host are suspended, the LLD is informed (via a new autosuspend method in the host template) so that it can put the host adapter in a low-power state.  Likewise, a new autoresume method is called when the

Re: [RFC] Implementation of SCSI dynamic power management

On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb drivers if we wish to adopt this patch. All a device's interfaces must be resumed when the storage interface is

Re: [RFC] Implementation of SCSI dynamic power management

Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern: On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb drivers if we wish to adopt this patch. All a

Re: [RFC] Implementation of SCSI dynamic power management

On Wed, 9 Jan 2008, Oliver Neukum wrote: Am Mittwoch, 9. Januar 2008 18:22:51 schrieb Alan Stern: On Wed, 9 Jan 2008, Oliver Neukum wrote: This has an interesting implication. As the storage driver can share a device with in principle any other usb driver, we must audit all usb

Re: [RFC] Implementation of SCSI dynamic power management

Am Dienstag, 8. Januar 2008 04:56:03 schrieb Alan Stern: You'll have to add this method whenever a new subsystem is affected by power management. Sorry, I don't understand your point.  If you mean that we'll have to add autosuspend and autoresume code to every driver that wants to support

Re: [RFC] Implementation of SCSI dynamic power management

Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:  /** + * autoresume - perform dynamic (runtime) host resume + [EMAIL PROTECTED]: host to resume + * + * Resume (return to an operational power level) the specified host. + * Return 0 if the resume was successful, otherwise a

Re: [RFC] Implementation of SCSI dynamic power management

Am Dienstag, 8. Januar 2008 16:06:53 schrieb Alan Stern: Eventually parts of the autosuspend mechanism will go there.  But first I thought we should have a proof-of-concept version working for at least two different subsystems (such as SCSI and USB), so that we can understand what should go

Re: [RFC] Implementation of SCSI dynamic power management

On Tue, 8 Jan 2008, Oliver Neukum wrote: Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:  /** + * autoresume - perform dynamic (runtime) host resume + [EMAIL PROTECTED]: host to resume + * + * Resume (return to an operational power level) the specified host. + * 

Re: [RFC] Implementation of SCSI dynamic power management

Am Dienstag, 8. Januar 2008 16:12:52 schrieb Alan Stern: On Tue, 8 Jan 2008, Oliver Neukum wrote: Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern:  /** + * autoresume - perform dynamic (runtime) host resume + [EMAIL PROTECTED]: host to resume + * + * Resume

Re: [RFC] Implementation of SCSI dynamic power management

On Tue, 8 Jan 2008, Oliver Neukum wrote: Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: This patch applies to 2.6.24-rc6.  Comments and suggestions are welcome. What about the SG_IO ioctl() ? It seems to me that you must not autosuspend a device after that ioctl() has been used

Re: [RFC] Implementation of SCSI dynamic power management

Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: This patch applies to 2.6.24-rc6.  Comments and suggestions are welcome. What about the SG_IO ioctl() ? It seems to me that you must not autosuspend a device after that ioctl() has been used until the file handle is closed.

Re: [RFC] Implementation of SCSI dynamic power management

On Tue, 8 Jan 2008, Oliver Neukum wrote: Am Dienstag, 8. Januar 2008 04:56:03 schrieb Alan Stern: You'll have to add this method whenever a new subsystem is affected by power management. Sorry, I don't understand your point.  If you mean that we'll have to add autosuspend

Re: [RFC] Implementation of SCSI dynamic power management

Am Dienstag, 8. Januar 2008 16:16:43 schrieb Alan Stern: What about the SG_IO ioctl() ? It seems to me that you must not autosuspend a device after that ioctl() has been used until the file handle is closed. That's an open problem.  The patch does block autosuspends as long as an sg file

Re: [RFC] Implementation of SCSI dynamic power management

Alan Stern wrote: On Tue, 8 Jan 2008, Oliver Neukum wrote: Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: /** + * autoresume - perform dynamic (runtime) host resume [...] This seems to be a bit misleading. It seems to me that you must cancel any outstanding request to

Re: [RFC] Implementation of SCSI dynamic power management

On Tue, 8 Jan 2008, Stefan Richter wrote: How about something more like this: * Resume (return to an operational power level) the specified host, * and prevent autosuspends from other software layers until the * template autosuspend method has been called again. * Return 0 if

Re: [linux-pm] Re: [RFC] Implementation of SCSI dynamic power management

When all the devices under a host are suspended, the LLD is informed (via a new autosuspend method in the host template) so that it can That is most certainly a mistake. Why? Is there a good reason to not modify to extend suspend() to take an extra argument for the reason it

[RFC] Implementation of SCSI dynamic power management

=== --- 2.6.24-rc6.orig/drivers/scsi/Kconfig +++ 2.6.24-rc6/drivers/scsi/Kconfig @@ -57,6 +57,18 @@ config SCSI_PROC_FS If unsure say Y. +config SCSI_DYNAMIC_PM + bool SCSI dynamic Power Management support (EXPERIMENTAL) + depends on SCSI PM EXPERIMENTAL + ---help

Re: [RFC] Implementation of SCSI dynamic power management

Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: When all the devices under a host are suspended, the LLD is informed (via a new autosuspend method in the host template) so that it can That is most certainly a mistake. Is there a good reason to not modify to extend suspend() to take an

Re: [RFC] Implementation of SCSI dynamic power management

On Mon, 7 Jan 2008, Oliver Neukum wrote: Am Montag, 7. Januar 2008 20:42:23 schrieb Alan Stern: When all the devices under a host are suspended, the LLD is informed (via a new autosuspend method in the host template) so that it can That is most certainly a mistake. Why? Is there a

Re: [RFC] Implementation of SCSI dynamic power management

That is most certainly a mistake. Why? You'll have to add this method whenever a new subsystem is affected by power management. Besides what are the semantics of this method? May suspend() be called after autosuspend() ? If not, will resume() be called or autoresume() ? Regards

Re: [RFC] Implementation of SCSI dynamic power management

autosuspend method in the host template) so that it can That is most certainly a mistake. Why? You'll have to add this method whenever a new subsystem is affected by power management. Sorry, I don't understand your point. If you mean that we'll have to add autosuspend and autoresume code

Re: SCSI dynamic power management

On Mon, Nov 19 2007, Alan Stern wrote: On Mon, 19 Nov 2007, Matthew Wilcox wrote: On Mon, Nov 19, 2007 at 10:36:19AM -0500, Alan Stern wrote: These are conflicting requirements. How can we send the START-STOP UNIT commands to spin the disk up/down through the request queue while

RE: SCSI dynamic power management

past this filter. Is this what the REQ_PREEMPT flag is intended for? Um, that model is pretty host centric ... we wouldn't be able to use that for power management of shared devices like SAS/SATA devices in an expander or FC devices. The basic problem with power management

  1   2   3   >