[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <43F901BD926A4E43B106BF17856F07559A257E3D@orsmsx508.amr.corp.intel.com>
Date: Thu, 17 Dec 2009 14:31:44 -0800
From: "Pan, Jacob jun" <jacob.jun.pan@...el.com>
To: Cyrill Gorcunov <gorcunov@...il.com>
CC: "H. Peter Anvin" <hpa@...ux.intel.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>
Subject: RE: [PATCH 2/2] x86/apic: check global clockevent in lapic timer
setup
>
>Wouldn't be better to operate the same way as in case of "noapictimer"
>boot option. I guess the non-pc x86 midplatforms you're mentioning
>do not use SMP ever but just to be consistent in code.
>
[[JPAN]] We do use SMP with hyper threading in Moorestown.
In that case we have a per cpu platform timer without global clockevent.
so i think we don't want the dummy lapic event. we don't want to use the
broadcast mechanism as mentioned in the comments before disabling lapic
timer.
For moorestown, I can use x86_init.timers.setup_percpu_clockev
abstraction function so that Moorestown platform does not need to call
setup_boot_APIC_clock() if per cpu platform timer is used. so many IFs :).
But in the case of having constant and always on LAPIC timer, we still do
not want the dummy lapic clockevent and the broadcast. we will just have
per cpu always on local apic timers without global clockevent device.
>Perhaps something like:
>
>void __init setup_boot_APIC_clock(void) {
>
> if (!global_clock_event) {
> pr_info("No global clockevent for calibration\n");
> disable_apic_timer = 1;
> }
>
> if (disable_apic_timer) {
> pr_info("Disabling APIC timer\n");
> /* No broadcast on UP ! */
> if (num_possible_cpus() > 1) {
> lapic_clockevent.mult = 1;
> setup_APIC_timer();
> }
> return;
> }
>
> ...
>}
>
>Or I miss something?
>
> -- Cyrill
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists