On 09/10/17 17:36, Todor Tomov wrote: > Hi, > > On 30.05.2017 06:41, Rajendra Nayak wrote: >> [].. >> >>>>> 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 >> > > I have come to a similar case with multiple power domains on Qualcomm APQ8096 - the > camera subsystem has two VFE modules (Video Front End - these are image processing modules) > and each of them has a separate power domain but we might want to control these from > a single driver. > > So I wanted to ask if there have been any news on this topic lately? There has not but there is still clearly a need for this and we need it for Tegra. I still plan to get back to this but recently a few items have cropped up and I have not had chance. So sorry about that. My plan was to split the current GPD framework so there is a lower-level set of APIs for managing the power-domains as I discussed with Rafael [0]. Cheers Jon [0] https://lkml.org/lkml/2017/5/2/203 -- nvpublic -- 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
