Re: newbus ioport usage
From: M. Warner Losh (imp_at_bsdimp.com)
Date: 01/27/04
- Previous message: Mike Smith: "Re: newbus ioport usage"
- In reply to: Mike Smith: "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 03:21:19 -0700 (MST) To: msmith@freebsd.org
In message: <E4469364-5092-11D8-8DD8-000393C72BD6@freebsd.org>
Mike Smith <msmith@freebsd.org> writes:
: The whole reason for the sysresource device was to have something
: sitting on resources that the AML said had "something" behind them
: so that they didn't get handed out to devices on eg. PCI. If you're
: in the same sort of scope as the sysresource device, it's fair to
: say that you know more than eg. the PCI bus resource code does about
: whether you can use the resource in question.
Yes. It is a form of resource enumeration that belongs to ACPI.
Therefore, ACPI should manage it and dole it out to its children which
are based on the AML. That's what it is there for. It is akin to the
PCI code assigning resources based on the BARs that a child has.
However, only akin, because the entire resource space is enumerated in
the bus, not the children, for ACPI. The sysresource stuff was a
means to an end, not the only way to that end. I'm starting to think
that the right way to go is to reserve EVERYTHING up front, and then
have all the acpi_foo devices allocate out of that reserveation.
In this way it is similar to a BAR that has been assigned by the BIOS,
but isn't allocated by a child device on pci. In the code I'm working
on, those resources are reserved at the bus level and given to the
child if it asks for it later. Well, it is a little more complex than
that because the child device actually owns the resource, but the bus
is who assigns ownership. In ACPI, since the resource maps aren't
child specific, the ownership should resided in the bus layer. So
instead of belonging to acpi_sysresource0, it would belong to acpi0.
This may also help some downstream resource allocations, since they
would now be happening a little earlier in the game.
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: Mike Smith: "Re: newbus ioport usage"
- In reply to: Mike Smith: "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
- Re: newbus ioport usage
... :>: whether you can use the resource in question. ... It is a form of resource
enumeration that belongs to ACPI. ... :> PCI code assigning resources based on the BARs
that a child has. ... :> have all the acpi_foo devices allocate out of that reserveation.
... (freebsd-arch) - Re: newbus ioport usage
... whether you can use the resource in question. ... > PCI code assigning resources
based on the BARs that a child has. ... > the bus, not the children, for ACPI.
... > have all the acpi_foo devices allocate out of that reserveation. ... (freebsd-arch) - Re: newbus ioport usage
... Why not just allocate it in acpi0? ... > the child and takes it out
of its resource manager. ... > These resource ranges are there to be used by acpi,
... (freebsd-arch) - Re: newbus ioport usage
... :>: immediately allocate it to the child. ... Why not just allocate it in
acpi0? ... :> the child and takes it out of its resource manager. ...
:> These resource ranges are there to be used by acpi, ... (freebsd-arch) - Re: [Pcihpd-discuss] Re: ACPI problem with PCI Express Native Hot-plug driver
... system has two hot-pluggable PCI Express slots). ... PCI bus 0x0 Resource
structure 0. ... Resource Type: Bus Number Range ... pciehp_save_config: In
do loop ... (Linux-Kernel)