Re: [PATCH 0/2] x86 - Move laptop drivers out of x86 Kconfig
On Sunday 17 February 2008 18:20:08 Ingo Molnar wrote: > i suspect this should be merged by the char driver tree which is > affected by the addition of these new entries. Where is such a tree, and who's responsible for it though? I grep'ed MAINTAINERS and didn't turn up anyone. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH 17/27] acer-wmi: fix section mismatch warnings
On Sunday 17 February 2008 12:22:54 Sam Ravnborg wrote: > Fix following warnings: > WARNING: vmlinux.o(.text+0x672615): Section mismatch in reference from the > function acer_platform_remove() to the function > .exit.text:acer_backlight_exit() WARNING: vmlinux.o(.devinit.text+0x1e859): > Section mismatch in reference from the function acer_platform_probe() to > the function .init.text:acer_led_init() WARNING: > vmlinux.o(.devinit.text+0x1e878): Section mismatch in reference from the > function acer_platform_probe() to the function > .init.text:acer_backlight_init() > > Remove __exit annotation from acer_backlight_exit(). We cannot reference > a __exit annotated function from non __exit functions. > > acer_led_init() and acer_backlight_init() where both annotated __init but > used from a __devinit function. This would result in an oops should > gcc drop their inlining and the module are hot plugged. > > Fix by annotating acer_led_init() and acer_backlight_init() __devinit. > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> > Cc: Len Brown <[EMAIL PROTECTED]> Len, can you apply this to acpi-test? (Unless Andrew wants to take all these through -mm?) -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH 17/27] acer-wmi: fix section mismatch warnings
On Sunday 17 February 2008 12:22:54 Sam Ravnborg wrote: Fix following warnings: WARNING: vmlinux.o(.text+0x672615): Section mismatch in reference from the function acer_platform_remove() to the function .exit.text:acer_backlight_exit() WARNING: vmlinux.o(.devinit.text+0x1e859): Section mismatch in reference from the function acer_platform_probe() to the function .init.text:acer_led_init() WARNING: vmlinux.o(.devinit.text+0x1e878): Section mismatch in reference from the function acer_platform_probe() to the function .init.text:acer_backlight_init() Remove __exit annotation from acer_backlight_exit(). We cannot reference a __exit annotated function from non __exit functions. acer_led_init() and acer_backlight_init() where both annotated __init but used from a __devinit function. This would result in an oops should gcc drop their inlining and the module are hot plugged. Fix by annotating acer_led_init() and acer_backlight_init() __devinit. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Signed-off-by: Carlos Corbacho [EMAIL PROTECTED] Cc: Len Brown [EMAIL PROTECTED] Len, can you apply this to acpi-test? (Unless Andrew wants to take all these through -mm?) -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH 0/2] x86 - Move laptop drivers out of x86 Kconfig
On Sunday 17 February 2008 18:20:08 Ingo Molnar wrote: i suspect this should be merged by the char driver tree which is affected by the addition of these new entries. Where is such a tree, and who's responsible for it though? I grep'ed MAINTAINERS and didn't turn up anyone. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] wmi: (!x & y) strikes again
On Wednesday 13 February 2008 04:03:25 Al Viro wrote: > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Acked-by: Carlos Corbacho <[EMAIL PROTECTED]> > --- > d2d6f5b9eb315a53043a722d952bb21ed5ca1229 > diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c > index 457ed3d..efacc9f 100644 > --- a/drivers/acpi/wmi.c > +++ b/drivers/acpi/wmi.c > @@ -247,7 +247,7 @@ u32 method_id, const struct acpi_buffer *in, struct > acpi_buffer *out) > block = >gblock; > handle = wblock->handle; > > - if (!block->flags & ACPI_WMI_METHOD) > + if (!(block->flags & ACPI_WMI_METHOD)) > return AE_BAD_DATA; > > if (block->instance_count < instance) > -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH 1/2] acer-wmi - Fail gracefully if ACPI is disabled
On Tuesday 12 February 2008 04:41:42 Linus Torvalds wrote: > > On Mon, 11 Feb 2008, Carlos Corbacho wrote: > > > > WMI drivers, like their ACPI counterparts, should also check if ACPI is > > disabled or not, and bail out if so, otherwise we cause a crash. > > Shouldn't "wmi_has_guid()" just return false if ACPI isn't enabled, and > the drivers should just then always give up? Yes - that's a better fix. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] wmi: (!x y) strikes again
On Wednesday 13 February 2008 04:03:25 Al Viro wrote: Signed-off-by: Al Viro [EMAIL PROTECTED] Acked-by: Carlos Corbacho [EMAIL PROTECTED] --- d2d6f5b9eb315a53043a722d952bb21ed5ca1229 diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c index 457ed3d..efacc9f 100644 --- a/drivers/acpi/wmi.c +++ b/drivers/acpi/wmi.c @@ -247,7 +247,7 @@ u32 method_id, const struct acpi_buffer *in, struct acpi_buffer *out) block = wblock-gblock; handle = wblock-handle; - if (!block-flags ACPI_WMI_METHOD) + if (!(block-flags ACPI_WMI_METHOD)) return AE_BAD_DATA; if (block-instance_count instance) -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[PATCH 2/2] tc1100-wmi - Fail gracefully if ACPI is disabled
tc1100-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho <[EMAIL PROTECTED]>
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Linus Torvalds <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/tc1100-wmi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/tc1100-wmi.c b/drivers/misc/tc1100-wmi.c
index f25e4c9..cb8f79f 100644
--- a/drivers/misc/tc1100-wmi.c
+++ b/drivers/misc/tc1100-wmi.c
@@ -263,6 +263,9 @@ static int __init tc1100_init(void)
{
int result = 0;
+ if (acpi_disabled)
+ return -ENODEV;
+
if (!wmi_has_guid(GUID))
return -ENODEV;
--
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/
[PATCH 1/2] acer-wmi - Fail gracefully if ACPI is disabled
acer-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho <[EMAIL PROTECTED]>
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Linus Torvalds <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Len Brown <[EMAIL PROTECTED]>
---
drivers/misc/acer-wmi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/acer-wmi.c b/drivers/misc/acer-wmi.c
index d7aea93..6e81027 100644
--- a/drivers/misc/acer-wmi.c
+++ b/drivers/misc/acer-wmi.c
@@ -1029,6 +1029,9 @@ static int __init acer_wmi_init(void)
{
int err;
+ if (acpi_disabled)
+ return -ENODEV;
+
printk(ACER_INFO "Acer Laptop ACPI-WMI Extras version %s\n",
ACER_WMI_VERSION);
--
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/
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
On Monday 11 February 2008 09:17:43 Ingo Molnar wrote: > no, it does not help - see the attached .config and the crash.log. Thanks Ingo - the cause of the crash is ACPI being disabled on your system for some reason. I can reproduce your crash every time here with acpi=off. The two WMI based drivers (acer-wmi, tc1100-wmi) in the kernel both need a simple patch each to fix this - patches to follow. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[PATCH 2/2] tc1100-wmi - Fail gracefully if ACPI is disabled
tc1100-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho [EMAIL PROTECTED]
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho [EMAIL PROTECTED]
CC: Ingo Molnar [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED]
CC: Len Brown [EMAIL PROTECTED]
---
drivers/misc/tc1100-wmi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/tc1100-wmi.c b/drivers/misc/tc1100-wmi.c
index f25e4c9..cb8f79f 100644
--- a/drivers/misc/tc1100-wmi.c
+++ b/drivers/misc/tc1100-wmi.c
@@ -263,6 +263,9 @@ static int __init tc1100_init(void)
{
int result = 0;
+ if (acpi_disabled)
+ return -ENODEV;
+
if (!wmi_has_guid(GUID))
return -ENODEV;
--
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/
[PATCH 1/2] acer-wmi - Fail gracefully if ACPI is disabled
acer-wmi - Fail gracefully if ACPI is disabled
From: Carlos Corbacho [EMAIL PROTECTED]
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho [EMAIL PROTECTED]
CC: Ingo Molnar [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED]
CC: Len Brown [EMAIL PROTECTED]
---
drivers/misc/acer-wmi.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/acer-wmi.c b/drivers/misc/acer-wmi.c
index d7aea93..6e81027 100644
--- a/drivers/misc/acer-wmi.c
+++ b/drivers/misc/acer-wmi.c
@@ -1029,6 +1029,9 @@ static int __init acer_wmi_init(void)
{
int err;
+ if (acpi_disabled)
+ return -ENODEV;
+
printk(ACER_INFO Acer Laptop ACPI-WMI Extras version %s\n,
ACER_WMI_VERSION);
--
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/
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
On Monday 11 February 2008 09:17:43 Ingo Molnar wrote: no, it does not help - see the attached .config and the crash.log. Thanks Ingo - the cause of the crash is ACPI being disabled on your system for some reason. I can reproduce your crash every time here with acpi=off. The two WMI based drivers (acer-wmi, tc1100-wmi) in the kernel both need a simple patch each to fix this - patches to follow. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
On Saturday 09 February 2008 06:19:36 Ingo Molnar wrote:
> (Carlos Cc:-ed too)
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > * Len Brown <[EMAIL PROTECTED]> wrote:
> > > Len Brown (6):
> > > ACPI: add newline to printk
> > > ACPI: build WMI on X86 only
> > > acer-wmi, tc1100-wmi: select ACPI_WMI
> >
> > hm, this new WMI code caused a bootup crash in the overnight x86.git
> > tests:
I suspect this is a problem on systems without ACPI-WMI in the DSDT - though I
can't reproduce this here on my other box that lacks ACPI-WMI.
Ingo, can you try the patch below and see if this cures it?
---
ACPI: WMI: Fix crash on WMI free systems
From: Carlos Corbacho <[EMAIL PROTECTED]>
We have two pointers in the find_guid() code that aren't checked before
we use them. On ACPI-WMI free systems, this can sometimes cause a crash if
another driver tries to use any of the methods provided by WMI.
Also throw in an extra early check to see if the GUID list is empty, so we
can try to bail out before reaching this code as well.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
CC: Ingo Molnar <[EMAIL PROTECTED]>
CC: Linus Torvalds <[EMAIL PROTECTED]>
CC: Andrew Morton <[EMAIL PROTECTED]>
CC: Len Brown <[EMAIL PROTECTED]>
---
drivers/acpi/wmi.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c
index 36b84ab..b54e734 100644
--- a/drivers/acpi/wmi.c
+++ b/drivers/acpi/wmi.c
@@ -201,12 +201,20 @@ static bool find_guid(const char *guid_string, struct
wmi_block **out)
struct guid_block *block;
struct list_head *p;
+ if (list_empty(_blocks.list))
+ return 0;
+
wmi_parse_guid(guid_string, tmp);
wmi_swap_bytes(tmp, guid_input);
list_for_each(p, _blocks.list) {
wblock = list_entry(p, struct wmi_block, list);
+ if (!wblock)
+ return 0;
+
block = >gblock;
+ if (!block)
+ return 0;
if (memcmp(block->guid, guid_input, 16) == 0) {
if (out)
--
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--
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/
Re: [GIT PATCH] ACPI patches for 2.6.25-rc0 (#2)
On Saturday 09 February 2008 06:19:36 Ingo Molnar wrote:
(Carlos Cc:-ed too)
* Ingo Molnar [EMAIL PROTECTED] wrote:
* Len Brown [EMAIL PROTECTED] wrote:
Len Brown (6):
ACPI: add newline to printk
ACPI: build WMI on X86 only
acer-wmi, tc1100-wmi: select ACPI_WMI
hm, this new WMI code caused a bootup crash in the overnight x86.git
tests:
I suspect this is a problem on systems without ACPI-WMI in the DSDT - though I
can't reproduce this here on my other box that lacks ACPI-WMI.
Ingo, can you try the patch below and see if this cures it?
---
ACPI: WMI: Fix crash on WMI free systems
From: Carlos Corbacho [EMAIL PROTECTED]
We have two pointers in the find_guid() code that aren't checked before
we use them. On ACPI-WMI free systems, this can sometimes cause a crash if
another driver tries to use any of the methods provided by WMI.
Also throw in an extra early check to see if the GUID list is empty, so we
can try to bail out before reaching this code as well.
Spotted by Ingo Molnar.
Signed-off-by: Carlos Corbacho [EMAIL PROTECTED]
CC: Ingo Molnar [EMAIL PROTECTED]
CC: Linus Torvalds [EMAIL PROTECTED]
CC: Andrew Morton [EMAIL PROTECTED]
CC: Len Brown [EMAIL PROTECTED]
---
drivers/acpi/wmi.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c
index 36b84ab..b54e734 100644
--- a/drivers/acpi/wmi.c
+++ b/drivers/acpi/wmi.c
@@ -201,12 +201,20 @@ static bool find_guid(const char *guid_string, struct
wmi_block **out)
struct guid_block *block;
struct list_head *p;
+ if (list_empty(wmi_blocks.list))
+ return 0;
+
wmi_parse_guid(guid_string, tmp);
wmi_swap_bytes(tmp, guid_input);
list_for_each(p, wmi_blocks.list) {
wblock = list_entry(p, struct wmi_block, list);
+ if (!wblock)
+ return 0;
+
block = wblock-gblock;
+ if (!block)
+ return 0;
if (memcmp(block-guid, guid_input, 16) == 0) {
if (out)
--
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
--
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/
[PATCH 1/2] i8k - Move Kconfig entry to drivers/char
The source code for this driver is currently located in drivers/char, and given that this is not an x86 processor feature, it shouldn't live in the x86 Kconfig. So lets move it to the Kconfig for drivers/char instead, and just add a dependency on x86. Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> CC: Massimo Dal Zotto <[EMAIL PROTECTED]> CC: Ingo Molnar <[EMAIL PROTECTED]> CC: Thomas Gleixner <[EMAIL PROTECTED]> --- arch/x86/Kconfig | 20 drivers/char/Kconfig | 21 + 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c95482b..beaf268 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -632,26 +632,6 @@ config TOSHIBA Say Y if you intend to run this kernel on a Toshiba portable. Say N otherwise. -config I8K - tristate "Dell laptop support" - ---help--- - This adds a driver to safely access the System Management Mode - of the CPU on the Dell Inspiron 8000. The System Management Mode - is used to read cpu temperature and cooling fan status and to - control the fans on the I8K portables. - - This driver has been tested only on the Inspiron 8000 but it may - also work with other Dell laptops. You can force loading on other - models by passing the parameter `force=1' to the module. Use at - your own risk. - - For information on utilities to make use of this driver see the - I8K Linux utilities web site at: - <http://people.debian.org/~dz/i8k/> - - Say Y if you intend to run this kernel on a Dell Inspiron 8000. - Say N otherwise. - config X86_REBOOTFIXUPS def_bool n prompt "Enable X86 board specific fixups for reboot" diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index f01ac9a..37861c4 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -867,6 +867,27 @@ config APPLICOM If unsure, say N. +config I8K + tristate "Dell laptop support" + depends on X86 + ---help--- + This adds a driver to safely access the System Management Mode + of the CPU on the Dell Inspiron 8000. The System Management Mode + is used to read cpu temperature and cooling fan status and to + control the fans on the I8K portables. + + This driver has been tested only on the Inspiron 8000 but it may + also work with other Dell laptops. You can force loading on other + models by passing the parameter `force=1' to the module. Use at + your own risk. + + For information on utilities to make use of this driver see the + I8K Linux utilities web site at: + <http://people.debian.org/~dz/i8k/> + + Say Y if you intend to run this kernel on a Dell Inspiron 8000. + Say N otherwise. + config SONYPI tristate "Sony Vaio Programmable I/O Control Device support (EXPERIMENTAL)" depends on EXPERIMENTAL && X86 && PCI && INPUT && !64BIT -- 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/
[PATCH 0/2] x86 - Move laptop drivers out of x86 Kconfig
The following patch series moves the two laptop drivers from x86 Kconfig (i8k and toshiba) to drivers/char, which is where the source for them lives anyway. Given they are not x86 processor features, the x86 Kconfig menu is not really an appropriate place for them to live. This is against Linus latest tree, since x86 git seems to be missing an earlier Kconfig patch for I8K that dropped the x86_32 limitation. -Carlos --- Carlos Corbacho (2): toshiba - Move Kconfig entry to drivers/char i8k - Move Kconfig entry to drivers/char arch/x86/Kconfig | 36 drivers/char/Kconfig | 37 + 2 files changed, 37 insertions(+), 36 deletions(-) -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[PATCH 2/2] toshiba - Move Kconfig entry to drivers/char
The source code for this driver is currently located in drivers/char, and given that this is not an x86 processor feature, it shouldn't live in the x86 Kconfig. So lets move it to the Kconfig for drivers/char instead. Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> CC: Jonathan Buzzard <[EMAIL PROTECTED]> CC: Ingo Molnar <[EMAIL PROTECTED]> CC: Thomas Gleixner <[EMAIL PROTECTED]> --- arch/x86/Kconfig | 16 drivers/char/Kconfig | 16 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index beaf268..01ad8d2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -616,22 +616,6 @@ config VM86 XFree86 to initialize some video cards via BIOS. Disabling this option saves about 6k. -config TOSHIBA - tristate "Toshiba Laptop support" - depends on X86_32 - ---help--- - This adds a driver to safely access the System Management Mode of - the CPU on Toshiba portables with a genuine Toshiba BIOS. It does - not work on models with a Phoenix BIOS. The System Management Mode - is used to set the BIOS and power saving options on Toshiba portables. - - For information on utilities to make use of this driver see the - Toshiba Linux utilities web site at: - <http://www.buzzard.org.uk/toshiba/>. - - Say Y if you intend to run this kernel on a Toshiba portable. - Say N otherwise. - config X86_REBOOTFIXUPS def_bool n prompt "Enable X86 board specific fixups for reboot" diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 37861c4..aa3ac8e 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -901,6 +901,22 @@ config SONYPI To compile this driver as a module, choose M here: the module will be called sonypi. +config TOSHIBA + tristate "Toshiba Laptop support" + depends on X86_32 + ---help--- + This adds a driver to safely access the System Management Mode of + the CPU on Toshiba portables with a genuine Toshiba BIOS. It does + not work on models with a Phoenix BIOS. The System Management Mode + is used to set the BIOS and power saving options on Toshiba portables. + + For information on utilities to make use of this driver see the + Toshiba Linux utilities web site at: + <http://www.buzzard.org.uk/toshiba/>. + + Say Y if you intend to run this kernel on a Toshiba portable. + Say N otherwise. + config GPIO_TB0219 tristate "TANBAC TB0219 GPIO support" depends on TANBAC_TB022X -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 06:53:13 Pavel Machek wrote: > I believe selct is the way to go here. What do acer-wmi handle? > Additional buttons? Leds? Temperatures? Fan states? Enabling wireless, bluetooth and 3G; and exposing the mail LED and backlight. tc1100-wmi handles wireless and the jog dial, IIRC. > The laptops will boot fine without it, right? Yes. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 06:53:13 Pavel Machek wrote: I believe selct is the way to go here. What do acer-wmi handle? Additional buttons? Leds? Temperatures? Fan states? Enabling wireless, bluetooth and 3G; and exposing the mail LED and backlight. tc1100-wmi handles wireless and the jog dial, IIRC. The laptops will boot fine without it, right? Yes. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[PATCH 1/2] i8k - Move Kconfig entry to drivers/char
The source code for this driver is currently located in drivers/char, and given that this is not an x86 processor feature, it shouldn't live in the x86 Kconfig. So lets move it to the Kconfig for drivers/char instead, and just add a dependency on x86. Signed-off-by: Carlos Corbacho [EMAIL PROTECTED] CC: Massimo Dal Zotto [EMAIL PROTECTED] CC: Ingo Molnar [EMAIL PROTECTED] CC: Thomas Gleixner [EMAIL PROTECTED] --- arch/x86/Kconfig | 20 drivers/char/Kconfig | 21 + 2 files changed, 21 insertions(+), 20 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c95482b..beaf268 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -632,26 +632,6 @@ config TOSHIBA Say Y if you intend to run this kernel on a Toshiba portable. Say N otherwise. -config I8K - tristate Dell laptop support - ---help--- - This adds a driver to safely access the System Management Mode - of the CPU on the Dell Inspiron 8000. The System Management Mode - is used to read cpu temperature and cooling fan status and to - control the fans on the I8K portables. - - This driver has been tested only on the Inspiron 8000 but it may - also work with other Dell laptops. You can force loading on other - models by passing the parameter `force=1' to the module. Use at - your own risk. - - For information on utilities to make use of this driver see the - I8K Linux utilities web site at: - http://people.debian.org/~dz/i8k/ - - Say Y if you intend to run this kernel on a Dell Inspiron 8000. - Say N otherwise. - config X86_REBOOTFIXUPS def_bool n prompt Enable X86 board specific fixups for reboot diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index f01ac9a..37861c4 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -867,6 +867,27 @@ config APPLICOM If unsure, say N. +config I8K + tristate Dell laptop support + depends on X86 + ---help--- + This adds a driver to safely access the System Management Mode + of the CPU on the Dell Inspiron 8000. The System Management Mode + is used to read cpu temperature and cooling fan status and to + control the fans on the I8K portables. + + This driver has been tested only on the Inspiron 8000 but it may + also work with other Dell laptops. You can force loading on other + models by passing the parameter `force=1' to the module. Use at + your own risk. + + For information on utilities to make use of this driver see the + I8K Linux utilities web site at: + http://people.debian.org/~dz/i8k/ + + Say Y if you intend to run this kernel on a Dell Inspiron 8000. + Say N otherwise. + config SONYPI tristate Sony Vaio Programmable I/O Control Device support (EXPERIMENTAL) depends on EXPERIMENTAL X86 PCI INPUT !64BIT -- 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/
[PATCH 0/2] x86 - Move laptop drivers out of x86 Kconfig
The following patch series moves the two laptop drivers from x86 Kconfig (i8k and toshiba) to drivers/char, which is where the source for them lives anyway. Given they are not x86 processor features, the x86 Kconfig menu is not really an appropriate place for them to live. This is against Linus latest tree, since x86 git seems to be missing an earlier Kconfig patch for I8K that dropped the x86_32 limitation. -Carlos --- Carlos Corbacho (2): toshiba - Move Kconfig entry to drivers/char i8k - Move Kconfig entry to drivers/char arch/x86/Kconfig | 36 drivers/char/Kconfig | 37 + 2 files changed, 37 insertions(+), 36 deletions(-) -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
[PATCH 2/2] toshiba - Move Kconfig entry to drivers/char
The source code for this driver is currently located in drivers/char, and given that this is not an x86 processor feature, it shouldn't live in the x86 Kconfig. So lets move it to the Kconfig for drivers/char instead. Signed-off-by: Carlos Corbacho [EMAIL PROTECTED] CC: Jonathan Buzzard [EMAIL PROTECTED] CC: Ingo Molnar [EMAIL PROTECTED] CC: Thomas Gleixner [EMAIL PROTECTED] --- arch/x86/Kconfig | 16 drivers/char/Kconfig | 16 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index beaf268..01ad8d2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -616,22 +616,6 @@ config VM86 XFree86 to initialize some video cards via BIOS. Disabling this option saves about 6k. -config TOSHIBA - tristate Toshiba Laptop support - depends on X86_32 - ---help--- - This adds a driver to safely access the System Management Mode of - the CPU on Toshiba portables with a genuine Toshiba BIOS. It does - not work on models with a Phoenix BIOS. The System Management Mode - is used to set the BIOS and power saving options on Toshiba portables. - - For information on utilities to make use of this driver see the - Toshiba Linux utilities web site at: - http://www.buzzard.org.uk/toshiba/. - - Say Y if you intend to run this kernel on a Toshiba portable. - Say N otherwise. - config X86_REBOOTFIXUPS def_bool n prompt Enable X86 board specific fixups for reboot diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index 37861c4..aa3ac8e 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -901,6 +901,22 @@ config SONYPI To compile this driver as a module, choose M here: the module will be called sonypi. +config TOSHIBA + tristate Toshiba Laptop support + depends on X86_32 + ---help--- + This adds a driver to safely access the System Management Mode of + the CPU on Toshiba portables with a genuine Toshiba BIOS. It does + not work on models with a Phoenix BIOS. The System Management Mode + is used to set the BIOS and power saving options on Toshiba portables. + + For information on utilities to make use of this driver see the + Toshiba Linux utilities web site at: + http://www.buzzard.org.uk/toshiba/. + + Say Y if you intend to run this kernel on a Toshiba portable. + Say N otherwise. + config GPIO_TB0219 tristate TANBAC TB0219 GPIO support depends on TANBAC_TB022X -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 01:38:01 Ray Lee wrote: > That's clear to me (whereas the original wasn't), though I would > still argue for this driver being select'ed by the drivers that > require it. As you note, other laptop specific drivers do so, and > Linus has come down in favor of that as well in the past, so you have > a friend in high places :-). I have some other patches lined up to do so. Unless I hear some arguments against it, or some better alternatives, I'll put them together with this and get Len to apply them to the ACPI tree (and then hopefully push back out before the -rc1 release). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 00:12:24 Ray Lee wrote: > On Feb 7, 2008 3:51 PM, Carlos Corbacho <[EMAIL PROTECTED]> wrote: > > On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > > > Do you have list of hardware/platforms that require this feature to > > > get the hardware to work? (acer abc123, tcm1100 xyz) > > > > I have a very long list of Acer laptops that are supported - which is far > > too long, and changes on far too much of a regular basis to put in there. > > > > Perhaps adding something like "This driver is also a required dependency > > to build the firmware specific drivers needed for many laptops, including > > Acer and HP machines"? Would this be acceptable then? -Carlos --- ACPI: WMI: Improve Kconfig entry From: Carlos Corbacho <[EMAIL PROTECTED]> As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty non-descriptive. Rewrite it so that it explains what ACPI-WMI is, and why anyone would want to enable it. Many thanks to Ray Lee for ideas on this. Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]> CC: Pavel Machek <[EMAIL PROTECTED]> CC: Ray Lee <[EMAIL PROTECTED]> CC: Len Brown <[EMAIL PROTECTED]> --- drivers/acpi/Kconfig | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b7fbf16..ea763ef 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -207,11 +207,22 @@ config ACPI_WMI depends on EXPERIMENTAL depends on X86 help - This driver adds support for the ACPI-WMI mapper device (PNP0C14) - found on some systems. + This driver adds support for the ACPI-WMI (Windows Management + Instrumentation) mapper device (PNP0C14) found on some systems. - NOTE: You will need another driver or userspace application on top of - this to actually use anything defined in the ACPI-WMI mapper. + ACPI-WMI is a proprietary extension to ACPI to expose parts of the + ACPI firmware to userspace - this is done through various vendor + defined methods and data blocks in a PNP0C14 device, which are then + made available for userspace to call. + + The implementation of this in Linux currently only exposes this to + other kernel space drivers. + + This driver is a required dependency to build the firmware specific + drivers needed on many machines, including Acer and HP laptops. + + It is safe to enable this driver even if your DSDT doesn't define + any ACPI-WMI devices. config ACPI_ASUS tristate "ASUS/Medion Laptop Extras" -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 00:12:24 Ray Lee wrote: > While I'm not trying to set you up for a firing squad, if you can show > that the only use this driver has is as underlying support for Acer/HP > xyz drivers, Certainly at the moment, this is the only real use it has (and the only reason I spent any time working on a generic ACPI-WMI driver - probably one of the reasons Kconfig is somewhat neglected - ACPI-WMI is a means to an end for me (getting my laptop properly supported by another driver on top of it), not the end itself). Although, given most of the other laptop drivers in drivers/misc use 'select' for various things, I don't see the harm here - unless anyone else has a great objection to acer-wmi and tc1100-wmi having 'select ACPI_WMI'? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Thursday 07 February 2008 23:33:54 Ray Lee wrote: > Do you have list of hardware/platforms that require this feature to > get the hardware to work? (acer abc123, tcm1100 xyz) I have a very long list of Acer laptops that are supported - which is far too long, and changes on far too much of a regular basis to put in there. Perhaps adding something like "This driver is also a required dependency to build the firmware specific drivers needed for many laptops, including Acer and HP machines"? (There's currently another ACPI-WMI based driver in development related to more HP laptops, and acer-wmi also supports a handful of non-Acer laptops). I don't think explaining what WMI is, and how ACPI-WMI is related to it is that useful in Kconfig here; so I agree that further elaborating on the 'why' this should be enabled is definitely worth doing. > Better, if there are kernel drivers that require this (and currently > only those drivers), then have those kernel drivers enable ACPI WMI, Wouldn't that require 'select' though, and I'm led to believe that's seriously frowned upon these days? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Thursday 07 February 2008 22:34:55 Pavel Machek wrote: > +3) What is the ACPI-WMI mapper > + > +The Linux ACPI-WMI driver is the implementation of this mapper for Linux. > > Yes, please. This needs translation into plain english. In plain English? ACPI-WMI is a nasty hack/ abuse of ACPI by Microsoft to force their driver model into ACPI, and that should be thoroughly discouraged from further use. However, since quite a few laptop vendors rely on it for basic functionality, we have to implement it (or a part of it) as well. Yes, WMI itself is supposed to be an instrumentation/ management thing, as well as, if I understand, part of their driver model, and ACPI-WMI is a part of that - by and of itself though, ACPI-WMI is _not_ the whole of WMI. All that the Linux driver currently cares about is translating this crap into something that we can actually use in Linux to make hardware work (kernel space). So at the moment, ACPI-WMI is exactly what it says it is - not a lot. It needs another driver on top to do something useful (e.g. acer-wmi, tc1100-wmi). Later on, we will try and replicate the rest of the 'specification', which is supposed to export all this rubbish (data, and direct access to various ACPI methods defined in a WMI device) to userspace. > What is WBEM, in plain terms? What is it good for? If you can make heads or tails of WBEM, please feel free to let me know. AFAICT, it's supposed to be a means of providing some sort of web based management/ instrumentation. So yes, I agree with you the documentation is crap - but it needs to be redone anyway, and I've already had that pointed out to me. As for the Kconfig - I'm open to suggestions. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Thursday 07 February 2008 22:34:55 Pavel Machek wrote: +3) What is the ACPI-WMI mapper + +The Linux ACPI-WMI driver is the implementation of this mapper for Linux. Yes, please. This needs translation into plain english. In plain English? ACPI-WMI is a nasty hack/ abuse of ACPI by Microsoft to force their driver model into ACPI, and that should be thoroughly discouraged from further use. However, since quite a few laptop vendors rely on it for basic functionality, we have to implement it (or a part of it) as well. Yes, WMI itself is supposed to be an instrumentation/ management thing, as well as, if I understand, part of their driver model, and ACPI-WMI is a part of that - by and of itself though, ACPI-WMI is _not_ the whole of WMI. All that the Linux driver currently cares about is translating this crap into something that we can actually use in Linux to make hardware work (kernel space). So at the moment, ACPI-WMI is exactly what it says it is - not a lot. It needs another driver on top to do something useful (e.g. acer-wmi, tc1100-wmi). Later on, we will try and replicate the rest of the 'specification', which is supposed to export all this rubbish (data, and direct access to various ACPI methods defined in a WMI device) to userspace. What is WBEM, in plain terms? What is it good for? If you can make heads or tails of WBEM, please feel free to let me know. AFAICT, it's supposed to be a means of providing some sort of web based management/ instrumentation. So yes, I agree with you the documentation is crap - but it needs to be redone anyway, and I've already had that pointed out to me. As for the Kconfig - I'm open to suggestions. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Thursday 07 February 2008 23:33:54 Ray Lee wrote: Do you have list of hardware/platforms that require this feature to get the hardware to work? (acer abc123, tcm1100 xyz) I have a very long list of Acer laptops that are supported - which is far too long, and changes on far too much of a regular basis to put in there. Perhaps adding something like This driver is also a required dependency to build the firmware specific drivers needed for many laptops, including Acer and HP machines? (There's currently another ACPI-WMI based driver in development related to more HP laptops, and acer-wmi also supports a handful of non-Acer laptops). I don't think explaining what WMI is, and how ACPI-WMI is related to it is that useful in Kconfig here; so I agree that further elaborating on the 'why' this should be enabled is definitely worth doing. Better, if there are kernel drivers that require this (and currently only those drivers), then have those kernel drivers enable ACPI WMI, Wouldn't that require 'select' though, and I'm led to believe that's seriously frowned upon these days? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 00:12:24 Ray Lee wrote: While I'm not trying to set you up for a firing squad, if you can show that the only use this driver has is as underlying support for Acer/HP xyz drivers, Certainly at the moment, this is the only real use it has (and the only reason I spent any time working on a generic ACPI-WMI driver - probably one of the reasons Kconfig is somewhat neglected - ACPI-WMI is a means to an end for me (getting my laptop properly supported by another driver on top of it), not the end itself). Although, given most of the other laptop drivers in drivers/misc use 'select' for various things, I don't see the harm here - unless anyone else has a great objection to acer-wmi and tc1100-wmi having 'select ACPI_WMI'? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 00:12:24 Ray Lee wrote: On Feb 7, 2008 3:51 PM, Carlos Corbacho [EMAIL PROTECTED] wrote: On Thursday 07 February 2008 23:33:54 Ray Lee wrote: Do you have list of hardware/platforms that require this feature to get the hardware to work? (acer abc123, tcm1100 xyz) I have a very long list of Acer laptops that are supported - which is far too long, and changes on far too much of a regular basis to put in there. Perhaps adding something like This driver is also a required dependency to build the firmware specific drivers needed for many laptops, including Acer and HP machines? Would this be acceptable then? -Carlos --- ACPI: WMI: Improve Kconfig entry From: Carlos Corbacho [EMAIL PROTECTED] As Pavel Machek has pointed out, the Kconfig entry for WMI is pretty non-descriptive. Rewrite it so that it explains what ACPI-WMI is, and why anyone would want to enable it. Many thanks to Ray Lee for ideas on this. Signed-off-by: Carlos Corbacho [EMAIL PROTECTED] CC: Pavel Machek [EMAIL PROTECTED] CC: Ray Lee [EMAIL PROTECTED] CC: Len Brown [EMAIL PROTECTED] --- drivers/acpi/Kconfig | 19 +++ 1 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b7fbf16..ea763ef 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -207,11 +207,22 @@ config ACPI_WMI depends on EXPERIMENTAL depends on X86 help - This driver adds support for the ACPI-WMI mapper device (PNP0C14) - found on some systems. + This driver adds support for the ACPI-WMI (Windows Management + Instrumentation) mapper device (PNP0C14) found on some systems. - NOTE: You will need another driver or userspace application on top of - this to actually use anything defined in the ACPI-WMI mapper. + ACPI-WMI is a proprietary extension to ACPI to expose parts of the + ACPI firmware to userspace - this is done through various vendor + defined methods and data blocks in a PNP0C14 device, which are then + made available for userspace to call. + + The implementation of this in Linux currently only exposes this to + other kernel space drivers. + + This driver is a required dependency to build the firmware specific + drivers needed on many machines, including Acer and HP laptops. + + It is safe to enable this driver even if your DSDT doesn't define + any ACPI-WMI devices. config ACPI_ASUS tristate ASUS/Medion Laptop Extras -- 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/
Re: ACPI_WMI: worst config description of all times
On Friday 08 February 2008 01:38:01 Ray Lee wrote: nod That's clear to me (whereas the original wasn't), though I would still argue for this driver being select'ed by the drivers that require it. As you note, other laptop specific drivers do so, and Linus has come down in favor of that as well in the past, so you have a friend in high places :-). I have some other patches lined up to do so. Unless I hear some arguments against it, or some better alternatives, I'll put them together with this and get Len to apply them to the ACPI tree (and then hopefully push back out before the -rc1 release). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: hpet on nforce4/MCP51 in asus a6t
[Adding tglx to CC as he knows more about HPET's than I] On Sunday 03 February 2008 18:33:57 [EMAIL PROTECTED] wrote: > Hello, > I have a asus a6t with nforce4/MCP51 chipset. I pass to kernel 2.6.24 > 32 bit the options acpi_use_timer_override and hpet=force, in this way > and the timer IRQ ends up routed as IO-APIC-edge instead of XT-PIC. > With acpi_use_timer_override I just get: > > TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > > and it works through the IO-APIC. > > Instead the hpet is disabled and I just get : > > Time: acpi_pm clocksource has been installed. > Clocksource tsc unstable (delta = -85010975 ns) > > Is possible to have hpet working also with if the BIOS doesn't support > it ? One point before we start - MCP51 is nForce 5, not nForce 4 (which is CK804). If my understanding is correct, acpi_use_timer_override is only a workaround required for those nForce 5 boards that don't enable the HPET for you. So IIUC, you should be able to use either 'hpet=force' or 'acpi_use_timer_override', either of which should solve any timing issues you see, but you shouldn't need both (which should solve your problem of acpi_use_timer_override ignoring the HPET - it shouldn't be needed if 'hpet=force' enables the HPET). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: hpet on nforce4/MCP51 in asus a6t
[Adding tglx to CC as he knows more about HPET's than I] On Sunday 03 February 2008 18:33:57 [EMAIL PROTECTED] wrote: Hello, I have a asus a6t with nforce4/MCP51 chipset. I pass to kernel 2.6.24 32 bit the options acpi_use_timer_override and hpet=force, in this way and the timer IRQ ends up routed as IO-APIC-edge instead of XT-PIC. With acpi_use_timer_override I just get: TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 and it works through the IO-APIC. Instead the hpet is disabled and I just get : Time: acpi_pm clocksource has been installed. Clocksource tsc unstable (delta = -85010975 ns) Is possible to have hpet working also with if the BIOS doesn't support it ? One point before we start - MCP51 is nForce 5, not nForce 4 (which is CK804). If my understanding is correct, acpi_use_timer_override is only a workaround required for those nForce 5 boards that don't enable the HPET for you. So IIUC, you should be able to use either 'hpet=force' or 'acpi_use_timer_override', either of which should solve any timing issues you see, but you shouldn't need both (which should solve your problem of acpi_use_timer_override ignoring the HPET - it shouldn't be needed if 'hpet=force' enables the HPET). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote: > What about finding what does this BIOS function and writing > an equivalent in C? There would be no BIOS call anymore and > this module could be used in the x86-64 port. > > But, is it a sane solution? The problem is that the BIOS call would be unique to each supported machine as in which memory addresses, EC registers etc get touched and with what values. You would end up needing to reimplement this on a case-by-case basis. This was an idea that was considered by acerhk, but they considered it far too much work and completely impractical. For at least all modern Acer laptops, this direct BIOS calling is completely deprecated, in favour of ACPI-WMI (which in turn, on those systems, usually either triggers SMI traps or touches EC registers, and is 32/ 64 bit agnostic), so the question for those laptops is becoming more and more irrelevant (and modern Acer laptops of the last four years, at least, don't have problems with missing keycodes that require us to poll). For Fujitsu-Siemens laptops, I did come across someone who was looking into poking at ACPI to generate keypresses for the keys that don't generate standard keycodes[1], as a 32/ 64 bit agnostic solution (since most Fujitsu Siemens laptops don't support the required BIOS call from long mode, and also still don't produce standard keycodes on certain button presses). -Carlos [1] http://code.google.com/p/fscamiloa16xx/ -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: wistron_btns-add-support-for-x86_64-systems.patch in -mm
On Saturday 05 January 2008 17:52:06 Rémi Hérilier wrote: What about finding what does this BIOS function and writing an equivalent in C? There would be no BIOS call anymore and this module could be used in the x86-64 port. But, is it a sane solution? The problem is that the BIOS call would be unique to each supported machine as in which memory addresses, EC registers etc get touched and with what values. You would end up needing to reimplement this on a case-by-case basis. This was an idea that was considered by acerhk, but they considered it far too much work and completely impractical. For at least all modern Acer laptops, this direct BIOS calling is completely deprecated, in favour of ACPI-WMI (which in turn, on those systems, usually either triggers SMI traps or touches EC registers, and is 32/ 64 bit agnostic), so the question for those laptops is becoming more and more irrelevant (and modern Acer laptops of the last four years, at least, don't have problems with missing keycodes that require us to poll). For Fujitsu-Siemens laptops, I did come across someone who was looking into poking at ACPI to generate keypresses for the keys that don't generate standard keycodes[1], as a 32/ 64 bit agnostic solution (since most Fujitsu Siemens laptops don't support the required BIOS call from long mode, and also still don't produce standard keycodes on certain button presses). -Carlos [1] http://code.google.com/p/fscamiloa16xx/ -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 01:01:08 Alex Dubov wrote: > This is exactly the same as with tifm_sd module if you noticed. Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD cards. > Second, it is impossible to guess in advance, which type of card is put > into slot (Pro, legacy or IO of either sort). I imagined this to be the case. > Same as mmc_block, actually. > The only way to get it autoloaded, is, again, with appropriate udev rule > (uevent is emitted when card type is detected). So do we require changes to the userspace udev rules here, or just some use of modalias in the drivers? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote: > On Dec 31 2007 00:01, Carlos Corbacho wrote: > >On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > >> From: Alex Dubov <[EMAIL PROTECTED]> > >> > >> Sony MemoryStick cards are used in many products manufactured by Sony. > >> They are available both as storage and as IO expansion cards. Currently, > >> only MemoryStick Pro storage cards are supported via TI FlashMedia > >> MemoryStick interface. > > Actually... my MS slot on PCG-U3 is recognized through usb_storage. Then consider yourself very lucky - some laptop manufacturers play nice and the card reader identifies itself, and works as, a USB mass storage device; so it works out of the box with no extra drivers needed for either the card reader, or the flash memory card. The Texas Instruments chip/ card reader that Alex's work here is currently aimed at does not - it has a completely proprietary, so called "FlashMedia" chip/ interface that talks to MMC/ SD, MemoryStick (/ Pro), and SmartMedia/ xD cards, of which TI have refused to release any specs. Yes, this chip doesn't even use sdhci for communicating with MMC/ SD cards - tifm_sd (Alex's previous work on the MMC/ SD front for this TI chip) handles that. MemoryStick support is more complicated in this case than MMC/ SD, given that on top of TI refusing to release specs for their own FlashMedia chips, Sony will also not release any specs on MemoryStick cards; the same is also true of xD with Olympus and Fuji. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
Mostly just stylistic comments from me here. On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: > From: Alex Dubov <[EMAIL PROTECTED]> > > Sony MemoryStick cards are used in many products manufactured by Sony. They > are available both as storage and as IO expansion cards. Currently, only > MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick > interface. > > Signed-off-by: Alex Dubov <[EMAIL PROTECTED]> For MemoryStick Pro on my TI7421 card reader (since my old MemoryStick card and camera have disappeared somewhere, so I cannot currently test that): Tested-by: Carlos Corbacho <[EMAIL PROTECTED]> However, my only concerns are that: 1) tifm_ms was not autoloaded 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. Although, whether this is an issue with userspace (ie. udev) not dealing with the modules properly, I don't know. > --- /dev/null > +++ b/drivers/memstick/core/memstick.c > @@ -0,0 +1,557 @@ > +/* > + * memstick.c - Sony MemoryStick support File names in comments are now frowned upon - there was a thread on this in October on LKML: http://lkml.org/lkml/2007/10/12/524 Also, before Andrew gets in with this - you should run this through checkpatch, as there are a few errors it throws up (mostly foo* and C99 comments). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
Mostly just stylistic comments from me here. On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Signed-off-by: Alex Dubov [EMAIL PROTECTED] For MemoryStick Pro on my TI7421 card reader (since my old MemoryStick card and camera have disappeared somewhere, so I cannot currently test that): Tested-by: Carlos Corbacho [EMAIL PROTECTED] However, my only concerns are that: 1) tifm_ms was not autoloaded 2) On loading tifm_ms, only memstick was autoloaded - mspro_block was not. Although, whether this is an issue with userspace (ie. udev) not dealing with the modules properly, I don't know. --- /dev/null +++ b/drivers/memstick/core/memstick.c @@ -0,0 +1,557 @@ +/* + * memstick.c - Sony MemoryStick support File names in comments are now frowned upon - there was a thread on this in October on LKML: http://lkml.org/lkml/2007/10/12/524 Also, before Andrew gets in with this - you should run this through checkpatch, as there are a few errors it throws up (mostly foo* and C99 comments). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 00:31:12 Jan Engelhardt wrote: On Dec 31 2007 00:01, Carlos Corbacho wrote: On Monday 24 December 2007 03:06:37 [EMAIL PROTECTED] wrote: From: Alex Dubov [EMAIL PROTECTED] Sony MemoryStick cards are used in many products manufactured by Sony. They are available both as storage and as IO expansion cards. Currently, only MemoryStick Pro storage cards are supported via TI FlashMedia MemoryStick interface. Actually... my MS slot on PCG-U3 is recognized through usb_storage. Then consider yourself very lucky - some laptop manufacturers play nice and the card reader identifies itself, and works as, a USB mass storage device; so it works out of the box with no extra drivers needed for either the card reader, or the flash memory card. The Texas Instruments chip/ card reader that Alex's work here is currently aimed at does not - it has a completely proprietary, so called FlashMedia chip/ interface that talks to MMC/ SD, MemoryStick (/ Pro), and SmartMedia/ xD cards, of which TI have refused to release any specs. Yes, this chip doesn't even use sdhci for communicating with MMC/ SD cards - tifm_sd (Alex's previous work on the MMC/ SD front for this TI chip) handles that. MemoryStick support is more complicated in this case than MMC/ SD, given that on top of TI refusing to release specs for their own FlashMedia chips, Sony will also not release any specs on MemoryStick cards; the same is also true of xD with Olympus and Fuji. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [PATCH] [MEMSTICK] Initial commit for Sony MemoryStick support
On Monday 31 December 2007 01:01:08 Alex Dubov wrote: This is exactly the same as with tifm_sd module if you noticed. Unfortunately not, I've really never used tifm_sd as I don't have any MMC/ SD cards. Second, it is impossible to guess in advance, which type of card is put into slot (Pro, legacy or IO of either sort). I imagined this to be the case. Same as mmc_block, actually. The only way to get it autoloaded, is, again, with appropriate udev rule (uevent is emitted when card type is detected). So do we require changes to the userspace udev rules here, or just some use of modalias in the drivers? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [RFC][PATCH 0/7] Fix the ACPI 1.0 vs ACPI 2.0 suspend ordering issue
On Thursday 27 December 2007 18:03:52 Rafael J. Wysocki wrote: > Please review (and test, if possible). Suspend now works properly here with this patch set. Tested-by: Carlos Corbacho <[EMAIL PROTECTED]> -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe 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/
Re: [RFC][PATCH 0/7] Fix the ACPI 1.0 vs ACPI 2.0 suspend ordering issue
On Thursday 27 December 2007 18:03:52 Rafael J. Wysocki wrote: Please review (and test, if possible). Suspend now works properly here with this patch set. Tested-by: Carlos Corbacho [EMAIL PROTECTED] -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- To unsubscribe 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/
Re: ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Tuesday 25 December 2007 14:07:22 Rafael J. Wysocki wrote: > OK, sorry, the approach is generally reasonable, IMO, but it needs to be a > bit more fine grained. I know, hence this was marked as a hack and not signed off; it's just a demonstration of the general idea with code instead of words. > I'll try to prepare some patches along these lines soon. Much appreciated - I'm much happier with someone who's more familiar with this code than I working on it. -Carlos (Now going back to unwrapping Christmas presents...) -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote: > Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning > from the Working to the Sleeping State (which is what we're discussing > here): > > 3. OSPM places all device drivers into their respective Dx state. If the > device is enabled for wake, it enters the Dx state associated with the wake > capability. If the device is not enabled to wake the system, it enters the > D3 state. > 4. OSPM executes the _PTS control method, passing an argument that > indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, > S3, and S4). > > My opinion is that we should follow this part of the specification and so > we do. This is that same section from ACPI 1.0B: 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). 4. The OS places all device drivers into their respective Dx state. If the device is enabled for wakeup, it enters the Dx state associated with the wakeup capability. If the device is not enabled to wakeup the system, it enters the D3 state. The DSDTs in question also claim ACPI 1.0 compatiblity. > You're wrong, sorry. No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of the ACPI 2.0 spec. * ACPI 1.0 is very clear - we are breaking the 1.0 spec * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which is what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says the opposite. So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is contradictory (and I presume this is one of the points ACPI 3.0 set out to clean up). I will rescind my point on ACPI 2.0 - I don't know what we should or shouldn't be doing there, the spec is unclear. But for ACPI 1.0, we are doing the wrong thing. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Pavel, On Tuesday 25 December 2007 12:12:31 Pavel Machek wrote: > > The patch is fine by me, so if anyone has objections, please speak up. > > Just.. I have been running with very similar patch for few years... it > fixes few prototype machines I have here. I've withdrawn the patch since it doesn't actually fix the issue (turns out it's actually a bug in Linux's handling of suspend-to-RAM for ACPI 1.0 and 2.0 systems). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
Pavel, On Tuesday 25 December 2007 12:12:31 Pavel Machek wrote: The patch is fine by me, so if anyone has objections, please speak up. Just.. I have been running with very similar patch for few years... it fixes few prototype machines I have here. I've withdrawn the patch since it doesn't actually fix the issue (turns out it's actually a bug in Linux's handling of suspend-to-RAM for ACPI 1.0 and 2.0 systems). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Tuesday 25 December 2007 13:26:12 Rafael J. Wysocki wrote: Well, citing from the ACPI 2.0 specification, section 9.1.6 Transitioning from the Working to the Sleeping State (which is what we're discussing here): 3. OSPM places all device drivers into their respective Dx state. If the device is enabled for wake, it enters the Dx state associated with the wake capability. If the device is not enabled to wake the system, it enters the D3 state. 4. OSPM executes the _PTS control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). My opinion is that we should follow this part of the specification and so we do. This is that same section from ACPI 1.0B: 3. The OS executes the Prepare To Sleep (_PTS) control method, passing an argument that indicates the desired sleeping state (1, 2, 3, or 4 representing S1, S2, S3, and S4). 4. The OS places all device drivers into their respective Dx state. If the device is enabled for wakeup, it enters the Dx state associated with the wakeup capability. If the device is not enabled to wakeup the system, it enters the D3 state. The DSDTs in question also claim ACPI 1.0 compatiblity. You're wrong, sorry. No, I'm not entirely wrong - read the 1.0 spec, and read section 7.3.2 of the ACPI 2.0 spec. * ACPI 1.0 is very clear - we are breaking the 1.0 spec * ACPI 2.0 is contradictory - section 7.3.2 repeats 1.0 ad verbatim (which is what I quote in reply to Robert Hancock), but as you point out, 9.3.2 says the opposite. So, 1.0 and 3.0 are very clear and rather different on this, and 2.0 is contradictory (and I presume this is one of the points ACPI 3.0 set out to clean up). I will rescind my point on ACPI 2.0 - I don't know what we should or shouldn't be doing there, the spec is unclear. But for ACPI 1.0, we are doing the wrong thing. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
On Tuesday 25 December 2007 14:07:22 Rafael J. Wysocki wrote: OK, sorry, the approach is generally reasonable, IMO, but it needs to be a bit more fine grained. I know, hence this was marked as a hack and not signed off; it's just a demonstration of the general idea with code instead of words. I'll try to prepare some patches along these lines soon. Much appreciated - I'm much happier with someone who's more familiar with this code than I working on it. -Carlos (Now going back to unwrapping Christmas presents...) -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
Adding Linux-ACPI to CC.
On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
> According to the earlier versions of the ACPI spec, Linux is doing the
> wrong thing - we should call _PTS() before we start powerding down devices,
> or notifying device drivers to start suspending.
>
> So, my limited understanding of what we currently do for ACPI
> suspend-to-RAM is:
>
> 1) Freeze processes/ devices
> 2) Put all devices into low power mode
> 3) Execute _PTS()
> 4) Suspend system
>
> So the problem is - our current suspend order is fine for ACPI 3.0 and
> above, but for pre-3.0 systems, this violates the older specs, where 2) and
> 3) should be reversed.
The following is a hack to illustrate what I'm getting at (this is
tested on x86-64) (it's a hack since it does all the ACPI prepare bits
during set_target() for the pre ACPI 3.0 systems, rather than prepare() -
whether this can be cleaned up to move out just the _PTS() call, I don't
know).
It abuses suspend_ops->set_target(), but was the easiest way to quickly
demonstrate this (since the kerneldoc for set_target() says it will always
be executed before we suspend the devices).
-Carlos
---
drivers/acpi/sleep/main.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 96d23b3..89e708b 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -77,8 +77,19 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
} else {
printk(KERN_ERR "ACPI does not support this state: %d\n",
pm_state);
- error = -ENOSYS;
+ return -ENOSYS;
}
+
+ /*
+* For ACPI 1.0 and 2.0 systems, we must run the preparation methods
+* before we put the devices into low power mode.
+*/
+ if (acpi_gbl_FADT.header.revision < 3) {
+ error = acpi_sleep_prepare(acpi_target_sleep_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+ }
+
return error;
}
@@ -91,10 +102,17 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
static int acpi_pm_prepare(void)
{
- int error = acpi_sleep_prepare(acpi_target_sleep_state);
+ int error = 0;
- if (error)
- acpi_target_sleep_state = ACPI_STATE_S0;
+ /*
+* For ACPI 3.0 or newer systems, we must run the preparation methods
+* after we put the devices into low power mode.
+*/
+ if (acpi_gbl_FADT.header.revision >= 3) {
+ error = acpi_sleep_prepare(acpi_target_sleep_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+ }
return error;
}
--
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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 22:40:46 Robert Hancock wrote: > The ACPI spec has the following to say about the _PTS method: > > "The platform must not make any assumptions about the state of the > machine when _PTS is called. For example, operation region accesses that > require devices to be configured and enabled may not succeed, as these > devices may be in a non-decoding state due to plug and play or power > management operations." That is from the 3.0 spec though. And it looks like the definition changed from pre-3.0 to 3.0 and above. This is what the 1.0B spec says (and this is also repeated verbatim in 2.0, 2.0a, 2.0b, and 2.0c): "The _PTS control method is executed by the operating system at the beginning of the sleep process for S1, S2, S3, S4, and for orderly S5 shutdown. The sleeping state value (1, 2, 3, 4, or 5) is passed to the _PTS control method. Before the OS notifies native device drivers and prepares the system software for a system sleeping state, it executes this ACPI control method. Thus, this control method can be executed a relatively long time before actually entering the desired sleeping state. In addition, the OS can abort the sleeping operation without notification to the ACPI driver, in which case another _PTS would occur some time before the next attempt by the OS to enter a sleeping state. The _PTS control method cannot modify the current configuration or power state of any device in the system. For example, _PTS would simply store the sleep type in the embedded controller in sequencing the system into a sleep state when the SLP_EN bit is set." According to the earlier versions of the ACPI spec, Linux is doing the wrong thing - we should call _PTS() before we start powerding down devices, or notifying device drivers to start suspending. So, my limited understanding of what we currently do for ACPI suspend-to-RAM is: 1) Freeze processes/ devices 2) Put all devices into low power mode 3) Execute _PTS() 4) Suspend system So the problem is - our current suspend order is fine for ACPI 3.0 and above, but for pre-3.0 systems, this violates the older specs, where 2) and 3) should be reversed. > I would guess some BIOS writers failed to heed this.. No, it looks like the BIOS is obeying the older specs, and Linux is at fault here for breaking the suspend logic of pre ACPI 3.0 systems. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 18:34:21 Linus Torvalds wrote: > On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: > > Well, having considered that for a longer while, I think the AML code is > > referring to a device that we have suspended already, and since it's in a > > low power state, it just can't handle the reference. > > > > If that is the case, we'll have to find the device (that should be > > possible using some code instrumentation) and move the suspending of it > > into the late stage. > > Yes. My own experimentation (in device_suspend(), calling _PTS() in the AML after each suspend_device() runs, until one device causes it to hang) points to ohci_hcd being the culprit here (with or without any devices attached). With the ohci_hcd module unloaded, the machine suspends just fine[1]. Of course, I'm at a complete loss as to why suspending OHCI would cause a problem for an IO port write. > NOTE! This following patch is just for discussion, and while I think it's > conceptually a good thing to try, I don't think it will help Carlos' > problem. But removing the "pci_set_power_state()" in agp_nvidia_suspend() > might. nvidia-agp cannot be built on x86-64, so it's not the culprit in this case. -Carlos [1] And yes, I double checked the custom DSDT is not loaded this time. -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 18:34:21 Linus Torvalds wrote: On Mon, 24 Dec 2007, Rafael J. Wysocki wrote: Well, having considered that for a longer while, I think the AML code is referring to a device that we have suspended already, and since it's in a low power state, it just can't handle the reference. If that is the case, we'll have to find the device (that should be possible using some code instrumentation) and move the suspending of it into the late stage. Yes. My own experimentation (in device_suspend(), calling _PTS() in the AML after each suspend_device() runs, until one device causes it to hang) points to ohci_hcd being the culprit here (with or without any devices attached). With the ohci_hcd module unloaded, the machine suspends just fine[1]. Of course, I'm at a complete loss as to why suspending OHCI would cause a problem for an IO port write. NOTE! This following patch is just for discussion, and while I think it's conceptually a good thing to try, I don't think it will help Carlos' problem. But removing the pci_set_power_state() in agp_nvidia_suspend() might. nvidia-agp cannot be built on x86-64, so it's not the culprit in this case. -Carlos [1] And yes, I double checked the custom DSDT is not loaded this time. -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 22:40:46 Robert Hancock wrote: The ACPI spec has the following to say about the _PTS method: The platform must not make any assumptions about the state of the machine when _PTS is called. For example, operation region accesses that require devices to be configured and enabled may not succeed, as these devices may be in a non-decoding state due to plug and play or power management operations. That is from the 3.0 spec though. And it looks like the definition changed from pre-3.0 to 3.0 and above. This is what the 1.0B spec says (and this is also repeated verbatim in 2.0, 2.0a, 2.0b, and 2.0c): The _PTS control method is executed by the operating system at the beginning of the sleep process for S1, S2, S3, S4, and for orderly S5 shutdown. The sleeping state value (1, 2, 3, 4, or 5) is passed to the _PTS control method. Before the OS notifies native device drivers and prepares the system software for a system sleeping state, it executes this ACPI control method. Thus, this control method can be executed a relatively long time before actually entering the desired sleeping state. In addition, the OS can abort the sleeping operation without notification to the ACPI driver, in which case another _PTS would occur some time before the next attempt by the OS to enter a sleeping state. The _PTS control method cannot modify the current configuration or power state of any device in the system. For example, _PTS would simply store the sleep type in the embedded controller in sequencing the system into a sleep state when the SLP_EN bit is set. According to the earlier versions of the ACPI spec, Linux is doing the wrong thing - we should call _PTS() before we start powerding down devices, or notifying device drivers to start suspending. So, my limited understanding of what we currently do for ACPI suspend-to-RAM is: 1) Freeze processes/ devices 2) Put all devices into low power mode 3) Execute _PTS() 4) Suspend system So the problem is - our current suspend order is fine for ACPI 3.0 and above, but for pre-3.0 systems, this violates the older specs, where 2) and 3) should be reversed. I would guess some BIOS writers failed to heed this.. No, it looks like the BIOS is obeying the older specs, and Linux is at fault here for breaking the suspend logic of pre ACPI 3.0 systems. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
ACPI: _PTS ordering needs fixing for pre ACPI 3.0 systems (was: Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM)
Adding Linux-ACPI to CC.
On Tuesday 25 December 2007 00:03:25 Carlos Corbacho wrote:
According to the earlier versions of the ACPI spec, Linux is doing the
wrong thing - we should call _PTS() before we start powerding down devices,
or notifying device drivers to start suspending.
So, my limited understanding of what we currently do for ACPI
suspend-to-RAM is:
1) Freeze processes/ devices
2) Put all devices into low power mode
3) Execute _PTS()
4) Suspend system
So the problem is - our current suspend order is fine for ACPI 3.0 and
above, but for pre-3.0 systems, this violates the older specs, where 2) and
3) should be reversed.
The following is a hack to illustrate what I'm getting at (this is
tested on x86-64) (it's a hack since it does all the ACPI prepare bits
during set_target() for the pre ACPI 3.0 systems, rather than prepare() -
whether this can be cleaned up to move out just the _PTS() call, I don't
know).
It abuses suspend_ops-set_target(), but was the easiest way to quickly
demonstrate this (since the kerneldoc for set_target() says it will always
be executed before we suspend the devices).
-Carlos
---
drivers/acpi/sleep/main.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 96d23b3..89e708b 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -77,8 +77,19 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
} else {
printk(KERN_ERR ACPI does not support this state: %d\n,
pm_state);
- error = -ENOSYS;
+ return -ENOSYS;
}
+
+ /*
+* For ACPI 1.0 and 2.0 systems, we must run the preparation methods
+* before we put the devices into low power mode.
+*/
+ if (acpi_gbl_FADT.header.revision 3) {
+ error = acpi_sleep_prepare(acpi_target_sleep_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+ }
+
return error;
}
@@ -91,10 +102,17 @@ static int acpi_pm_set_target(suspend_state_t pm_state)
static int acpi_pm_prepare(void)
{
- int error = acpi_sleep_prepare(acpi_target_sleep_state);
+ int error = 0;
- if (error)
- acpi_target_sleep_state = ACPI_STATE_S0;
+ /*
+* For ACPI 3.0 or newer systems, we must run the preparation methods
+* after we put the devices into low power mode.
+*/
+ if (acpi_gbl_FADT.header.revision = 3) {
+ error = acpi_sleep_prepare(acpi_target_sleep_state);
+ if (error)
+ acpi_target_sleep_state = ACPI_STATE_S0;
+ }
return error;
}
--
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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 01:14:34 Linus Torvalds wrote: > Side note: we could obviously undo the commit that triggered this for you > [..] > In other words, we'd have to go back to our original ordering, which Len > said was fundamentally wrong. I don't think anybody really wants that. Nor would I argue to do so. > It would be better to figure out why "device_suspend()" apparently causes > problems for your AML crud. Will do - thanks for the pointer. > Oh, and why is linux-kernel cc'd, but not linux-pm? Because I like to compound my errors (I mean, if you're going to screw up, you might as well _really_ go for it). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Sunday 23 December 2007 23:12:47 H. Peter Anvin wrote: > Rafael J. Wysocki wrote: > > On Sunday, 23 of December 2007, Linus Torvalds wrote: > >> On Sun, 23 Dec 2007, Rafael J. Wysocki wrote: > >>> The patch is fine by me, so if anyone has objections, please speak up. > >> > >> There is absolutely *no* way I will apply this in an -rc6 release. > >> > This is totally the wrong way to go about it. Please disregard the patch anyway - my test system was still using the custom DSDT - it doesn't fix anything. Regardless, Linus' patch in question (in combination with Rafael's suspend reordering work) still broke suspend, and the port 0x142E write is still the offender, so something is still not playing nice - I'm just now at a complete loss as to what. (PNPACPI came to mind as a suspect, but even with that disabled, this board/ chipset still wedges on suspend). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Sunday 23 December 2007 23:12:47 H. Peter Anvin wrote: Rafael J. Wysocki wrote: On Sunday, 23 of December 2007, Linus Torvalds wrote: On Sun, 23 Dec 2007, Rafael J. Wysocki wrote: The patch is fine by me, so if anyone has objections, please speak up. There is absolutely *no* way I will apply this in an -rc6 release. This is totally the wrong way to go about it. Please disregard the patch anyway - my test system was still using the custom DSDT - it doesn't fix anything. Regardless, Linus' patch in question (in combination with Rafael's suspend reordering work) still broke suspend, and the port 0x142E write is still the offender, so something is still not playing nice - I'm just now at a complete loss as to what. (PNPACPI came to mind as a suspect, but even with that disabled, this board/ chipset still wedges on suspend). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: x86: Increase PCIBIOS_MIN_IO to 0x1500 to fix nForce 4 suspend-to-RAM
On Monday 24 December 2007 01:14:34 Linus Torvalds wrote: Side note: we could obviously undo the commit that triggered this for you [..] In other words, we'd have to go back to our original ordering, which Len said was fundamentally wrong. I don't think anybody really wants that. Nor would I argue to do so. It would be better to figure out why device_suspend() apparently causes problems for your AML crud. Will do - thanks for the pointer. Oh, and why is linux-kernel cc'd, but not linux-pm? Because I like to compound my errors (I mean, if you're going to screw up, you might as well _really_ go for it). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: PATCH] adding wistron_btns support for X86_64 systems.
(CC'ing linux-input, as that is the relevant subsystem list for wistron-btns). Rémi Hérilier wrote: > To use my previous patch (wistron_btns support for fujitsu-siemens amilo > pro edition v3505) with my laptop, I need to make the wistron module > compile for x86_64. It is based on Linux 2.4.24-rc4 too. NAK. You cannot make 32 bit BIOS calls in a 64 bit OS. This will (and does) segfault on x86-64 (tested on my Aspire 5020, where call_bios wistron-btns just segfaults on x86-64 with this patch). This is a known issue, and the reason why wistron-btns (and the out-of-tree acerhk) have not been ported to x86-64. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: PATCH] adding wistron_btns support for X86_64 systems.
(CC'ing linux-input, as that is the relevant subsystem list for wistron-btns). Rémi Hérilier wrote: To use my previous patch (wistron_btns support for fujitsu-siemens amilo pro edition v3505) with my laptop, I need to make the wistron module compile for x86_64. It is based on Linux 2.4.24-rc4 too. NAK. You cannot make 32 bit BIOS calls in a 64 bit OS. This will (and does) segfault on x86-64 (tested on my Aspire 5020, where call_bios wistron-btns just segfaults on x86-64 with this patch). This is a known issue, and the reason why wistron-btns (and the out-of-tree acerhk) have not been ported to x86-64. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 02:13:22 Elvis Pranskevichus wrote: > Hi Carlos, > > I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to > bugzilla entry #9514: > > http://bugzilla.kernel.org/attachment.cgi?id=14132 A quick look over the DSDT shows that there is no ACPI-WMI mapper device (PNP0C14) on this board; so WMI is, at least in this case, not the solution to this bug. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: > I suspect the manufacturers would say "Oh, the sensors? The BIOS > isn't broken, you're just supposed to use WMI or some (undocumented) > ACPI device to get at those." It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 00:20:21 Bjorn Helgaas wrote: I suspect the manufacturers would say Oh, the sensors? The BIOS isn't broken, you're just supposed to use WMI or some (undocumented) ACPI device to get at those. It's quite possible - can we have DSDTs for the boards in question so we can quickly check if this is a possibility? (Basically, to see if they have PNP0C14 devices - if they don't, then I'm afraid it's nothing to do with WMI). -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
Re: [lm-sensors] 2.6.24-rc4 hwmon it87 probe fails
On Thursday 20 December 2007 02:13:22 Elvis Pranskevichus wrote: Hi Carlos, I've attached the DSDT for Gigabyte GA-965G-DS3 (rev 1.0, bios rev. F9) to bugzilla entry #9514: http://bugzilla.kernel.org/attachment.cgi?id=14132 A quick look over the DSDT shows that there is no ACPI-WMI mapper device (PNP0C14) on this board; so WMI is, at least in this case, not the solution to this bug. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D -- 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/
x86: Add HPET force support for MCP55 (nForce 5) chipsets
From: Carlos Corbacho <[EMAIL PROTECTED]>
Add support to force_hpet for all known MCP55 (nForce 5) chipset
LPC bridges.
---
These are the untested nForce 5 chips (taken from Mikko's original
patch, and checked against pci.ids).
arch/x86/kernel/quirks.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index df01a1e..8f72148 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -354,6 +354,24 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0050,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0051,
nvidia_force_enable_hpet);
+/* LPC bridges */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0360,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0361,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0362,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0363,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0364,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0365,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0366,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0367,
+ nvidia_force_enable_hpet);
+
void force_hpet_resume(void)
{
switch (force_hpet_resume_type) {
--
1.5.2.2
-
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/
[PATCH] x86: Fix resume for nVidia and force_hpet
From: Carlos Corbacho <[EMAIL PROTECTED]> Actually set force_hpet_resume_type. --- Whoops, just noticed I forgot to re-add this to the patch before submitting it. arch/x86/kernel/quirks.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c index cb21bcb..df01a1e 100644 --- a/arch/x86/kernel/quirks.c +++ b/arch/x86/kernel/quirks.c @@ -344,6 +344,7 @@ static void nvidia_force_enable_hpet(struct pci_dev *dev) printk(KERN_DEBUG "Force enabled HPET at base address 0x%lx\n", force_hpet_address); cached_dev = dev; + force_hpet_resume_type = NVIDIA_FORCE_HPET_RESUME; return; } -- 1.5.2.2 - 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/
[PATCH] x86: Force enable HPET for CK804 (nForce 4) chipsets
From: Carlos Corbacho <[EMAIL PROTECTED]>
This patch adds a quirk from LinuxBIOS to force enable HPET on
the nVidia CK804 (nForce 4) chipset.
This quirk can very likely support more than just nForce 4
(LinuxBIOS use the same code for nForce 5), and possibly nForce 3,
but I don't have those chipsets, so cannot add and test them.
Tested on an Abit KN9 (CK804).
Signed-off-by: Carlos Corbacho <[EMAIL PROTECTED]>
---
Thomas,
I've rewritten the code based on what LinuxBIOS does, since they have a better
idea
of how to drive the HPET than I do. I've tested this code, and it's also working
fine here on my system.
Documentation/kernel-parameters.txt |3 +-
arch/x86/kernel/quirks.c| 36 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 983f631..8abbfe6 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -434,7 +434,8 @@ and is between 256 and 4096 characters. It is defined in
the file
hpet= [X86-32,HPET] option to control HPET usage
Format: { enable (default) | disable | force }
disable: disable HPET and use PIT instead
- force: allow force enabled of undocumented chips (ICH4,
VIA)
+ force: allow force enabled of undocumented chips (ICH4,
+ VIA, nVidia)
com20020= [HW,NET] ARCnet - COM20020 chipset
Format:
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a4ce191..cb21bcb 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -60,7 +60,8 @@ static enum {
NONE_FORCE_HPET_RESUME,
OLD_ICH_FORCE_HPET_RESUME,
ICH_FORCE_HPET_RESUME,
- VT8237_FORCE_HPET_RESUME
+ VT8237_FORCE_HPET_RESUME,
+ NVIDIA_FORCE_HPET_RESUME,
} force_hpet_resume_type;
static void __iomem *rcba_base;
@@ -321,6 +322,36 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8235,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
vt8237_force_enable_hpet);
+/*
+ * Undocumented chipset feature taken from LinuxBIOS.
+ */
+static void nvidia_force_hpet_resume(void)
+{
+ pci_write_config_dword(cached_dev, 0x44, 0xfed1);
+ printk(KERN_DEBUG "Force enabled HPET at resume\n");
+}
+
+static void nvidia_force_enable_hpet(struct pci_dev *dev)
+{
+ u32 uninitialized_var(val);
+
+ if (!hpet_force_user || hpet_address || force_hpet_address)
+ return;
+
+ pci_write_config_dword(dev, 0x44, 0xfed1);
+ pci_read_config_dword(dev, 0x44, );
+ force_hpet_address = val & 0xfffe;
+ printk(KERN_DEBUG "Force enabled HPET at base address 0x%lx\n",
+ force_hpet_address);
+ cached_dev = dev;
+ return;
+}
+
+/* ISA Bridges */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0050,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0051,
+ nvidia_force_enable_hpet);
void force_hpet_resume(void)
{
@@ -334,6 +365,9 @@ void force_hpet_resume(void)
case VT8237_FORCE_HPET_RESUME:
return vt8237_force_hpet_resume();
+ case NVIDIA_FORCE_HPET_RESUME:
+ return nvidia_force_hpet_resume();
+
default:
break;
}
--
1.5.2.2
-
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/
Re: nVidia HPET force enable - merge requirements? (resend)
Thomas,
On Friday 19 October 2007 07:50:08 Thomas Gleixner wrote:
> So if there are working quirks, please refactor them analogous to the
> existing ones in quirks.c.
>
> All undocumented chipset poking needs to be protected by the
> hpet=force boot option, so the default is not to do scan for it.
Would the following patch be more acceptable then? I've limited the device
id's to just the nForce 4 chipset, because that's the only one I have here
to test with at the moment - it appears to work fine:
hpet clockevent registered
hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31
hpet0: 3 32-bit timers, 2500 Hz
Time: hpet clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
At the moment, I'm not clear on how to detect if the HPET has not been
enabled by the BIOS (but given that this is hidden behind hpet=force,
would this be acceptable, since the user would have to explicitly call
hpet=force, and then it either works or doesn't?)
-Carlos
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a4ce191..7c772bf 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -321,6 +321,26 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8235,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
vt8237_force_enable_hpet);
+static void nvidia_force_enable_hpet(struct pci_dev *dev)
+{
+ u32 uninitialized_var(val);
+
+ if (!hpet_force_user || hpet_address || force_hpet_address)
+ return;
+
+ pci_read_config_dword(dev, 0x44, );
+ force_hpet_address = val;
+ printk(KERN_DEBUG "Force enabled HPET at base address 0x%lx\n",
+ force_hpet_address);
+ cached_dev = dev;
+ return;
+}
+
+/* ISA Bridge */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0050,
+nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0051,
+nvidia_force_enable_hpet);
void force_hpet_resume(void)
{
-
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/
[PATCH] x86: Force enable HPET for CK804 (nForce 4) chipsets
From: Carlos Corbacho [EMAIL PROTECTED]
This patch adds a quirk from LinuxBIOS to force enable HPET on
the nVidia CK804 (nForce 4) chipset.
This quirk can very likely support more than just nForce 4
(LinuxBIOS use the same code for nForce 5), and possibly nForce 3,
but I don't have those chipsets, so cannot add and test them.
Tested on an Abit KN9 (CK804).
Signed-off-by: Carlos Corbacho [EMAIL PROTECTED]
---
Thomas,
I've rewritten the code based on what LinuxBIOS does, since they have a better
idea
of how to drive the HPET than I do. I've tested this code, and it's also working
fine here on my system.
Documentation/kernel-parameters.txt |3 +-
arch/x86/kernel/quirks.c| 36 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 983f631..8abbfe6 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -434,7 +434,8 @@ and is between 256 and 4096 characters. It is defined in
the file
hpet= [X86-32,HPET] option to control HPET usage
Format: { enable (default) | disable | force }
disable: disable HPET and use PIT instead
- force: allow force enabled of undocumented chips (ICH4,
VIA)
+ force: allow force enabled of undocumented chips (ICH4,
+ VIA, nVidia)
com20020= [HW,NET] ARCnet - COM20020 chipset
Format:
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a4ce191..cb21bcb 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -60,7 +60,8 @@ static enum {
NONE_FORCE_HPET_RESUME,
OLD_ICH_FORCE_HPET_RESUME,
ICH_FORCE_HPET_RESUME,
- VT8237_FORCE_HPET_RESUME
+ VT8237_FORCE_HPET_RESUME,
+ NVIDIA_FORCE_HPET_RESUME,
} force_hpet_resume_type;
static void __iomem *rcba_base;
@@ -321,6 +322,36 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8235,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
vt8237_force_enable_hpet);
+/*
+ * Undocumented chipset feature taken from LinuxBIOS.
+ */
+static void nvidia_force_hpet_resume(void)
+{
+ pci_write_config_dword(cached_dev, 0x44, 0xfed1);
+ printk(KERN_DEBUG Force enabled HPET at resume\n);
+}
+
+static void nvidia_force_enable_hpet(struct pci_dev *dev)
+{
+ u32 uninitialized_var(val);
+
+ if (!hpet_force_user || hpet_address || force_hpet_address)
+ return;
+
+ pci_write_config_dword(dev, 0x44, 0xfed1);
+ pci_read_config_dword(dev, 0x44, val);
+ force_hpet_address = val 0xfffe;
+ printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n,
+ force_hpet_address);
+ cached_dev = dev;
+ return;
+}
+
+/* ISA Bridges */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0050,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0051,
+ nvidia_force_enable_hpet);
void force_hpet_resume(void)
{
@@ -334,6 +365,9 @@ void force_hpet_resume(void)
case VT8237_FORCE_HPET_RESUME:
return vt8237_force_hpet_resume();
+ case NVIDIA_FORCE_HPET_RESUME:
+ return nvidia_force_hpet_resume();
+
default:
break;
}
--
1.5.2.2
-
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/
[PATCH] x86: Fix resume for nVidia and force_hpet
From: Carlos Corbacho [EMAIL PROTECTED] Actually set force_hpet_resume_type. --- Whoops, just noticed I forgot to re-add this to the patch before submitting it. arch/x86/kernel/quirks.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c index cb21bcb..df01a1e 100644 --- a/arch/x86/kernel/quirks.c +++ b/arch/x86/kernel/quirks.c @@ -344,6 +344,7 @@ static void nvidia_force_enable_hpet(struct pci_dev *dev) printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n, force_hpet_address); cached_dev = dev; + force_hpet_resume_type = NVIDIA_FORCE_HPET_RESUME; return; } -- 1.5.2.2 - 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/
Re: nVidia HPET force enable - merge requirements? (resend)
Thomas,
On Friday 19 October 2007 07:50:08 Thomas Gleixner wrote:
So if there are working quirks, please refactor them analogous to the
existing ones in quirks.c.
All undocumented chipset poking needs to be protected by the
hpet=force boot option, so the default is not to do scan for it.
Would the following patch be more acceptable then? I've limited the device
id's to just the nForce 4 chipset, because that's the only one I have here
to test with at the moment - it appears to work fine:
hpet clockevent registered
hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31
hpet0: 3 32-bit timers, 2500 Hz
Time: hpet clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
At the moment, I'm not clear on how to detect if the HPET has not been
enabled by the BIOS (but given that this is hidden behind hpet=force,
would this be acceptable, since the user would have to explicitly call
hpet=force, and then it either works or doesn't?)
-Carlos
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index a4ce191..7c772bf 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -321,6 +321,26 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8235,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
vt8237_force_enable_hpet);
+static void nvidia_force_enable_hpet(struct pci_dev *dev)
+{
+ u32 uninitialized_var(val);
+
+ if (!hpet_force_user || hpet_address || force_hpet_address)
+ return;
+
+ pci_read_config_dword(dev, 0x44, val);
+ force_hpet_address = val;
+ printk(KERN_DEBUG Force enabled HPET at base address 0x%lx\n,
+ force_hpet_address);
+ cached_dev = dev;
+ return;
+}
+
+/* ISA Bridge */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0050,
+nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0051,
+nvidia_force_enable_hpet);
void force_hpet_resume(void)
{
-
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/
x86: Add HPET force support for MCP55 (nForce 5) chipsets
From: Carlos Corbacho [EMAIL PROTECTED]
Add support to force_hpet for all known MCP55 (nForce 5) chipset
LPC bridges.
---
These are the untested nForce 5 chips (taken from Mikko's original
patch, and checked against pci.ids).
arch/x86/kernel/quirks.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c
index df01a1e..8f72148 100644
--- a/arch/x86/kernel/quirks.c
+++ b/arch/x86/kernel/quirks.c
@@ -354,6 +354,24 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0050,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0051,
nvidia_force_enable_hpet);
+/* LPC bridges */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0360,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0361,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0362,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0363,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0364,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0365,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0366,
+ nvidia_force_enable_hpet);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, 0x0367,
+ nvidia_force_enable_hpet);
+
void force_hpet_resume(void)
{
switch (force_hpet_resume_type) {
--
1.5.2.2
-
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/
nVidia HPET force enable - merge requirements? (resend)
(Resend with CC's fixed) Back in April, Mikko posted a patch to force enable the HPET on some nVidia chipsets: v2: http://lkml.org/lkml/2007/4/16/46 v3: http://lkml.org/lkml/2007/4/17/354 What would need to be done to this patch to get it into x86 now (besides i386/ x86_64 -> x86 conversion), given that: A) There is now a force_hpet boot parameter in the x86 tree (mm branch) (rather than relying on the solution in the earlier patches of a config option). B) On the other hand, the force-quirk's are going into quirks.c, whilst Mikko's patch requires PCI scanning in early_quirks.c (could the PCI scanning be done in early_quirks.c and the actual HPET enabling handled in quirks.c later - or if not, could this early quirk play be made to obey the force_hpet boot option)? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - 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/
nVidia HPET force enable - merge requirements? (resend)
(Resend with CC's fixed) Back in April, Mikko posted a patch to force enable the HPET on some nVidia chipsets: v2: http://lkml.org/lkml/2007/4/16/46 v3: http://lkml.org/lkml/2007/4/17/354 What would need to be done to this patch to get it into x86 now (besides i386/ x86_64 - x86 conversion), given that: A) There is now a force_hpet boot parameter in the x86 tree (mm branch) (rather than relying on the solution in the earlier patches of a config option). B) On the other hand, the force-quirk's are going into quirks.c, whilst Mikko's patch requires PCI scanning in early_quirks.c (could the PCI scanning be done in early_quirks.c and the actual HPET enabling handled in quirks.c later - or if not, could this early quirk play be made to obey the force_hpet boot option)? -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - 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/
Re: [PATCH] Make wistron-btns recognize special keys on Medion WIM2160 notebooks
Bernhard Rosenkraenzer wrote: > The patch below adds support for Medion WIM2160 notebooks to the > wistron-btns driver. Do these keys emit proper scancodes though? If yes (i.e. you press a button and get a warning about "unknown scancodes" in dmesg), then they should not be added to wistron-btns, but to hal-info in userspace. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - 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/
Re: [PATCH] Make wistron-btns recognize special keys on Medion WIM2160 notebooks
Bernhard Rosenkraenzer wrote: The patch below adds support for Medion WIM2160 notebooks to the wistron-btns driver. Do these keys emit proper scancodes though? If yes (i.e. you press a button and get a warning about unknown scancodes in dmesg), then they should not be added to wistron-btns, but to hal-info in userspace. -Carlos -- E-Mail: [EMAIL PROTECTED] Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - 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/
