Dear coreboot folks,
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@vger.kernel.org
Doing
$ git grep _GTA
reveals that it is only implemented in the DSDT of AMD based boards. As resuming currently does not work on the ASRock E350M1 [1], I cannot test that.
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.
It looks like support for this has been removed in the meantime though
commit 3f6f49c7854c9294119437a82c5b35be78f9cea6 Author: Len Brown len.brown@intel.com Date: Thu Jul 26 20:08:54 2012 -0400
ACPI: delete _GTS/_BFS support
since Linux Git tag v3.6-rc2.
Thanks,
Paul
[1] http://www.coreboot.org/ASRock_E350M1 [2] https://patchwork.kernel.org/patch/1246671/
Dear coreboot folks,
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@vger.kernel.org
Doing
$ git grep _GTA
reveals that it is only implemented in the DSDT of AMD based boards.
Looking at the actual “implementation” it looks like it is not implemented at all (see for AMD Thatcher’s DSDT) [1]. ;-)
$ more src/mainboard/amd/parmer/dsdt.asl […] /* * _BFS OEM Back From Sleep method * * Entry: * Arg0=The value of the sleeping state S1=1, S2=2 * * Exit: * -none- */ Method(_BFS, 1) { /* DBGO("\_BFS\n") */ /* DBGO("From S") */ /* DBGO(Arg0) */ /* DBGO(" to S0\n") */ } […]
Would a patch be useful to remove that from all of the AMD DSDTs as Len Brown wrote they requested to remove that from the next ACPI specification?
For the curious, the method _BFS is documented in
7.3.1 _BFS (Back From Sleep)
of the ACPI 4.0a specification [
As resuming currently does not work on the ASRock E350M1 [1], I cannot test that.
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.
It looks like support for this has been removed in the meantime though
commit 3f6f49c7854c9294119437a82c5b35be78f9cea6 Author: Len Brown <len.brown@intel.com> Date: Thu Jul 26 20:08:54 2012 -0400 ACPI: delete _GTS/_BFS support
since Linux Git tag v3.6-rc2.
Thanks,
Paul
[1] http://www.coreboot.org/ASRock_E350M1 [2] https://patchwork.kernel.org/patch/1246671/
[3] http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/mainboard/amd/... [4] http://www.acpi.info/spec40a.htm
On Mon, Feb 18, 2013 at 9:24 AM, Paul Menzel paulepanter@users.sourceforge.net wrote:
Dear coreboot folks,
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@vger.kernel.org
Doing
$ git grep _GTA
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) [1]. ;-)
...
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. Some debug information could be enabled if the OS called the function.
It looks like support for this has been removed in the meantime though
commit 3f6f49c7854c9294119437a82c5b35be78f9cea6 Author: Len Brown <len.brown@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.
Marc