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

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]


> > 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).
> 
Your first patch has been modified, and now my patch is needed. 
In your first implementation you did an (pr->power)++ before the loop
that started the polling of the _CST object. At the moment all C-States
are deleted (see the memset) and generated from scratch. Your idea
sounds faster to me !


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

I agree, looks faster to me. 

A new patch is attached

  Janosch

[-- Attachment #2: _CST_fakeC1.patch --]
[-- Type: text/x-patch, Size: 2081 bytes --]

--- processor_idle.original	2005-04-16 17:13:44.000000000 +0200
+++ processor_idle.c	2005-04-18 14:13:52.000000000 +0200
@@ -479,8 +479,6 @@
 
 static int acpi_processor_get_power_info_fadt (struct acpi_processor *pr)
 {
-	int i;
-
 	ACPI_FUNCTION_TRACE("acpi_processor_get_power_info_fadt");
 
 	if (!pr)
@@ -489,8 +487,7 @@
 	if (!pr->pblk)
 		return_VALUE(-ENODEV);
 
-	for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
-		memset(pr->power.states, 0, sizeof(struct acpi_processor_cx));
+	memset(pr->power.states, 0, ACPI_PROCESSOR_MAX_POWER * sizeof(struct acpi_processor_cx));
 
 	/* if info is obtained from pblk/fadt, type equals state */
 	pr->power.states[ACPI_STATE_C1].type = ACPI_STATE_C1;
@@ -536,8 +533,8 @@
 		return_VALUE(-ENODEV);
 
 	pr->power.count = 0;
-	for (i = 0; i < ACPI_PROCESSOR_MAX_POWER; i++)
-		memset(pr->power.states, 0, sizeof(struct acpi_processor_cx));
+
+	memset(pr->power.states, 0, ACPI_PROCESSOR_MAX_POWER * sizeof(struct acpi_processor_cx));
 
 	status = acpi_evaluate_object(pr->handle, "_CST", NULL, &buffer);
 	if (ACPI_FAILURE(status)) {
@@ -609,6 +606,27 @@
 
 		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 = 0; //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 more power 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) &&
 		    (reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO))
 			continue;

  parent reply	other threads:[~2005-04-18 12:16 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
     [not found]   ` <20050418114757.GF2298-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2005-04-18 12:16     ` Janosch Machowinski [this message]
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=1113826585.8500.12.camel@scotchmobil \
    --to=scotch-cgbd8117fjm@public.gmane.org \
    --cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@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