Date: Tue, 28 Jun 2011 17:39:45 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-acpi@freebsd.org, Vitaly Magerya <vmagerya@gmail.com> Subject: Re: (Missing) power states of an Atom N455-based netbook Message-ID: <201106281739.47588.jkim@FreeBSD.org> In-Reply-To: <4E0A4534.30904@FreeBSD.org> References: <BANLkTim%2B1UwquMJ32WP8wZBGkYxPv78MLA@mail.gmail.com> <201106281713.20698.jkim@FreeBSD.org> <4E0A4534.30904@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 28 June 2011 05:18 pm, Andriy Gapon wrote: > on 29/06/2011 00:13 Jung-uk Kim said the following: > > On Tuesday 28 June 2011 03:37 pm, Vitaly Magerya wrote: > >>> I think that part (but not all) of the differences between > >>> FreeBSD and Linux can be explained by the fact that FreeBSD > >>> currently doesn't advertise itself as featuring > >>> ACPI_CAP_SMP_C1_NATIVE and ACPI_CAP_SMP_C3_NATIVE. I am not > >>> sure what it would take to actually support these features. I > >>> think that Linux does support (or at least advertise support) > >>> for these features. > >> > >> Is there some simple way of sending fake advertisement? Or will > >> that lead to disaster? > > > > Actually, ACPI_CAP_SMP_C1_NATIVE is kinda supported but without > > hints from ACPI _CST FFH. It sits in machdep.c as > > cpu_idle_mwait(). So, I think you can advertise them. The > > easist way is this (not tested): > > But don't we currently ignore FFH-type C state definitions? Correct. > I am not sure that mwait that we use (its parameters) would be the > same as the system would expect us to use unless we actually parse > FFH data. Even for C1 sate. It is unfortunate but you're correct. We don't have correct support code yet. > Also I am not sure if that would give much gain/difference. Just for the sake of testing your theory, nothing more, nothing less. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106281739.47588.jkim>