From owner-freebsd-acpi@FreeBSD.ORG Mon Feb 25 21:04:11 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 C975516A40E; Mon, 25 Feb 2008 21:04:11 +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 491AC13C4F8; Mon, 25 Feb 2008 21:04:11 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B9E63744002; Mon, 25 Feb 2008 23:04:08 +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 4rzVSFl3rI17; Mon, 25 Feb 2008 23:04:08 +0200 (EET) Received: from [10.74.68.211] (unknown [193.138.145.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id A23A0744001; Mon, 25 Feb 2008 23:04:07 +0200 (EET) Message-ID: <47C32D3C.2020205@icyb.net.ua> Date: Mon, 25 Feb 2008 23:03:56 +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> In-Reply-To: <47C30201.3060501@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: Mon, 25 Feb 2008 21:04:11 -0000 on 25/02/2008 19:59 Nate Lawson said the following: > Andriy Gapon wrote: >> on 22/02/2008 17:56 Andriy Gapon said the following: >>> Please find attached a patch that makes sure that acpi_thermal is >>> initialized after PCI bus is available, so that it is possible to decide >>> about hardware quirks based on PCI information. >>> The code uses the same approach as ichss does. >>> The patch is tested to work. >> Oops! I attached on older version of the patch, sorry. >> Correct patch is here. >> (parent of acpi_throttle is cpu, not acpi) >> >>> NOTE: This patch in contaminated! It contains code that forces throttle >>> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance >>> with the chipsets specifications. Some motherboard/bios vendors lie >>> about this value in FADT. >>> If not accepted, this quirk can be easily stripped from the patch as its >>> code is contained in distinct hunks. > > Ok, couple comments I think should be addressed before committing: > > * This only adds a child to cpu0. On an SMP machine, we should have a > device instance attached to each cpu. On machines where each CPU has > its own throttling register, this is necessary to program the new rate. > > * Is it necessary to add "device_probe_and_attach(child)"? I guess if > the child is added after the cpu parent's probe/attach run has > completed, that could be a problem. > > * I'm uncomfortable with moving the whole driver probe under pci. I'd > rather the pci probe happen separately and provide information to the > cpufreq probe. But I'm not sure this is feasible. I wonder if John > might have any advice on how to coordinate between PCI and cpufreq? > 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. -- Andriy Gapon