On Wed, Jul 8, 2009 at 11:54 AM, Alan Stern<stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 8 Jul 2009, Rafael J. Wysocki wrote: > >> > I've now jumped from v5 to v8 and I feel that the code is getting >> > cleaner and cleaner. Very nice. >> >> That's mostly thanks to Alan. > > I haven't had time yet to look through the new code. Things have been > very busy. > >> > Issue 1: >> > ------------ >> > Device drivers which do not perform any hardware access in probe() >> > work fine. During software setup in probe() the runtime pm code is >> > initialized with the following: >> > >> > + pm_suspend_ignore_children(&dev->dev, true); >> > + pm_runtime_set_suspended(&dev->dev); >> > + pm_runtime_enable(&dev->dev); >> > >> > Before accessing hardware I perform: >> > + pm_runtime_resume(pd->dev); >> > >> > When done with the hardware I do: >> > + pm_runtime_suspend(pd->dev); >> > >> > Not so complicated. Am I supposed to initialize something else as well? > > No, that's all you need. Ok, thank you! >> > All good with the code above, but there seem to be some issue with how >> > usage_count is counted up and down and when runtime_disabled is set: >> > >> > 1. pm_runtime_init(): usage_count = 1, runtime_disabled = true >> > 2. driver_probe_device(): pm_runtime_get_sync() >> > 3. pm_runtime_get_sync(): usage_count = 2 >> > 4. device driver probe(): pm_runtime_enable() >> > 5. pm_runtime_enable(): usage_count = 1 >> > 6. driver_probe_device(): pm_runtime_put() >> > 7. pm_runtime_put(): usage_count = 0 >> > >> > I expect runtime_disabled = false in 7. > > Wasn't it? It should have been set to false in step 4 and remained > that way. I may misunderstand, but in v8 won't the pm_runtime_enable() function do a atomic_dec_test() where the counter value will go from 2 to 1 in the case above? This would mean that atomic_dec_test() returns false so runtime_disabled is never modified. Thanks for your feedback, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html