Hi, Adding Rafael and linux-pm to Cc as well. * Felipe Balbi <balbi@xxxxxxxxxx> [180619 01:23]: > This is a direct consequence of not paying attention to the order of > things. If driver were to assume that pm_domain->activate() would do the > right thing for the device -- meaning that probe would run with an > active device --, then we wouldn't need that pm_runtime_get() call on > probe at all. Rather we would follow the sequence: > > pm_runtime_forbid() > pm_runtime_set_active() > pm_runtime_enable() > > /* do your probe routine */ > > pm_runtime_put_noidle() > > Then you remove you would need to call pm_runtime_get_noresume() to > balance out the pm_runtime_put_noidle() there. How about let's create some prettier interface for the above runtime PM trickery? How about something like pm_runtime_init_enabled() for the above sequence? It might be then able to do the trick even if activate is not implemented.. Right now it has the feeling of "oh well we can't get runtime PM to work so let's bypass it with activate call and then trick runtime PM to start in enabled mode" :) > Anyway, with an assumption like this, after all platform_devices are > converted over, the assumption can be moved into the bus code and, low > and behold, to enable runtime pm for your driver, all you have to is > implement your callbacks and add pm_runtime_put_noidle() to probe and > pm_runtime_get_noresume() to remove (apart from, of course, making sure > the device isn't allowed to runtime_suspend when it's actually busy). > > Do you see the end goal? It certainly would be nice to make runtime PM generic for drivers :) > (If you need to know why the pm_runtime_put_noidle(), remember that > pm_runtime_set_active() increments the usage counter, so > pm_runtime_put_noidle is basically allowing pm_runtime to happen as soon > as userspace writes "auto" to /sys/..../power/control) I wonder if we could also remove the need for drivers to call pm_runtime_putnoidle() at the end of the probe? If we had pm_runtime_init_enabled() implemented. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
