ACPICA version 20140627 released
by Moore, Robert
27 June 2014. Summary of changes for version 20140627:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Formatted Output: Implemented local versions of standard formatted output utilities such as printf, etc. Over time, it has been discovered that there are in fact many portability issues with printf, and the addition of this feature will fix/prevent these issues once and for all. Some known issues are summarized below:
1) Output of 64-bit values is not portable. For example, UINT64 is %ull for the Linux kernel and is %uI64 for some MSVC versions.
2) Invoking printf consistently in a manner that is portable across both 32-bit and 64-bit platforms is difficult at best in many situations.
3) The output format for pointers varies from system to system (leading zeros especially), and leads to inconsistent output from ACPICA across platforms.
4) Certain platform-specific printf formats may conflict with ACPICA use.
5) If there is no local C library available, ACPICA now has local support for printf.
-- To address these printf issues in a complete manner, ACPICA now directly implements a small subset of printf format specifiers, only those that it requires. Adds a new file, utilities/utprint.c. Lv Zheng.
Implemented support for ACPICA generation within the EFI environment. Initially, the AcpiDump utility is supported in the UEFI shell environment. Lv Zheng.
Added a new external interface, AcpiLogError, to improve ACPICA portability. This allows the host to redirect error messages from the ACPICA utilities. Lv Zheng.
Added and deployed new OSL file I/O interfaces to improve ACPICA portability:
AcpiOsOpenFile
AcpiOsCloseFile
AcpiOsReadFile
AcpiOsWriteFile
AcpiOsGetFileOffset
AcpiOsSetFileOffset
There are C library implementations of these functions in the new file service_layers/oslibcfs.c -- however, the functions can be implemented by the local host in any way necessary. Lv Zheng.
Implemented a mechanism to disable/enable ACPI table checksum validation at runtime. This can be useful when loading tables very early during OS initialization when it may not be possible to map the entire table in order to compute the checksum. Lv Zheng.
Fixed a buffer allocation issue for the Generic Serial Bus support. Originally, a fixed buffer length was used. This change allows for variable-length buffers based upon the protocol indicated by the field access attributes. Reported by Lan Tianyu. Lv Zheng.
Fixed a problem where an object detached from a namespace node was not properly terminated/cleared and could cause a circular list problem if reattached. ACPICA BZ 1063. David Box.
Fixed a possible recursive lock acquisition in hwregs.c. Rakib Mullick.
Fixed a possible memory leak in an error return path within the function AcpiUtCopyIobjectToIobject. ACPICA BZ 1087. Colin Ian King.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Current Release:
Non-Debug Version: 98.7K Code, 27.2K Data, 125.9K Total
Debug Version: 191.7K Code, 79.6K Data, 271.3K Total
Previous Release:
Non-Debug Version: 96.8K Code, 27.2K Data, 124.0K Total
Debug Version: 189.5K Code, 79.7K Data, 269.2K Total
2) iASL Compiler/Disassembler and Tools:
Disassembler: Add dump of ASCII equivalent text within a comment at the end of each line of the output for the Buffer() ASL operator.
AcpiDump: Miscellaneous changes:
Fixed repetitive table dump in -n mode.
For older EFI platforms, use the ACPI 1.0 GUID during RSDP search if the ACPI 2.0 GUID fails.
iASL: Fixed a problem where the compiler could fault if incorrectly given an acpidump output file as input. ACPICA BZ 1088. David Box.
AcpiExec/AcpiNames: Fixed a problem where these utilities could fault if they are invoked without any arguments.
Debugger: Fixed a possible memory leak in an error return path. ACPICA BZ 1086. Colin Ian King.
Disassembler: Cleaned up a block of code that extracts a parent Op object. Added a comment that explains that the parent is guaranteed to be valid in this case. ACPICA BZ 1069.
8 years, 3 months
[PATCH] Naive implementation of AcpiExCmosSpaceHandler()
by Anthony Jenkins
I'm testing on FreeBSD 11.0-CURRENT #18 r266756M on an HP Envy Sleekbook 6z-1100 (AMD A-10). This is a naive implementation of AcpiExCmosSpaceHandler(), it simply uses I/O ports 0x70 and 0x71 to read/write CMOS registers using AcpiHwWritePort()/AcpiHwReadPort() calls. I'm new(ish) to the ACPICA subsystem and I'm probably not going about this the right way - I think I should implement an actual FreeBSD CMOS RTC device which handles the three PNP IDs that represent those hardware devices, but this was good enough for what I was trying to do.
This fixes my HP Envy 6z-1100 laptop's suspend/resume (except video fails to resume, but I believe that's due to backlight handling from my research). Before, initiating a suspend (zzz(8)) caused the laptop to suspend and immediately resume. Now trying to track down the backlight issue. I implemented a missing _BQC method which returns a single value from the _BCL listj; I think Linux does some kind of vendor backlight control method if this method is missing.
Suggestions on the patch or backlight issue welcome.
Anthony Jenkins
diff --git a/source/components/events/evhandler.c b/source/components/events/evhandler.c
index d17411e..4f341ca 100644
--- a/source/components/events/evhandler.c
+++ b/source/components/events/evhandler.c
@@ -142,6 +142,7 @@ UINT8 AcpiGbl_DefaultAddressSpaces[ACPI_NUM_DEFAULT_SPACES] =
ACPI_ADR_SPACE_SYSTEM_MEMORY,
ACPI_ADR_SPACE_SYSTEM_IO,
ACPI_ADR_SPACE_PCI_CONFIG,
+ ACPI_ADR_SPACE_CMOS,
ACPI_ADR_SPACE_DATA_TABLE
};
@@ -451,9 +452,12 @@ AcpiEvInstallSpaceHandler (
*/
if ((Node->Type != ACPI_TYPE_DEVICE) &&
(Node->Type != ACPI_TYPE_PROCESSOR) &&
+ (Node->Type != ACPI_TYPE_REGION) &&
(Node->Type != ACPI_TYPE_THERMAL) &&
(Node != AcpiGbl_RootNode))
{
+ ACPI_DEBUG_PRINT ((ACPI_DB_OPREGION,
+ "Device %p not a DEVICE, PROCESSOR, REGION, THERMAL type or root node.\n", Node));
Status = AE_BAD_PARAMETER;
goto UnlockAndExit;
}
diff --git a/source/components/executer/exregion.c b/source/components/executer/exregion.c
index ea10a01..bfdd721 100644
--- a/source/components/executer/exregion.c
+++ b/source/components/executer/exregion.c
@@ -521,6 +521,20 @@ AcpiExPciConfigSpaceHandler (
return_ACPI_STATUS (Status);
}
+static UINT8 AcpiExCmosRead(ACPI_PHYSICAL_ADDRESS Address)
+{
+ UINT32 Value32;
+
+ AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8);
+ AcpiHwReadPort ((ACPI_IO_ADDRESS) 0x71, &Value32, 8);
+ return Value32 & 0xFF;
+}
+
+static void AcpiExCmosWrite(ACPI_PHYSICAL_ADDRESS Address, UINT8 Value)
+{
+ AcpiHwWritePort((ACPI_IO_ADDRESS) 0x70, (UINT32) Address, 8);
+ AcpiHwWritePort((ACPI_IO_ADDRESS) 0x71, (UINT32) Value, 8);
+}
/*******************************************************************************
*
@@ -545,7 +559,7 @@ AcpiExCmosSpaceHandler (
UINT32 Function,
ACPI_PHYSICAL_ADDRESS Address,
UINT32 BitWidth,
- UINT64 *Value,
+ UINT64 *Value64,
void *HandlerContext,
void *RegionContext)
{
@@ -554,7 +568,23 @@ AcpiExCmosSpaceHandler (
ACPI_FUNCTION_TRACE (ExCmosSpaceHandler);
-
+ if (Address < 0x80 &&
+ (Function == ACPI_READ || Function == ACPI_WRITE) &&
+ BitWidth <= 64)
+ {
+ UINT32 i;
+ UINT8 *Value = (UINT8 *)Value64;
+
+ for (i = 0; i < (BitWidth + 7) / 8; ++i, ++Address, ++Value) {
+ if (Function == ACPI_READ) {
+ *Value = AcpiExCmosRead(Address);
+ } else {
+ AcpiExCmosWrite(Address, *Value);
+ }
+ }
+ } else {
+ Status = AE_BAD_PARAMETER;
+ }
return_ACPI_STATUS (Status);
}
diff --git a/source/include/acconfig.h b/source/include/acconfig.h
index 6b34484..7fe2eac 100644
--- a/source/include/acconfig.h
+++ b/source/include/acconfig.h
@@ -270,7 +270,7 @@
/* Maximum SpaceIds for Operation Regions */
#define ACPI_MAX_ADDRESS_SPACE 255
-#define ACPI_NUM_DEFAULT_SPACES 4
+#define ACPI_NUM_DEFAULT_SPACES 5
/* Array sizes. Used for range checking also */
8 years, 3 months
Re: [Devel] [PATCH 1/7] ACPICA: Only include ACPI asm files if ACPI is enabled
by Zheng, Lv
Hi,
> From: Hanjun Guo [mailto:hanjun.guo@linaro.org]
> Sent: Thursday, June 05, 2014 12:11 PM
> To: Zheng, Lv; Lee Jones; Rafael J. Wysocki
>
> On 2014-6-5 9:14, Zheng, Lv wrote:
> > Hi, Lee
> >
> >> From: Lee Jones [mailto:lee.jones@linaro.org]
> >> Sent: Wednesday, June 04, 2014 8:52 PM
> >> To: Rafael J. Wysocki
> >>
> >> On Wed, 04 Jun 2014, Rafael J. Wysocki wrote:
> >>
> >>> On Wednesday, June 04, 2014 01:09:50 PM Lee Jones wrote:
> >>>> Any drivers which support ACPI and Device Tree probing need to include
> >>>> both respective header files. Without this patch, if a driver is being
> >>>> used on a platform which does not support ACPI and subsequently does not
> >>>> have the config option enabled, but includes linux/acpi.h the build
> >>>> breaks with:
> >>>>
> >>>> In file included from ../include/acpi/platform/acenv.h:150:0,
> >>>> from ../include/acpi/acpi.h:56,
> >>>> from ../include/linux/match.h:2,
> >>>> from ../drivers/i2c/i2c-core.c:43:
> >>>> ../include/acpi/platform/aclinux.h:73:23:
> >>>> fatal error: asm/acenv.h: No such file or directory
> >>>> #include <asm/acenv.h>
> >>>> ^
> >
> > Note that:
> > In our tree:
> > <asm/acenv.h> is only included by <acpi/acpi.h>.
> > And <acpi/acpi.h> is only included by
> > 1. <linux/acpi.h> when CONFIG_ACPI enabled
> > 2. <linux/sfi_acpi.h> - this is x86 specific, we'll clean it up by implementing stubs for all ACPI external interfaces.
> > So there is no case we need to exclude <asm/acenv.h> when CONFIG_ACPI is not enabled.
> >
> > I cannot find linux/match.h here.
> > If <linux/match.h> want to include ACPI features, it shouldn't include <acpi/acpi.h>, but should include <linux/acpi.h>.
> > Please refer to:
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?i...
> > And stop including <acpi/acpi.h> directly in any cases.
>
> Ah, I agree, please ignore my previous email,
> sorry for the noise.
>
> Since it is very important to include <linux/acpi.h> but not <acpi/acpi.h>,
> can we document it somewhere as the guidance? Then people will not
> make such mistake :)
After I test the ACPICA stubs and remove the only abnormal direct <acpi/acpi.h> inclusion from <linux/sfi_acpi.h>.
We could have a commit to add something like:
#ifndef _LINUX_ACPI_H
#error ....
#endif
To the <acpi/platform/aclinux.h> (the Linux OSL for ACPICA headers, it is included by <acpi/acpi.h>).
Hope this can be the hint to prevent future mistakes.
Thanks and best regards
-Lv
>
> Thanks
> Hanjun
8 years, 3 months
Re: [Devel] [PATCH 1/7] ACPICA: Only include ACPI asm files if ACPI is enabled
by Zheng, Lv
Hi, Lee
> From: Lee Jones [mailto:lee.jones@linaro.org]
> Sent: Wednesday, June 04, 2014 8:52 PM
> To: Rafael J. Wysocki
>
> On Wed, 04 Jun 2014, Rafael J. Wysocki wrote:
>
> > On Wednesday, June 04, 2014 01:09:50 PM Lee Jones wrote:
> > > Any drivers which support ACPI and Device Tree probing need to include
> > > both respective header files. Without this patch, if a driver is being
> > > used on a platform which does not support ACPI and subsequently does not
> > > have the config option enabled, but includes linux/acpi.h the build
> > > breaks with:
> > >
> > > In file included from ../include/acpi/platform/acenv.h:150:0,
> > > from ../include/acpi/acpi.h:56,
> > > from ../include/linux/match.h:2,
> > > from ../drivers/i2c/i2c-core.c:43:
> > > ../include/acpi/platform/aclinux.h:73:23:
> > > fatal error: asm/acenv.h: No such file or directory
> > > #include <asm/acenv.h>
> > > ^
Note that:
In our tree:
<asm/acenv.h> is only included by <acpi/acpi.h>.
And <acpi/acpi.h> is only included by
1. <linux/acpi.h> when CONFIG_ACPI enabled
2. <linux/sfi_acpi.h> - this is x86 specific, we'll clean it up by implementing stubs for all ACPI external interfaces.
So there is no case we need to exclude <asm/acenv.h> when CONFIG_ACPI is not enabled.
I cannot find linux/match.h here.
If <linux/match.h> want to include ACPI features, it shouldn't include <acpi/acpi.h>, but should include <linux/acpi.h>.
Please refer to:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?i...
And stop including <acpi/acpi.h> directly in any cases.
Thanks and best regards
-Lv
> >
> > Which kernel does this happen with?
>
> a0a962d (tag: refs/tags/next-20140602, refs/remotes/next/master)
> Add linux-next specific files for 20140602
>
> > > Cc: Lv Zheng <lv.zheng(a)intel.com>
> > > Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
> > > Cc: linux-acpi(a)vger.kernel.org
> > > Cc: devel(a)acpica.org
> > > Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
> > > ---
> > > include/acpi/platform/aclinux.h | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
> > > index cd1f052..fdf7663 100644
> > > --- a/include/acpi/platform/aclinux.h
> > > +++ b/include/acpi/platform/aclinux.h
> > > @@ -70,9 +70,10 @@
> > > #ifdef EXPORT_ACPI_INTERFACES
> > > #include <linux/export.h>
> > > #endif
> > > -#include <asm/acenv.h>
> > >
> > > -#ifndef CONFIG_ACPI
> > > +#ifdef CONFIG_ACPI
> > > +#include <asm/acenv.h>
> > > +#else
> > >
> > > /* External globals for __KERNEL__, stubs is needed */
> > >
> > >
> >
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
8 years, 3 months
Re: [Devel] [PATCH 1/7] ACPICA: Only include ACPI asm files if ACPI is enabled
by Zheng, Lv
Hi,
> From: linux-i2c-owner(a)vger.kernel.org [mailto:linux-i2c-owner@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Thursday, June 05, 2014 5:30 AM
>
> On Wednesday, June 04, 2014 01:51:37 PM Lee Jones wrote:
> > On Wed, 04 Jun 2014, Rafael J. Wysocki wrote:
> >
> > > On Wednesday, June 04, 2014 01:09:50 PM Lee Jones wrote:
> > > > Any drivers which support ACPI and Device Tree probing need to include
> > > > both respective header files. Without this patch, if a driver is being
> > > > used on a platform which does not support ACPI and subsequently does not
> > > > have the config option enabled, but includes linux/acpi.h the build
> > > > breaks with:
> > > >
> > > > In file included from ../include/acpi/platform/acenv.h:150:0,
> > > > from ../include/acpi/acpi.h:56,
> > > > from ../include/linux/match.h:2,
> > > > from ../drivers/i2c/i2c-core.c:43:
> > > > ../include/acpi/platform/aclinux.h:73:23:
> > > > fatal error: asm/acenv.h: No such file or directory
> > > > #include <asm/acenv.h>
> > > > ^
> > >
> > > Which kernel does this happen with?
> >
> > a0a962d (tag: refs/tags/next-20140602, refs/remotes/next/master)
> > Add linux-next specific files for 20140602
>
> It looks like the problem is with include/linux/match.h that should not
> include acpi/acpi.h directly.
This is another example that many mis-ordered inclusions are caused by the mis-ordered <asm/acpi.h> inclusion.
>
> But I can't find this file in the Linus' next branch even, so I guess it's
> on its way to that branch?
>
I guess,
In their tree, they have CONFIG_ACPI enabled for ARM, but we've changed to make:
1. <asm/acenv.h> the architecture specific layer for ACPICA, and
2. <asm/acpi.h> is now the architecture specific layer for Linux ACPI.
So they need to follow this.
Thanks and best regards
-Lv
> Rafael
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
8 years, 3 months
Re: [Devel] [PATCH 1/7] ACPICA: Only include ACPI asm files if ACPI is enabled
by Zheng, Lv
Hi, Lee
> From: Lee Jones [mailto:lee.jones@linaro.org]
> Sent: Wednesday, June 04, 2014 8:10 PM
>
> Any drivers which support ACPI and Device Tree probing need to include
> both respective header files. Without this patch, if a driver is being
> used on a platform which does not support ACPI and subsequently does not
> have the config option enabled, but includes linux/acpi.h the build
> breaks with:
>
> In file included from ../include/acpi/platform/acenv.h:150:0,
> from ../include/acpi/acpi.h:56,
> from ../include/linux/match.h:2,
> from ../drivers/i2c/i2c-core.c:43:
> ../include/acpi/platform/aclinux.h:73:23:
> fatal error: asm/acenv.h: No such file or directory
> #include <asm/acenv.h>
> ^
> Cc: Lv Zheng <lv.zheng(a)intel.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
> Cc: linux-acpi(a)vger.kernel.org
> Cc: devel(a)acpica.org
> Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
> ---
> include/acpi/platform/aclinux.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
> index cd1f052..fdf7663 100644
> --- a/include/acpi/platform/aclinux.h
> +++ b/include/acpi/platform/aclinux.h
> @@ -70,9 +70,10 @@
> #ifdef EXPORT_ACPI_INTERFACES
> #include <linux/export.h>
> #endif
> -#include <asm/acenv.h>
>
> -#ifndef CONFIG_ACPI
> +#ifdef CONFIG_ACPI
> +#include <asm/acenv.h>
> +#else
This is exactly what I want to do in the next step.
But you are a bit faster here.
I believe:
The miss-ordered inclusions of <asm/acpi.h> is the culprit of all of the miss-ordered inclusions in arch/x86/include/asm.
You should have noted that <asm/acpi.h> was originally unexpected included by some x86 specific headers.
Simply doing <asm/acenv.h> exlusion in this way might be able to fix your issue for your architecture, but it could be very likely breaking x86 builds.
You might be able to find another way to solve your build issue - for example, creating an empty <asm/acenv.h> for arch/arm.
Thanks and best regards
-Lv
>
> /* External globals for __KERNEL__, stubs is needed */
>
> --
> 1.8.3.2
8 years, 3 months