| Age | Commit message (Collapse) | Author |
|
XXX pullup-8 (by patch with membar_enter/exit)
XXX pullup-9 (by patch with membar_enter/exit)
XXX pullup-10
|
|
|
|
|
|
|
|
|
|
It seems additional code is required to support Baytrail and Lynxpoint.
Disable those support.
|
|
|
|
It was introduced in 2007 for some Xbox thing which was removed in
2011. The API and the threads it spawned have been sitting around
idly for over a decade serving no purpose -- sometimes causing kernel
lock spinouts in the event of panic.
Add ic_tag_private to obviate need for future ABI changes. Not
currently used, but we can privately allocate memory in iic_tag_init
for the purpose later if need be without changing ABI.
XXX kernel revbump -- changes struct i2c_controller
|
|
PR kern/57063
|
|
The Arm ACPI code relied on PCI_NETBSD_CONFIGURE to configure devices that
were not enabled by system firmware. This is not safe to do unless the
firmware explicitly permits it using a device specific method defined in
the PCI firmware spec.
Introduce a new PCI resource manager that discovers what has already been
configured by firmware and allocates from the remaining space. This will
ensure that devices setup by firmware are untouched and only will program
BARs of devices that are not enabled at boot time.
The current implementation assumes that the parent PCI-PCI bridge's
are already configured. A worthwhile improvement in the future would be
to support programming windows for bridges that are not fully configured.
|
|
There's no important state that needs to be recorded, or resources
that need to be relinquished, so detach-on-shutdown isn't necessary.
At the moment, detach-on-shutdown is actually harmful here: if
shutdown is triggered by a sysmon power switch event, then
config_detach will be called from the sysmon taskqueue, but
thinkpad_detach has to wait for ACPI notifiers to finish running
which means waiting for the sysmon taskqueue -> deadlock or crash.
We should maybe arrange to do config_detach from a thread other than
the sysmon taskqueue thread to avoid this class of problems -- but
for now, thinkpad(4) has no reason to detach on shutdown anyway, so
let's take the easy path.
Note: There are many drivers that set DVF_DETACH_SHUTDOWN which
probably shouldn't; the flag means the kernel _will_ detach on
shutdown, not that it _may_. Even those that do need to record state
or relinquish resources might be better served by pmf shutdown hooks
which can skip freeing software resources for faster shutdown.
|
|
- Don't pass the _HID value as the device name; always use the ACPI
node name.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Intel i915 graphics driver needs to receive ACPI VGA 0x80
notifications, but with NetBSD's ACPI API, each ACPI node -- such as
the VGA node -- can only have one notifier attached, and acpivga(4)
already uses it.
|
|
New MI default of 0 serves.
|
|
This way acpica.h always exists unconditionally, so MI code can be
conditional on NACPICA.
It is not great to have such conditionals, but it's better to have
#include "acpica.h"
#ifdef NACPICA > 0
than to have
#if defined(__i386__) || defined(__x86_64__) || defined(__arm__)
#include "acpica.h"
#endif
#ifdef NACPICA > 0
and we can still grep for NACPICA to find places that could be
factored better.
|
|
It is always initialized by config_devalloc before config_devlink
makes it visible to device iteration. No need to reach into private
autoconf internals.
|
|
ADMA2 support in sdhc is mature now, so no need for it to be opt-in.
|
|
|
|
from which the newly created handle will inherit it's implementation.
The root implementation for a new handle type is used if an invalid
"super handle" is passed.
|
|
|
|
SDHC_FLAG_HOSTCAPS means that the driver has to supply both caps and caps2
values.
|
|
RK356x has a DesignWare eMMC controller that is somewhat SDHCI compliant,
with one major problem -- the clock divisor doesn't actually work. To
change the clock card on Rockchip SoCs, the clock frequency needs to be
adjusted in the Clock & Reset Unit (CRU) directly.
The RK356x UEFI implementation introduces a DSM that allows drivers to
request firmware assistance in setting the card clock rate, for instances
like this where the divisor is broken.
From the UEFI README:
Function 1: Set Card Clock
The _DSM control method parameters for the Set Card Clock function are
as follows:
Arguments
* Arg0: UUID = 434addb0-8ff3-49d5-a724-95844b79ad1f
* Arg1: Revision = 0
* Arg2: Function Index = 1
* Arg3: Target card clock rate in Hz.
Return
The actual card clock rate in Hz. Will be less than or equal to the
target clock rate. Returns 0 if the target clock rate could not be set.
|
|
|
|
|
|
For the benefit of GEDs backed by level interrupts, mask the interrupt
source before dispatching the handler to a worker thread and unmask it
after it has been handled.
|
|
|
|
|
|
|
|
|
|
acpiec_bus_read now initializes the whole ACPI_INTEGER like its
signature suggests, so we don't need to pick out the low bits of the
result or carefully avoid undefined behaviour from uninitialized
stack garbage.
|
|
Write as essay about what this is supposed to do, as far as I can
tell from reading acpica and the commit history and the relevant PR.
|
|
The value of the object will be as small as requested, but the whole
uint64_t object will be written as the caller of a space handler
expects, instead of just part of it.
|
|
1. Guarantee everything which happened before acpi_register_notify
has also happened before the notifier is actually called.
2. On acpi_deregister_notify, don't return until the notifier is
definitely not running any more on any CPU, using
AcpiOsWaitEventsComplete.
|
|
|
|
|
|
Makes it hard to follow when there is a big gap between everything
even when there is a tight logical coupling, like setting and testing
an error code.
|
|
On attach: Don't register acpibat_resume handler with pmf or
acpibat_notify_handler with acpi until it is safe to call
acpibat_update_info and acpibat_update_status.
=> This requires the sc->sc_sensor array to be allocated, so allocate
that first.
=> This requires sc->sc_sme to be created, so defer them to
config_interrupts after sysmon_envsys_register.
=> Make sure to register the notify handler before initially polling
the info and status.
On detach: Deregister pmf handler and acpi notifier before we destroy
anything.
|
|
A "compatible" DSD property may either be a string, or a package of
strings. Support both variants in acpi_compatible_match.
|
|
Instead of just asking for cur - 5 or cur + 5, repeatedly ask for
that increment, check whether we actually made progress in that
direction, and if not keep going with another increment, until we hit
the bounds of brightness levels.
I can't find anything in the ACPI spec about this, but my laptop
seems to have trouble with certain levels: 15, 75, 85, 95. It goes
in all other increments of 5 from 5 to 100, just not those ones --
acts as if the change just never happened, so with the old logic the
brightness up/down would get stuck unable to move in either
direction.
This should have no impact on machines where the first increment
actually takes.
|
|
|
|
|
|
The PRP0001 device ID is used to tell the OS to match a driver against
the "compatible" _DSD property. Make acpi_compatible_match aware of this
special device ID and match device compatible entries against the
compatible property when applicable.
|
|
Look for companion controllers using the rules in ACPI 6.3 section 9.14.1
"USB 2.0 Host Controllers and _UPC and _PLD", and only assume TT is
present if we can't find a USB 1.1 companion.
|