src/sys/dev/cpufreq, branch releng/7.3 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F7.3 2008-08-20T18:33:09Z MFC: Attach the cpufreq child devices with specific orders to enforce 2008-08-20T18:33:09Z John Baldwin jhb@FreeBSD.org 2008-08-20T18:33:09Z urn:sha1:d8481c991175c678901c343db7bb66926a8251dd relative priority of some of the drivers that manage the same state (e.g. ichss0 vs est0). MFC: Probe CPUs after the PCI hierarchy on i386, amd64, and ia64. This 2008-06-27T03:49:22Z John Baldwin jhb@FreeBSD.org 2008-06-27T03:49:22Z urn:sha1:673ded81d5b23762113e978ffee80b217e4d60ce allows the cpufreq drivers to reliably use properties of PCI devices for quirks, etc. Since DELAY() was moved, most <machine/clock.h> #includes have been 2006-05-16T14:37:58Z Poul-Henning Kamp phk@FreeBSD.org 2006-05-16T14:37:58Z urn:sha1:c40da00ca320a38816049edd21966bd4045b2303 unnecessary. Only activate ICH speedstep if we're going to use it. No bugs were observed 2005-03-20T01:25:21Z Nate Lawson njl@FreeBSD.org 2005-03-20T01:25:21Z urn:sha1:823d404a6d929d473ee81056b61f675c74082aea due to this but it's cleaner this way. Make a pass through all drivers checking specs for desired behavior on 2005-02-27T02:43:02Z Nate Lawson njl@FreeBSD.org 2005-02-27T02:43:02Z urn:sha1:97d31723e73ab6e80b3d0d586fc9a9998c2e1b6e SMP systems. It appears all drivers except ichss should attach to each CPU and that settings should be performed on each CPU. Add comments about this. Also, add a guard for p4tcc's identify method being called more than once. Support disabling individual cpufreq drivers with hints, e.g., 2005-02-22T06:31:45Z Nate Lawson njl@FreeBSD.org 2005-02-22T06:31:45Z urn:sha1:0dc1b976eb96fc6fa7fd78ce27e312385e4b9340 hint.ichss.0.disabled="1" Don't attach ichss if est is present. On systems that seem to support both, 2005-02-20T23:41:20Z Nate Lawson njl@FreeBSD.org 2005-02-20T23:41:20Z urn:sha1:a47331bb737cae17b7c1db59088a165411853ab6 the multi-setting EST is preferable. Introduce a new method, cpufreq_drv_type(), that returns the type of the 2005-02-18T00:23:36Z Nate Lawson njl@FreeBSD.org 2005-02-18T00:23:36Z urn:sha1:e94a0c1a18e6974bd6467d32a0f0fec8bffe5307 driver. This used to be handled by cpufreq_drv_settings() but it's useful to get the type/flags separately from getting the settings. (For example, you don't have to pass an array of cf_setting just to find the driver type.) Use this new method in our in-tree drivers to detect reliably if acpi_perf is present and owns the hardware. This simplifies logic in drivers as well as fixing a bug introduced in my last commit where too many drivers attached. Fix the check for acpi_perf(4) so that we verify if it is fully attached 2005-02-17T01:01:40Z Nate Lawson njl@FreeBSD.org 2005-02-17T01:01:40Z urn:sha1:6655857ec7b8ca3beb28de35e587e8f28cde6f2e or just offering info. In the former case, we don't probe/attach to allow the ACPI driver precedence. A refinement of this would be to actually use the info provided by acpi_perf(4) to get the real CPU clock rates instead of estimating them but since all systems that support both acpi_perf(4) and ichss(4) export the control registers to acpi_perf(4), it can just handle the registers on its own. Use intr_disable/restore() instead of disable_intr() since the latter is 2005-02-05T16:31:58Z Nate Lawson njl@FreeBSD.org 2005-02-05T16:31:58Z urn:sha1:0a9145a2f211e1fb7be961e0810569ded80ff1ee not MI. This should fix build on non i386 platforms.