From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: [PATCH 1/3] PM / QoS: Make it possible to expose PM QoS latency constraints Date: Thu, 08 Mar 2012 14:05:24 -0800 Message-ID: <87haxyaguz.fsf@ti.com> References: <201203040101.53177.rjw@sisk.pl> <201203080028.12547.rjw@sisk.pl> <87aa3rdluj.fsf@ti.com> <201203082227.50138.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog105.obsmtp.com ([74.125.149.75]:56104 "EHLO na3sys009aog105.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758719Ab2CHWFY (ORCPT ); Thu, 8 Mar 2012 17:05:24 -0500 Received: by iagw33 with SMTP id w33so1652489iag.21 for ; Thu, 08 Mar 2012 14:05:23 -0800 (PST) In-Reply-To: <201203082227.50138.rjw@sisk.pl> (Rafael J. Wysocki's message of "Thu, 8 Mar 2012 22:27:49 +0100") Sender: linux-mmc-owner@vger.kernel.org List-Id: linux-mmc@vger.kernel.org To: "Rafael J. Wysocki" Cc: Linux PM list , Linux MMC list , Guennadi Liakhovetski , Chris Ball , Ulf Hansson , Magnus Damm , Linus Walleij , Adrian Hunter , Mark Brown "Rafael J. Wysocki" writes: > On Thursday, March 08, 2012, Kevin Hilman wrote: >> "Rafael J. Wysocki" writes: >> >> > From: Rafael J. Wysocki >> > >> > A runtime suspend of a device (e.g. an MMC controller) belonging to >> > a power domain or, in a more complicated scenario, a runtime suspend >> > of another device in the same power domain, may cause power to be >> > removed from the entire domain. In that case, the amount of time >> > necessary to runtime-resume the given device (e.g. the MMC >> > controller) is often substantially greater than the time needed to >> > run its driver's runtime resume callback. That may hurt performance >> > in some situations, because user data may need to wait for the >> > device to become operational, so we should make it possible to >> > prevent that from happening. >> > >> > For this reason, introduce a new sysfs attribute for devices, >> > power/pm_qos_latency_us, allowing user space to specify the upper >> >> If we're expecting to have more of these knobs, maybe having a pm_qos >> subdir under power will keep down the clutter in /sys/devices/.../power. >> This knob would then be /sys/devices/.../power/pm_qos/pm_qos_latency_us. > > I'm not sure how difficult it is to create a subdir in sysfs under something > that is not a kobject. > > Besides, this follows the convention already used by wakeup and runtime PM > attributes that don't have their own subdirs (although there may be a number > of them in each category). OK >> I think 'latency' alone is a bit too vague (wakeup latency? interrupt >> latency? I think wakeup latency is clearer. Another possibility is >> resume latency, IMO, that will lead to confusion about whether this >> field also affects system suspend/resume. > > I think "wakeup latency" will lead to more confusion because of the > wakeup-related attributes. What confusion? All of those are related to device wakeups from some low power state, and so is this proposed latency attribute. So I don't understand the potential confusion. > I'll go for "resume_latency" if you don't mind. :-) Most people think of resume as coming back from system PM. If this is called resume_latency, I would expect confusion about why setting this attribute has no effect on how fast their system returns from system suspend. Kevin