In function acpi_system_write_alarm in file drivers/acpi/sleep/proc.c,
big sec, min, hr, mo, day and yr are counted twice to get reasonable
values, that is very superfluous, we can do that only once.
In additon, /proc/acpi/alarm can set a related value which can be
specified as years MM
On Wed, 26 Dec 2007, Matthew Garrett wrote:
On Wed, Dec 26, 2007 at 02:10:27PM -0800, Andrew Morton wrote:
Vice versa for me. The thinkpad_acpi driver in 2.6.23 _does_ work,
but its interface vanished in 2.6.24-rc5 and the acpi driver does not
work.
As I said, the interface for the
On Wed, 26 Dec 2007, Andrew Morton wrote:
Vice versa for me. The thinkpad_acpi driver in 2.6.23 _does_ work,
but its interface vanished in 2.6.24-rc5 and the acpi driver does not
work.
As I said, give thinkpad-acpi the brightness_enable=1 parameter, and it will
export its backlight interface,
ACSWR - A Christmas Sale WMI release
Patch #1: (WMI - driver and in kernel interface)
Added per GUID event handling callbacks, as per Matthew's suggestion.
Len:
For review, and to go upstream.
(Bar the EC stuff, this code has also been inflictested by acer_acpi users
with my 0.10 releases,
The following is an implementation of the Windows Management
Instrumentation (WMI) ACPI interface mapper (PNP0C14).
What it does:
Parses the _WDG method and exports functions to process WMI method calls,
data block query/ set commands (both based on GUID) and does basic event
handling.
How: WMI
This is a driver for newer Acer (and Wistron) laptops. It adds wireless
radio and bluetooth control, and on some laptops, exposes the mail LED and
LCD backlight.
v1:
* Initial release
v2:
* Replace left over ACPI references with WMI
* Add GUID based autoloading (depends on future work to WMI)
This is based on the 2004 out-of-tree work of Jamey Hicks, to add
support via WMI for controlling the jog dial and wireless on these
tablets.
v1:
Original release
v2:
As per Joshua Wise's comments, change bluetooth to jogdial (an error from
the original driver).
Signed-off-by: Carlos Corbacho
Create a 'wmi' class, and populate it with a virtual device for each GUID.
This also allows us to autoload WMI drivers based on GUID
via MODULE_ALIAS.
Under each GUID are a set of files that can be read and written to from
userspace (these will be fully documented in a later patch).
v1
Until Kay Sievers bus_id variable length code goes in, this is a
temporary workaround.
NOT-Signed-Off-By: Carlos Corbacho [EMAIL PROTECTED]
CC: Len Brown [EMAIL PROTECTED]
CC: Matthew Garrett [EMAIL PROTECTED]
---
drivers/acpi/wmi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
On Wed, 26 Dec 2007, Andrew Morton wrote:
For thinkpad-acpi at least, it is not a regression. 2.6.23/0.16 did NOT
support your thinkpad (it will pretend to work, but it won't work 100% right
as it only supports 8 levels of backlight control).
Well it may have been partially working, but
Hi,
The following patchset is intended to fix the ACPI 1.0 vs ACPI 2.0 suspend
ordering issue described at http://bugzilla.kernel.org/show_bug.cgi?id=9528 and
in a recent LKML thread (http://lkml.org/lkml/2007/12/25/37).
The patches actually do more than that, as I think it's reasonable to
From: Rafael J. Wysocki [EMAIL PROTECTED]
The execution of ACPI global control methods _GTS and _BFS is
currently tied to the preparation to enter a sleep state and to the
leaving of the sleep state, respectively. However, these functions
are called before disabling the nonboot CPUs and after
From: Rafael J. Wysocki [EMAIL PROTECTED]
The preparation to enter an ACPI system sleep state is now tied to
the disabling of GPEs, but the GPEs should not be disabled before
suspending devices. Since on ACPI 1.0x systems the _PTS global
control method should be executed before suspending
From: Rafael J. Wysocki [EMAIL PROTECTED]
The ACPI 1.0 specification wants us to put devices into low power
states after executing the _PTS global control methods, while ACPI
2.0 and later want us to do that in the reverse order. The current
suspend code follows ACPI 2.0 in that respect which
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make acpi_sleep_prepare() static and cause it to print a message
specifying the ACPI system sleep state to be entered (helpful for
debugging the suspend/hibernation code).
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/acpi/sleep/main.c
From: Rafael J. Wysocki [EMAIL PROTECTED]
The ACPI 1.0 specification wants us to put devices into low power
states after executing the _PTS global control methods, while ACPI
2.0 and later want us to do that in the reverse order. The current
hibernation code follows ACPI 2.0 in that respect
From: Rafael J. Wysocki [EMAIL PROTECTED]
On ACPI systems the target state set by acpi_pm_set_target() is
reset by acpi_pm_finish(), but that need not be called in the
suspend fails. For this reason, we need an additional global suspend
callback that will reset the target state regardless of
Rafael J. Wysocki wrote:
On Wednesday, 26 of December 2007, Linus Torvalds wrote:
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
2.0 and later wants us to put devices into low power states before calling
_PTS, ACPI 1.0x
On Thursday 27 December 2007 18:03:52 Rafael J. Wysocki wrote:
Please review (and test, if possible).
Suspend now works properly here with this patch set.
Tested-by: Carlos Corbacho [EMAIL PROTECTED]
--
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
To unsubscribe
On Thursday, 27 of December 2007, Robert Hancock wrote:
Rafael J. Wysocki wrote:
On Wednesday, 26 of December 2007, Linus Torvalds wrote:
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
2.0 and later wants us to put
# dmidecode 2.9
SMBIOS 2.3 present.
63 structures occupying 2290 bytes.
Table at 0x000F0450.
Handle 0xDA00, DMI type 218, 53 bytes
OEM-specific Type
Header and Data:
DA 35 00 DA B2 00 17 0B 0E 38 00 00 80 00 80 01
00 02 80 02 80 01 00 00 A0 00 A0 01 00 58
On Thursday, 27 of December 2007, Carlos Corbacho wrote:
On Thursday 27 December 2007 18:03:52 Rafael J. Wysocki wrote:
Please review (and test, if possible).
Suspend now works properly here with this patch set.
Tested-by: Carlos Corbacho [EMAIL PROTECTED]
Thanks a lot for testing!
Hello.
I frequently work with certain Asterisk-compatible PCI telephony
interfaces that use the zaptel module/driver. This module generates
1000 interrupts per second (yes, I know...) and any noticeable latency
in handling that interrupt can cause significant problems for modulated
data
Hello,
Just sendig the content of dmidecode.
Hope that can help someone someday somewhere...
# dmidecode 2.9
SMBIOS 2.4 present.
22 structures occupying 1012 bytes.
Table at 0x000DC010.
Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: TOSHIBA
Version: V1.70
Rafael J. Wysocki wrote:
Also, as was pointed out, pre-Vista versions of Windows follow ACPI 1.0
and Vista follows 3.0, so 2.0 doesn't really matter since BIOS people
won't test against it. 1.0 specifies that _PTS is to be called before
suspending devices and 3.0 says that the AML must not
On Fri, 2007-12-28 at 06:00 +0800, Lee Howard wrote:
Hello.
I frequently work with certain Asterisk-compatible PCI telephony
interfaces that use the zaptel module/driver. This module generates
1000 interrupts per second (yes, I know...) and any noticeable latency
in handling that
Shaohua Li wrote:
In IOAPIC mode, interrupt priority isn't related with the pin (in your
case, irq 16 or 19), but the vector of the pin. How vector of a pin is
allocated is quite random. Usually driver who calls pci_enable_device
earier will get a lower priority vector.
You used the words
On Thu, 27 Dec 2007, Robert Hancock wrote:
I doubt they would prefer the later ordering in any way that matters, if the
Windows version they were designed for uses the earlier ordering.
Well, I wouldn't say it's abotu preferring one over the other. It's very
possible that the BIOS writers
On Thu, 2007-12-27 at 21:29 -0800, Lee Howard wrote:
Shaohua Li wrote:
In IOAPIC mode, interrupt priority isn't related with the pin (in your
case, irq 16 or 19), but the vector of the pin. How vector of a pin is
allocated is quite random. Usually driver who calls pci_enable_device
29 matches
Mail list logo
