summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorSuzuki K Poulose <suzuki.poulose@arm.com>2018-03-26 15:12:48 +0100
committerWill Deacon <will.deacon@arm.com>2018-03-26 18:01:44 +0100
commit05abb595bbaccc9c4290bee62086d0eeea9f0f32 (patch)
tree1d396820ddc09bfbd216337f460a1928aa048f89 /tools
parent6e616864f21160d8d503523b60a53a29cecc6f24 (diff)
downloadlinux-05abb595bbaccc9c4290bee62086d0eeea9f0f32.tar.bz2
arm64: Delay enabling hardware DBM feature
We enable hardware DBM bit in a capable CPU, very early in the boot via __cpu_setup. This doesn't give us a flexibility of optionally disable the feature, as the clearing the bit is a bit costly as the TLB can cache the settings. Instead, we delay enabling the feature until the CPU is brought up into the kernel. We use the feature capability mechanism to handle it. The hardware DBM is a non-conflicting feature. i.e, the kernel can safely run with a mix of CPUs with some using the feature and the others don't. So, it is safe for a late CPU to have this capability and enable it, even if the active CPUs don't. To get this handled properly by the infrastructure, we unconditionally set the capability and only enable it on CPUs which really have the feature. Also, we print the feature detection from the "matches" call back to make sure we don't mislead the user when none of the CPUs could use the feature. Cc: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: Dave Martin <dave.martin@arm.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions