linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anssi Hannula <anssi.hannula@iki.fi>
To: linux-acpi@vger.kernel.org
Subject: Re: ACPI _PPC issue with bios_limit
Date: Wed, 21 Dec 2011 12:41:22 +0200	[thread overview]
Message-ID: <4EF1B7D2.7000206@iki.fi> (raw)
In-Reply-To: <4EEB4F1E.3070908@iki.fi>

On 16.12.2011 16:01, Anssi Hannula wrote:
> Hi!
> 
> On my laptop, processor _PPC is evaluated as 1 and therefore the
> processor never goes to the highest frequency (1333MHz vs 1666 MHz).
> 
> The system is HP Mini 5102 and processor Atom N450.
> 
> ACPI tables are at http://zarb.org/~anssi/hpmini5102/
> 
> This only started happening since 2.6.34 when 3b1da4c5d1 ("ACPI:
> processor: remove early _PDC optin quirks") was applied and thus the
> _PDC is now evaluated early.
> 
> This causes extra tables to be loaded dynamically on boot:
[...]
> Of these, the first two (SSDT4, SSDT5) seem more interesting, and SSDT4
> contains "Name (_PPC, 0x00)".
> 
> However, I don't know how to debug this further, so I'm asking for
> assistance.
> 
> Boot dmesg with current linus git tree is attached.
> This issue doesn't happen on win7 included with the laptop.

Looking at DSDT, it looks like EC0 method RPPC is the one setting _PPC to 1.

RPPC seems to do
  _PPC++ when OTSI flag is set and OTLL is 0x00
  _PPC-- when OTSI flag is set and OTLL is 0x02
and then it clears the OTSI flag.

OTLL is initialized to 0x00 and OTSI is initialized to 0x01.

RPPC seems to be called from EC0's _REG->ECRI->PRIT and from _Q04 (and
from _WAK->HWAK, though my guess is that that is not relevant).

Since on EC0 registration time OTLL=0 and OTSI=1, this causes RPPC to
bump _PPC to 1.

_Q04, if triggered, would set OTSI=1 and OTLL to the value from OCPS
(from EC's memory region).

So it seems to me like either RPPC is somehow not supposed to set _PPC
when EC0 region is registered, or the EC is supposed to send a '04'
event with OCPS=2 which would cause RPPC to reset _PPC to 0.

If it is the latter, I guess the EC is waiting for some action from the
kernel which never happens. During normal system operation OCPS seems to
have 0x01 (which means no _PPC change), so the issue is not simply a
missing _Q04 call.

Again, any hints or debugging suggestions welcome :)

-- 
Anssi Hannula

      reply	other threads:[~2011-12-21 10:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-16 14:01 ACPI _PPC issue with bios_limit Anssi Hannula
2011-12-21 10:41 ` Anssi Hannula [this message]

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=4EF1B7D2.7000206@iki.fi \
    --to=anssi.hannula@iki.fi \
    --cc=linux-acpi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).