Re: [RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods

2012-10-18 Thread Kevin Hilman
Felipe Balbi ba...@ti.com writes: current omap_device PM implementation defines omap-specific *_noirq methods but uses the generic versions for all other PM methods. As it turns out, if a device decides to implement non-runtime PM callbacks, we might fall into a situation where the hwmod

Re: [RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods

2012-10-18 Thread Felipe Balbi
Hi, On Thu, Oct 18, 2012 at 10:07:31AM -0700, Kevin Hilman wrote: Felipe Balbi ba...@ti.com writes: current omap_device PM implementation defines omap-specific *_noirq methods but uses the generic versions for all other PM methods. As it turns out, if a device decides to implement

Re: [RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods

2012-10-18 Thread Felipe Balbi
Hi, On Thu, Oct 18, 2012 at 08:06:40PM +0300, Felipe Balbi wrote: Hi, On Thu, Oct 18, 2012 at 10:07:31AM -0700, Kevin Hilman wrote: Felipe Balbi ba...@ti.com writes: current omap_device PM implementation defines omap-specific *_noirq methods but uses the generic versions for all

[RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods

2012-10-17 Thread Felipe Balbi
current omap_device PM implementation defines omap-specific *_noirq methods but uses the generic versions for all other PM methods. As it turns out, if a device decides to implement non-runtime PM callbacks, we might fall into a situation where the hwmod is still idled which will generate an