From owner-freebsd-acpi@FreeBSD.ORG Fri Jun 22 07:24:24 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 838EA106566C; Fri, 22 Jun 2012 07:24:24 +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 9C1AA8FC0C; Fri, 22 Jun 2012 07:24:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA17418; Fri, 22 Jun 2012 10:24:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ShyDz-000MYC-AA; Fri, 22 Jun 2012 10:24:11 +0300 Message-ID: <4FE41D9A.4080008@FreeBSD.org> Date: Fri, 22 Jun 2012 10:24:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Sean Bruno References: <1340121728.5203.8.camel@powernoodle> <1340210648.2858.9.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1340210648.2858.9.camel@powernoodle.corp.yahoo.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "sbruno@freebsd.org" , "freebsd-acpi@freebsd.org" Subject: Re: [CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing. 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: Fri, 22 Jun 2012 07:24:24 -0000 on 20/06/2012 19:44 Sean Bruno said the following: > On Tue, 2012-06-19 at 09:02 -0700, Sean Bruno wrote: >> http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt > > also, I wanted to point out that I'm returning BUS_PROBE_GENERIC here. > > I want to emulate the Intel acpi_idle code that exists in linux-land and > I *thought* that I could setup an acpi_cpu_idle module that would come > in at a higher priority on Intel cpus, however there's some SYSINIT() > hackery going on that I don't know how to handle gracefully. I'm not > sure how to proceed with a different idle module here. thoughts? > > e.g. > > 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); > > Just a little bit of explanation for the code. acpi_cpu driver is attached very early because it does some ACPI configuration in its attach method (_OSC/_PDC calls) and correct behavior of other ACPI drivers may depend on this. On the other hand, acpi_cpu acts as a bus and has child devices. Some of those children can not attach that early because they need more of the system to be initialized (e.g. PCI bus). Hence the SYSINIT hack to attach them later. -- Andriy Gapon