Messages in this thread | | | From | Ulf Hansson <> | Date | Mon, 28 Sep 2020 11:03:51 +0200 | Subject | Re: [PATCH v2 3/3] PM / Domains: Add support for PM domain on/off notifiers for genpd |
| |
On Fri, 25 Sep 2020 at 16:30, Peng Fan <peng.fan@nxp.com> wrote: > > > Subject: Re: [PATCH v2 3/3] PM / Domains: Add support for PM domain on/off > > notifiers for genpd > > > > On Fri, 25 Sep 2020 at 08:08, Peng Fan <peng.fan@nxp.com> wrote: > > > > > > Hi Ulf, > > > > > > > Subject: [PATCH v2 3/3] PM / Domains: Add support for PM domain > > > > on/off notifiers for genpd > > > > > > > > A device may have specific HW constraints that must be obeyed to, > > > > before its corresponding PM domain (genpd) can be powered off - and > > > > vice verse at power on. These constraints can't be managed through > > > > the regular runtime PM based deployment for a device, because the > > > > access pattern for it, isn't always request based. In other words, > > > > using the runtime PM callbacks to deal with the constraints doesn't work > > for these cases. > > > > > > Could the notification be added before/after power on, and > > > before/after power off? not just after power on and before power off? > > > > > > Our SoC has a requirement that before power on/off the specific > > > module, the corresponding clk needs to be on to make sure the hardware > > > async bridge could finish handshake. > > > > Thanks for your comments! > > > > May I ask, to be sure - does the clock correspond to the genpd provider or is it > > a clock for the genpd consumer device? > > It is the clock for the genpd consumer device. > > > > > If the former, couldn't the clock be managed from the ->power_on|off() > > callbacks for the genpd provider? > > Sadly not former. > > Our current solution is to add a clock property to the power domain node(NXP ARM SIP > based power domain driver), and when power_on/off, we enable/disable the clocks. > > But we are moving to use SCMI power domain, and leave the clock in Linux, > Scmi power domain driver is a generic driver, and we are not able to mix clock > parts in the driver which is bad. > > Your patch gives me a light that if we could use notification to let consumer > device driver do the clock enable/disable for each power on and power off. > That would be great.
Thanks for clarifying. Let me re-spin the patch to address your points.
[...]
Kind regards Uffe
| |