Date: Fri, 4 Jun 2004 09:45:56 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-acpi@FreeBSD.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. Message-ID: <200406040945.56645.jhb@FreeBSD.org> In-Reply-To: <20040603104616.I43856@root.org> References: <20040601141424.I29932@root.org> <200406030917.36901.jhb@FreeBSD.org> <20040603104616.I43856@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 03 June 2004 01:54 pm, Nate Lawson wrote: > On Thu, 3 Jun 2004, John Baldwin wrote: > > On Wednesday 02 June 2004 07:27 pm, Nate Lawson wrote: > > > On Wed, 2 Jun 2004, John Baldwin wrote: > > > > Ok, summary of PITAs after an hour or so of looking into it: > > > > > > I appreciate your efforts. Just to recap, we're trying to work around > > > an API design problem with bus_config_intr(). > > > > Well, it depends. See, using the existing API, I can make it work now > > with a small change. Here's some more food for thought. Specifically we > > are dealing with properties of an IRQ resource, correct? Now, the flags > > in struct resource now are provided by the driver as part of the request > > (align to this many bytes, I want it to be prefetchable, etc.). The > > properties of the actual hardware interrupt line are _not_ provided by > > the driver, but by the firmware. Now, what's another attribute about an > > IRQ resource that is provided by the firmware/BIOS. PCI interrupt > > routing! Yes, and where do we go ask the firmware for that information? > > bus_alloc_resource! So, we have a working model now. > > Except we already have the special bus_setup_intr() and bus_config_intr() > methods in addition to bus_alloc_resource() and bus_activate_resource(). > This indicates that a more general method is needed (bus_config_resource?) > between alloc/activate to set any special options, properties, etc. It > could just have a (void *) argument that is interpreted by the bus method > in any way it wants. This could also allow someone to reconfigure > resources by deactivating them, configuring them, then reactivating them. Yes, whatever model we go with, setup_intr/teardown_intr() need to die. I think that the nexus drivers should setup interrupt handlers when an IRQ resource is activated (done automatically during a RF_ACTIVE bus_alloc_resource()). It seems we have a few different types of meta-data associated with a resource: 1) Data that the device driver provides (for example, alignment of memory, whether or not memory is prefetchable, interrupt routine and argument) 2) Data that the firmware provides (PCI interrupt routing, interrupt properties (trigger/polarity). The bus driver provides this. Right now our current model is to use flags to bus_alloc_resource() for 1) with a hack for interrupt handler variables and to do 2) during bus_alloc_resource()'s implementation. If a bus wants to cache data for 2) earlier than bus_alloc_resource(), it can either provide its own method of doing this (this is what my patch does for ACPI by using _CRS as the cache) or we can try to push the data down into the resource list. We need a better solution for 1) though. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200406040945.56645.jhb>