From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754011AbbCDFJF (ORCPT ); Wed, 4 Mar 2015 00:09:05 -0500 Received: from mail-wg0-f41.google.com ([74.125.82.41]:40190 "EHLO mail-wg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751441AbbCDFJD (ORCPT ); Wed, 4 Mar 2015 00:09:03 -0500 Date: Wed, 4 Mar 2015 06:08:58 +0100 From: Ingo Molnar To: "Li, Aubrey" Cc: "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , arjan@linux.intel.com, "Rafael J. Wysocki" , Len.Brown@intel.com, x86@kernel.org, LKML Subject: Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform Message-ID: <20150304050858.GB5158@gmail.com> References: <54F67ACC.3010500@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F67ACC.3010500@linux.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Li, Aubrey wrote: > On ACPI hardware reduced platform, the legacy PIC and PIT may not be > initialized even though they may be present in silicon. Touching > these legacy components causes unexpected result on system. > > On Bay Trail-T(ASUS-T100) platform, touching these legacy components > blocks platform hardware low idle power state(S0ix) during system suspend. > So we should bypass them on ACPI hardware reduced platform. > > Suggested-by: Arjan van de Ven > Signed-off-by: Li Aubrey > Cc: Len Brown > Cc: Rafael J. Wysocki > --- > arch/x86/kernel/irqinit.c | 6 +++++- > arch/x86/kernel/time.c | 3 ++- > 2 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kernel/irqinit.c b/arch/x86/kernel/irqinit.c > index 70e181e..9a64cc3 100644 > --- a/arch/x86/kernel/irqinit.c > +++ b/arch/x86/kernel/irqinit.c > @@ -75,7 +75,11 @@ void __init init_ISA_irqs(void) > #if defined(CONFIG_X86_64) || defined(CONFIG_X86_LOCAL_APIC) > init_bsp_APIC(); > #endif > - legacy_pic->init(0); > + if (acpi_gbl_reduced_hardware) { > + pr_info("Using NULL legacy PIC\n"); > + legacy_pic = &null_legacy_pic; > + } else > + legacy_pic->init(0); > > for (i = 0; i < nr_legacy_irqs(); i++) > irq_set_chip_and_handler(i, chip, handle_level_irq); > diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c > index 25adc0e..5ba94fa 100644 > --- a/arch/x86/kernel/time.c > +++ b/arch/x86/kernel/time.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -76,7 +77,7 @@ void __init setup_default_timer_irq(void) > /* Default timer init function */ > void __init hpet_time_init(void) > { > - if (!hpet_enable()) > + if (!hpet_enable() && !acpi_gbl_reduced_hardware) > setup_pit_timer(); > setup_default_timer_irq(); > } So the whole acpi_gbl_reduced_hardware flaggery sucks as it mixes various hardware drivers that have little relation to each other... Instead of having a proper platform init this flag hooks into various drivers and generic code, such as the efi reboot and shutdown code, and now the generic irq init code. For this IRQ init problem, why not add a proper callback to x86_platform_ops, define your own IRQ init function, initialize it in your platform init sequence and let it be called? That solves it without creating an ugly mix of different platform methods. For the EFI shutdown case, what's wrong with setting your own pm_power_off handler like most of the other platforms are doing? Plus the EFI code in drivers/firmware/efi/reboot.c should probably only set the shutdown handler if pm_power_off is still NULL. Thanks, Ingo