From owner-freebsd-acpi@FreeBSD.ORG Thu Feb 28 19:17:34 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 0AAF0106566C; Thu, 28 Feb 2008 19:17:34 +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 69FF88FC26; Thu, 28 Feb 2008 19:17:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id C339974400A; Thu, 28 Feb 2008 21:17:31 +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 VRBMt37nlbnF; Thu, 28 Feb 2008 21:17:31 +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 7E32443F5C4; Thu, 28 Feb 2008 21:17:30 +0200 (EET) Message-ID: <47C708BE.3020108@icyb.net.ua> Date: Thu, 28 Feb 2008 21:17:18 +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> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> <200802280856.31548.jhb@freebsd.org> <47C6F939.4060301@root.org> In-Reply-To: <47C6F939.4060301@root.org> 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: Thu, 28 Feb 2008 19:17:34 -0000 on 28/02/2008 20:11 Nate Lawson said the following: > John Baldwin wrote: >> Actually, we can make ichss rather simple w/o changing it much by having it >> just set a global variable in its PCI probe routine and checking that global >> when attaching to the CPU. > > I like your approach. I like it too. And I also think that if pci-cpu ordering is implemented, then pci_find_bsf approach that John mentioned should work too. So there would be no need to attach to pci bus at all - all pci-specific stuff could be done through the chipset device. >> One other thing that concerns me is that cpufreq drivers want to know about >> each other (e.g. smist checks for ichss0, etc.). I'd rather that if we have >> multiple drivers controlling the same back-end hardware (via difference >> interfaces) they all use the same driver name (e.g. speedstep0) and use probe >> priority to decide which driver wins if both ichss0 and smist0 can handle a >> CPU for example. > > It took me a while to figure out what the generic interface was actually > hooking up to in terms of hardware. For example, some laptops export > p4tcc via acpi_throttle. Others export a SMI/BIOS equivalent that > programs the chipset instead of the CPU. Unfortunately, there doesn't > seem to be an easy way to figure out if two drivers are talking to the > same hardware so it seems the right choice is to only use the generic > interface if the hw-specific one fails to attach. > > I think making acpi_throttle attach at a lower priority than ichss, est, > and smist is the best approach. I wouldn't want to change the names as > it would be hard to figure out which hw is actually being driven. > Still, there needs to be a way for them to indicate that they attach to > the same hw as acpi_throttle. Your global may be the best approach for now. And there is another thing: as I understand there could be multiple "cpufreq-ish" devices attached simultaneously - some providing absolute values, some providing relative ones, and "the" cpufreq device aggregates them. John's suggestion has a lot of appeal. Maybe it could be implemented in some other form, but that definitely would require detailed analysis. >> Here is a patch to make CPUs come after PCI and an attempt to fix ICH. Note >> that if we made ichss_identify() manually look for the PCI device by bsf >> instead of using a probe routine to find it we could remove the pci "driver" >> completely and make it work on kldload. It also fixes a bug that the attempt >> to enable SS via a PCI config register write could never work as it passed a >> cpu0 device_t to pci_read_config/pci_write_config in ichss_probe() >> previously. I moved this to attach() (where it belongs) and used the right >> device_t so this should work now. I have no hardware to test it on though. > > ICH SpeedStep is pretty old. You need Pentium 3 era laptops, i.e IBM T23. Unfortunately I can not test this particular driver too for the same reason. I will test the acpi ordering patch and its interaction with acpi_throttle (with my private quirk for PIIX4E). -- Andriy Gapon