| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
modulating the STPCLK# pin based on the duty cycle. Since p4tcc uses the
same mechanism (but internal to the CPU), we triggered a hang on some
systems at low frequencies when both were in use. Now, disable
acpi_throttle when p4tcc is also present.
Tested by: Kevin Oberman
|
|
|
|
| |
they don't actually support Px states.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Suggested by: Jung-uk Kim
|
|
|
|
| |
Noticed by: Coverity tool
|
|
|
|
| |
a bitfield.
|
|
|
|
|
| |
in units of bytes and adjust accordingly. This is found at least on the
Sony PCG-505BX.
|
|
|
|
| |
IRQ 0 quirk.
|
|
|
|
|
|
|
|
|
| |
IRQ 0 and not an ExtINT pin. The MADT enumerators ignore the PC-AT flag
and ignore overrides that map IRQ 0 to pin 2 when this quirk is present.
- Add a block comment above the quirks to document each quirk so that we
can use more verbose descriptions quirks.
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
modes, systems may take longer. If the status values don't match, try
matching just the lowest 8 bits if no bits above 8 are set in the desired
value. The IBM R32 has other bits set in the status register that are
irrelevant to the expected value.
|
|
|
|
| |
hint.ichss.0.disabled="1"
|
|
|
|
|
|
|
|
|
| |
the switch. Other interim tests (i.e., for minimum runtime) could
invalidate the start time. This fixes transitions to cooler states in that
now they go to the next active state (_AC0 -> _AC1) instead of going
straight to off (_AC0 -> off).
Submitted by: Alexandre "Sunny" Kovalenko (Alex.Kovalenko / verizon.net)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
locks held, specify the ACPI_ISR flag to keep it from acquiring any more
mutexes (which could potentially sleep.) This should fix "could sleep"
warning messages on the following path:
msleep()
AcpiOsWaitSemaphore()
AcpiUtAcquireMutex()
AcpiDisableGpe()
EcGpeHandler()
AcpiEvGpeDispatch()
AcpiEvGpeDetect()
AcpiEvGpeDetect()
AcpiEvSciXruptHandler()
|
|
|
|
|
| |
specific values that other components may want to use. Add support to
acpi_perf(4) to export the control and status values via this field.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
we want to return EOPNOTSUPP for FFixedHW no matter what the address.
Submitted by: Bruno Ducrot
|
|
|
|
| |
ENOMEM. The manpage and ichss(4) are correct.
|
|
|
|
| |
Suggested by: Jung-uk Kim
|
|
|
|
|
|
|
|
|
|
|
| |
are not added to the list(s) of available settings. However, other drivers
can call the CPUFREQ_DRV_SETTINGS() method on those devices directly to
get info about available settings.
Update the acpi_perf(4) driver to use this flag in the presence of
"functional fixed hardware." Thus, future drivers like Powernow can
query acpi_perf for platform info but perform frequency transitions
themselves.
|
|
|
|
|
|
|
|
|
| |
throttling, neglecting to do this kept the sysctls from appearing.
Attach an acpi_throttle device to each CPU that supports it.
Don't add a device if the P_BLK is invalid or if _PTC is not present.
This removes extraneous probe/attach failure messages on some machines.
Make the cpu throttle state local to the softc to account for partial
successes when changing the clock rate on MP machines.
|
|
|
|
| |
methods.
|
| |
|
|
|
|
| |
is supported by acpi_throttle(4).
|
|
|
|
| |
acpi_throttle(4).
|
|
|
|
|
|
|
|
|
| |
doing it in the cpu driver. The previous code was incorrect anyway since
this value controls Px states, not throttling as the comment said. Since
we didn't support Px states before, there was no impact. Also, note that
we delay the write to SMI_CMD until after booting is complete since it
sometimes triggers a change in the frequency and we want to have all
drivers ready to detect/handle this.
|
|
|
|
|
|
| |
devclass. As pointed out by dfr@, devclasses don't have to share the same
linkage if multiple drivers have the same name. Newbus should match the
devclasses based on name and allocate non-conflicting unit numbers.
|
|
|
|
|
|
| |
the PERF_CTRL register in our probe method so that we can tell earlier
that another driver should handle this device due to FFixedHW. This avoids
scaring users when attach failed when we really wanted probe to fail.
|
| |
|
|
|
|
|
|
| |
type. This is needed if the resource is to be released later. The RID is
still also present, though less necessary since rman_get_rid() can be used
to obtain it from the resource.
|
|
|
|
|
|
| |
Instead, just fail to attach so another hardware-specific driver can
claim the device. Also, clean up some small memory leaks in the failure
case.
|
|
|
|
| |
since this type of register should be handled by another driver.
|
| |
|
|
|
|
|
|
|
|
| |
settings as exported via the ACPI _PSS method. OEMs use this interface
to encapsulate chipset or processor-specific methods (e.g., SpeedStep or
Powernow) and export their settings in a standard way. On systems that
have valid ACPI Performance states and a hardware-specific driver (e.g.,
ichss), acpi_perf(4) is preferred.
|
|
|
|
| |
appropriate requests to any children.
|
| |
|
|
|
|
|
|
| |
producers rather than consumers as new-bus resources only handle consumed
resources. We already do this for the other ACPI resource types that
support the producer/consumer attribute.
|
|
|
|
|
|
|
|
| |
object (/) rather than the pci bus object when walking the _PRT to force
attach devices. We already look up relative to the root object when doing
interrupt routing.
Suggested by: njl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For such devices, we require _PRS to exist and we warn if any of the
resources in _PRS are not IRQ resources (since we'll have no way of knowing
which of those resources to use without a working _CRS). When it does
come time to set resources, we build up a resource buffer from scratch
as we do for devices with _CRS that only have IRQ resources.
- Fix a bug with setting extended IRQ resources where we set the IRQ value
in the wrong resource structure meaning that whichever IRQ was listed in
_PRS was used instead. This might fix some weird issues on certain boxes
where IRQs > 16 don't seem to work when using ACPI.
- Fix a bug with how we walked the resource buffer after _SRS to call
config_intr() in that the 'end' variable was not properly updated, so we
could either terminate the loop early or loop after the end of the
buffer.
Tested by: pjd
|
|
|
|
|
|
|
|
|
| |
place device objects in \ (in this case, PCI links.) Work around this by
starting our probe from \. To avoid attaching system scope objects,
explicitly skip them. (I think it's an ACPI-CA bug that \_SB and \_TZ have
device and thermal object types.) Thanks to pjd@ for testing.
MFC after: 2 weeks
|
| |
|
|
|
|
| |
TRUE/FALSE instead of 1/0 for booleans. Remove trailing and extra whitespace.
|
| |
|
|
|
|
|
|
|
|
|
| |
multiple IRQs (which is nonsense for _CRS) when the link hasn't been
programmed. Before, this was a KASSERT. A ServerWorks system was
seen returning IRQs of 0, 2 in response to _CRS before link setup.
Thanks to sam@ for quick testing and turnaround on this.
Tested by: sam
|
|
|
|
|
|
|
| |
An improvement would be to check all batteries for critical state before
printing a message.
Reported by: Kevin Oberman (oberman at es net)
|
|
|
|
|
|
|
| |
one will never be supported on the same platform, this does not hurt
debugging.
MFC after: 3 days
|
|
|
|
| |
error had caused the hang and it has been corrected now.
|
| |
|