On Sat, Feb 19, 2011 at 10:54:57AM +0100, Linus Walleij wrote: > 2011/2/18 Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>: > > > Do we have any pressing need to convert AMBA stuff? I haven't heard 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 in. > > As my boards don't have any sensible PM support, I don't have any > > visibility of what PM facilities would be required. > > Sure, basically I ACK Rabins patch and his reasoning for it. (BTW > Rabin spends most of his days working on the Ux500 SoCs too.) > > 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. > > 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 preserve > across transfers, it is written such that the core is loaded with the > appropriate state for each message. > > Continuing this approach we run into two problems with this > and other drivers: > > - 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. > > - 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. > > 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 talked about earlier in this thread? -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
