Re: newbus ioport usage
From: M. Warner Losh (imp_at_bsdimp.com)
Date: 01/27/04
- Previous message: Nate Lawson: "Re: newbus ioport usage"
- In reply to: Nate Lawson: "Re: newbus ioport usage"
- Next in thread: Nate Lawson: "Re: newbus ioport usage"
- Reply: Nate Lawson: "Re: newbus ioport usage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 27 Jan 2004 15:31:20 -0700 (MST) To: nate@root.org
In message: <20040127141708.O75272@root.org>
Nate Lawson <nate@root.org> writes:
: On Tue, 27 Jan 2004, M. Warner Losh wrote:
: > In message: <20040127133251.W75080@root.org>
: > Nate Lawson <nate@root.org> writes:
: > : > There's nothing magical about the acpi_sysresource device, and it can
: > : > be relegated to the scrap-heap of history if needed.
: > :
: > : Well, the way we find out about the resources is through a pseudo-device
: > : with a PNPID. So it makes sense to use the normal device discovery method
: > : to find these resources. This leads me to do the allocation for the
: > : parent by the acpi_sysresource0 attach method.
: >
: > This gets ugly. The reason that I suggested not doing the discovery
: > this way is because you want to allocate *ALL* resources up front
: > before giving any to any children. pci has issues with this right now
: > that I'm working to fix.
:
: I'm pretty sure there is no other way to know what resources acpi devices
: will be using without evaluating the resource pseudo-device. The other
: way (which we currently do) is assume everything is available and let each
: driver grab whatever is free and then attach the resource pseudo-device
: last to claim all remaining acpi resources. Unless you have a better
: idea, the short-term approach will not change any of the above. It will
: just add the ability for acpi devices to later reclaim resources from
: acpi0 (by having acpi_sysresource0 attach remaining resources to its
: parent).
You could add acpi_sysresource as the first child, which would get
around the issues. It could then call a private method on its parent
to give it the resources. But why couldn't that code be moved up into
parent? I guess I'm not understanding the difficulty here, because
right now there's only one sysresource, and it does:
static int
acpi_sysresource_probe(device_t dev)
{
if (!acpi_disabled("sysresource") && acpi_MatchHid(dev, "PNP0C02"))
device_set_desc(dev, "System Resource");
else
return (ENXIO);
device_quiet(dev);
return (-100);
}
static int
acpi_sysresource_attach(device_t dev)
{
struct resource *res;
int i, rid;
/*
* Suck up all the resources that might have been assigned to us.
* Note that it's impossible to tell the difference between a
* resource that someone else has claimed, and one that doesn't
* exist.
*/
for (i = 0; i < 100; i++) {
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, 0, ~0, 1, 0);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0, ~0, 1,
RF_SHAREABLE);
}
return (0);
}
I'm not sure that I see.
: Allocating all resources up front would require multiple passes of the
: namespace and I'm not ready to make that drastic of a change without some
: more design work about how this fits in with the rest of FreeBSD (in
: particular, PCI).
Yes. We do need to redesign the probe/attach code to have multiple
passes.
Warner
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Nate Lawson: "Re: newbus ioport usage"
- In reply to: Nate Lawson: "Re: newbus ioport usage"
- Next in thread: Nate Lawson: "Re: newbus ioport usage"
- Reply: Nate Lawson: "Re: newbus ioport usage"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
