From owner-freebsd-acpi@FreeBSD.ORG Tue Feb 19 15:52:12 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 67F0C16A469 for ; Tue, 19 Feb 2008 15:52:12 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 4512113C4D9 for ; Tue, 19 Feb 2008 15:52:12 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 49351 invoked from network); 19 Feb 2008 15:52:12 -0000 Received: from adsl-71-141-98-131.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.98.131) by root.org with ESMTPA; 19 Feb 2008 15:52:12 -0000 Message-ID: <47BAFB27.1050509@root.org> Date: Tue, 19 Feb 2008 07:52:07 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Andriy Gapon References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> In-Reply-To: <47BAF97A.80405@icyb.net.ua> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Tue, 19 Feb 2008 15:52:12 -0000 Andriy Gapon wrote: > on 19/02/2008 01:00 Rui Paulo said the following: >> On Feb 18, 2008, at 11:18 AM, Andriy Gapon wrote: >> >>> While looking for something else I accidentally noticed that >>> acpi_throttle has one quirk for some early revisions of PIIX4 chipset >>> and the quirk is enabled based on PCI info. >>> I have a newer revision of PIIX4 so the quirk is not applicable in >>> my case. >>> >>> Nevertheless I noticed that acpi_throttle is initialized before PCI >>> bus >>> driver, so when it calls pci_find_device() it always returns NULL and >>> quirk is not applied. At least this is what I see in dmesg on my >>> machine. >> I run into a similar problem on my SoC MacBook project and I ended up >> using the SMI vendor strings because it was too early in boot in order >> to find the PCI devices. The problem here is very similar. >> Maybe we should try to use SMI vendor strings instead of >> pci_find_device()? > > I am not familiar with this approach and I am not sure if that works > with that type of (quite old) hardware. > > When I worked on something else I remember somebody (maybe Nate) > recommending me to model my code after ichss: > sys/dev/cpufreq/ichss.c > > Maybe the same approach could be used here? > > I.e. no identify method for acpi bus. > Additional device/driver for pci bus. > pci probe method checks for duplicates and adds the acpi device as a > child to acpi bus. > pci probe method sets quirks based on pci info. > pci probe method runs device_probe_and_attach on the acpi device. > as a consequence acpi probe and attach (for successful probe) are executed. > > The only unclear issue is where to place the code that is currently in > (acpi) identify method - should it go to pci identify method or should > it go to acpi probe method. Yeah, it's a problem either way. I remember something like: 1. Separate PCI attachment that adds ACPI device Guaranteed that PCI is available. Bad: won't work if loaded after boot (not probed) 2. Directly calling device_probe() Good: works after boot. Bad: always adds a device even if none present. You can see the first one in ichss.c. It's why cpufreq devices are not loadable. -- Nate