On 05/31/2012 10:05 AM, Jon Hunter wrote: > Hi Will, > > On 05/30/2012 08:29 PM, Will Deacon wrote: >> Hi Kevin, >> >> On Wed, May 30, 2012 at 10:50:01PM +0100, Kevin Hilman wrote: >>> Basically, I don't like the result when we have to hack around missing >>> runtime PM support for a driver, so IMO, the driver should be updated. >>> >>> IOW, it looks to me like the armpmu driver should grow runtime PM >>> support. The current armpmu_release|reserve should probably be replaced >>> with runtime PM get/put, and the functionality in those functions would >>> be the runtime PM callbacks instead. >>> >>> Will, any objections to armpmu growing runtime PM support? >> >> My plan for the armpmu reservation is to kill the global reservation scheme >> that we currently have and push those function pointers into the arm_pmu, >> so that fits with what you'd like. >> >> The only concern I have is that we need the mutual exclusion even when we >> don't have support for runtime PM. If we can solve that then I'm fine with >> the approach. > > I am not sure I follow your last point. Can you elaborate a little more? By the way, I do see your point now. I have just posted a very simple PM runtime adaption, which I am not sure if this is exactly what you and Kevin have in mind. However, with this implementation we would not need to worry about the mutual exclusion as we don't change the flow. Alternatively, the reserve_pmu() call could be done outside of the runtime pm callbacks. Cheers Jon -- 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
