summaryrefslogtreecommitdiffstats
path: root/sys/dev/acpica/acpi.c
Commit message (Collapse)AuthorAgeFilesLines
* Add an EARLY_AP_STARTUP option to start APs earlier during boot.jhb2016-05-141-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, Application Processors (non-boot CPUs) are started by MD code at SI_SUB_CPU, but they are kept waiting in a "pen" until SI_SUB_SMP at which point they are released to run kernel threads. SI_SUB_SMP is one of the last SYSINIT levels, so APs don't enter the scheduler and start running threads until fairly late in the boot. This change moves SI_SUB_SMP up to just before software interrupt threads are created allowing the APs to start executing kernel threads much sooner (before any devices are probed). This allows several initialization routines that need to perform initialization on all CPUs to now perform that initialization in one step rather than having to defer the AP initialization to a second SYSINIT run at SI_SUB_SMP. It also permits all CPUs to be available for handling interrupts before any devices are probed. This last feature fixes a problem on with interrupt vector exhaustion. Specifically, in the old model all device interrupts were routed onto the boot CPU during boot. Later after the APs were released at SI_SUB_SMP, interrupts were redistributed across all CPUs. However, several drivers for multiqueue hardware allocate N interrupts per CPU in the system. In a system with many CPUs, just a few drivers doing this could exhaust the available pool of interrupt vectors on the boot CPU as each driver was allocating N * mp_ncpu vectors on the boot CPU. Now, drivers will allocate interrupts on their desired CPUs during boot meaning that only N interrupts are allocated from the boot CPU instead of N * mp_ncpu. Some other bits of code can also be simplified as smp_started is now true much earlier and will now always be true for these bits of code. This removes the need to treat the single-CPU boot environment as a special case. As a transition aid, the new behavior is available under a new kernel option (EARLY_AP_STARTUP). This will allow the option to be turned off if need be during initial testing. I plan to enable this on x86 by default in a followup commit in the next few days and to have all platforms moved over before 11.0. Once the transition is complete, the option will be removed along with the !EARLY_AP_STARTUP code. These changes have only been tested on x86. Other platform maintainers are encouraged to port their architectures over as well. The main things to check for are any uses of smp_started in MD code that can be simplified and SI_SUB_SMP SYSINITs in MD code that can be removed in the EARLY_AP_STARTUP case (e.g. the interrupt shuffling). PR: kern/199321 Reviewed by: markj, gnn, kib Sponsored by: Netflix
* Add a new bus method to fetch device-specific CPU sets.jhb2016-05-091-30/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bus_get_cpus() returns a specified set of CPUs for a device. It accepts an enum for the second parameter that indicates the type of cpuset to request. Currently two valus are supported: - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to the device when DEVICE_NUMA is enabled) - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core) For systems that do not support NUMA (or if it is not enabled in the kernel config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus' by default. The idea is that INTR_CPUS should always return a valid set. Device drivers which want to use per-CPU interrupts should start using INTR_CPUS instead of simply assigning interrupts to all available CPUs. In the future we may wish to add tunables to control the policy of INTR_CPUS (e.g. should it be local-only or global, should it ignore SMT threads or not). The x86 nexus driver exposes the internal set of interrupt CPUs from the the x86 interrupt code via INTR_CPUS. The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and the global INTR_CPUS set from the nexus driver with the per-domain set from _PXM to generate a local INTR_CPUS set for child devices. Compared to the r298933, this version uses 'struct _cpuset' in <sys/bus.h> instead of 'cpuset_t' to avoid requiring <sys/param.h> (<sys/_cpuset.h> still requires <sys/param.h> for MAXCPU even though <sys/_bitset.h> does not after recent changes).
* sys/dev: minor spelling fixes.pfg2016-05-031-1/+1
| | | | Most affect comments, very few have user-visible effects.
* Revert bus_get_cpus() for now.jhb2016-05-031-58/+30
| | | | | I really thought I had run this through the tinderbox before committing, but many places need <sys/types.h> -> <sys/param.h> for <sys/bus.h> now.
* Add a new bus method to fetch device-specific CPU sets.jhb2016-05-021-30/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bus_get_cpus() returns a specified set of CPUs for a device. It accepts an enum for the second parameter that indicates the type of cpuset to request. Currently two valus are supported: - LOCAL_CPUS (on x86 this returns all the CPUs in the package closest to the device when DEVICE_NUMA is enabled) - INTR_CPUS (like LOCAL_CPUS but only returns 1 SMT thread for each core) For systems that do not support NUMA (or if it is not enabled in the kernel config), LOCAL_CPUS fails with EINVAL. INTR_CPUS is mapped to 'all_cpus' by default. The idea is that INTR_CPUS should always return a valid set. Device drivers which want to use per-CPU interrupts should start using INTR_CPUS instead of simply assigning interrupts to all available CPUs. In the future we may wish to add tunables to control the policy of INTR_CPUS (e.g. should it be local-only or global, should it ignore SMT threads or not). The x86 nexus driver exposes the internal set of interrupt CPUs from the the x86 interrupt code via INTR_CPUS. The ACPI bus driver and PCI bridge drivers use _PXM to return a suitable LOCAL_CPUS set when _PXM exists and DEVICE_NUMA is enabled. They also and the global INTR_CPUS set from the nexus driver with the per-domain set from _PXM to generate a local INTR_CPUS set for child devices. Reviewed by: wblock (manpage) Differential Revision: https://reviews.freebsd.org/D5519
* Optionally return the output capabilities list from _OSC.jhb2016-04-221-5/+23
| | | | | | | | Both of the callers were expecting the input cap_set to be modified. This fixes them to request cap_set to be updated with the returned buffer. Reviewed by: jkim Differential Revision: https://reviews.freebsd.org/D6040
* Prefer sizeof(*pointer) over sizeof(type). No funtional change.jkim2016-04-201-1/+1
|
* Remove query flag from acpi_EvaluateOSC(). This function does not supportjkim2016-04-201-2/+1
| | | | return buffer (yet).
* Add a wrapper for evaluating _OSC methods.jhb2016-04-201-0/+23
| | | | | | | | | | | This wrapper does not translate errors in the first word to ACPI error status returns. Use this wrapper in the acpi_cpu(4) driver in place of the existing _OSC code. While here, fix a bug where the wrong count of words was passed when invoking _OSC. Reviewed by: jkim MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D6022
* Add more fine-grained kernel options for NUMA support.jhb2016-04-091-1/+3
| | | | | | | | | | | | | VM_NUMA_ALLOC is used to enable use of domain-aware memory allocation in the virtual memory system. DEVICE_NUMA is used to enable affinity reporting for devices such as bus_get_domain(). MAXMEMDOM must still be set to a value greater than for any NUMA support to be effective. Note that 'cpuset -gd' always works if MAXMEMDOM is enabled and the system supports NUMA. Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D5782
* Use uintmax_t (typedef'd to rman_res_t type) for rman ranges.jhibbits2016-03-181-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some architectures, u_long isn't large enough for resource definitions. Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but type `long' is only 32-bit. This extends rman's resources to uintmax_t. With this change, any resource can feasibly be placed anywhere in physical memory (within the constraints of the driver). Why uintmax_t and not something machine dependent, or uint64_t? Though it's possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on 32-bit architectures. 64-bit architectures should have plenty of RAM to absorb the increase on resource sizes if and when this occurs, and the number of resources on memory-constrained systems should be sufficiently small as to not pose a drastic overhead. That being said, uintmax_t was chosen for source clarity. If it's specified as uint64_t, all printf()-like calls would either need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t aren't horrible, but it would also bake into the API for resource_list_print_type() either a hidden assumption that entries get cast to uintmax_t for printing, or these calls would need the PRI*64 macros. Since source code is meant to be read more often than written, I chose the clearest path of simply using uintmax_t. Tested on a PowerPC p5020-based board, which places all device resources in 0xfxxxxxxxx, and has 8GB RAM. Regression tested on qemu-system-i386 Regression tested on qemu-system-mips (malta profile) Tested PAE and devinfo on virtualbox (live CD) Special thanks to bz for his testing on ARM. Reviewed By: bz, jhb (previous) Relnotes: Yes Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D4544
* Remove default initializations for rman, a'la r296331jhibbits2016-03-041-2/+0
|
* Introduce a RMAN_IS_DEFAULT_RANGE() macro, and use it.jhibbits2016-02-201-1/+1
| | | | | | | | | | | This simplifies checking for default resource range for bus_alloc_resource(), and improves readability. This is part of, and related to, the migration of rman_res_t from u_long to uintmax_t. Discussed with: jhb Suggested by: marcel
* document some ACPI related sysctls.adrian2016-02-191-4/+8
| | | | | | Submitted by: Oliver Pinter <oliver.pinter@hardenedbsd.org> Sponsored by: HardenedBSD Differential Revision: https://reviews.freebsd.org/D5263
* Convert rman to use rman_res_t instead of u_longjhibbits2016-01-271-10/+10
| | | | | | | | | | | | | | | | | | | | Summary: Migrate to using the semi-opaque type rman_res_t to specify rman resources. For now, this is still compatible with u_long. This is step one in migrating rman to use uintmax_t for resources instead of u_long. Going forward, this could feasibly be used to specify architecture-specific definitions of resource ranges, rather than baking a specific integer type into the API. This change has been broken out to facilitate MFC'ing drivers back to 10 without breaking ABI. Reviewed By: jhb Sponsored by: Alex Perez/Inertial Computing Differential Revision: https://reviews.freebsd.org/D5075
* Disable suspend when we're shutting down. This solves the "tell FreeBSDcperciva2015-10-011-2/+5
| | | | | | | | | | | | to shut down; close laptop lid" scenario which otherwise tended to end with a laptop overheating or the battery dying. The implementation uses a new sysctl, kern.suspend_blocked; init(8) sets this while rc.suspend runs, and the ACPI sleep code ignores requests while the sysctl is set. Discussed on: freebsd-acpi (35 emails) MFC after: 1 week
* Catch up with ACPICA 20150717.jkim2015-07-221-1/+1
|
* CALLOUT_MPSAFE has lost its meaning since r141428, i.e., for more than tenjkim2015-05-221-1/+1
| | | | | | | | | | years for head. However, it is continuously misused as the mpsafe argument for callout_init(9). Deprecate the flag and clean up callout_init() calls to make them more consistent. Differential Revision: https://reviews.freebsd.org/D2613 Reviewed by: jhb MFC after: 2 weeks
* AcpiGbl_FACS will not be defined when building using the reduced hardwareandrew2015-05-061-0/+2
| | | | model. This may be the case on ARM.
* There may not be an FACS table, check for this before accessing it.andrew2015-04-281-1/+1
| | | | Sponsored by: The FreeBSD Foundation
* Refactor out the _PXM -> VM domain lookup done in ACPI, in preparation foradrian2015-04-191-9/+32
| | | | | | | | | | | | | its use in upcoming code. This is inspired by something in jhb's NUMA IRQ allocation patchset. However, the tricky bit here is that the PXM lookup for a node may fail, requiring a lookup on the parent node. So if it doesn't exist, don't fail - just go up to the parent. Only error out of the lookup is the ACPI lookup returns an error. Sponsored by: Norse Corp, Inc.
* Move the message complaining about failed system resource allocationsjhb2015-04-061-1/+1
| | | | | | | | | | under bootverbose. Every example I've seen to date has been due to an ACPI system resource device reserving a range that overlaps with system memory (which ram0 attempts to reserve) or a local or I/O APIC (which apic0 attempts to reserve). These are always harmless but look scary to users. MFC after: 1 week
* Fix a typo.jhb2015-03-061-1/+1
|
* Add a new device control utility for new-bus devices called devctl. Thisjhb2015-02-061-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allows the user to request administrative changes to individual devices such as attach or detaching drivers or disabling and re-enabling devices. - Add a new /dev/devctl2 character device which uses ioctls for device requests. The ioctls use a common 'struct devreq' which is somewhat similar to 'struct ifreq'. - The ioctls identify the device to operate on via a string. This string can either by the device's name, or it can be a bus-specific address. (For unattached devices, a bus address is the only way to locate a device.) Bus drivers register an eventhandler to claim unrecognized device names that the driver recognizes as a valid address. Two buses currently support addresses: ACPI recognizes any device in the ACPI namespace via its full path starting with "\" and the PCI bus driver recognizes an address specification of 'pci[<domain>:]<bus>:<slot>:<func>' (identical to the PCI selector strings supported by pciconf). - To make it easier to cut and paste, change the PnP location string in the PCI bus driver to output a full PCI selector string rather than 'slot=<slot> function=<func>'. - Add a devctl(3) interface in libdevctl which provides a wrapper around the ioctls and is the preferred interface for other userland code. - Add a devctl(8) program which is a simple wrapper around the requests supported by devctl(3). - Add a device_is_suspended() function to check DF_SUSPENDED. - Add a resource_unset_value() function that can be used to remove a hint from the kernel environment. This is used to clear a hint.<driver>.<unit>.disabled hint when re-enabling a boot-time disabled device. Reviewed by: imp (parts) Requested by: imp (changing PCI location string) Relnotes: yes
* hook userland threads suspend + resume into acpi suspend codeavg2015-01-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, split power_suspend into power_suspend and power_suspend_early. power_suspend_early is called before the userland is frozen. power_suspend is called after the userland is frozen. Currently only VT switching is hooked to power_suspend_early. This is needed because switching away from X server requires its cooperation, so obviously X server must not be frozen when that happens. Freezing userland during ACPI suspend is useful because not all drivers correctly handle suspension concurrent with other activity. This is especially applicable to drivers ported from other operating systems that suspend all software activity between placing drivers and hardware into suspended state. In particular drm2/radeon (radeonkms) depends on the described procedure. The driver does not have any internal synchronization between suspension activities and processing of userland requests. Many thanks to kib for the code that allows to freeze and thaw all userland threads. Note that ideally we also need to park / inhibit (non-special) kernel threads as well to ensure that they do not call into drivers. MFC after: 17 days
* Use the correct device. Note this commit complements r274386.jkim2014-11-111-3/+2
| | | | PR: 194884
* Use the correct device (child) when asking the bus layer about which poweradrian2014-11-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | state said device should go into. This was a snafu introduced in the ACPI/PCI awareness separation. When putting a device into a power state, the bus (and thus firmware, eg ACPI) should be asked before hand to check whether the device can indeed go into that power state. There's a set of nodes in ACPI under each device - the _SxD nodes - which state which ACPI power state to put the device into when the system is going into power save state 'x'. So when going into S3, the existence of an _S3D node would override whatever the system was trying to do. By default the PCI code wants to put devices into D3 before suspending. I have a laptop here (Asus Zenbook - check the PR) whose EHCI controller really wants to be in D2 during suspend, not D3. So if we put it into D3 and then try to enter S3, everything hangs. The device itself can go into D3 - it just can't be there when the call to ACPI to enter S3 occurs. The PCI patch fixes this. jkim@ noticed that the same is needed for the ACPI child device enumeration. Thankyou to Matt Dillon (the programmer, not the actor) for buying me this particular laptop so I could debug the issues with the Atheros AR9485 that is in it. It's his fault that I ended up with this laptop and was sufficiently annoyed by the lack of USB suspend to go down this rabbit hole. Tested: * Thinkpad T400 * Thinkpad X230 * Thinkpad T42 * Thinkpad T60 * Asus Zenbook (see PR) * Asus EEEPC 701 * Asus EEEPC 1001PX TODO: * Figure out what we should do about devices we unload drivers for that want to be in a specific state when entering S3 / S4 - the "put devices into D3 if they're not bound to a driver" option may also mess with things. PR: kern/194884 Reviewed by: jhb, jkim MFC after: 1 week Relnotes: yes Sponsored by: Matt Dillon <dillon@apollo.backplane.com> (hardware)
* The SYSCTL data pointers can come from userspace and must not behselasky2014-10-281-7/+8
| | | | | | | | | | directly accessed. Although this will work on some platforms, it can throw an exception if the pointer is invalid and then panic the kernel. Add a missing SYSCTL_IN() of "SCTP_BASE_STATS" structure. MFC after: 3 days Sponsored by: Mellanox Technologies
* Follow up to r225617. In order to maximize the re-usability of kernel codedavide2014-10-161-8/+8
| | | | | | | | in userland rename in-kernel getenv()/setenv() to kern_setenv()/kern_getenv(). This fixes a namespace collision with libc symbols. Submitted by: kmacy Tested by: make universe
* Add a bus method to fetch the VM domain for the given device/bus.adrian2014-10-091-0/+31
| | | | | | | | | | | | | | | | | | | * Add a bus_if.m method - get_domain() - returning the VM domain or ENOENT if the device isn't in a VM domain; * Add bus methods to print out the domain of the device if appropriate; * Add code in srat.c to save the PXM -> VM domain mapping that's done and expose a function to translate VM domain -> PXM; * Add ACPI and ACPI PCI methods to check if the bus has a _PXM attribute and if so map it to the VM domain; * (.. yes, this works recursively.) * Have the pci bus glue print out the device VM domain if present. Note: this is just the plumbing to start enumerating information - it doesn't at all modify behaviour. Differential Revision: D906 Reviewed by: jhb Sponsored by: Norse Corp
* Merge ACPICA 20140926.jkim2014-10-021-11/+7
|
* Convert from timeout(9) to callout(9).jhb2014-09-221-7/+10
|
* Populate the device info string with _PXM (proximity domain) information.adrian2014-09-201-5/+12
| | | | | | | This is primarily useful for debugging right now - it'll show up in devinfo. Reviewed by: jhb
* Revert unrelated changes accidentally committed in r271192.jhb2014-09-171-5/+0
|
* Create a separate structure for per-CPU state saved across suspend andjhb2014-09-061-0/+5
| | | | | | | | | resume that is a superset of a pcb. Move the FPU state out of the pcb and into this new structure. As part of this, move the FPU resume code on amd64 into a C function. This allows resumectx() to still operate only on a pcb and more closely mirrors the i386 code. Reviewed by: kib (earlier version)
* Expand r261243 even further and ignore any I/O port resources assigned tojhb2014-06-251-5/+14
| | | | | | | | PCI root bridges except for the one known-valid case on x86 where bridges claim the I/O port registers used for PCI config space access. Tested by: Hilko Meyer <hilko.meyer@gmx.de> MFC after: 1 week
* Remove instances of variables that were set, but never used. gcc 4.9imp2014-03-301-2/+0
| | | | warns about these by default.
* Some BIOSes incorrectly use standard memory resource ranges to listjhb2014-01-281-0/+16
| | | | | | | | | | | | | | | the memory ranges that they decode for downstream devices rather than creating ResourceProducer range resource entries. The result is that we allocate the full range to the PCI root bridge device causing allocations in child devices to all fail. As a workaround, ignore any standard memory resources on a PCI root bridge device. It is normal for a PCI root bridge to allocate an I/O resource for the I/O ports used for PCI config access, but I have not seen any PCI root bridges that legitimately allocate a memory resource. Reviewed by: jkim MFC after: 1 week
* More BUS_PROBE_NOWILDCARD sweeping. Some devices here (if_ath_ahb and siba)nwhitehorn2013-10-291-1/+1
| | | | | | resist easy conversion since they implement a great deal of their attach logic inside probe(). Some of this could be fixed by moving it to attach(), but some requires something more subtle than BUS_PROBE_NOWILDCARD.
* - Some BIOSes use an Extended IRQ resource descriptor in _PRS for a linkjhb2013-04-221-2/+2
| | | | | | | | | | that uses non-ISA IRQs but use a plain IRQ resource in _CRS. However, a non-ISA IRQ can't fit into a plain IRQ resource. If we encounter a link like this, build the resource buffer from _PRS instead of _CRS. - Set the correct size of the end tag in a resource buffer. Tested by: Benjamin Lee <ben@b1c1l1.com> MFC after: 2 weeks
* revert accidentally committed unneeded changes from r246250avg2013-02-021-2/+2
| | | | | MFC after: 7 days X-MFC with: r246250
* acpi: clear power button status bit after waking up...avg2013-02-021-0/+25
| | | | | | | | so that it is not confused for a new power off request. Learned from: Linux and ACPI specification Tested by: gjb MFC after: 12 days
* acpi: after wakeup from a state > S1 re-enable SCI_EN with a direct writeavg2013-02-021-2/+15
| | | | | | | | | | | This hack is picked up from Linux, which claims that it follows Windows behavior. PR: amd64/174409 Tested by: Sergey V. Dyatko <sergey.dyatko@gmail.com>, KAHO Toshikazu <kaho@elam.kais.kyoto-u.ac.jp>, Slawa Olhovchenkov <slw@zxy.spb.ru> MFC after: 13 days
* Use DEVMETHOD_END macro defined in sys/bus.h instead of {0, 0} sentinel on ↵sbz2013-01-301-1/+1
| | | | | | | device_method_t arrays Reviewed by: cognet Approved by: cognet
* Merge ACPICA 20130117.jkim2013-01-171-1/+3
|
* Merge ACPICA 20121018.jkim2012-10-231-1/+1
|
* This isn't functionally identical. In some cases a hint to disableeadler2012-10-221-0/+4
| | | | | | | | unit 0 would in fact disable all units. This reverts r241856 Approved by: cperciva (implicit)
* Now that device disabling is generic, remove extraneous code from theeadler2012-10-221-4/+0
| | | | | | | | device drivers that used to provide this feature. Reviewed by: des Approved by: cperciva MFC after: 1 week
* Merge ACPICA 20120816.jkim2012-08-161-12/+4
|
* Execute AcpiLeaveSleepStatePrep() for S1 and reduce code duplication.jkim2012-06-011-2/+2
| | | | MFC after: 3 days
OpenPOWER on IntegriCloud