Patched in Tegra support.

3 files changed, 11 insertions, 373 deletions

diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt
index e20b6daaced..5cc699ba545 100644
--- a/Documentation/acpi/apei/einj.txt
+++ b/Documentation/acpi/apei/einj.txt
@@ -47,61 +47,20 @@ directory apei/einj. The following files are provided.
 
 - param1
   This file is used to set the first error parameter value. Effect of
-  parameter depends on error_type specified.
+  parameter depends on error_type specified. For memory error, this is
+  physical memory address.  Only available if param_extension module
+  parameter is specified.
 
 - param2
   This file is used to set the second error parameter value. Effect of
-  parameter depends on error_type specified.
-
-- notrigger
-  The EINJ mechanism is a two step process. First inject the error, then
-  perform some actions to trigger it. Setting "notrigger" to 1 skips the
-  trigger phase, which *may* allow the user to cause the error in some other
-  context by a simple access to the cpu, memory location, or device that is
-  the target of the error injection. Whether this actually works depends
-  on what operations the BIOS actually includes in the trigger phase.
-
-BIOS versions based in the ACPI 4.0 specification have limited options
-to control where the errors are injected.  Your BIOS may support an
-extension (enabled with the param_extension=1 module parameter, or
-boot command line einj.param_extension=1). This allows the address
-and mask for memory injections to be specified by the param1 and
-param2 files in apei/einj.
-
-BIOS versions using the ACPI 5.0 specification have more control over
-the target of the injection. For processor related errors (type 0x1,
-0x2 and 0x4) the APICID of the target should be provided using the
-param1 file in apei/einj. For memory errors (type 0x8, 0x10 and 0x20)
-the address is set using param1 with a mask in param2 (0x0 is equivalent
-to all ones). For PCI express errors (type 0x40, 0x80 and 0x100) the
-segment, bus, device and function are specified using param1:
-
-         31     24 23    16 15    11 10      8  7        0
-        +-------------------------------------------------+
-        | segment |   bus  | device | function | reserved |
-        +-------------------------------------------------+
-
-An ACPI 5.0 BIOS may also allow vendor specific errors to be injected.
-In this case a file named vendor will contain identifying information
-from the BIOS that hopefully will allow an application wishing to use
-the vendor specific extension to tell that they are running on a BIOS
-that supports it. All vendor extensions have the 0x80000000 bit set in
-error_type. A file vendor_flags controls the interpretation of param1
-and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
-documentation for details (and expect changes to this API if vendors
-creativity in using this feature expands beyond our expectations).
-
-Example:
-# cd /sys/kernel/debug/apei/einj
-# cat available_error_type              # See which errors can be injected
-0x00000002      Processor Uncorrectable non-fatal
-0x00000008      Memory Correctable
-0x00000010      Memory Uncorrectable non-fatal
-# echo 0x12345000 > param1              # Set memory address for injection
-# echo 0xfffffffffffff000 > param2      # Mask - anywhere in this page
-# echo 0x8 > error_type                 # Choose correctable memory error
-# echo 1 > error_inject                 # Inject now
+  parameter depends on error_type specified. For memory error, this is
+  physical memory address mask.  Only available if param_extension
+  module parameter is specified.
 
+Injecting parameter support is a BIOS version specific extension, that
+is, it only works on some BIOS version.  If you want to use it, please
+make sure your BIOS version has the proper support and specify
+"param_extension=y" in module parameter.
 
 For more information about EINJ, please refer to ACPI specification
-version 4.0, section 17.5 and ACPI 5.0, section 18.6.
+version 4.0, section 17.5.
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
deleted file mode 100644
index 54469bc81b1..00000000000
--- a/Documentation/acpi/enumeration.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-ACPI based device enumeration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus,
-SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave
-devices behind serial bus controllers.
-
-In addition we are starting to see peripherals integrated in the
-SoC/Chipset to appear only in ACPI namespace. These are typically devices
-that are accessed through memory-mapped registers.
-
-In order to support this and re-use the existing drivers as much as
-possible we decided to do following:
-
-        o Devices that have no bus connector resource are represented as
-          platform devices.
-
-        o Devices behind real busses where there is a connector resource
-          are represented as struct spi_device or struct i2c_device
-          (standard UARTs are not busses so there is no struct uart_device).
-
-As both ACPI and Device Tree represent a tree of devices (and their
-resources) this implementation follows the Device Tree way as much as
-possible.
-
-The ACPI implementation enumerates devices behind busses (platform, SPI and
-I2C), creates the physical devices and binds them to their ACPI handle in
-the ACPI namespace.
-
-This means that when ACPI_HANDLE(dev) returns non-NULL the device was
-enumerated from ACPI namespace. This handle can be used to extract other
-device-specific configuration. There is an example of this below.
-
-Platform bus support
-~~~~~~~~~~~~~~~~~~~~
-Since we are using platform devices to represent devices that are not
-connected to any physical bus we only need to implement a platform driver
-for the device and add supported ACPI IDs. If this same IP-block is used on
-some other non-ACPI platform, the driver might work out of the box or needs
-some minor changes.
-
-Adding ACPI support for an existing driver should be pretty
-straightforward. Here is the simplest example:
-
-        #ifdef CONFIG_ACPI
-        static struct acpi_device_id mydrv_acpi_match[] = {
-                /* ACPI IDs here */
-                { }
-        };
-        MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match);
-        #endif
-
-        static struct platform_driver my_driver = {
-                ...
-                .driver = {
-                        .acpi_match_table = ACPI_PTR(mydrv_acpi_match),
-                },
-        };
-
-If the driver needs to perform more complex initialization like getting and
-configuring GPIOs it can get its ACPI handle and extract this information
-from ACPI tables.
-
-Currently the kernel is not able to automatically determine from which ACPI
-device it should make the corresponding platform device so we need to add
-the ACPI device explicitly to acpi_platform_device_ids list defined in
-drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
-and I2C devices are created automatically as described below.
-
-SPI serial bus support
-~~~~~~~~~~~~~~~~~~~~~~
-Slave devices behind SPI bus have SpiSerialBus resource attached to them.
-This is extracted automatically by the SPI core and the slave devices are
-enumerated once spi_register_master() is called by the bus driver.
-
-Here is what the ACPI namespace for a SPI slave might look like:
-
-        Device (EEP0)
-        {
-                Name (_ADR, 1)
-                Name (_CID, Package() {
-                        "ATML0025",
-                        "AT25",
-                })
-                ...
-                Method (_CRS, 0, NotSerialized)
-                {
-                        SPISerialBus(1, PolarityLow, FourWireMode, 8,
-                                ControllerInitiated, 1000000, ClockPolarityLow,
-                                ClockPhaseFirst, "\\_SB.PCI0.SPI1",)
-                }
-                ...
-
-The SPI device drivers only need to add ACPI IDs in a similar way than with
-the platform device drivers. Below is an example where we add ACPI support
-to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
-
-        #ifdef CONFIG_ACPI
-        static struct acpi_device_id at25_acpi_match[] = {
-                { "AT25", 0 },
-                { },
-        };
-        MODULE_DEVICE_TABLE(acpi, at25_acpi_match);
-        #endif
-
-        static struct spi_driver at25_driver = {
-                .driver = {
-                        ...
-                        .acpi_match_table = ACPI_PTR(at25_acpi_match),
-                },
-        };
-
-Note that this driver actually needs more information like page size of the
-eeprom etc. but at the time writing this there is no standard way of
-passing those. One idea is to return this in _DSM method like:
-
-        Device (EEP0)
-        {
-                ...
-                Method (_DSM, 4, NotSerialized)
-                {
-                        Store (Package (6)
-                        {
-                                "byte-len", 1024,
-                                "addr-mode", 2,
-                                "page-size, 32
-                        }, Local0)
-
-                        // Check UUIDs etc.
-
-                        Return (Local0)
-                }
-
-Then the at25 SPI driver can get this configation by calling _DSM on its
-ACPI handle like:
-
-        struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
-        struct acpi_object_list input;
-        acpi_status status;
-
-        /* Fill in the input buffer */
-
-        status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM",
-                                      &input, &output);
-        if (ACPI_FAILURE(status))
-                /* Handle the error */
-
-        /* Extract the data here */
-
-        kfree(output.pointer);
-
-I2C serial bus support
-~~~~~~~~~~~~~~~~~~~~~~
-The slaves behind I2C bus controller only need to add the ACPI IDs like
-with the platform and SPI drivers. However the I2C bus controller driver
-needs to call acpi_i2c_register_devices() after it has added the adapter.
-
-An I2C bus (controller) driver does:
-
-        ...
-        ret = i2c_add_numbered_adapter(adapter);
-        if (ret)
-                /* handle error */
-
-        of_i2c_register_devices(adapter);
-        /* Enumerate the slave devices behind this bus via ACPI */
-        acpi_i2c_register_devices(adapter);
-
-Below is an example of how to add ACPI support to the existing mpu3050
-input driver:
-
-        #ifdef CONFIG_ACPI
-        static struct acpi_device_id mpu3050_acpi_match[] = {
-                { "MPU3050", 0 },
-                { },
-        };
-        MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match);
-        #endif
-
-        static struct i2c_driver mpu3050_i2c_driver = {
-                .driver = {
-                        .name   = "mpu3050",
-                        .owner  = THIS_MODULE,
-                        .pm     = &mpu3050_pm,
-                        .of_match_table = mpu3050_of_match,
-                        .acpi_match_table  ACPI_PTR(mpu3050_acpi_match),
-                },
-                .probe          = mpu3050_probe,
-                .remove         = mpu3050_remove,
-                .id_table       = mpu3050_ids,
-        };
-
-GPIO support
-~~~~~~~~~~~~
-ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
-and GpioInt. These resources are used be used to pass GPIO numbers used by
-the device to the driver. For example:
-
-        Method (_CRS, 0, NotSerialized)
-        {
-                Name (SBUF, ResourceTemplate()
-                {
-                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
-                                IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
-                                0x00, ResourceConsumer,,)
-                        {
-                                // Pin List
-                                0x0055
-                        }
-                        ...
-
-                        Return (SBUF)
-                }
-        }
-
-These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
-specifies the path to the controller. In order to use these GPIOs in Linux
-we need to translate them to the Linux GPIO numbers.
-
-The driver can do this by including <linux/acpi_gpio.h> and then calling
-acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
-negative errno if there was no translation found.
-
-Other GpioIo parameters must be converted first by the driver to be
-suitable to the gpiolib before passing them.
-
-In case of GpioInt resource an additional call to gpio_to_irq() must be
-done before calling request_irq().
diff --git a/Documentation/acpi/initrd_table_override.txt b/Documentation/acpi/initrd_table_override.txt
deleted file mode 100644
index 35c3f541547..00000000000
--- a/Documentation/acpi/initrd_table_override.txt
+++ /dev/null
@@ -1,94 +0,0 @@
-Overriding ACPI tables via initrd
-=================================
-
-1) Introduction (What is this about)
-2) What is this for
-3) How does it work
-4) References (Where to retrieve userspace tools)
-
-1) What is this about
----------------------
-
-If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to
-override nearly any ACPI table provided by the BIOS with an instrumented,
-modified one.
-
-For a full list of ACPI tables that can be overridden, take a look at
-the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c
-All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
-be overridable, except:
-   - ACPI_SIG_RSDP (has a signature of 6 bytes)
-   - ACPI_SIG_FACS (does not have an ordinary ACPI table header)
-Both could get implemented as well.
-
-
-2) What is this for
--------------------
-
-Please keep in mind that this is a debug option.
-ACPI tables should not get overridden for productive use.
-If BIOS ACPI tables are overridden the kernel will get tainted with the
-TAINT_OVERRIDDEN_ACPI_TABLE flag.
-Complain to your platform/BIOS vendor if you find a bug which is so sever
-that a workaround is not accepted in the Linux kernel.
-
-Still, it can and should be enabled in any kernel, because:
-  - There is no functional change with not instrumented initrds
-  - It provides a powerful feature to easily debug and test ACPI BIOS table
-    compatibility with the Linux kernel.
-
-
-3) How does it work
--------------------
-
-# Extract the machine's ACPI tables:
-cd /tmp
-acpidump >acpidump
-acpixtract -a acpidump
-# Disassemble, modify and recompile them:
-iasl -d *.dat
-# For example add this statement into a _PRT (PCI Routing Table) function
-# of the DSDT:
-Store("HELLO WORLD", debug)
-iasl -sa dsdt.dsl
-# Add the raw ACPI tables to an uncompressed cpio archive.
-# They must be put into a /kernel/firmware/acpi directory inside the
-# cpio archive.
-# The uncompressed cpio archive must be the first.
-# Other, typically compressed cpio archives, must be
-# concatenated on top of the uncompressed one.
-mkdir -p kernel/firmware/acpi
-cp dsdt.aml kernel/firmware/acpi
-# A maximum of: #define ACPI_OVERRIDE_TABLES 10
-# tables are  currently allowed (see osl.c):
-iasl -sa facp.dsl
-iasl -sa ssdt1.dsl
-cp facp.aml kernel/firmware/acpi
-cp ssdt1.aml kernel/firmware/acpi
-# Create the uncompressed cpio archive and concatenate the original initrd
-# on top:
-find kernel | cpio -H newc --create > /boot/instrumented_initrd
-cat /boot/initrd >>/boot/instrumented_initrd
-# reboot with increased acpi debug level, e.g. boot params:
-acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF
-# and check your syslog:
-[    1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
-[    1.272091] [ACPI Debug]  String [0x0B] "HELLO WORLD"
-
-iasl is able to disassemble and recompile quite a lot different,
-also static ACPI tables.
-
-
-4) Where to retrieve userspace tools
-------------------------------------
-
-iasl and acpixtract are part of Intel's ACPICA project:
-http://acpica.org/
-and should be packaged by distributions (for example in the acpica package
-on SUSE).
-
-acpidump can be found in Len Browns pmtools:
-ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump
-This tool is also part of the acpica package on SUSE.
-Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels:
-/sys/firmware/acpi/tables