On 12/05/2015 17:50, Russell King - ARM Linux wrote:
> On Tue, May 12, 2015 at 05:14:15PM +0200, Mason wrote:
>> This ties in to another thread I started in LAKML:
>> ("High-resolution timers not supported when using smp_twd on Cortex A9")
>>
>> $ git show 5388a6b2 arch/arm/kernel/smp_twd.c
>> commit 5388a6b266e9c3357353332ba0cd5549082887f1
>> Author: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx>
>> Date: Mon Jul 26 13:19:43 2010 +0100
>>
>> ARM: SMP: Always enable clock event broadcast support
>>
>> The TWD local timers are unable to wake up the CPU when it is placed
>> into a low power mode, eg. C3. Therefore, we need to adapt things
>> such that the TWD code can cope with this.
>>
>> We do this by always providing a broadcast tick function, and marking
>> the fact that the TWD local timer will stop in low power modes. This
>> means that when the CPU is placed into a low power mode, the core
>> timer code marks this fact, and allows an IPI to be given to the core.
>>
>> This mentions a "broadcast tick function" (of which I know nothing).
>> Is this what you're referring to?
>
> No. This has nothing to do with low power modes.
>
> How this works depends on how your kernel is configured, but essentially
> it's something like this:
>
> * The CPU which will be idling sets its local timer to wake up after N
> counter cycles, where N is calculated from the timer frequency.
>
> * When the local timer fires, the CPU is kicked out of the idle loop, and
> it reads the current system time. If the current system time indicates
> that the software timer set in schedule_timeout() has fired, that
> software timer fires.
>
> If the local timer changes frequency without the idling CPU being woken
> up, then the problem you're referring to can happen.
>
> As you're not giving much information about your system (including
> indicating where we might see some source code) we're not able to help
> more than providing above descriptions. Maybe if you posted your
> patches so far to support the project you're working on, we could
> provide better answers.
$ git diff v3.14.41 HEAD >tango.patch && xz tango.patch
I don't understand the IRQ-related part yet
( arch/arm/mach-tangox/irq.c and drivers/irqchip/irq-gic.c )
If anyone spots the problem, that would make my day.
I tested with a loadable module whose init function is
static int __init ts_init(void)
{
long res;
printk("ABOUT TO SLEEP\n");
set_current_state(TASK_INTERRUPTIBLE);
res = schedule_timeout(HZ);
printk("WAKE UP res=%ld\n", res);
return 0;
}
Loading the module, with cpufreq divided by 9, prints:
[ 1738.962982] ABOUT TO SLEEP
[ 1747.956191] WAKE UP res=0
Regards.
Attachment:
tango.patch.xz
Description: application/force-download
Attachment:
dot.config.xz
Description: application/force-download
