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? Thank you. Best regards, Todor -- 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
