On Monday, November 03, 2014 10:41:02 AM Alan Stern wrote: > 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. There is a problem with it, though. Say, a driver handles a device that may or may not be in a power domain. Or in other words, the power domain the device is in may or may not be always on. If the domain is always on, the runtime PM callbacks are IRQ-safe (they depend on the driver only). If it isn't, they may not be IRQ-safe. How's the driver going to decide whether or not to set power.irq_safe? Rafael -- 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
