PM_GENERIC_DOMAINS && !PM

Currently, if PM is disabled in the kernel then so is PM_GENERIC_DOMAINS. Although this makes sense, I can see a scenario where having minimal genpd support could be advantageous.

I am looking at enabling genpd for Tegra and ideally we would populate the power domains when the platform device is probed for the power management controller (PMC) as this device contains the registers for enabling the power domains.

This works fine for the case where PM is enabled, but I am concerned about the case where we don't have PM enabled in the kernel. In this case, because domains are not populated early during the boot process, I am concerned that there is a chance for a device dependent on a power domain to be probed before the PMC device has been probed and had chance to turn on any power domains.

Quoted 9 lines · Jon Hunter

Currently, if PM is disabled in the kernel then so is PM_GENERIC_DOMAINS. Although this makes sense, I can see a scenario where having minimal genpd support could be advantageous.

I am looking at enabling genpd for Tegra and ideally we would populate the power domains when the platform device is probed for the power management controller (PMC) as this device contains the registers for enabling the power domains.

Quoted 6 lines

This works fine for the case where PM is enabled, but I am concerned about the case where we don't have PM enabled in the kernel. In this case, because domains are not populated early during the boot process, I am concerned that there is a chance for a device dependent on a power domain to be probed before the PMC device has been probed and had chance to turn on any power domains.

So make the !PM case invalid for that platform.

Seriously, either PM is mandatory, or it isn't. If it is mandatory, make it so instead of pretending that you can live without it.

Quoted 10 lines · Rafael J. Wysocki

Quoted 9 lines · Jon Hunter

Currently, if PM is disabled in the kernel then so is PM_GENERIC_DOMAINS. Although this makes sense, I can see a scenario where having minimal genpd support could be advantageous.

I am looking at enabling genpd for Tegra and ideally we would populate the power domains when the platform device is probed for the power management controller (PMC) as this device contains the registers for enabling the power domains.

Quoted 8 lines

Quoted 6 lines

This works fine for the case where PM is enabled, but I am concerned about the case where we don't have PM enabled in the kernel. In this case, because domains are not populated early during the boot process, I am concerned that there is a chance for a device dependent on a power domain to be probed before the PMC device has been probed and had chance to turn on any power domains.

So make the !PM case invalid for that platform.

Thierry, I know that we have not reviewed GPD for tegra recently, but what are your thoughts on the above in principle? At least for Tegra 64-bit?

Quoted 2 lines

Seriously, either PM is mandatory, or it isn't. If it is mandatory, make it so instead of pretending that you can live without it.

I understand your point and I do agree, however, this means that for any device with power-domains that PM is already mandatory (unless they don't use genpd at all).

I see some platforms getting around this by enabling all the power-domains early during the platform code and if PM is not enabled then they won't be turned off and so all is ok (d438462c20a3 "ARM: imx6:
gpc: always enable PU domain if CONFIG_PM is not set"). However, this assumes that power-domains will never fail to power on and this seems a little fragile to me.

One thought I had was to make the PM_GENERIC_DOMAINS_OF code independent of PM (ie. moved to domain_of.c) and with a little tweaking of the genpd_dev_pm_attach() function it could be made to work whether PM is enable or not. In other words, if PM is not enabled, then genpd_dev_pm_attach() would only return success if:
1. The device is not dependent on a power domain or
2. The device is dependent on a power domain and it is present and already powered on.

Alternatively, may be genpd_dev_pm_attach() should always return -EPROBE_DEFER (to prevent probing a device) if !PM and the device has a "power-domains" node defined.

That all sounds very complicated for little gain. Disabling PM doesn't make much sense these days, so I'd personally be fine to unconditonally enable PM on Tegra. I'm not sure what the correct way would be. Since the PM symbol is user-visible, selecting it doesn't sound like a very good solution, though a quick grep shows that some architectures do this.

Rafael, do you know what the canonical way is to make !PM invalid for a platform?

Quoted 1 line · Thierry Reding

[cut]

Quoted 8 lines

That all sounds very complicated for little gain. Disabling PM doesn't make much sense these days, so I'd personally be fine to unconditonally enable PM on Tegra. I'm not sure what the correct way would be. Since the PM symbol is user-visible, selecting it doesn't sound like a very good solution, though a quick grep shows that some architectures do this.

Quoted 2 lines

Rafael, do you know what the canonical way is to make !PM invalid for a platform?

Well, good question.

I can't really suggest anything cleaner than selecting it from the top-level Kconfig at the moment.