summaryrefslogtreecommitdiffstats
path: root/drivers/dma/stm32-mdma.c
diff options
context:
space:
mode:
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>2019-04-18 16:11:37 +0200
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2019-04-25 23:20:11 +0200
commitc208ac8f8f862dba7b01eb54557f4803b3c17296 (patch)
tree2d5aaed88ace2da727f4f3d86c2bf0f74a7c2861 /drivers/dma/stm32-mdma.c
parent7973b799dbea1770742851487a98276a24c961a5 (diff)
downloadlinux-stable-c208ac8f8f862dba7b01eb54557f4803b3c17296.tar.gz
linux-stable-c208ac8f8f862dba7b01eb54557f4803b3c17296.tar.bz2
linux-stable-c208ac8f8f862dba7b01eb54557f4803b3c17296.zip
x86: tsc: Rework time_cpufreq_notifier()
There are problems with running time_cpufreq_notifier() on SMP systems. First off, the rdtsc() called from there runs on the CPU executing that code and not necessarily on the CPU whose sched_clock() rate is updated which is questionable at best. Second, in the cases when the frequencies of all CPUs in an SMP system are always in sync, it is not sufficient to update just one of them or the set associated with a given cpufreq policy on frequency changes - all CPUs in the system should be updated and that would require more than a simple transition notifier. Note, however, that the underlying issue (the TSC rate depending on the CPU frequency) has not been present in hardware shipping for the last few years and in quite a few relevant cases (acpi-cpufreq in particular) running time_cpufreq_notifier() will cause the TSC to be marked as unstable anyway. For this reason, make time_cpufreq_notifier() simply mark the TSC as unstable and give up when run on SMP and only try to carry out any adjustments otherwise. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Diffstat (limited to 'drivers/dma/stm32-mdma.c')
0 files changed, 0 insertions, 0 deletions