public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
To: Janosch Machowinski <scotch-cGBD8117FJM@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: _CST Patches
Date: Mon, 18 Apr 2005 13:47:57 +0200	[thread overview]
Message-ID: <20050418114757.GF2298@poupinou.org> (raw)
In-Reply-To: <1113665142.7964.13.camel@scotchmobil>

On Sat, Apr 16, 2005 at 05:25:41PM +0200, Janosch Machowinski wrote:
> Hey
> it's the guy with the stupid questions again ;-) 
> And now I got a few answers I think... 
> ACPI specification says, that every processor has a C1
> state, and on page 262 is an example of an _CST package,
> where the first given C state is C2. So I would suggest following patch
> to the processor_idle.c Line: 611
> 
> cx.type = obj->integer.value;
> 
> +//Test if the first entry is a C1 state, if not we fake one
> +if ((cx.type != ACPI_STATE_C1) && i == 1) {
> +		ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Faking C1 State"));
> +		struct acpi_processor_cx c1_fake;
> +		memset(&c1_fake, 0, sizeof(c1_fake));
> +
> +		c1_fake.address = 0;
> +		c1_fake.type = ACPI_STATE_C1;
> +		c1_fake.latency = 1; //How long needs a HLT instruction to execute ?
> +		c1_fake.power = 0; //We don't know anything about the power
> consumption so we set it to 0
> +		//We copy our fake C1 state over to the power states
> +		(pr->power.count)++;
> +		memcpy(&(pr->power.states[pr->power.count]), &c1_fake,
> sizeof(c1_fake));
> +		//Finally we avoid to have morepower 				+		//states than
> ACPI_PROCESSOR_MAX_POWER
> +		if(count == ACPI_PROCESSOR_MAX_POWER)
> +		count--;
> +		
> +		//c1_fake should be freed automaticaly
> +
> +		}
> +
> 
> 		if ((cx.type != ACPI_STATE_C1) &&
> 
> This patch fakes an C1 state if the given states by the _CST object
> start with anything else than C1 (like on my M6NE here it start's with
> C2)

It should not be needed.  I've taken care that it work by testing
in almost all cases by overriding the DSDT when I wrote this part to
handle properly almost all cases (I forgot the case when C1 and C3, but
no C2 though, that why I wrote 'almost').

Normally, we register a C1 state no matter what before we check
the content of _CST, then we just skip if a C1 type is found.

If your patch is needed, then the patch I send some times ago have not been
fully integrated in the original form, or maybe the wrong one was considered
(the first was buggy in that regard, but the second was OK).

> By looking throug the code I also discovered some errors :
> on line 492 and 539 
> for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
> memset(pr->power.states, 0, sizeof(struct acpi_processor_cx))
> 
> my patch also replaces these lines by 
> for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
> memset(&(pr->power.states[i]), 0, sizeof(struct acpi_processor_cx))

I would prefer
memset(pr->power.states, 0, ACPI_PROCESSOR_MAX_POWER * sizeof(struct acpi_processor_cx));
(without the loop)

> 
> Greets
> 	Janosch Machowinski
> 
> P.S.: Note the attached file is only a diff to the original
> processor_idle.c

Please post unified patch (diff with option '-u').


-- 
Bruno Ducrot

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


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

  reply	other threads:[~2005-04-18 11:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-16 15:25 _CST Patches Janosch Machowinski
2005-04-18 11:47 ` Bruno Ducrot [this message]
     [not found]   ` <20050418114757.GF2298-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2005-04-18 12:16     ` Janosch Machowinski
2005-04-18 14:26       ` Bruno Ducrot

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=20050418114757.GF2298@poupinou.org \
    --to=ducrot-kk6yzipjem5g9huczpvpmw@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=scotch-cGBD8117FJM@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