From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Subject: Re: [patch update] Re: Run-time PM idea (was: Re: [RFC][PATCH 0/2] PM: Rearrange core suspend code) Date: Thu, 11 Jun 2009 18:05:52 +0200 Message-ID: <200906111805.53388.oliver__3397.03329741514$1244736465$gmane$org@neukum.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Alan Stern Cc: ACPI Devel Maling List , Linux-pm mailing list , LKML List-Id: linux-pm@vger.kernel.org Am Donnerstag, 11. Juni 2009 17:22:06 schrieb Alan Stern: > > > Okay, I'll agree to that. =A0It should be made clear that a device wh= ich > > > is "suspended" according to this definition is not necessarily in a > > > low-power state. =A0For example, before powering down the link to a d= isk > > > drive you might want the drive's suspend method to flush the drive's > > > cache, but it wouldn't have to spin the drive down. > > > > This precludes handling busses that have low power states that are > > left automatically. If such links are stacked the management of > > acceptable latencies cannot be left to the busses. > > An actual example are the link states of USB 3.0 > > I don't understand. =A0Can you explain more fully? I am talking about the U1 and U2 feature of USB 3.0. Or abstractly any power saving state that does autoresume in hardware. In these cases you know that you can enter a powersaving state that will add X latency. In terms of user space API we'll probably add a way for user space to specify how much latency may be added for power management's sake. If busses are stacked the "latency budget" has to be handled at core level. If furthermore states that allow IO but with additional latency are ignored, the budget will be calculated wrongly. Regards Oliver