From: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
To: Corentin Chary <corentin.chary@gmail.com>
Cc: Grigori Goronzy <greg@chown.ath.cx>,
linux-acpi@vger.kernel.org, Len Brown <len.brown@intel.com>
Subject: Re: [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE)
Date: Mon, 25 May 2009 12:51:20 +0100 [thread overview]
Message-ID: <4A1A8638.2060105@tuffmail.co.uk> (raw)
In-Reply-To: <71cd59b00905250419u4256446endef52672b7d5ab77@mail.gmail.com>
Corentin Chary wrote:
> On Mon, May 25, 2009 at 12:07 PM, Alan Jenkins
> <alan-jenkins@tuffmail.co.uk> wrote:
>
>> Corentin Chary wrote:
>>
>>> On Mon, May 25, 2009 at 11:43 AM, Alan Jenkins
>>> <alan-jenkins@tuffmail.co.uk> wrote:
>>>
>>>
>>>> Corentin Chary wrote:
>>>>
>>>>
>>>>> On Sunday 24 May 2009 19:29:37 Alan Jenkins wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Corentin Chary wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Sun, May 24, 2009 at 11:28 AM, Alan Jenkins
>>>>>>>
>>>>>>> <sourcejedi.lkml@googlemail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 5/16/09, Len Brown <lenb@kernel.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> From: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>>
>>>>>>>>> The older eeepc-acpi driver allowed to control the SHE performance
>>>>>>>>> preset through a ACPI function for just this purpose. SHE underclocks
>>>>>>>>> and undervolts the FSB and undervolts the CPU (at preset 2,
>>>>>>>>> "powersave"), or slightly overclocks the CPU (at preset 0,
>>>>>>>>> "performance"). Preset 1 is the default setting with default clocks and
>>>>>>>>> voltage.
>>>>>>>>>
>>>>>>>>> The new eeepc-laptop driver doesn't support it anymore.
>>>>>>>>> The attached patch adds support for it to eeepc-laptop. It's very
>>>>>>>>> straight-forward and almost trivial.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Grigori Goronzy <greg@chown.ath.cx>
>>>>>>>>> Signed-off-by: Corentin Chary <corentincj@iksaif.net>
>>>>>>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Hi, out of curiosity I tried this on my EeePC 701. I upgraded the
>>>>>>>> BIOS to the latest version available a few months ago.
>>>>>>>>
>>>>>>>> I find that the file is present and can successfully be read from.
>>>>>>>> The file returns the value "513". If I write "1" to it, nothing
>>>>>>>> happens. If I write "0" to it, the speakers start hissing and the
>>>>>>>> file then returns the value "512". Writing "1" again gets it back to
>>>>>>>> normal. There is no apparent effect on performance.
>>>>>>>>
>>>>>>>> This is stupid, because we _do_ appear to check the BIOS supported
>>>>>>>> features bitmask, but that's Asus firmware for you. Can you please
>>>>>>>> add an extra test, so this file only allows reads or writes if the
>>>>>>>> current value is 0 or 1? If you're quick you might slip it into -rc8
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> Hi, Can you try this patch ? It seems to works for me.
>>>>>
>>>>>
>>>>>
>>>> Thanks, it does make the interface less confusing. The behaviour (no
>>>> performance change, hissing speakers) is the same.
>>>>
>>>>
>>> It works on mine (original bios). But I don't know how to see if there
>>> is a performance change.
>>> Is there a quick cpu bench ?
>>>
>>>
>> I used:
>>
>> time for {1..10000}; do echo -n; done
>>
>> It's a bit bogus - I expect it would show if my 630Mhz processor jumped
>> to 900Mhz, but smaller changes might be lost in noise.
>>
>> <http://pavelmachek.livejournal.com/77425.html> suggests "time factor
>> $[65863223*65863159]", which should be better.
>>
>> I think it's also significant that the current (630Mhz) setting is "1".
>> I would expect "0" to be slower - but in the original 701 BIOS, 630Mhz
>> is the slower of the two speeds, right?
>>
>
> 1 - time factor: ~ 1.574s - default, seems to be 630Mhz
> 0 - time factor: ~ 1.01s - seems to be 900
>
>
How illogical :-). Oh - I should have read the commit message, this is
the expected order (and proper SHE just has the extra state: 2 /
"performance").
Perhaps we should DMI-blacklist 701s with newer BIOS versions, so we
only provide the performance control when it is available from the BIOS
setup screen. The specific version is well-documented e.g. on
forum.eeeuser.com.
Thanks for your time
Alan
next prev parent reply other threads:[~2009-05-25 11:50 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-16 6:01 ACPI & driver patches for 2.6.30-rc5 Len Brown
2009-05-16 6:01 ` [PATCH 01/19] ACPI video: dmi check for broken _BQC on Acer Aspire 5720 Len Brown
2009-05-16 6:01 ` [PATCH 02/19] ACPICA: use acpi.* modparam namespace Len Brown
2009-05-16 6:02 ` [PATCH 03/19] ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness Len Brown
2009-05-16 6:02 ` [PATCH 04/19] ACPI: power: update error message Len Brown
2009-05-16 6:02 ` [PATCH 05/19] ACPI: suspend: don't let device _PS3 failure prevent suspend Len Brown
2009-05-16 6:02 ` [PATCH 06/19] eeepc-laptop: fix wlan rfkill state change during init Len Brown
2009-05-16 6:02 ` [PATCH 07/19] eeepc-laptop: report brightness control events via the input layer Len Brown
2009-05-16 6:02 ` [PATCH 08/19] eeepc-laptop: Work around rfkill firmware bug Len Brown
2009-05-16 6:02 ` [PATCH 09/19] eeepc-laptop: support for super hybrid engine (SHE) Len Brown
2009-05-24 9:28 ` Alan Jenkins
2009-05-24 17:23 ` Corentin Chary
[not found] ` <4A198401.3040003@tuffmail.co.uk>
2009-05-25 8:12 ` Corentin Chary
2009-05-25 9:43 ` Alan Jenkins
2009-05-25 9:59 ` Corentin Chary
2009-05-25 10:07 ` Alan Jenkins
2009-05-25 11:19 ` Corentin Chary
2009-05-25 11:51 ` Alan Jenkins [this message]
2009-05-26 10:12 ` Corentin Chary
2009-05-26 10:15 ` Alan Jenkins
2009-05-26 17:29 ` Francesco Lattanzio
2009-05-26 17:43 ` Alan Jenkins
2009-05-26 18:05 ` Corentin Chary
2009-05-24 20:24 ` Corentin Chary
2009-05-16 6:02 ` [PATCH 10/19] asus-laptop: fix input keycode Len Brown
2009-05-16 6:02 ` [PATCH 11/19] eeepc-laptop: unregister_rfkill_notifier on failure Len Brown
2009-05-16 6:02 ` [PATCH 12/19] thermal: fix off-by-1 error in trip point trigger condition Len Brown
2009-05-16 6:02 ` [PATCH 13/19] ACPI: resume: re-enable SCI-enable workaround Len Brown
2009-05-16 6:02 ` [PATCH 14/19] ACPI: suspend: restore BM_RLD on resume Len Brown
2009-05-16 6:02 ` [PATCH 15/19] ACPI, i915: build fix Len Brown
2009-05-18 2:49 ` yakui_zhao
2009-05-16 6:02 ` [PATCH 16/19] ACPI processor: introduce module parameter processor.ignore_tpc Len Brown
2009-05-16 6:02 ` [PATCH 17/19] ACPI processor: reset the throttling state once it's invalid Len Brown
2009-05-16 6:02 ` [PATCH 18/19] ACPI: idle: fix init-time TSC check regression Len Brown
2009-05-16 6:02 ` [PATCH 19/19] ACPI: Idle C-states disabled by max_cstate should not disable the TSC Len Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A1A8638.2060105@tuffmail.co.uk \
--to=alan-jenkins@tuffmail.co.uk \
--cc=corentin.chary@gmail.com \
--cc=greg@chown.ath.cx \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox