Re: toshiba video brightness

[Luming Yu]

Hi Len,

There are three issues according to your description.
Issue 1:
The missing of /sys/backlight on your Toshiba seems just due to
the sysfs backlight requires bios expose _BCL, _BCM, and _BQC
for returning levels supported, controlling brightness, querying the current
brightness respectively. I checked the DSDT of the Toshiba box. There is
NO _BQC. Without _BQC, the sysfs backlight driver will lose the capability
of returning the current brightness level to user space. Maybe it is
just not important, and need to loose the condition check to register
into back light sysfs layer anyway.

Issue 2: Only the values of 0 and 40 have any effect, the others are a NOP
I will take a closer look at the related methods to check if that is
expected by the BIOS.

Issue 3: cannot remove video module
It is NOT reproducible on my napa. I will see if it is the consequence
of the previous two issues.

Thanks,
Luming

On 3/29/07, Len Brown <[EMAIL PROTECTED]> wrote:

Luming
I've got 2.6.21-rc5 running on a Toshiba Satellite Pro laptop.
The ACPI video drivers seems to supply 2 brightness levels in proc,
but nothing in /sys/backlight, and the toshiba_acpi driver
seems to supply 8 levels in /proc.

what am I missing?

thanks,
-Len


loading the video driver, I see this:
[EMAIL PROTECTED]:/proc/acpi/video> ls -R
.:
VGA

./VGA:
CRT  DOS  info  LCD  POST  POST_info  ROM  TV

./VGA/CRT:
brightness  EDID  info  state

./VGA/LCD:
brightness  EDID  info  state

./VGA/TV:
brightness  EDID  info  state

[EMAIL PROTECTED]:/proc/acpi/video/VGA/LCD> cd /proc/acpi/video/VGA/LCD
[EMAIL PROTECTED]:/proc/acpi/video/VGA/LCD> su
Password:
toshiba:/proc/acpi/video/VGA/LCD # echo 0 > brightness

(this dimmed the screen to minimum)

toshiba:/proc/acpi/video/VGA/LCD # echo 40 > brightness

(this make the screen max brightness)

toshiba:/proc/acpi/video/VGA/LCD # echo 100 > brightness
bash: echo: write error: Invalid argument
toshiba:/proc/acpi/video/VGA/LCD # echo 20 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 10 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 0 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 40 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 50 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 30 > brightness

Only the values of 0 and 40 have any effect, the others are a NOP

toshiba:/proc/acpi/video/VGA/LCD # cd /proc/acpi/toshiba/
toshiba:/proc/acpi/toshiba # ls
fan  keys  lcd  version  video
toshiba:/proc/acpi/toshiba # cat lcd
brightness:  3
brightness_levels:   8
toshiba:/proc/acpi/toshiba # echo brightness:0 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:2 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:3 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:4 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:5 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:6 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:7 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:8 > lcd
bash: echo: write error: Invalid argument
toshiba:/proc/acpi/toshiba #

All of these 8 give a different brightness

video.c: brightness 0 = toshiba_acpi brightness 0
video.c: brightness 40 = toshiba_acpi brightness 3

rmmod toshiba_acpi makes no difference.

toshiba:/proc/acpi/video/VGA/LCD # ls /sys/class/backlight/
toshiba:/proc/acpi/video/VGA/LCD #

toshiba:/proc/acpi/video/VGA/LCD # gunzip -dc /proc/config.gz |grep BACKLIGHT
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_RADEON_BACKLIGHT=y



-
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: test

[Luming Yu]

why do you think so?

On 3/29/07, Conke Hu <[EMAIL PROTECTED]> wrote:

my mail does not work ?

-
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


-
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

test

[Conke Hu]

my mail does not work ?

-
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] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
> 
> On Thu, 29 Mar 2007, Maxim wrote:
> >
> > I am sending here a patch that as was discussed here adds hpet to list 
> > of system devices
> > and adds suspend/resume hooks this way.
> > I tested it and it works fine.
> 
> Ok, it certainly looks better, but it *also* looks like it just assumes 
> the HPET is there. Which would work in testing _with_ a HPET, but would 
> likely break on hardware without one, no?
> 
> Shouldn't there be at least something like a
> 
>   if (!is_hpet_capable())
>   return 0;
> 
> at the top of that init routine? I'd also expect that you'd need to check 
> that "hpet_virt_address" is valid or something?
> 
> (Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
> to use the HPET, and set hpet_virt_address to NULL?)

This is done here

out_nohpet:
iounmap(hpet_virt_address);
hpet_virt_address = NULL;
> 
>   Linus
> 

Hi, 
Of course, I forgot.

I was planning to put sysdev code in hpet_enable()
but it is not possible because this function is called too early.

Thus I put sysdev initialization  in separate function but forgot to 
test for HPET

Thanks a lot.

Best regards
Maxim Levitsky

---
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>

---
 arch/i386/kernel/hpet.c |   68 +++
 1 files changed, 68 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..7c67780 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -310,6 +312,7 @@ int __init hpet_enable(void)
 out_nohpet:
iounmap(hpet_virt_address);
hpet_virt_address = NULL;
+   boot_hpet_disable = 1;
return 0;
 }
 
@@ -524,3 +527,68 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+   unsigned long cfg = hpet_readl(HPET_CFG);
+
+   cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+   hpet_writel(cfg, HPET_CFG);
+
+   return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+   unsigned int id;
+
+   hpet_start_counter();
+
+   id = hpet_readl(HPET_ID);
+
+   if (id & HPET_ID_LEGSUP)
+   hpet_enable_int();
+
+   return 0;
+}
+
+static struct sysdev_class hpet_class = {
+   set_kset_name("hpet"),
+   .suspend= hpet_suspend,
+   .resume = hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+   .id = 0,
+   .cls= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+   int err;
+
+   if (!is_hpet_capable())
+   return 0;
+
+   err = sysdev_class_register(&hpet_class);
+
+   if (!err) {
+   sysdev_register(&hpet_device);
+   if (err)
+   sysdev_class_unregister(&hpet_class);
+   }
+
+   return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
-- 
1.4.4.2

-
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 3/5] ACPI: thinkpad-acpi: add compatibility MODULE_ALIAS entry

[Henrique de Moraes Holschuh]

Add a ibm_acpi module alias for userpace, so that modprobe ibm_acpi will
still load the correct driver.  This alias can be removed in the future,
probably two years from now if nothing warrants removing it sooner.

Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
 drivers/misc/thinkpad_acpi.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index bb789db..90ffc46 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -86,6 +86,9 @@ MODULE_DESCRIPTION(IBM_DESC);
 MODULE_VERSION(IBM_VERSION);
 MODULE_LICENSE("GPL");
 
+/* Please remove this in year 2009 */
+MODULE_ALIAS("ibm_acpi");
+
 #define __unused __attribute__ ((unused))
 
 /
-- 
1.5.0.3

-
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: thinkpad-acpi: cleanup after rename

[Henrique de Moraes Holschuh]

Cleanup documentation, driver strings and other misc stuff, now that the
driver is named "thinkpad-acpi".

Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
 Documentation/thinkpad-acpi.txt |   46 ++
 drivers/misc/thinkpad_acpi.c|   18 +--
 drivers/misc/thinkpad_acpi.h|   21 +
 3 files changed, 49 insertions(+), 36 deletions(-)

diff --git a/Documentation/thinkpad-acpi.txt b/Documentation/thinkpad-acpi.txt
index f409f4b..af18d29 100644
--- a/Documentation/thinkpad-acpi.txt
+++ b/Documentation/thinkpad-acpi.txt
@@ -1,17 +1,22 @@
-   IBM ThinkPad ACPI Extras Driver
+ThinkPad ACPI Extras Driver
 
-Version 0.13
-   31 December 2006
+Version 0.14
+  March 26th, 2007
 
Borislav Deianov <[EMAIL PROTECTED]>
 Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
  http://ibm-acpi.sf.net/
 
 
-This is a Linux ACPI driver for the IBM ThinkPad laptops. It supports
-various features of these laptops which are accessible through the
-ACPI framework but not otherwise fully supported by the generic Linux
-ACPI drivers.
+This is a Linux driver for the IBM and Lenovo ThinkPad laptops. It
+supports various features of these laptops which are accessible
+through the ACPI and ACPI EC framework, but not otherwise fully
+supported by the generic Linux ACPI drivers.
+
+This driver used to be named ibm-acpi until kernel 2.6.21 and release
+0.13-20070314.  It used to be in the drivers/acpi tree, but it was
+moved to the drivers/misc tree and renamed to thinkpad-acpi for kernel
+2.6.22, and release 0.14.
 
 
 Status
@@ -43,6 +48,8 @@ Please include the following information in your report:
 
- ThinkPad model name
- a copy of your DSDT, from /proc/acpi/dsdt
+   - a copy of the output of dmidecode, with serial numbers
+ and UUIDs masked off
- which driver features work and which don't
- the observed behavior of non-working features
 
@@ -53,8 +60,9 @@ Installation
 
 
 If you are compiling this driver as included in the Linux kernel
-sources, simply enable the CONFIG_ACPI_IBM option (Power Management /
-ACPI / IBM ThinkPad Laptop Extras).
+sources, simply enable the CONFIG_THINKPAD_ACPI option, and optionally
+enable the CONFIG_THINKPAD_ACPI_BAY option if you want the
+thinkpad-specific bay functionality.
 
 Features
 
@@ -210,7 +218,7 @@ hot plugging of devices in the Linux ACPI framework. If the 
laptop was
 booted while not in the dock, the following message is shown in the
 logs:
 
-   Mar 17 01:42:34 aero kernel: ibm_acpi: dock device not present
+   Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present
 
 In this case, no dock-related events are generated but the dock and
 undock commands described below still work. They can be executed
@@ -270,7 +278,7 @@ This is due to the current lack of support for hot plugging 
of devices
 in the Linux ACPI framework. If the laptop was booted without the
 UltraBay, the following message is shown in the logs:
 
-   Mar 17 01:42:34 aero kernel: ibm_acpi: bay device not present
+   Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present
 
 In this case, no bay-related events are generated but the eject
 command described below still works. It can be executed manually or
@@ -637,12 +645,12 @@ range. The fan cannot be stopped or started with this 
command.
 
 The ThinkPad's ACPI DSDT code will reprogram the fan on its own when
 certain conditions are met.  It will override any fan programming done
-through ibm-acpi.
+through thinkpad-acpi.
 
-The ibm-acpi kernel driver can be programmed to revert the fan level
-to a safe setting if userspace does not issue one of the fan commands:
-"enable", "disable", "level" or "watchdog" within a configurable
-ammount of time.  To do this, use the "watchdog" command.
+The thinkpad-acpi kernel driver can be programmed to revert the fan
+level to a safe setting if userspace does not issue one of the fan
+commands: "enable", "disable", "level" or "watchdog" within a
+configurable ammount of time.  To do this, use the "watchdog" command.
 
echo 'watchdog ' > /proc/acpi/ibm/fan
 
@@ -686,8 +694,8 @@ separating them with commas, for example:
echo enable,0x > /proc/acpi/ibm/hotkey
echo lcd_disable,crt_enable > /proc/acpi/ibm/video
 
-Commands can also be specified when loading the ibm_acpi module, for
-example:
+Commands can also be specified when loading the thinkpad-acpi module,
+for example:
 
-   modprobe ibm_acpi hotkey=enable,0x video=auto_disable
+   modprobe thinkpad_acpi hotkey=enable,0x video=auto_disable
 
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 90ffc46..ddaedf8 100644
--- a/drivers/misc/thinkpad_acpi.c
+

[PATCH 1/5] ACPI: ibm-acpi: rename driver to thinkpad-acpi

[Henrique de Moraes Holschuh]

Rename the ibm-acpi driver to thinkpad-acpi.  ThinkPads are not even made
by IBM anymore, so it is high time to rename the driver...

The name thinkpad-acpi was used sometime ago by a thinkpad-specific hotkey
driver by Erik Rigtorp, around the 2.6.8-2.6.10 time frame.  The driver
apparently never got merged into mainline (it did make some trips through
-mm).  ibm-acpi was merged soon after, making its debut in 2.6.10.

The reuse of the thinkpad-acpi name shouldn't be a problem as far as user
confusion goes, as Erik's thinkpad-acpi apparently didn't get widespread
use in the Linux ThinkPad community and most hits for thinkpad-acpi in
google point to ibm-acpi anyway.

Erik, if you read this, please consider the reuse of the thinkpad-acpi name
as a compliment to your effort to make ThinkPads more useful to all of us.

Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
 Documentation/{ibm-acpi.txt => thinkpad-acpi.txt} |0 
 drivers/misc/Makefile |2 +-
 drivers/misc/{ibm_acpi.c => thinkpad_acpi.c}  |2 +-
 drivers/misc/{ibm_acpi.h => thinkpad_acpi.h}  |0 
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename Documentation/{ibm-acpi.txt => thinkpad-acpi.txt} (100%)
 rename drivers/misc/{ibm_acpi.c => thinkpad_acpi.c} (100%)
 rename drivers/misc/{ibm_acpi.h => thinkpad_acpi.h} (100%)

diff --git a/Documentation/ibm-acpi.txt b/Documentation/thinkpad-acpi.txt
similarity index 100%
rename from Documentation/ibm-acpi.txt
rename to Documentation/thinkpad-acpi.txt
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 848b398..ebf4ff2 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -12,4 +12,4 @@ obj-$(CONFIG_TIFM_CORE)   += tifm_core.o
 obj-$(CONFIG_TIFM_7XX1)+= tifm_7xx1.o
 obj-$(CONFIG_SGI_IOC4) += ioc4.o
 obj-$(CONFIG_SONY_LAPTOP)  += sony-laptop.o
-obj-$(CONFIG_ACPI_IBM) += ibm_acpi.o
+obj-$(CONFIG_ACPI_IBM) += thinkpad_acpi.o
diff --git a/drivers/misc/ibm_acpi.c b/drivers/misc/thinkpad_acpi.c
similarity index 100%
rename from drivers/misc/ibm_acpi.c
rename to drivers/misc/thinkpad_acpi.c
index ae03b8f..2836516 100644
--- a/drivers/misc/ibm_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -79,7 +79,7 @@
  *  2004-08-09 0.1 initial release, support for X series
  */
 
-#include "ibm_acpi.h"
+#include "thinkpad_acpi.h"
 
 MODULE_AUTHOR("Borislav Deianov, Henrique de Moraes Holschuh");
 MODULE_DESCRIPTION(IBM_DESC);
diff --git a/drivers/misc/ibm_acpi.h b/drivers/misc/thinkpad_acpi.h
similarity index 100%
rename from drivers/misc/ibm_acpi.h
rename to drivers/misc/thinkpad_acpi.h
-- 
1.5.0.3

-
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

[GIT PULL] rename ibm-acpi driver to thinkpad-acpi

[Henrique de Moraes Holschuh]

Len,

Please pull from: 
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test

to receive the following patches *already* in acpi-test:
  ACPI: ibm-acpi: kill trailing whitespace
  ACPI: ibm-acpi: rename some identifiers
  ACPI: ibm-acpi: add header file
  ACPI: ibm-acpi: organize code
  ACPI: ibm-acpi: update copyright notice
  ACPI: ibm-acpi: update documentation
  ACPI: ibm-acpi: move driver to drivers/misc hierarchy

and to receive the following **new** patches:
  ACPI: ibm-acpi: rename driver to thinkpad-acpi
  ACPI: thinkpad-acpi: cleanup Kconfig for thinkpad-acpi
  ACPI: thinkpad-acpi: add compatibility MODULE_ALIAS entry
  ACPI: thinkpad-acpi: cleanup after rename
  ACPI: thinkpad-acpi: update MAINTAINERS

As you can notice from the above, the branch contains the patches you have
already pulled into acpi-test.  I don't know how well git will handle the
merging as some *have* been rebased and whitespace-modified since you last
pulled them (they are now exactly the same of what you have in acpi-test).

I suppose you could just drop the ones already in acpi-test and get them
all again from the above branch, or you can get just the new ones from
this thread using git-am.  I didn't base the branch on acpi-test, as you
previously told me not to do that as it would make matters worse for you.

If you'd rather I prepare these branches in a different way, just tell me
how you'd like them done.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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: thinkpad-acpi: update MAINTAINERS

[Henrique de Moraes Holschuh]

Update MAINTAINERS file for the ibm-acpi -> thinkpad-acpi renaming.

Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
 MAINTAINERS |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index dd6978b..7d42183 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1618,15 +1618,6 @@ W:   http://www.ia64-linux.org/
 T: git kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
 S: Maintained
 
-IBM ACPI EXTRAS DRIVER
-P: Henrique de Moraes Holschuh
-M: [EMAIL PROTECTED]
-L: ibm-acpi-devel@lists.sourceforge.net
-W: http://ibm-acpi.sourceforge.net
-W: http://thinkwiki.org/wiki/Ibm-acpi
-T: git repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
-S: Maintained
-
 SN-IA64 (Itanium) SUB-PLATFORM
 P: Jes Sorensen
 M: [EMAIL PROTECTED]
@@ -3118,6 +3109,15 @@ P:   Chris Zankel
 M: [EMAIL PROTECTED]
 S: Maintained
 
+THINKPAD ACPI EXTRAS DRIVER
+P: Henrique de Moraes Holschuh
+M: [EMAIL PROTECTED]
+L: ibm-acpi-devel@lists.sourceforge.net
+W: http://ibm-acpi.sourceforge.net
+W: http://thinkwiki.org/wiki/Ibm-acpi
+T: git repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
+S: Maintained
+
 UltraSPARC (sparc64):
 P: David S. Miller
 M: [EMAIL PROTECTED]
-- 
1.5.0.3

-
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: thinkpad-acpi: cleanup Kconfig for thinkpad-acpi

[Henrique de Moraes Holschuh]

Since ibm-acpi was renamed to thinkpad-acpi, rename and update its Kconfig
entries and Kconfig-related symbols accordingly.

Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
 drivers/misc/Kconfig |   37 -
 drivers/misc/Makefile|2 +-
 drivers/misc/thinkpad_acpi.c |   26 +-
 drivers/misc/thinkpad_acpi.h |8 
 4 files changed, 38 insertions(+), 35 deletions(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 5d2bcbf..2cd96a3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -122,40 +122,43 @@ config SONY_LAPTOP
 
  Read  for more information.
 
-config ACPI_IBM
-   tristate "IBM ThinkPad Laptop Extras"
+config THINKPAD_ACPI
+   tristate "ThinkPad ACPI Laptop Extras"
depends on X86 && ACPI
select BACKLIGHT_CLASS_DEVICE
---help---
- This is a Linux ACPI driver for the IBM ThinkPad laptops. It adds
+ This is a driver for the IBM and Lenovo ThinkPad laptops. It adds
  support for Fn-Fx key combinations, Bluetooth control, video
  output switching, ThinkLight control, UltraBay eject and more.
- For more information about this driver see 

- and  .
+ For more information about this driver see 
+  and  .
 
- If you have an IBM ThinkPad laptop, say Y or M here.
+ This driver was formely known as ibm-acpi.
 
-config ACPI_IBM_DOCK
+ If you have an IBM or Lenovo ThinkPad laptop, say Y or M here.
+
+config THINKPAD_ACPI_DOCK
bool "Legacy Docking Station Support"
-   depends on ACPI_IBM
+   depends on THINKPAD_ACPI
depends on ACPI_DOCK=n
default n
---help---
- Allows the ibm_acpi driver to handle docking station events.
- This support is obsoleted by CONFIG_HOTPLUG_PCI_ACPI.  It will
- allow locking and removing the laptop from the docking station,
- but will not properly connect PCI devices.
+ Allows the thinkpad_acpi driver to handle docking station events.
+ This support was made obsolete by the generic ACPI docking station
+ support (CONFIG_ACPI_DOCK).  It will allow locking and removing the
+ laptop from the docking station, but will not properly connect PCI
+ devices.
 
  If you are not sure, say N here.
 
-config ACPI_IBM_BAY
+config THINKPAD_ACPI_BAY
bool "Legacy Removable Bay Support"
-   depends on ACPI_IBM
+   depends on THINKPAD_ACPI
default y
---help---
- Allows the ibm_acpi driver to handle removable bays.  It will allow
- disabling the device in the bay, and also generate notifications when
- the bay lever is ejected or inserted.
+ Allows the thinkpad_acpi driver to handle removable bays.  It will
+ eletrically disable the device in the bay, and also generate
+ notifications when the bay lever is ejected or inserted.
 
  If you are not sure, say Y here.
 
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index ebf4ff2..e325164 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -12,4 +12,4 @@ obj-$(CONFIG_TIFM_CORE)   += tifm_core.o
 obj-$(CONFIG_TIFM_7XX1)+= tifm_7xx1.o
 obj-$(CONFIG_SGI_IOC4) += ioc4.o
 obj-$(CONFIG_SONY_LAPTOP)  += sony-laptop.o
-obj-$(CONFIG_ACPI_IBM) += thinkpad_acpi.o
+obj-$(CONFIG_THINKPAD_ACPI)+= thinkpad_acpi.o
diff --git a/drivers/misc/thinkpad_acpi.c b/drivers/misc/thinkpad_acpi.c
index 2836516..bb789db 100644
--- a/drivers/misc/thinkpad_acpi.c
+++ b/drivers/misc/thinkpad_acpi.c
@@ -1040,7 +1040,7 @@ static int light_write(char *buf)
 /* don't list other alternatives as we install a notify handler on the 570 */
 IBM_HANDLE(pci, root, "\\_SB.PCI");/* 570 */
 
-#ifdef CONFIG_ACPI_IBM_DOCK
+#ifdef CONFIG_THINKPAD_ACPI_DOCK
 
 IBM_HANDLE(dock, root, "\\_SB.GDCK",   /* X30, X31, X40 */
   "\\_SB.PCI0.DOCK",   /* 600e/x,770e,770x,A2xm/p,T20-22,X20-21 */
@@ -,13 +,13 @@ static int dock_write(char *buf)
return 0;
 }
 
-#endif /* CONFIG_ACPI_IBM_DOCK */
+#endif /* CONFIG_THINKPAD_ACPI_DOCK */
 
 /*
  * Bay subdriver
  */
 
-#ifdef CONFIG_ACPI_IBM_BAY
+#ifdef CONFIG_THINKPAD_ACPI_BAY
 static int bay_status_supported;
 static int bay_status2_supported;
 static int bay_eject_supported;
@@ -1208,7 +1208,7 @@ static int bay_write(char *buf)
 
return 0;
 }
-#endif /* CONFIG_ACPI_IBM_BAY */
+#endif /* CONFIG_THINKPAD_ACPI_BAY */
 
 /*
  * CMOS subdriver
@@ -2477,7 +2477,7 @@ static struct ibm_struct ibms[] = {
 .read = light_read,
 .write = light_write,
 },
-#ifdef CONFIG_ACPI_IBM_DOCK
+#ifdef CONFIG_THINKPAD_ACPI_D

Re: [ PATCH] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Thu, 29 Mar 2007, Maxim wrote:
>
>   I am sending here a patch that as was discussed here adds hpet to list 
> of system devices
>   and adds suspend/resume hooks this way.
>   I tested it and it works fine.

Ok, it certainly looks better, but it *also* looks like it just assumes 
the HPET is there. Which would work in testing _with_ a HPET, but would 
likely break on hardware without one, no?

Shouldn't there be at least something like a

if (!is_hpet_capable())
return 0;

at the top of that init routine? I'd also expect that you'd need to check 
that "hpet_virt_address" is valid or something?

(Or, better yet, shouldn't we set "boot_hpet_disable" when we decide not 
to use the HPET, and set hpet_virt_address to NULL?)

Linus
-
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] Add suspend/resume for HPET was: Re: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 18:38:48 Linus Torvalds wrote:
> 
> On Wed, 28 Mar 2007, Maxim wrote:
> > 
> > Now I don't have a clue how to set those bits if only HPET is used as 
> > clock source because now clocksources
> > don't have _any_ resume hook.
> 
> One thing that drives me wild about that "clocksource resume" thing is 
> that it seems to think that clocksources are somehow different from any 
> other system devices..
> 
> Why isn't the HPET considered a "device", and has it's own *device* 
> "suspend" and "resume"? Why do we seem to think that only "set_mode()" 
> etc should wake up clock sources?
> 
> It's a *device*, dammit. It should save and resume like one (probably as a 
> system device). The "set_mode()" etc stuff is at a completely different 
> (higher) conceptual level.
> 
> Thomas? It does seem like Maxim has hit the nail on the head (at least 
> partly) on the HPET timer resume problems..
> 
>   Linus
> 


Hi,
I am sending here a patch that as was discussed here adds hpet to list 
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.

---
Add suspend/resume support for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>

---
 arch/i386/kernel/hpet.c |   64 +++
 1 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..ac41476 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -3,6 +3,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
@@ -524,3 +526,65 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 #endif
+
+
+/*
+ * Suspend/resume part
+ */
+
+#ifdef CONFIG_PM
+
+static int hpet_suspend(struct sys_device *sys_device, pm_message_t state)
+{
+   unsigned long cfg = hpet_readl(HPET_CFG);
+
+   cfg &= ~(HPET_CFG_ENABLE|HPET_CFG_LEGACY);
+   hpet_writel(cfg, HPET_CFG);
+
+   return 0;
+}
+
+static int hpet_resume(struct sys_device *sys_device)
+{
+   unsigned int id;
+
+   hpet_start_counter();
+
+   id = hpet_readl(HPET_ID);
+
+   if (id & HPET_ID_LEGSUP)
+   hpet_enable_int();
+
+   return 0;
+}
+
+static struct sysdev_class hpet_class = {
+   set_kset_name("hpet"),
+   .suspend= hpet_suspend,
+   .resume = hpet_resume,
+};
+
+static struct sys_device hpet_device = {
+   .id = 0,
+   .cls= &hpet_class,
+};
+
+
+static __init int hpet_register_sysfs(void)
+{
+   int err;
+
+   err = sysdev_class_register(&hpet_class);
+
+   if (!err) {
+   sysdev_register(&hpet_device);
+   if (err)
+   sysdev_class_unregister(&hpet_class);
+   }
+
+   return err;
+}
+
+device_initcall(hpet_register_sysfs);
+
+#endif
-- 
1.4.4.2

-
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: Developing ACPI for Linux - March 27, 2007

[Len Brown]

On Wednesday 28 March 2007 01:10, Alexey Starikovskiy wrote:
> Len,
> We talked about converting ACPICA tree from CVS to git, and didn't
> find a reason for that.
> I think now it's become interesting again. What if you make snapshot
> "git cvsimport" of CVS  ACPICA (Acpi/source) is enough, and make it
> available as all other ACPI git trees you have?
> 
> It is also possible to modify our conversion scripts to work from this
> snapshot, so it will be easy to try modifications on Linux.

Yes, I think we should look into this.

I don't know if it would be acceptable to the folks on kernel.org
to host the tree, since it contains code that is non-linux too,
but I can ask -- or probably we can find a spot on another server.

thanks,
-Len

-
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: libata-acpi: summary, problems, questions and proposal

[Tejun Heo]

Matthew Garrett wrote:
>> * You'll end up doing _STM/_GTM on ahci controller on some BIOSen - 1. 
>> it can be dangerous 2. you might get partial or incorrect mapping - 
>> think about ICH8-split-to-two-PCI-fn-in-piix-mode case.
> 
> So far I haven't seen any DSDTs that include _GTM and _STM methods for 
> controllers that come up flagged as ahci, though I'm perfectly willing 
> to believe that they're out there...

My ICH8 board seems to.  I'll further look into it and post dsl files.

>> I think PM functions in libata-eh is better place and you also need to 
>> do _GTF after _GTM during resume.
> 
> Well, "need" - I haven't actually found hardware that seems upset about 
> the missing _GTF call :)

_GTF does the password unlocking and device configuration part of _STM.
 ACPI itself might not whine because no other ACPI method depends on
_GTF being executed but functionally it's the most important piece.

Now I think about it, _GTF is eventually done during device revalidation
but that needs to be removed, so we'll need to add it in the resume path.

> But you're right, it ought to be done. Can you 
> point me at the right bits of the libata-eh code? I was trying to work 
> through it earlier, but keeping track of the conditional paths is a bit 
> tricky.

There is a big suspend/resume rewrite patch pending and the
suspend/resume code will look quiet different (simpler) after it.

I think the correct place for _STM/_GTF would be right after
ata_eh_revalidate_and_attach().  As libata allows device hotplugging
while suspended, we probably need to skip _STM/_GTF if the attached
device isn't the one we've seen during suspending.

Another problem is that _GTF might alter device size (number of blocks).
 Currently libata uses device size as one of the metrics to determine
whether the device is the same one it saw last time during revalidation.
 This is pretty good safeguard as IIRC in some rare cases BIOS not only
cuts sectors at the end of the disk but also offsets all the blocks (was
this even standard?  it can't be done using overlay or hpa.  some vendor
extension maybe?).  So, if the different disk size is due to offset and
you continue to operate on the disk as before, you're seriously screwed.

We need to make sure that the device is the same one that we saw during
suspend before doing _STM/_GTF and before _GTF the disk size might
differ.  Recent HPA handling Alan posted should be considered here too.
 Also, HPA programming might interact with _GTF.

>>> I think this is just a matter of making sure that the sata and pata 
>>> handle matching code matches reality now :)
>> Currently 1/2 of libata-acpi code is dealing with the above.  I'm trying 
>> to figure out why it needs to be that complex.
> 
> I wrote a patch at one point that simplified this to an extent 
> (http://lkml.org/lkml/2005/12/7/425), but it got somewhat bogged down in 
> discussion about where the right place to do the binding was. Personally 
> I'd prefer to handle this in a similar way to PCI - that is, register 
> the ata bus with ACPI and then find handles as and when new ata devices 
> are added to that bus. This has the advantage that it's easy to tie ACPI 
> events to specific ata devices, which could then be integrated with the 
> bay and dock drivers.

Yeap, that would be great.  The problem is that libata isn't struct
device'd (yet).  As libata needs sysfs representation anyway, we might
go all the way and implement ATA bus and all.  Duplication between SCSI
and ATA nodes is worrying but I guess we can figure out something.

Thanks.

-- 
tejun
-
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 4/4] acpi/dock: use NULL for pointer

[Len Brown]

Applied.

thanks,
-Len

On Tuesday 27 March 2007 01:38, [EMAIL PROTECTED] wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Use NULL instead of 0 for pointers:
> drivers/acpi/dock.c:677:75: warning: Using plain integer as NULL pointer
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> Cc: Len Brown <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
> 
>  drivers/acpi/dock.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff -puN drivers/acpi/dock.c~acpi-dock-use-null-for-pointer 
> drivers/acpi/dock.c
> --- a/drivers/acpi/dock.c~acpi-dock-use-null-for-pointer
> +++ a/drivers/acpi/dock.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -674,7 +675,7 @@ static ssize_t show_dock_uid(struct devi
>struct device_attribute *attr, char *buf)
>  {
>   unsigned long lbuf;
> - acpi_status status = acpi_evaluate_integer(dock_station->handle, 
> "_UID", 0, &lbuf);
> + acpi_status status = acpi_evaluate_integer(dock_station->handle, 
> "_UID", NULL, &lbuf);
>   if(ACPI_FAILURE(status)) {
>   return 0;
>   }
> _
> 
-
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: WMI vs Linux

[Joshua Wise]

On Wed, 28 Mar 2007, Len Brown wrote:

I was wondering if you could tell me about it.


FYI, to whoever decides to bring this patch forward, "bluetooth" I believe
should be changed to "backlight_control" or some such.

This patch exists in the Ubuntu kernels, too, and has been updated to work
with recent kernels there.

joshua



thanks,
-Len

ps. while you're at it, what is the WACF005 Wacom Digitizer device also in the 
patch --
I don't see that upstream either.
-
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


-
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 1/4] cuidle: fix boot hang

[Len Brown]

Applied
(and cpuidle branch restored to acpi-test tree)

thanks,
-Len

On Tuesday 27 March 2007 01:38, [EMAIL PROTECTED] wrote:
> From: Venkatesh Pallipadi <[EMAIL PROTECTED]>
> 
> Patch for cpuidle boot hang reported by Larry Finger here.
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.2/2025.html
> 
> Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
> Cc: Len Brown <[EMAIL PROTECTED]>
> Cc: Larry Finger <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
> 
>  drivers/cpuidle/cpuidle.c |   26 +++---
>  drivers/cpuidle/driver.c  |4 ++--
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff -puN drivers/cpuidle/cpuidle.c~cpuidle-fix-boot-hang 
> drivers/cpuidle/cpuidle.c
> --- a/drivers/cpuidle/cpuidle.c~cpuidle-fix-boot-hang
> +++ a/drivers/cpuidle/cpuidle.c
> @@ -119,6 +119,7 @@ static int cpuidle_add_device(struct sys
>  
>   dev = &per_cpu(cpuidle_devices, cpu);
>  
> + dev->cpu = cpu;
>   mutex_lock(&cpuidle_lock);
>   if (cpu_is_offline(cpu)) {
>   mutex_unlock(&cpuidle_lock);
> @@ -129,15 +130,26 @@ static int cpuidle_add_device(struct sys
>   mutex_unlock(&cpuidle_lock);
>   return 0;
>   }
> - dev->status |= CPUIDLE_STATUS_DETECTED;
> - list_add(&dev->device_list, &cpuidle_detected_devices);
> - cpuidle_add_sysfs(sys_dev);
> - if (cpuidle_curr_driver)
> - cpuidle_attach_driver(dev);
> - if (cpuidle_curr_governor)
> - cpuidle_attach_governor(dev);
> + if (cpuidle_curr_driver) {
> + if (cpuidle_attach_driver(dev))
> + goto err_ret;
> + }
> +
> + if (cpuidle_curr_governor) {
> + if (cpuidle_attach_governor(dev)) {
> + cpuidle_detach_driver(dev);
> + goto err_ret;
> + }
> + }
> +
>   if (cpuidle_device_can_idle(dev))
>   cpuidle_install_idle_handler();
> +
> + list_add(&dev->device_list, &cpuidle_detected_devices);
> + cpuidle_add_sysfs(sys_dev);
> + dev->status |= CPUIDLE_STATUS_DETECTED;
> +
> +err_ret:
>   mutex_unlock(&cpuidle_lock);
>  
>   return 0;
> diff -puN drivers/cpuidle/driver.c~cpuidle-fix-boot-hang 
> drivers/cpuidle/driver.c
> --- a/drivers/cpuidle/driver.c~cpuidle-fix-boot-hang
> +++ a/drivers/cpuidle/driver.c
> @@ -37,8 +37,8 @@ int cpuidle_attach_driver(struct cpuidle
>   ret = cpuidle_curr_driver->init(dev);
>   if (ret) {
>   module_put(cpuidle_curr_driver->owner);
> - printk(KERN_ERR "cpuidle: driver %s failed to attach to cpu 
> %d\n",
> - cpuidle_curr_driver->name, dev->cpu);
> + printk(KERN_INFO "cpuidle: driver %s failed to attach to "
> + "cpu %d\n", cpuidle_curr_driver->name, dev->cpu);
>   } else {
>   if (dev->status & CPUIDLE_STATUS_GOVERNOR_ATTACHED)
>   cpuidle_rescan_device(dev);
> _
> -
> 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
> 
-
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 3/4] cpuidle: unsigned bitfield

[Len Brown]

applied

thanks,
-len

On Tuesday 27 March 2007 01:38, [EMAIL PROTECTED] wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> A 1-bit bitfield has no room for a sign bit.
> drivers/cpuidle/governors/ladder.c:54:16: error: dubious bitfield without 
> explicit `signed' or `unsigned'
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> Cc: Venkatesh Pallipadi <[EMAIL PROTECTED]>
> Cc: Len Brown <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> ---
> 
>  drivers/cpuidle/governors/ladder.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff -puN drivers/cpuidle/governors/ladder.c~cpuidle-unsigned-bitfield 
> drivers/cpuidle/governors/ladder.c
> --- a/drivers/cpuidle/governors/ladder.c~cpuidle-unsigned-bitfield
> +++ a/drivers/cpuidle/governors/ladder.c
> @@ -51,7 +51,7 @@ struct ladder_device_state {
>  
>  struct ladder_device {
>   struct ladder_device_state states[CPUIDLE_STATE_MAX];
> - int bm_check:1;
> + unsigned int bm_check:1;
>   unsigned long bm_check_timestamp;
>   unsigned long bm_activity; /* FIXME: bm activity should be global */
>   int last_state_idx;
> _
> -
> 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
> 
-
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: WMI vs Linux

[Len Brown]

On Wednesday 28 March 2007 17:55, Jamey wrote:
> 
> The patch was designed for the HP TC1100 tablet computer. It has a
> builtin Wifi module whose power supply is controlled via WMI. The state
> is persistent across reboots, but I was not happy needing to have a
> Windows partition just to turn Wifi and Bluetooth on and off. Actually,
> I did not care about Bluetooth but I wanted to ensure Wifi was on. That
> part of the driver seems to work.
>
> Also, I could not find a good way to detect that it was a TC1100.

yeah, this is a problem -- as it stands (stood) the driver binds
as a generic WMI driver...

> Perhaps it should probe for PNP0C14 and the WACF005 and unload itself if
> those are not both present. Given the total lack of response I got when
> I sent that patch to LKML, I was quite amused to find it running on all
> sorts of machines because it was picked up by some distributions (e.g.,
> Mandrake, Ubuntu).

It is no longer possible to shock me with what some distros ship...

> And because of the aforementioned lack of 
> identifiers, the driver stays loaded on all sorts of machines.
> Fortunately it is rather small. If you have any suggestions, I'm willing
> to update it.
> 
> I would pretty much have to agree that WMI is unfriendly.  I had the
> spec for WMI for some of the HP laptops, NC4000 I think, but I couldn't
> really do much with it. The NC4000 ACPI seemed to be totally different
> from the TC1100 one.
> 
> But I guess this driver is one instance where Linux is able to use the
> WMI stuff.

Well, you did more with WMI than I thought would be possible on Linux.

I think at a minimum, we should have a small driver upstream that
binds on PNP0C14, spits out a message that the system has Windows
proprietary firmware extensions, and acts as a place where folks
who care about WMI them can try to hack together something useful...

> Matthew wrote:

> It would be helpful to export as much WMI information as possible - we 
> can supply information to utilise it via HAL, which would at least 
> provide support for doing things like poking the wireless and bluetooth 
> hardware on the old HP tablets.
> 
> I agree that WMI functionality is generally a bad sign, but where we can 
> drive it I think we probably should be.

Well, if you think you can do something useful with it...
My only request is that the source not live in drivers/acpi/ --
I'd rather it live with the platform specific drivers that use ACPI,
eg. drivers/misc/wmi.c  You think?
 
> > ps. while you're at it, what is the WACF005 Wacom Digitizer device also in 
> > the patch --
> > I don't see that upstream either.
> 
> It's handled by 8250_pnp.c now.

good to know.

So, do we have a volunteer to cobble together an upstream wmi.c?

thanks,
-Len




-
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: libata-acpi: summary, problems, questions and proposal

[Matthew Garrett]

On Thu, Mar 29, 2007 at 10:42:03AM +0900, Tejun Heo wrote:

> Yeap, I think it's in the right direction but we need to go further.
> 
> * I'm not sure whether the complex walk libata-acpi is doing is justifiable.

Yeah, that may well be less than ideal.

> * You'll end up doing _STM/_GTM on ahci controller on some BIOSen - 1. 
> it can be dangerous 2. you might get partial or incorrect mapping - 
> think about ICH8-split-to-two-PCI-fn-in-piix-mode case.

So far I haven't seen any DSDTs that include _GTM and _STM methods for 
controllers that come up flagged as ahci, though I'm perfectly willing 
to believe that they're out there...

> I think PM functions in libata-eh is better place and you also need to 
> do _GTF after _GTM during resume.

Well, "need" - I haven't actually found hardware that seems upset about 
the missing _GTF call :) But you're right, it ought to be done. Can you 
point me at the right bits of the libata-eh code? I was trying to work 
through it earlier, but keeping track of the conditional paths is a bit 
tricky.

> >I think this is just a matter of making sure that the sata and pata 
> >handle matching code matches reality now :)
> 
> Currently 1/2 of libata-acpi code is dealing with the above.  I'm trying 
> to figure out why it needs to be that complex.

I wrote a patch at one point that simplified this to an extent 
(http://lkml.org/lkml/2005/12/7/425), but it got somewhat bogged down in 
discussion about where the right place to do the binding was. Personally 
I'd prefer to handle this in a similar way to PCI - that is, register 
the ata bus with ACPI and then find handles as and when new ata devices 
are added to that bus. This has the advantage that it's easy to tie ACPI 
events to specific ata devices, which could then be integrated with the 
bay and dock drivers.

-- 
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: libata-acpi: summary, problems, questions and proposal

[Tejun Heo]

Hello, Matthew.

Matthew Garrett wrote:

On Wed, Mar 28, 2007 at 04:30:02PM +0900, Tejun Heo wrote:

Hi Tejun,

Firstly, could I ask you to take a look at the patch in 
http://permalink.gmane.org/gmane.linux.acpi.devel/22066/ ? It deals with 
some of these issues.


Yeap, I've seen the patch.  That's why you're on the cc list in the 
first place.  :-)



ACPI support implementation in libata-dev supports both IDE and SATA
ACPI object layouts and subset of ATA ACPI methods - _SDD and _GTF.
It incorrectly uses ap->cbl (the port's cable type) to choose between
the two ACPI layouts.  Association between the host and its ACPI
object is performed every time ACPI methods are invoked but the
association between an ATA device and its ACPI object is cached in
ata_device object.


These issues are both fixed in my patch, I believe.


Yeap, I think it's in the right direction but we need to go further.

* I'm not sure whether the complex walk libata-acpi is doing is justifiable.

* You'll end up doing _STM/_GTM on ahci controller on some BIOSen - 1. 
it can be dangerous 2. you might get partial or incorrect mapping - 
think about ICH8-split-to-two-PCI-fn-in-piix-mode case.



2-2. Missing proper _GTM/_STM support.  As stated above, although -mm
contains _GTM/_STM support, it does not hook it to regular
exception handling path and thus _GTF cannot be used in a lot of
cases.


I've added _GTM and _STM support over suspend/resume. Right now they're 
in the host power management code - I'm not sure whether they should be 
here or the SCSI glue layer?


I think PM functions in libata-eh is better place and you also need to 
do _GTF after _GTM during resume.



2-3. Misplaced _GTF hook.  _GTF currently is called prior to every
device configuration.  This is unnecessary and incorrect.  The
ACPI spec specifies that _GTM/_STM and _GTF should be executed
during suspend/resume cycles not on every reset or
reconfiguration.  This, for example, causes the following
problem.


That should be quite easily fixable with the above patch.


Yeap.


4-1. Depending on how questions in section 3 are answered, fix and
clean up ATA host/device <-> ACPI object association.  Whether
IDE or SATA native style hierarchy is used should be determined
by driver flag not cable type.  e.g. ahci and sata_sil24 should
use SATA native style hierarchy while ata_piix should use IDE
hierarchy whether the port is SATA or PATA.


I think this is just a matter of making sure that the sata and pata 
handle matching code matches reality now :)


Currently 1/2 of libata-acpi code is dealing with the above.  I'm trying 
to figure out why it needs to be that complex.


Anyways, I think your patch is a step in the right direction, so 
depending on how ACPI gurus enlighten us here, we can base further fix 
on your patch.  Let's see how the questions are answered.


Thanks.

--
tejun
-
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 22:42:00 Linus Torvalds wrote:
> 
> On Wed, 28 Mar 2007, David Brownell wrote:
> >
> > On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> > 
> > > It's a *device*, dammit. It should save and resume like one (probably as 
> > > a 
> > > system device). The "set_mode()" etc stuff is at a completely different 
> > > (higher) conceptual level.
> > 
> > Agreed, except about "probably as a system device".
> > 
> > Last I checked, there was no good reason to use sysdev suspend()/resume()
> > rather than platform_device suspend_late()/early_resume().  Which more
> > or less means no good reason to use sysdev in new code...
> 
> I won't disagree - it might well be much nicer to just show it in the 
> "real" device tree. I'm not 100% sure where in the tree it would go, 
> though. It should probably be "inside" the root entry, before any of the 
> PCI buses. It's generally what we've used those "system device" things 
> for, but I agree that it would be better to just make system devices show 
> up early on the regular device list than it is to have them be special 
> cases.
> 
> Bit I think that's a separate (and fairly small) issue compared to the 
> "don't use the clocksource infrastructure as a make-believe suspend/resume 
> mechanism" problem that Maxim's patch had.
> 
> (Maxim, don't take that the wrong way - I think your analysis and patch 
> were great, I just think another organization would be better)

Exactly, I agree completely
I said that my patch was a  temporary fix, and I agree that the best way is to 
create a new system device
and use its suspend/resume hooks to bring HPET back to life on resume.

> 
> > Also, making HPET use the legacy mode seems like a step backwards.
> 
> I don't think that's actually "legacy" in any sense but the interrupt 
> delivery, where the "legacy mode" bit is not so much that the HPET itself 
> is "legacy" but that it *replaces* legacy devices.
> 
> But I may have misunderstood the thing. I'm an old fart, so I know the old 
> timers much better than I know the new ones ;). Somebody feel free to hit 
> me with the clue-2x4.
> 
>   Linus
> 

Best regards,
Maxim Levitsky
-
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: WMI vs Linux

[Matthew Garrett]

On Wed, Mar 28, 2007 at 03:44:41PM -0400, Len Brown wrote:

> I was wondering if you could tell me about it.
> I was just about to write a little driver that binds to PNP0C14 and tells the
> user that they should not buy machines with WMI extensions and run Linux on 
> them --
> but maybe an exception to that rule already exists?

It would be helpful to export as much WMI information as possible - we 
can supply information to utilise it via HAL, which would at least 
provide support for doing things like poking the wireless and bluetooth 
hardware on the old HP tablets.

I agree that WMI functionality is generally a bad sign, but where we can 
drive it I think we probably should be.

> ps. while you're at it, what is the WACF005 Wacom Digitizer device also in 
> the patch --
> I don't see that upstream either.

It's handled by 8250_pnp.c now.
-- 
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 22:59:26 David Brownell wrote:
> On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> > On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> 
> > > 
> > > Also, making HPET use the legacy mode seems like a step backwards.
> 
> > It is not 'legacy' mode,
> > It is a legacy replacement mode.
> 
> Typo, sorry.
> 
> 
> > It this mode HPET takes over IRQ0 and IRQ 8 and provides this way
> > replacement for PIT and RTC periodic function 
> 
> It's that RTC periodic thing that bothers me, I don't mind about
> the PIT.  Remember that IRQ8 is also used for other RTC functions.
> 
> Now, if there were a way to tell rtc-cmos that HPET is active,
> and arrange some kind of handshake ... that would be different.
> 
> - Dave
> 

Yes,
When HPET is active it eats RTC IRQ,
So the only way out is to emulate RTC using HPET,
It is done this way in old rtc driver, rtc-cmos should do the same.

Of course suspend resume is not supported at all by old rtc driver

I already wrote complete support for suspend/resume for old rtc driver 
(I wrote it long time ago)

Now I fixed it to support HPET , and this way I discovered that HPET 
doesn't have suspend resume functions

I will do last checks now and send this patch very soon

I am also planning to add support of HPET and suspend/resume for 
rtc-cmos, but I didn't start this yet.

Best regards,
Maxim Levitsky





-
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: 2.6.21-rc5-mm2 -- ACPI problems (lid switch broken, always shows running from AC, plugging in AC hangs machine)

[Andrew Morton]

On Wed, 28 Mar 2007 13:55:54 -0700
"Miles Lane" <[EMAIL PROTECTED]> wrote:

> My laptop (HP dv1240us) is always showing that my laptop is plugged
> into AC power, even when it is running off of the battery.  When I
> plug into the AC after running on the battery, the machine immediately
> locks up.  Also, the laptop lid button isn't working -- pressing it
> doesn't trigger a suspend.

OK, thanks.

If you have time, could you please test

2.6.21-rc5 +
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/origin.patch
 +
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm2/broken-out/git-acpi.patch

which will allow us to eliminate any non-acpi patches.

And please keep an eye on these bugs for us, don't let us merge these
problems into 2.6.22.  It is bad of us to allow known failures to propagate
into mainline and it has happened a couple of times in recent months.

-
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 1:42 pm, Linus Torvalds wrote:
> 
> I won't disagree - it might well be much nicer to just show it in the 
> "real" device tree. I'm not 100% sure where in the tree it would go, 
> though. It should probably be "inside" the root entry, before any of the 
> PCI buses. 

Mixing "inside" and "before" is a small linguistic clue about
one of the issues with driver model PM.  Off topic here; and
in terms of suspend/resume callback sequencing that answer
shouldn't matter much for HPET (as I understand things).


> It's generally what we've used those "system device" things  
> for, but I agree that it would be better to just make system devices show 
> up early on the regular device list than it is to have them be special 
> cases.

Yes -- where "platform_device" is a regular Joe-Sixpack kind of
device, but "sysdev" is a special case.


> Bit I think that's a separate (and fairly small) issue compared to the 
> "don't use the clocksource infrastructure as a make-believe suspend/resume 
> mechanism" problem that Maxim's patch had.

Agreed -- although isn't it the "clockevent" change which is at issue?

A "clockevent" thingie wraps various kinds of timer IRQs; the clocksource
is conceptually just a free run counter.  Clocksources have been around
for a while, with no particular problems.

It's clockevent sources have been the problem with dynamic tick solutions
all along, since they mask such chaos inside x86 hardware and interact
with so many different parts of the kernel.  ;)

- Dave


> (Maxim, don't take that the wrong way - I think your analysis and patch 
> were great, I just think another organization would be better)
-
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 1:19 pm, Maxim wrote:
> On Wednesday 28 March 2007 21:38:55 David Brownell wrote:

> > 
> > Also, making HPET use the legacy mode seems like a step backwards.

>   It is not 'legacy' mode,
> It is a legacy replacement mode.

Typo, sorry.


> It this mode HPET takes over IRQ0 and IRQ 8 and provides this way
> replacement for PIT and RTC periodic function 

It's that RTC periodic thing that bothers me, I don't mind about
the PIT.  Remember that IRQ8 is also used for other RTC functions.

Now, if there were a way to tell rtc-cmos that HPET is active,
and arrange some kind of handshake ... that would be different.

- Dave
-
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Wed, 28 Mar 2007, David Brownell wrote:
>
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> 
> > It's a *device*, dammit. It should save and resume like one (probably as a 
> > system device). The "set_mode()" etc stuff is at a completely different 
> > (higher) conceptual level.
> 
> Agreed, except about "probably as a system device".
> 
> Last I checked, there was no good reason to use sysdev suspend()/resume()
> rather than platform_device suspend_late()/early_resume().  Which more
> or less means no good reason to use sysdev in new code...

I won't disagree - it might well be much nicer to just show it in the 
"real" device tree. I'm not 100% sure where in the tree it would go, 
though. It should probably be "inside" the root entry, before any of the 
PCI buses. It's generally what we've used those "system device" things 
for, but I agree that it would be better to just make system devices show 
up early on the regular device list than it is to have them be special 
cases.

Bit I think that's a separate (and fairly small) issue compared to the 
"don't use the clocksource infrastructure as a make-believe suspend/resume 
mechanism" problem that Maxim's patch had.

(Maxim, don't take that the wrong way - I think your analysis and patch 
were great, I just think another organization would be better)

> Also, making HPET use the legacy mode seems like a step backwards.

I don't think that's actually "legacy" in any sense but the interrupt 
delivery, where the "legacy mode" bit is not so much that the HPET itself 
is "legacy" but that it *replaces* legacy devices.

But I may have misunderstood the thing. I'm an old fart, so I know the old 
timers much better than I know the new ones ;). Somebody feel free to hit 
me with the clue-2x4.

Linus
-
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 21:38:55 David Brownell wrote:
> On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:
> 
> > It's a *device*, dammit. It should save and resume like one (probably as a 
> > system device). The "set_mode()" etc stuff is at a completely different 
> > (higher) conceptual level.
> 
> Agreed, except about "probably as a system device".
> 
> Last I checked, there was no good reason to use sysdev suspend()/resume()
> rather than platform_device suspend_late()/early_resume().  Which more
> or less means no good reason to use sysdev in new code...
> 
> 
> Also, making HPET use the legacy mode seems like a step backwards.
> 
> - Dave
> 


Hi,
It is not 'legacy' mode,
It is a legacy replacement mode.
It this mode HPET takes over IRQ0 and IRQ 8 and provides this way replacement 
for PIT and RTC periodic function

Best regards,
Maxim Levitsky

-
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

WMI vs Linux

[Len Brown]

Jamey,
google stumbled across this patch:
http://www.th.ph.bham.ac.uk/staff/schofield/linux/tc1100/linux-2.6.9-tc1100-wmi.patch
with your name on it.

I was wondering if you could tell me about it.
I was just about to write a little driver that binds to PNP0C14 and tells the
user that they should not buy machines with WMI extensions and run Linux on 
them --
but maybe an exception to that rule already exists?

thanks,
-Len

ps. while you're at it, what is the WACF005 Wacom Digitizer device also in the 
patch --
I don't see that upstream either.
-
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: [linux-pm] [3/6] 2.6.21-rc4: known regressions

[David Brownell]

On Wednesday 28 March 2007 9:38 am, Linus Torvalds wrote:

> It's a *device*, dammit. It should save and resume like one (probably as a 
> system device). The "set_mode()" etc stuff is at a completely different 
> (higher) conceptual level.

Agreed, except about "probably as a system device".

Last I checked, there was no good reason to use sysdev suspend()/resume()
rather than platform_device suspend_late()/early_resume().  Which more
or less means no good reason to use sysdev in new code...


Also, making HPET use the legacy mode seems like a step backwards.

- Dave
-
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

toshiba video brightness

[Len Brown]

Luming
I've got 2.6.21-rc5 running on a Toshiba Satellite Pro laptop.
The ACPI video drivers seems to supply 2 brightness levels in proc,
but nothing in /sys/backlight, and the toshiba_acpi driver
seems to supply 8 levels in /proc.

what am I missing?

thanks,
-Len


loading the video driver, I see this:
[EMAIL PROTECTED]:/proc/acpi/video> ls -R
.:
VGA

./VGA:
CRT  DOS  info  LCD  POST  POST_info  ROM  TV

./VGA/CRT:
brightness  EDID  info  state

./VGA/LCD:
brightness  EDID  info  state

./VGA/TV:
brightness  EDID  info  state

[EMAIL PROTECTED]:/proc/acpi/video/VGA/LCD> cd /proc/acpi/video/VGA/LCD
[EMAIL PROTECTED]:/proc/acpi/video/VGA/LCD> su
Password:
toshiba:/proc/acpi/video/VGA/LCD # echo 0 > brightness

(this dimmed the screen to minimum)

toshiba:/proc/acpi/video/VGA/LCD # echo 40 > brightness

(this make the screen max brightness)

toshiba:/proc/acpi/video/VGA/LCD # echo 100 > brightness
bash: echo: write error: Invalid argument
toshiba:/proc/acpi/video/VGA/LCD # echo 20 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 10 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 0 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 40 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 50 > brightness
toshiba:/proc/acpi/video/VGA/LCD # echo 30 > brightness

Only the values of 0 and 40 have any effect, the others are a NOP

toshiba:/proc/acpi/video/VGA/LCD # cd /proc/acpi/toshiba/
toshiba:/proc/acpi/toshiba # ls
fan  keys  lcd  version  video
toshiba:/proc/acpi/toshiba # cat lcd
brightness:  3
brightness_levels:   8
toshiba:/proc/acpi/toshiba # echo brightness:0 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:2 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:3 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:4 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:5 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:6 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:7 > lcd
toshiba:/proc/acpi/toshiba # echo brightness:8 > lcd
bash: echo: write error: Invalid argument
toshiba:/proc/acpi/toshiba #

All of these 8 give a different brightness

video.c: brightness 0 = toshiba_acpi brightness 0
video.c: brightness 40 = toshiba_acpi brightness 3

rmmod toshiba_acpi makes no difference.

toshiba:/proc/acpi/video/VGA/LCD # ls /sys/class/backlight/
toshiba:/proc/acpi/video/VGA/LCD #  

toshiba:/proc/acpi/video/VGA/LCD # gunzip -dc /proc/config.gz |grep BACKLIGHT
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_RADEON_BACKLIGHT=y

-
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: [3/6] 2.6.21-rc4: known regressions

[Randy Dunlap]

On Wed, 28 Mar 2007 20:04:57 +0200 Michael S. Tsirkin wrote:

> > Subject: first disk access after resume takes several minutes
> >  ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> > References : http://lkml.org/lkml/2007/3/8/117
> >  http://lkml.org/lkml/2007/3/25/20
> > Submitter  : Michael S. Tsirkin <[EMAIL PROTECTED]>
> 
> ...
> 
> > Subject: after resume: X hangs after drawing a couple of windows
> > References : http://lkml.org/lkml/2007/3/8/117
> > Submitter  : Michael S. Tsirkin <[EMAIL PROTECTED]>
> > Status : unknown
> 
> ...
> 
> > > > > From: Jeff Chua <[EMAIL PROTECTED]>
> > > > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > > > with/without CONFIG_NO_HZ.
> > 
> > Quoting Maxim <[EMAIL PROTECTED]>:
> > 
> > Hi,
> > I almost sure Iknow why this happens,
> > The problem is that both hpet clock source
> > and hpet clockevents doesn't have a suspend/resume function
> > On resume we should enable the main counter _and_ enable
> > legacy replacement mode, On my system main counter in
> > enabled, by I think by bios, but legacy replacement mode is
> > not, so if a system doesn't use lapic as a tick source, but
> > use hpet+broadcast, it will hang for sure on resume, and i
> > tested it
> > 
> > The patch below is a temporally fix, until
> > clock-events and clocksources will get proper suspend/resume
> > hooks:
> > 
> > Regards,
> > Maxim Levitsky
> 
> Bingo!
> 
> The patch below fixes the two problems (listed above) with
> resume from RAM that I have observed on my T60 with
> 2.6.21-rc5: with this patch applied, and with CONFIG_NO_HZ
> unset, date advances correctly, X functions properly and
> there is no delay on first disk access.
> 
> Thanks very much.
> 
> ---
> > Add suspend/resume for HPET
> > Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>
> 
> Maxim, do you plan to send this upstream?

with whitespace fixes, please...


> Acked-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
> 
> ---
> 
> diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
> index 0fd9fba..a1ec79e 100644
> --- a/arch/i386/kernel/hpet.c
> +++ b/arch/i386/kernel/hpet.c
> @@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
>   unsigned long cfg, cmp, now;
>   uint64_t delta;
>  
> +
> + if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
> + {

if (mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN) {

> + unsigned long cfg = hpet_readl(HPET_CFG);
> + cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
> + hpet_writel(cfg, HPET_CFG);
> + 

delete above line.

> + }
> + 
> +
>   switch(mode) {
>   case CLOCK_EVT_MODE_PERIODIC:
>   delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: [3/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

* Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:

> Bingo!
> 
> The patch below fixes the two problems (listed above) with resume from 
> RAM that I have observed on my T60 with 2.6.21-rc5: with this patch 
> applied, and with CONFIG_NO_HZ unset, date advances correctly, X 
> functions properly and there is no delay on first disk access.
> 
> Thanks very much.
[...]
> 
> Maxim, do you plan to send this upstream?

we'll fix this the right way tomorrow, by adding a proper suspend/resume 
sysdev handler - the lapic clockevents driver already has that. Maxim 
definitely deserves alot of kudos for having found this bug!

Ingo
-
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: [3/6] 2.6.21-rc4: known regressions

[Michael S. Tsirkin]

> Subject: first disk access after resume takes several minutes
>  ('date' does not advance after resume from RAM, CONFIG_NO_HZ=n)
> References : http://lkml.org/lkml/2007/3/8/117
>  http://lkml.org/lkml/2007/3/25/20
> Submitter  : Michael S. Tsirkin <[EMAIL PROTECTED]>

...

> Subject: after resume: X hangs after drawing a couple of windows
> References : http://lkml.org/lkml/2007/3/8/117
> Submitter  : Michael S. Tsirkin <[EMAIL PROTECTED]>
> Status : unknown

...

> > > > From: Jeff Chua <[EMAIL PROTECTED]>
> > > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > > with/without CONFIG_NO_HZ.
> 
> Quoting Maxim <[EMAIL PROTECTED]>:
> 
> Hi,
>   I almost sure Iknow why this happens,
>   The problem is that both hpet clock source
>   and hpet clockevents doesn't have a suspend/resume function
>   On resume we should enable the main counter _and_ enable
>   legacy replacement mode, On my system main counter in
>   enabled, by I think by bios, but legacy replacement mode is
>   not, so if a system doesn't use lapic as a tick source, but
>   use hpet+broadcast, it will hang for sure on resume, and i
>   tested it
>   
>   The patch below is a temporally fix, until
>   clock-events and clocksources will get proper suspend/resume
>   hooks:
> 
>   Regards,
>   Maxim Levitsky

Bingo!

The patch below fixes the two problems (listed above) with
resume from RAM that I have observed on my T60 with
2.6.21-rc5: with this patch applied, and with CONFIG_NO_HZ
unset, date advances correctly, X functions properly and
there is no delay on first disk access.

Thanks very much.

---
> Add suspend/resume for HPET
> Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>

Maxim, do you plan to send this upstream?

Acked-by: Michael S. Tsirkin <[EMAIL PROTECTED]>

---

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..a1ec79e 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
unsigned long cfg, cmp, now;
uint64_t delta;
 
+
+   if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
+   {
+   unsigned long cfg = hpet_readl(HPET_CFG);
+   cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+   hpet_writel(cfg, HPET_CFG);
+   
+   }
+   
+
switch(mode) {
case CLOCK_EVT_MODE_PERIODIC:
delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;

-- 
MST
-
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: libata-acpi: summary, problems, questions and proposal

[Matthew Garrett]

On Wed, Mar 28, 2007 at 04:30:02PM +0900, Tejun Heo wrote:

Hi Tejun,

Firstly, could I ask you to take a look at the patch in 
http://permalink.gmane.org/gmane.linux.acpi.devel/22066/ ? It deals with 
some of these issues.

> ACPI support implementation in libata-dev supports both IDE and SATA
> ACPI object layouts and subset of ATA ACPI methods - _SDD and _GTF.
> It incorrectly uses ap->cbl (the port's cable type) to choose between
> the two ACPI layouts.  Association between the host and its ACPI
> object is performed every time ACPI methods are invoked but the
> association between an ATA device and its ACPI object is cached in
> ata_device object.

These issues are both fixed in my patch, I believe.

> 2-2. Missing proper _GTM/_STM support.  As stated above, although -mm
> contains _GTM/_STM support, it does not hook it to regular
> exception handling path and thus _GTF cannot be used in a lot of
> cases.

I've added _GTM and _STM support over suspend/resume. Right now they're 
in the host power management code - I'm not sure whether they should be 
here or the SCSI glue layer?

> 2-3. Misplaced _GTF hook.  _GTF currently is called prior to every
> device configuration.  This is unnecessary and incorrect.  The
> ACPI spec specifies that _GTM/_STM and _GTF should be executed
> during suspend/resume cycles not on every reset or
> reconfiguration.  This, for example, causes the following
> problem.

That should be quite easily fixable with the above patch.

> 4-1. Depending on how questions in section 3 are answered, fix and
> clean up ATA host/device <-> ACPI object association.  Whether
> IDE or SATA native style hierarchy is used should be determined
> by driver flag not cable type.  e.g. ahci and sata_sil24 should
> use SATA native style hierarchy while ata_piix should use IDE
> hierarchy whether the port is SATA or PATA.

I think this is just a matter of making sure that the sata and pata 
handle matching code matches reality now :)

> 4-2. Only associate once during initialization.  There is no reason to
> try to associate hosts and devices with ACPI objects at each try.
> Do it once during host initialization and use it if available or
> forget about ACPI if not available.

Fixed.

> 4-3. Integrate _GTM/_STM support and invoke methods only when the spec
> specifies to.  For IDE object, do _GTM during suspend and _STM
> followed by _GTF during resume.  There is no reason to call them
> anytime else.  For SATA native object, do _SDD followed by _GTF
> after every hardreset.

Patrially fixed.

> 4-4. Implement helpers for cable detection using _GTM/_STM and use it
> in sata_nv if CK804.  This is to substitute independent pata_acpi
> driver.  Low level driver should know when _GTM/_STM should be
> used for cable detection and/or device programming and doing it
> this way reduces user confusion (sata_nv also supports ck804 but
> you probably need to load pata_acpi if ACPI is available) and
> allows better integration with the rest of the low level driver
> (e.g. ADMA mode + _GTM/_STM cable detection).

Not done.

-- 
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: [3/6] 2.6.21-rc4: known regressions

[Linus Torvalds]

On Wed, 28 Mar 2007, Maxim wrote:
> 
>   Now I don't have a clue how to set those bits if only HPET is used as 
> clock source because now clocksources
>   don't have _any_ resume hook.

One thing that drives me wild about that "clocksource resume" thing is 
that it seems to think that clocksources are somehow different from any 
other system devices..

Why isn't the HPET considered a "device", and has it's own *device* 
"suspend" and "resume"? Why do we seem to think that only "set_mode()" 
etc should wake up clock sources?

It's a *device*, dammit. It should save and resume like one (probably as a 
system device). The "set_mode()" etc stuff is at a completely different 
(higher) conceptual level.

Thomas? It does seem like Maxim has hit the nail on the head (at least 
partly) on the HPET timer resume problems..

Linus
-
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: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 16:41:48 Ingo Molnar wrote:
> 
> * Maxim <[EMAIL PROTECTED]> wrote:
> 
> > I almost sure I know why this happens,
> 
> cool! Your patch is a definite improvement on my t60 (where 
> suspend/resume never worked with hpet enabled). But it does not fix 
> everything - for example the timings are way off after resume. Thomas?
> 
>   Ingo
> 

The problem is that HPET  consists of two parts:
one is a main counter and second is a a timers.

To enable main counter one must set HPET_CFG_ENABLE.
It is set only on boot, and not on resume now.

But on my system I think bios re-enables it.

Secondary to enable HPET to act as a timer on IRQ0 and to make it 
replace RTC IRQ8 one must set
HPET_CFG_LEGACY

This bit is definitely not set on resume, so on my system I get a hang 
if I use HPET as clockevents device,
and on other system where bios doesn't reenable HPET, then even if HPET 
is used as timing device 
'date won't advance'

But I set those bits only in initialization of HPET clockevents device, 
and I set always, when it is turned on,
It is not that good,but works.

Now I don't have a clue how to set those bits if only HPET is used as 
clock source because now clocksources
don't have _any_ resume hook.

The timing problem you mention I think isd connected to the fact that 
HPET is not enabled instantly after resume, but after some time when clockevents
core calls HPET to enable event timer.

Best regards,
Maxim Levitsky
-
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: [3/6] 2.6.21-rc4: known regressions

[Ingo Molnar]

* Maxim <[EMAIL PROTECTED]> wrote:

> I almost sure I know why this happens,

cool! Your patch is a definite improvement on my t60 (where 
suspend/resume never worked with hpet enabled). But it does not fix 
everything - for example the timings are way off after resume. Thomas?

Ingo
-
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: [3/6] 2.6.21-rc4: known regressions

[Maxim]

On Wednesday 28 March 2007 09:04:28 Thomas Gleixner wrote:
> On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> > On 3/27/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > 
> > > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > > suspend and resume from RAM (s2ram). Even better, it works
> > > > with/without CONFIG_NO_HZ.
> > >
> > > Does the patch below fix the HPET_TIMER=y case ?
> > 
> > Thomas, I tried, but it didn't help. Upon resume from ram, "date"
> > still didn't advance.
> 
> Can you please issue a SysRq-Q in this situation and provide the dmesg
> output ?
> 
> Thanks,
> 
>   tglx
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Hi,
I almost sure Iknow why this happens,
The problem is that both hpet clock source and hpet clockevents 
doesn't have a suspend/resume function
On resume we should enable the main counter _and_ enable legacy 
replacement mode,
On my system main counter in enabled, by I think by bios, but 
legacy replacement mode is not, so if
a system doesn't use lapic as a tick source, but use 
hpet+broadcast, it will hang for sure on resume, and i tested it

The patch below is a temporally fix, until clock-events and 
clocksources will get proper suspend/resume hooks:

Regards,
Maxim Levitsky

---

Add suspend/resume for HPET
Signed-off-by: Maxim Levitsky <[EMAIL PROTECTED]>

---

diff --git a/arch/i386/kernel/hpet.c b/arch/i386/kernel/hpet.c
index 0fd9fba..a1ec79e 100644
--- a/arch/i386/kernel/hpet.c
+++ b/arch/i386/kernel/hpet.c
@@ -152,6 +152,16 @@ static void hpet_set_mode(enum clock_event_mode mode,
unsigned long cfg, cmp, now;
uint64_t delta;
 
+
+   if ( mode != CLOCK_EVT_MODE_UNUSED && mode != CLOCK_EVT_MODE_SHUTDOWN)
+   {
+   unsigned long cfg = hpet_readl(HPET_CFG);
+   cfg |= HPET_CFG_ENABLE | HPET_CFG_LEGACY;
+   hpet_writel(cfg, HPET_CFG);
+   
+   }
+   
+
switch(mode) {
case CLOCK_EVT_MODE_PERIODIC:
delta = ((uint64_t)(NSEC_PER_SEC/HZ)) * hpet_clockevent.mult;

-
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: Linux/ACPI home page edit

[Yu, Ling L]

Hi, Len
The update has been done. If there are any other pages need to refresh, feel 
free to tell me please.

Thanks
- Ling

>-Original Message-
>From: Brown, Len
>Sent: 2007年3月28日 5:30
>To: Yu, Ling L
>Cc: linux-acpi@vger.kernel.org
>Subject: Linux/ACPI home page edit
>
>Yu-Ling,
>
>http://acpi.sourceforge.net/patches.html
>is massively out of date.  Please delete it,
>plus the link to it from here:
>http://acpi.sourceforge.net/
>
>The pointer to
>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/README.ACPI
>is still valid, however, and the latest patch information lives there.
>
>Speaking of the project home page
>We haven't used the term ACPI4Linux for years.
>My personal preference is to globally replace it with "Linux/ACPI"
>on the web pages.
>
>Also, I think you can replace all the text on the home page with that below.
>
>thanks,
>-Len
>--
>
>Linux/ACPI Overview
>
>ACPI  puts the OS in control of system configuration and
>power management.
>Further, it acts as a hardware abstraction layer between the OS and the 
>platform
>BIOS --
>allowing the OS and the platform to evolve independently.  See the 
>Documentation
>section for further information.
>
>The Linux/ACPI project is focused on making Linux run well on all ACPI-enabled
>platforms.
>Linux/ACPI is based on Intel's ACPI Component Architecture (ACPICA) reference
>implementation.
>
>
>A central goal of the project is that any computer whose ACPI implementation
>boots
>and runs Windows properly, should also boot and run Linux properly.
>This means that if Linux needs any ACPI-related command-line parameters
>or a modified BIOS DSDT to boot and run properly,
>then you should file a Linux bug.
>
>To participate in the project, the latest information on filing bugs
>and submitting patches is here:
>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/README.ACPI
-
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