From mboxrd@z Thu Jan 1 00:00:00 1970 From: Len Brown Subject: Re: [PATCH] ACPI: create "processor.bm_check_disable" boot param Date: Mon, 26 Jul 2010 20:19:10 -0400 (EDT) Message-ID: References: <20100427124703.GA16706@jgarrett.org> <20100430174447.GA14889@srcf.ucam.org> <20100525124325.GC7876@srcf.ucam.org> <20100525185507.GA15997@srcf.ucam.org> <20100722074750.GA22520@one.firstfloor.org> <87k4oiiu3x.fsf@basil.nowhere.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-path: In-reply-to: <87k4oiiu3x.fsf@basil.nowhere.org> Sender: linux-kernel-owner@vger.kernel.org To: Andi Kleen Cc: Matthew Garrett , "Yu, Luming" , Philip Langdale , Jeff Garrett , Linux Kernel Mailing List , "linux-acpi@vger.kernel.org" , "venki@google.com" List-Id: linux-acpi@vger.kernel.org > > Note also that an alternative for newer systems > > is to use the intel_idle driver, which always > > ignores BM_STS, relying Linux device drivers > > to register constraints explicitly via PM_QOS. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=15886 > > Thanks. I don't fully understand why the check for this option > is in a different place than the register check in the earlier patch? Technically, it could have been. There are a comple of constraints in the layout of this code. The _CST flag is x86 (actually Intel) specific -- so the detection went into arch/x86/kernel/acpi/cstate.c However, the operation of the that flag is per C-state, not necessarily per system -- so we remember the flag in in a cx->bm_sts_skip flag and check it in the 'acpi generic' drivers/acpi/processor_idle.c But we can't test a per cx flag inside acpi_idle_bm_check() because it doesn't have access to the cx, so i put that test at the site of its only caller. In this 2nd patch... we added a 'generic' ACPI bootparam that applies to all C-states. So it overrides any per-cstate flag and it is static to the processor_idle.c file, so it seemed cleanest (to me) to push it down inside acpi_idle_bm_check() rather than in its only caller. > This needs to be also documented in Documentation/kernel-parameters.txt I thought about that and decided against it. While we do document some driver specific modparams in kernel-parameters.txt, I do not expect this one to be used that often -- mostly for diagnosis of BIOS bugs. I know of two machines that need it, and both of those machines have a BIOS update or a BIOS update in progress that make it unnecessary. thanks for caring. Len Brown, Intel Open Source Technology Center.