From owner-freebsd-acpi@FreeBSD.ORG Tue Jun 1 15:35:27 2004 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F00F16A4CE; Tue, 1 Jun 2004 15:35:27 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24EC243D48; Tue, 1 Jun 2004 15:35:27 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i51MXF3D016677; Tue, 1 Jun 2004 16:33:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jun 2004 16:33:16 -0600 (MDT) Message-Id: <20040601.163316.88476133.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20040601221109.GA21063@ns1.xcllnt.net> References: <20040601141424.I29932@root.org> <200406011742.57991.jhb@FreeBSD.org> <20040601221109.GA21063@ns1.xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-acpi@FreeBSD.ORG cc: jhb@FreeBSD.ORG Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 22:35:27 -0000 In message: <20040601221109.GA21063@ns1.xcllnt.net> Marcel Moolenaar writes: : On Tue, Jun 01, 2004 at 05:42:57PM -0400, John Baldwin wrote: : > > > > > I need the patch below in order to turn on bus_config_intr() when : > > > > > using the I/O APICs. : *snip* : > > > > I appreciate what you're trying to do but I don't like this approach. : *snip* : > > > Well, arguably it exposes an improper layering violation when : > > > bus_config_intr() was added. : *snip* : > > I still don't like this. : *snip* : > FreeBSD has no format for this and I don't really have time to add multiple : > resource types (which is what ACPI does, and probably what we will need to do : > eventually) to struct resource. : : Ok, let's relax for a minute. Clearly, the addition of bus_config_intr() : was done in a biggest-bang-for-the-buck approach and I think we can : assume for now that it's there in a way that isn't easily extensible. : : So, the root problem now is that we need to consume the ACPI info in : a way that makes it available for later use, i.e., when we actually : allocate the IRQ resource. The solution needs to be simple so that : jhb@ can close the immediate problem and it should also be a step in : the right direction, or at least not a step in the opposite direction, : so that njl@ doesn't get cornered by it at some later time. : : Let me give the numbers: : o We need 2 bits for the polarity, : o We need 2 bits for the trigger mode, : o r_flags is 32 bits of which only 16 are in use. : : Can we not stick the IRQ properties in r_flags, just like we : stick the alignment properties there, remove bus_config_intr() : and make sure the MD backend queries the flags for polarity and : trigger (0 values will mean "default" and thus preserve backward : compatibility)? : : This change should only affect 2 places: the place where we set : the resource and the place where we actually install the interrupt : and its handler. It's roughly in line with what jhb@ wants to achieve : and I think it removes the code that njl@ is objecting to the most, : right? : : Oh, and it's not intended to be pretty. I like it. Or should I say "Given that we're looking for an evolutionary change to shoe horn this in, I think it is better than any of the other ugly kludges." Warner