On 3/23/2016 12:11 PM, Grygorii Strashko wrote:
On 03/23/2016 05:38 PM, santosh shilimkar wrote:
Hi,
On 3/23/2016 8:07 AM, Tony Lindgren wrote:
Hi,
* Anna-Maria Gleixner <anna-maria@xxxxxxxxxxxxx> [160323 02:28]:
the hotplug notifier in arch/arm/mach-omap2/omap-wakeupgen.c doesn't
handle the corresponding FROZEN transitions. Is there a reason for it?
FROZEN event as such doesn't matter from wakeupgen and its context
point of view since CPU(s) and its power domain are still alive.
Adding Santosh to Cc too.
I don't think it's needed in this case as omap-wakeupgen.c just
basically takes care of the context save before powering off and
context restore right after power on. It's only a helper for the
bootrom code. The FROZEN transitions are handled at a higher
level by drivers/cpuidle/coupled.c.
Or maybe I'm missing something, if so please let me know :)
You are correct Tony.
Hm. I'm not sure. I assume this question is about CPU_TASKS_FROZEN. Right?
if yes the irq_cpu_hotplug_notify() can be called from two code paths now
1) cpu hotplug
cpu_down()/cpu_up()
... -> irq_cpu_hotplug_notify() and CPU_TASKS_FROZEN is *not* set
action = [CPU_ONLINE:CPU_DEAD]
and wakeupgen_irqmask_all() will be executed
2) suspend & friends
disable_nonboot_cpus()/enable_nonboot_cpus()
... -> irq_cpu_hotplug_notify() and CPU_TASKS_FROZEN is set
action = [CPU_ONLINE_FROZEN:CPU_DEAD_FROZEN]
and wakeupgen_irqmask_all() will *not* be executed
In case 2 wakeupgen IRQs will not be masked for non-boot CPU before entering Suspend
Not sure how critical it is, but think below diff could be right thing to do:
Nope. We use wakeup on suspend feature which I added in core code.
That takes care of it.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
