Re: Problem with s3 suspend to ram

[Rafael J. Wysocki]

On Sunday, 27 of January 2008, G L wrote:
> Hello,

Hi,
 
> Thanks for replying!
> 
> Well I updated Mythbuntu 7.10 to the latest kernel offered, which is 
> 2.6.22-14-generic.

Please don't drop CCs in the next messages, thanks.

Would you be able to install a kernel.org kernel?

Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Please send dmidecode to linux-acpi@vger.kernel.org - Compal HEL8X

[Josue Resende]

[0.00] Kernel command line:
root=UUID=1bc00e49-e21a-47fc-8641-fbd7b557f8dd ro acpi_osi=!Linux
==> /proc/acpi/ac_adapter <==

==> /proc/acpi/alarm <==
2008-01-00 00:38:15

==> /proc/acpi/battery <==

==> /proc/acpi/button <==

==> /proc/acpi/embedded_controller <==

==> /proc/acpi/fan <==

==> /proc/acpi/info <==
version: 20070126

==> /proc/acpi/power_resource <==

==> /proc/acpi/processor <==

==> /proc/acpi/sleep <==
S0 S3 S4 S5

==> /proc/acpi/thermal_zone <==

==> /proc/acpi/video <==

==> /proc/acpi/wakeup <==
Device  S-state   Status   Sysfs node
HDEF  S4 disabled  pci::00:1b.0
PXS3  S5 disabled  pci::04:00.0
LANC  S0 disabled
MODM  S3 disabled
state:   off-line
==> /proc/acpi/battery/BAT1/alarm <==
alarm:   unsupported

==> /proc/acpi/battery/BAT1/info <==
present: yes
design capacity: 4800 mAh
last full capacity:  3732 mAh
battery technology:  rechargeable
design voltage:  11100 mV
design capacity warning: 373 mAh
design capacity low: 113 mAh
capacity granularity 1:  264 mAh
capacity granularity 2:  3780 mAh
model number:HEL8X000
serial number:   3041
battery type:Li-Ion
OEM info:LIBP

==> /proc/acpi/battery/BAT1/state <==
present: yes
capacity state:  ok
charging state:  discharging
present rate:1519 mA
remaining capacity:  426 mAh
present voltage: 10821 mV


[0.00] Kernel command line:
root=UUID=1bc00e49-e21a-47fc-8641-fbd7b557f8dd ro acpi_osi=Linux
==> /proc/acpi/ac_adapter <==

==> /proc/acpi/alarm <==
2008-01-00 00:38:15

==> /proc/acpi/battery <==

==> /proc/acpi/button <==

==> /proc/acpi/embedded_controller <==

==> /proc/acpi/fan <==

==> /proc/acpi/info <==
version: 20070126

==> /proc/acpi/power_resource <==

==> /proc/acpi/processor <==

==> /proc/acpi/sleep <==
S0 S3 S4 S5

==> /proc/acpi/thermal_zone <==

==> /proc/acpi/video <==

==> /proc/acpi/wakeup <==
Device  S-state   Status   Sysfs node
HDEF  S4 disabled  pci::00:1b.0
PXS3  S5 disabled  pci::04:00.0
LANC  S0 disabled
MODM  S3 disabled
state:   off-line
==> /proc/acpi/battery/BAT1/alarm <==
alarm:   unsupported

==> /proc/acpi/battery/BAT1/info <==
present: yes
design capacity: 4800 mAh
last full capacity:  3732 mAh
battery technology:  rechargeable
design voltage:  11100 mV
design capacity warning: 373 mAh
design capacity low: 113 mAh
capacity granularity 1:  264 mAh
capacity granularity 2:  3780 mAh
model number:HEL8X000
serial number:   3041
battery type:Li-Ion
OEM info:LIBP

==> /proc/acpi/battery/BAT1/state <==
present: yes
capacity state:  ok
charging state:  discharging
present rate:1439 mA
remaining capacity:  338 mAh
present voltage: 10819 mV

2008/1/21, Len Brown <[EMAIL PROTECTED]>:
> On Saturday 19 January 2008 16:42, Josue Resende wrote:
>
> > 2008/1/19, Len Brown <[EMAIL PROTECTED]>:
> > > On Sunday 04 November 2007 08:21, Josue Resende wrote:
> > > > System Information
> > > > Manufacturer: COMPAL
> > > > Product Name: HEL81I
> > > > Version: *
> > > > Serial Number: 2057336701224
> > > > UUID: 5D703279-5869-11DB-9D7E-0016D457FA87
> > > > Wake-up Type: Power Switch
> > > > SKU Number: Not Specified
> > > > Family: Not Specified
> > > >
> > > > Handle 0x0002, DMI type 2, 8 bytes
> > > > Base Board Information
> > > > Manufacturer: COMPAL
> > > > Product Name: HEL8X
>
> thanks for the acpidump
>
> Please verify that your battery information and AC/DC
> transitions are properly reported in /proc/acpi/
> both with and without acpi_osi=Linux
>
> -Len
> -
>
> Name (ECDY, 0x05)
> ...
>If (CondRefOf (_OSI, Local0))
> {
> If (_OSI ("Linux"))
> {
> Store (0x03E8, OSYS)
> ## setting OSYS is a NOP, since it gets overwritten
> Store (Zero, ECDY)
> ## clearing ECDY may have implications in wakeup,
> ## battery, and some ACPI general purpose events
> }
>
> If (_OSI ("Windows 2001"))
> {
> Store (0x07D1, OSYS)
>
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sony-laptop on AR series

[Mattia Dongili]

On Sat, Jan 26, 2008 at 05:46:59PM +0200, eaglex wrote:
> > Could you send the output of lspci and upload somewhere the DSDT (or
> > send me provately as I'm not sure about the limits for postings to this
> > list).
> 
> lspci: http://pastebin.ca/873456
> dsdt: http://pastebin.ca/873459

01:00.0 VGA compatible controller: nVidia Corporation G86M [GeForce 8400M GT] 
(rev a1)

eh... this is known not to be working with sony-laptop. Even though the
DSDT exposes the brightness methods the nvidia cards have their own way
to handle dimming the screen.
You can try with nvclock which works for *some* cards.

For now all sony-laptop can do is enable the Fn keys, I'll add your
model to the DMI list asap.

ciao
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sony-laptop on AR series

[eaglex]

> eh... this is known not to be working with sony-laptop. Even though the
> DSDT exposes the brightness methods the nvidia cards have their own way
> to handle dimming the screen.
> You can try with nvclock which works for *some* cards.

Thanks, I'll try nvclock.

> For now all sony-laptop can do is enable the Fn keys, I'll add your
> model to the DMI list asap.

Any chances of getting the rest of the controls working? (like turning
on bluetooth and so on)
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sony-laptop on AR series

[Mattia Dongili]

On Sun, Jan 27, 2008 at 03:16:27PM +0200, eaglex wrote:
...
> > For now all sony-laptop can do is enable the Fn keys, I'll add your
> > model to the DMI list asap.
> 
> Any chances of getting the rest of the controls working? (like turning
> on bluetooth and so on)

well, not until somebody is able to trace which SNC device methods (if
any at all) are called to control the extra features.
Unfortunately there are no specs available for it.

ciao
-- 
mattia
:wq!
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Troubles waking up from suspend (S3) - how to debug?

[Bruno Prémont]

I'm currently trying out suspend (S3) on a few machines but none of them wakes 
up completely/properly (I have a few more hosts I'm planning to try suspend 
on once I can get useful information out of those not waking up properly).

Tested kernels: 2.6.24(-rc8), on one 2.6.23.8

To suspend I enter the following from console:
  echo -n mem > /sys/power/state


Fujitsu-Siemens S7020 laptop (i915GM based):
  Works fine except backlight that remains asleep and Xorg vesa driver
  crashing Xorg.
  It looks like a suspend cycle discards the VideoBIOS shadow copy.
  Adjusting brightness using hotkeys or acpi-fujitsusiemens does not help
  waking up the backlight.
  At best backlight comes back when suspending from Xorg with
  xf86-video-intel-2.2.x but then mode is distorded. Any attempt to fix this
  using xrandr or switch to/from console puts backlight asleep.


Acer Travelmate 660 laptop (i855GM based):
  Laptop suspends as expected but hangs while waking up.


Desktop with MSI nforce based mainboard with Athlon CPU, onboard graphics and 
hdd on HighPoint RR1640 PCI card (USB mouse & keyboard):
  Suspends as expected but hangs while waking up.
  During wakeup I can ping the computer but userspace does not respond (e.g.
  no answer when trying to connect via ssh)
  The display remains off if using vga text console, display comes back with
  garbadge when using nvidiafb (no Xorg running), USB is powered but triggers
  no reactions on keyboard/mouse input


I tried using netconsole on the desktop computer to capture eventual printks 
during resume but I got not a line during wakup. (only suspend progress 
messages before actual suspend)

What can I do to get more information out of those two last machines and find 
out why they don't wake-up properly?


I can provide more details on each of those machines if it can help (lspci, 
kernel config, peripherials, acpidump)

Regards,
Bruno

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Troubles waking up from suspend (S3) - how to debug?

[Stephane Ascoet]

Bruno Prémont a écrit :
I'm currently trying out suspend (S3) on a few machines but none of them wakes 
up completely/properly (I have a few more hosts I'm planning to try suspend 
on once I can get useful information out of those not waking up properly).


Tested kernels: 2.6.24(-rc8), on one 2.6.23.8

To suspend I enter the following from console:
  echo -n mem > /sys/power/state




Bonjour, it seems for me that using echo isn't the right way. You could 
follow instructions at the end of: 



--
Bien cordialement, Stephane Ascoet, conseils pour que la technologie 
soit un progres respectueux de la vie.
Album photo:, 
site:

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version

[Rene Herman]

On 23-01-08 18:38, Thomas Renninger wrote:


isapnp is totally untested. Also the sysfs is rather untested.


If nobody beats me to it I'll debug this myself later on, but as a quick 
heads up:


pnp: the driver 'cs4236_isapnp' has been registered
cs4236_isapnp 01:01.00: driver attached
cs4236_isapnp 01:01.02: driver attached
cs4236_isapnp 01:01.03: driver attached
pnp: Port resource 0 not allocated, cannot assign value
pnp: Port resource 1 not allocated, cannot assign value
pnp: Port resource 2 not allocated, cannot assign value
pnp: Irq resource 0 not allocated, cannot assign value
pnp: DMA resource 0 not allocated, cannot assign value
pnp: DMA resource 1 not allocated, cannot assign value
BUG: unable to handle kernel NULL pointer dereference at virtual address 
000c

printing eip: c10e76d9 *pde = 
Oops:  [#1] PREEMPT
Modules linked in: snd_cs4236 snd_opl3_lib snd_hwdep snd_cs4236_lib 
snd_mpu401_uart snd_rawmidi snd_seq_device snd_cs4231_lib snd_pcm snd_timer 
snd_page_alloc snd soundcore nfsd lockd nfs_acl sunrpc exportfs


Pid: 1353, comm: modprobe Not tainted (2.6.24-local #2)
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at isapnp_set_resources+0x4d/0x132
EAX:  EBX:  ECX: e3c8f000 EDX: 
ESI:  EDI: ef8f5964 EBP: ef8f5800 ESP: e3c8fe5c
 DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
Process modprobe (pid: 1353, ti=e3c8f000 task=ed2c2f90 task.ti=e3c8f000)
Stack: ef8f5800 ef8f5888 f0a4e0a4 ed349000 c10e48c8 c10e373a f0a4e0c0 ef8f5800
   ef8f5800  c10e5101 ef8f5800 f0a4b559 0286 0001 f0a4d780
   c10e330d c12b7c6c ef8f5e00 ed37f140 ed3491bc ef8f5e00 ed37f140 f0a4e0a4
Call Trace:
 [] pnp_start_dev+0x55/0x9e
 [] pnp_request_card_device+0x9b/0xbe
 [] pnp_activate_dev+0x23/0x39
 [] snd_cs423x_pnpc_detect+0xe4/0x35f [snd_cs4236]
 [] pnp_alloc+0xe/0x25
 [] card_probe+0xba/0x107
 [] pnp_register_card_driver+0xa3/0xb3
 [] alsa_card_cs423x_init+0x2f/0x4f [snd_cs4236]
 [] sys_init_module+0x1379/0x149b
 [] unmap_region+0xe5/0x100
 [] syscall_call+0x7/0xb
 ===
Code: ff ff ff c7 85 54 01 00 00 01 00 00 00 eb 18 0f b7 12 8d 44 1b 60 43 
83 c6 1c 0f b6 c0 e8 ce fd ff ff 83 fb 08 74 13 89 f2 03 17 <8b> 42 0c 25 00 
01 00 20 3d 00 01 00 00 74 d5 31 db 31 f6 eb 25

EIP: [] isapnp_set_resources+0x4d/0x132 SS:ESP 0068:e3c8fe5c
---[ end trace f836fd70d1d20199 ]---

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ACPI module for Asus Eee PC

[Carlos Corbacho]

On Saturday 26 January 2008 14:48:24 Eric Cooper wrote:
> I happened to look at the patched asus_acpi.c module that was posted
> by Asus for the Eee PC and noticed that it's 75% dead code -- the Eee
> PC support is just stuck on at the end.  And of course it conflicts
> with the real asus_acpi.ko in any kernel package.
>
> So I cleaned it up, renamed it eeepc_acpi, and packaged it as a
> separate out-of-kernel Debian package that can be built with
> module-assistant.

To submit a driver, it needs to be as a patch against the ACPI Git tree 'test' 
branch.

New laptop drivers should:

1) Be in drivers/misc (asus_acpi is the only leftover in drivers/acpi - 
everything else has already been moved, and no new laptop drivers will be 
accepted in drivers/acpi)

2) proc is deprecated for new drivers - you should be using sysfs

3) #if LINUX_KERNEL_VERSION is an absolute no-no in upstream kernel code. Any 
such instances should be stripped out of the code.

4) Patches should be run through scripts/checkpatch.pl, and new drivers 
especially should be checkpatch clean - you will find it flags up quite a few 
style problems with the code.

If you can address these and then resubmit a proper patch, then you will stand 
a chance of getting this reviewed and accepted into the mainline kernel.

-Carlos
-- 
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] WMI

[Carlos Corbacho]

On Friday 18 January 2008 23:58:18 Carlos Corbacho wrote:
> ANYWR - Another New Year WMI release
>
> Len,
>
> Can you please review at least the first two patches in this series, as I
> would still really like to try and get them into 2.6.25.

Len,

I have a small update for acer-wmi to add another DMI entry queued up - before 
I submit that and re-submit the whole WMI series, is there anything else I 
can do that would help expedite the review of WMI?

I accept that at this stage, acceptance into 2.6.25 is unlikely - but I don't 
think aiming for 2.6.26 at least is entirely unrealistic (I've been posting 
the WMI patches for 'upstream review' since the end of October now, and 
earlier works-in-progress since the beginning of October). The sooner this 
gets looked at, the sooner I can get any problems addressed and this can be 
in a mergeable state for 2.6.26 (and can hopefully sit in -mm for a bit as 
well that way).

-Carlos
-- 
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Allocate pnp resources dynamically via krealloc - working version

[Pekka Enberg]

Hi Thomas,

On Sun, 2008-01-20 at 02:23 +0200, Pekka Enberg wrote:
> > When krealloc() returns NULL, there wasn't enough memory to fit the
> > new size but the original memory region remains unchanged.

On Jan 23, 2008 7:38 PM, Thomas Renninger <[EMAIL PROTECTED]> wrote:
> Thanks Pekka, this one should be better now:

Yeah, the krealloc() bits look good me. Thanks!

 Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Rationalise ACPI backlight implementation

[Matthew Garrett]

On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote:
> - Create a new /sys node with a new name which has the new semantics.

The semantics are the same as they always have been - values between 0 
and max_brightness are valid values. If you've made assumptions about 
what max_brightness is, then that's a bug in the userspace application 
rather than a change in the semantics of the interface.

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Troubles waking up from suspend (S3) - how to debug?

[R. J. Wysocki]

On Sunday, 27 of January 2008, Bruno Prémont wrote:
> I'm currently trying out suspend (S3) on a few machines but none of them 
> wakes 
> up completely/properly (I have a few more hosts I'm planning to try suspend 
> on once I can get useful information out of those not waking up properly).
> 
> Tested kernels: 2.6.24(-rc8), on one 2.6.23.8
> 
> To suspend I enter the following from console:
>   echo -n mem > /sys/power/state
> 

Please try s2ram (http://suspend.sf.net/s2ram-support.html).

> Fujitsu-Siemens S7020 laptop (i915GM based):
>   Works fine except backlight that remains asleep and Xorg vesa driver
>   crashing Xorg.
>   It looks like a suspend cycle discards the VideoBIOS shadow copy.
>   Adjusting brightness using hotkeys or acpi-fujitsusiemens does not help
>   waking up the backlight.
>   At best backlight comes back when suspending from Xorg with
>   xf86-video-intel-2.2.x but then mode is distorded. Any attempt to fix this
>   using xrandr or switch to/from console puts backlight asleep.

This one is on the s2ram whitelist, should work.

> Acer Travelmate 660 laptop (i855GM based):
>   Laptop suspends as expected but hangs while waking up.

This might work with "s2ram -f --vbe_post --vbe_save", please try.
 
> Desktop with MSI nforce based mainboard with Athlon CPU, onboard graphics

What kind?

> and hdd on HighPoint RR1640 PCI card (USB mouse & keyboard):
>   Suspends as expected but hangs while waking up.
>   During wakeup I can ping the computer but userspace does not respond (e.g.
>   no answer when trying to connect via ssh)
>   The display remains off if using vga text console, display comes back with
>   garbadge when using nvidiafb (no Xorg running), USB is powered but triggers
>   no reactions on keyboard/mouse input
> 
> 
> I tried using netconsole on the desktop computer to capture eventual printks 
> during resume but I got not a line during wakup. (only suspend progress 
> messages before actual suspend)
> 
> What can I do to get more information out of those two last machines and find 
> out why they don't wake-up properly?

Please apply the patches 01-11 from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24/patches/
on top of 2.6.24, compile the kernel and install it.  After booting, please do:

# echo core > /sys/power/pm_test
# echo mem > /sys/power/state

and see if the boxes survive it (this causes the suspend/resume sequence to
be executed without acutally suspending, but busy-waiting for 5 sec. instead).

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Rationalise ACPI backlight implementation

[Andrew Morton]

On Mon, 28 Jan 2008 01:25:50 + Matthew Garrett <[EMAIL PROTECTED]> wrote:

> On Sat, Jan 26, 2008 at 10:00:45PM -0800, Andrew Morton wrote:
> > - Create a new /sys node with a new name which has the new semantics.
> 
> The semantics are the same as they always have been - values between 0 
> and max_brightness are valid values. If you've made assumptions about 
> what max_brightness is, then that's a bug in the userspace application 
> rather than a change in the semantics of the interface.
> 

WTH?  My (utterly comedic chase-crap-around-the-tree) brightness script
was:

(
0 sh -c "echo $1 > /proc/acpi/sony/brightness"
0 sh -c "echo $1 > /proc/acpi/sony/brightness_default"
0 sh -c "echo $1 > /sys/class/backlight/sony/brightness"
0 sh -c "echo $1 > /sys/class/backlight/thinkpad_screen/brightness"
) 2>/dev/null

And yes, I had an rc.local command which assumed that 7 (later 8) is max
brightness.

You cannot seriously tell me that if we are to change this range from 0-8
up to 0-100 then this is not a backwards-incompatible change in
semantics.

My /sys/class/backlight/ directory is presently empty.  Rather than trying
to find out why, I think I'll just collapse in laughter.

Guys, sort it out, please.

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Rationalise ACPI backlight implementation

[Matthew Garrett]

On Sun, Jan 27, 2008 at 09:10:13PM -0800, Andrew Morton wrote:

> You cannot seriously tell me that if we are to change this range from 0-8
> up to 0-100 then this is not a backwards-incompatible change in
> semantics.

We're talking about changing 0-100 to 0-something sane, because the 
current driver is quite clearly broken. And yes, I'm perfectly happy to 
say that - the reason that max_brightness is exported is to allow 
userspace to determine what range of values is acceptable, and if 
userspace ignores that then things are going to break for it at some 
point.

-- 
Matthew Garrett | [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/5] ACPI: Add the T-state coordination

[Zhao Yakui]

Hi, all,

This patch series is for T-state coordination.
Patch 01 Set the bit of ACPI_PDC_SMP_T_SWCOORD.
Patch 02 Check the parameter when calling the function of
acpi_processor_get/set_throttling. 
Patch 03 Update the T-state coordination after obtaining _TSD info
Patch 04 Add the t-state event notifier function
Patch 05 Update the t-state for every affected cpu when t-state is
changed 

I've tested this patch set on t61 laptop. It can work on the three
T-state control mode(MSR, SystemIO, FADT).


Thanks,
Yakui

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] ACPI: Update the t-state for every affected cpu when t-state is changed

[Zhao Yakui]

Subject: ACPI : Update the t-state for every affected cpu when t-state is 
changed
>From : Zhao Yakui <[EMAIL PROTECTED]>

According to ACPI spec, the _TSD object provides T-state control cross
logical processor dependency information to OSPM. So the t-state
coordination should be considered when T-state for one cpu is changed.

According to ACPI spec, three types of coordination are defined.
SW_ALL, SW_ANY and HW_ALL.
SW_ALL: it means that OSPM needs to initiate T-state transition on 
all processors in the domain. It is necessary to call throttling set function
for all affected cpus.
SW_ANY: it means that OSPM may initiate T-state transition on any processor in 
the domain. 
HW_ALL: Apec only says that hardware will perform the coordination and doesn't 
recommend how OSPM coordinate T-state among the affected cpus. So it is treated
as the type of SW_ALL. It means that OSPM needs to initiate t-state transition
on all the processors in the domain.

Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
 drivers/acpi/processor_throttling.c |   79 +---
 1 file changed, 74 insertions(+), 5 deletions(-)

Index: linux-2.6/drivers/acpi/processor_throttling.c
===
--- linux-2.6.orig/drivers/acpi/processor_throttling.c
+++ linux-2.6/drivers/acpi/processor_throttling.c
@@ -68,7 +68,7 @@ static int acpi_processor_update_tsd_coo
 
/*
 * Now that we have _TSD data from all CPUs, lets setup T-state
-* coordination among all CPUs.
+* coordination between all CPUs.
 */
for_each_possible_cpu(i) {
pr = processors[i];
@@ -988,6 +988,11 @@ int acpi_processor_set_throttling(struct
 {
cpumask_t saved_mask;
int ret;
+   unsigned int i;
+   struct acpi_processor *match_pr;
+   struct acpi_processor_throttling *p_throttling;
+   struct throttling_tstate t_state;
+   cpumask_t online_throttling_cpus;
 
if (!pr)
return -EINVAL;
@@ -998,12 +1003,76 @@ int acpi_processor_set_throttling(struct
if ((state < 0) || (state > (pr->throttling.state_count - 1)))
return -EINVAL;
 
+   saved_mask = current->cpus_allowed;
+   t_state.target_state = state;
+   p_throttling = &(pr->throttling);
+   cpus_and(online_throttling_cpus, cpu_online_map,
+   p_throttling->shared_cpu_map);
/*
-* Migrate task to the cpu pointed by pr.
+* The throttling notifier will be called for every
+* affected cpu in order to get one proper T-state.
+* The notifier event is THROTTLING_PRECHANGE.
 */
-   saved_mask = current->cpus_allowed;
-   set_cpus_allowed(current, cpumask_of_cpu(pr->id));
-   ret = pr->throttling.acpi_processor_set_throttling(pr, state);
+   for_each_cpu_mask(i, online_throttling_cpus) {
+   t_state.cpu = i;
+   acpi_processor_throttling_notifier(THROTTLING_PRECHANGE,
+   &t_state);
+   }
+   /*
+* The function of acpi_processor_set_throttling will be called
+* to switch T-state. If the coordination type is SW_ALL or HW_ALL,
+* it is necessary to call it for every affected cpu. Otherwise
+* it can be called only for the cpu pointed by pr.
+*/
+   if (p_throttling->shared_type == DOMAIN_COORD_TYPE_SW_ANY) {
+   set_cpus_allowed(current, cpumask_of_cpu(pr->id));
+   ret = p_throttling->acpi_processor_set_throttling(pr,
+   t_state.target_state);
+   } else {
+   /*
+* When the T-state coordination is SW_ALL or HW_ALL,
+* it is necessary to set T-state for every affected
+* cpus.
+*/
+   for_each_cpu_mask(i, online_throttling_cpus) {
+   match_pr = processors[i];
+   /*
+* If the pointer is invalid, we will report the
+* error message and continue.
+*/
+   if (!match_pr) {
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+   "Invalid Pointer for CPU %d\n", i));
+   continue;
+   }
+   /*
+* If the throttling control is unsupported on CPU i,
+* we will report the error message and continue.
+*/
+   if (!match_pr->flags.throttling) {
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+   "Throttling Controll is unsupported "
+   "on CPU %d\n", i));
+   continue;
+   }
+

[PATCH 3/5] ACPI: Update T-state coordination after getting _TSD info

[Zhao Yakui]

Subject: ACPI : Update T-state coordination after getting _TSD info
>From : Zhao Yakui <[EMAIL PROTECTED]>

Accordint to ACPI spec, the _TSD object provides T-state control cross
logical processor dependency information to OSPM. 
After the _TSD data for all cpus are obtained, OSPM will set up
the T-state coordination between CPUs.

Of course if the _TSD doesn't exist or _TSD data is incorrect , it is
assumed that there is no T-state coordination and T-state is changed
independently.

Now there is no proper solution to update T-state coordination after
one cpu is hotplugged. So this patch won't support hotplugged cpu very well.

Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
 drivers/acpi/processor_core.c   |2 
 drivers/acpi/processor_throttling.c |  180 +++-
 include/acpi/processor.h|4 
 3 files changed, 184 insertions(+), 2 deletions(-)

Index: linux-2.6/drivers/acpi/processor_core.c
===
--- linux-2.6.orig/drivers/acpi/processor_core.c
+++ linux-2.6/drivers/acpi/processor_core.c
@@ -1061,6 +1061,8 @@ static int __init acpi_processor_init(vo
 
acpi_processor_ppc_init();
 
+   acpi_processor_throttling_init();
+
return 0;
 
 out_cpuidle:
Index: linux-2.6/include/acpi/processor.h
===
--- linux-2.6.orig/include/acpi/processor.h
+++ linux-2.6/include/acpi/processor.h
@@ -176,6 +176,8 @@ struct acpi_processor_throttling {
u32 address;
u8 duty_offset;
u8 duty_width;
+   u8 tsd_valid_flag;
+   unsigned int shared_type;
struct acpi_processor_tx states[ACPI_PROCESSOR_MAX_THROTTLING];
 };
 
@@ -316,7 +318,7 @@ static inline int acpi_processor_ppc_has
 int acpi_processor_get_throttling_info(struct acpi_processor *pr);
 extern int acpi_processor_set_throttling(struct acpi_processor *pr, int state);
 extern struct file_operations acpi_processor_throttling_fops;
-
+extern void acpi_processor_throttling_init(void);
 /* in processor_idle.c */
 int acpi_processor_power_init(struct acpi_processor *pr,
  struct acpi_device *device);
Index: linux-2.6/drivers/acpi/processor_throttling.c
===
--- linux-2.6.orig/drivers/acpi/processor_throttling.c
+++ linux-2.6/drivers/acpi/processor_throttling.c
@@ -48,6 +48,154 @@ ACPI_MODULE_NAME("processor_throttling")
 static int acpi_processor_get_throttling(struct acpi_processor *pr);
 int acpi_processor_set_throttling(struct acpi_processor *pr, int state);
 
+static int acpi_processor_update_tsd_coord(void)
+{
+   int count, count_target;
+   int retval = 0;
+   unsigned int i, j;
+   cpumask_t covered_cpus;
+   struct acpi_processor *pr, *match_pr;
+   struct acpi_tsd_package *pdomain, *match_pdomain;
+   struct acpi_processor_throttling *pthrottling, *match_pthrottling;
+
+   /*
+* Now that we have _TSD data from all CPUs, lets setup T-state
+* coordination among all CPUs.
+*/
+   for_each_possible_cpu(i) {
+   pr = processors[i];
+   if (!pr)
+   continue;
+
+   /* Basic validity check for domain info */
+   pthrottling = &(pr->throttling);
+
+   /*
+* If tsd package for one cpu is invalid, the coordination
+* among all CPUs is thought as invalid.
+* Maybe it is ugly.
+*/
+   if (!pthrottling->tsd_valid_flag) {
+   retval = -EINVAL;
+   break;
+   }
+   }
+   if (retval)
+   goto err_ret;
+
+   cpus_clear(covered_cpus);
+   for_each_possible_cpu(i) {
+   pr = processors[i];
+   if (!pr)
+   continue;
+
+   if (cpu_isset(i, covered_cpus))
+   continue;
+   pthrottling = &pr->throttling;
+
+   pdomain = &(pthrottling->domain_info);
+   cpu_set(i, pthrottling->shared_cpu_map);
+   cpu_set(i, covered_cpus);
+   /*
+* If the number of processor in the TSD domain is 1, it is
+* unnecessary to parse the coordination for this CPU.
+*/
+   if (pdomain->num_processors <= 1)
+   continue;
+
+   /* Validate the Domain info */
+   count_target = pdomain->num_processors;
+   count = 1;
+
+   for_each_possible_cpu(j) {
+   if (i == j)
+   continue;
+
+   match_pr = processors[j];
+   if (!match_pr)
+   continue;
+
+   match_pthrottling = &(match_pr->throttling);
+  

[PATCH 1/5] ACPI: Set the bif of ACPI_PDC_SMP_T_SWCOORD for _PDC

[Zhao Yakui]

Subject: ACPI: Set the bif of ACPI_PDC_SMP_T_SWCOORD for _PDC
>From : Zhao Yakui <[EMAIL PROTECTED]>

The bit of ACPI_PDC_SMP_T_SWCOORD is set so that OSPM is capable of 
native ACPI throttling software coordination for mutli-processors 
using the _TSD information.


Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
 arch/ia64/kernel/acpi-processor.c |6 ++
 arch/x86/kernel/acpi/processor.c  |6 ++
 2 files changed, 12 insertions(+)

Index: linux-2.6/arch/ia64/kernel/acpi-processor.c
===
--- linux-2.6.orig/arch/ia64/kernel/acpi-processor.c
+++ linux-2.6/arch/ia64/kernel/acpi-processor.c
@@ -45,6 +45,12 @@ static void init_intel_pdc(struct acpi_p
buf[0] = ACPI_PDC_REVISION_ID;
buf[1] = 1;
buf[2] = ACPI_PDC_EST_CAPABILITY_SMP;
+   /*
+* The default of PDC_SMP_T_SWCOORD bit is set for IA64 cpu so
+* that OSPM is capable of native ACPI throttling software
+* coordination using BIOS supplied _TSD info.
+*/
+   buf[2] |= ACPI_PDC_SMP_T_SWCOORD;
 
obj->type = ACPI_TYPE_BUFFER;
obj->buffer.length = 12;
Index: linux-2.6/arch/x86/kernel/acpi/processor.c
===
--- linux-2.6.orig/arch/x86/kernel/acpi/processor.c
+++ linux-2.6/arch/x86/kernel/acpi/processor.c
@@ -46,6 +46,12 @@ static void init_intel_pdc(struct acpi_p
buf[1] = 1;
buf[2] = ACPI_PDC_C_CAPABILITY_SMP;
 
+   /*
+* The default of PDC_SMP_T_SWCOORD bit is set for intel x86 cpu so
+* that OSPM is capable of native ACPI throttling software
+* coordination using BIOS supplied _TSD info.
+*/
+   buf[2] |= ACPI_PDC_SMP_T_SWCOORD;
if (cpu_has(c, X86_FEATURE_EST))
buf[2] |= ACPI_PDC_EST_CAPABILITY_SWSMP;
 


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/5] ACPI: Check parameter when calling acpi_processor_get/set_throttling

[Zhao Yakui]

Subject: ACPI : Check parameter when calling acpi_processor_get/set_throttling
>From : Zhao Yakui <[EMAIL PROTECTED]>

It is necessary to check the parameter when calling the function of 
acpi_processor_get/set_throttling function so as to avoid the NULL 
pointer reference in pr or throttling.

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

Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
 drivers/acpi/processor_throttling.c |   15 +++
 1 file changed, 15 insertions(+)

Index: linux-2.6/drivers/acpi/processor_throttling.c
===
--- linux-2.6.orig/drivers/acpi/processor_throttling.c
+++ linux-2.6/drivers/acpi/processor_throttling.c
@@ -589,6 +589,11 @@ static int acpi_processor_get_throttling
cpumask_t saved_mask;
int ret;
 
+   if (!pr)
+   return -EINVAL;
+
+   if (!pr->flags.throttling)
+   return -ENODEV;
/*
 * Migrate task to the cpu pointed by pr.
 */
@@ -743,6 +748,16 @@ int acpi_processor_set_throttling(struct
 {
cpumask_t saved_mask;
int ret;
+
+   if (!pr)
+   return -EINVAL;
+
+   if (!pr->flags.throttling)
+   return -ENODEV;
+
+   if ((state < 0) || (state > (pr->throttling.state_count - 1)))
+   return -EINVAL;
+
/*
 * Migrate task to the cpu pointed by pr.
 */


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/5] ACPI: Add T-state event notifier function

[Zhao Yakui]

Subject: ACPI : Add T-state event notifier function
>From : Zhao Yakui <[EMAIL PROTECTED]>

The t-state coordination should be considered when T-state for one cpu 
is changed.It means that OSPM should select one proper target T-state for
the all affected cpus before updating T-state. 

So the function of acpi_processor_throttling_notifier is added. 
Before updating T-state it can be called for all  the affected cpus to get 
the proper target T-state, which can meet the requirement of thermal, user and 
_TPC. After updating T-state, it can be called to update T-state flag.

Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
 drivers/acpi/processor_throttling.c |   72 
 1 file changed, 72 insertions(+)

Index: linux-2.6/drivers/acpi/processor_throttling.c
===
--- linux-2.6.orig/drivers/acpi/processor_throttling.c
+++ linux-2.6/drivers/acpi/processor_throttling.c
@@ -45,6 +45,14 @@
 #define _COMPONENT  ACPI_PROCESSOR_COMPONENT
 ACPI_MODULE_NAME("processor_throttling");
 
+struct throttling_tstate {
+   unsigned int cpu;   /* cpu nr */
+   int target_state;   /* target T-state */
+};
+
+#define THROTTLING_PRECHANGE   (1)
+#define THROTTLING_POSTCHANGE  (2)
+
 static int acpi_processor_get_throttling(struct acpi_processor *pr);
 int acpi_processor_set_throttling(struct acpi_processor *pr, int state);
 
@@ -196,6 +204,70 @@ void acpi_processor_throttling_init(void
return;
 }
 
+static int acpi_processor_throttling_notifier(unsigned long event, void *data)
+{
+   struct throttling_tstate *p_tstate = data;
+   struct acpi_processor *pr;
+   unsigned int cpu ;
+   int target_state;
+   struct acpi_processor_limit *p_limit;
+   struct acpi_processor_throttling *p_throttling;
+
+   cpu = p_tstate->cpu;
+   pr = processors[cpu];
+   if (!pr) {
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Invalid pr pointer\n"));
+   return 0;
+   }
+   if (!pr->flags.throttling) {
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Throttling control is "
+   "unsupported on CPU %d\n", cpu));
+   return 0;
+   }
+   target_state = p_tstate->target_state;
+   p_throttling = &(pr->throttling);
+   switch (event) {
+   case THROTTLING_PRECHANGE:
+   /*
+* Prechange event is used to choose one proper t-state,
+* which meets the limits of thermal, user and _TPC.
+*/
+   p_limit = &pr->limit;
+   if (p_limit->thermal.tx > target_state)
+   target_state = p_limit->thermal.tx;
+   if (p_limit->user.tx > target_state)
+   target_state = p_limit->user.tx;
+   if (pr->throttling_platform_limit > target_state)
+   target_state = pr->throttling_platform_limit;
+   if (target_state >= p_throttling->state_count) {
+   printk(KERN_WARNING
+   "Exceed the limit of T-state \n");
+   target_state = p_throttling->state_count - 1;
+   }
+   p_tstate->target_state = target_state;
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "PreChange Event:"
+   "target T-state of CPU %d is T%d\n",
+   cpu, target_state));
+   break;
+   case THROTTLING_POSTCHANGE:
+   /*
+* Postchange event is only used to update the
+* T-state flag of acpi_processor_throttling.
+*/
+   p_throttling->state = target_state;
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "PostChange Event:"
+   "CPU %d is switched to T%d\n",
+   cpu, target_state));
+   break;
+   default:
+   printk(KERN_WARNING
+   "Unsupported Throttling notifier event\n");
+   break;
+   }
+
+   return 0;
+}
+
 /*
  * _TPC - Throttling Present Capabilities
  */


-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html