tree 545cc0597f798e2c7ff544899023f16ef8912fad
parent 6cf9f785aaa143ca1709c05954966feffc70e4c2
author Harry Pan <harry.pan@intel.com> 1470992459 +0800
committer ChromeOS Commit Bot <chromeos-commit-bot@chromium.org> 1495255123 +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-winky-5216.1.B
TEST=rebuild firmware, deploy to remote rambi w/ 3.18 kernel,
then perform 'perf top' to profile __vdso_clock_gettime() cost;
also do 'cat /proc/iomem' 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/505933