[...] >>>>> In this regards as we consider genpd being a trivial PM domain, those >>>>> examples your bring up above is too me also examples of trivial PM >>>>> domains. Especially because they don't deal with wakeups, as that is >>>>> taken care of by the drivers, right!? >>>> >>>> Not directly, for example, omap device framework has noirq callback implemented >>>> which forcibly disable all devices which are not PM runtime suspended. >>>> while doing this it calls drivers PM .runtime_suspend() which may return >>>> non 0 value and in this case device will be left enabled (powered) at suspend for >>>> wake up purposes (see _od_suspend_noirq()). >>>> >>> >>> Yeah, I had that feeling that omap has some trickyness going on. :-) >>> >>> I sure that can be fixed in the omap PM domain, although >> >> ...slipped with my fingers.. here is the rest of the reply... >> >> ..of course that require us to use another way for drivers to signal >> to the omap PM domain that it needs to stay powered as to deal with >> wakeup. >> >> I can have a look at that more closely, to see if it makes sense to change. >> > > Also, additional note here. some IPs are reused between OMAP/Davinci/Keystone, > OMAP PM domain have some code running at noirq time to dial with devices left > in PM runtime enabled state (OMAP PM runtime centric), while Davinci/Keystone haven't (clock_ops.c), > so pm_runtime_force_* API is actually possibility now to make the same driver work > on all these platforms. That sounds great! Also, in the end it would be nice to also convert the OMAP PM domain to genpd. I think most of the needed infrastructure is already there to do that. Kind regards Uffe -- 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
