linux-toradex.git/drivers/acpi, branch v2.6.26.7

ACPI: Ignore _BQC object when registering backlight device

2008-10-22T21:13:28+00:00

upstream commmit: c2c789057f075022658b38b498755c29c1ba8055

According to acpi spec , the objectes of  _BCL and _BCM are required if
integrated LCD is present and supports brightness level and the _BQC is
the optional object. So the _BQC object will be ignored when the backlight
device is registered.
At the same time when there is no _BQC object, the current brightness will be
set to the maximum.

http://bugzilla.kernel.org/show_bug.cgi?id=10206

Signed-off-by: Zhao Yakui 
Signed-off-by: Zhang Rui  
Signed-off-by: Andi Kleen 
Cc: Len Brown 
Signed-off-by: Greg Kroah-Hartman

ACPI: Avoid bogus EC timeout when EC is in Polling mode

2008-10-09T03:23:01+00:00

commit 9d699ed92a459cb408e2577e8bbeabc8ec3989e1 upstream

When EC is in Polling mode, OS will check the EC status continually by using
the following source code:
       clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
       while (time_before(jiffies, delay)) {
               if (acpi_ec_check_status(ec, event))
       	            return 0;
               msleep(1);
       }
But msleep is realized by the function of schedule_timeout. At the same time
although one process is already waken up by some events, it won't be scheduled
immediately. So maybe there exists the following phenomena:
     a. The current jiffies is already after the predefined jiffies.
	But before timeout happens, OS has no chance to check the EC
	status again.
     b. If preemptible schedule is enabled, maybe preempt schedule will happen
	before checking loop. When the process is resumed again, maybe
	timeout already happens, which means that OS has no chance to check
	the EC status.

In such case maybe EC status is already what OS expects when timeout happens.
But OS has no chance to check the EC status and regards it as AE_TIME.

So it will be more appropriate that OS will try to check the EC status again
when timeout happens. If the EC status is what we expect, it won't be regarded
as timeout. Only when the EC status is not what we expect, it will be regarded
as timeout, which means that EC controller can't give a response in time.

http://bugzilla.kernel.org/show_bug.cgi?id=9823
http://bugzilla.kernel.org/show_bug.cgi?id=11141

Signed-off-by: Zhao Yakui 
Signed-off-by: Zhang Rui  
Signed-off-by: Andi Kleen 
Signed-off-by: Greg Kroah-Hartman

ACPI: Fix thermal shutdowns

2008-10-09T03:22:48+00:00

commit 9f497bcc695fb828da023d74ad3c966b1e58ad21 upstream

ACPI: Fix thermal shutdowns

Do not use unsigned int if there is test for negative number...

See drivers/acpi/processor_perflib.c
  static unsigned int ignore_ppc = -1;
...
  if (event == CPUFREQ_START && ignore_ppc <= 0) {
       ignore_ppc = 0;
...

Signed-off-by: Milan Broz 
Signed-off-by: Andi Kleen 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T19:43:12+00:00

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger 
Cc: Andi Kleen 
Cc: Len Brown 
Cc: Dave Jones 
Cc: Ingo Molnar 
Cc: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86 ACPI: normalize segment descriptor register on resume

2008-07-05T06:25:40+00:00

Some Dell laptops enter resume with apparent garbage in the segment
descriptor registers (almost certainly the result of a botched
transition from protected to real mode.)  The only way to clean that
up is to enter protected mode ourselves and clean out the descriptor
registers.

This fixes resume on Dell XPS M1210 and Dell D620.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=10927

Signed-off-by: H. Peter Anvin 
Cc: Andrew Morton 
Cc: Pavel Machek 
Cc: pm list 
Cc: Len Brown 
Signed-off-by: Ingo Molnar 
Tested-by: Kirill A. Shutemov 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Ingo Molnar

rtc: fix CMOS time error after writing /proc/acpi/alarm

2008-07-04T17:40:05+00:00

When writing /proc/acpi/alarm in adjust mode, e.g.
	echo "+0000-00-00 00:00:15" >/proc/acpi/alarm
The "century" field should be read and added to "year" field before
writing, otherwise the CMOS time will go back to 2000 years ago, e.g.
	# cat /proc/acpi/alarm
	0008-06-21 11:38:46
Then the system time may be reset to the date of manufacture after
rebooting. This patch fixed this issue.

Signed-off-by: Huacai Chen 
Acked-by: Pavel Machek 
Acked-by: Zhao Yakui 
Acked-by: Alessandro Zummo 
Acked-by: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.

2008-06-26T05:55:27+00:00

Signed-off-by: Len Brown

ACPI: don't walk tables if ACPI was disabled

2008-06-26T05:55:18+00:00

Ingo Molnar wrote:
> -tip auto-testing started triggering this spinlock corruption message
> yesterday:
>
> [    3.976213] calling  acpi_rtc_init+0x0/0xd3
> [    3.980213] ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread F7C50000 could not acquire Mutex [3] [20080321]
> [    3.992213] BUG: spinlock bad magic on CPU#0, swapper/1
> [    3.992213]  lock: c2508dc4, .magic: 00000000, .owner: swapper/1, .owner_cpu: 0

This is apparently because some parts of ACPI, including mutexes, are not
initialized when acpi=off is passed to the kernel.

Reported-by: Ingo Molnar 
Signed-off-by: Vegard Nossum 
Signed-off-by: Len Brown

Merge branch 'bugzilla-9761' into release

2008-06-20T06:47:16+00:00

ACPI: no AC status notification

2008-06-14T05:26:37+00:00

http://bugzilla.kernel.org/show_bug.cgi?id=10695

Signed-off-by: Len Brown