From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:04:29 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DF516A46C for ; Wed, 3 Oct 2007 16:04:29 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 594FC13C4A7 for ; Wed, 3 Oct 2007 16:04:28 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 4142 invoked from network); 3 Oct 2007 16:04:29 -0000 Received: from ppp-71-139-1-224.dsl.snfc21.pacbell.net (HELO ?10.0.0.15?) (nate-mail@71.139.1.224) by root.org with ESMTPA; 3 Oct 2007 16:04:29 -0000 Message-ID: <4703BD8D.1080501@root.org> Date: Wed, 03 Oct 2007 09:04:29 -0700 From: Nate Lawson User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jung-uk Kim References: <470002B5.6030002@root.org> <200710031138.28820.jkim@FreeBSD.org> In-Reply-To: <200710031138.28820.jkim@FreeBSD.org> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: patch: change in acpi taskq behavior X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2007 16:04:29 -0000 Jung-uk Kim wrote: > On Sunday 30 September 2007 04:10 pm, Nate Lawson wrote: >> Attached is a patch (one for 6, one for 7) that shouldn't break >> anything for most people and may fix some battery status issues for >> others. It changes how we run tasks during boot. It seems some >> hardware expects synchronous access but our taskq is not running >> until after interrupts are enabled. This patch bounces calls >> through a wrapper that executes the callback directly if we're not >> booted yet. > > Sorry, I didn't test it but I have some questions. Why do you add a > wrapper and pollute all AcpiOsQueueForExecution()/AcpiOsExecute() > consumers? Isn't it more simpler to let the function determine to > queue or not to queue? Why do you check cold and rebooting flags? > If you wanted to check the taskqueue is ready, you could check > taskqueue_acpi is NULL or not, instead. There are 2 different behaviors I'm trying to support and only the caller knows which one they want: 1. Run a task at some point in the future but "soon" 2. Queue a task to be run, definitely after boot is complete Notifies are in the first class. Initialization functions for the various drivers are in the second. ACPI-CA is moving to making all Notifies completely synchronous (i.e. they wait for the thread to run). So if we go to the model you describe (#1), this will work but suddenly the initialization of the drivers won't wait for boot. It will be run right away. -- Nate