summaryrefslogtreecommitdiffstats
path: root/sys/dev/acpica
Commit message (Collapse)AuthorAgeFilesLines
* Use a more proper fix for enabling HT MSI mapping windows on Host-PCIjhb2012-03-291-16/+35
| | | | | | | | | | | | | | | | | | | | bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
* Restore interrupt state after executing AcpiEnterSleepState().jkim2012-03-271-5/+10
|
* Add ACPI_LV_REPAIR debug level, available since ACPICA 20091214 (r200553).jkim2012-03-221-0/+1
| | | | MFC after: 3 days
* Merge ACPICA 20120320.jkim2012-03-202-3/+16
|
* ServerWorks HT1000 HPET reported to have problems with IRQs >= 16.mav2012-03-101-0/+8
| | | | | | | | Lower (ISA) IRQs are working, but allowed mask is not set correctly. Block both by default to allow HP BL465c G6 blade system to boot. Reported by: Attila Nagy <bra@fsn.hu> MFC after: 1 week
* - Add a bus_dma tag to each PCI bus that is a child of a Host-PCI bridge.jhb2012-03-021-5/+7
| | | | | | | | | | | | | | | The tag enforces a single restriction that all DMA transactions must not cross a 4GB boundary. Note that while this restriction technically only applies to PCI-express, this change applies it to all PCI devices as it is simpler to implement that way and errs on the side of caution. - Add a softc structure for PCI bus devices to hold the bus_dma tag and a new pci_attach_common() routine that performs actions common to the attach phase of all PCI bus drivers. Right now this only consists of a bootverbose printf and the allocate of a bus_dma tag if necessary. - Adjust all PCI bus drivers to allocate a PCI bus softc and to call pci_attach_common() from their attach routines. MFC after: 2 weeks
* Fix a long-standing bug for AcpiOsGetTimer(). time_t is 32-bit on i386 andjkim2012-02-241-3/+3
| | | | | | it needs proper casting before multiplication. MFC after: 3 days
* Merge ACPICA 20120215.jkim2012-02-163-4/+21
|
* De-obfuscate acpi_acquire_global_lock(). It seems the function was directlyjkim2012-02-101-8/+6
| | | | translated from i386 assembly version.
* Refine r231226. Swap timecounters before suspending any device drivers.jkim2012-02-091-10/+17
|
* Reset clock after atrtc(4) is properly resumed.jkim2012-02-082-4/+9
|
* Revert r211288 and move the logic to the acpi_timer itself.jkim2012-02-081-0/+48
|
* - Give all clocks and timers on acpi0 the equal probing order.jkim2012-02-075-21/+27
| | | | | | | - Increase probing order for ECDT table to match HID-based probing. - Decrease probing order for HPET table to match HID-based probing. - Decrease probing order for CPUs and system resources. - Fix ACPI_DEV_BASE_ORDER to reflect the reality.
* Further relax the strictness of enforcing allocations to only come fromjhb2011-12-291-1/+10
| | | | | | | | | | | | | | | | decoded ranges. Pass any request for a specific range that fails because it is not in a decoded range for an ACPI Host-PCI bridge up to the parent to see if it can still be allocated. This is based on the assumption that many BIOSes are inconsistent/broken and that settings programmed into BARs or resources assigned to other built-in components are more trustworthy than the list of decoded resource ranges in _CRS. This effectively limits the decoded ranges to only being used for "wildcard" ranges when allocating fresh resources for a BAR, etc. At some point I would like to only be this permissive during an early scan of firmware-assigned resources during boot and to be strict about all later allocations, but that isn't viable currently. MFC after: 2 weeks
* Prevent a division by zero with some broken batteriesdumbbell2011-11-261-0/+8
| | | | This problem was seen on a laptop with a dead battery.
* - There's no need to overwrite the default device method with the defaultmarius2011-11-223-6/+3
| | | | | | | | | | one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID.
* - be more precise about the unit of measurementeadler2011-11-171-1/+1
| | | | | Approved by: jhb MFC after: 3 days
* - be more precise about the unit of measurementeadler2011-11-171-1/+1
| | | | | | Submitted by: Oliver Pinter <oliver.pntr@gmail.com> Approved by: jhb MFC after: 3 days
* Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.ed2011-11-072-2/+3
| | | | | | The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static.
* Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.ed2011-11-0710-10/+11
| | | | This means that their use is restricted to a single C file.
* If an allocation for a specific resource range fails because it is not injhb2011-10-123-7/+27
| | | | | | | | a decoded range for an ACPI Host-PCI bridge, try to allocate it from the ACPI system resource range. If that works, permit the resource allocation regardless. MFC after: 1 week
* Improve the sleep_delay sysctl description by specifying which unitbrueffer2011-09-131-1/+1
| | | | | | | | | the number is in. PR: 159975 Submitted by: gcooper Approved by: re (kib) MFC after: 1 week
* Always check current HPET counter value after comparator programming tomav2011-08-162-8/+8
| | | | | | | | | | | avoid lost timer interrupts. Previous optimization attempt doing it only for intervals less then 5000 ticks (~300us) reported to be unreliable by some people. Probably because of some heavy SMI code on their boards. Introduce additional safety interval of 128 counter ticks (~9us) between programmed comparator and counter values to cover different cases of delayed write found on some chipsets. Approved by: re (kib)
* Allow non-fixed endpoints for a producer address range if the length ofjhb2011-07-211-3/+5
| | | | | | | | | | the resource covers the entire range. Some BIOSes appear to mark endpoints as non-fixed incorrectly (non-fixed endpoints are supposed to be used in _PRS when OSPM is allowed to allocate a certain chunk of address space within a larger range, I don't believe it is supposed to be used for _CRS). Approved by: re (kib)
* Don't ignore negatively decoded address ranges.jhb2011-07-171-7/+0
| | | | Reported by: scottl
* Respect the BIOS/firmware's notion of acceptable address ranges for PCIjhb2011-07-151-0/+166
| | | | | | | | | | | | | | | | | | | | resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
* Remove duplicate header includeskevlo2011-06-281-1/+0
|
* Now that ia64 has been switched to the event timers, remove themarcel2011-06-251-4/+0
| | | | conditional compilation work-arounds.
* Typo.jhb2011-06-241-1/+1
|
* Fix build on ia64 after r223426.jkim2011-06-221-0/+2
|
* Set negative quality to TSC timecounter when C3 state is enabled for Inteljkim2011-06-221-0/+2
| | | | | | | | | | | | | | | processors unless the invariant TSC bit of CPUID is set. Intel processors may stop incrementing TSC when DPSLP# pin is asserted, according to Intel processor manuals, i. e., TSC timecounter is useless if the processor can enter deep sleep state (C3/C4). This problem was accidentally uncovered by r222869, which increased timecounter quality of P-state invariant TSC, e.g., for Core2 Duo T5870 (Family 6, Model f) and Atom N270 (Family 6, Model 1c). Reported by: Fabian Keil (freebsd-listen at fabiankeil dot de) Ian FREISLICH (ianf at clue dot co dot za) Tested by: Fabian Keil (freebsd-listen at fabiankeil dot de) - Core2 Duo T5870 (C3 state available/enabled) jkim - Xeon X5150 (C3 state unavailable)
* Add a helper routine to conditionally modify the start address of ajhb2011-06-221-22/+4
| | | | | | | | | | | | | | | | resource allocation from an x86 Host-PCI bridge driver so that it can be reused by the ACPI Host-PCI bridge driver (and eventually the MPTable Host-PCI bridge driver) instead of duplicating the same logic. Note that this means that hw.acpi.host_mem_start is now replaced with the hw.pci.host_mem_start tunable that was already used in the non-ACPI case. This also removes hw.acpi.host_mem_start on ia64 where it was not applicable (the implementation was very x86-specific). While here, adjust the logic to apply the new start address on any "wildcard" allocation even if that allocation comes from a subset of the allowable address range. Reviewed by: imp (1)
* Fix build with ACPI_DEBUG defined.jhb2011-06-211-8/+9
| | | | | Submitted by: jkim Pointy hat to: jhb
* Use AcpiWalkResources() to parse the resource list from _CRS rather thanjhb2011-06-212-336/+282
| | | | | | | using a home-rolled loop. While here, add support for 64-bit address range resources. Silence on: acpi@ (older version)
* Don't create a device_t object or parse current resources (via _CRS) forjhb2011-06-172-20/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI Device() objects that do not have any device IDs available via the _HID or _CID methods. Without a device ID a device driver cannot attach to the device anyway. Namespace objects that are devices but not of type ACPI_TYPE_DEVICE are not affected. A few BIOSes have also attached a _CRS method to a PCI device to allocate resources that are not managed via a BAR. With the previous code those resources are allocated from acpi0 directly which can interfere with the new PCI-PCI bridge driver (since the PCI device in question may be behind a bridge and its resources should be allocated from that bridge's windows instead). The resources were also orphaned and and would end up associated with some other random device whose device_t reused the pointer of the original ACPI-enumerated device (after it was free'd by the ACPI PCI bus driver) in devinfo output which was confusing. If we want to handle _CRS on PCI devices we can adjust the ACPI PCI bus driver to do that in the future and associate the resources with the proper device object respecting PCI-PCI bridges, etc. Note that with this change the ACPI PCI bus driver no longer has to delete ACPI-enumerated device_t devices that mirror PCI devices since they should in general not exist. There are rare cases when a BIOS will give a PCI device a _HID (e.g. I've seen a PCI-ISA bridge given a _HID for a system resource device). In that case we leave both the ACPI and PCI-enumerated device_t objects around just as in the previous code.
* Implement BUS_ADJUST_RESOURCE() for the x86 drivers that sit between thejhb2011-06-101-11/+25
| | | | Host-PCI bridge drivers and nexus.
* Merge ACPICA 20110527.jkim2011-05-311-10/+13
|
* Decrease ACPI-fast timecounter quality to 900 and increase HPET timecounterjkim2011-05-232-2/+2
| | | | | | | | quality to 950. HPET on modern platforms usually have better resolution and lower latency than ACPI timer. Effectively this changes default timecounter hardware from ACPI-fast to HPET by default when both are available. Discussed with: avg
* Reimplement how PCI-PCI bridges manage their I/O windows. Previously thejhb2011-05-032-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | driver would verify that requests for child devices were confined to any existing I/O windows, but the driver relied on the firmware to initialize the windows and would never grow the windows for new requests. Now the driver actively manages the I/O windows. This is implemented by allocating a bus resource for each I/O window from the parent PCI bus and suballocating that resource to child devices. The suballocations are managed by creating an rman for each I/O window. The suballocated resources are mapped by passing the bus_activate_resource() call up to the parent PCI bus. Windows are grown when needed by using bus_adjust_resource() to adjust the resource allocated from the parent PCI bus. If the adjust request succeeds, the window is adjusted and the suballocation request for the child device is retried. When growing a window, the rman_first_free_region() and rman_last_free_region() routines are used to determine if the front or end of the existing I/O window is free. From using that, the smallest ranges that need to be added to either the front or back of the window are computed. The driver will first try to grow the window in whichever direction requires the smallest growth first followed by the other direction if that fails. Subtractive bridges will first attempt to satisfy requests for child resources from I/O windows (including attempts to grow the windows). If that fails, the request is passed up to the parent PCI bus directly however. The PCI-PCI bridge driver will try to use firmware-assigned ranges for child BARs first and only allocate a "fresh" range if that specific range cannot be accommodated in the I/O window. This allows systems where the firmware assigns resources during boot but later wipes the I/O windows (some ACPI BIOSen are known to do this) to "rediscover" the original I/O window ranges. The ACPI Host-PCI bridge driver has been adjusted to correctly honor hw.acpi.host_mem_start and the I/O port equivalent when a PCI-PCI bridge makes a wildcard request for an I/O window range. The new PCI-PCI bridge driver is only enabled if the NEW_PCIB kernel option is enabled. This is a transition aide to allow platforms that do not yet support bus_activate_resource() and bus_adjust_resource() in their Host-PCI bridge drivers (and possibly other drivers as needed) to use the old driver for now. Once all platforms support the new driver, the kernel option and old driver will be removed. PR: kern/143874 kern/149306 Tested by: mav
* The ACPI Host-PCI bridge driver actually supports multiple domains viajhb2011-05-021-1/+1
| | | | | the optional _SEG function. Return that value (ap->segment) rather than 0 for the pcib domain ivar.
* Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver,jhb2011-05-021-0/+1
| | | | | generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge drivers.
* Correctly output the entire array for hw.acpi.thermal._ACx.mdf2011-04-191-1/+2
| | | | | Reported by: Taku YAMAMOTO < taku AT tackymt DOT homeip DOT net > Tested by: Nick Ulen < uncle AT wolfman DOT devio DOT us >
* Do not assume PM timer GAS type is I/O or memory. It may be an unsupportedjkim2011-04-181-8/+33
| | | | | type, i. e., a broken table. Also, do not hardcode ACPI timer frequency in device description.
* Fix a few acpi sysctls that want "IK" formatting to specify CTLTYPE_INT.mdf2011-04-181-7/+7
| | | | | | | This got broken after r217586. Pointy hat: to me Tested by: David Wolfskill < davit AT catwhisker DOT org >
* Add event handlers for (ACPI) suspend/resume events. Suspend event handlersjkim2011-04-141-0/+4
| | | | | are invoked right before device drivers go into sleep state and resume event handlers are invoked right after all device drivers are waken up.
* Add some tunable descriptions about x86 timers.jkim2011-04-141-1/+1
| | | | Requested by: arundel
* Use atomic load & store for TSC frequency. It may be overkill for amd64 butjkim2011-04-071-1/+1
| | | | | | | | | safer for i386 because it can be easily over 4 GHz now. More worse, it can be easily changed by user with 'machdep.tsc_freq' tunable (directly) or cpufreq(4) (indirectly). Note it is intentionally not used in performance critical paths to avoid performance regression (but we should, in theory). Alternatively, we may add "virtual TSC" with lower frequency if maximum frequency overflows 32 bits (and ignore possible incoherency as we do now).
* Lower the bar for ACPI-fast on real machines slightly. Empirical evidencesjkim2011-04-051-8/+11
| | | | | | | show that there are perfectly working PM timers with occasional "hiccups", probably because of an SMI. Now we ignore the maximum if it happens once in the test loop and the width is small enough. Also, relax normal width a bit to count in a boundary case.
* Move a trivial acpi_TimerDelta() to acpivar.h to make it inlineable.jkim2011-04-042-11/+10
|
* Always check the current minimum value to make the test more predictable.jkim2011-04-041-2/+2
| | | | Use INT32_MAX instead of an arbitrary big number for the initial minimum.
OpenPOWER on IntegriCloud