Age | Commit message (Collapse) | Author |
|
COVERITY 1491295
ok kettenis@
|
|
|
|
Previously we refreshed the state of acpiac(4) and acpibat(4)/acpisbs(4)
by queueing fake ACPI events to be processed by the acpi thread.
acpibat(4) using ACPIDEV_POLL meant that its status could be refreshed
first, resulting in an APM_POWER_CHANGE event sent to userland before
the state of acpiac(4) was up to date. Because of this, apmd(8) could
see A/C unplugged when it was in fact plugged, possibly leading to
a wrong decision.
Instead of using fake ACPI events, refresh the status of acpiac(4) and
acpibat(4)/acpisbs(4) right away at DVACT_WAKEUP time. To reuse the
existing refresh code of those drivers, make their ACPI *_notify()
handlers responsible for sending APM_POWER_CHANGE events instead. Also
queue an APM_POWER_CHANGE event right after resume to retain existing
behavior.
This fixes the consistency of data shown to userland, and makes those
drivers less special.
Initially discussed last year (!) with mpi@ at Miod's place.
Feedback and ok jcs@, deraadt@ agrees with the use of DVACT_WAKEUP here.
|
|
debug is enabled
|
|
ok kettenis
|
|
conversion steps). it only contains kernel prototypes for 4 interfaces,
all of which legitimately belong in sys/systm.h, which are already included
by all enqueue_randomness() users.
|
|
no functional change as clflush is currently only done on Intel
|
|
struct acpi_attach_args.
tpm(4) tested by kn@
ok jmatthew@
|
|
Prevents crashes on broken AML.
ok jcs@
|
|
information on ACPI 5.0 and later.
ok krw@, patrick@
|
|
Overall remaining power was computed as the average of the remaining
power of each battery, in percents. This doesn't work with batteries of
different capacity, so use the total capacity and remaining power
instead.
Reported by lidstah, successful tests by lidstah and benno@, ok kettenis@
|
|
Avoids an uninitialized variable warning. ok kettenis@
|
|
Rename surrounding code to reflect that. ok kettenis@
|
|
information in struct acpi_attach_args.
ok mpi@
|
|
into wsdisplay(4). This code is now exposed through
wsdisplay_brightness_{step,zero,cycle} functions that can be called by
any driver that handles brightnes "hotkeys". These functions take
a wsdisplay(4) device pointer as their first argument, which should be
provided if a clear association between events and a particular display
exist. This is used in wskbd(4). Otherwise NULL can be passed and
the code will direct the request at the first wsdisplay(4) that
implements brightness adjustment.
Tested by many. Fixes brightness keys on x395 and other thinkpads with
AMD graphics.
ok patrick@
|
|
|
|
the Raspberry Pi4.
ok patrick@
|
|
ok patrick@
|
|
cache-coherent or not. To implement this, acpi(4) gets two bus_dma tags
and passes the appropriate one when attaching devices based on _CCA.
On i386/amd64, where for all practical purpose DMA is always cache-coherent,
the two tags are the same. But on arm64 they are distinct.
ok patrick@
|
|
the device is present instead.
ok deraadt@
|
|
resource descriptors. Add support for this.
ok deraadt@
|
|
for example, with locking assertions.
OK mpi@, anton@
|
|
kettenis@ notes that ACPI integers are supposed to be unsigned, but
ours are signed. This is a much deeper problem than what I'm looking
to change with this conversion. To work around the issue for now we
can round the sleep interval up to 1 millisecond.
There is a very nasty-looking rwsleep(9) call elsewhere in
dev/acpi/dsdt.c that I'm going to leave as-is for now to avoid
breaking something.
With input from pirofti@, kettenis@, and mortimer@.
Tested by Lucas Raab, Moises Simon, mortimer@, and gkoehler@.
ok kettenis@
|
|
|
|
EOPNOTSUPP is returned when there's no "filterops" for a given fd.
EINVAL when the requested filter isn't supported by the "filterops".
ENXIO means the underlying device is no longer valid/present.
ok visa@
|
|
ok deraadt@
|
|
On certain machines (like the ASUS 1001PXD) _BQC returns an out of
range value. Make acpivout_get_brightness() always return a valid
value in order to not break brightness controls, like the
display.brightness control in wsconsctl(8).
ok patrick
|
|
|
|
adding more filter properties without cluttering the struct.
OK mpi@, anton@
|
|
Do not include <sys/kthread.h> where it is not needed and stop including
<sys/proc.h> in it.
ok visa@, anton@
|
|
no _BQC method. But we need it to attach, since it provides
the events for the brightness keys. Thus, make acpivout(4)
attach enough to register the event handler, but return early
so that it doesn't register itself as ws_[gs]et_param.
ok kettenis@
|
|
calling the ACPI methods. On some machines, like my X395,
those ACPI methods don't allow changing the brightness, so
this allows acpivout(4) to e.g. use amdgpu(4)'s code.
In comparison to the previously committed and backed out
version we now schedule the brightness change on the ACPI
task queue so that we don't run into any recursive locking
issues. Additionally the diff has been modified according
to the recent commit where we make sure that a 5% brightness
change does not result in the same brightness level.
ok jcs@ kn@
|
|
Tested by and ok jcs@
|
|
have no interrupt handler registered.
Avoids interrupt storm on Matebook D reported by brynet@
From James Hastings. ok kettenis@ brynet@
|
|
Not all machines provide levels that scale linearly, e.g. an ThinkPad X230
has 16 levels of exponential scale that end with [50, 67, 100].
Make acpivout_find_brightness() return the BCL's index instead of its value
such that acpivout_brightness_step() is able to fall back to the lower next
value by index in case the 5% heuristic fails.
Tested by Tracey Emery with an T470s
OK patrick jcs
|
|
ok bluhm@
|
|
_SRV method if present.
tested by sthen@
ok jmatthew@
|
|
make the structs const so that the data are put in .rodata.
OK mpi@, deraadt@, anton@, bluhm@
|
|
ok kn@
|
|
don't depend on indirect inclusion from acpidev.h
|
|
AMD SoCs/chipsets.
From James Hastings
|
|
ACPI lock and when we call our own ws_[gs]et_param functions we cannot
take the lock again, because it's non-recursive. Thus we need to find
another way, like not taking the lock if we already have it. But the
solutions need to be discussed first, so back it out in the meantime.
|
|
calling the ACPI methods. On some machines, like my X395,
those ACPI methods don't allow changing the brightness, so
this allows acpivout(4) to e.g. use amdgpu(4)'s code.
ok kettenis@
|
|
backlight controls so that acpivout can. This allows using all of
the fine-grained backlight BCL steps defined in ACPI (usually 100)
instead of the dozen or so available through acpithinkpad's
proprietary ACPI or CMOS interfaces.
This is also needed for future amdgpu work.
|
|
adjust by 1 BCL level as there may be 100 levels. Find the next
brightness level that is at least 5% up or down and use that.
ok kettenis
|
|
Early in the release cycle is the right time to do this.
"yes please" jcs@. ok deraadt@
|
|
|
|
ok deraadt@, jsg@
|
|
ok patrick@
|
|
Several machines have broken AML which reads past the end the end
of an array. Previously this was an aml_die/panic. acpica just warns
on such accesses, so this diff makes us do the same.
ok kettenis, jcs, deraadt
|