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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
