Re: newbus ioport usage

From: Nate Lawson (nate_at_root.org)
Date: 01/27/04

  • Next message: M. Warner Losh: "Re: newbus ioport usage" 
    Date: Tue, 27 Jan 2004 13:05:08 -0800 (PST)
To: "M. Warner Losh" <imp@bsdimp.com>

    On Tue, 27 Jan 2004, M. Warner Losh wrote:
    > 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.

    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.

    -Nate
    _______________________________________________
    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"

  • Next message: M. Warner Losh: "Re: newbus ioport usage"

    Relevant Pages