On 2/10/21 11:40 AM, Randy Dunlap wrote: > Hi-- > > On 2/10/21 6:52 AM, Mukesh Ojha wrote: >> There could be a sceanario where we define some region > > scenario > >> in normal memory and use them store to logs which is later >> retrieved by bootloader during warm reset. >> >> In this scenario, we wanted to treat this memory as normal >> cacheable memory instead of default behaviour which >> is an overhead. Making it cacheable could improve >> performance. >> >> This commit gives control to change mem_type from Device >> tree, and also documents the value for normal memory. >> >> Signed-off-by: Huang Yiwei <hyi...@codeaurora.org> >> Signed-off-by: Mukesh Ojha <mo...@codeaurora.org> >> --- >> Documentation/admin-guide/ramoops.rst | 4 +++- >> fs/pstore/ram.c | 1 + >> fs/pstore/ram_core.c | 10 ++++++++-- >> 3 files changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/Documentation/admin-guide/ramoops.rst >> b/Documentation/admin-guide/ramoops.rst >> index b0a1ae7..8f107d8 100644 >> --- a/Documentation/admin-guide/ramoops.rst >> +++ b/Documentation/admin-guide/ramoops.rst >> @@ -3,7 +3,7 @@ Ramoops oops/panic logger >> >> Sergiu Iordache <ser...@chromium.org> >> >> -Updated: 17 November 2011 >> +Updated: 10 Feb 2021 >> >> Introduction >> ------------ >> @@ -30,6 +30,8 @@ mapping to pgprot_writecombine. Setting ``mem_type=1`` >> attempts to use >> 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. >> +Setting ``mem_type=2`` attempts to treat the memory region as normal memory, > > Does "mem_type=" work? or does it need to be "mem-type=", as below? > I.e., do both of them work? >
Ah yes, as documented: "Hyphens (dashes) and underscores are equivalent in parameter names," thanks. >> +which enables full cache on it. This can improve the performance. >> >> The memory area is divided into ``record_size`` chunks (also rounded down to >> power of two) and each kmesg dump writes a ``record_size`` chunk of >> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c >> index ca6d8a8..b262c57 100644 >> --- a/fs/pstore/ram.c >> +++ b/fs/pstore/ram.c >> @@ -666,6 +666,7 @@ static int ramoops_parse_dt(struct platform_device *pdev, >> field = value; \ >> } >> >> + parse_u32("mem-type", pdata->record_size, pdata->mem_type); > > here^^^^^^^^^^ -- ~Randy