This driver supports two bindings:
- cpufreq-dt: systems which share clock and voltage across all CPUs
- arm_big_little_dt: systems which share clock and voltage across all
CPUs in a single cluster
Reviewed by: andrew, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D7741
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
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
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.
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.
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.
