On Mon, 3 Nov 2014, Russell King - ARM Linux wrote: > 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. If a bus subsystem or PM domain is going to allow its drivers to choose between IRQ-safe and non-IRQ-safe runtime PM, then it is up to the subsystem to come up with a way for drivers to indicate their choice. I tend to agree with Rafael that testing dev->power.irq_safe should be good enough, with no real need for a wrapper. But the subsystem can use a different mechanism if it wants. Bear in mind, however, that once the irq_safe flag has been set, the runtime PM core offers no way to turn it off again. Alan Stern -- 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
