[PATCH] arm64: Kconfig: select PM for ARCH_VEXPRESS

[sudeep.holla@arm.com (Sudeep Holla)]

On 17/06/16 20:38, Arnd Bergmann wrote:
> On Friday, June 17, 2016 4:49:34 PM CEST Sudeep Holla wrote:
>>
>> On 17/06/16 16:07, Arnd Bergmann wrote:
>>> On Friday, June 17, 2016 3:59:34 PM CEST Sudeep Holla wrote:
>>
>> [...]
>>
>>>> To be more precise genpd/runtime code return same error -ENODEV when
>>>> PM_GENERIC_DOMAINS=n and if the no power domain is found with
>>>> PM_GENERIC_DOMAINS=y . The AMBA bus code just checks for -EPROBE_DEFER
>>>> to stop adding devices, while proceeds to access the device otherwise.
>>>>
>>>> However on Juno, the coresight needs to powered up before accessing it.
>>>> Well all is fine if you specify power domains in DT and have
>>>> PM_GENERIC_DOMAINS=y. However if PM_GENERIC_DOMAINS=n the AMBA ignores
>>>> the error(-ENODEV) from runtime PM and access the device resulting in
>>>> boot hang when adding amba devices.
>>>>
>>>> I thought we need is to have code to check for power domains in DT for
>>>> the device even when PM_GENERIC_DOMAINS=n and return an error that can
>>>> be used to skip registering the device and clearly identifies with other
>>>> allowed errors. It may need a bit of surgery and closer look IMO. But
>>>> when asked for opinion, I was suggested to do this. I admit that I
>>>> didn't propose my thoughts then :)
>>>
>>> Ok, so we also need PM_GENERIC_DOMAINS, not just PM, right?
>>>
>> Yes, but latter won't select former. Generally I have seen domain
>> controller code selecting PM_GENERIC_DOMAINS if PM=y
>
> Then at least we need the vexpress code to select both as well,
> otherwise you could end up with PM_GENERIC_DOMAINS disabled in
> configurations that have none of the other code.
>

True, will add it.

>>> It also sounds like there is no easy way to just turn on the clocks
>>> in the amba bus handler when PM_GENERIC_DOMAINS is turned off, other
>>> than reimplementing PM_GENERIC_DOMAINS?
>>>
>>
>> Turn on power domain, not just clocks(just to be precise), yes. It needs
>> some thoughts as there are some assumptions on which existing platform
>> work. Adding the support to handle the scenario I mentioned earlier is
>> not trivial. Also the driver to handle the device may not be compiled in
>> when PM_GENERIC_DOMAINS=n or when PM=n. So I was thinking of not
>> accessing the device and hence skip adding it.
>
> I see. Another idea I had is flawed, too: we can't easily make ARM_AMBA
> depend on PM_GENERIC_DOMAINS, because the main relevant use case I
> can see for !PM builds is a kernel that is only used in virtual machines,
> but we still want to use the PL01x serial port driver in that configuration.
>
> I'd say let's select both PM_GENERIC_DOMAINS and PM on VEXPRESS for now,
> (almost) as you have in your patch.
>

OK, thanks for taking time to review. I understand it's not the best
solution but *just OK* for now. I will repost with suggested change.

-- 
Regards,
Sudeep