On Mon, 17 Nov 2014, Kevin Hilman wrote: > Ulf Hansson <ulf.hansson@xxxxxxxxxx> writes: > > > The amba bus, amba drivers and a vast amount of platform drivers which > > enables runtime PM, don't invoke a pm_runtime_get_sync() while probing > > their devices. > > > > Instead, once they have turned on their PM resourses during ->probe() > > and are ready to handle I/O, these invokes pm_runtime_set_active() to > > synchronize its state towards the runtime PM core. > > > > From a runtime PM point of view this behavior is perfectly acceptable, > > In the context of PM domains that can be dynamically powered on/off, I'm > not so sure it's perfectly acceptable anymore. > > Why doesn't the bus do a _get_sync() instead of a _get_noresume() > followed by a _set_active(). > > By using the _get_noresume() you're bypassing the paths that would bring > up your PM domain. This probably comes about because devices that are part of a power domain need special treatment. Before the driver's probe routine gets called, the bus ought to resume the entire power domain. For that, some sort of _get_sync() is needed. For devices that aren't part of a power domain, things are simpler. The bus does _get_noresume() to make sure the device won't be runtime suspended while the probe routine is running. It doesn't do _get_sync(), because that would end up calling the driver's runtime_resume routine before the driver was bound to the device. (The bus could prevent that from happening by taking special precautions, like PCI does, but in general it's a nuisance.) Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html