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:09:36 -0700 (MST) To: nate@root.org
In message: <20040127133251.W75080@root.org>
Nate Lawson <nate@root.org> writes:
: On Tue, 27 Jan 2004, M. Warner Losh wrote:
: > In message: <20040127125547.G74774@root.org>
: > Nate Lawson <nate@root.org> writes:
: > : Ok, let me propose a design and I'd appreciate your comments. The probe
: > : routine for acpi_sysresource will stay the same. The attach will allocate
: > : the resources to its parent device (acpi0).
: > :
: > : acpi0 will make this set of resources available to its children via a
: > : flag included with bus_alloc_resource, say ACPIDEV_REQUEST. If
: > : acpi_resource_alloc finds a range already has that flag set, it will
: > : refuse the request. Otherwise, it will release that range and then
: > : immediately allocate it to the child.
: >
: > That seems overly convoluted. Why not just allocate it in acpi0? If
: > a driver requests something that acpi0 has allocated, it assigns it to
: > the child and takes it out of its resource manager. If not, then it
: > passes things up a level in the tree. No special flags needed,
: > although acpi does get a little more complicated. This will ensure
: > that the resources are owned by someone, and can easily be delegated.
: > These resource ranges are there to be used by acpi, and only acpi.
:
: So acpi0 would do a resource_list_delete for the given resource if it's in
: the list and then perform the alloc request. This would then succeed
: since no one owns the resource at that point. Once it succeeds, the child
: owns the range and it can't be stolen. And I guess when the child
: releases the range, acpi0 can reclaim all such resources. I wouldn't want
: a pccard device plugged in later to grab the IO ports after a child
: temporarily releases them (say while the ACPI Performance cpufreq driver
: is unloaded and then reloaded).
Right, that's why it would delegate the resource. This implies that
when the delegation is released, it would go back to being owned by
acpi0.
: > 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.
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
|
|
