Re: newbus ioport usage

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

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

    On Tue, 27 Jan 2004, M. Warner Losh wrote:
    > In message: <20040127141708.O75272@root.org>
    > Nate Lawson <nate@root.org> writes:
    > : > : 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:

    As usual, the devil is in the details. If we want to attach the resources
    first, we must add another namespace walk first. (And while we're at
    that, I'd add another pass to hook up the embedded controller after the
    resources so all other devices if they ignore _REG will still work. I
    think this is needed for some Gateways.) Instead, let's assume we keep
    the current approach to keep this simpler.

    The first step is to move the resource attach code into acpi0. As we walk
    the tree, when we hit a resource object, set the resources and then attach
    them immediately:

    @@ -1035,7 +1040,10 @@
                 * device. Ignore the return value here; it's OK for the
                 * device not to have any resources.
                 */
               acpi_parse_resources(child, handle, &acpi_res_parse_set);
               if (!acpi_disabled("sysresource") &&
                    acpi_MatchHid(dev, "PNP0C02")) {

                    acpi_parse_resources(bus, acpi_get_handle(bus),
                            &acpi_res_parse_set);
                    device_probe_and_attach(bus);
                    continue;
               } else
                    acpi_parse_resources(child, handle, &acpi_res_parse_set);

                /* If we're debugging, probe/attach now rather than later */
                ACPI_DEBUG_EXEC(device_probe_and_attach(child));

    Now acpi0 owns the resources. In acpi_alloc_resource, I
    call resource_list_alloc(). If it returns NULL, then loop through all
    rids, calling resource_list_find() on each. For each that it finds, check
    if rl->start + rl->count overlaps the requested address. If so, free this
    resource via resource_list_free(), call BUS_ALLOC_RESOURCE() for the
    caller's resource, then generate a new resource_list_alloc() for the
    truncated range. This would be unnecessary if we had a way to free a
    partial range of a resource, but it appears this is the only way.

    Thoughts?

    -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
      ... So it makes sense to use the normal device discovery method ... I'm pretty sure there is no other way to know what resources acpi devices ... driver grab whatever is free and then attach the resource pseudo-device ...
      (freebsd-arch)
    • Re: newbus ioport usage
      ... : On Tue, 27 Jan 2004, M. Warner Losh wrote: ... :>: to find these resources. ... I'm pretty sure there is no other way to know what resources acpi devices ... It could then call a private method on its parent ...
      (freebsd-arch)
    • Re: 2 AD domains same physical switches and router ?
      ... Currently the remote sites resources live on our parent companies ... I'm not really wanting to have to put static dns entries onto the ... the workstations and user accounts to be part of your Active Directory ...
      (microsoft.public.windows.server.networking)
    • Re: sub domain
      ... In a Windows 2000 network, parent and child domains have an automatic ... resources in both domains using the user accounts in each. ... assign permissions to the Domain Local group. ... I was going to create groups on the>subdomain and add the users from the parent to that domain. ...
      (microsoft.public.win2000.active_directory)
    • Re: 2 AD domains same physical switches and router ?
      ... Currently the remote sites resources live on our parent companies ... workstations and user accounts to be part of your Active Directory ... Instead of the website you're using, try using OEx (Outlook Express ...
      (microsoft.public.windows.server.networking)