~hc/RK356X_SDK_RELEASE.git

..	..	@@ -3,7 +3,7 @@
3	3
4	4	Sergiu Iordache <sergiu@chromium.org>
5	5
6		-Updated: 17 November 2011
	6	+Updated: 10 Feb 2021
7	7
8	8	Introduction
9	9	------------
..	..	@@ -30,13 +30,21 @@
30	30	depends on atomic operations. At least on ARM, pgprot_noncached causes the
31	31	memory to be mapped strongly ordered, and atomic operations on strongly ordered
32	32	memory are implementation defined, and won't work on many ARMs such as omaps.
	33	+Setting ``mem_type=2`` attempts to treat the memory region as normal memory,
	34	+which enables full cache on it. This can improve the performance.
33	35
34	36	The memory area is divided into ``record_size`` chunks (also rounded down to
35		-power of two) and each oops/panic writes a ``record_size`` chunk of
	37	+power of two) and each kmesg dump writes a ``record_size`` chunk of
36	38	information.
37	39
38		-Dumping both oopses and panics can be done by setting 1 in the ``dump_oops``
39		-variable while setting 0 in that variable dumps only the panics.
	40	+Limiting which kinds of kmsg dumps are stored can be controlled via
	41	+the ``max_reason`` value, as defined in include/linux/kmsg_dump.h's
	42	+``enum kmsg_dump_reason``. For example, to store both Oopses and Panics,
	43	+``max_reason`` should be set to 2 (KMSG_DUMP_OOPS), to store only Panics
	44	+``max_reason`` should be set to 1 (KMSG_DUMP_PANIC). Setting this to 0
	45	+(KMSG_DUMP_UNDEF), means the reason filtering will be controlled by the
	46	+``printk.always_kmsg_dump`` boot param: if unset, it'll be KMSG_DUMP_OOPS,
	47	+otherwise KMSG_DUMP_MAX.
40	48
41	49	The module uses a counter to record multiple dumps but the counter gets reset
42	50	on restart (i.e. new dumps after the restart will overwrite old ones).
..	..	@@ -90,7 +98,7 @@
90	98	.mem_address = <...>,
91	99	.mem_type = <...>,
92	100	.record_size = <...>,
93		- .dump_oops = <...>,
	101	+ .max_reason = <...>,
94	102	.ecc = <...>,
95	103	};
96	104