src/sys/dev/cpufreq, branch release/10.1.0 FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=release%2F10.1.0 2013-02-26T18:30:47Z Add a quirk to disable this driver for certain older laptops with an ICH2 2013-02-26T18:30:47Z John Baldwin jhb@FreeBSD.org 2013-02-26T18:30:47Z urn:sha1:7ad65edee343f79be93a1ec098d38a7881609e02 southbridge and an Intel 82815_MC host bridge where the host bridge's revision is less than 5. Tested by: mi MFC after: 1 week Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on device_method_t arrays 2013-01-30T18:01:20Z Sofian Brabez sbz@FreeBSD.org 2013-01-30T18:01:20Z urn:sha1:61bfd867626dad25026bafcbc5fbc595d9e85417 Reviewed by: cognet Approved by: cognet Attach the cpufreq child devices with specific orders to enforce relative 2008-08-13T16:09:40Z John Baldwin jhb@FreeBSD.org 2008-08-13T16:09:40Z urn:sha1:bc136b187d98c5e736530cd9b9b0e7658b305d8b priority of some of the drivers that manage the same state (e.g. ichss0 vs est0). Specifically, powernow, est, and p4tcc are added at order 10, ichss at order 20, and smist at order 30. Previously, some laptops were seeing both ichss0 and est0 attaching and stomping on each other. XXX: This isn't quite ideal, but works with the existing hacks, I think what we really want instead is a single "speedstep0" device for CPUs that the ichss, est, and smist drivers probe (but with differing priorities). MFC after: 1 week Probe CPUs after the PCI hierarchy on i386, amd64, and ia64. This allows 2008-03-10T22:18:07Z John Baldwin jhb@FreeBSD.org 2008-03-10T22:18:07Z urn:sha1:463e0f91cb2b4baf565f29fd8c472dcba24c0940 the cpufreq drivers to reliably use properties of PCI devices for quirks, etc. - For the legacy drivers, add CPU devices via an identify routine in the CPU driver itself rather than in the legacy driver's attach routine. - Add CPU devices after Host-PCI bridges in the acpi bus driver. - Change the ichss(4) driver to use pci_find_bsf() to locate the ICH and check its device ID rather than having a bogus PCI attachment that only checked for the ID in probe and always failed. As a side effect, you can now kldload ichss after boot. - Fix the ichss(4) driver to use the correct device_t for the ICH (and not for ichss0) when doing PCI config space operations to enable SpeedStep. MFC after: 2 weeks Reviewed by: njl, Andriy Gapon avg of icyb.net.ua 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.