Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759972AbZFIMuH (ORCPT ); Tue, 9 Jun 2009 08:50:07 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753927AbZFIMt6 (ORCPT ); Tue, 9 Jun 2009 08:49:58 -0400 Received: from mga01.intel.com ([192.55.52.88]:44736 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753243AbZFIMt5 convert rfc822-to-8bit (ORCPT ); Tue, 9 Jun 2009 08:49:57 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,331,1241420400"; d="scan'208";a="697763080" From: "Pan, Jacob jun" To: Thomas Gleixner CC: "Tang, Feng" , "mingo@elte.hu" , "linux-kernel@vger.kernel.org" , "Li, Shaohua" Date: Tue, 9 Jun 2009 05:49:58 -0700 Subject: RE: [PATCH] tick: add check for the existence of broadcast clock event device Thread-Topic: [PATCH] tick: add check for the existence of broadcast clock event device Thread-Index: Acno2vfz7sldVO0vQnqWli+mtrNYggAJVqJg Message-ID: <43F901BD926A4E43B106BF17856F075563408766@orsmsx508.amr.corp.intel.com> References: <20090605112711.67e7d5cb@feng-desktop> <20090606204736.00700bd0@feng-desktop> <20090608095730.0c945e78@feng-desktop> <20090608141250.6a5735fa@feng-desktop> <20090608144740.62f2ed95@feng-desktop> <43F901BD926A4E43B106BF17856F07556340868E@orsmsx508.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2561 Lines: 58 Thanks for the explanations, I will add the secondary clock code to the x86_quirks. It should be submitted for review soon. Jacob >-----Original Message----- >From: Thomas Gleixner [mailto:tglx@linutronix.de] >Sent: Tuesday, June 09, 2009 1:19 AM >To: Pan, Jacob jun >Cc: Tang, Feng; mingo@elte.hu; linux-kernel@vger.kernel.org; Li, Shaohua >Subject: RE: [PATCH] tick: add check for the existence of broadcast clock event >device > >On Mon, 8 Jun 2009, Pan, Jacob jun wrote: >> >I understand that, but HPET does not rely on some magic events >> >happening. That's what I'm worried about. The boot code is fragile and >> >I prefer some explicit setup call over a fragile solution which >> >happens to work. >> > >> >There is not much to complain about a platform specific function call >> >to set up special devices if there is a requirement for a call order. >> > >> >In fact you can avoid setting up the local APIC timer at all. So what >> >you want is something like the patch below. You can set the >> >setup_secondary_clock pointer in the quirks structure when you detect >> >that you are running on such a system. >> > > >> [[JPAN]] Hi Thomas, I have been developing the APB timer driver as >> Feng mentioned, thank you for the suggestions. I agree with you >> that direct setting up secondary clockevent is a better solution. >> But maybe I misunderstand the HPET code, isn't it true that per CPU >> HPET timer also rely on IPI? In hpet_cpuhp_notify(). > >Well the difference is, that the HPET setup always has a functional >clock event device (local APIC + the broadcast fallback) and it does >not depend on that IPI to make progress. > >> Also for using x86_quirks, I think the default quirks are more >> generic in the sense of x86 platform, but here we are really >> choosing timer device, so can we switch based on availability of the >> timer devices instead of quirks? Otherwise, if more platforms share >> the same setup_secondary_clock() quirk, we would have to check for >> timer devices anyway. > >The quirks mechanism is exactly the right thing. It provides platforms >and I consider your system a platform which has neither PIT nor HPET a >mechanism to override the default implementation. And overriding the >default local APIC timer setup is exaclty what you want to do. > >Thanks, > > tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/