summaryrefslogtreecommitdiff
path: root/drivers/soc/qcom/qcom-geni-se.c
diff options
context:
space:
mode:
authorDouglas Anderson <dianders@chromium.org>2020-05-28 17:48:34 +0300
committerBjorn Andersson <bjorn.andersson@linaro.org>2020-06-25 01:41:32 +0300
commitbe24c6a71ecfbd9436ea1f496eb518a53e06368c (patch)
tree62dd14adc92dc5e28929169201a5be3cb1b17aeb /drivers/soc/qcom/qcom-geni-se.c
parenta9541d2e8a2450ca7e97b63256e556e3fa27026d (diff)
downloadlinux-be24c6a71ecfbd9436ea1f496eb518a53e06368c.tar.xz
soc: qcom: rpmh-rsc: Don't use ktime for timeout in write_tcs_reg_sync()
The write_tcs_reg_sync() may be called after timekeeping is suspended so it's not OK to use ktime. The readl_poll_timeout_atomic() macro implicitly uses ktime. This was causing a warning at suspend time. Change to just loop 1000000 times with a delay of 1 us between loops. This may give a timeout of more than 1 second but never less and is safe even if timekeeping is suspended. NOTE: I don't have any actual evidence that we need to loop here. It's possibly that all we really need to do is just read the value back to ensure that the pipes are cleaned and the looping/comparing is totally not needed. I never saw the loop being needed in my tests. However, the loop shouldn't hurt. Reviewed-by: Stephen Boyd <sboyd@kernel.org> Reviewed-by: Maulik Shah <mkshah@codeaurora.org> Fixes: 91160150aba0 ("soc: qcom: rpmh-rsc: Timeout after 1 second in write_tcs_reg_sync()") Reported-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20200528074530.1.Ib86e5b406fe7d16575ae1bb276d650faa144b63c@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Diffstat (limited to 'drivers/soc/qcom/qcom-geni-se.c')
0 files changed, 0 insertions, 0 deletions