[PATCH] arm64: Kconfig: select PM for ARCH_VEXPRESS
Arnd Bergmann
arnd at arndb.de
Fri Jun 17 07:16:59 PDT 2016
On Friday, June 17, 2016 2:38:32 PM CEST Sudeep Holla wrote:
> On 17/06/16 12:53, Arnd Bergmann wrote:
> >> The discussion on this happened on linux-pm list[1]. This is need on
> >> Juno once we introduce coresight components in the DT. With !CONFIG_PM,
> >> the board stalls on boot and hence this patch is needed. This shouldn't
> >> change any thing in the defconfig as couple of other platforms already
> >> do the same. It's needed in case all other ARCH_* configs are disabled.
> >>
> >> Without this, we need a dirty trick in the DT[2] to handle !CONFIG_PM.
> >>
> >> Can you please pick this for v4.8 ?
> >
> > Question: if AMBA cannot deal with CONFIG_PM disabled, should
> > the 'select' be done from CONFIG_ARM_AMBA instead?
> >
>
> But few platforms using AMBA may not want PM at all.
Ok, then I just misunderstood what you meant with "the AMBA framework can't
deal with !CONFIG_PM case".
> > I also feel a little uncomfortable with just adding 'select PM', given
> > that this option is normally just implied by CONFIG_SUSPEND ||
> > CONFIG_HIBERNATE_CALLBACKS,
>
> On that analogy, for the current requirement I would say
> PM_GENERIC_DOMAINS should select but it just depends on PM.
Possibly, it's not entirely clear what the dependency is used for
here, or what CONFIG_PM actually means. I'm also still unsure what
aspect of CONFIG_PM you actually rely on here. Is this about the
amba_pm_runtime_suspend/amba_pm_runtime_resume operations or something
else?
> > so we might run into regressionswhen we get configurations that
> > were invalid before.
>
> Sorry my build/config knowledge is limited, I don't understand what you
> mean by the above. I am asking just to improve my knowledge.
If today, CONFIG_PM is only set when CONFIG_PM_SLEEP is set and
we introduce a case where we have PM without PM_SLEEP, a lot of
drivers that incorrectly make the assumption that PM_SLEEP is mean
with CONFIG_PM may behave in new unexpected ways.
> > Then again ARCH_RENESAS seems to already do this.
>
> Yes, it was hard to find get !CONFIG_PM as many platforms select it
> directly or indirectly.
Starting from an allmodconfig build, I just needed to disable
ARCH_RENESAS, ARCH_OMAP2PLUS_TYPICAL, SUSPEND and HIBERNATE.
Arnd
More information about the linux-arm-kernel
mailing list