Linux kernel source tree https://git.amat.us/linux/atom/include/acpi?h=v3.3 2012-01-24T00:47:06Z 2012-01-24T00:47:06Z Len Brown len.brown@intel.com 2012-01-24T00:47:06Z urn:sha1:eb7004e623637a6c2b32317c000d4b617b5cb053 2012-01-21T06:09:00Z Myron Stowe mstowe@redhat.com 2012-01-21T02:13:37Z urn:sha1:1001a3a307ca2425c028fd23b8ad05ad8bb048dd With the conversion of atomicio's routines in place (see commits 6f68c91c55e and 700130b41f4), atomicio.[ch] can be removed, replacing the APEI specific pre-mapping capabilities with the more generalized versions that drivers/acpi/osl.c provides. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com> 2012-01-21T06:08:17Z Myron Stowe mstowe@redhat.com 2012-01-21T02:13:24Z urn:sha1:e615bf5b5519862ab66172f4dec7455d6543a578 Base ACPI (CA) currently does not support atomic 64-bit reads and writes (acpi_read() and acpi_write() split 64-bit loads/stores into two 32-bit transfers) yet APEI expects 64-bit transfer capability, even when running on 32-bit systems. This patch implements 64-bit read and write routines for APEI usage. This patch re-factors similar functionality introduced in commit 04c25997c97, bringing it into the ACPI subsystem in preparation for removing ./drivers/acpi/atomicio.[ch]. In the implementation I have replicated acpi_os_read_memory() and acpi_os_write_memory(), creating 64-bit versions for APEI to utilize, as opposed to something more elegant. My thinking is that we should attempt to see if we can get ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write() interfaces are natively 64-bit capable and then subsequently remove the replication. Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com> 2012-01-20T02:26:32Z Thomas Renninger trenn@suse.de 2012-01-19T17:18:43Z urn:sha1:99b725084450bbc6f8e1ab20a0df4cc291c342b5 Delay the setting up of features (cpuidle, throttling by calling acpi_processor_start()) to the time when the hotplugged core got onlined the first time and got fully initialized. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com> 2012-01-18T23:51:48Z Linus Torvalds torvalds@linux-foundation.org 2012-01-18T23:51:48Z urn:sha1:507a03c1cba0e32309223d23d19a1bfc0916c140 This includes initial support for the recently published ACPI 5.0 spec. In particular, support for the "hardware-reduced" bit that eliminates the dependency on legacy hardware. APEI has patches resulting from testing on real hardware. Plus other random fixes. * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: (52 commits) acpi/apei/einj: Add extensions to EINJ from rev 5.0 of acpi spec intel_idle: Split up and provide per CPU initialization func ACPI processor: Remove unneeded variable passed by acpi_processor_hotadd_init V2 ACPI processor: Remove unneeded cpuidle_unregister_driver call intel idle: Make idle driver more robust intel_idle: Fix a cast to pointer from integer of different size warning in intel_idle ACPI: kernel-parameters.txt : Add intel_idle.max_cstate intel_idle: remove redundant local_irq_disable() call ACPI processor: Fix error path, also remove sysdev link ACPI: processor: fix acpi_get_cpuid for UP processor intel_idle: fix API misuse ACPI APEI: Convert atomicio routines ACPI: Export interfaces for ioremapping/iounmapping ACPI registers ACPI: Fix possible alignment issues with GAS 'address' references ACPI, ia64: Use SRAT table rev to use 8bit or 16/32bit PXM fields (ia64) ACPI, x86: Use SRAT table rev to use 8bit or 32bit PXM fields (x86/x86-64) ACPI: Store SRAT table revision ACPI, APEI, Resolve false conflict between ACPI NVS and APEI ACPI, Record ACPI NVS regions ACPI, APEI, EINJ, Refine the fix of resource conflict ... 2012-01-18T06:15:54Z Len Brown len.brown@intel.com 2012-01-18T06:15:54Z urn:sha1:79ba0db69c5887f1ad4ed51d58894e7e889084b0 2012-01-18T06:14:17Z Tony Luck tony.luck@intel.com 2012-01-17T20:10:16Z urn:sha1:c130bd6f82e5dda28b1a19741c4c2fe269713199 ACPI 5.0 provides extensions to the EINJ mechanism to specify the target for the error injection - by APICID for cpu related errors, by address for memory related errors, and by segment/bus/device/function for PCIe related errors. Also extensions for vendor specific error injections. Tested-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> 2012-01-17T09:19:04Z Kurt Garloff kurt@garloff.de 2012-01-17T09:18:02Z urn:sha1:8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. In order to know whether or not, we must know what version the SRAT table has. This patch stores the SRAT table revision for later consumption by arch specific __init functions. Signed-off-by: Kurt Garloff <kurt@garloff.de> Signed-off-by: Len Brown <len.brown@intel.com> 2012-01-17T08:38:52Z Bob Moore robert.moore@intel.com 2012-01-12T05:29:41Z urn:sha1:5d1f86572685d577b76142b7c61453000e1a5e26 Version 20120111. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> 2012-01-17T08:38:50Z Lin Ming ming.m.lin@intel.com 2012-01-12T05:10:32Z urn:sha1:f654c0fefa8c16d439185b61442710fadc167e78 Allows drivers to determine if any memory or I/O addresses will conflict with addresses used by ACPI operation regions. Introduces a new interface, acpi_check_address_range. http://marc.info/?t=132251388700002&r=1&w=2 Reported-and-tested-by: Luca Tettamanti <kronos.it@gmail.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>