]> git.proxmox.com Git - mirror_ubuntu-jammy-kernel.git/commit
soc: qcom: rpmh-rsc: Kill cmd_cache and find_match() with fire
authorDouglas Anderson <dianders@chromium.org>
Mon, 13 Apr 2020 17:04:10 +0000 (10:04 -0700)
committerBjorn Andersson <bjorn.andersson@linaro.org>
Tue, 14 Apr 2020 05:09:33 +0000 (22:09 -0700)
commit1bc92a933f19e2415353a4892f7df4617f691b6c
treef46420e8f45f40c66720727032a2b1cc50a939b0
parent53d49fe1ff49196712c416ddb987634483423934
soc: qcom: rpmh-rsc: Kill cmd_cache and find_match() with fire

The "cmd_cache" in RPMH wasn't terribly sensible.  Specifically:

- The current code doesn't really detect "conflicts" properly any case
  where the sequence being checked has more than one entry.  One
  simple way to see this in the current code is that if cmd[0].addr
  isn't found then cmd[1].addr is never checked.
- The code attempted to use the "cmd_cache" to update an existing
  message in a sleep/wake TCS with new data.  The goal appeared to be
  to update part of a TCS while leaving the rest of the TCS alone.  We
  never actually do this.  We always fully invalidate and re-write
  everything.
- If/when we try to optimize things to not fully invalidate / re-write
  every time we update the TCSes we'll need to think it through very
  carefully.  Specifically requirement of find_match() that the new
  sequence of addrs must match exactly the old sequence of addrs seems
  inflexible.  It's also not documented in rpmh_write() and
  rpmh_write_batch().  In any case, if we do decide to require updates
  to keep the exact same sequence and length then presumably the API
  and data structures should be updated to understand groups more
  properly.  The current algorithm doesn't really keep track of the
  length of the old sequence and there are several boundary-condition
  bugs because of that.  Said another way: if we decide to do
  something like this in the future we should start from scratch and
  thus find_match() isn't useful to keep around.

This patch isn't quite a no-op.  Specifically:

- It should be a slight performance boost of not searching through so
  many arrays.
- The old code would have done something useful in one case: it would
  allow someone calling rpmh_write() to override the data that came
  from rpmh_write_batch().  I don't believe that actually happens in
  reality.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://lore.kernel.org/r/20200413100321.v4.5.I6d3d0a3ec810dc72ff1df3cbf97deefdcdeb8eef@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
drivers/soc/qcom/rpmh-internal.h
drivers/soc/qcom/rpmh-rsc.c