summaryrefslogtreecommitdiffstats
path: root/drivers/soc/qcom/Kconfig
diff options
context:
space:
mode:
authorDouglas Anderson <dianders@chromium.org>2020-05-04 10:50:19 -0700
committerBjorn Andersson <bjorn.andersson@linaro.org>2020-05-15 11:45:21 -0700
commitd2a8cfc6f320263b90ca523590a339661d0f4fae (patch)
tree4610bbcfc44e8d0c4b615934375973afd9483b0b /drivers/soc/qcom/Kconfig
parent555701a45f146673c8961f084b6880c637d41129 (diff)
downloadlinux-d2a8cfc6f320263b90ca523590a339661d0f4fae.tar.gz
linux-d2a8cfc6f320263b90ca523590a339661d0f4fae.tar.bz2
linux-d2a8cfc6f320263b90ca523590a339661d0f4fae.zip
soc: qcom: rpmh-rsc: Remove the pm_lock
It has been postulated that the pm_lock is bad for performance because a CPU currently running rpmh_flush() could block other CPUs from coming out of idle. Similarly CPUs coming out of / going into idle all need to contend with each other for the spinlock just to update the variable tracking who's in PM. Let's optimize this a bit. Specifically: - Use a count rather than a bitmask. This is faster to access and also means we can use the atomic_inc_return() function to really detect who the last one to enter PM was. - Accept that it's OK if we race and are doing the flush (because we think we're last) while another CPU is coming out of idle. As long as we block that CPU if/when it tries to do an active-only transfer we're OK. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20200504104917.v6.5.I295cb72bc5334a2af80313cbe97cb5c9dcb1442c@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Diffstat (limited to 'drivers/soc/qcom/Kconfig')
0 files changed, 0 insertions, 0 deletions