On Wed, Oct 24, 2012 at 04:06:07PM +0100, Jon Hunter wrote: > On 10/24/2012 09:32 AM, Will Deacon wrote: > > Hmmm, now I start to wonder whether your original idea of having separate > > callbacks for enable/disable irq and resume/suspend doesn't make more sense. > > Then the CTI magic can go in the irq management code and be totally separate > > to the PM stuff. > > > > What do you reckon? > > The resume/suspend calls really replaced the enable/disable irq > callbacks. That still seems like a good approach given that we need > runtime PM for OMAP and PMU. Ok, perhaps splitting it up isn't worth it then. I'm still not convinced either way. > > Nah, we should be able to fix this in the platdata, I'd just rather have > > function pointers instead of state variables in there. > > Well, we could pass a pointer to pm_runtime_enable() function in the > platdata. What do other drivers do? Grepping around, I see calls to pm_runtime_enable made in various drivers and, given that you pass the device in there, what's the problem with us just calling that unconditionally from perf? I know you said that will work for OMAP, but I'm trying to understand the effect that has on PM-aware platforms that don't require this for the PMU (since this seems to be per-device). Will -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
