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:40:18 -0800 (PST)
    To: "M. Warner Losh" <imp@bsdimp.com>
    
    

    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).

    > 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.

    -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

    • 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
      ... :>: 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: page fault panic in device_get_softc/acpi_pcib_route_interrupt
      ... ACPI APIC Table: ... acpi0: on motherboard ... adding child \_PR_.CPU1, dev 0 ...
      (freebsd-current)
    • Re: How to disable ACPI in 5.3
      ... > nothing in my kernelconfig indicates that ACPI is enabled. ... looks like you have 'device acpi' in your kernel config. ... that ACPI is enabled is to look for an acpi0 in your dmesg. ... If it is a child of legacy0, ...
      (freebsd-current)
    • git pull request on Linux/ACPI release tree
      ... This updates the ACPICA core interpreter to the latest, ... A key fix is for bugzilla 5483 where Linux now tells the ... [ACPI] ... enable PNPACPI support for resource types used by HP serial ...
      (Linux-Kernel)