ACPI defines two different battery device interfaces: "Control Method"
batteries, in which AML methods are defined in order to get battery
status and set battery alarm thresholds, and a "Smart Battery" device,
which is an SMbus device accessed through the ACPI Embedded Controller
device; this driver knows how to attach to the former sort of device.
As a total kludge, since we haven't wired things up to sysmon/envsys
yet, we report battery status through a once-per-minute kernel printf,
so don't use this driver yet if you want your disk to spin down.
Motivated by and tested on Sony PCG-R505TL laptop, which has
nonfunctional APM.
configure as:
acpibat* at acpi ?
Sample output:
acpibat0 at acpi0: ACPI Battery
acpibat0: Sony Corp. LION
acpibat0: Design 38480mWh, Predicted 38480mWh Warn 120mWh Low 0mWh
acpibat0: discharging: 15112mV cap 25480mWh (66%) rate 16849mW
...
acpibat0: discharging: 15224mV cap 25070mWh (65%) rate 18405mW
...
acpibat0: discharging: 15200mV cap 24310mWh (63%) rate 13771mW
...
acpibat0: charging: 15768mV cap 23330mWh (60%) rate 20388mW
#if 0-out a half-fixed acpi_eval_string() and #if 0 the only call to it.
(Previous code referenced an uninitialized local variable and couldn't
have possibly worked).
(revisions 1.47 & 1.48 effectively backed off):
* for all but vnodes, just fallback to sys_fcntl(); assumming
state of support for F_SETOWN/F_GETOWN and even hardcoding it here is
not right (e.g. rev. 1.47 had this incorrect for DTYPE_PIPE)
* fallback to sys_fcntl() also for vnodes which don't represent tty
* don't need to use FILE_{,UN}USE() here, the code won't block while
using the pointer
* add/fix some comments
incorporate write back support for processors not having a write through
cache.
The current fb_devconfig structure now really holds the device's
configuration and the softc really only holds the attachment information.
This used to be mixed giving rise to weird stuctures and cross references.
The number of vertical syncs before the video memory writeback is triggered
is configurable ... default is to wait for 5 Vsync .. aprox minumum 10
times a second, but more likely in the order of 12,5 times a second. When
printing is in progress no write back is performed... only after the
waiting time. The reasoning behind this is that as long as the screen is
printed too the cache will be purged of dirty data anyway due to the
processing and new screen memory useage.
the newly-allocated msgbuf. (Note, it happened to work before
because nothing used pte afterwards, but in the event something
is added that does, pte should be correct.)
Be more informative about the state of the disk (locked, unloaded etc...)
Send NULL as proc pointer to bus_dma_load if B_PHYS is not set.
Break out softc's from rl.c to rlvar.h for inclusion elsewhere.
- svis, strsvis, strsvisx were not reversible, because they did not encode
\\ unless it was passed in the extras array.
- Fix documentation to match the proper signature of the functions.
