From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Locke Subject: Re: sysfs power/state file & dpm_runtime_suspend() Date: Wed, 16 Aug 2006 23:31:29 -0700 Message-ID: References: <200607270853.54674.david-b@pacbell.net> <018801c6c104$0b0ab980$4686190c@dsn.sec.samsung.com> <200608161209.07004.david-b@pacbell.net> <006a01c6c1a6$ac74b760$4686190c@dsn.sec.samsung.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <006a01c6c1a6$ac74b760$4686190c@dsn.sec.samsung.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.osdl.org Errors-To: linux-pm-bounces@lists.osdl.org To: Ikhwan Lee Cc: David Brownell , linux-pm@lists.osdl.org List-Id: linux-pm@vger.kernel.org On Aug 16, 2006, at 7:41 PM, Ikhwan Lee wrote: > Thanks for your comments. > >>> Now I understand that the drivers are responsible for making runtime > power >>> management decisions for individual devices. But there are cases = >>> that a >>> device driver does not have enough information to make the most > effective >>> decision. In such a case, we may want to employ a high level power > manager >>> to make decisions for them. >> >> And that will need some sort of programming interface. But those will >> be providing domain-specific hints and information, not describing the >> system-wide power state transitions which are being addressed by = >> current >> bus/class/driver suspend()/resume() methods. >> >> Plus, not all drivers will have those cases and thus need new APIs. >> Best to let just those drivers pay the costs of such interfaces, and >> not try to inflict them universally. :) > > Basically agree. Some drivers actually allow applications to manage the > device power directly. (usually through ioctl) However, for a > battery-operated embedded system, we would prefer to have all the = > drivers > provide such interfaces. Yes, all drivers on the battery power embedded system will need to = provide the interface and the interface should be the same for these = drivers. I'm thinking we only need to allow userspace to turn the = device on and off. The other states of the device can be managed by = the driver with input from another kernel component as discussed = elsewhere in this thread (But I can't find where right now). > >>> This is a common case for state-of-the-art mobile handsets such as a = >>> DMB >>> phone. As a different example, a system-level power manager may want = >>> to > put >>> the codec into a low quality (thus low power) mode regarding the = >>> battery >>> status. Certainly, this kind of decision cannot be made by the = >>> driver. >> >> You've got a bit of chicken-vs-egg going on there, in that you're = >> assuming >> the answer is a system/global manager that knows about the codec!! Dave, That is not a chicken v egg problem. The manager on these = devices will know a lot about the system. Its really the only way to = get maximum balance between power efficiency and keeping the device = operational for its various use cases. >> While > in >> fact there can easily be other solutions. Examples include notifying = >> the >> user and letting _them_ choose which module to put into lowpower/off = >> mode >> (maybe the WLAN instead, since the codec is more essential just now), = >> or >> a general system "cut power usage" notification, which that driver = >> will >> interpret in that way. This is the same as having a manager. Sometimes it will be a user and = sometimes it will be automatic based on a policy. >> >> But I certainly agree that there are cases where "higher level" inputs >> are needed to help drivers manage power usage effectively. I consider >> most of those to be domain-specific APIs, outside the specific scope >> of the PM framework. (But clearly needing to be pm-aware designs.) > > Maybe it is the PowerOp's scope? Partially. and I don't have much more to add specifically right now:) = Something will have to tell the audio driver its ok to reduce quality. = The connection between powerop and drivers (which doesn't exist yet) = will have to facilitate this communication. > >>> and interdependencies >>> among devices (the device model perfectly suits for this) while = >>> device >>> drivers provide necessary APIs for safe power state transitions. >> >> The device model has glitches in terms of not handling power/voltage >> domains at all, or devices that sit on multiple busses. One example >> I've seen quite often is an external multifunction chip with a = >> highspeed >> serial bus for a codec data link, and a separate serial bus (I2C, SPI, > etc) >> for its control link and lowspeed non-codec data. Plus, clusters of >> interrelated devices aren't handled that well, even if you assume that >> clock and power domain APIs will handle those issues; my pet example >> being USB-OTG modules, which started out involving five controllers >> (host, peripheral, and OTG for USB; plus I2c and external PHY) before >> chip vendors started to use more integrated design approaches. >> >> Given the wide variety of possible device power states, I really think >> it's best to try to keep the driver model out of that business. > > OK, maybe a power/voltage domain framework will do it, and I hope that = > it > would not be as complex as the device model. > >>> I have been following the thread. I especially like the section on > runtime >>> power management, with lots of examples. I am actually working on = >>> some > of >>> them, and my claim is that (as stated above) we may need to involve = >>> some >>> kind of public power state updating in a system-wide way. >> >> I can't disagree with that at all. :) >> >> One of my concerns is how to factor that stuff well -- "architect" it = >> -- > so >> that the approach is broadly applicable. A factoring that works well = >> at >> the SOC level may not work as well at the board level; working well = >> on one >> family of SOCs doesn't mean it works well on others. > > This is a real problem. I sometimes even want to distinguish on-chip = > devices > from on-board devices. > >> I feel comfortable saying we need a power/voltage domain framework, = >> and an >> extensible framework for system-wide operating (and non-operating = >> sleep) >> states. The rest looks to me like stuff that would best be worked out >> over time, while integrating those two things and fixing the = >> inevitable >> botches in the initial designs, as applied to current hardware. > > Can't agree more. =3D) Having a power/voltage domain framework, the clock > framework, and a framework for system-wide operating states (maybe = > PowerOp), > we can say that we have a complete power management solution for = > embedded > systems. > Well, I have to agree with that too:) > Ikhwan > > > _______________________________________________ > linux-pm mailing list > linux-pm@lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm >