From: Len Brown <len.brown@intel.com>
To: "Rafał Bilski" <rafalbilski@interia.pl>
Cc: cpufreq@lists.linux.org.uk
Subject: Re: [PATCH] Longhaul - Add ignore_latency option
Date: Thu, 24 Aug 2006 15:54:11 -0400 [thread overview]
Message-ID: <200608241554.11782.len.brown@intel.com> (raw)
In-Reply-To: <44EDDF56.2060807@interia.pl>
On Thursday 24 August 2006 13:18, you wrote:
> >> Some laptops with VIA C3 processor, CLE266 chipset and
> >> AMI BIOS have incorrect latency values in FADT table. These
> >> laptops seems to be C3 capable, but latency values are to
> >> big: 101 for C2 and 1017 for C3. This option will allow
> >> user to skip C3 latency test but not C3 address test. AMI
> >> BIOS is setting C3 address to correct value in DSDT table.
> >
> > This looks very fishy.
>
> So why P_BLK address is valid and have proper lenght?
One possible scenario is that the same BIOS source runs on
multiple hardware steppings. If a broken stepping is found,
the BIOS writer knows that setting the latency above the
legal threshold is sufficient to disable the C-state in
all known ACPI-enabled operating systems, per below.
> > C2 latency above 100usec and C3 latency above 1000 usec
> > are the official way for the BIOS to tell the OS to NOT USE
> > those C-states. Under no conditions should Linux second
> > guess those explicit instructions -- the BIOS may have put
> > those values there because you get silent data corruption
> > on that particular stepping of the processor or chipset
> > if they are enabled.
> >
>
> It is disabled by default.
> It is only needed for some laptops.
> As far I know there is no data corruption. Chipset and processor
> are exacly the same as on Epia M10000 so I don't expect any.
>
> Why force user to recompilation of distro kernel?
Why should a distro support this if the BIOS vendor disabled it?
Is the fact that you have not noticed data corruption a
sufficient test such that they can suport this?
> > But the real question is why the longhaul driver is checking
> > for C2 and C3 support in the first place -- as they are not
> > directly related to the availability of P-states.
>
> Because Longhaul isn't using P-states.
I guess I don't understand what longhaul.c is doing.
Why is it using ACPI's C2 and C3 register addresses in order
to do frequency/voltage scaling?
In the case there those addresses have been deemed invalid for
the purpose of ACPI C-states, why are they still valid for longhaul?
-Len
next prev parent reply other threads:[~2006-08-24 19:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-13 7:16 [PATCH] Longhaul - Add ignore_latency option Rafał Bilski
2006-08-24 3:22 ` Len Brown
2006-08-24 17:18 ` Rafał Bilski
2006-08-24 19:54 ` Len Brown [this message]
2006-08-24 21:09 ` Rafał Bilski
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=200608241554.11782.len.brown@intel.com \
--to=len.brown@intel.com \
--cc=cpufreq@lists.linux.org.uk \
--cc=lenb@kernel.org \
--cc=rafalbilski@interia.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.