On 24/06/13 21:06, Stephen Boyd wrote:
> On 06/24/13 08:53, Srinivas KANDAGATLA wrote:
>> +
>> +static void gt_clockevents_stop(struct clock_event_device *clk)
>> +{
>> + gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, clk);
>> + disable_percpu_irq(clk->irq);
>> +}
>> +
>> +static int __cpuinit gt_clockevents_setup(struct clock_event_device *clk)
>> +{
>> + struct clock_event_device *evt = this_cpu_ptr(gt_evt);
>> + return evt->name ? 0 : gt_clockevents_init(evt);
>> +}
>
> How does this work? gt_clockevents_stop() is using the
> clock_event_device struct from the ARM local timer layer whereas
> gt_clockevents_setup() is using a driver private allocation.
Thanks for pointing this..
This should fix it.
static void gt_clockevents_stop(struct clock_event_device *clk)
{
struct clock_event_device *evt = this_cpu_ptr(gt_evt);
gt_clockevent_set_mode(CLOCK_EVT_MODE_UNUSED, evt);
disable_percpu_irq(evt->irq);
}
Please just
> don't use the local timer API at all and use cpu notifiers instead.
Last time when I did try using cpu notifiers like arm_arch_timer, the
broadcast dummy timer did kick off and took over the local timer on the
secondary cpus. Resulting in lot of broadcast IPI's.
If I use cpu notifiers I will end up two clk events on a each core (one
dummy from arm/kernel/smp.c and other gt clk_evt). I think I can only
use cpu notifiers in my case once your patches are in.
Also I cant disable LOCAL_TIMERS as it y by default.
Am I missing something?
Am happy to move to cpu notifiers if it works, else the driver will be
broken.
Thanks,
srini
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
