All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@linux.intel.com>
To: "Pan, Jacob jun" <jacob.jun.pan@intel.com>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 2/2] x86/apic: check global clockevent in lapic timer setup
Date: Thu, 17 Dec 2009 14:34:24 -0800	[thread overview]
Message-ID: <4B2AB1F0.1020105@linux.intel.com> (raw)
In-Reply-To: <43F901BD926A4E43B106BF17856F07559A257E3D@orsmsx508.amr.corp.intel.com>

On 12/17/2009 02:31 PM, Pan, Jacob jun wrote:
>> 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.

OK, I'm not entirely sure I follow this, and I'm not sure someone trying
to understand the code in five years would, either.  I don't really see
the above translating into "we don't have a global clockevent, therefore
we shouldn't initialize (but should still not disable) the local APIC
timer."

	-hpa

  reply	other threads:[~2009-12-17 22:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-17 17:59 [PATCH 2/2] x86/apic: check global clockevent in lapic timer setup Pan, Jacob jun
2009-12-17 19:41 ` Cyrill Gorcunov
2009-12-17 22:31   ` Pan, Jacob jun
2009-12-17 22:34     ` H. Peter Anvin [this message]
2009-12-18  1:14       ` Pan, Jacob jun
2009-12-18 16:35         ` Thomas Gleixner
2009-12-18 18:13           ` Pan, Jacob jun
2009-12-18 22:44             ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B2AB1F0.1020105@linux.intel.com \
    --to=hpa@linux.intel.com \
    --cc=gorcunov@gmail.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.