[PATCH 1/1] x86: Added support for Acer Aspire 5755G fan control.

[Tero Keski-Valkama]

This patch is a patch to add support for Acer Aspire 5755G fan control
to acerhdf module for the latest BIOS version available in the Acer
web site, V1.20.

<DSDT disassembly dump>
...
Offset (0xA7),
OSTT, 8,
OSST, 8,
THLT, 8,
TCNL, 8,
MODE, 1,
, 2,
INIT, 1,
FAN1, 1,
FAN2, 1,
FANT, 1,
SKNM, 1,
SDTM, 8,
FSSN, 4,
FANU, 4,
...
</DSDT disassembly dump>

By experiment it was found that setting the register address 0xAB to
0x00 (FAN1 -> 0) caused the fan to stop, and setting it to the
original value of 0x08 (FAN1 -> 1) caused the fan to operate
automatically in BIOS control.

By observation the value in the Embedded Controller table which
correlated best with the temperature, and changes up and down along
with real temperature was the register address 0xB4 (SKTC).

This patch and related evidence and dumps were sent to the original
authors of the module, peter and bp.

The original author of the patch: Tero Keski-Valkama

Signed-off-by: Tero Keski-Valkama <tero.kesk...@neter.fi>
---
drivers/platform/x86/acerhdf.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index 39abb15..06c5c85 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -7,6 +7,8 @@
* http://piie.net
* 2009 Borislav Petkov bp (a) alien8.de
*
+ * 2012 Tero Keski-Valkama tero.keski-valkama (a) neter.fi
+ *
* Inspired by and many thanks to:
* o acerfand - Rachel Greenham
* o acer_ec.pl - Michael Kurz michi.kurz (at) googlemail.com
@@ -187,6 +189,8 @@ static const struct bios_settings_t bios_tbl[] = {
{"Acer", "Aspire 1810T", "v1.3310", 0x55, 0x58, {0x9e, 0x00} },
{"Acer", "Aspire 1810TZ", "v1.3314", 0x55, 0x58, {0x9e, 0x00} },
{"Acer", "Aspire 1810T", "v1.3314", 0x55, 0x58, {0x9e, 0x00} },
+ /* Acer 5755G */
+ {"Acer", "Aspire 5755G", "V1.20", 0xab, 0xb4, {0x00, 0x08} },
/* Acer 531 */
{"Acer", "AO531h", "v0.3104", 0x55, 0x58, {0x20, 0x00} },
{"Acer", "AO531h", "v0.3201", 0x55, 0x58, {0x20, 0x00} },
@@ -723,6 +727,7 @@ MODULE_ALIAS("dmi:*:*Acer*:pnAO751h*:");
MODULE_ALIAS("dmi:*:*Acer*:pnAspire*1410*:");
MODULE_ALIAS("dmi:*:*Acer*:pnAspire*1810*:");
MODULE_ALIAS("dmi:*:*Acer*:pnAspire*1825PTZ:");
+MODULE_ALIAS("dmi:*:*Acer*:pnAspire*5755G:");
MODULE_ALIAS("dmi:*:*Acer*:pnAO531*:");
MODULE_ALIAS("dmi:*:*Acer*:TravelMate*7730G:");
MODULE_ALIAS("dmi:*:*Gateway*:pnAOA*:");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Borislav Petkov]

No need for that - the Signed-off-by and patch authorship annotation in
git says that already.

>
> Signed-off-by: Tero Keski-Valkama <tero.kesk...@neter.fi>

But before we go with this any further: you mentioned some issues still
with acerhdf - you don't want to turn off your fan but to turn it to
full?

I think in this case, you want to simply not load the driver and use the
BIOS settings, no?

--
Regards/Gruss,
Boris.

[Tero Keski-Valkama]

2012/9/25 Borislav Petkov <b...@alien8.de>:

> On Tue, Sep 25, 2012 at 10:34:13AM +0300, Tero Keski-Valkama wrote:
>
> But before we go with this any further: you mentioned some issues still
> with acerhdf - you don't want to turn off your fan but to turn it to
> full?
>
> I think in this case, you want to simply not load the driver and use the
> BIOS settings, no?
>
> --
> Regards/Gruss,
> Boris.

Technically I think my original issue is about thermal zones, and BIOS
control doesn't solve it as is. However, the patch should be valid,
even if it doesn't solve my original issue.

The thing is that passive cooling thermal zones throttle all the cores
to stone age, to 800 MHz, before the fan even really starts powering
up from the low default level. So, my original problem would be solved
by:
a) Direct control of the fan, to be able to put it on full for example
through userspace control,
b) Changing the active cooling thermal zones, so that the fan speeds
up earlier, or
c) Changing the passive cooling (CPU throttling) thermal zones, so
that it doesn't prevent fan from speeding up in the first place.

At the moment, I don't see any way to change the thermal zones through
existing interfaces for this laptop, and I don't see any potential
thermal zone controls, or manual fan control option in the Embedded
Controller registry.

--
Kind Regards / Ystävällisin terveisin,

Tero Keski-Valkama, MSc(Tech)

+358 (0)46 876 0485

tero.kesk...@neter.fi
http://www.neter.fi

[Borislav Petkov]

Adding Peter.

On Tue, Sep 25, 2012 at 12:41:11PM +0300, Tero Keski-Valkama wrote:
> 2012/9/25 Borislav Petkov <b...@alien8.de>:
> > On Tue, Sep 25, 2012 at 10:34:13AM +0300, Tero Keski-Valkama wrote:
> >
> > But before we go with this any further: you mentioned some issues still
> > with acerhdf - you don't want to turn off your fan but to turn it to
> > full?
> >
> > I think in this case, you want to simply not load the driver and use the
> > BIOS settings, no?
> >
> > --
> > Regards/Gruss,
> > Boris.
>
> Technically I think my original issue is about thermal zones, and BIOS
> control doesn't solve it as is. However, the patch should be valid,
> even if it doesn't solve my original issue.
>
> The thing is that passive cooling thermal zones throttle all the cores
> to stone age, to 800 MHz, before the fan even really starts powering
> up from the low default level.

I don't understand: you want the thermal zones to not throttle your cpu
to 800 Mhz and/or the fan to start sooner?

> So, my original problem would be solved
> by:
> a) Direct control of the fan, to be able to put it on full for example
> through userspace control,

That's always a bad idea, especially if userspace dies on you.

> b) Changing the active cooling thermal zones, so that the fan speeds
> up earlier, or

Ok, I see, here's what you want.

> c) Changing the passive cooling (CPU throttling) thermal zones, so
> that it doesn't prevent fan from speeding up in the first place.
>
> At the moment, I don't see any way to change the thermal zones through
> existing interfaces for this laptop, and I don't see any potential
> thermal zone controls, or manual fan control option in the Embedded
> Controller registry.

I'll let Peter have a look at the patch too.

@Peter, it is at: http://lkml.org/lkml/2012/9/25/92

Btw, the commit message starts with "x86:... " and it should be
"acerhdf:.. " Peter, please change that when handling the patch further.

Also, you've added yourself to the copyright - this means that you're
pretty much going to get all future email about acerhdf. Do you really
want that?

--
Regards/Gruss,
Boris.

[Tero Keski-Valkama]

2012/9/26 Borislav Petkov <b...@alien8.de>:

Yes. I disabled acpi_cpufreq and cpufreq daemon, so throttling to iron
age didn't happen now, but the fan didn't start increasing cooling
either. So while it seems during testing different values with the EC
registers I achieved at one point automatic fan control by BIOS, but
it's not the default state. The default state is still constant speed,
as it was in the start, and I can't get it to change anymore.

>
> Also, you've added yourself to the copyright - this means that you're
> pretty much going to get all future email about acerhdf. Do you really
> want that?

For now, that is what I want to the foreseeable future, as long as I
own such a laptop. I can perhaps contribute to the development a bit.

>
> --
> Regards/Gruss,
> Boris.

--
Kind Regards / Ystävällisin terveisin,

Tero Keski-Valkama, MSc(Tech)

+358 (0)46 876 0485

tero.kesk...@neter.fi
http://www.neter.fi

[Tero Keski-Valkama]

2012/9/26 Tero Keski-Valkama <tero.kesk...@neter.fi>:

Now I have confirmed that:
a) In default state fan does not speed up even in temperatures above
90 degrees, and
b) Now, fan provably sped up, two times, at temperature of about 77 degrees.

The configuration now:
# ./acer_ec.pl regs

00 01 02 03 04 05 06 07 | 08 09 0A 0B 0C 0D 0E 0F
__ __ __ __ __ __ __ __ | __ __ __ __ __ __ __ __
00 | 2 0 0 0 2 2 0 1 | 0 9 0 0 0 0 0 0
10 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
20 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
30 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
40 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
50 | 0 0 0 0 0 34 0 0 | 0 0 0 0 0 0 0 0
60 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
70 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
80 | 0 0 0 0 0 0 0 0 | 0 0 0 0 0 0 0 0
90 | 83 65 78 89 79 0 0 0 | 0 65 83 49 48 68 51 49
A0 | 0 0 0 128 193 0 0 95 | 255 0 0 14 100 31 0 0
B0 | 0 0 0 80 78 0 0 0 | 0 9 0 4 0 2 17 17
C0 | 19 0 201 15 63 171 155 48 | 48 42 48 17 201 15 100 31
D0 | 0 0 0 0 25 124 156 35 | 0 0 2 19 0 0 224 64
E0 | 0 0 0 59 16 50 16 47 | 16 0 0 0 0 0 0 0
F0 | 75 16 0 0 3 63 0 0 | 68 0 0 0 0 0 0 0

Somehow the fan speedup has always coincided with "acer_ec.pl regs"
command, which might be caused by:
a) Processor warms up in that command, or
b) Reading EC has some consequences.

The above register dump differs from the default boot-up state by
obviously registers to read, with volatile values, and:
- Register 0xAB from original value 0x08 to 0x0E.
- Register 0xAD from original value 0x17 to 0x1F.
This means that some of these register changes seem to enable
automatic BIOS fan control:
- FAN2 0 -> 1
- FANT 0 -> 1
- FANU 0x7 -> 0xF

I have been trying to do some web searches for these register names to
determine their meaning, but while many people have found them, they
have only made invalid or no documented guesses about their purpose.

[Tero Keski-Valkama]

2012/9/26 Tero Keski-Valkama <tero.kesk...@neter.fi>:
> 2012/9/26 Tero Keski-Valkama <tero.kesk...@neter.fi>:

>
> Now I have confirmed that:
> a) In default state fan does not speed up even in temperatures above
> 90 degrees, and
> b) Now, fan provably sped up, two times, at temperature of about 77 degrees.
>

> Somehow the fan speedup has always coincided with "acer_ec.pl regs"
> command, which might be caused by:
> a) Processor warms up in that command, or
> b) Reading EC has some consequences.
>
> The above register dump differs from the default boot-up state by
> obviously registers to read, with volatile values, and:
> - Register 0xAB from original value 0x08 to 0x0E.
> - Register 0xAD from original value 0x17 to 0x1F.
> This means that some of these register changes seem to enable
> automatic BIOS fan control:
> - FAN2 0 -> 1
> - FANT 0 -> 1
> - FANU 0x7 -> 0xF
>
> I have been trying to do some web searches for these register names to
> determine their meaning, but while many people have found them, they
> have only made invalid or no documented guesses about their purpose.
>
> --
> Kind Regards / Ystävällisin terveisin,
>
> Tero Keski-Valkama, MSc(Tech)
>
> +358 (0)46 876 0485
>
> tero.kesk...@neter.fi
> http://www.neter.fi

The automatic fan speed up has now been confirmed under CPU stress,
without running acer_ec.pl regs, so reading the registry is not the
cause.

It seems that setting the above register values actually changes the
FAN to be BIOS controlled correctly, as opposed to the default values,
which seem to keep the fan at a constant, medium speed.

At the moment it's my best guess that FANU register change does
nothing, but this needs to be confirmed. I'll check that out at some
point. At least playing around with its different values does not seem
to have any effect whatsoever.

After checking that, the patch should probably be changed from just
continuing the default boot up status in AUTO mode, because that seems
not to be truly automatic, and use the value 0x0E instead of 0x08 for
this setting.

However, this means that people not running this module will still be
left with the non-automatic fan mode for these laptops.

[Tero Keski-Valkama]

I dumped a working registry by booting with acpi=off kernel parameter.

<dump>
EC RAM:

00: 02 00 00 00 02 02 00 01 00 09 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 22 00 00 00 00 00 00 00 00 00 fe
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 53 41 4e 59 4f 00 00 00 00 41 53 31 30 44 33 31
a0: 00 00 00 80 c1 00 00 5f ff 10 00 0e 64 17 81 ff
b0: 00 00 00 52 53 00 00 00 00 09 00 05 00 02 11 11
c0: 13 00 c9 0f 3f ab 65 30 30 2a 30 11 c9 0f 64 1f
d0: 00 00 00 00 19 7b 9b 24 00 00 05 0a 00 00 e0 40
e0: 00 00 00 28 10 20 10 1d 10 00 00 00 00 00 00 00
f0: 43 10 00 00 03 3f 00 00 44 00 00 00 00 00 00 00

Not dumping EC IDX RAM.
</dump>

This configuration rewritten to a registry booted with normal ACPI
kernel support actually speeds up the fan automatically in a sane
manner, and it actually puts the fan to max power when the temperature
is very high, as opposed to any other hack I have tried so far.

I still need to find out what exact registry value here causes the
normal automatic fan operation.

At least in this acpi=off configuration, 0xAB := 0x0E, as opposed to
the normal kernel boot up value of 0xAB := 0x08, but of course this is
not the only difference.

[Peter Feuerer]

Hi,

Borislav Petkov writes:

> Adding Peter.

Just wanted to say, that I've got currently very less spare time. I think
I'll be fully available again in about 2 weeks. I'll catch up then.

--
Thanks and kind regards,
--peter;

[Tero Keski-Valkama]

Are there any news about this? I have received several external
queries about this functionality, so there's clearly need for this to
be in the kernel. And the patch does work.

2012/9/29 Peter Feuerer <pe...@piie.net>:

> Hi,
>
> Borislav Petkov writes:
>
>> Adding Peter.
>
>
> Just wanted to say, that I've got currently very less spare time. I think
> I'll be fully available again in about 2 weeks. I'll catch up then.
>
> --
> Thanks and kind regards,
> --peter;



--

Kind Regards / Yst�v�llisin terveisin,

Tero Keski-Valkama, MSc(Tech)

+358 (0)40 706 9762

tero.kesk...@neter.fi
http://www.neter.fi

[Borislav Petkov]

On Thu, Mar 07, 2013 at 11:41:29AM +0200, Tero Keski-Valkama wrote:
> Are there any news about this? I have received several external
> queries about this functionality, so there's clearly need for this to
> be in the kernel. And the patch does work.

Well, this conversation will definitely need a refresh. The thermal code
has been rewritten recently so you probably want to restart your testing
with 3.9-rc1 which contains the latest state and see if it does fix your
issue.

Thanks.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[Tero Keski-Valkama]

2013/3/7 Borislav Petkov <b...@alien8.de>:

> On Thu, Mar 07, 2013 at 11:41:29AM +0200, Tero Keski-Valkama wrote:
>> Are there any news about this? I have received several external
>> queries about this functionality, so there's clearly need for this to
>> be in the kernel. And the patch does work.
>
> Well, this conversation will definitely need a refresh. The thermal code
> has been rewritten recently so you probably want to restart your testing
> with 3.9-rc1 which contains the latest state and see if it does fix your
> issue.
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --

Yes, I will check that issue, but what about the patch? Is it going
into the kernel any time soon?

--
Kind Regards / Yst�v�llisin terveisin,

Tero Keski-Valkama, MSc(Tech)

+358 (0)40 706 9762

tero.kesk...@neter.fi
http://www.neter.fi

[Borislav Petkov]

On Thu, Mar 07, 2013 at 12:50:27PM +0200, Tero Keski-Valkama wrote:
> Yes, I will check that issue, but what about the patch? Is it going
> into the kernel any time soon?

Please regenerate it against the latest kernel 3.9-rc1 and make sure to
test it properly with this kernel and to see whether the interactions
with the new thermal code are ok on your box.

Thanks.

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--