From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marco Aurelio da Costa <costa@gamic.com>
Cc: Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] ACPI: Ignore invalid _PSS entries, but use valid ones
Date: Fri, 4 May 2012 10:39:48 -0400 [thread overview]
Message-ID: <20120504143948.GD1049@phenom.dumpdata.com> (raw)
In-Reply-To: <CAEe-dwj4JP-U0tc3wpmHvzv=aQU5zy3cG_E9FrriPw_sdfg2bg@mail.gmail.com>
On Fri, May 04, 2012 at 11:13:22AM -0300, Marco Aurelio da Costa wrote:
> Hi, Konrad.
>
> On Fri, May 4, 2012 at 10:52 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, May 04, 2012 at 10:46:01AM -0300, Marco Aurelio da Costa wrote:
> >> From: Marco Aurelio da Costa <costa@gamic.com>
> >> Signed-off-by: Marco Aurelio da Costa <costa@gamic.com>
> >>
> >> The EliteBook 8560W has non-initialized entries in its _PSS ACPI
> >> table. Instead of bailing out when the first non-initialized entry is
> >> found, ignore it and use only the valid entries. Only bail out if there
> >> is no valid entry at all.
> >
> > Is that safe? Meaning re-use the other CPU's _PSS states? Perhaps the
> > warning at the end should say: "Trying to compensate by using the
> > other CPU's PSS state).
>
> This case in question was created by HP removing the overclock options
> and leaving the entries in a invalid/empty situation. In this specific
> case, it is safe.
> I am not changing the table in any way, I just ignore the
> non-initialized entries. The code only use listed states. If they are
> CPU bound, the code doesn't assume anything.
>
> >
> >>
> >> ---
> >> --- linux-3.3.3/drivers/acpi/processor_perflib.c.orig 2012-04-24
> >> 22:18:23.288041268 +0200
> >> +++ linux-3.3.3/drivers/acpi/processor_perflib.c 2012-04-24
> >> 22:19:25.912042603 +0200
> >> @@ -311,6 +311,7 @@ static int acpi_processor_get_performanc
> >> struct acpi_buffer state = { 0, NULL };
> >> union acpi_object *pss = NULL;
> >> int i;
> >> + int last_invalid = -1;
> >>
> >>
> >> status = acpi_evaluate_object(pr->handle, "_PSS", NULL, &buffer);
> >> @@ -374,12 +375,30 @@ static int acpi_processor_get_performanc
> >> printk(KERN_ERR FW_BUG PREFIX
> >> "Invalid BIOS _PSS frequency: 0x%llx MHz\n",
> >> px->core_frequency);
> >> - result = -EFAULT;
> >> - kfree(pr->performance->states);
> >> - goto end;
> >> + if (-1 == last_invalid)
> >
> > Swap it around or just do it this way:
>
> Ok.
>
> >
> > if (last_invalid < 0)
> >
> >> + last_invalid = i;
> >> + } else {
> >> + if (last_invalid != -1) {
> >
> > if (last_invalid >= 0)
> >
> >> + /*
> >> + * Copy this valid entry over last_invalid entry
> >> + */
> >> + memcpy(&(pr->performance->states[last_invalid]),
> >> + px, sizeof(struct acpi_processor_px));
> >> + ++last_invalid;
> >> + }
> >> }
> >> }
> >>
> >> + if (0 == last_invalid) {
> >
> > So if _PSS that is missing is at CPU2, this own't print it.
>
> I don't get what do you mean by CPU. last_invalid is just the last
> invalid _PSS entry item. Nothing to do with the CPU.
The loop is based on CPU, oh wait. Not this loop. You are right - ignore
that comment please.
>
> >
> > I think you want 'if (last_invalid >= 0)'
>
> No, it is correct. If the last invalid found item is the item 0, than
> it means that no valid item was found.
I somehow thought that the 'i' was for the for_each_possible(cpu), but
that is another funtion.
>
> >
> >> + printk(KERN_ERR FW_BUG PREFIX
> >> + "No valid BIOS _PSS frequency found\n");
> >
> > And you should mention which CPU has it busted - as there are
> > some that are working.
>
> No CPU here, just the _PSS item.
Add pr->id - that will tell us which of the _PSS entries is defective.
>
> >
> >
> >> + result = -EFAULT;
> >> + kfree(pr->performance->states);
> >> + }
> >> +
> >> + if (last_invalid > 0)
> >
> > Don't you want 'last_invalid >= 0' ?
>
> No. It is correct. If the last invalid item is greater than 0, then
> there was at least 1 valid _PSS entry. And the count of valid entries
> is the same as the last_invalid variable.
>
> >
> >> + pr->performance->state_count = last_invalid;
> >> +
> >> end:
> >> kfree(buffer.pointer);
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> I will send the corrected patch next.
>
>
> --
> Marco Costa
> Customer Support
> --
> GAMIC mbH
> Roermonder Strasse, 151
> 52072 Aachen
> Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marco Aurelio da Costa <costa@gamic.com>
Cc: Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] ACPI: Ignore invalid _PSS entries, but use valid ones
Date: Fri, 4 May 2012 10:39:48 -0400 [thread overview]
Message-ID: <20120504143948.GD1049@phenom.dumpdata.com> (raw)
In-Reply-To: <CAEe-dwj4JP-U0tc3wpmHvzv=aQU5zy3cG_E9FrriPw_sdfg2bg@mail.gmail.com>
On Fri, May 04, 2012 at 11:13:22AM -0300, Marco Aurelio da Costa wrote:
> Hi, Konrad.
>
> On Fri, May 4, 2012 at 10:52 AM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> > On Fri, May 04, 2012 at 10:46:01AM -0300, Marco Aurelio da Costa wrote:
> >> From: Marco Aurelio da Costa <costa@gamic.com>
> >> Signed-off-by: Marco Aurelio da Costa <costa@gamic.com>
> >>
> >> The EliteBook 8560W has non-initialized entries in its _PSS ACPI
> >> table. Instead of bailing out when the first non-initialized entry is
> >> found, ignore it and use only the valid entries. Only bail out if there
> >> is no valid entry at all.
> >
> > Is that safe? Meaning re-use the other CPU's _PSS states? Perhaps the
> > warning at the end should say: "Trying to compensate by using the
> > other CPU's PSS state).
>
> This case in question was created by HP removing the overclock options
> and leaving the entries in a invalid/empty situation. In this specific
> case, it is safe.
> I am not changing the table in any way, I just ignore the
> non-initialized entries. The code only use listed states. If they are
> CPU bound, the code doesn't assume anything.
>
> >
> >>
> >> ---
> >> --- linux-3.3.3/drivers/acpi/processor_perflib.c.orig 2012-04-24
> >> 22:18:23.288041268 +0200
> >> +++ linux-3.3.3/drivers/acpi/processor_perflib.c 2012-04-24
> >> 22:19:25.912042603 +0200
> >> @@ -311,6 +311,7 @@ static int acpi_processor_get_performanc
> >> struct acpi_buffer state = { 0, NULL };
> >> union acpi_object *pss = NULL;
> >> int i;
> >> + int last_invalid = -1;
> >>
> >>
> >> status = acpi_evaluate_object(pr->handle, "_PSS", NULL, &buffer);
> >> @@ -374,12 +375,30 @@ static int acpi_processor_get_performanc
> >> printk(KERN_ERR FW_BUG PREFIX
> >> "Invalid BIOS _PSS frequency: 0x%llx MHz\n",
> >> px->core_frequency);
> >> - result = -EFAULT;
> >> - kfree(pr->performance->states);
> >> - goto end;
> >> + if (-1 == last_invalid)
> >
> > Swap it around or just do it this way:
>
> Ok.
>
> >
> > if (last_invalid < 0)
> >
> >> + last_invalid = i;
> >> + } else {
> >> + if (last_invalid != -1) {
> >
> > if (last_invalid >= 0)
> >
> >> + /*
> >> + * Copy this valid entry over last_invalid entry
> >> + */
> >> + memcpy(&(pr->performance->states[last_invalid]),
> >> + px, sizeof(struct acpi_processor_px));
> >> + ++last_invalid;
> >> + }
> >> }
> >> }
> >>
> >> + if (0 == last_invalid) {
> >
> > So if _PSS that is missing is at CPU2, this own't print it.
>
> I don't get what do you mean by CPU. last_invalid is just the last
> invalid _PSS entry item. Nothing to do with the CPU.
The loop is based on CPU, oh wait. Not this loop. You are right - ignore
that comment please.
>
> >
> > I think you want 'if (last_invalid >= 0)'
>
> No, it is correct. If the last invalid found item is the item 0, than
> it means that no valid item was found.
I somehow thought that the 'i' was for the for_each_possible(cpu), but
that is another funtion.
>
> >
> >> + printk(KERN_ERR FW_BUG PREFIX
> >> + "No valid BIOS _PSS frequency found\n");
> >
> > And you should mention which CPU has it busted - as there are
> > some that are working.
>
> No CPU here, just the _PSS item.
Add pr->id - that will tell us which of the _PSS entries is defective.
>
> >
> >
> >> + result = -EFAULT;
> >> + kfree(pr->performance->states);
> >> + }
> >> +
> >> + if (last_invalid > 0)
> >
> > Don't you want 'last_invalid >= 0' ?
>
> No. It is correct. If the last invalid item is greater than 0, then
> there was at least 1 valid _PSS entry. And the count of valid entries
> is the same as the last_invalid variable.
>
> >
> >> + pr->performance->state_count = last_invalid;
> >> +
> >> end:
> >> kfree(buffer.pointer);
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> I will send the corrected patch next.
>
>
> --
> Marco Costa
> Customer Support
> --
> GAMIC mbH
> Roermonder Strasse, 151
> 52072 Aachen
> Germany
next prev parent reply other threads:[~2012-05-04 14:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 13:46 [RFC][PATCH] ACPI: Ignore invalid _PSS entries, but use valid ones Marco Aurelio da Costa
2012-05-04 13:52 ` Konrad Rzeszutek Wilk
2012-05-04 14:13 ` Marco Aurelio da Costa
2012-05-04 14:13 ` Marco Aurelio da Costa
2012-05-04 14:39 ` Konrad Rzeszutek Wilk [this message]
2012-05-04 14:39 ` Konrad Rzeszutek Wilk
[not found] ` <CAEe-dwg5pG2aDHopeHA2yiACUjS3cba5Vm1GyOaM4y=gpvpmMQ@mail.gmail.com>
2012-05-04 15:25 ` [RFC][PATCH v2] " Marco Aurelio da Costa
2012-05-04 16:11 ` Konrad Rzeszutek Wilk
2012-05-04 16:21 ` Marco Aurelio da Costa
2012-05-04 16:21 ` Marco Aurelio da Costa
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=20120504143948.GD1049@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=costa@gamic.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@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 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.