From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Brownell Subject: Re: [linux-pm] Re: [RFD] How to tell ACPI drivers what the target sleep state is (was: Re: [PATCH 1/2] acpi choose sleep state help) Date: Thu, 21 Jun 2007 13:03:24 -0700 Message-ID: <200706211303.25004.david-b@pacbell.net> References: <1182220394.14837.9.camel@sli10-conroe.sh.intel.com> <200706210837.29857.david-b@pacbell.net> <20070621185910.GH18481@elf.ucw.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]:28634 "HELO smtp124.sbc.mail.sp1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753060AbXFUUN6 (ORCPT ); Thu, 21 Jun 2007 16:13:58 -0400 In-Reply-To: <20070621185910.GH18481@elf.ucw.cz> Content-Disposition: inline Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Pavel Machek Cc: pm list , linux acpi On Thursday 21 June 2007, Pavel Machek wrote: > Hi! > > > > > IMO it can be done in two different ways: > > > > 1) via a .suspend() argument > > > > 2) via a global variable that the drivers can read. > > > > For sufficiently small values of "two" that is. > > > > Other solutions that have been described on the PM list include > > > > 3) Providing accessors to the information actually needed > > in drivers ... e.g. say whether this clock or power domain > > will be available in that target state. > > > > 4) Act more like "current" ... there's a function returning > > whatever "state" struct is settled on. (But ideally > > without the pseudo-global.) > > > > I'm amused that nobody really reacted to the technical comments in > > my previous posts on this thread. That's unfortunate, since from > > where I sit it feels to me like everyone else is a johnny-come-lately > > on this issue, and is now grasping at the quickest and dirtiest ways > > to work around the issue instead of coming to grasp with the various > > underlying issues. > > Well, rest of the word is still using PC here, so johny-come-lately > may not be completely unexpected. True. I could hardly escape noticing this problem though, given what it takes to get USB remote wakeup working on various systems. We've had a few years now to get that infrastructure in place. > Could you push framework for some embedded system you care about? OLPC > by chance? I'll probably push those two patches (clock core, AT91 implementation) since there seemed to be no objections. I don't work on OLPC. :) > > IMO #3 is strongly preferable. > > 3) actually looks ok to me. For acpi it would mean > > int acpi_state_we_are_entering(void) > > returning S1..S4, right? My original patch included acpi_get_target_sleep_state() returning ACPI_STATE_Sx values, yes. However, that was purely internal to ACPI-aware logic ... it was used to implement pci_choose_state(). Drivers would never make such ACPI calls themselves, they'd use pci_choose_state() instead. And the clk_must_disable() call is another instance of the same approach as pci_choose_state(): drivers getting access to the PM-reated information they need, without needing to use platform-specific calls or care about "what the target sleep state is". > > But I really thought the discussion on new PM methods, back a > > couple months now, was going to finally get rid of that. > > Umm, well, when someone gets to implement that... Oh. *THAT* little problem. Sorry, I thought it was in the works. - Dave