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
1 file changed
