On Fri, 9 Jul 2021 at 13:39, Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> wrote: > > Hi, > > On Fri, 9 Jul 2021 at 11:25, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > > > On Fri, 9 Jul 2021 at 06:32, Dmitry Baryshkov > > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > > > Registers for some genpds can be located in the SoC area, powered up by > > > another power domain. To enabled access to those registers, respective > > > domain should be turned on. > > > > > > This patch adds basic infrastructure to the genpd code to allow > > > implementing drivers for such genpd. PM domain can provide the parent > > > device through the genpd->dev.parent pointer. If its provided at the > > > pm_genpd_init() call time and if it is pm-enabled, genpd power_on and > > > power_off operations will call pm_runtime_get_sync() before powering up > > > the domain and pm_runtime_put_sync() after powering it down. > > > > > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > > > > Hi Dmitry, > > > > Using runtime PM for the genpd provider device, is not the correct > > approach. If the provider domain needs another domain to be powered on > > to work correctly, that per definition means that it has a parent > > domain. > > > > I suggest you try to build the correct PM domain topology, via using > > pm_genpd_add_subdomain() or of_genpd_add_subdomain(), then genpd will > > manages the power on/off for parent/child domain internally. > > Indeed, this patch seems redundant now, with the > pm_genpd_add_subdomain call in place. > Would you like me to resend a v3 just dropping this patch? Yes, $subject patch isn't the way to go. Let's continue discussing things on patch3/7 to conclude on the way forward. [...] Kind regards Uffe
