From owner-freebsd-acpi@FreeBSD.ORG Wed Feb 27 07:54:53 2008 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94BE5106566B; Wed, 27 Feb 2008 07:54:53 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2D413C43E; Wed, 27 Feb 2008 07:54:52 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7C14343E2B9; Wed, 27 Feb 2008 09:54:50 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8gobYn4SFVPX; Wed, 27 Feb 2008 09:54:50 +0200 (EET) Received: from [91.193.172.111] (unknown [91.193.172.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 3158543E252; Wed, 27 Feb 2008 09:54:49 +0200 (EET) Message-ID: <47C5173E.40207@icyb.net.ua> Date: Wed, 27 Feb 2008 09:54:38 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: Nate Lawson References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> <47C30201.3060501@root.org> <47C32D3C.2020205@icyb.net.ua> In-Reply-To: <47C32D3C.2020205@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 07:54:53 -0000 on 25/02/2008 23:03 Andriy Gapon said the following: > Nate, > these are very good points. It seems that I wrote something very > specific to my case and didn't consider other scenarios. I completely > forgot about SMP case. > I need to think more about this. > A possible blanket solution would be to probe/attach all and any cpu > child devices after pci bus is attached. But I don't know if this is a > viable solution in general and if it's possible to implement at all. I looked through some code while pursuing the above idea. Of course, things are more complicated if one has to consider legacy scenarios (no ACPI) too, but for the scope of this issue I sticked to the case when ACPI is available. It seems that children of acpi are added in acpi_probe_children function. First we walk over all devices declared in DSDT and create child devices for those that are interesting to us. AcpiWalkNamespace with acpi_probe_child is used for that. When we call BUS_ADD_CHILD for a device we typically specify an order value based on a device's level/depth. For some special devices we set specific (early) order value in acpi_probe_order (based on HID). Then we add devices that are not auto-detected but rather add themselves via device_identify method. Then we perform probe and attach for all added devices via bus_generic_attach, and the devices are probed and attached according to their 'order' attribute. >From this, my conclusion is that relative order of cpu and pci bridge is generally undetermined in this case. This is because neither of them has a specific order assigned. So their order depends on their level and, well, order in DSDT. Typically, processor would have a smaller or equal level compared to host-pci bridge. In my particular case I believe that the levels are the same: \_PR_.CPU0 \_SB_.PCI0 And processor appears earlier in DSDT, so they both have the same order value but processor is added earlier. Another thing is that acpi_cpu and acpi_pcib_acpi (using their "full names") are the buses themselves, so they identify/probe/attach their children in their attach methods. Thus, whichever has earlier order will also probe and attach (all of) its children earlier. So what I am getting at - it is certainly not hard to make acpi_pcib_acpi (and consecutively pci) be attached earlier than acpi_cpu. All is needed is to add another special case in acpi_probe_order after the existing ones, I actually did it as an experiment: else if (acpi_MatchHid(handle, "PNP0A03")) *order = 4; This worked for me as expected and without any side effects. But I have a big concern about whether we have any devices/drivers that rely on a current typical order. That is, drivers that expect cpu device/bus to be already probed and attached at the time when probe/attach is called for something on pci bus. I guess one example here is famous ichss that adds a child to cpu bus in its pci probe routine, and calls device_probe_and_attach for it in the same place too. I guess that while BUS_ADD_CHILD should work at that place, device_probe_and_attach may not because cpu itself is not probed and attached yet. On the other hand, as I said in the beginning, I think that even now there are no strict guarantees about the order, it just happens to work. Anyway, I am not sure if the discussed change in ordering has any merit. It seems that whatever the order it would be convenient in some places and inconvenient in others, so some jumping through the hoops is inevitable. I wonder if it would be possible to create some mechanism for attaching "important" devices first and then the rest later. E.g. cpu and pcib+pci are attached first (in whatever order), then their children are attached later (in whatever order). What is important is that all those "late" children can expect both cpu and pci to be fully available. P.S. sorry for high-jacking a topic, an unrelated question: shouldn't ISA PnP devices get configured (assigned resources) before any PCI devices ? http://docs.FreeBSD.org/cgi/mid.cgi?47C338D5.2080906 -- Andriy Gapon