From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754835AbdARLKT (ORCPT ); Wed, 18 Jan 2017 06:10:19 -0500 Received: from mga14.intel.com ([192.55.52.115]:48304 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754824AbdARLKR (ORCPT ); Wed, 18 Jan 2017 06:10:17 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,249,1477983600"; d="scan'208";a="32095821" Message-ID: <1484736987.2133.188.camel@linux.intel.com> Subject: Re: [PATCH v2 1/1] x86/rtc: Allocate interrupt for platform device From: Andy Shevchenko To: Thomas Gleixner Cc: "Luis R. Rodriguez" , Ingo Molnar , "H . Peter Anvin" , linux-kernel@vger.kernel.org, x86@kernel.org Date: Wed, 18 Jan 2017 12:56:27 +0200 In-Reply-To: References: <20170116172345.3823-1-andriy.shevchenko@linux.intel.com> <20170116190437.GB13946@wotan.suse.de> <1484594499.2133.159.camel@linux.intel.com> <1484660404.2133.170.camel@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2017-01-18 at 11:24 +0100, Thomas Gleixner wrote: > On Tue, 17 Jan 2017, Andy Shevchenko wrote: > > > On Mon, 2017-01-16 at 22:00 +0100, Thomas Gleixner wrote: > > > > > The early callback does not work, but we have one which is invoked > > > later > > > on: x86_init.wallclock_init(). That's invoked after the (IO/APIC) > > > setup has > > > been completed. See patch below. > > > > Unfortunately it is till too early. Looks like descriptors are not > > available yet and we still can't get an allocation: > > > > [    0.000000] intel_mid: Failed to allocate RTC interrupt. > > Disabling > > RTC > > > > ... > > > > [    0.000000] NR_IRQS:4352 nr_irqs:512 0 > > Indeed. Did not think about that we need the irq subsystem up not only > the > primary IOAPIC init done. > > Looking deeper it's actually simple. MID already overloads the > timer_init() > setup function. So we can just do it there. Yes, it does. However I have another solution, just would like to discuss. There is a timekeeping_init() call, which is a first user of the RTC. I have 3 changes: - introduce arch_pre_timekeeping_init() and move wallclock_init() call there - use almost your initial suggestion - move wallclock_init() to x86_platform and rename to init_wallclock() to be consistent with the rest of wallclock API (this, though, has item to discuss, i.e. __init use for callbacks) This would allow to clearly initialize virtual RTC or legacy one at the same know point. What do you think? Should I send a series for review? -- Andy Shevchenko Intel Finland Oy