| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shared and generalized between our current amd64, i386 and pc98.
This is just an initial step that should lead to a more complete effort.
For the moment, a very simple porting of cpufreq modules, BIOS calls and
the whole MD specific ISA bus part is added to the sub-tree but ideally
a lot of code might be added and more shared support should grow.
Sponsored by: Sandvine Incorporated
Reviewed by: emaste, kib, jhb, imp
Discussed on: arch
MFC: 3 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have found that it is not only desktop CPUs problem. but mobile also.
Probably AP on laptops just started initially at lower frequency, hiding
the problem.
Disable frequency validation by default, for systems with more then one CPU,
until we can implement it properly. It looks like making more harm now then
benefits. Add 'hw.est.strict' loader tunable to control it.
Now my iXsystems Invincibook is able to run at 800MHz lowest frequency,
instead of 1200MHz before, when 800MHz was incorrectly reported invalid.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
CPU core, only pair of them. As result, both cores are running on highest
one of requested frequencies, and that is reported by status register.
Such behavior confuses frequency validation logic, as it runs on only
one core, as SMP is not yet launched, making EIST completely unusable.
To workaround this, add check for validation result. If we haven't found
at least two usable frequencies, then probably we are looking bad and have
to trust data provided by BIOS as-is.
|
|
|
|
| |
unnecessary #ifdef's for shared code between them.
|
| |
|
|
|
|
|
| |
Found with: Coverity Prevent(tm)
CID: 4285, 4286
|
|
|
|
| |
Submitted by: G.Otsuji
|
|
|
|
|
|
|
| |
Its a newer version provided by the author than in the PR.
PR: kern/128575
Submitted by: Gen Otsuji annona2 [at] gmail.com
|
|
|
|
| |
Reported by: thompsa, "build universe"
|
|
|
|
| |
and hide i386-specific code under #ifdef.
|
| |
|
|
|
|
|
| |
Found with: Coverity Prevent(tm)
CID: 3677
|
|
|
|
| |
Reviewed by: jhb, peter (early amd64 version)
|
|
|
|
|
|
|
|
|
| |
throttle. My SMP kernel hangs when one of those is selected by
powerd. Errata AA21 here:
ftp://download.intel.com/design/PentiumXE/specupdt/31030717.pdf
MFC after: 2 weeks
|
| |
|
| |
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
MFC after: 1 week
|
|
|
|
| |
This can be enabled by setting the 'hw.est.msr_info' tunable to 1.
|
|
|
|
|
|
|
|
| |
tables, then attempt to build a simple list containing just the high and
low frequencies based on the current CPU frequency calculated during boot
and the contents of the MSR.
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
whatever frequency it started at instead of always picking the highest
frequency. The first version of this driver attempted to do this, but it
set the speed to the first frequency in the list rather than the value it
had saved.
MFC after: 1 week
Discussed with: rpaulo, phk
|
|
|
|
|
|
| |
Pointy hat to: me
Pointed out by: jhb
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
| |
10 microseconds is too short.
Always set the cpu to the highest frequency so that we get through
boot and don't handicap cpus where powerd(8) is not used.
|
| |
|
|
|
|
|
|
|
| |
10 microseconds is too short.
Always set the cpu to the highest frequency so that we get through
boot and don't handicap cpus where powerd(8) is not used.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
present in cpu_feature2. Also, use CPUID2_EST rather than a magic
number.
- Don't free the ACPI settings list in detach if we are going to fail the
request. Otherwise an attempt to kldunload est would free the array
but the driver would keep trying to use it.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
CPUFREQ_DRV_SETTINGS(). The value of count on input is used to
prefent overflow of the settings buffer passed into CPUFREQ_DRV_SETTINGS().
This corrects the "est: CPU supports Enhanced Speedstep, but is not recognized."
error on my system.
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
Style changes by me and njl.
Approved by: njl (mentor)
Reviewed by: njl (mentor)
Submitted by: Takeharu KATO <takeharu1219 at ybb.ne.jp>
PR: 119350
MFC after: 1 week
|
|
|
|
|
|
|
|
| |
of the magic string is passed in a 32-bit register, we can't use high
memory in the PAE case. This also eliminates a use of vtophys().
Tested by: Jeff Shimbo <jts767 / gmail.com>
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o remove errata_a0 and introduce the corresponding flags into 'errata'.
o introduce a new errata for K8, namely some platform might set the
PENDING_BIT but aren't able to unset it, also don't loop forever
waiting PENDING_BIT being cleared.
o try to introduce a workaround for the PENDING_BIT stuck problem,
o support now half multipliers for K8.
Tested by: Abdullah Al-Marrie
Approved by: njl
|
|
|
|
| |
unnecessary.
|
|
|
|
|
|
|
|
|
| |
Remove an unnecessary check of the table's bus clock. CPUs that
support this feature export only the high/low settings via the MSR,
packed into 32 bits.
Hardware from: Centaur Technologies
MFC after: 1 week
|
|
|
|
|
|
| |
processors.
Obtained from: Intel Datasheet 302189-008
|
|
|
|
| |
this value lower, making the system quite slow after booting.
|
|
|
|
|
|
| |
even though we're not asking people to contact us.
Requested by: njl
|
|
|
|
|
| |
CPUs. Intel refuses to give me the information I need, and getting
more emails about this doesn't help.
|
|
|
|
|
|
|
|
|
|
| |
settings and is an older version of the same design used for ICH SpeedStep.
It is only known to be available on PIIX4 chipsets.
Many thanks to Bruno Ducrot for writing the driver and Jon Noack for
testing.
Submitted by: Bruno Ducrot
|
|
|
|
|
| |
settings are length-counted while the EST table is null-terminated.
This fixes extra garbage states being reported with ACPI probing.
|
| |
|
|
|
|
|
| |
the PERF_CTL/STS MSRs via the new acpi_get_features() method. This should
allow newer systems to use SpeedStep.
|
|
|
|
|
|
|
|
| |
checks, including cpuid_is_k7(), will catch CPUs that really don't support
this method.
Submitted by: Bruno Ducrot
Tested by: Jari Kirma (kirma cs.hut.fi)
|
|
|
|
|
|
|
|
|
| |
and AMD Cool&Quiet PowerNow! (k8) cpufreq control. This driver is enabled
for both i386 and amd64 architectures. It has both acpi and legacy BIOS
attachments. Thanks to Bruno Ducrot for writing this driver and Jung-uk
Kim for testing.
Submitted by: Bruno Ducrot (ducrot:poupinou.org)
|
|
|
|
|
|
| |
modern CPUs that have multiple VID#s that aren't detectable via public
methods. We use the control value from acpi_perf as the id16 for setting
a given frequency.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
The extraneous "0" state was not fatal but useless.
|
|
|
|
|
|
| |
a bugfix of clearing the On-Demand flag when going back to 100%. It
has been tested and works on an IBM R32. Note original work done by
Ted Unangst and sobomax@.
|