[PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn

Cousson, Benoit b-cousson at ti.com
Thu Sep 15 05:36:02 EDT 2011


Hi Santosh,

On 9/14/2011 7:22 PM, Shilimkar, Santosh wrote:
> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
>> * Santosh<santosh.shilimkar at ti.com>   [110914 09:40]:
>>> On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
>>>> * Santosh<santosh.shilimkar at ti.com>    [110914 09:16]:
>>>>
>>>> Thanks for the clarification. It seems to me the spec is most likely
>>>> wrong as we've had the GIC working for over two years now without
>>>> doing anything with the wakeup gen registers :)
>>>>
>>> It's working because CPU clockdomain are never put under HW
>>> supervised mode and they are kept in force wakeup. Clock-domain
>>> never idles on mainline code. PM series will put the clock-domains
>>> under HW supervison as needed to achieve any low power states and
>>> then all sorts of corner cases will come out.
>>
>> But again the wakeup gen triggers only do something when hitting
>> idle. There should be no use for them during runtime, right?
>>
> You missed my point in the description. Clockdomain inactive
> doesn't depend on idle or WFI execution. Under HW supervison
> CPU clock domain can get into inactive when CPU is stalled and
> waiting for a read response from slow interconnect.

I'm a little bit confused by that statement...

I'm wondering how the PRCM can gate the CPU/MPU clock and re-enable it 
if the MPU is gated? What kind of event can wakeup the CPU in case of 
CPU stalled?

The spec seems to indicate that wakeupgen is needed only if CPU are in 
WFI. It is even written: "CPUx will change power state only when 
StandbyWFI is asserted.". Even a WFE is not supposed to trigger a standby.
How can the CPU be inactive at clock domain level without a WFI?

Regards,
Benoit



More information about the linux-arm-kernel mailing list