(Missing) power states of an Atom N455-based netbook

[Vitaly Magerya]

Andriy Gapon <avg at freebsd.org> wrote:
> Here's what Intel docs say:
>
> The processor implements two software interfaces for requesting low power
> states, MWAIT instruction extensions with sub-state hints and P_LVLx reads to
> the ACPI P_BLK register block mapped in the processor's I/O address space. The
> P_LVLx I/O reads are converted to equivalent MWAIT C-state requests inside the
> processor and do not directly result in I/O reads on the processor FSB.
>
> My interpretation is that both mechanism should work equally.

I see.

>> Just tried this. Nothing seems fried; the visible effect is that
>> now when I plug the power cord in backlight brightness turns all
>> the way up, and then back down the I turn it off. No changes in
>> SNVS or GNVS variables aside from the usual ones.
>
> At least some improvement (or just a difference)...

Since VDRV is always 0, you can't really say if it's a coincidence
or the intended behavior.

> Not sure how to proceed here further.  Apparently we do something differently
> from Linux (and presumably Windows) here, but it's quite hard to tell what. The
> problem is that SNVS/GNVS (in particular C1ON) seem to be controlled by some
> firmware/hardware and that's a black box.
> And I am still puzzled about which exactly event triggers change in C1ON value
> on FreeBSD...

I got the dumps for Linux (it appears that you can't just read
/dev/mem on there, you need to mmap it). The summary of differences
between FreeBSD and Linux right after the boot:

    DB00: 01 -> 00
    P80D: 06:08:00:00 -> 06:08:4C:00
    PCP0: 1D -> BF
    PCP1: 1D -> BF
    BRTL: 00 -> 1E
    VDRV: 00 -> 01

(Note that C1ON is 0 just as with FreeBSD, and yet powertop does
report C2 and C4).

Then, after about 4 minutes of uptime, C1ON changes to 1 (and
powertop still reports the same states).

> Do you have powerd enabled?  Can you check if anything changes
> with it disabled (just for the sake of testing).

I do; nothing changes if I don't.

> P.S. Just an idea, maybe the following script could be of some help if you
> have dtrace support in your kernel:
> $ dtrace -n 'fbt::AcpiEvaluateObject:entry { printf("%p->%s\n", args[0],
> (string)args[1]); }'
> I would like to get entries, if any, around the time that the C-states
> become available.

I'll try to compile the kernel with dtrace and post the results back.