[...] >>> >>>> What is missing, is how a call to pm_runtime_get_sync() by a driver, >>>> can inform the ->start() callback about what exact power resource(s) >>>> it shall turn on, because it may not always be all of them. Similar >>>> problem exists for pm_runtime_put(). >>> >>> Yes that is missing too, but I still don't see how you bind a device to >>> more than one power-domain :-( >> >> I think this is what Rafael wanted us avoid (because of the complexity >> involved). Instead the suggestion is to deal with this on top of the >> existing PM domain structure, as "power resources" instead. Unless I >> missed his point. :-) >> >> Then *my* point is: To be able to implement that, still only allowing >> one PM domain per device, we would anyway need a new layer in-between >> the PM domain (genpd) and the driver controlling the device. Simply >> because these two entities, needs to be able to exchange information >> about which "power resources" that shall be turned off/on, when the >> driver do pm_runtime_get|put(). > > Right, but isn't this similar to what I was suggesting above in my > previous email? Perhaps it was, apologize for my ignorance in that case. Then, isn't that quite what you already started hacking on in $subject series? What's the new thing in your previous reply? However, I was under the impression that Rafael preferred another way - but again I might have missed his point. > > I was proposing to have such a lower-layer by splitting the existing > genpd framework so the drivers would have the option of calling the > lower-level power control functions to look-up pm-domains and control > them directly from their rpm callbacks (if they need to). Same as we do > for clocks. This way you would not need to mess with the genpd ->start() > callback and leave it to the driver to handle itself as it knows what > needs to be done. This assumes that the device is never bound to the > pm-domain by the genpd core. Yes, agree! To me this is the only solution what would really work. Perhaps Rafael can confirm that he is fine with a solution like this? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
