arm: dts: rk3288-evb-rk818: fix 32k out to xin32k

[firefly-linux-kernel-4.4.55.git] / Documentation / ramoops.txt

diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 69b3cac4749d76811be9c39a6e3605023a7639fd..9264bcab4099a1e2198eb0acaf79c95ac4c62cb5 100644 (file)
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -14,11 +14,19 @@ survive after a restart.
 
 1. Ramoops concepts
 
 
 1. Ramoops concepts
 

-Ramoops uses a predefined memory area to store the dump. The start and size of
-the memory area are set using two variables:
+Ramoops uses a predefined memory area to store the dump. The start and size
+and type of the memory area are set using three variables:

   * "mem_address" for the start
   * "mem_size" for the size. The memory size will be rounded down to a
   power of two.
   * "mem_address" for the start
   * "mem_size" for the size. The memory size will be rounded down to a
   power of two.

+  * "mem_type" to specifiy if the memory type (default is pgprot_writecombine).
+
+Typically the default value of mem_type=0 should be used as that sets the pstore
+mapping to pgprot_writecombine. Setting mem_type=1 attempts to use
+pgprot_noncached, which only works on some platforms. This is because pstore
+depends on atomic operations. At least on ARM, pgprot_noncached causes the
+memory to be mapped strongly ordered, and atomic operations on strongly ordered
+memory are implementation defined, and won't work on many ARMs such as omaps.

 
 The memory area is divided into "record_size" chunks (also rounded down to
 power of two) and each oops/panic writes a "record_size" chunk of
 
 The memory area is divided into "record_size" chunks (also rounded down to
 power of two) and each oops/panic writes a "record_size" chunk of


@@ -37,7 +45,7 @@ corrupt, but usually it is restorable.
 
 2. Setting the parameters
 
 
 2. Setting the parameters
 

-Setting the ramoops parameters can be done in 2 different manners:
+Setting the ramoops parameters can be done in 3 different manners:

  1. Use the module parameters (which have the names of the variables described
  as before).
  For quick debugging, you can also reserve parts of memory during boot
  1. Use the module parameters (which have the names of the variables described
  as before).
  For quick debugging, you can also reserve parts of memory during boot


@@ -46,7 +54,9 @@ Setting the ramoops parameters can be done in 2 different manners:
  kernel to use only the first 128 MB of memory, and place ECC-protected ramoops
  region at 128 MB boundary:
  "mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1"
  kernel to use only the first 128 MB of memory, and place ECC-protected ramoops
  region at 128 MB boundary:
  "mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1"

- 2. Use a platform device and set the platform data. The parameters can then
+ 2. Use Device Tree bindings, as described in
+ Documentation/device-tree/bindings/misc/ramoops.txt.
+ 3. Use a platform device and set the platform data. The parameters can then

  be set through that platform data. An example of doing that is:
 
 #include <linux/pstore_ram.h>
  be set through that platform data. An example of doing that is:
 
 #include <linux/pstore_ram.h>


@@ -55,6 +65,7 @@ Setting the ramoops parameters can be done in 2 different manners:
 static struct ramoops_platform_data ramoops_data = {
         .mem_size               = <...>,
         .mem_address            = <...>,
 static struct ramoops_platform_data ramoops_data = {
         .mem_size               = <...>,
         .mem_address            = <...>,

+        .mem_type               = <...>,

         .record_size            = <...>,
         .dump_oops              = <...>,
         .ecc                    = <...>,
         .record_size            = <...>,
         .dump_oops              = <...>,
         .ecc                    = <...>,