On Mon, Nov 03, 2014 at 09:36:45AM +0100, Krzysztof Kozlowski wrote: > On sob, 2014-11-01 at 01:01 +0000, Russell King - ARM Linux wrote: > > Would another possible solution be to remember the irq-safeness in the > > suspend handler, and use that in the resume handler? Resume should > > /always/ undo what the suspend handler previously did wrt clk API stuff. > > I think the second solution could be more readable. The WARN_ON wouldn't > be needed. However this won't solve the two dual nature of runtime > callbacks. > > I wondered also about removing runtime PM callbacks from amba/bus.c > completely and moving this to child drivers. This way runtime PM would > be obvious in each driver case. That makes it pretty horrid from the point of view of having bus management code, because we now have the management of the bus clock split between the bus layer and the device driver. This is /really/ a problem for runtime PM. Runtime PM permits there to be a bus layer involved - and runtime PM can also be coupled up to PM domains as well. For all this stuff, the context which the callbacks are called in depends on whether the driver itself has marked the device as having IRQ-safe callbacks. That's fine, but the bus and PM domain level code then /really/ needs to know what context they're being called in, so they know whether they can sleep or not, or they must to be written to always use non-sleeping functions so they work in both contexts. If we assume the former, then that implies that the irq-safe flag must never change state between a suspend and a resume. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
