tree 96119a814f8f5e3b22519c7a74113361cd754f52
parent e7e14b3f7a2942cb08b6a8f9cbefea0ad21a0e1f
author Harry Pan <harry.pan@intel.com> 1470992459 +0800
committer ChromeOS Commit Bot <chromeos-commit-bot@chromium.org> 1495302078 +0000

Baytrial: fix ACPI table by recollecting TOLM

On Baytrail devices (w/ 3.18 kernel), by userland 'perf top',
observed demanding clocks on __vdso_clock_gettime() since
chromeos_3.18 kernel; besides, evaluated massive calling of
clock_gettime() cost, up to 700 ns in average.

It turns out that Linux kernel of map_vdso() first call of
remap_pfn_range() does not fall into reserve_pfn_range()
due to size parameter, instead it relies on lookup_memtype()
and potentially be failed to be identified as eligible RAM
resource because the function of pat_pagerange_is_ram() actually
walks through root's sibling.

Meanwhile, on current BYT (and BSW) firmware implementation
makes System RAM resources located on child leaf, combining all
of these factors makes the kernel treat the vvar page of vdso
as a uncached-minus one leading slow access in result.

This patch recollects TOLM accessing; as Aaron recalled some
core_msr_script turns off access to TOLM register, he suggests
to store tolm to avoid getting back a zero while setting acpi
nvs space.

BUG=chromium:611896
BRANCH=firmware-clapper-5218.B
TEST=rebuild firmware, image it to BYT chrome device,
do 'cat /proc/iomem' and examine System RAM in root's sibling.

Change-Id: I8d8c0bd60c5b768aef58d61677c7d5874783b8ad
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/368516
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/506031