[coreboot] AMD S3: Experiences with ACPI 2.0 method _BFS (Back From Sleep)
paulepanter at users.sourceforge.net
Tue Feb 19 00:37:26 CET 2013
Am Montag, den 18.02.2013, 12:21 -0700 schrieb Marc Jones:
> On Mon, Feb 18, 2013 at 9:24 AM, Paul Menzel wrote:
> > Am Montag, den 18.02.2013, 17:09 +0100 schrieb Paul Menzel:
> >> searching for ACPI in the output of `dmesg` I noticed the following
> >> message.
> >> $ uname -v
> >> #1 SMP Debian 3.2.35-2
> >> $ dmesg | grep -i acpi
> >> [ 0.154063] ACPI: BIOS offers _BFS
> >> [ 0.154067] ACPI: If "acpi.bfs=1" improves resume, please notify linux-acpi at vger.kernel.org
> >> Doing
> >> $ git grep _GTA
for correctness, that was supposed to be `git grep _BFS`.
> >> reveals that it is only implemented in the DSDT of AMD based boards.
> The kernel sees the ACPI method, but doesn't do anything with it. If
> you would like the kernel to use the method, pass acpi.bfs=1.
> > Looking at the actual “implementation” it looks like it is not
> > implemented at all (see for AMD Thatcher’s DSDT) . ;-)
> >> Was this ever tested by adding `acpi.bfs=1` to the Linux kernel command
> >> line and what was the outcome? A test on AMD Persimmon would be very
> >> interesting.
> Why would this be interesting? As noted, the method is present, but
> doesn't do anything.
So why is it there in the first place?
> Some debug information could be enabled if the OS called the function.
I read the Linux ACPI message »If "acpi.bfs=1" improves resume, …« that
way, that resume will be improved (by being quicker). I guess it was
supposed to mean, »If your system has less problems with "acpi.bfs=1"
than without, please …«.
Sorry for the confusion.
> >> It looks like support for this has been removed in the meantime though
> >> commit 3f6f49c7854c9294119437a82c5b35be78f9cea6
> >> Author: Len Brown <len.brown at intel.com>
> >> Date: Thu Jul 26 20:08:54 2012 -0400
> >> ACPI: delete _GTS/_BFS support
> >> since Linux Git tag v3.6-rc2.
> The function is part of the spec up to 4.0 and Len recommends that it
> be remove it in the future revisions.
> It seems safe to remove it, but it isn't causing harm and is part of
> the spec as implemented by coreboot.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the coreboot