Date: Wed, 02 Jun 2004 18:08:19 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: nate@root.org Cc: freebsd-acpi@freebsd.org Subject: Re: Patch: Defer bus_config_intr() until bus_alloc_resource().. Message-ID: <20040602.180819.122454942.imp@bsdimp.com> In-Reply-To: <20040602160338.T38138@root.org> References: <20040601.163316.88476133.imp@bsdimp.com> <200406021358.17521.jhb@FreeBSD.org> <20040602160338.T38138@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040602160338.T38138@root.org>
Nate Lawson <nate@root.org> writes:
: > - For the PIC mode on i386, we use bus_config_intr() after bus_setup_intr() to
: > set the interrupt to level/low. This can be worked around by deferring
: > handler setup until after acpica_machdep_init() and calling
: > AcpiEnableSubsystem() twice.
: > - There is no way (currently) to get a pointer to the resource structure
: > associated with rid X w/o calling bus_alloc_resource(). In fact, there is
: > no resource structure in which to place the IRQ configuration flags until
: > bus_alloc_resource(), thus for the bus_config_intr() that sets the mode for
: > the SCI for PIC mode above there is no resource (once you defer the
: > interrupt setup) and for all of the resources set via bus_set_resource() in
: > acpi_parse_resources() there is no resource to set the flags in, so that
: > info is lost unless we also hack on the resource list items to add flag
: > members and change that API to allow for flags to be passed around.
:
: How about adding bus_{get,set}_resource_flags(dev, int rid, int flags) and
: adding an "int flags" field to struct resource_list_entry? Or break the
: API now and add flags to the normal bus_{get,set}_resource(). This is
: going to be needed for other resource types in the future that have modes.
What sort of resources have modes (apart from the polarity of
interrupts)? What does the 'flags' mean? Who is allowed to set it?
It would likely be better to have an API that allows mutliple parties
to set it. The PCI bus code sets the IRQ number or requests the
higher level nodes in the device tree to route an interrupt for it,
which it then sets. The ordering is not quite right to allow for the
flags to be set in the initial bus_set_resource. The interrupt
routing things also tend to not have good knowledge of who the
appropriate ultimate customer of the interrupt is as well. So there
are problems down this path as well.
I know there is prefechtable vs non-prefetchable memory. However,
that is allocated in a different way (they come out of different pools
at the bridge level). Interrupts come from a common pool and it is
how they are configured that is magic.
: > I really don't want to spend a lot of time implementing all this. Does
: > somebody else want to do this? The change I posted earlier is a _lot_
: > simpler and smaller.
:
: Just because bus_config_intr doesn't have a counterpart for storing the
: config doesn't mean the right thing to do is to force every user of it to
: re-parse/fetch the settings they already set. I understand this is a pain
: but the time to contain the damage is now rather than letting it spread
: more.
Not necessarily true. It may be better to deal with this in an ad-hoc
way now to make progress and deal with the resource model short
comings in the future. Especially given how close we are to the 5.x
branch point. It might make good sense to have an expedient fix as
well as a long term plan.
The bigger problem is that interrupts are an afterthough in our
resource allocation mechanism. They just barely fit into the scheme
we have now, and not very well. Two step allocation/activation is
different than other resources (since you have to give an ISR rather
than just calling bus_activiate_resource). Forcing all resources to
behave like interrupts so we can use the common underlying mechanism
might not be the right thing either.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040602.180819.122454942.imp>