From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753412AbdARQdq (ORCPT ); Wed, 18 Jan 2017 11:33:46 -0500 Received: from mga06.intel.com ([134.134.136.31]:3299 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751482AbdARQdo (ORCPT ); Wed, 18 Jan 2017 11:33:44 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,249,1477983600"; d="scan'208";a="214861774" Message-ID: <1484756950.2133.211.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 18:29:10 +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. Still too early. There is kernel_init() thread which initializes IO-APIC IRQs AFAIU. Neither mine, nor your solution would work. [    0.000000] NR_IRQS:4352 nr_irqs:512 0 [    0.000000] intel_mid: Failed to allocate RTC interrupt. Disabling RTC [    0.105359] ENABLING IO-APIC IRQs I see this one, not sure if it's correct path kernel_init() ->  kernel_init_freeable() -> smp_prepare_cpus() / native_smp_prepare_cpus() -> apic_bsp_setup() -> setup_IO_APIC() So, fixing in rtc.c seems now more reasonable (we may get rid of ugly #ifdef:s by providing stubs in IOAPIC code). Another variant is to use just a separate callback on arch_initcall(). It would be closer to current solution. If you have something better to try, please tell, I would test it. >  static void __init intel_mid_time_init(void) >  { >   sfi_table_parse(SFI_SIG_MTMR, NULL, NULL, sfi_parse_mtmr); > > + > + /* If the platform has an RTC make sure the APIC entry is > allocated */ > + if (x86_platform.legacy.rtc) > + intel_mid_legacy_rtc_init(); Just in case this should be first call in the function, otherwise it never been called. -- Andy Shevchenko Intel Finland Oy