public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
To: Thomas Renninger <trenn-l3A5Bk7waGM@public.gmane.org>
Cc: Janosch Machowinski <scotch-cGBD8117FJM@public.gmane.org>,
	acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
	Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: _CST implementation
Date: Tue, 19 Apr 2005 15:45:18 +0200	[thread overview]
Message-ID: <20050419134518.GL2298@poupinou.org> (raw)
In-Reply-To: <4264F251.5030705-l3A5Bk7waGM@public.gmane.org>

On Tue, Apr 19, 2005 at 01:58:09PM +0200, Thomas Renninger wrote:
> Bruno Ducrot wrote:
> > On Mon, Apr 18, 2005 at 07:25:54PM +0200, Thomas Renninger wrote:
> >>Bruno Ducrot wrote:
> >>>On Fri, Apr 15, 2005 at 10:50:44PM +0200, Janosch Machowinski wrote:
> >>...
> >>>>Oh I almost forgot another question : 
> >>>>About the validation of the C states. At the moment it is tested if the
> >>>>latency of C2 if under 100 and if C3 latency is under 1000 but the
> >>>>ACPI-Spec says that "There is no latency restrictions" so why do you do
> >>>>this ? (My notebook hat a C3 latency of 1001)
> >>>Normally you are right, but unfortunately there are still some strange
> >>>misread of the specification by bios writters in that regard.  Therefore
> >>>if for C3 the latency is 1001 even if given by _CST, we should disable
> >>>it.
> >>>
> >>My spec says (Revision 3.0, September 2, 2004):
> >>The worst-case hardware latency for this state is declared in the FADT
> >>(p. 257).
> >>
> >>And there they say (p. 98):
> >>The worst-case hardware latency, in microseconds, to enter and
> >>exit a C2 state. A value > 100 indicates the system does not
> >>support a C2 state.
> >>The worst-case hardware latency, in microseconds, to enter and
> >>exit a C3 state. A value > 1000 indicates the system does not
> >>support a C3 state.
> >>
> > 
> > For P_LVL2_LAT and P_LVL3_LAT defined in the FADT only.  There are no
> > such restriction if _CST exist (see 8.1.5 and 8.4.2).
> > If power states are defined via _CST, then all of them are valid.
> > 
> 
> Thanks, only knew of the fadt restrictions.
> This should fix it?
> Only compile tested.

There is this problem:
> >>>Normally you are right, but unfortunately there are still some strange
> >>>misread of the specification by bios writters in that regard.  Therefore
> >>>if for C3 the latency is 1001 even if given by _CST, we should disable
> >>>it.

IOW, from spec we should not invalidate, but from "common practice" by
bios writters, we should invalidate.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728

  parent reply	other threads:[~2005-04-19 13:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-15 20:50 _CST implementation Janosch Machowinski
2005-04-18 12:07 ` Bruno Ducrot
     [not found]   ` <20050418120744.GG2298-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2005-04-18 12:23     ` Janosch Machowinski
2005-04-18 14:21       ` Bruno Ducrot
2005-04-18 17:25     ` Thomas Renninger
     [not found]       ` <4263EDA2.4030106-l3A5Bk7waGM@public.gmane.org>
2005-04-18 17:52         ` Janosch Machowinski
2005-04-19  9:22         ` Bruno Ducrot
     [not found]           ` <20050419092251.GK2298-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2005-04-19 11:58             ` Thomas Renninger
     [not found]               ` <4264F251.5030705-l3A5Bk7waGM@public.gmane.org>
2005-04-19 13:45                 ` Bruno Ducrot [this message]
     [not found]                   ` <20050419134518.GL2298-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2005-04-19 20:05                     ` Stefan Seyfried
     [not found]                       ` <20050419200505.GE19499-l0tNAEGuAhhzZ8+rp42Dbp9+tswZ0GTaehPwdyo5hKaELgA04lAiVw@public.gmane.org>
2005-04-19 20:11                         ` Rich Townsend
     [not found]                           ` <42656601.3060304-OBnUx95tOyn10jlvfTC4gA@public.gmane.org>
2005-04-20  9:45                             ` Bruno Ducrot
     [not found]                               ` <20050420094556.GN2298-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2005-04-22 13:00                                 ` Thomas Renninger
     [not found]                                   ` <4268F572.4090707-l3A5Bk7waGM@public.gmane.org>
2005-04-22 17:13                                     ` Janosch Machowinski

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=20050419134518.GL2298@poupinou.org \
    --to=ducrot-kk6yzipjem5g9huczpvpmw@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=scotch-cGBD8117FJM@public.gmane.org \
    --cc=trenn-l3A5Bk7waGM@public.gmane.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