From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: platform/i2c busses: pm runtime and system sleep Date: Sat, 19 Feb 2011 10:00:17 +0000 Message-ID: <20110219100017.GA29493@n2100.arm.linux.org.uk> References: <201102181928.05911.rjw@sisk.pl> <201102182120.29977.rjw@sisk.pl> <20110218202744.GA19427@n2100.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Walleij Cc: "Rafael J. Wysocki" , Rabin Vincent , khilman@ti.com, magnus.damm@gmail.com, LKML , stern@rowland.harvard.edu, linux-i2c@vger.kernel.org, linux-pm@lists.linux-foundation.org, linux-arm-kernel List-Id: linux-i2c@vger.kernel.org On Sat, Feb 19, 2011 at 10:54:57AM +0100, Linus Walleij wrote: > 2011/2/18 Russell King - ARM Linux : >=20 > > Do we have any pressing need to convert AMBA stuff? =A0I haven't he= ard any > > reason yet to convert them to runtime PM - they don't even make any > > runtime PM calls. > > > > Maybe Linus can comment on the PM stuff as he has SoCs with these i= n. > > As my boards don't have any sensible PM support, I don't have any > > visibility of what PM facilities would be required. >=20 > Sure, basically I ACK Rabins patch and his reasoning for it. (BTW > Rabin spends most of his days working on the Ux500 SoCs too.) >=20 > The runtime PM we need for Ux500 is to switch off silicon core > voltage first and foremost. The call I've added to switch of a core > voltage regulator will need to be called when the silicon is idle. >=20 > In spi/amba-pl022.c I take the most brutal approach with a recent > patch: hammer off this core switch (and clock) whenever the hardware > is not used. This is simple in this driver since it has no state to p= reserve > across transfers, it is written such that the core is loaded with the > appropriate state for each message. >=20 > Continuing this approach we run into two problems with this > and other drivers: >=20 > - Hammering off/on the clock+voltage is causing delays in HW > so what you want is some hysteresis (usually, wait a few us/ms > then switch off) - sort of a takeoff/landing effect. >=20 > - Modelling voltage domains as regulators is nice, but require > us to switch on/off from process context, so we cannot do this > from interrupt handlers. >=20 > Both of these problems are solved by elegance if we use runtime > PM, since it will provide a hysteresis timeout that can be triggered > from interrupt context and call the idling hooks in process context. So what's the interdependence with the platform bus that was being talk= ed about earlier in this thread?