Théo Lebrun <theo.lebrun@xxxxxxxxxxx> writes: > Hello, > > On Wed Nov 22, 2023 at 11:23 PM CET, Kevin Hilman wrote: >> Théo Lebrun <theo.lebrun@xxxxxxxxxxx> writes: >> > On Fri Nov 17, 2023 at 12:51 PM CET, Roger Quadros wrote: >> >> On 17/11/2023 12:17, Théo Lebrun wrote: >> >> > On Thu Nov 16, 2023 at 10:44 PM CET, Roger Quadros wrote: >> >> >> On 16/11/2023 20:56, Théo Lebrun wrote: >> >> >>> On Thu Nov 16, 2023 at 1:40 PM CET, Roger Quadros wrote: >> >> >>>> On 15/11/2023 17:02, Théo Lebrun wrote: >> >> >>>>> On Wed Nov 15, 2023 at 12:37 PM CET, Roger Quadros wrote: >> >> >>>>>> You might want to check suspend/resume ops in cdns3-plat and >> >> >>>>>> do something similar here. >> >> >>>>> >> >> >>>>> I'm unsure what you are referring to specifically in cdns3-plat? >> >> >>>> >> >> >>>> What I meant is, calling pm_runtime_get/put() from system suspend/resume >> >> >>>> hooks doesn't seem right. >> >> >>>> >> >> >>>> How about using something like pm_runtime_forbid(dev) on devices which >> >> >>>> loose USB context on runtime suspend e.g. J7200. >> >> >>>> So at probe we can get rid of the pm_runtime_get_sync() call. >> >> >>> >> >> >>> What is the goal of enabling PM runtime to then block (ie forbid) it in >> >> >>> its enabled state until system suspend? >> >> >> >> >> >> If USB controller retains context on runtime_suspend on some platforms >> >> >> then we don't want to forbid PM runtime. >> >> > >> >> > What's the point of runtime PM if nothing is done based on it? This is >> >> > the current behavior of the driver. >> >> The point is to signal to the power domain the device is in that it can >> power on/off. These IP blocks are (re)used on many different SoCs, so >> the driver should not make any assumptions about what power domain it is >> in (if any.) > > On my platform, when the device is attached to the PD it gets turned on. > That feels logical to me: if a driver is not RPM aware it "just works". It "just works"... until the domain gets turned off. > Are there platforms where RPM must get enabled for the attached > power-domains to be turned on? Yes, but but more importantly, there are platforms where RPM must get enabled for the power domain to *stay* on. For example, the power domain might get turned on due to devices probing etc, but as soon as all the RPM-enabled drivers drop their refcount, the domain will turn off. If there is a device in that domain with a non-RPM enabled driver, that device will be powered off anc cause a crash. > The call chain that attaches & enables PD is platform_probe -> > dev_pm_domain_attach. That function takes a bool power_on which is > always true. In the genpd case, genpd_dev_pm_attach > calls __genpd_dev_pm_attach which does a genpd_power_on. > > Things I've not accounted for: > > - ACPI looks like it does the same but I've not checked. It gets passed > the power_on bool argument. > > - genpd_dev_pm_attach early returns with no error if there are multiple > PM domains attached to the device. There are many platforms in the > case according to some devicetree grepping. I can imagine a behavior > difference where dev_pm_domain callpaths handle that differently in > the RPM case. Is that what we are discussing? You're only looking at the attach, power-on phase. You need to think about when the domain powers off and powers back on. Kevin
