From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 9 17:22:22 2010 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 292911065670 for ; Tue, 9 Feb 2010 17:22:22 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 562DF8FC1B for ; Tue, 9 Feb 2010 17:22:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17246 for ; Tue, 09 Feb 2010 19:22:19 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4B7199CB.1030104@freebsd.org> Date: Tue, 09 Feb 2010 19:22:19 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <4B55B7CF.4080501@freebsd.org> In-Reply-To: <4B55B7CF.4080501@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: acpi_cpu: promote Processor's order 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: Tue, 09 Feb 2010 17:22:22 -0000 Please review the following patch for doing acpu_cpu's probe+attach ealier. There are several arguments in favor of this: 1. Theoretical: it's natural to attach to Processor before any other devices in ACPI namespace, because a processor is a central resource and a root of all action. 2. Practical: there are systems with DSDT defined in such a way that other devices depend on objects that get dynamically loaded (via Load) when Processor control methods are executed (e.g. _PDC/_OSC). Those devices may include devices that are themselves pretty essential to a system, for example, EC. Some links: http://lkml.org/lkml/2009/12/20/146 http://bugzilla.kernel.org/show_bug.cgi?id=14824 http://patchwork.kernel.org/patch/69039/ Of course, there is a reason why we give a low priority to acpi_cpu driver now. (In fact, I remember being somehow involved in that). The drivers on cpu (acpi_cpu) buses (child devices) expect to be probed and attached at the time when some other system resources are already made available, for example, PCI configuration space. So, I think that before proper multi-pass is available, we could use currently available approximation/emulation of multi-pass, that is SYSINIT with order of SI_SUB_CONFIGURE+SI_ORDER_MIDDLE. With that acpu_cpu child devices will be probed around the same time as they do now. Legacy systems (non-ACPI) are not affected by the suggested changes. P.S. Since I mentioned EC, I'd like to add a couple of words on ECDT. Currently we handle ECDT so early that AcpiInstallAddressSpaceHandler wouldn't and shouldn't call _REG method (or any other methods), so this case should not cause problems. And EC device in ACPI namespace would have a later order than Processor, so that's OK too. Index: sys/dev/acpica/acpi.c =================================================================== --- sys/dev/acpica/acpi.c (revision 203670) +++ sys/dev/acpica/acpi.c (working copy) @@ -1685,14 +1685,14 @@ * 100000. CPUs */ AcpiGetType(handle, &type); - if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) + if (type == ACPI_TYPE_PROCESSOR) *order = 1; + else if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02")) + *order = 2; else if (acpi_MatchHid(handle, "PNP0C09")) - *order = 2; + *order = 3; else if (acpi_MatchHid(handle, "PNP0C0F")) - *order = 3; - else if (type == ACPI_TYPE_PROCESSOR) - *order = 100000; + *order = 4; } /* Index: sys/dev/acpica/acpi_cpu.c =================================================================== --- sys/dev/acpica/acpi_cpu.c (revision 203670) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@ -384,13 +384,30 @@ /* Probe for Cx state support. */ acpi_cpu_cx_probe(sc); - /* Finally, call identify and probe/attach for child devices. */ - bus_generic_probe(dev); - bus_generic_attach(dev); - return (0); } +static void +acpi_cpu_postattach(void *unused __unused) +{ + device_t *devices; + int err; + int i, n; + + err = devclass_get_devices(acpi_cpu_devclass, &devices, &n); + if (err != 0) { + printf("devclass_get_devices(acpi_cpu_devclass) failed\n"); + return; + } + for (i = 0; i < n; i++) + bus_generic_probe(devices[i]); + for (i = 0; i < n; i++) + bus_generic_attach(devices[i]); + free(devices, M_TEMP); +} +SYSINIT(acpi_cpu, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE, + acpi_cpu_postattach, NULL); + /* * Disable any entry to the idle function during suspend and re-enable it * during resume. -- Andriy Gapon