[].. >>> 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. > > I agree! :-) > >> Perhaps Rafael can confirm that he is fine with a solution like this? > > Yes and Rafael, please can you also elaborate on what you meant by > "allow genpd to use either a list of power resources or the on/off > callbacks provided by itself to cover different use cases"? > > I would like to understand exactly what you meant by allowing genpd to > use a list of power resources (ie. how you envisioned we could achieve > this). While thinking through the problem of devices associated with multiple Power domains (or power resources) and controlling them individually (or together) I was wondering if something like a PM domain governor (with PM resource level constraints) could help. So with just one set of PM domain callbacks, its quite easy to control multiple power resources, if they need to be *all* turned on/off together, using something similar to what Jon proposed in his RFC [1] However, there could be instances where in we might need to control them individually and in such cases we could hook up a PM domain governor which decides if an individual PM resource can be turned on or off while the device is runtime suspended/resumed. We can expose some PM resource level QoS APIs which the drivers can use to express their needs, which the PM domain governor then takes into account during the decision making. if this seems worth pursuing further, I can post some RFCs on these lines and get the discussion going. thanks, Rajendra [1] https://lkml.org/lkml/2016/9/20/173 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
