Commit Graph

1311 Commits

Author SHA1 Message Date
kib
6b02ef79f2 acpi_hpet: Add Hygon Dhyana support.
Submitted by:	Pu Wen <puwen@hygon.cn>
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D23555
2020-02-07 22:26:11 +00:00
mjg
165ba25434 Add KERNEL_PANICKED macro for use in place of direct panicstr tests 2020-01-12 06:07:54 +00:00
cem
3578d5b360 acpi(4): Add _CID to PNP info string
While a given ACPI device may have 0-N compatibility IDs, in practice most
seem to have 0 or 1.  If one is present, emit it as part of the PNP info
string associated with a device.  This could enable MODULE_PNP_INFO-based
automatic kldload for ACPI drivers associated with a given _CID (but without
a good _HID or _UID identifier).

Reviewed by:	imp, jhb
Differential Revision:	https://reviews.freebsd.org/D22846
2019-12-18 06:22:28 +00:00
cem
d5b17121d8 acpica: Fix for the fix, unfortunately
Follow-up to incomplete pedantic change in r353691 by actually fixing the
default implementation to match the interface type.  Mea culpa.

X-MFC-With:	r353691, r339754
2019-10-17 19:53:55 +00:00
cem
db456c276c acpica: Match ID_PROBE default implementation to interface
After r339754, the additional interface parameter was accidentally left out
of the default acpi_generic_id_probe implementation.  Apparently this does
not cause any real problems, so this fix is mostly stylistic.

No functional change intended.

X-MFC-With:	r339754
2019-10-17 18:45:11 +00:00
jhb
d4c3d2e382 Install an ACPI PCI bus notify handler.
Rescan a PCI bus when the ACPI_NOTIFY_BUS_CHECK event is posted to a
PCI bus.

Reviewed by:	scottl
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D21948
2019-10-15 19:12:09 +00:00
jhb
ce12d00cf5 Support hot insertion and removal of PCI devices on EC2.
Install ACPI notify handlers on PCI devices with an _EJ0 method.  This
handler is invoked when devices are added or removed.

- When an ACPI_NOTIFY_DEVICE_CHECK event posts, rescan the parent bus
  device.  Note that strictly speaking we only need to rescan the
  specified device, but BUS_RESCAN is what is available, so we rescan
  the entire bus.
- When an ACPI_NOTIFY_EJECT_REQUEST event posts, detach the device
  associated with the ACPI handle, invoke the _EJ0 method, and then
  delete the device.

Eventually this might be changed to vector notify events to devd in
userspace where devctl can be used instead to permit more complex
actions such as graceful unmounting of filesystems.

Tested by:	cperciva
Reviewed by:	cperciva, imp, scottl
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D21948
2019-10-15 19:04:39 +00:00
mav
7c414dcc28 Announce PCI Segment Groups supported to PCI host _OSC.
According to ACPI 6.3 specification:
    The OS sets this bit to 1 if it supports PCI Segment Groups as defined
    by the _SEG object, and access to the configuration space of devices
    in PCI Segment Groups as described by this specification.  Otherwise,
    the OS sets this bit to 0.

As far as I see we support both of those as PCI domains for quite a while.

MFC after:	2 months
2019-08-26 17:54:19 +00:00
scottph
be85ca9eb8 Don't set the string "unknown" as a device's location_str
Return an empty string when the location is unknown instead of the
string "unknown". This ensures that all location entries are of
the form key=val.

Suggested by:	imp
Approved by:	jhb (mentor)
MFC after:	1 week
Sponsored by:	Intel Corporation
Differential Revision:	https://reviews.freebsd.org/D21326
2019-08-19 17:51:06 +00:00
jeff
ee0c5182a7 Allocate all per-cpu datastructures in domain correct memory.
Reviewed by:	kib, gallatin (some objections)
Tested by:	pho
Sponsored by:	Netflix
Differential Revision:	https://reviews.freebsd.org/D21242
2019-08-18 23:44:23 +00:00
jhb
32cfb3eef3 Detect invalid PCI devices more correctly in PCI interrupt router drivers.
- Check for an invalid device (vendor is invalid) before reading the
  header type register when examining function 0 of a possible device.
- When iterating over functions of a device, reject any device whose
  16-bit vendor is invalid rather than requiring the full 32-bit
  vendor+device to be all 1's.  In practice the latter check is
  probably fine, but checking the vendor is what the PCI spec
  recommends.

Reviewed by:	imp
MFC after:	2 weeks
Differential Revision:	https://reviews.freebsd.org/D21147
2019-08-06 23:15:04 +00:00
emaste
f7de72081f acpi_resource.c: mention ThunderX2 firmware revision with issue
Presumably this will be fixed in the next version, and the workaround
could eventually be removed.  See r330113 and r346066 details.
2019-08-01 14:02:59 +00:00
markj
a8ad406373 acpi_dock(4): Notify devd(8) on dock status change.
PR:		238138
Submitted by:	Muhammad Kaisar Arkhan <hi@yukiisbo.red>
MFC after:	2 weeks
2019-05-31 15:44:33 +00:00
avg
f5b337b830 acpi_hpet: restore support for timers defined only in HPET table
This fixes a regress introduced in r339754.
After that change the code required that there is a HPET device
in the ACPI namespace.
The problem has been noticed on an PC Engines apu2 system.

While here, fix a small formatting issue.
2019-05-22 08:30:03 +00:00
allanjude
e7fc15972b Correct the way remaining battery life is calculated
Previously, if a system had multiple batteries, the remaining life
percentage was calculated as the average of each battery's percent
remaining. This results in rather incorrect values when you consider the
case of the Thinkpad X270 that has a small 3 cell internally battery, and
a hot-swappable 9 cell battery that is used first. Battery 0 is at 100%,
but battery 1 is at 10%, you do not infact have 55% of your capacity
remaining.

The new method calculates the percentage based on remaining capacity
out of total capacity, giving a much more accurate reading.

PR:		229818
Submitted by:	Keegan Drake H.P. <kd-dev@pm.me>
MFC after:	2 weeks
Sponsored by:	Klara Systems
Event:		Waterloo Hackathon 2019
2019-05-21 21:14:22 +00:00
cem
3038f1af7b Include ktr.h in more compilation units
Similar to r348026, exhaustive search for uses of CTRn() and cross reference
ktr.h includes.  Where it was obvious that an OS compat header of some kind
included ktr.h indirectly, .c files were left alone.  Some of these files
clearly got ktr.h via header pollution in some scenarios, or tinderbox would
not be passing prior to this revision, but go ahead and explicitly include it
in files using it anyway.

Like r348026, these CUs did not show up in tinderbox as missing the include.

Reported by:	peterj (arm64/mp_machdep.c)
X-MFC-With:	r347984
Sponsored by:	Dell EMC Isilon
2019-05-21 20:38:48 +00:00
cem
250e158ddf Extract eventfilter declarations to sys/_eventfilter.h
This allows replacing "sys/eventfilter.h" includes with "sys/_eventfilter.h"
in other header files (e.g., sys/{bus,conf,cpu}.h) and reduces header
pollution substantially.

EVENTHANDLER_DECLARE and EVENTHANDLER_LIST_DECLAREs were moved out of .c
files into appropriate headers (e.g., sys/proc.h, powernv/opal.h).

As a side effect of reduced header pollution, many .c files and headers no
longer contain needed definitions.  The remainder of the patch addresses
adding appropriate includes to fix those files.

LOCK_DEBUG and LOCK_FILE_LINE_ARG are moved to sys/_lock.h, as required by
sys/mutex.h since r326106 (but silently protected by header pollution prior
to this change).

No functional change (intended).  Of course, any out of tree modules that
relied on header pollution for sys/eventhandler.h, sys/lock.h, or
sys/mutex.h inclusion need to be fixed.  __FreeBSD_version has been bumped.
2019-05-20 00:38:23 +00:00
jhb
2b1f6ab13c Refine r330113 to honor the ProducerConsumer flag most of the time.
While it is true that the ACPI spec says that the flag is only valid
on Extended Address Space Descriptors, examples of other descriptors
in the spec use the ProducerConsumer flag explicitly, and real
hardware uses it as well.  In fact, even in the ASL of the Thunder X2
for which r330113 was a workaround, some devices use this flag on
non-Extended Address Space Descriptors correctly.  Instead, only
ignore the flag for resources associated with the UART devices on the
Thunder X2 using the "ARMH0011" HID to identify these devices.

This should fix regressions from ignoring this flag in other contexts
such as Hyper-V.

PR:		235876
Reported by:	Wei Hu <weh@microsoft.com>
Tested by:	emaste (Thunder X2)
MFC after:	2 weeks
2019-04-09 21:18:02 +00:00
jhb
8350e99074 Don't pre-reserve resources for CPU devices when they are set.
CPUs can use shared (RF_SHAREABLE) resources for the I/O port used for
entering and exiting C states.  If this I/O port is included in an ACPI
system resource device, then this happens to still work, but if the port
wasn't part of a system resource device, only the first CPU could allocate
the I/O port and use C states since resource_list_reserve() was always
allocating the resource from nexus0 without RF_SHAREABLE.  By avoiding
the reservation, the flags from the bus_alloc_resource() in the CPU driver
(which include RF_SHAREABLE) are honored.

PR:		236513
Reported by:	stockhausen@collogia.de
Sleuthing by:	avg
Reviewed by:	avg
MFC after:	2 weeks
2019-04-09 19:22:08 +00:00
jkim
c30ced85d1 Merge ACPICA 20190329. 2019-03-29 20:21:28 +00:00
jhb
ae6222b0c3 Drop "All rights reserved" from my copyright statements.
Reviewed by:	rgrimes
MFC after:	1 month
Differential Revision:	https://reviews.freebsd.org/D19485
2019-03-06 22:11:45 +00:00
thj
5152bed271 Fix style after r340832
Reported by:	jhb
Reviewed by:	jhb, jtl
Approved by:	jtl (mentor)
MFC after:	3 days
Differential Revision:	https://reviews/freebsd.org/D18354
2019-02-19 19:04:52 +00:00
jchandra
47b24738b8 arm64 acpi: Add support for IORT table
Add new file arm64/acpica/acpi_iort.c to support the "IO Remapping
Table" (IORT). The table is specified in ARM document "ARM DEN 0049D"
titled "IO Remapping Table Platform Design Document".  The IORT table
has information on the associations between PCI root complexes, SMMU
blocks and GIC ITS blocks in the system.

The changes are to parse and save the information in the IORT table.
The API to use this information is added to sys/dev/acpica/acpivar.h.

The acpi_iort.c also has code to check the GIC ITS nodes seen in the
IORT table with corresponding entries in MADT table (for validity)
and with entries in SRAT table (for proximity information).

Reviewed by:	andrew
Differential Revision:	https://reviews.freebsd.org/D18002
2019-02-07 02:30:33 +00:00
jchandra
6fd503bd86 acpica: support parsing of arm64 affinity in acpi_pxm.c
ACPI SRAT table on arm64 uses GICC entries to provide CPU locality
information. These entries use an AcpiProcessorUid to identify the
CPU (unlike on x86 where the entries have an APIC ID).

Update acpi_pxm.c to extend the cpu_add/cpu_find/cpu_get_info
functions to handle AcpiProcessorUid. Use the updated functions
while parsing ACPI_SRAT_GICC_AFFINITY entry for arm64.

Also update sys/conf/files.arm64 to build acpi_pxm.c when ACPI is
enabled.

Reviewed by:	markj (previous version)
Differential Revision:	https://reviews.freebsd.org/D17942
2018-12-08 19:32:23 +00:00
jchandra
2d1461899d acpica : move SRAT/SLIT parsing to sys/dev/acpica
This moves the architecture independent parts of sys/x86/acpica/srat.c
to sys/dev/acpica/acpi_pxm.c, to be used later on arm64. The function
declarations are moved to sys/dev/acpica/acpivar.h

We also need to update sys/conf/files.{i386,amd64} to use the new file.
No functional changes.

Reviewed by:	markj, imp
Differential Revision:	https://reviews.freebsd.org/D17941
2018-12-08 19:10:58 +00:00
avg
72442df1f5 acpi_MatchHid: use ACPI_MATCHHID_NOMATCH instead of FALSE
Binary representation of both is the same (zero), but
ACPI_MATCHHID_NOMATCH is better for consistency.

MFC after:	4 days
X-MFC with:	r339754
2018-12-07 16:05:39 +00:00
avg
08dcca15a0 acpi_{Device,Battery}IsPresent: restore pre-r330957 behaviour
Specifically, assume that the device is present if evaluation of _STA
method fails.

Before r330957 we ignored any _STA evaluation failure (which was
performed by AcpiGetObjectInfo in ACPICA contrib code) for the purpose
of acpi_DeviceIsPresent and acpi_BatteryIsPresent.  ACPICA 20180313
removed evaluation of _STA from AcpiGetObjectInfo.  So, we added
evaluation of _STA to acpi_DeviceIsPresent and acpi_BatteryIsPresent.
One important difference is that the new code ignored a failure only if
_STA did not exist (AE_NOT_FOUND).  Any other kind of failure was
treated as a fatal failure.  Apparently, on some systems we can get
AE_NOT_EXIST when evaluating _STA.  And that error is not an evil twin
of AE_NOT_FOUND, despite a very similar name, but a distinct error
related to a missing handler for an ACPI operation region.

It's possible that for some people the problem was already fixed by
changes in ACPICA and/or in acpi_ec driver (or even in BIOS) that fixed
the AE_NOT_EXIST failure related to EC operation region.

This work is based on a great analysis by cem and an earlier patch by
Ali Abdallah <aliovx@gmail.com>.

PR:		227191
Reported by:	0mp
MFC after:	2 weeks
2018-12-06 12:34:34 +00:00
kib
ea0a5b75bc Fix off by one in hpet_mmap() csw method.
Reported by:	C Turt <ecturt@gmail.com>
Reviewed by:	alc, markj
Tested by:	pho
admbug:		781
MFC after:	2 weeks
Sponsored by:	The FreeBSD Foundation
2018-12-02 13:27:36 +00:00
bwidawsk
17083afa3e acpi/ec: Fix regression caused by r340644
After r340644 there were two things wrong in cases where there is both
an ECDT, and an EC device exposed via acpica. The first is a rather
trivial situation where the device desc would say ECDT even when it was
not implicitly created via ECDT (not really sure why the compiler
doesn't seem to warn about this).

The other more pervasive issue is that the code is designed to
essentially not do anything for EC probe when its uid was already
created an EC based on the ECDT's uid. The issue was that probe would
still return 0 in this case, and so we'd end up with some weird
duplication. Now to be honest, I'm not actually sure what exactly broke,
but it was definitely not working as intended. To fix this, all that is
really needed is to make sure we return ENXIO when we're probing the
device already added for the ECDT entry. While here though, move the
check for this earlier to avoid wasted cycles when we know after
obtaining the uid that it's duplicative.

There remains one questionable bit here which I don't want to touch -
when doing probe for PNP0C09, if acquiring _UID for the device fails, 0
is assumed, which is a valid UID used by the implicit ECDT.

Reported by:	Charlie Li, et al.
Reviewed by:	jhb
Differential Revision:	https://reviews.freebsd.org/D18311
2018-11-26 19:41:13 +00:00
thj
c3264193e7 Add support for none ACPI battery method batteries
Remove the requirement that a device be a ACPI method battery to be supported
as a battery.

Require now that the device be in the battery devclass and implement the
get_status and get_info functions. This allows batteries which are not ACPI
method batteries to be supported.

Reviewed by: jtl
Approved by: jtl (mentor)
MFC after: 1 Month
Differential Revision:	https://reviews.freebsd.org/D17434
2018-11-23 12:03:01 +00:00
bwidawsk
9f689ee7c3 acpi: fix acpi_ec_probe to only check EC devices
This patch utilizes the fixed_devclass attribute in order to make sure
other acpi devices with params don't get confused for an EC device.

The existing code assumes that acpi_ec_probe is only ever called with a
dereferencable acpi param. Aside from being incorrect because other
devices of ACPI_TYPE_DEVICE may be probed here which aren't ec devices,
(and they may have set acpi private data), it is even more nefarious if
another ACPI driver uses private data which is not dereferancable. This
will result in a pointer deref during boot and therefore boot failure.

On X86, as it stands today, no other devices actually do this (acpi_cpu
checks for PROCESSOR type devices) and so there is no issue. I ran into
this because I am adding such a device which gets probed before
acpi_ec_probe and sets private data. If ARM ever has an EC, I think
they'd run into this issue as well.

There have been several iterations of this patch. Earlier
iterations had ECDT enumerated ECs not call into the probe/attach
functions of this driver. This change was Suggested by: jhb@.

Reviewed by:    jhb
Approved by:	emaste (mentor)
Differential Revision:  https://reviews.freebsd.org/D16635
2018-11-19 18:29:03 +00:00
jchandra
bd91f059fb pci_host_generic, acpi_resource: drop unneeded code
Now that we are handling PCI resources in pci_host_generic_acpi.c, we
don't need these change (made by r336129)

Reviewed by:	andrew
Differential Revision:	https://reviews.freebsd.org/D17792
2018-11-19 03:34:15 +00:00
jchandra
65f57cddff acpica, pci_host_generic_acpi: redo pci_host_generic_acpi.c
This is a major update for pci_host_generic_acpi.c, the current
implementation has some gaps that are better fixed up in one go.
The changes are to:
 * Follow x86 method of not adding PCI resources to PCI host bridge in
   ACPI code. This has been moved to pci_host_generic_acpi.c, where we
   walk thru its resources of the host bridge and add them.
 * Fixup code in pci_host_generic_acpi.c to read all decoded ranges
   and update the 'ranges' property. This allows us to share most of
   the code with generic implementation (and the FDT one).
 * Parse and setup IO ranges and bus ranges when walking the resources
   above. Drop most of the changes related to this from acpica code.
 * Add the ECAM memory area as mem resource 0. Implement the logic to
   get the ECAM area from MCFG (using bus range which we now decode),
   or from _CBA (using _BBN/bus range). Drop aarch64 ifdefs from acpica
   code which did part of this.
 * Switch resource activation to similar code as FDT implementation,
   this can be moved into generic implementation in a later pass.
 * Drop the mechanism of using the 7th bit of bus number as the domain,
   this is not correct and will work only in very specific cases. Use
   _SEG as PCI domain and use the bus ranges of the host bridge to
   provide start bus number.

This commit should not make any functional change to dev/acpica/acpi.c
for other architectures, almost all the changes there are to revert
earlier additions in this file done for aarch64.

Reviewed by:	andrew
Differential Revision:	https://reviews.freebsd.org/D17791
2018-11-19 03:16:16 +00:00
jchandra
51870f602c acpica: rework INTRNG interrupts
On arm64 (where INTRNG is enabled), the interrupts have to be mapped
with ACPI_BUS_MAP_INTR() before adding them as resources to devices.

The earlier code did the mapping before calling acpi_set_resource(),
which bypassed code that checked for PCI link interrupts.

To fix this, move the call to map interrupts into acpi_set_resource()
and that requires additional work to lookup interrupt properties.
The changes here are to:
 * extend acpi_lookup_irq_handler() to lookup an irq in the ACPI
   resources
 * create a helper function acpi_map_intr() which uses the updated
   acpi_lookup_irq_handler() to look up an irq, and then map it
   with ACPI_BUS_MAP_INTR()
 * use acpi_map_intr() in acpi_pcib_route_interrupt() to map
   pci link interrupts.

With these changes, we can drop the ifdefs in acpi_resource.c, and
we can also drop the call for mapping interrupts in generic_timer.c

Reviewed by:	andrew
Differential Revision:	https://reviews.freebsd.org/D17790
2018-11-19 03:02:47 +00:00
jhb
e8969647b4 Make battery emptying rate available as sysctl variable.
Curiously, the in-kernel routines always use the design voltage to
convert from mA to mW, but acpiconf in userland uses the current
voltage.  As a result, this can report a different mW rate than
acpiconf.

Submitted by:	Manuel Stühn <freebsdnewbie@freenet.de>
MFC after:	2 months
Differential Revision:	https://reviews.freebsd.org/D17077
2018-10-30 00:19:44 +00:00
takawata
5499ddf2ec Distinguish _CID match and _HID match and make lower priority probe
when _CID match.

Reviewed by: jhb, imp
Differential Revision:https://reviews.freebsd.org/D16468
2018-10-26 00:05:46 +00:00
imp
2779184949 Update comment for AMI00[12]0 override.
The AML is even stupider than always returning 0. It will only return
non-zero for an OS that reports itself as "Windows 2015", at least
on the Threadripper board's AML that I've examined.

Those AMLs also suggest we may need this quirk for AMI0030 as well.
There may be other cases where we need to override the _STA in a
generic way, so we should consider writing code to do that.
2018-10-25 17:17:11 +00:00
bwidawsk
2127b447f4 acpi: Add an interface to obtain DSM information
The Device Specific Method (_DSM) is on optional object that defines
device specific controls. This will be useful for our power management
controller in upcoming patches. More information can be found in ACPI
spec 6.2 section 9.1.1

https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf

This patch had a minor modification changing ENOMEM to AE_NO_MEMORY
after it got review and approval but before committing.

Test Plan: Tested in my s0ix branch

Reviewed by:	kib
Approved by:	emaste (mentor)
Differential Revision: https://reviews.freebsd.org/D17121
2018-10-22 03:29:54 +00:00
mmacy
5910d436b2 add snps IP uart support / genaralize UART
This is an amalgam of a patch by Doug Ambrisko to
generalize uart_acpi_find_device, imp moving the
ACPI table to uart_dev_ns8250.c and advice by jhb
to work around a bug in the EPYC 3151 BIOS
(the BIOS incorrectly marks the serial ports as
disabled)

Reviewed by: imp
MFC after: 8 weeks
Differential Revision: https://reviews.freebsd.org/D16432
2018-08-19 21:10:21 +00:00
asomers
b3776cb8de Make timespecadd(3) and friends public
The timespecadd(3) family of macros were imported from NetBSD back in
r35029. However, they were initially guarded by #ifdef _KERNEL. In the
meantime, we have grown at least 28 syscalls that use timespecs in some
way, leading many programs both inside and outside of the base system to
redefine those macros. It's better just to make the definitions public.

Our kernel currently defines two-argument versions of timespecadd and
timespecsub.  NetBSD, OpenBSD, and FreeDesktop.org's libbsd, however, define
three-argument versions.  Solaris also defines a three-argument version, but
only in its kernel.  This revision changes our definition to match the
common three-argument version.

Bump _FreeBSD_version due to the breaking KPI change.

Discussed with:	cem, jilles, ian, bde
Differential Revision:	https://reviews.freebsd.org/D14725
2018-07-30 15:46:40 +00:00
wma
00a2c6b638 ARM64: Add support for ThunderX2 PCIe
Submitted by:          Patryk Duda <pdk@semihalf.com>
Obtained from:         Semihalf
Sponsored by:          Cavium
Differential revision: https://reviews.freebsd.org/D15141
2018-07-09 08:55:07 +00:00
avg
da4bc8f61e remove unneeded inclusion of sys/interrupt.h from several files
It's likely that the header was needed in the past for swi(9).
But now that code does not use swi(9) or any other interfaces defined
in sys/interrupt.h.

MFC after:	1 week
2018-07-04 09:07:18 +00:00
trasz
bcab7689a8 Change the group and the permissions on /dev/acpi, to make "acpiconf"
work when called by members of the 'operator' group. They are already
allowed to eg power off the system (via suid shutdown(8)), so they
might as well be permitted to suspend it.

Tested by:	xmj@
Reviewed by:	delphij@
MFC after:	2 weeks
Relnotes:	yes
Sponsored by:	DARPA, AFRL
Differential Revision:	https://reviews.freebsd.org/D16062
2018-07-02 14:15:30 +00:00
markj
6243836bcf Fix the NUMA build for non-x86 platforms.
acpi_map_pxm_to_vm_domainid() is currently implemented only on x86.

MFC after:	1 week
2018-06-04 14:56:02 +00:00
avg
5bfef09f27 call AcpiLeaveSleepStatePrep after re-enabling interrupts
I want to do this change because this call (actually,
AcpiHwLegacyWakePrep) does a memory allocation and ACPI namespace
evaluation.  Although it is not very likely to run into any trouble, it
is still not safe to make those calls with interrupts disabled.
witness(4) and malloc(9) do not currently check for a context with
interrupts disabled via intr_disable and we lack a facility for doing
that.  So, those unsafe operations fly under the radar.  But if
intr_disable in acpi_EnterSleepState was replaced with spinlock_enter
(which it probably should be), then witness and malloc would immediately
complain.

Also, AcpiLeaveSleepStatePrep is documented as called when interrupts
are enabled.  It used to require disabled interrupts, but that
requirement was changed a long time ago when support for _BFS and _GTS
was removed from ACPICA.

The ACPI wakeup sequence is very sensitive to changes. I consider this
change to be correct, but there can be fallouts from it.

What AcpiHwLegacyWakePrep essentially does is writing a value
corresponding to S0 into SLP_TYPx bits of PM1 Control Register(s).
According to ACPI specifications that write should be a NOP as SLP_EN
bit is not set.  But I see in some chipset specifications that they
allow to ignore SLP_EN altogether and to act on a change of SLP_TYPx
alone.

Also, there are a couple of accesses to ACPI hardware before the new
location of the call to AcpiLeaveSleepStatePrep.  One is to clear the
power button status and the other is to enable SCI.  So, the move may
affect the interaction between then OS and ACPI platform.

I have not seen any regressions on my test system, but it's a desktop.

MFC after:	5 weeks
2018-06-01 09:44:23 +00:00
avg
546f863d51 re-synchronize TSC-s on SMP systems after resume, if necessary
The TSC-s are checked and synchronized only if they were good
originally.  That is, invariant, synchronized, etc.

This is necessary on an AMD-based system where after a wakeup from STR I
see that BSP clock differs from AP clocks by a count that roughly
corresponds to one second.  The APs are in sync with each other.  Not
sure if this is a hardware quirk or a firmware bug.

This is what I see after a resume with this change:
    SMP: passed TSC synchronization test after adjustment
    acpi_timer0: restoring timecounter, ACPI-fast -> TSC-low

Reviewed by:	kib
MFC after:	3 weeks
Differential Revision: https://reviews.freebsd.org/D15551
2018-05-25 07:33:20 +00:00
avg
5942b784c9 stop and restart kernel event timers in the suspend / resume cycle
I have a system that is very unstable after resuming from suspend-to-RAM
but only if HPET is used as the event timer.  The theory is that SMM
code / firmware could be enabling HPET for its own uses and unexpected
interrupts cause a trouble for it.  Originally I wanted to solve the
problem in hpet_suspend() method, but that was insufficient as the event
timer could get reprogrammed again.

So, it's better, for my case and in general, to stop the event timer(s)
before entering the hardware suspend.

MFC after:	4 weeks
Differential Revision: https://reviews.freebsd.org/D15413
2018-05-21 20:23:04 +00:00
emaste
f0cc1a044c Use NULL for SYSINIT's last arg, which is a pointer type
Sponsored by:	The FreeBSD Foundation
2018-05-18 17:58:09 +00:00
imp
e1c497727c Use device_quiet_children to silence verbose CPU probe messages.
Have cpu0 be noisy, but all the other CPU devices be quiet on boot.
2018-05-07 21:09:17 +00:00
jkim
619bcfed64 Redo r332918 with the ACPICA API and remove debug.acpi.suspend_deep_bounce.
AcpiOsEnterSleep() was meant to implement this feature.

Reviewed by:	avg
2018-05-03 19:00:50 +00:00